On Wed, Mar 22, 2000, Georg Acher <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 22, 2000 at 01:14:31PM +0000, Matthew Dharm wrote:
> > So, I was sitting here, slamming down large amounts of caffine, and I
> > suddenly realized that my code might be full of race conditions which are
> > caused by the behavior of probes, disconnects, and suspends.
> >
> > So, I think I need to ask some questions of the HCD gurus. Here they are,
> > in no particular order. When answering these, please keep in mind that
> > some people have multiple host controllers, possibly of multiple types.
>
> All probing/connecting/disconnecting is done in the one and only
> khub-thread. HCDs deliver their connect/disconnect-status only via the
> virtual root hub to khub, actually all other HCD stuff has no
> knowledge that a device was disconnected (thus the Stalled/CRC/Timeout
> messages when unplugging a 'hot' device). So all connections changes are
> serialized over all host controllers (if khub does it right, which I
> assume).
This is partially incorrect. When rmmoding one of the HCD drivers,
cleanup_module (actually another function depending on the HCD driver)
will remove the virtual root hub, which then disconnects() all of the
devices.
Of course rmmoding the HCD driver is rare, but still.
Since it's rare, serializing it with khub shouldn't be too bad an idea,
right?
> > (4) What happens during a suspend? Are all devices disconnected and then
> > re-connected? If not, what happens if the system is suspended,
> > devices are added/removed, and then the system resumes?
>
> Good question. Is there a defined behavior all HCDs should have? usb-uhci
> simply stops the HC (switching off the frame sync) and restarts it.
> I haven't tried adding devices during suspend, so I don't know what the HC
> will do..
I suspect that the device will be detected when the system resumes. The
root hub on UHCI is pretty dumb, we have to poll it's status anyway.
There shouldn't be too much of a difference if we poll 50ms (normal
interval) or minutes/hours for a suspend.
> > (5) Once I return from a call to usb_deregister(), can I be _assured_ that
> > my probe and disconnect functions will never be called again?
>
> Not my working area, but I assume that's how it is supposed to work ;-)
Yes, deregister will call the _disconnect function for you for all of
the devices.
> > (6) What happens if, while my probe function is attempting to communicate
> > with a device, the device is removed?
>
> usb-uhci: Stalled/CRC/Timeout (ie. a hard timeout on the USB detected by the
> HC, -ETIMEDOUT/-EILSEQ). You should draw the right conclusions out of that.
Same with my alt uhci driver.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
