linux-kernel - Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors

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:   Wed, 9 Nov 2016 20:29:23 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Christopher Covington <cov@...eaurora.org>,
        Sinan Kaya <okaya@...eaurora.org>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Will Deacon <will.deacon@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Jayachandran C <jchandra@...adcom.com>,
        Duc Dang <dhdang@....com>,
        Robert Richter <robert.richter@...iumnetworks.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        Liviu Dudau <Liviu.Dudau@....com>,
        David Daney <ddaney@...iumnetworks.com>,
        "wangyijing@...wei.com" <wangyijing@...wei.com>,
        Mark Salter <msalter@...hat.com>, linux-pci@...r.kernel.org,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
        Jon Masters <jcm@...hat.com>,
        Andrea Gallo <andrea.gallo@...aro.org>,
        Jeremy Linton <jeremy.linton@....com>,
        Dongdong Liu <liudongdong3@...wei.com>,
        Gabriele Paoloni <gabriele.paoloni@...wei.com>,
        Jeff Hugo <jhugo@...eaurora.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors

Hi Bjorn,

On 9 November 2016 at 20:06, Bjorn Helgaas <helgaas@...nel.org> wrote:
> On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
>> Hi Bjorn,
>>
[...]
>>
>> We're working to add the PNP0C02 resource to future firmware, but it's
>> not in the current firmware. Are dmesg and /proc/iomem from the
>> current firmware interesting or should we wait for the update to file?
>
> Note that the ECAM space is not the only thing that should be
> described via these PNP0C02 devices.  *All* non-enumerable resources
> should be described by the _CRS method of some ACPI device.  Here's a
> sample from my laptop:
>
>   PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
>   system 00:01: [io  0x1800-0x189f] could not be reserved
>   system 00:01: [io  0x0800-0x087f] has been reserved
>   system 00:01: [io  0x0880-0x08ff] has been reserved
>   system 00:01: [io  0x0900-0x097f] has been reserved
>   system 00:01: [io  0x0980-0x09ff] has been reserved
>   system 00:01: [io  0x0a00-0x0a7f] has been reserved
>   system 00:01: [io  0x0a80-0x0aff] has been reserved
>   system 00:01: [io  0x0b00-0x0b7f] has been reserved
>   system 00:01: [io  0x0b80-0x0bff] has been reserved
>   system 00:01: [io  0x15e0-0x15ef] has been reserved
>   system 00:01: [io  0x1600-0x167f] has been reserved
>   system 00:01: [io  0x1640-0x165f] has been reserved
>   system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
>   system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
>   system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
>   system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
>   system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved
>   system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
>   system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
>   system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved
>   system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
>
> Do you have firmware in the field that may not get updated?  If so,
> I'd like to see the whole solution for that firmware, including the
> MCFG quirk (which tells the PCI core where the ECAM region is) and
> whatever PNP0C02 quirk you figure out to actually reserve the region.
>
> I proposed a PNP0C02 quirk to Duc along these lines of the below.  I
> don't actually know if it's feasible, but it didn't look as bad as I
> expected, so I'd kind of like somebody to try it out.  I think you
> would have to call this via a DMI hook (do you have DMI on arm64?),
> maybe from pnp_init() or similar.
>

We do have SMBIOS/DMI on arm64, but we have been successful so far not
to rely on it for quirks, and we'd very much like to keep it that way.

Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely
there is a better way to wire up the reservation code to the
information exposed by ACPI?

-- 
Ard.

>   struct pnp_protocol pnpquirk_protocol = {
>     .name = "Plug and Play Quirks",
>   };
>
>   void quirk()
>   {
>     struct pnp_dev *dev;
>     struct resource res;
>
>     ret = pnp_register_protocol(&pnpquirk_protocol);
>     if (ret)
>       return;
>
>     dev = pnp_alloc_dev(&pnpquirk_protocol, 0, "PNP0C02");
>     if (!dev)
>       return;
>
>     res.start = XX;          /* ECAM start */
>     res.end = YY;            /* ECAM end */
>     res.flags = IORESOURCE_MEM;
>     pnp_add_resource(dev, &res);
>
>     dev->active = 1;
>     pnp_add_device(dev);
>
>     dev_info(&dev->dev, "fabricated device to reserve ECAM space %pR\n", &res);
>   }
>
> Bjorn