Messages in this thread | | | Subject | Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices | From | John Garry <> | Date | Fri, 20 Apr 2018 15:09:30 +0100 |
| |
On 20/04/2018 14:52, Mika Westerberg wrote: > On Fri, Apr 20, 2018 at 02:24:18PM +0100, John Garry wrote: >> Hi Mika, >> >> On 20/04/2018 14:07, Mika Westerberg wrote: >>> On Fri, Apr 20, 2018 at 06:07:25PM +0800, John Garry wrote: >>>> + } else { >>>> + device->driver_data = dev; >>> >>> I think this deserves a comment explaining why we (ab)use driver_data >>> like this. >> >> Sure, could add. I didn't see any other way for the acpi_device structure to >> reference the derived PNP device. >> >> TBH, This overall approach is not good since we are creating the PNP device >> in the scan, and then leaving the device in limbo, waiting for the parent to >> add it, if at all. There's no rule for this. >> >> So I'm looking for ideas on how to improve this. >
Hi Mika,
> One idea is to make pnpacpi_add_device() available outside of PNP and > call it directly (or some variation) in hisi_lpc.c when it walks over > its children. >
I did consider this initially and it seems quite straightforward.
However I think the problem is that we would need to modify the acpi_device child resources from FW with kernel-specific resources, which does not seem right (I think that is what you meant). As I see, this is one reason that we went in the direction of modelling the host as an MFD, as we could set the resources of the mfd_cells.
So adding a variant of pnpacpi_add_device() could work, or modifying pnpacpi_add_device() to accept a callback to translate the resources. But this feature is specific to our very special requirement...
Thanks, John
> . >
| |