Re: [PATCH v2] PCI: dwc: rcar-gen4-ep: Mark BAR0 and BAR2 as Resizable BARs

[Niklas Cassel <cassel@kernel.org>]

On Wed, Mar 04, 2026 at 08:04:52PM +0530, Manivannan Sadhasivam wrote:
> > 
> > So this is not something unique to BAR type/sizing scheme, the same arguments,
> > for/against, also applies for msi_capable/msix_capable.
> > 
> > Manivannan, would it be possible to automatically initialize msi/msix_capable
> > on Qcom once a reference is provided, or would this be too late?
> > 
> 
> Yes, with a valid reference clock, it should be possible to read the
> capabilities and detect these. But there is no way we can make sure that the
> reference clock is always be present. Maybe we can do it using a devicetree
> property that you tried upstreaming some time before:
> https://lore.kernel.org/linux-pci/20250425092012.95418-2-cassel@kernel.org

I was thinking something more like, e.g. dw_pcie_ep_init_registers() calling:
1) A function that hides broken features.

2) A function that allocates and initializes features in epc_features.
   E.g. msi_capable = true, msix_capable = true, barX = resizable,
   based on the information it can parse from the capabilities list.

The allocation done in 2) could be dynamically allocated memory, so the
information could be kept even if the reference clock is lost at a later
time.

At least during dw_pcie_ep_init_registers(), I would assume that there is
a reference clock, even when using Common Clock, e.g. as default on Qcom.

Anyway, while I kind of like this idea, it would be a significant change
from the current design.

E.g. pci-epf-test makes use of epc_features already in .bind().
I don't know exactly how e.g. Qcom works, do we know that we will have
a reference clock in .bind() ?  If I remember correctly, we only know that
we have a reference clock in .epc_init(). So this change would also need
to modify all existing EPF drivers to not make use of epc_features in
.bind(), and only make use of epc_features first after .epc_init().

So it sounds like quite a big change. Probably a design we would want if
we designed the PCI endpoint framework today, but doubt it will happen now.


Kind regards,
Niklas