[PATCH] pci: pci_mvebu: Disable config access to PCI host bridge ports

[Pali Rohár]

Hello Stefan!

On Monday 08 February 2021 15:19:20 Stefan Roese wrote:
> On 08.02.21 15:00, Marek Behun wrote:
> >    I would like to know why this memory controller is there and whether
> >    it should be configured. The pci-mvebu driver in kernel currently
> >    ignores this Memory Controller. That is the reason why your Intel
> >    WiFi card and my ath10k wifi card are not working: U-Boot configures
> >    some addresses in PCIe registers of this Memory Controller, but
> >    kernel does not reconfigure it.
> 
> AFAIR, the U-Boot PCIe host driver configured this "memory controller"
> incorrectly resulting in these problems with the attached PCIe devices
> (WiFi controller). My presumption is, that the "memory controller" is
> the host bridge root port and it's BAR's need to intepreted / configured
> differently.

I'm not sure if this can be a host bridge. Because mvebu has separate
address space for host bridge registers and kernel is creating a virtual
bridge device for accessing host bridge registers.

I think first somebody needs to answer the question what is this device
doing and why kernel has "hacks" which completely hides it from lspci
output.

> The easy solution was to not configure this host bridge at all, as it
> solves these issues (for me and for you) and no further issues are
> introduced. At least not that I know of. If there are issues, we of
> course need to fix them.
> 
> > So all in all:
> > - your patch solves the issue, but I wonder whether it shouldn't be
> >    solved in another way, for example by adding pci,no-autoconfig device
> >    tree property in DTS files in u-boot for these Memory Controllers
> 
> Hmmm. If my findings above are correct, then we should fix this
> incorrect BAR configuration for all boards using this driver globally
> and not introduce a DT property than needs to be added to all boards.
> 
> Perhaps it's possible to correctly interpret the "memory controller"
> and correctly configure it's BARs. Frankly, I was not able to come up
> with such a solution quickly and did choose the solution provided in
> this patch instead.
> 
> > - I wonder whether kernel should stop ignoring this device and
> >    configure it somehow
> 
> Why should the kernel do this? Is some functionality missing from your
> point of view?

Kernel is not only ignoring this device, but it also hides it from PCI
bus. It is not visible in lspci output. And I do not think that kernel
should hide devices. AFAIK lspci show all devices present on bus, even
those which do not have loaded kernel driver...

> 
> Thanks,
> Stefan