[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXCb8MFYKs43XVPH@ryzen>
Date: Wed, 21 Jan 2026 10:27:12 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Aksh Garg <a-garg7@...com>
Cc: linux-pci@...r.kernel.org, jingoohan1@...il.com, mani@...nel.org,
lpieralisi@...nel.org, kwilczynski@...nel.org, robh@...nel.org,
bhelgaas@...gle.com, linux-kernel@...r.kernel.org,
s-vadapalli@...com, danishanwar@...com
Subject: Re: [PATCH 0/2] PCI: dwc: ep: Enhance multi-function endpoint support
On Wed, Jan 21, 2026 at 09:50:58AM +0100, Niklas Cassel wrote:
> On Wed, Jan 21, 2026 at 11:12:12AM +0530, Aksh Garg wrote:
> > This series addresses multi-function endpoint configuration issues in
> > the DWC PCIe controller driver. The changes enable proper operations
> > for physical functions and enhance the multi-function endpoint support.
>
>
> Considering that the DWC driver design has always been broken with regards
> to multiple physical functions, as you explain yourself, the iATU to BAR
> mapping has always been per controller, not per PF.
>
> Thus, it would be nice if you explained how you have actually tested this.
>
> Does the controller you are using have both Resizable and Programmable BARs?
If your PCIe controller supports multiple PFs, as you might know,
while:
const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
u8 func_no, u8 vfunc_no);
takes both a PF and a VF...
dw_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
ignores both of these parameters and simply call:
ep->ops->get_features(ep);
For each PF in your controller, do all BARs have the exact same definition?
e.g. all BARs for each PF would need to have the same type, e.g. if BAR0
is FIXED, BAR1 is programmable, and BAR2 is resizable, with the current
design of dw_pcie_ep_get_features() that would need to be the case for all
PFs.
Kind regards,
Niklas
Powered by blists - more mailing lists