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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170616083313.GY3187@lahna.fi.intel.com>
Date:   Fri, 16 Jun 2017 11:33:13 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Gabriele Paoloni <gabriele.paoloni@...wei.com>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "frowand.list@...il.com" <frowand.list@...il.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "brian.starkey@....com" <brian.starkey@....com>,
        "olof@...om.net" <olof@...om.net>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "minyard@....org" <minyard@....org>,
        John Garry <john.garry@...wei.com>,
        "xuwei (O)" <xuwei5@...ilicon.com>
Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices
 before scanning

On Thu, Jun 15, 2017 at 06:01:02PM +0000, Gabriele Paoloni wrote:
> Hi Mika
> 
> > -----Original Message-----
> > From: linux-pci-owner@...r.kernel.org [mailto:linux-pci-
> > owner@...r.kernel.org] On Behalf Of Mika Westerberg
> > Sent: 13 June 2017 21:04
> > To: Gabriele Paoloni
> > Cc: Lorenzo Pieralisi; rafael@...nel.org; Rafael J. Wysocki;
> > catalin.marinas@....com; will.deacon@....com; robh+dt@...nel.org;
> > frowand.list@...il.com; bhelgaas@...gle.com; arnd@...db.de; linux-arm-
> > kernel@...ts.infradead.org; mark.rutland@....com;
> > brian.starkey@....com; olof@...om.net; benh@...nel.crashing.org; linux-
> > kernel@...r.kernel.org; linux-acpi@...r.kernel.org; Linuxarm; linux-
> > pci@...r.kernel.org; minyard@....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 07:01:38PM +0000, Gabriele Paoloni wrote:
> > > 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?
> > 
> > If you look at Documentation/acpi/enumeration.txt there is a chapter
> > "MFD devices". I think it pretty much maches what you have here. An LPC
> > device (MFD device) and bunch of child devices. The driver for your LPC
> > device can specify _HID for each child device. Those are then mached by
> > the MFD ACPI code to the corresponding ACPI nodes from which platform
> > devices are created including "IPI0001".
> 
> So I guess here in the LPC driver I would have an MFD cell for IPMI. I.e.:
> 
> 	static struct mfd_cell_acpi_match hisi_lpc_ipmi_acpi_match = {
> 		.pnpid = "IPI0001",
> 	};
> 
> correct?

Yes.

> > 
> > It causes acpi_default_enumeration() to be called but it should be fine
> > as we are dealing with platform device anyway.
> 
> I do not quite understand how declaring such MFD cell above would make sure
> that the LPC probe is called before the IPMI device is enumerated...

In fact it may be that it is not sufficient in this case because the
ACPI core might enumerate child devices before the LPC driver even gets
a chance to probe so you would need to add also scan handler to the
child devices and mark them already enumerated or something like that.

> Could you point me to the code that does this?

Check for example drivers/mfd/intel-lpss.c.