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:   Mon, 19 Jun 2017 09:50:49 +0000
From:   Gabriele Paoloni <gabriele.paoloni@...wei.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        "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

Hi Rafael, Mika, Lorenzo

> -----Original Message-----
> From: rjwysocki@...il.com [mailto:rjwysocki@...il.com] On Behalf Of
> Rafael J. Wysocki
> Sent: 16 June 2017 13:23
> To: Mika Westerberg
> Cc: Rafael J. Wysocki; Gabriele Paoloni; Lorenzo Pieralisi; 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 Fri, Jun 16, 2017 at 2:00 PM, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> > On Fri, Jun 16, 2017 at 01:24:32PM +0200, Rafael J. Wysocki wrote:
> >> > 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.
> >
> > Sure but those have I2c/SpiSerialBus() resources which we can use to
> > identify them but for the ipmi thing there is nothing else than _HID
> so
> > we would need to keep a list of such devices in ACPI core.
> 
> OK, so adding a scan handler for that would be the way to go IMO.

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?

Thanks
Gab