From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 29 Aug 2014 11:27:17 +0200 Subject: [U-Boot] [PATCH] usb: hub: don't check CONNECTION in hub_port_reset() In-Reply-To: <1407452879-4875-1-git-send-email-swarren@wwwdotorg.org> References: <1407452879-4875-1-git-send-email-swarren@wwwdotorg.org> Message-ID: <201408291127.17891.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Friday, August 08, 2014 at 01:07:59 AM, Stephen Warren wrote: > From: Stephen Warren > > One specific USB 3.0 device behaves strangely when reset by > usb_new_device()'s call to hub_port_reset(). For some reason, the device > appears to briefly drop off the bus when this second bus reset is > executed, yet if we retry this loop, it'll eventually come back after > another two resets. > > If USB bus reset is executed over and over within usb_new_device()'s call > to hub_port_reset(), I see the following sequence of results, which > repeats as long as you want: > > 1) STAT_C_CONNECTION = 1 STAT_CONNECTION = 0 USB_PORT_STAT_ENABLE 0 > 2) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 > 3) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 > > The device in question is a SanDisk Ultra USB 3.0 16GB memory stick with > USB VID/PID 0x0781/0x5581. > > In order to allow this device to work with U-Boot, ignore the > {C_,}CONNECTION bits in the status/change registers, and only use the > ENABLE bit to determine if the reset was successful. > > To be honest, extensive investigation has failed to determine why this > problem occurs. I'd love to know! I don't know if it's caused by: > * A HW bug in the device > * A HW bug in the Tegra USB controller > * A SW bug in the U-Boot Tegra USB driver > * A SW bug in the U-Boot USB core > > This issue only occurs when the device's USB3 pins are attached to the > host; if only the USB2 pins are connected the issue does not occur. The > USB3 controller on Tegra is in reset, so is not actively communicating > with the device at all - a USB3 analyzer confirms this. Slightly > unplugging the device (so the USB3 pins don't contact) or using a USB2 > cable or hub as an intermediary avoids the problem. For some reason, > the Linux kernel (either on the same Tegra board, or on an x86 host) > has no issue with the device, and I observe no disconnections during > reset. > > This change won't affect any USB device that already works, since such > devices could not currently be triggering the error return this patch > removes, or they wouldn't be working currently. > > However, this patch is quite reliable in practice, hence I hope it's > acceptable to solve the problem. > > The only potential fallout I can see from this patch is: > > * A broken device that triggers C_CONNECTION/!CONNECTION now causes the > loop in hub_port_reset() to run multiple times. If it never succeeds, > this will cause "usb start" to take roughly 1s extra to execute. > > * If the user unplugs a device while hub_port_reset() is executing, and > very quickly swaps in a new device, hub_port_reset() might succeed on > the new device. This would mean that any information cached about the > original device (from the descriptor read in usb_new_device(), which > simply caches the max packet size) might be invalid, which would cause > problems talking to the new device. However, without this change, the > new device wouldn't work anyway, so this is probably not much of a > loss. > > Signed-off-by: Stephen Warren > --- I'll apply this and see if we get any breakage. I don't expect any though.