On Tue, Aug 16, 2022 at 2:33 PM John Garry <[email protected]> wrote:
>
> For ACPI devices with the enumeration_by_parent flag set, we expect the
> parent device to enumerate the device after the ACPI scan.
>
> This patch does partially the same for devices which are enumerated as PNP
> devices.
>
> We still want PNP scan code to create the per-ACPI device PNP device, but
> hold off adding the device to allow the parent to do this optionally.
>
> Flag acpi_device.driver_data is used as temp store as a reference to the
> PNP device for the parent.
>
> A note on impact of this change:
>
> For the hisi_lpc driver, for the UART ACPI node we have a binding like:
>
> Device (LPC0.CON0) {
> Name (_HID, "HISI1031")
> Name (_CID, "PNP0501")
> Name (LORS, ResourceTemplate() {
> QWordIO (
>
> We have the compat and hid string. The ACPI/PNP code matches the compat
> string first, and creates the PNP device. In doing so, the acpi_device
> created has physical_node_count member set in acpi_bind_one().
>
> The hisi_lpc driver also creates a platform device serial device for uart,
> which is the actual uart which we want to use - see
> hisi_lpc_acpi_add_child(). That function does not check
> physical_node_count value, but acpi_create_platform_device() does check it.
> So if we were to move hisi_lpc_acpi_add_child() across to use
> acpi_create_platform_device(), then the change in this patch is required to
> not create the PNP binding (so that physical_node_count is not set from
> PNP probe).
Hmm... The flag, as I interpret it, is equal to "the device in
question is a peripheral device to the non-discoverable bus, such as
SPI, I2C or UART". I.o.w. I do not see how PNP suits here. So, from my
point of view it seems like an abuse of the flag. Not sure the current
state of affairs in ACPI glue layer regarding this, though.
--
With Best Regards,
Andy Shevchenko