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

[Marc Zyngier]

On 2019-12-18 10:22, Andre Przywara wrote:
> On Tue, 17 Dec 2019 21:21:17 -0500
> Jon Masters <jcm@xxxxxxxxxxxxxx> 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@xxxxxxx>
> > >>
> > >> 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...