[PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning
Andy Shevchenko
andy.shevchenko at gmail.com
Tue Jul 4 08:46:59 PDT 2017
On Tue, Jul 4, 2017 at 6:14 PM, Gabriele Paoloni
<gabriele.paoloni at huawei.com> wrote:
>> > In my case I'd like to have a platform device using the resources
>> that are
>> > parsed from the ACPI table (i.e. as it is done now by
>> > acpi_create_platform_device()).
>>
>> So far so good. Nothing prevents you to do that.
>>
>> > If my understanding is correct, if I declared an mfd_cell for my IPMI
>> child
>> > the mfd subsystem would create a platform device for such child and
>> > therefore acpi_create_platform_device() would fail to create a new
>> platform
>> > device as adev->physical_node_count will be non zero.
>> > However as things stand now mfd_cell devices can only use the
>> resources
>> > that are statically defined in the code (and therefore not the ones
>> in the
>> > ACPI nodes)...am I right?
>>
>> You may file resources first and then register MFD cells. See many
>> existing examples in the kernel.
>
> Well I had a look around the Kernel I have seen no mfd cells using
> Resources that are not statically defined:
> i.e. cell->resources in mfd_add_device() always points to statically
> defined resource structures.
>
> Usually for ACPI devices first you need to parse the ACPI resources
> from the table calling acpi_dev_get_resources(), then you iterate
> over the resource list and fill the resource array by calling
> acpi_platform_fill_resurces() (as in acpi_create_platform_device())
>
> With respect to my case are you suggesting dynamically allocate a
> resource array and fill it using the same fashion as
> acpi_create_platform_device(), then point cell->resources to such
> array before calling mfd_add_device() ?
You may do it on stack. Define your cell statically (but not const)
and apply resources just before mfd_add_devices() call.
There are examples in the existing drivers. Intel LPC comes to my mind
and perhaps PMC (Broxton), though latter has too much other stuff
around.
--
With Best Regards,
Andy Shevchenko
More information about the linux-arm-kernel
mailing list