Possible regression between 4.9 and 4.13

[mathias.nyman@linux.intel.com (Mathias Nyman)]

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