On Friday 30 October 2020 00:15:57 Toke Høiland-Jørgensen wrote: > Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxx> writes: > > > Hello, > > > > On Thu, 29 Oct 2020 14:30:22 -0500 > > Bjorn Helgaas <helgaas@xxxxxxxxxx> 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? I could speculate, they wanted to decrease cost of hw, so they did not include bridge into hw and let user to emulate it (if is needed). > 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? I doubt, slots and registers are independent. Every slot/card has own (emulated) bridge.