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

On 2019-12-18 10:22, Andre Przywara wrote:
> 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.

In all honesty, I really wonder why we are even having this discussion:

- The HW is unavailable to the mere mortal. And even most superheroes
   cannot get their hands on it

- Even with this terrible son of a hack, essential PCIe features cannot
   work (and yes, I do consider SR-IOV as an essential feature)

- If we take this hack and somehow get this thing to run with mainline,
   we will never be able to say "no" to this kind of unfinished,
   *prototype* implementations ever again

To sum it up: a hack that doesn't really work for a prototype that you
can't really buy? Why should we even care?

         M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists