Re: [PATCH v4 13/14] usb: force warm reset to break resume livelock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 18, 2014 at 2:40 PM, Julius Werner <jwerner@xxxxxxxxxxxx> wrote:
>> Can you take a look at it, and see if it would address your issue?  I
>> think it will catch the case where we transition from SS.Inactive ->
>> RxDetect -> Polling.
>
> I don't think that's targeting the same problem. Hans seems to be
> describing a situation where the device connects again even though he
> doesn't want it to -- in our case, the device doesn't connect even
> though we want that. His patch shouldn't do anything for our issue
> since he checks for PORT_STAT_CONNECTION, and that bit will be unset
> when the host port is stuck in RxDetect/Polling.

Yes, agreed.

>
>> > It is a valid transitional state, unfortunately, but in a working case
>> > it should resolve itself within a few milliseconds (probably less than
>> > 10). Maybe we should try to differentiate between USB 2.0 and 3.0
>> > devices in hub_port_debounce()? I think due to the built-in link
>> > training in USB 3.0, the classic debouncing doesn't really make sense
>> > anymore (and wastes a lot of time since SuperSpeed links can train
>> > really fast when they work).
>> >
>> > As for this patch, I think the best approach would be to wait for the
>> > device to come back in usb_port_runtime_resume() (through
>> > hub_port_debounce() or something else), and if it doesn't show up
>> > always set the bit to warm reset the port (regardless of LTSSM state,
>> > since even if it says RxDetect I wouldn't be sure that there is really
>> > nothing connected). We could then also use those bits in the "lost
>> > power" case of xhci_resume() to try and work around the problems with
>> > that Synopsys controller.
>>
>> That's a lot of changes to the hub core.  Would an xHCI quirk be
>> simpler?  Is there some scenario I'm missing that the S3 resume quirk
>> wouldn't handle?
>
> We don't need to change hub_port_debounce() right away... that was
> just an additional suggestion to make things more efficient for
> SuperSpeed devices in general. I think for now (in order to solve
> Dan's problem), it would be best if he just calls hub_port_debounce()
> in usb_port_runtime_resume() (which should bring a connected device
> back in the majority of cases), and always queues up a warm reset if
> that fails. (This is essentially what his patch is already doing, just
> get rid of the extra check for USB_SS_PORT_LS_POLLING in the error
> path which I think might be a little too specific and overlook cases
> where the RxDetect/Polling cycle just happens to be at RxDetect in
> that moment.)

That's the plan, and I also want to test a usb device quirk flag to
unconditionally warm reset on power-session loss since it does seem to
be device specifc in my case.
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux