[PATCH 2/2] PCI: Add quirk to disable PCIe port services on Sophgo SG2042

Inochi Amaoto inochiama at gmail.com
Wed May 6 17:41:23 PDT 2026


On Sun, May 03, 2026 at 10:52:06AM +0200, Lukas Wunner wrote:
> 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.
> 

I think it is possible to quirk all the SG2042 products, because the
typical usage already shows MSI shortage (And this is why SG2044 has
512 MSIs). Although it may left some MSIs in the test case, MSI shortage
is a common issue in a real scenario. And the Sophgo already maintains
a whitelist to limit the MSI usage of most devices in their vendor
kernel. So I think it is fine to quirk all the products that use SG2042.

Regards,
Inochi

> > > 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