From mboxrd@z Thu Jan 1 00:00:00 1970 From: mathias.nyman@linux.intel.com (Mathias Nyman) Date: Thu, 31 Aug 2017 14:38:22 +0300 Subject: Possible regression between 4.9 and 4.13 In-Reply-To: <18588e5d-4f29-d259-329e-533a21ce10ad@free.fr> References: <599D3410.9050504@intel.com> <251c41c0-a4fd-8aae-88e0-5d5928ce45cf@free.fr> <599D62EA.7050100@linux.intel.com> <8ac92197-907a-282b-2165-f50d1b09bd55@free.fr> <61d34811-f17c-6faf-252f-c4c81feb9e89@free.fr> <59A3D6BF.7010400@linux.intel.com> <0b089b17-00fc-5a7c-baa3-e6141029b191@free.fr> <59A56C15.2000403@linux.intel.com> <20170829235310.GA20214@wunner.de> <20170830060237.GA2782@kroah.com> <678490ce-9381-e63e-7a12-33d3eff7f894@free.fr> <18588e5d-4f29-d259-329e-533a21ce10ad@free.fr> Message-ID: <59A7F52E.7000301@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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