On Thu, Feb 12, 2026 at 11:26:59AM +0100, Niklas Cassel wrote: > 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.
Yes, I remember this was discussed in another patch thread. > > 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.) While I think the MSI-X table placement issue is not directly relevant to the eDMA register case (which needs to be addressed in this patch series), they similarly appear to be consequences of SoC-level integration decisions. >From that perspective, I feel that extending pci_epc_bar_desc so it can describe (1) what resides behind a BAR_RESERVED region and (2) whether it must be reused rather than accessed via a new iATU inbound mapping, would be a clearer and more generic, extensible solution than adding a dedicated epc->ops API for each such case. Anyway, I think that the MSI-X Table case should be handled in another patch series. Best regards, Koichiro > > 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
