Alan Stern wrote:
So the question is this:  If disabling a port fails, should we reset the
entire hub (and thereby reset all the other devices attached to it), or
should we power down just that one port (which will make it useless until
the entire hub is reset)?

Just power down that one port -- unless it's the only active one on that hub. If you have to give up, and hub indicator LEDs are available on that hub, set that one to blink orange (or whatever).

(BTW:  Blinking the port indicator LEDs will likely need a per-hub
timer callback to queue a control URB changing indicator status.)


Nonexistent is survivable. Endpoints going away while the URB is processed
are another matter.


I see what you mean.  We want to avoid having any URBs in flight while a
configuration change occurs.  The code that David has written for
disabling endpoints might do the job, with no need for any additional
locking.

That _must_ be used whenever the device has a config change event, such as setting an altsetting or configuration -- or resetting.

If we take the simple and "obviously correct" path of disconnecting
all drivers along the reset paths, we can allow reset completion
handlers to re-bind before we kick in the sysfs code that manages
other binding logic.



What do we do about URBs sent to endpoint 0 by a driver during the time that device_reset() is re-establishing the original altsettings? We can't disable endpoint 0.

If we disconnect() drivers up front, then such calls won't happen.




Probe() should have three possible returns.
1. can deal with the device
2. cannot deal with the device
3. can deal in a new form with firmware now in place


I don't like 3 ...

Me either: it's not necessary, and it creates all kinds of strange device states. And as I pointed out, at least the EZ-USB and DFU firmware models can't need that. Is there really a firmware model, used with Linux, that can't be treated as just a re-enumeration? I can't imagine it ever passing the "chapter 9" conformance tests.

IMO, if probe() changes the firmware, the right thing to
do is to fail and require whatever is driving the probe()
to handle the "device is now gone" case.  It needs to do
that anyway, so there's no point in adding a bunch of new
failure modes.

- Dave





-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to