PCI trouble on mvebu (Turris Omnia)

Toke Høiland-Jørgensen toke at redhat.com
Thu Oct 29 19:15:57 EDT 2020


Thomas Petazzoni <thomas.petazzoni at bootlin.com> writes:

> Hello,
>
> On Thu, 29 Oct 2020 14:30:22 -0500
> Bjorn Helgaas <helgaas at kernel.org> wrote:
>
>> We could quirk these NICs to avoid the retrain, but since aardvark and
>> mvebu have no obvious connection and WLE200/WLE900 and MT76 have no
>> obvious connection, I doubt there's a simple hardware defect that
>> explains all these.  
>
> aardvark and mvebu have one very strong connection: they are the only
> two drivers making use of the PCI Bridge emulation logic in
> drivers/pci/pci-bridge-emul.c:
>
> drivers/pci$ git grep pci-bridge-emul
> akefile:obj-$(CONFIG_PCI_BRIDGE_EMUL)  += pci-bridge-emul.o
> controller/pci-aardvark.c:#include "../pci-bridge-emul.h"
> controller/pci-mvebu.c:#include "../pci-bridge-emul.h"
> pci-bridge-emul.c:#include "pci-bridge-emul.h"
>
> I haven't read the whole thread, but it is important to keep in mind
> that on those two platforms, the PCI Bridge seen by Linux is *not* a
> real HW bridge. It is faked by the the pci-bridge-emul code. So if this
> code has defects/bugs in how it emulates a PCI Bridge behavior, you
> might see weird things.

Ohh, that's interesting. Why does it need to emulate it?

And could this cause things weird interactions like what I'm seeing,
where a somewhat buggy device in slot 2 affects the ability to retrain
the link also in slot 1, but only if there's no device in slot 3?

-Toke




More information about the linux-arm-kernel mailing list