[PATCH 1/2] PCI: Add per-device flag to disable native PCIe port services

[PATCH 1/2] PCI: Add per-device flag to disable native PCIe port services

[Han Gao]

Add PCI_DEV_FLAGS_NO_PORT_SERVICES to allow quirks to prevent the PCIe
port service driver from probing specific devices. This provides a
per-device equivalent of the global pcie_ports=compat kernel parameter.

Some platforms have PCIe root ports that break MSI delivery to downstream
devices when native port services (AER, PME, bwctrl, etc.) are active.
The existing pci_host_bridge native_* flags do not cover all services
(notably bwctrl), so a mechanism to skip port driver probing entirely
on a per-device basis is needed.

Cc: stable@vger.kernel.org
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
 drivers/pci/pcie/portdrv.c | 3 +++
 include/linux/pci.h        | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
index 2d6aa488fe7b..3386818d200d 100644
--- a/drivers/pci/pcie/portdrv.c
+++ b/drivers/pci/pcie/portdrv.c
@@ -685,6 +685,9 @@ static const struct dev_pm_ops pcie_portdrv_pm_ops = {
 static int pcie_portdrv_probe(struct pci_dev *dev,
 					const struct pci_device_id *id)
 {
+	if (dev->dev_flags & PCI_DEV_FLAGS_NO_PORT_SERVICES)
+		return -ENODEV;
+
 	int type = pci_pcie_type(dev);
 	int status;
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1c270f1d5123..e038fe14ef78 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -253,6 +253,8 @@ enum pci_dev_flags {
 	 * integrated with the downstream devices and doesn't use real PCI.
 	 */
 	PCI_DEV_FLAGS_PCI_BRIDGE_NO_ALIAS = (__force pci_dev_flags_t) (1 << 14),
+	/* Do not use native PCIe port services (equivalent to pcie_ports=compat) */
+	PCI_DEV_FLAGS_NO_PORT_SERVICES = (__force pci_dev_flags_t) (1 << 15),
 };
 
 enum pci_irq_reroute_variant {
-- 
2.47.3

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

[Han Gao]

SG2042's PCIe root ports [1f1c:2042] fail to deliver MSI interrupts to
downstream devices when native port services are enabled. Devices under
an affected root port receive zero interrupts despite successful vector
allocation, causing driver timeouts (e.g. amdgpu fence fallback timer
expired on all rings).

Set PCI_DEV_FLAGS_NO_PORT_SERVICES on SG2042 root ports to prevent the
port service driver from probing, restoring correct MSI delivery.

Fixes: 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver")
Cc: stable@vger.kernel.org
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
 drivers/pci/quirks.c    | 12 ++++++++++++
 include/linux/pci_ids.h |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 48946cca4be7..bbde482ff7cb 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6380,3 +6380,15 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
 #endif
+
+/*
+ * SG2042's PCIe root ports do not correctly deliver MSI interrupts to
+ * downstream devices when native PCIe port services are enabled. All
+ * services including bwctrl must be disabled, equivalent to pcie_ports=compat.
+ */
+static void quirk_sg2042_no_port_services(struct pci_dev *dev)
+{
+	pci_info(dev, "SG2042: disabling native PCIe port services\n");
+	dev->dev_flags |= PCI_DEV_FLAGS_NO_PORT_SERVICES;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOPHGO, 0x2042, quirk_sg2042_no_port_services);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 406abf629be2..9663be526dd0 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2630,6 +2630,8 @@
 
 #define PCI_VENDOR_ID_CXL		0x1e98
 
+#define PCI_VENDOR_ID_SOPHGO		0x1f1c
+
 #define PCI_VENDOR_ID_TEHUTI		0x1fc9
 #define PCI_DEVICE_ID_TEHUTI_3009	0x3009
 #define PCI_DEVICE_ID_TEHUTI_3010	0x3010
-- 
2.47.3

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

[Manivannan Sadhasivam]

On Wed, Apr 01, 2026 at 01:56:58AM +0800, Han Gao wrote:
> SG2042's PCIe root ports [1f1c:2042] fail to deliver MSI interrupts to
> downstream devices when native port services are enabled. Devices under
> an affected root port receive zero interrupts despite successful vector
> allocation, causing driver timeouts (e.g. amdgpu fence fallback timer
> expired on all rings).
> 

Have you investigated why the endpoint is not able to deliver MSIs to host when
Port services are enabled? Is it because the portdrv driver consumes all MSIs or
MSIs are masked in hw (if so why? due to hardware issue?) or something else?

Currently, the problem description is very vague.

- Mani

> Set PCI_DEV_FLAGS_NO_PORT_SERVICES on SG2042 root ports to prevent the
> port service driver from probing, restoring correct MSI delivery.
> 
> Fixes: 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> ---
>  drivers/pci/quirks.c    | 12 ++++++++++++
>  include/linux/pci_ids.h |  2 ++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 48946cca4be7..bbde482ff7cb 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6380,3 +6380,15 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
>  #endif
> +
> +/*
> + * SG2042's PCIe root ports do not correctly deliver MSI interrupts to
> + * downstream devices when native PCIe port services are enabled. All
> + * services including bwctrl must be disabled, equivalent to pcie_ports=compat.
> + */
> +static void quirk_sg2042_no_port_services(struct pci_dev *dev)
> +{
> +	pci_info(dev, "SG2042: disabling native PCIe port services\n");
> +	dev->dev_flags |= PCI_DEV_FLAGS_NO_PORT_SERVICES;
> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOPHGO, 0x2042, quirk_sg2042_no_port_services);
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 406abf629be2..9663be526dd0 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2630,6 +2630,8 @@
>  
>  #define PCI_VENDOR_ID_CXL		0x1e98
>  
> +#define PCI_VENDOR_ID_SOPHGO		0x1f1c
> +
>  #define PCI_VENDOR_ID_TEHUTI		0x1fc9
>  #define PCI_DEVICE_ID_TEHUTI_3009	0x3009
>  #define PCI_DEVICE_ID_TEHUTI_3010	0x3010
> -- 
> 2.47.3
> 

-- 
மணிவண்ணன் சதாசிவம்

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

[Icenowy Zheng]

在 2026-05-01五的 22:23 +0530，Manivannan Sadhasivam写道：
> On Wed, Apr 01, 2026 at 01:56:58AM +0800, Han Gao wrote:
> > SG2042's PCIe root ports [1f1c:2042] fail to deliver MSI interrupts
> > to
> > downstream devices when native port services are enabled. Devices
> > under
> > an affected root port receive zero interrupts despite successful
> > vector
> > allocation, causing driver timeouts (e.g. amdgpu fence fallback
> > timer
> > expired on all rings).
> > 
> 
> Have you investigated why the endpoint is not able to deliver MSIs to
> host when
> Port services are enabled? Is it because the portdrv driver consumes
> all MSIs or
> MSIs are masked in hw (if so why? due to hardware issue?) or
> something else?

The problem is that the MSI controller has only 16 MSIs usable (it's
wrongly described as 32 previously, a fix to this is pending[1]), and
the failing device have an onboard PCIe switch, which created many PCIe
ports (and corresponding pcieport devices).

With pcieport devices activated, 11 MSIs are requested by the pcieport
drivers -- 3 SoC PCIe ports and 8 switch downstream ports. Then only 5
MSIs are available, but there're still 10 downstream-facing PCIe ports
now (and 5 of them are hardwired to onboard peripherals).

Thanks,
Icenowy

[1]
https://lore.kernel.org/all/20260407160143.1182430-1-zhengxingda@iscas.ac.cn/

> 
> Currently, the problem description is very vague.
> 
> - Mani
> 
> > Set PCI_DEV_FLAGS_NO_PORT_SERVICES on SG2042 root ports to prevent
> > the
> > port service driver from probing, restoring correct MSI delivery.
> > 
> > Fixes: 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> > ---
> >  drivers/pci/quirks.c    | 12 ++++++++++++
> >  include/linux/pci_ids.h |  2 ++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 48946cca4be7..bbde482ff7cb 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -6380,3 +6380,15 @@ static void
> > pci_mask_replay_timer_timeout(struct pci_dev *pdev)
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750,
> > pci_mask_replay_timer_timeout);
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755,
> > pci_mask_replay_timer_timeout);
> >  #endif
> > +
> > +/*
> > + * SG2042's PCIe root ports do not correctly deliver MSI
> > interrupts to
> > + * downstream devices when native PCIe port services are enabled.
> > All
> > + * services including bwctrl must be disabled, equivalent to
> > pcie_ports=compat.
> > + */
> > +static void quirk_sg2042_no_port_services(struct pci_dev *dev)
> > +{
> > +	pci_info(dev, "SG2042: disabling native PCIe port
> > services\n");
> > +	dev->dev_flags |= PCI_DEV_FLAGS_NO_PORT_SERVICES;
> > +}
> > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOPHGO, 0x2042,
> > quirk_sg2042_no_port_services);
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 406abf629be2..9663be526dd0 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2630,6 +2630,8 @@
> >  
> >  #define PCI_VENDOR_ID_CXL		0x1e98
> >  
> > +#define PCI_VENDOR_ID_SOPHGO		0x1f1c
> > +
> >  #define PCI_VENDOR_ID_TEHUTI		0x1fc9
> >  #define PCI_DEVICE_ID_TEHUTI_3009	0x3009
> >  #define PCI_DEVICE_ID_TEHUTI_3010	0x3010
> > -- 
> > 2.47.3
> > 

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

[Lukas Wunner]

On Sat, May 02, 2026 at 09:58:04PM +0800, Icenowy Zheng wrote:
> The problem is that the MSI controller has only 16 MSIs usable (it's
> wrongly described as 32 previously, a fix to this is pending[1]), and
> the failing device have an onboard PCIe switch, which created many PCIe
> ports (and corresponding pcieport devices).

Is the SG2042 only used in that single product?  If it is used in other
products which do not have an on-board PCIe switch, why do you want to
disable MSIs on those other products as well?

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?

> With pcieport devices activated, 11 MSIs are requested by the pcieport
> drivers -- 3 SoC PCIe ports and 8 switch downstream ports. Then only 5
> MSIs are available, but there're still 10 downstream-facing PCIe ports
> now (and 5 of them are hardwired to onboard peripherals).

pcieport can make do with a single MSI vector because all port services
support a shared interrupt.  But I assume your point is that this
particular product has so many PCIe ports that you're still close
to the 16 MSIs limit?

Thanks,

Lukas

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

[Icenowy Zheng]

在 2026-05-02六的 21:47 +0200，Lukas Wunner写道：
> On Sat, May 02, 2026 at 09:58:04PM +0800, Icenowy Zheng wrote:
> > The problem is that the MSI controller has only 16 MSIs usable
> > (it's
> > wrongly described as 32 previously, a fix to this is pending[1]),
> > and
> > the failing device have an onboard PCIe switch, which created many
> > PCIe
> > ports (and corresponding pcieport devices).
> 
> Is the SG2042 only used in that single product?  If it is used in
> other
> products which do not have an on-board PCIe switch, why do you want
> to
> disable MSIs on those other products as well?

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.

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

> 
> > With pcieport devices activated, 11 MSIs are requested by the
> > pcieport
> > drivers -- 3 SoC PCIe ports and 8 switch downstream ports. Then
> > only 5
> > MSIs are available, but there're still 10 downstream-facing PCIe
> > ports
> > now (and 5 of them are hardwired to onboard peripherals).
> 
> pcieport can make do with a single MSI vector because all port
> services
> support a shared interrupt.  But I assume your point is that this
> particular product has so many PCIe ports that you're still close
> to the 16 MSIs limit?

Yes, different services of the same port are now sharing a single MSI
(the 3 native ports have PME, aerdrv, bwctrl sharing the same IRQ while
the only service available for switch downstream ports is bwctrl).
However there're 11 ports (3 native ports + 8 switch downstream ports),
so this still leaves too few room for other cards.

Thanks,
Icenowy

> 
> Thanks,
> 
> Lukas
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Lukas Wunner]

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

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

[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 way or the
other if one of the endpoints consume all MSIs...

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [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

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

[Inochi Amaoto]

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

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

[Manivannan Sadhasivam]

On Thu, May 07, 2026 at 08:41:23AM +0800, Inochi Amaoto wrote:
> 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.
> 

I'm not too sure about quirk. We usually add quirks to workaround the hardware
issues. But what you are seeing is a platform limitation, which is a common
scenario. So adding a cmdline param would help other platforms as well (without
any more code changes).

- Mani

-- 
மணிவண்ணன் சதாசிவம்