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]

Date:   Fri, 16 Jun 2017 13:24:32 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Gabriele Paoloni <gabriele.paoloni@...wei.com>,
        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 Fri, Jun 16, 2017 at 10:33 AM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
> 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.

Or extend the special I2C/SPI handling to them.

Thanks,
Rafael