[PATCH v3 1/9] PCI: endpoint: Introduce pci_epc_bar_type BAR_64BIT_UPPER
Manivannan Sadhasivam
mani at kernel.org
Thu Mar 12 04:12:56 AEDT 2026
On Wed, Mar 11, 2026 at 11:38:50AM +0100, Niklas Cassel wrote:
> Hello Mani,
>
> On Wed, Mar 11, 2026 at 12:05:59PM +0530, Manivannan Sadhasivam wrote:
>
> (snip)
>
> > This also brings the question, do we really need to mark the preceding BAR?
>
> From a pure code PoV, marking the preceding BAR is enough even with the
> current code:
> https://github.com/torvalds/linux/blob/v7.0-rc3/drivers/pci/endpoint/pci-epc-core.c#L101-L103
>
> However, the current documentation claims that the succeeding BAR must be
> marked as BAR_RESERVED:
> https://github.com/torvalds/linux/blob/v7.0-rc3/include/linux/pci-epc.h#L207-L210
>
> I want to change this to BAR_64BIT_UPPER / BAR_64BIT_UPPER_BASE, so we can use
> BAR_RESERVED for BARs that expose fixed hardware resources (e.g. eDMA regs).
>
>
> Thus, an EPC driver does not strictly need mark the succeeding BAR with anything.
> This was done mostly for clarity. (E.g. with BAR_64BIT_UPPER_BASE it is obvious
> that this BAR cannot be a standalone 32-bit BAR.)
>
> If we don't mark the succeeding BAR with anything, IMO, it is less obvious that
> the succeeding BAR cannot be used as a standalone 32-bit BAR.
>
> But... since the code already does the "right thing". We could simply nuke this
> part of the documentation, and drop the .type for all BARs succeeding a
> .only_64bit BAR, if you prefer that option over having a dedicated type for the
> "upper base of a 64-bit BAR".
>
Yes, let's just remove that comment.
>
> > Why can't we let the PCI EPC core to always assume that if the previous BAR
> > has 'only_64bit' bit set, next BAR cannot be used as a standalone 32bit BAR?
> >
> > I find it weird or redundant to mark both BARs.
>
> Redundant, yes, but in my opinion marking both BARs makes it unambigious
> that two BARs are used when a BAR is "only_64bit".
>
> E.g. Manikanta originally wanted to add code comments for the upper part of
> the 64-bit BAR:
> https://lore.kernel.org/linux-pci/20260217-master-v1-2-727e26cdfaf5@nvidia.com/
>
> Sure, we can just skip the .type for the succeeding BAR...
> But is that really better than clearly showing that a "forced" 64-bit BAR will
> always occupy two BARs?
>
To whom are we showing? If it is a developer, then he should understand that a
64bit BAR occupies two consecutive 32bit BARs. The flag should only be set for
the code not for the reader.
>
> Tell me what you prefer:
> 1) s/BAR_RESERVED/BAR_64BIT_UPPER_BASE/
> 2) Change documentation and drop .type for a BAR following a .only_64bit BAR.
>
Let's go with 2.
- Mani
--
மணிவண்ணன் சதாசிவம்
More information about the Linuxppc-dev
mailing list