Commit 9bbf8e17 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'acpi-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 

Pull ACPI updates from Rafael Wysocki:
 "These update APEI (new EINJv2 error injection, assorted fixes), fix
  the ACPI processor driver, update the legacy ACPI /proc interface
  (multiple assorted fixes of minor issues) and several assorted ACPI
  drivers (minor fixes and cleanups):

   - Printing the address in acpi_ex_trace_point() is either incorrect
     during early kernel boot or not really useful later when pathnames
     resolve properly, so stop doing it (Mario Limonciello)

   - Address several minor issues in the legacy ACPI proc interface
     (Andy Shevchenko)

   - Fix acpi_object union initialization in the ACPI processor driver
     to avoid using memory that contains leftover data (Sebastian Ott)

   - Make the ACPI processor perflib driver take the initial _PPC limit
     into account as appropriate (Jiayi Li)

   - Fix message formatting in the ACPI processor throttling driver and
     in the ACPI PCI link driver (Colin Ian King)

   - Clean up general ACPI PM domain handling (Rafael Wysocki)

   - Fix iomem-related sparse warnings in the APEI EINJ driver (Zaid
     Alali, Tony Luck)

   - Add EINJv2 error injection support to the APEI EINJ driver (Zaid
     Alali)

   - Fix memory corruption in error_type_set() in the APEI EINJ driver
     (Dan Carpenter)

   - Fix less than zero comparison on a size_t variable in the APEI EINJ
     driver (Colin Ian King)

   - Fix check and iounmap of an uninitialized pointer in the APEI EINJ
     driver (Colin Ian King)

   - Add TAINT_MACHINE_CHECK to the GHES panic path in APEI to improve
     diagnostics and post-mortem analysis (Breno Leitao)

   - Update APEI reviewer records and other ACPI-related information in
     MAINTAINERS as well as the contact information in the ACPI ABI
     documentation (Rafael Wysocki)

   - Fix the handling of synchronous uncorrected memory errors in APEI
     (Shuai Xue)

   - Remove an AudioDSP-related ID from the ACPI LPSS driver (Andy
     Shevchenko)

   - Replace sprintf()/scnprintf() with sysfs_emit() in the ACPI fan
     driver and update a debug message in fan_get_state_acpi4() (Eslam
     Khafagy, Abdelrahman Fekry, Sumeet Pawnikar)

   - Add Intel Wildcat Lake support to the ACPI DPTF driver (Srinivas
     Pandruvada)

   - Add more debug information regarding failing firmware updates to
     the ACPI pfr_update driver (Chen Yu)

   - Reduce the verbosity of the ACPI PRM (platform runtime mechanism)
     driver to avoid user confusion (Zhu Qiyu)

   - Replace sprintf() with sysfs_emit() in the ACPI TAD (time and alarm
     device) driver (Sukrut Heroorkar)

   - Enable CONFIG_ACPI_DEBUG by default to make it easier to get ACPI
     debug messages from OEM platforms (Mario Limonciello)

   - Fix parent device references in ASL examples in the ACPI
     documentation and fix spelling and style in the gpio-properties
     documentation in firmware-guide (Andy Shevchenko)

   - Fix typos in ACPI documentation and comments (Bjorn Helgaas)"

* tag 'acpi-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (39 commits)
  ACPI: Fix typos
  ACPI/PCI: Remove space before newline
  ACPI: processor: throttling: Remove space before newline
  ACPI: processor: perflib: Fix initial _PPC limit application
  ACPI/PNP: Use my kernel.org address in MAINTAINERS and ABI docs
  ACPI: TAD: Replace sprintf() with sysfs_emit()
  ACPI: APEI: handle synchronous exceptions in task work
  ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered
  ACPI: APEI: MAINTAINERS: Update reviewers for APEI
  Documentation: ACPI: Fix parent device references
  ACPI: fan: Update debug message in fan_get_state_acpi4()
  ACPI: PRM: Reduce unnecessary printing to avoid user confusion
  ACPI: fan: Replace sprintf() with sysfs_emit()
  ACPI: APEI: EINJ: Fix trigger actions
  ACPI: processor: fix acpi_object initialization
  ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path
  ACPI: LPSS: Remove AudioDSP related ID
  Documentation: firmware-guide: gpio-properties: Spelling and style fixes
  ACPI: fan: Replace sprintf()/scnprintf() with sysfs_emit() in show() functions
  ACPI: PM: Set .detach in acpi_general_pm_domain definition
  ...
parents 53edfece ea34e67a

Documentation/ABI/testing/sysfs-bus-acpi

+9 −9
Original line number Diff line number Diff line 
What:		/sys/bus/acpi/devices/.../path

Date:		December 2006

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		This attribute indicates the full path of ACPI namespace

		object associated with the device object.  For example,
@@ -12,7 +12,7 @@ Description: 


What:		/sys/bus/acpi/devices/.../modalias

Date:		July 2007

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		This attribute indicates the PNP IDs of the device object.

		That is acpi:HHHHHHHH:[CCCCCCC:].  Where each HHHHHHHH or
@@ -20,7 +20,7 @@ Description: 


What:		/sys/bus/acpi/devices/.../hid

Date:		April 2005

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		This attribute indicates the hardware ID (_HID) of the

		device object.  For example, PNP0103.
@@ -29,14 +29,14 @@ Description: 


What:		/sys/bus/acpi/devices/.../description

Date:		October 2012

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		This attribute contains the output of the device object's

		_STR control method, if present.



What:		/sys/bus/acpi/devices/.../adr

Date:		October 2012

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		This attribute contains the output of the device object's

		_ADR control method, which is present for ACPI device
@@ -45,14 +45,14 @@ Description: 


What:		/sys/bus/acpi/devices/.../uid

Date:		October 2012

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		This attribute contains the output of the device object's

		_UID control method, if present.



What:		/sys/bus/acpi/devices/.../eject

Date:		December 2006

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		Writing 1 to this attribute will trigger hot removal of

		this device object.  This file exists for every device
@@ -60,7 +60,7 @@ Description: 


What:		/sys/bus/acpi/devices/.../status

Date:		Jan, 2014

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		(RO) Returns the ACPI device status: enabled, disabled or

		functioning or present, if the method _STA is present.
@@ -90,7 +90,7 @@ Description: 


What:		/sys/bus/acpi/devices/.../hrv

Date:		Apr, 2016

Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>

Contact:	Rafael J. Wysocki <rafael@kernel.org>

Description:

		(RO) Allows users to read the hardware version of non-PCI

		hardware, if the _HRV control method is present.  It is mostly

Documentation/ABI/testing/sysfs-firmware-acpi

+3 −3
Original line number Diff line number Diff line
@@ -108,15 +108,15 @@ Description: 
		number of a "General Purpose Events" (GPE).



		A GPE vectors to a specified handler in AML, which

		can do a anything the BIOS writer wants from

		can do anything the BIOS writer wants from

		OS context.  GPE 0x12, for example, would vector

		to a level or edge handler called _L12 or _E12.

		The handler may do its business and return.

		Or the handler may send send a Notify event

		Or the handler may send a Notify event

		to a Linux device driver registered on an ACPI device,

		such as a battery, or a processor.



		To figure out where all the SCI's are coming from,

		To figure out where all the SCIs are coming from,

		/sys/firmware/acpi/interrupts contains a file listing

		every possible source, and the count of how many

		times it has triggered::

Documentation/firmware-guide/acpi/apei/einj.rst

+33 −0
Original line number Diff line number Diff line
@@ -59,6 +59,9 @@ The following files belong to it: 
  0x00000200        Platform Correctable

  0x00000400        Platform Uncorrectable non-fatal

  0x00000800        Platform Uncorrectable fatal

  V2_0x00000001     EINJV2 Processor Error

  V2_0x00000002     EINJV2 Memory Error

  V2_0x00000004     EINJV2 PCI Express Error

  ================  ===================================



  The format of the file contents are as above, except present are only
@@ -88,6 +91,8 @@ The following files belong to it: 
      Memory address and mask valid (param1 and param2).

    Bit 2

      PCIe (seg,bus,dev,fn) valid (see param4 below).

    Bit 3

      EINJv2 extension structure is valid



  If set to zero, legacy behavior is mimicked where the type of

  injection specifies just one bit set, and param1 is multiplexed.
@@ -122,6 +127,13 @@ The following files belong to it: 
  this actually works depends on what operations the BIOS actually

  includes in the trigger phase.



- component_id0 .. component_idN, component_syndrome0 .. component_syndromeN



  These files are used to set the "Component Array" field

  of the EINJv2 Extension Structure. Each holds a 128-bit

  hex value. Writing just a newline to any of these files

  sets an invalid (all-ones) value.



CXL error types are supported from ACPI 6.5 onwards (given a CXL port

is present). The EINJ user interface for CXL error types is at

<debugfs mount point>/cxl. The following files belong to it:
@@ -194,6 +206,27 @@ An error injection example:: 
  # echo 0x8 > error_type			# Choose correctable memory error

  # echo 1 > error_inject			# Inject now



An EINJv2 error injection example::



  # cd /sys/kernel/debug/apei/einj

  # cat available_error_type			# See which errors can be injected

  0x00000002	Processor Uncorrectable non-fatal

  0x00000008	Memory Correctable

  0x00000010	Memory Uncorrectable non-fatal

  V2_0x00000001	EINJV2 Processor Error

  V2_0x00000002	EINJV2 Memory Error



  # echo 0x12345000 > param1			# Set memory address for injection

  # echo 0xfffffffffffff000 > param2		# Range - anywhere in this page

  # echo 0x1 > component_id0			# First device ID

  # echo 0x4 > component_syndrome0		# First error syndrome

  # echo 0x2 > component_id1			# Second device ID

  # echo 0x4 > component_syndrome1		# Second error syndrome

  # echo '' > component_id2			# Mark id2 invalid to terminate list

  # echo V2_0x2 > error_type			# Choose EINJv2 memory error

  # echo 0xa > flags				# set flags to indicate EINJv2

  # echo 1 > error_inject			# Inject now



You should see something like this in dmesg::



  [22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR

Documentation/firmware-guide/acpi/gpio-properties.rst

+17 −17
Original line number Diff line number Diff line
@@ -6,7 +6,7 @@ _DSD Device Properties Related to GPIO 


With the release of ACPI 5.1, the _DSD configuration object finally

allows names to be given to GPIOs (and other things as well) returned

by _CRS.  Previously, we were only able to use an integer index to find

by _CRS. Previously we were only able to use an integer index to find

the corresponding GPIO, which is pretty error prone (it depends on

the _CRS output ordering, for example).
@@ -49,11 +49,11 @@ index 
pin

  Pin in the GpioIo()/GpioInt() resource. Typically this is zero.

active_low

  If 1, the GPIO is marked as active_low.

  If 1, the GPIO is marked as active-low.



Since ACPI GpioIo() resource does not have a field saying whether it is

active low or high, the "active_low" argument can be used here.  Setting

it to 1 marks the GPIO as active low.

active-low or active-high, the "active_low" argument can be used here.

Setting it to 1 marks the GPIO as active-low.



Note, active_low in _DSD does not make sense for GpioInt() resource and

must be 0. GpioInt() resource has its own means of defining it.
@@ -92,8 +92,8 @@ and polarity settings. The table below shows the expectations: 
|             | Low         | as low, assuming active                       |

+-------------+-------------+-----------------------------------------------+



That said, for our above example the both GPIOs, since the bias setting

is explicit and _DSD is present, will be treated as active with a high

That said, for our above example, since the bias setting is explicit and

_DSD is present, both GPIOs will be treated as active with a high

polarity and Linux will configure the pins in this state until a driver

reprograms them differently.
@@ -231,8 +231,8 @@ In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV, 
available to the driver can be used to identify the device and that is supposed

to be sufficient to determine the meaning and purpose of all of the GPIO lines

listed by the GpioIo()/GpioInt() resources returned by _CRS.  In other words,

the driver is supposed to know what to use the GpioIo()/GpioInt() resources for

once it has identified the device.  Having done that, it can simply assign names

the driver is supposed to know what to use from the GpioIo()/GpioInt() resources

for once it has identified the device. Having done that, it can simply assign names

to the GPIO lines it is going to use and provide the GPIO subsystem with a

mapping between those names and the ACPI GPIO resources corresponding to them.
@@ -270,7 +270,7 @@ Using the _CRS fallback 


If a device does not have _DSD or the driver does not create ACPI GPIO

mapping, the Linux GPIO framework refuses to return any GPIOs. This is

because the driver does not know what it actually gets. For example if we

because the driver does not know what it actually gets. For example, if we

have a device like below::



  Device (BTH)
@@ -292,7 +292,7 @@ The driver might expect to get the right GPIO when it does:: 
	...error handling...



but since there is no way to know the mapping between "reset" and

the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT).

the GpioIo() in _CRS the desc will hold ERR_PTR(-ENOENT).



The driver author can solve this by passing the mapping explicitly

(this is the recommended way and it's documented in the above chapter).
@@ -318,15 +318,15 @@ Case 1:: 
  desc = gpiod_get(dev, "non-null-connection-id", flags);

  desc = gpiod_get_index(dev, "non-null-connection-id", index, flags);



Case 1 assumes that corresponding ACPI device description must have

defined device properties and will prevent from getting any GPIO resources

otherwise.



Case 2::



  desc = gpiod_get(dev, NULL, flags);

  desc = gpiod_get_index(dev, NULL, index, flags);



Case 1 assumes that corresponding ACPI device description must have

defined device properties and will prevent to getting any GPIO resources

otherwise.



Case 2 explicitly tells GPIO core to look for resources in _CRS.



Be aware that gpiod_get_index() in cases 1 and 2, assuming that there

Documentation/firmware-guide/acpi/i2c-muxes.rst

+4 −4
Original line number Diff line number Diff line
@@ -14,7 +14,7 @@ Consider this topology:: 
    |      |   | 0x70 |--CH01--> i2c client B (0x50)

    +------+   +------+



which corresponds to the following ASL::

which corresponds to the following ASL (in the scope of \_SB)::



    Device (SMB1)

    {
@@ -24,7 +24,7 @@ which corresponds to the following ASL:: 
            Name (_HID, ...)

            Name (_CRS, ResourceTemplate () {

                I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,

                            AddressingMode7Bit, "^SMB1", 0x00,

                            AddressingMode7Bit, "\\_SB.SMB1", 0x00,

                            ResourceConsumer,,)

            }
@@ -37,7 +37,7 @@ which corresponds to the following ASL:: 
                    Name (_HID, ...)

                    Name (_CRS, ResourceTemplate () {

                        I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,

                                    AddressingMode7Bit, "^CH00", 0x00,

                                    AddressingMode7Bit, "\\_SB.SMB1.CH00", 0x00,

                                    ResourceConsumer,,)

                    }

                }
@@ -52,7 +52,7 @@ which corresponds to the following ASL:: 
                    Name (_HID, ...)

                    Name (_CRS, ResourceTemplate () {

                        I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,

                                    AddressingMode7Bit, "^CH01", 0x00,

                                    AddressingMode7Bit, "\\_SB.SMB1.CH01", 0x00,

                                    ResourceConsumer,,)

                    }

                }