On 31.08.2017 12:17, Mason wrote:
On 30/08/2017 11:37, Mason wrote:
On 30/08/2017 11:07, Ard Biesheuvel wrote:
Please don't forget to mention that this is quirky hardware that
depends on BROKEN because it multiplexes MMIO and config space
accesses in the same memory window without any locking whatsoever
(which would be difficult to do in the first place because we don't
use accessors for MMIO in the kernel).
You're right, it was in the back of my mind, but I didn't state
it explicitly for the benefit of linux-usb readers.
So how likely is it that you are attempting to read from the xhci
BAR window while a config space access is in progress? Any way to
instrument this in your driver?
I logged config space accesses here:
https://www.spinics.net/lists/arm-kernel/msg602832.html
IIRC, the config space accesses are generated by the AER ISR.
So disabling the AER driver should guarantee that no config space
accesses are occurring when the drive is unplugged.
I checked, and I *did* remember correctly.
Disabling the AER driver results in 0 config space access occurring
when the USB3 drive is unplugged. This confirms that the controller's
broken design (muxing config and mem space) is not responsible for
the glitches occurring on unplug events.
Furthermore, I confirm that once the controller has been deemed "dead",
even USB2 drives are no longer detected, and all USB port on the PCIe
board are disabled.
xhci handles both USB3 and USB2, If there is only a xhci in use then all
usb ports will be disabled.
Many systems have both ehci and xhci, where ehci handles USB2 side.
I'm guessing yours only have the xhci.
-Mathias
