2006/1/3, Alan Stern <[EMAIL PROTECTED]>:
> Not quite. The HCD doesn't wait for the device to stop driving the bus;
> it must begin resume signalling within 1 ms of the time it first receives
> the remote wakeup signal. This is described in section 11.5.1.10 of the
> USB 2.0 spec and also in 7.1.7.7.
ok I miss read that part, I thought that the HCD should begin resume
signaling within 1ms of the time the device finish its own resum
signaling.
could we do that in this way: the device send a remote wakeup
request. The HCD get an interrupt and it asks to the core for sending
a clear_port_feature(PORT_SUSPEND) through a new core function. Thus
we could have the same path that deals with remote wakeup and simple
wakeup ?
> >
> > I put in my "resume detect" interrupt handler :
> >
> > if (hcd->state == HC_STATE_SUSPENDED)
> > usb_hcd_resume_root_hub(hcd);
> >
> > Is that correct ?
>
> It's correct if and only if hcd->state behaves properly. Note that
> hcd->state can be set by code outside of your driver, so it's not totally
> reliable.
>
Well if hcd->state does not behave properly that means something is
broken in the core layer, isn't it ?
Thanks,
--
Franck
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
