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

[Stefan Roese]

Hi Marek,

On 08.02.21 15:00, Marek Behun wrote:
> On Mon, 25 Jan 2021 15:25:31 +0100
> Stefan Roese <sr at denx.de> wrote:
> 
>> This patch changes the PCI config routines in the Armada XP / 38x driver
>> to not allow access to the PCIe root ports.
>>
>> While updating the Armada XP based theadorable to the latest mainline
>> and testing it with the DM PCI driver I noticed, that the PCI root
>> bridge was being configured incorrectly. Resulting in the PCIe Intel
>> WiFi was not working correctly in Linux. With this patch applied, all
>> PCIe devices work without any issues in Linux again.
>>
> 
> Hi Stefan,
> 
> I overlooked this patch and coincidentally also discovered this bug
> last week. Your patches solves this issue,

Good...

> but
> 
> - previously, when pci-mvebu did not use DM, it was solved differently:
>    pci_skip_dev returned 1 for (b,d,f) = (*,0,0).
> - on this address (*,0,0) there seems to be a Memory Controller -
>    without applying your patch the pci command lists
> 
>      => pci
>      Scanning PCI devices on bus 0
>      BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
>      _____________________________________________________________
>      00.00.00   0x11ab     0x6820     Memory controller       0x80
>      00.01.00   0x168c     0x003c     Network controller      0x80
> 
>    with your patch
> 
>      => pci
>      Scanning PCI devices on bus 0
>      BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
>      _____________________________________________________________
>      00.01.00   0x168c     0x003c     Network controller      0x80

Yes.

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

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?

Thanks,
Stefan