Revert commit c10383e8ddf4 ("ACPI: scan: Release PM resources blocked
by unused objects"), because it causes boot issues to appear on some
platforms.

Reported-by: Kyle D. Pelton <kyle.d.pelton@intel.com>
Reported-by: Saranya Gopal <saranya.gopal@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge updates of the code associating ACPI device objects with
devices and PNP code, processor driver, and Intel LPSS driver updates
for 5.16-rc1:

 - Make the association of ACPI device objects with PCI devices more
   straightforward and simplify the code doing that for all devices
   in general (Rafael Wysocki).

 - Use acpi_device_adr() in acpi_find_child_device() instead of
   evaluating _ADR (Rafael Wysocki).

 - Drop duplicate device IDs from PNP device IDs list (Krzysztof
   Kozlowski).

 - Allow acpi_idle_play_dead() to use C3 on AMD processors (Richard
   Gong).

 - Use ACPI_COMPANION() to simplify code in the ACPI driver for Intel
   SoCs (Rafael Wysocki).

* acpi-glue:
  ACPI: glue: Use acpi_device_adr() in acpi_find_child_device()
  ACPI: glue: Look for ACPI bus type only if ACPI companion is not known
  ACPI: glue: Drop cleanup callback from struct acpi_bus_type
  PCI: ACPI: Drop acpi_pci_bus

* acpi-pnp:
  ACPI: PNP: remove duplicated BRI0A49 and BDP3336 entries

* acpi-processor:
  ACPI: processor idle: Allow playing dead in C3 state

* acpi-soc:
  ACPI: LPSS: Use ACPI_COMPANION() directly

Instead of evaluating _ADR in acpi_find_child_device(), use the
observation that it has already been evaluated and the value returned
by it has been stored in the pnp.type.bus_address field of the ACPI
device object at hand.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

On some systems the ACPI namespace contains device objects that are
not used in certain configurations of the system.  If they start off
in the D0 power state configuration, they will stay in it until the
system reboots, because of the lack of any mechanism possibly causing
their configuration to change.  If that happens, they may prevent
some power resources from being turned off or generally they may
prevent the platform from getting into the deepest low-power states
thus causing some energy to be wasted.

Address this issue by changing the configuration of unused ACPI
device objects to the D3cold power state one after carrying out
the ACPI-based enumeration of devices.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091
Link: https://lore.kernel.org/linux-acpi/20211007205126.11769-1-mario.limonciello@amd.com/
Reported-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>

Notice that it is not necessary to look for the "ACPI bus type" of
the device in acpi_device_notify() if the device's ACPI companion
is set upfront, so modify the code to do that lookup only if it is
necessary to find the ACPI companion.

Also notice that if the device's ACPI companion is not set upfront
in acpi_device_notify(), the device cannot be either a PCI one or a
platform one, so check for these bus types only if the device's
ACPI companion is set.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Ferry Toth <fntoth@gmail.com>

Since PCI was the only user of the ->cleanup callback in struct
acpi_bus_type and it is not using struct acpi_bus_type any more,
drop that callback from there and update acpi_device_notify_remove()
accordingly.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Ferry Toth <fntoth@gmail.com>

The acpi_pci_bus structure was used primarily for running
acpi_pci_find_companion() during PCI device objects registration,
but after commit 375553a93201 ("PCI: Setup ACPI fwnode early and at
the same time with OF") that function is called by pci_setup_device()
via pci_set_acpi_fwnode(), which happens before calling
pci_device_add() on the new PCI device object, so its ACPI companion
has been set already when acpi_device_notify() runs and it will never
call ->find_companion() from acpi_pci_bus.

For this reason, modify acpi_device_notify() and
acpi_device_notify_remove() to call pci_acpi_setup() and
pci_acpi_cleanup(), respectively, directly on PCI device objects
and drop acpi_pci_bus altogether.

While at it, notice that pci_acpi_setup() and pci_acpi_cleanup()
can obtain the ACPI companion pointer, which is guaranteed to not
be NULL, from their callers and modify them to work that way so
as to reduce the number of redundant checks somewhat.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Ferry Toth <fntoth@gmail.com>

Get rid of acpi_platform_notify() which is redundant and
make device_platform_notify() in the driver core call
acpi_device_notify() and acpi_device_notify_remove() directly.

No functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Since the return values of acpi_device_notify() and
acpi_device_notify_remove() are discarded by their only caller,
change their return type to void.

No functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Make the code flow in acpi_device_notify() more straightforward and
make it use dev_dbg() and acpi_handle_debug() for printing debug
messages.

The only expected functional impact of this change is the content of
the debug messages printed by acpi_device_notify().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>