On Tue, Jul 4, 2017 at 6:14 PM, Gabriele Paoloni <gabriele.paoloni@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
