linux-kernel - Re: [PATCH 2/2] PCI: dwc: Add multi-port controller support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m5ukeugo2lazipljqpubyvm7j3xk2j5o7i2xgdbkkhii57xmyk@lh32qdzjhe4n>
Date: Tue, 6 Jan 2026 10:49:19 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Niklas Cassel <cassel@...nel.org>
Cc: Sumit Kumar <sumit.kumar@....qualcomm.com>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Jingoo Han <jingoohan1@...il.com>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kwilczynski@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>, 
	Alim Akhtar <alim.akhtar@...sung.com>, Richard Zhu <hongxing.zhu@....com>, 
	Lucas Stach <l.stach@...gutronix.de>, Shawn Guo <shawnguo@...nel.org>, 
	Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>, 
	Fabio Estevam <festevam@...il.com>, Yue Wang <yue.wang@...ogic.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Kevin Hilman <khilman@...libre.com>, 
	Jerome Brunet <jbrunet@...libre.com>, Martin Blumenstingl <martin.blumenstingl@...glemail.com>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Greentime Hu <greentime.hu@...ive.com>, 
	Samuel Holland <samuel.holland@...ive.com>, Chuanhua Lei <lchuanhua@...linear.com>, 
	Marek Vasut <marek.vasut+renesas@...il.com>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Magnus Damm <magnus.damm@...il.com>, 
	Pratyush Anand <pratyush.anand@...il.com>, Thierry Reding <thierry.reding@...il.com>, 
	Jonathan Hunter <jonathanh@...dia.com>, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org, imx@...ts.linux.dev, 
	linux-amlogic@...ts.infradead.org, linux-arm-msm@...r.kernel.org, linux-renesas-soc@...r.kernel.org, 
	linux-tegra@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 2/2] PCI: dwc: Add multi-port controller support

On Mon, Jan 05, 2026 at 05:19:38PM +0100, Niklas Cassel wrote:
> On Mon, Jan 05, 2026 at 05:57:55PM +0530, Sumit Kumar wrote:
> > The current DesignWare PCIe RC implementation supports only the controller
> > (Host Bridge) node for specifying the Root Port properties in an assumption
> > that the underlying platform only supports a single root Port per
> > controller instance. This limits support for multi-port controllers where
> > different ports may have different lane configurations and speed limits.
> > 
> > Introduce a separate dw_pcie_port structure to enable multi-port support.
> > Each Root Port can have independent lane count, speed limit through pcie@N
> > child nodes in device tree. Add dw_pcie_parse_root_ports()
> > API to parse these child nodes.
> > 
> > Equalization presets and link width detection currently use common DBI
> > space for all the root ports. Per-port DBI space assignment for these
> > features will be added in future.
> > 
> > Signed-off-by: Sumit Kumar <sumit.kumar@....qualcomm.com>
> 
> Hello Sumit,
> 
> Is there a reason why you represent this as a list of ports rather than a
> simple array?
> 
> The number of ports is known by parsing the device tree, so it should be
> static, no?
> 
> At least to me, this seem similar to e.g. how a gpio_device has multiple
> gpio_descriptors "struct gpio_desc *descs":
> https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib.h#L68C1-L68C26
> 
> A list is usually used for something that is dynamic.
> I don't think that the number of ports to a PCIe controller will be dynamic.
> 
> I can see that struct qcom_pcie in pcie-qcom.c has struct list_head ports,
> but that does not necessarily mean that we need to have a list of ports in
> pcie-designware-host.c. (pcie-qcom could also be modified to have an array
> of ports if there is a desire for similar design pattern.)
> 

Only reason why I went with lists in pcie-qcom is flexibility. There are useful
helpers available for traversing the lists and they seem much more elegant to
use rather than manually traversing the array in C.

But to be frank, I don't really care which one is used as there is going to be
only a handful of ports at max anyway and there is not much overhead.

- Mani

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