Hi, On 01/26/2017 12:16 AM, Peter Zijlstra wrote: > On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote: > >>> What is timeout and why? >> Put it in simple: >> >> The driver sets the RUN bit in control register and polls READY >> bit in status register for the successful USB device enumeration. >> As the USB device enumeration might fail and the READY bit will >> never be set, the driver must have a timeout logic to avoid >> endless loop. >> >> More details: >> >> The operational model is that driver sets up all necessary registers >> and data structures, and then starts the debug engine by setting >> the RUN/STOP bit in the control register. >> >> The debug engine then brings up itself as a ready-for-enumeration >> USB device. The USB link between host and device starts link training >> and then host will detect the connected device. The hub driver in >> host will then starts the USB device enumeration processes (as defined >> in USB spec). If everything goes smoothly, the device gets enumerated >> and host can talk with the debug device. >> >> After that, xdbc firmware will set the READY bit in status register. And >> the driver can go ahead with data transfer over USB. > I have vague memories from a prior discussion where you said this READY > state can be lost at any time (cable unplug or whatnot) and at that > point the driver should re-start the setup, right? Yes. So the documentation requires users not to unplug the usb cable during debugging. This rule applies to other debug methods as well. > >>> If there is an error other than !ready, I would >>> expect the hardware to inform you of this through another status bit, >>> no? >> Yeah, this might be another choice of hardware design. But it's not a >> topic for this driver. > So is there really no way to way to distinguish between "I did setup and > am waiting for READY", "I did setup, am waiting for READY, but things > got hosed" and "I was READY, things be hosed" ? > > I suppose the first and last can be distinguished by remembering if you > ever saw READY, but the first and second are the interesting case I > think. > >>> So why can't you poll indefinitely for either ready or error? >>> >> Even if the hardware has both ready and error status bits, it's still >> nice to have a time out watch dog. Buggy hardware or firmware >> might not set any of these bits. Polling indefinitely might result in >> a endless loop. > Loosing output, esp. without indication, is very _very_ annoying when > you're debugging things. Its just about on par with a stuck system, at > least then you know something bad happened. Fair enough. USB connection is stable enough, unless the user unplugs the USB cable during debugging. Best regards, Lu Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
