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

Pull ACPI updates from Rafael Wysocki:
 "These fix issues, add new quirks, rearrange the IRQ override quirk
  definitions, add new helpers and switch over code to using them,
  rework a couple of interfaces to be more flexible, eliminate strncpy()
  usage from PNP, extend the ACPI PCC mailbox driver and clean up code.

  This is based on ACPI thermal driver changes that are present in the
  thermal control updates for 6.7-rc1 pull request (they are depended on
  by the ACPI utilities updates). However, the ACPI thermal driver
  changes are not included in the list of specific ACPI changes below.

  Specifics:

   - Add symbol definitions related to CDAT to the ACPICA code (Dave
     Jiang)

   - Use the acpi_device_is_present() helper in more places and rename
     acpi_scan_device_not_present() to be about enumeration (James
     Morse)

   - Add __printf format attribute to acpi_os_vprintf() (Su Hui)

   - Clean up departures from kernel coding style in the low-level
     interface for ACPICA (Jonathan Bergh)

   - Replace strncpy() with strscpy() in acpi_osi_setup() (Justin Stitt)

   - Fail FPDT parsing on zero length records and add proper handling
     for fpdt_process_subtable() to acpi_init_fpdt() (Vasily Khoruzhick)

   - Rework acpi_handle_list handling so as to manage it dynamically,
     including size computation (Rafael Wysocki)

   - Clean up ACPI utilities code so as to make it follow the kernel
     coding style (Jonathan Bergh)

   - Consolidate IRQ trigger-type override DMI tables and drop .ident
     values from dmi_system_id tables used for ACPI resources management
     quirks (Hans de Goede)

   - Add ACPI IRQ override for TongFang GMxXGxx (Werner Sembach)

   - Allow _DSD buffer data only for byte accessors and document the
     _DSD data buffer GUID (Andy Shevchenko)

   - Drop BayTrail and Lynxpoint pinctrl device IDs from the ACPI LPSS
     driver, because it does not need them (Raag Jadav)

   - Add acpi_backlight=vendor quirk for Toshiba Portégé R100 (Ondrej
     Zary)

   - Add "vendor" backlight quirks for 3 Lenovo x86 Android tablets
     (Hans de Goede)

   - Move Xiaomi Mi Pad 2 backlight quirk to its own section (Hans de
     Goede)

   - Annotate struct prm_module_info with __counted_by (Kees Cook)

   - Fix AER info corruption in aer_recover_queue() when error status
     data has multiple sections (Shiju Jose)

   - Make APEI use ERST maximum execution time for slow devices (Jeshua
     Smith)

   - Add support for platform notification handling to the PCC mailbox
     driver and modify it to support shared interrupts for multiple
     subspaces (Huisong Li)

   - Define common macros to use when referring to various bitfields in
     the PCC generic communications channel command and status fields
     and use them in some drivers (Sudeep Holla)

   - Add EC GPE detection quirk for HP 250 G7 Notebook PC (Jonathan
     Denose)

   - Fix and clean up create_pnp_modalias() and create_of_modalias()
     (Christophe JAILLET)

   - Modify 2 pieces of code to use acpi_evaluate_dsm_typed() (Andy
     Shevchenko)

   - Define acpi_dev_uid_match() for matching _UID and use it in several
     places (Raag Jadav)

   - Use acpi_device_uid() for fetching _UID in 2 places (Raag Jadav)

   - Add context argument to acpi_dev_install_notify_handler() (Rafael
     Wysocki)

   - Clarify ACPI bus concepts in the ACPI device enumeration
     documentation (Rafael Wysocki)

   - Switch over the ACPI AC and ACPI PAD drivers to using the platform
     driver interface which, is more logically consistent than binding a
     driver directly to an ACPI device object, and clean them up (Michal
     Wilczynski)

   - Replace strncpy() in the PNP code with either memcpy() or strscpy()
     as appropriate (Justin Stitt)

   - Clean up coding style in pnp.h (GuoHua Cheng)"

* tag 'acpi-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (54 commits)
  ACPI: resource: Do IRQ override on TongFang GMxXGxx
  perf: arm_cspmu: use acpi_dev_hid_uid_match() for matching _HID and _UID
  ACPI: EC: Add quirk for HP 250 G7 Notebook PC
  ACPI: x86: use acpi_dev_uid_match() for matching _UID
  ACPI: utils: use acpi_dev_uid_match() for matching _UID
  pinctrl: intel: use acpi_dev_uid_match() for matching _UID
  ACPI: utils: Introduce acpi_dev_uid_match() for matching _UID
  ACPI: sysfs: Clean up create_pnp_modalias() and create_of_modalias()
  ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias()
  ACPI: acpi_pad: Rename ACPI device from device to adev
  ACPI: acpi_pad: Use dev groups for sysfs
  ACPI: acpi_pad: Replace acpi_driver with platform_driver
  ACPI: APEI: Use ERST timeout for slow devices
  ACPI: scan: Rename acpi_scan_device_not_present() to be about enumeration
  PNP: replace deprecated strncpy() with memcpy()
  PNP: ACPI: replace deprecated strncpy() with strscpy()
  perf: qcom: use acpi_device_uid() for fetching _UID
  ACPI: sysfs: use acpi_device_uid() for fetching _UID
  ACPI: scan: Use the acpi_device_is_present() helper in more places
  ACPI: AC: Rename ACPI device from device to adev
  ...

1 files changed, 43 insertions, 0 deletions

diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index 56d9913a3370..d79f69390991 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -64,6 +64,49 @@ If the driver needs to perform more complex initialization like getting and
 configuring GPIOs it can get its ACPI handle and extract this information
 from ACPI tables.
 
+ACPI device objects
+===================
+
+Generally speaking, there are two categories of devices in a system in which
+ACPI is used as an interface between the platform firmware and the OS: Devices
+that can be discovered and enumerated natively, through a protocol defined for
+the specific bus that they are on (for example, configuration space in PCI),
+without the platform firmware assistance, and devices that need to be described
+by the platform firmware so that they can be discovered.  Still, for any device
+known to the platform firmware, regardless of which category it falls into,
+there can be a corresponding ACPI device object in the ACPI Namespace in which
+case the Linux kernel will create a struct acpi_device object based on it for
+that device.
+
+Those struct acpi_device objects are never used for binding drivers to natively
+discoverable devices, because they are represented by other types of device
+objects (for example, struct pci_dev for PCI devices) that are bound to by
+device drivers (the corresponding struct acpi_device object is then used as
+an additional source of information on the configuration of the given device).
+Moreover, the core ACPI device enumeration code creates struct platform_device
+objects for the majority of devices that are discovered and enumerated with the
+help of the platform firmware and those platform device objects can be bound to
+by platform drivers in direct analogy with the natively enumerable devices
+case.  Therefore it is logically inconsistent and so generally invalid to bind
+drivers to struct acpi_device objects, including drivers for devices that are
+discovered with the help of the platform firmware.
+
+Historically, ACPI drivers that bound directly to struct acpi_device objects
+were implemented for some devices enumerated with the help of the platform
+firmware, but this is not recommended for any new drivers.  As explained above,
+platform device objects are created for those devices as a rule (with a few
+exceptions that are not relevant here) and so platform drivers should be used
+for handling them, even though the corresponding ACPI device objects are the
+only source of device configuration information in that case.
+
+For every device having a corresponding struct acpi_device object, the pointer
+to it is returned by the ACPI_COMPANION() macro, so it is always possible to
+get to the device configuration information stored in the ACPI device object
+this way.  Accordingly, struct acpi_device can be regarded as a part of the
+interface between the kernel and the ACPI Namespace, whereas device objects of
+other types (for example, struct pci_dev or struct platform_device) are used
+for interacting with the rest of the system.
+
 DMA support
 ===========