Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu <baolu.lu@linux.intel.com>]

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