[PATCH 2/2] PCI: Add quirk to disable PCIe port services on Sophgo SG2042
Lukas Wunner
lukas at wunner.de
Sun May 3 01:52:06 PDT 2026
On Sun, May 03, 2026 at 03:10:58PM +0800, Icenowy Zheng wrote:
> It's used in multiple products, but only one of them (EVBv1, which is
> just an early EVB available for a few people including me) lacks an
> onboard switch, because SG2042 is short on on-chip peripherals. All
> other devices (including two mainlined ones, EVBv2 and Milk-V Pioneer,
> and unmainlined dual socket rack servers; Milk-V Pioneer should be the
> most popular device because it was on shelf) have an onboard switch to
> mitigate the lack of on-chip peripherals in SG2042.
Who knows, maybe someone will design a product which doesn't attach
a PCIe switch to the SoC, maybe the lack of peripherals isn't a
problem for them.
It seems reasonable to accommodate such non-switch use cases as well,
so I think you definitely do not want to quirk all products using that
SoC but only those that need it, regardless whether it's the majority.
> > My point is, you want to constrain this to a specific product, not to
> > the SoC. Can you maybe solve this by not specifying interrupts in
> > the devicetree for the PCIe switch?
>
> The PCIe switches are not described in the device tree at all, because
> they're all just discoverable; can we describe them in the DT and
> redirect their interrupts to void?
Yes, somebody did a writeup how to represent switches and endpoints
in the devicetree:
https://farlepet.github.io/linux/2024/02/20/using-linux-device-tree-with-pcie-devices.html
And then I would try providing an empty "interrupts" property for
those switch ports for which you want to avoid port services being
instantiated.
That way you could selectively *enable* port services for specific
ports where it's useful. Let's say you need DPC on a specific port
to contain errors of an attached NVMe drive. Just assign a single
MSI for that port and assign no MSIs for all the others. Much more
flexible than globally disabling port services.
Thanks,
Lukas
More information about the linux-riscv
mailing list