On Thu, Sep 20, 2012 at 10:43 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 20 Sep 2012, Ming Lei wrote:
>
>> It is very common that hub status endpoint has a long 'bInterval',
>> for example, it may be 11(128ms for HS device) or 12(256ms for HS
>> device), so the device connection change may be reported a bit
>> later via status pipe.
>
> In fact, the USB spec requires FS hubs to have bInterval set to 255 and
> HS hubs to have bInterval set to 12.
>
>> So there may have device connection changes happened already on the
>> downstream ports, and no status URB completes when it is killed
>> in hub auto-suspend path, which may miss the connection change event
>> and let hub suspend successfully.
>>
>> This patch introduces check_ports_changed() to check port change event
>> in auto-suspend path, and recover hub state and return -EBUSY if
>> change events are found.
>>
>> The disadvantage is that some delay may be introduced in hub auto-suspend
>> path.
>
> This is not necessary. If a connect change occurred but hadn't been
> reported when the hub was suspended, then the hub will issue a wakeup
> request. The connect change will not get lost.
You mean the wakeup request is remote wakeup? At least, from ehci_irq,
only PCD interrupt handles remote wakeup irq.
But from '7.1.7.7 Resume' part of USB 2.0 spec:
Additionally, the device can signal the system to resume operation
if its remote wakeup capability has been enabled by the USB System
Software
At this time, the remote wakeup capability hasn't been enabled for the hub,
so the wakeup might not be generated.
I have tested the case by adding 'msleep(10000)' after hub_quiesce()
inside hub_suspend(), then plug a new device into the hub during the
time, but current usbcore can't find the connection.
This patch can fix the problem in the above case.
Thanks,
--
Ming Lei
--
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
