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

Gabriele Paoloni gabriele.paoloni at huawei.com
Tue Jun 13 12:01:38 PDT 2017


Hi Mika

> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg at linux.intel.com]
> Sent: 13 June 2017 16:10
> To: Gabriele Paoloni
> Cc: Lorenzo Pieralisi; rafael at kernel.org; Rafael J. Wysocki;
> catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org;
> frowand.list at gmail.com; bhelgaas at google.com; arnd at arndb.de; linux-arm-
> kernel at lists.infradead.org; mark.rutland at arm.com;
> brian.starkey at arm.com; olof at lixom.net; benh at kernel.crashing.org; linux-
> kernel at vger.kernel.org; linux-acpi at vger.kernel.org; Linuxarm; linux-
> pci at vger.kernel.org; minyard at 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 Tue, Jun 13, 2017 at 02:38:26PM +0000, Gabriele Paoloni wrote:
> > > Is there an example ASL showing how these LPC devices are
> > > currently presented in ACPI?
> >
> > Please find below the asl sketch for our LPC and IPMI
> >
> > //
> > // LPC
> > //
> >
> > Scope(_SB) {
> >   Device (LPC0) {
> >     Name (_HID, "HISI0191")  // HiSi LPC
> >     Name (_CRS, ResourceTemplate () {
> >       Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000)
> >     })
> >   }
> >
> >   Device (LPC0.IPMI) {
> >     Name (_HID, "IPI0001")
> >     Method (_IFT) {
> >       Return (0x03)
> >     }
> >     Name (LORS, ResourceTemplate() {
> >       QWordIO (
> >         ResourceConsumer,
> > 	MinNotFixed,     // _MIF
> > 	MaxNotFixed,     // _MAF
> > 	PosDecode,
> > 	EntireRange,
> > 	0x0,             // _GRA
> > 	0xe4,            // _MIN
> > 	0x3fff,          // _MAX
> > 	0x0,             // _TRA
> > 	0x04,            // _LEN
> > 	, ,
> > 	BTIO
> >       )
> >     })
> >     CreateQWordField (LORS, BTIO._MIN, CMIN)
> >     CreateQWordField (LORS, BTIO._MAX, CMAX)
> >     CreateQWordField (LORS, BTIO._LEN, CLEN)
> >
> >     Method (_PRS, 0) {
> >       Return (LORS)
> >     }
> >
> >     Method (_CRS, 0) {
> >       Return (LORS)
> >     }
> >     Method (_SRS, 1) {
> >       CreateQWordField (Arg0, \_SB.LPC0.IPMI.BTIO._MIN, IMIN)
> >       Store (IMIN, CMIN)
> >       CreateQWordField (Arg0, \_SB.LPC0.IPMI.BTIO._MAX, IMAX)
> >       Store (IMAX, CMAX)
> >     }
> >   }
> > [...]
> > }
> 
> Thanks. So this looks pretty much like normal Linux MFD device which we
> already have support for adding ACPI bindings to child devices. It
> should also support splitting resources to child devices IIRC.

I am not very familiar with Linux MFD however the main issue here is that
1) for IPMI we want to re-use the standard IPMI driver without touching it:
   see 

   static const struct acpi_device_id acpi_ipmi_match[] = {
         { "IPI0001", 0 },
         { },
   };

   in "drivers/char/ipmi/ipmi_si_intf.c" (and in general any standard driver
   of an LPC child)

2) We need a way to guarantee that all LPC children are not enumerated
   by acpi_default_enumeration() (so for example if an ipmi node is an LPC#
   child it should not be enumerated, otherwise it should be)
   Currently acpi_default_enumeration() skips spi/i2c slaves by checking:
   1) if the acpi resource type is a serial bus
   2) if the type of serial bus descriptor is I2C or SPI

   For LPC we cannot leverage on any ACPI property to "recognize" that our
   devices are LPC children; hence before I proposed for acpi_default_enumeration()
   to skip devices that have already been enumerated (by calling 
   acpi_device_enumerated() ).

So in the current scenario, how do you think that MFD can help?
Do you see any possible solution?

Many thanks
Gab
  





More information about the linux-arm-kernel mailing list