> Ah, but re-submission of an interrupt URB from within the completion
> handler will run in interrupt context.
That we'll have to deal with later.
> This could also be entirely solved by making the requirements that:
> (1) The core or HCD will unlink all URBs for a removed device when
> it's removed
To do so you need to add the urb to a per device list, which has to be
locked. The problems arise if you loose the race. Where do you put the
lock ?
> (2) The mid- and high-level drivers will not submit any more URBs
> to the removed device once the disconnect() routine has ended.
You need to block usb_submit_urb() for disconnected devices.
To know whether a device has been unplugged, you need to scan all
connected devices. This sucks.
> If you think about it, some of this is needed anyway. After all, there
> will always be the fundamental race of the cable being pulled, and URB
> being submitted, and then the disconnect function getting called. We could
That's not a problem. On that level a disconnected device is just a source
of continuous io errors.
> require the disconnect to unlink the URBs, but since the core/HCDs have to
> be able to accept (at least for a small window) URBs for a removed device,
> why not put the logic all in one place?
Because it's a twofold problem. The device going away and the device
descriptor going away. The latter is the hard part.
> After all, it used to work this way....
How so? When?
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
