From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Jon Masters <jcm@jonmasters.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
<linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
Andrew Murray <andrew.murray@arm.com>,
Will Deacon <will@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] pcie: Add quirk for the Arm Neoverse N1SDP platform
Date: Wed, 18 Dec 2019 13:53:02 +0000 [thread overview]
Message-ID: <68c0c1e31ce72ab26eab7f1b077a302c@www.loen.fr> (raw)
In-Reply-To: <20191218102203.4078b011@donnerap.cambridge.arm.com>
On 2019-12-18 10:22, Andre Przywara wrote:
> On Tue, 17 Dec 2019 21:21:17 -0500
> Jon Masters <jcm@jonmasters.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@arm.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...
next prev parent reply other threads:[~2019-12-18 13:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 16:06 [PATCH] pcie: Add quirk for the Arm Neoverse N1SDP platform Andre Przywara
2019-12-09 16:26 ` Will Deacon
2019-12-18 2:21 ` Jon Masters
2019-12-18 10:22 ` Andre Przywara
2019-12-18 13:53 ` Marc Zyngier [this message]
2019-12-10 14:41 ` Bjorn Helgaas
2019-12-11 11:00 ` Andre Przywara
2019-12-11 20:17 ` Bjorn Helgaas
2019-12-12 11:05 ` Andre Przywara
2019-12-12 13:44 ` Robin Murphy
2019-12-13 21:07 ` Bjorn Helgaas
2019-12-18 15:07 ` Andre Przywara
2019-12-12 21:07 ` Andrew Murray
2019-12-13 14:39 ` Andre Przywara
2019-12-12 12:37 ` Andrew Murray
2019-12-13 14:23 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68c0c1e31ce72ab26eab7f1b077a302c@www.loen.fr \
--to=maz@kernel.org \
--cc=andre.przywara@arm.com \
--cc=andrew.murray@arm.com \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=jcm@jonmasters.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=rjw@rjwysocki.net \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).