On Thu, Feb 12, 2026 at 12:26:49PM +0900, Koichiro Den wrote: > On Wed, Feb 11, 2026 at 05:52:53PM +0100, Niklas Cassel wrote: > > Thanks for the additional context. > Even if we introduce the distinction between BAR_RESERVED and BAR_DISABLED, > as I understand it, we currently lack a way to describe what actually > resides behind a BAR_RESERVED region. > > Perhaps extending pci_epc_bar_desc to describe what a reserved BAR > contains (e.g. DMA register block) might allow us to handle this in a > cleaner and more generic way. It would at least be cleaner than treating it > as a quirk and hard-code the reserved BAR+offset+contents.
Yes, you are absolutely right. Improving struct pci_epc_bar_desc to be able give more information about a BAR_RESERVED BAR would be a next logical step. If we take RK3588 as an example: BAR4 offset 0x0 is eDMA registers. BAR4 offset 0x2000 is ATU registers. BAR4 offset 0x4000 is MSI-X table. BAR4 offset 0x5000 is MSI-X PBA. Many different SoCs have the MSI-X table in one of the BARs. pci-epf-test always puts the MSI-X table in BAR0 (test_reg_bar), after the pci_epf_test_reg registers. On RK3588, this mostly works fine, e.g. the MSI-X test case in the pci_endpoint_test selftest passes with the MSI-X table in BAR0, however, e.g. dw_pcie_ep_raise_msix_irq_doorbell() does not work when the MSI-X table is in BAR0. If I hack the pci-epf-test code to have the MSI-X table in BAR4 (as it is by default), then dw_pcie_ep_raise_msix_irq_doorbell() works fine. This would however require an EPF driver to be able to get an EPC drivers' "desired" MSI-X table and MSI-X PBA location, so that it could call pci_epc_set_msix() with these "desired" locations. I guess we would just need to add a new "get desired MSI-X location" API in epc->ops. However, I have been too busy to work on this, so right now it is only an idea. (Anyone with some spare cycles are free to implement it.) I know for a fact that many other SoCs with the DWC PCIe EP controller have the MSI-X table in one of the BARs by default, so this would also allow them to use dw_pcie_ep_raise_msix_irq_doorbell(). (And would also allow us to no longer force disable these BAR_RESERVED BARs, as the PCI endpoint currently has no way to make use for these BAR_RESERVED BARs.) Kind regards, Niklas
