Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1680466 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO  devices before scanning Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2017-07-03 18:10 +0200
    RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO  devices before scanning Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2017-07-03 18:30 +0200
    Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices  before scanning Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-07-03 22:30 +0200
      RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO  devices before scanning Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2017-07-04 17:20 +0200
        Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices  before scanning Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-07-04 17:50 +0200
          RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO  devices before scanning Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2017-07-04 18:30 +0200

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

Hi Mika

> -----Original Message-----
> From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-
> owner@vger.kernel.org] 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@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> frowand.list@gmail.com; bhelgaas@google.com; arnd@arndb.de; linux-arm-
> kernel@lists.infradead.org; mark.rutland@arm.com;
> brian.starkey@arm.com; olof@lixom.net; benh@kernel.crashing.org; linux-
> kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Linuxarm; linux-
> pci@vger.kernel.org; minyard@acm.org; 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@linux.intel.com]
> > Sent: 19 June 2017 11:02
> > To: Gabriele Paoloni
> > Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> > catalin.marinas@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> > frowand.list@gmail.com; bhelgaas@google.com; arnd@arndb.de; linux-
> arm-
> > kernel@lists.infradead.org; mark.rutland@arm.com;
> > brian.starkey@arm.com; olof@lixom.net; benh@kernel.crashing.org;
> linux-
> > kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Linuxarm; linux-
> > pci@vger.kernel.org; minyard@acm.org; 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

[toc] | [next] | [standalone]

#1680478

+CC Lee Jones

> -----Original Message-----
> From: Gabriele Paoloni
> Sent: 03 July 2017 17:08
> To: Gabriele Paoloni; Mika Westerberg
> Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> catalin.marinas@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> frowand.list@gmail.com; bhelgaas@google.com; arnd@arndb.de; linux-arm-
> kernel@lists.infradead.org; mark.rutland@arm.com;
> brian.starkey@arm.com; olof@lixom.net; benh@kernel.crashing.org; linux-
> kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Linuxarm; linux-
> pci@vger.kernel.org; minyard@acm.org; 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: linux-pci-owner@vger.kernel.org [mailto:linux-pci-
> > owner@vger.kernel.org] 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@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> > frowand.list@gmail.com; bhelgaas@google.com; arnd@arndb.de; linux-
> arm-
> > kernel@lists.infradead.org; mark.rutland@arm.com;
> > brian.starkey@arm.com; olof@lixom.net; benh@kernel.crashing.org;
> linux-
> > kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Linuxarm; linux-
> > pci@vger.kernel.org; minyard@acm.org; 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@linux.intel.com]
> > > Sent: 19 June 2017 11:02
> > > To: Gabriele Paoloni
> > > Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> > > catalin.marinas@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> > > frowand.list@gmail.com; bhelgaas@google.com; arnd@arndb.de; linux-
> > arm-
> > > kernel@lists.infradead.org; mark.rutland@arm.com;
> > > brian.starkey@arm.com; olof@lixom.net; benh@kernel.crashing.org;
> > linux-
> > > kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Linuxarm;
> linux-
> > > pci@vger.kernel.org; minyard@acm.org; 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

[toc] | [prev] | [next] | [standalone]

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

On Mon, Jul 3, 2017 at 7:08 PM, Gabriele Paoloni
<gabriele.paoloni@huawei.com> wrote:

JFYI: Mika on vacation.

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

Right.

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

It's one possibility.

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

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1681040

Hi Andy

[...]

> 
> JFYI: Mika on vacation.

Thanks for letting me know

> 
> > 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().
> 
> Right.
> 
> > 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.
> 
> It's one possibility.
> 
> > 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() ?

Thanks
Gab

> 
> --
> With Best Regards,
> Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jul 4, 2017 at 6:14 PM, Gabriele Paoloni
<gabriele.paoloni@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

[toc] | [prev] | [next] | [standalone]

#1681084

Hi Andy

[...]

> 
> You may do it on stack. Define your cell statically (but not const)
> and apply resources just before mfd_add_devices() call.

Ok thanks got it

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

Uh yes I see now in lpc_ich.c (base address is read from PCI config space
and resources are set accordingly).

Cheers
Gab

> 
> --
> With Best Regards,
> Andy Shevchenko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web