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

[Icenowy Zheng]

在 2026-05-06三的 19:09 +0530，Manivannan Sadhasivam写道：
> 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.
> > 
> > > > 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
> > 
> 
> I wouldn't recommend going this far... We do have some switches
> described in DT,
> but they have some resource requirements like regulator, i2c...
> 
> > And then I would try providing an empty "interrupts" property for
> > those switch ports for which you want to avoid port services being
> > instantiated.
> > 
> 
> There is no 'interrupts' property in DT binding for PCI bridge nodes.
> There is
> 'interrupt-map', but that's used for mapping INTx with platform
> interrupt
> controller.
> 
> Moreover, DT should just describe the hardware topology/resource, not
> platform constraints.
> 
> I'd recommend introducing a new cmdline param to the portdrv driver
> to disable
> using MSIs for services. But the platform limitation would hit one

Currently `pcie_ports=compat` command line parameter is used to
workaround the current situation, and this patch is designed to
integrate such workaround into the kernel.

> way or the
> other if one of the endpoints consume all MSIs...

I think one EP claiming multiple MSI (not MSI-X) is an extended
capability of the MSI controller controlled by MSI_FLAG_MULTI_PCI_MSI
flag, which isn't supported for the SG2042 MSI controller driver.

In fact the SG2042 MSI controller isn't originally designed for PCIe
MSIs -- one bit in its doorbell register corresponds to one interrupt.
It's why there's only 16 MSIs available (only one doorbell register is
available and the PCI MSI restricts to 16-bit message data), and also
why multiple PCI MSI isn't supported (multiple PCI MSIs must have
consecutive data values, which isn't possible in such case).

Thanks,
Icenowy

> 
> - Mani