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

Pull ACPI updates from Rafael Wysocki:
 "ACPI and PNP updates for 6.1-rc1.

  These rearrange the ACPI device object initialization code (to get rid
  of a redundant parent pointer from struct acpi_device among other
  things), unify the _UID handling, drop support for some _OSI strings
  that should not be necessary any more, add new IDs to support more
  hardware and some more quirks, fix a few issues and clean up code all
  over.

  Specifics:

   - Reimplement acpi_get_pci_dev() using the list of physical devices
     associated with the given ACPI device object (Rafael Wysocki)

   - Rename ACPI device object reference counting functions (Rafael
     Wysocki)

   - Rearrange ACPI device object initialization code (Rafael Wysocki)

   - Drop parent field from struct acpi_device (Rafael Wysocki)

   - Extend the the int3472-tps68470 driver to support multiple
     consumers of a single TPS68470 along with the requisite
     framework-level support (Daniel Scally)

   - Filter out non-memory resources in is_memory(), add a helper
     function to find all memory type resources of an ACPI device object
     and use that function in 3 places (Heikki Krogerus)

   - Add IRQ override quirks for Asus Vivobook K3402ZA/K3502ZA and ASUS
     model S5402ZA (Tamim Khan, Kellen Renshaw)

   - Fix acpi_dev_state_d0() kerneldoc (Sakari Ailus)

   - Fix up suspend-to-idle support on ASUS Rembrandt laptops (Mario
     Limonciello)

   - Clean up ACPI platform devices support code (Andy Shevchenko, John
     Garry)

   - Clean up ACPI bus management code (Andy Shevchenko, ye xingchen)

   - Add support for multiple DMA windows with different offsets to the
     ACPI device enumeration code and use it on LoongArch (Jianmin Lv)

   - Clean up the ACPI LPSS (Intel SoC) driver (Andy Shevchenko)

   - Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable (Mario
     Limonciello)

   - Drop unused dev_fmt() and redundant 'HMAT' prefix from the HMAT
     parsing code (Liu Shixin)

   - Make ACPI FPDT parsing code avoid calling acpi_os_map_memory() on
     invalid physical addresses (Hans de Goede)

   - Silence missing-declarations warning related to Apple device
     properties management (Lukas Wunner)

   - Disable frequency invariance in the CPPC library if registers used
     by cppc_get_perf_ctrs() are accessed via PCC (Jeremy Linton)

   - Add ACPI disabled check to acpi_cpc_valid() (Perry Yuan)

   - Fix Tx acknowledge in the PCC address space handler (Huisong Li)

   - Use wait_for_completion_timeout() for PCC mailbox operations
     (Huisong Li)

   - Release resources on PCC address space setup failure path (Rafael
     Mendonca)

   - Remove unneeded result variables from APEI code (ye xingchen)

   - Print total number of records found during BERT log parsing (Dmitry
     Monakhov)

   - Drop support for 3 _OSI strings that should not be necessary any
     more and update documentation on custom _OSI strings so that adding
     new ones is not encouraged any more (Mario Limonciello)

   - Drop unneeded result variable from ec_write() (ye xingchen)

   - Remove the leftover struct acpi_ac_bl from the ACPI AC driver
     (Hanjun Guo)

   - Reorder symbols to get rid of a few forward declarations in the
     ACPI fan driver (Uwe Kleine-König)

   - Add Toshiba Satellite/Portege Z830 ACPI backlight quirk (Arvid
     Norlander)

   - Add ARM DMA-330 controller to the supported list in the ACPI AMBA
     driver (Vijayenthiran Subramaniam)

   - Drop references to non-functional 01.org/linux-acpi web site from
     MAINTAINERS and Kconfig help texts (Rafael Wysocki)

   - Replace strlcpy() with unused retval with strscpy() in the ACPI
     support code (Wolfram Sang)

   - Do not initialize ret in main() in the pfrut utility (Shi junming)

   - Drop useless ACPI DSDT override documentation (Rafael Wysocki)

   - Fix a few typos and wording mistakes in the ACPI device enumeration
     documentation (Jean Delvare)

   - Introduce acpi_dev_uid_to_integer() to convert a _UID string into
     an integer value (Andy Shevchenko)

   - Use acpi_dev_uid_to_integer() in several places to unify _UID
     handling (Andy Shevchenko)

   - Drop unused pnpid32_to_pnpid() declaration from PNP code (Gaosheng
     Cui)"

* tag 'acpi-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (79 commits)
  ACPI: LPSS: Deduplicate skipping device in acpi_lpss_create_device()
  ACPI: LPSS: Replace loop with first entry retrieval
  ACPI: x86: s2idle: Add another ID to s2idle_dmi_table
  ACPI: x86: s2idle: Fix a NULL pointer dereference
  MAINTAINERS: Drop records pointing to 01.org/linux-acpi
  ACPI: Kconfig: Drop link to https://01.org/linux-acpi
  ACPI: docs: Drop useless DSDT override documentation
  ACPI: DPTF: Drop stale link from Kconfig help
  ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13
  ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7
  ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
  ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
  ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID
  ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt
  ACPI: x86: s2idle: Move _HID handling for AMD systems into structures
  platform/x86: int3472: Add board data for Surface Go2 IR camera
  platform/x86: int3472: Support multiple gpio lookups in board data
  platform/x86: int3472: Support multiple clock consumers
  ACPI: bus: Add iterator for dependent devices
  ACPI: scan: Add acpi_dev_get_next_consumer_dev()
  ...

3 files changed, 19 insertions, 35 deletions

diff --git a/Documentation/admin-guide/acpi/dsdt-override.rst b/Documentation/admin-guide/acpi/dsdt-override.rst
deleted file mode 100644
index 50bd7f194bf4..000000000000
--- a/Documentation/admin-guide/acpi/dsdt-override.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-===============
-Overriding DSDT
-===============
-
-Linux supports a method of overriding the BIOS DSDT:
-
-CONFIG_ACPI_CUSTOM_DSDT - builds the image into the kernel.
-
-When to use this method is described in detail on the
-Linux/ACPI home page:
-https://01.org/linux-acpi/documentation/overriding-dsdt
diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index dbb03022b127..b9dc0c603f36 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -21,7 +21,7 @@ possible we decided to do following:
   - Devices behind real busses where there is a connector resource
     are represented as struct spi_device or struct i2c_device. Note
     that standard UARTs are not busses so there is no struct uart_device,
-    although some of them may be represented by sturct serdev_device.
+    although some of them may be represented by struct serdev_device.
 
 As both ACPI and Device Tree represent a tree of devices (and their
 resources) this implementation follows the Device Tree way as much as
@@ -205,7 +205,7 @@ Here is what the ACPI namespace for a SPI slave might look like::
 		}
 		...
 
-The SPI device drivers only need to add ACPI IDs in a similar way than with
+The SPI device drivers only need to add ACPI IDs in a similar way to
 the platform device drivers. Below is an example where we add ACPI support
 to at25 SPI eeprom driver (this is meant for the above ACPI snippet)::
 
@@ -362,7 +362,7 @@ These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
 specifies the path to the controller. In order to use these GPIOs in Linux
 we need to translate them to the corresponding Linux GPIO descriptors.
 
-There is a standard GPIO API for that and is documented in
+There is a standard GPIO API for that and it is documented in
 Documentation/admin-guide/gpio/.
 
 In the above example we can get the corresponding two GPIO descriptors with
@@ -538,8 +538,8 @@ information.
 PCI hierarchy representation
 ============================
 
-Sometimes could be useful to enumerate a PCI device, knowing its position on the
-PCI bus.
+Sometimes it could be useful to enumerate a PCI device, knowing its position on
+the PCI bus.
 
 For example, some systems use PCI devices soldered directly on the mother board,
 in a fixed position (ethernet, Wi-Fi, serial ports, etc.). In this conditions it
@@ -550,7 +550,7 @@ To identify a PCI device, a complete hierarchical description is required, from
 the chipset root port to the final device, through all the intermediate
 bridges/switches of the board.
 
-For example, let us assume to have a system with a PCIe serial port, an
+For example, let's assume we have a system with a PCIe serial port, an
 Exar XR17V3521, soldered on the main board. This UART chip also includes
 16 GPIOs and we want to add the property ``gpio-line-names`` [1] to these pins.
 In this case, the ``lspci`` output for this component is::
@@ -593,8 +593,8 @@ of the chipset bridge (also called "root port") with address::
 
 	Bus: 0 - Device: 14 - Function: 1
 
-To find this information is necessary disassemble the BIOS ACPI tables, in
-particular the DSDT (see also [2])::
+To find this information, it is necessary to disassemble the BIOS ACPI tables,
+in particular the DSDT (see also [2])::
 
 	mkdir ~/tables/
 	cd ~/tables/
diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst
index 05869c0045d7..784850adfcb6 100644
--- a/Documentation/firmware-guide/acpi/osi.rst
+++ b/Documentation/firmware-guide/acpi/osi.rst
@@ -41,26 +41,23 @@ But it is likely that they will all eventually be added.
 What should an OEM do if they want to support Linux and Windows
 using the same BIOS image?  Often they need to do something different
 for Linux to deal with how Linux is different from Windows.
-Here the BIOS should ask exactly what it wants to know:
 
+In this case, the OEM should create custom ASL to be executed by the
+Linux kernel and changes to Linux kernel drivers to execute this custom
+ASL.  The easiest way to accomplish this is to introduce a device specific
+method (_DSM) that is called from the Linux kernel.
+
+In the past the kernel used to support something like:
 _OSI("Linux-OEM-my_interface_name")
 where 'OEM' is needed if this is an OEM-specific hook,
 and 'my_interface_name' describes the hook, which could be a
 quirk, a bug, or a bug-fix.
 
-In addition, the OEM should send a patch to upstream Linux
-via the linux-acpi@vger.kernel.org mailing list.  When that patch
-is checked into Linux, the OS will answer "YES" when the BIOS
-on the OEM's system uses _OSI to ask if the interface is supported
-by the OS.  Linux distributors can back-port that patch for Linux
-pre-installs, and it will be included by all distributions that
-re-base to upstream.  If the distribution can not update the kernel binary,
-they can also add an acpi_osi=Linux-OEM-my_interface_name
-cmdline parameter to the boot loader, as needed.
-
-If the string refers to a feature where the upstream kernel
-eventually grows support, a patch should be sent to remove
-the string when that support is added to the kernel.
+However this was discovered to be abused by other BIOS vendors to change
+completely unrelated code on completely unrelated systems.  This prompted
+an evaluation of all of it's uses. This uncovered that they aren't needed
+for any of the original reasons. As such, the kernel will not respond to
+any custom Linux-* strings by default.
 
 That was easy.  Read on, to find out how to do it wrong.