RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning

[Gabriele Paoloni]

Hi Mika

> -----Original Message-----
> From: linux-pci-owner@xxxxxxxxxxxxxxx [mailto:linux-pci-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Gabriele Paoloni
> Sent: 19 June 2017 11:05
> To: Mika Westerberg
> Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> catalin.marinas@xxxxxxx; will.deacon@xxxxxxx; robh+dt@xxxxxxxxxx;
> frowand.list@xxxxxxxxx; bhelgaas@xxxxxxxxxx; arnd@xxxxxxxx; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx; mark.rutland@xxxxxxx;
> brian.starkey@xxxxxxx; olof@xxxxxxxxx; benh@xxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; Linuxarm; linux-
> pci@xxxxxxxxxxxxxxx; minyard@xxxxxxx; John Garry; xuwei (O)
> Subject: RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
> devices before scanning
> 
> Hi Mika
> 
> > -----Original Message-----
> > From: Mika Westerberg [mailto:mika.westerberg@xxxxxxxxxxxxxxx]
> > Sent: 19 June 2017 11:02
> > To: Gabriele Paoloni
> > Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> > catalin.marinas@xxxxxxx; will.deacon@xxxxxxx; robh+dt@xxxxxxxxxx;
> > frowand.list@xxxxxxxxx; bhelgaas@xxxxxxxxxx; arnd@xxxxxxxx; linux-
> arm-
> > kernel@xxxxxxxxxxxxxxxxxxx; mark.rutland@xxxxxxx;
> > brian.starkey@xxxxxxx; olof@xxxxxxxxx; benh@xxxxxxxxxxxxxxxxxxx;
> linux-
> > kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; Linuxarm; linux-
> > pci@xxxxxxxxxxxxxxx; minyard@xxxxxxx; John Garry; xuwei (O)
> > Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
> > devices before scanning
> >
> > On Mon, Jun 19, 2017 at 09:50:49AM +0000, Gabriele Paoloni wrote:
> > > Many thanks for your response and your help here.
> > >
> > > I guess that as conclusion with respect to the current v9 patchset
> we
> > can
> > > disregard the idea of MFD and modify the current v9 so that it
> > doesn't
> > > touch directly ACPI resources.
> > > Instead as I proposed before we can have the scan handler to
> > enumerate
> > > the children devices and translate its addresses filling dev-
> > >resources[] and
> > > at the same time we can modify acpi_default_enumeration to check
> > > acpi_device_enumerated() before continuing with device
> > enumeration...?
> > >
> > > Do you think it as a viable solution?
> >
> > No, I think MFD + scan handler inside the MFD driver is the way to
> go.
> > We don't want to trash ACPI core with stuff that does not belong
> there
> > IMHO.
> 
> Ok Many thanks I will investigate this direction

I had a look into the MFD framework. If my understanding is correct the mfd
framework create a platform device for each declared mfd_cell that is passed
to mfd_add_devices().
However there is something that I do not quite understand:
from
http://elixir.free-electrons.com/linux/latest/source/drivers/mfd/mfd-core.c#L207
it seems that mfd_add_device() will create the platform device using the
resources that are statically declared in the respective mfd_cell.

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()).

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?

Thanks
Gab

> 
> >
> > Also you don't need to modify acpi_default_enumeration() because you
> > can
> > mark your device enumerated in the MFD driver. So all the dirty
> details
> > will be in the MFD driver and not in ACPI core.
> 
> Ok got it :)
> 
> Cheers
> Gab