No subject

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".


> 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?


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.

And I will respin with that.


Kind regards,
Niklas