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
