Thomas Petazzoni [off-list ref] writes:

Hello,

On Thu, 29 Oct 2020 14:30:22 -0500
Bjorn Helgaas [off-list ref] wrote:

quoted

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel