linux-kernel - Re: [PATCH] pcie: Add quirk for the Arm Neoverse N1SDP platform

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, 18 Dec 2019 10:22:03 +0000
From:   Andre Przywara <andre.przywara@....com>
To:     Jon Masters <jcm@...masters.org>
Cc:     Will Deacon <will@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Andrew Murray <andrew.murray@....com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH] pcie: Add quirk for the Arm Neoverse N1SDP platform

On Tue, 17 Dec 2019 21:21:17 -0500
Jon Masters <jcm@...masters.org> wrote:

Hi Jon,

> On 12/9/19 11:26 AM, Will Deacon wrote:
> > On Mon, Dec 09, 2019 at 04:06:38PM +0000, Andre Przywara wrote:  
> >> From: Deepak Pandey <Deepak.Pandey@....com>
> >>
> >> The Arm N1SDP SoC suffers from some PCIe integration issues, most
> >> prominently config space accesses to not existing BDFs being answered
> >> with a bus abort, resulting in an SError.  
> > 
> > "Do as I say, not as I do"?  
> 
> In my former role I asked nicely that these patches not be posted 
> upstream, but I see that they ended up being posted anyway. Hacking up 
> upstream Linux to cover for the fact that a (reference) platform is 
> non-standard is not only not good form but it actively harms the community.

Please keep in mind that this platform was designed to be standards compliant, it is just due to an integration problem that this is not the case with this silicon. So we end up with the usual hardware errata, which the kernel can fix up. I agree it's not nice, and I also want it fixed in hardware, but I guess that's the usual software guy's pipe dream.

> You'll have people consume this platform and not realize that it's 
> broken, IP won't get fixed, and generally it'll be a mess.

I don't see how yet another ACPI quirk in the ACPI quirk framework(!) will make a mess.
Actually the rest of the system is standards compliant (it even uses ACPI from the very beginning ;-), so it's just this problem that prevents us from using the system in the proper, standards compliant way. Effectively we are back to the embedded times with compiling your own kernel and somehow getting a root filesystem on the hard drive.
If there would be mainline kernel support, all of this would go away and would could use standard distro installers (given they backport the patch).

> Yes, it's 
> unfortunate, but so was taping out that platform without working PCI. We 
> all know what should have happened, and what the right move ahead is.

That may come as a surprise to some, but Arm Ltd. is actually not really in the business of *producing silicon*, so a respin of the chip was and is not an option. I too wish it would be different, but that's how it is.

Cheers,
Andre.