Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Inochi Amaoto <inochiama@gmail.com>
To: Lukas Wunner <lukas@wunner.de>,  Icenowy Zheng <zhengxingda@iscas.ac.cn>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"Han Gao" <gaohan@iscas.ac.cn>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	"Jonathan Cameron" <jonathan.cameron@huawei.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Kees Cook" <kees@kernel.org>,
	"Chen Wang" <unicorn_wang@outlook.com>,
	linux-pci@vger.kernel.org, sophgo@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	"Han Gao" <rabenda.cn@gmail.com>,
	"Inochi Amaoto" <inochiama@gmail.com>,
	"Vivian Wang" <wangruikang@iscas.ac.cn>, "Yao Zi" <me@ziyao.cc>,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/2] PCI: Add quirk to disable PCIe port services on Sophgo SG2042
Date: Thu, 7 May 2026 08:41:23 +0800	[thread overview]
Message-ID: <afveQQI-CsQ2L1-N@inochi.infowork> (raw)
In-Reply-To: <afcMtlBJYeuxSqZr@wunner.de>

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

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

  parent reply	other threads:[~2026-05-07  0:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 17:56 [PATCH 0/2] PCI: Allow disabling port services on broken root ports Han Gao
2026-03-31 17:56 ` [PATCH 1/2] PCI: Add per-device flag to disable native PCIe port services Han Gao
2026-03-31 17:56 ` [PATCH 2/2] PCI: Add quirk to disable PCIe port services on Sophgo SG2042 Han Gao
2026-05-01 16:53   ` Manivannan Sadhasivam
2026-05-02 13:58     ` Icenowy Zheng
2026-05-02 19:47       ` Lukas Wunner
2026-05-03  7:10         ` Icenowy Zheng
2026-05-03  8:52           ` Lukas Wunner
2026-05-06 13:39             ` Manivannan Sadhasivam
2026-05-06 14:22               ` Icenowy Zheng
2026-05-07  0:41             ` Inochi Amaoto [this message]
2026-05-07  8:52               ` Manivannan Sadhasivam
2026-03-31 18:58 ` [PATCH 0/2] PCI: Allow disabling port services on broken root ports Lukas Wunner
2026-03-31 19:07   ` Han Gao

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=afveQQI-CsQ2L1-N@inochi.infowork \
    --to=inochiama@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=gaohan@iscas.ac.cn \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lukas@wunner.de \
    --cc=mani@kernel.org \
    --cc=me@ziyao.cc \
    --cc=rabenda.cn@gmail.com \
    --cc=sophgo@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=unicorn_wang@outlook.com \
    --cc=wangruikang@iscas.ac.cn \
    --cc=zhengxingda@iscas.ac.cn \
    /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