[..]
> If the hub driver is unbound, then the system won't be able to use the
> hub very well. In particular, connect changes won't be detected. On
> the other hand, devices that were plugged into the hub may still be
> electronically accessible. The cleanest way to handle this is to
> disable all the in-use ports and call usb_disconnect() for their
No, disconnect() must not differentiate between soft and hard unplug.
Just disconnect() the children.
> children. However, it's a little questionable how we can do this.
> Once a driver's disconnect() is called, the driver isn't supposed to
> communicate with the device any more. By a quirk of the
> implementation we don't enforce this restriction for endpoint 0, which
> is all the hub driver needs for disabling all the ports. Relying on
> such quirks generally isn't a good idea, although this could
> reasonably be considered a special case.
If you feel that the hub driver needs to be special cased at all,
then disallow soft disconnect entirely for hubs. That's the cleanest
thing to do.
> Of course, we can't disable the ports if the hub is suspended. I
> think the only way to deal with this complication is to check
> initially whether a device is suspended, and if it is, disallow
> unbinding or configuration changes. That's for all devices, not just
config changes, definitely yes. Unbinding, no.
> hubs. As an additional complication, we _can't_ disallow unbinding
> when a driver is being unloaded. We have to let it unbind from its
> interface -- even though we won't be able to set the interface back to
> altsetting 0 afterwards. (Luckily this part of the problem doesn't
> affect the hub driver; it can't be unloaded unless all the usb_devices
> are already gone.)
Isn't a driver that's not switching to altsetting 0 in its suspend() buggy?
> As a related matter, we also should disallow probing of interfaces on
> suspended devices. This won't be difficult, but it means a
> newly-loaded driver might not be able to bind to all the interfaces it
> should control. I think that's unavoidable.
Yes.
> Now let's discuss error recovery. First, consider what sorts of
> errors might occur. One that the hub driver already checks for is 10
> or more consecutive failures of the status interrupt URB (period is
> 256 ms). Another, highly critical sort of error (not currently
> handled) is failure of a hub to disable a port upon request. Finally,
Retry, reset, power down. If need be, recursively.
Not that it is a high priority.
> although not an error in the hub itself, is the possibility of rapid
> repeated cycling of the connection status of a port -- as might happen
> with a device that fails during initial probing, drops its connection,
> re-establishes it, and repeats...
>
> Errors of the first two sorts are best dealt with by resetting the
> hub. Should the user be given a chance to do something first? And if
> so, what could the user do? Unplugging the hub seems to be the only
> course of action, and that's even more drastic than resetting.
Yes.
> The code that resets hubs for error recovery isn't working now;
> usb_reset_device() won't accept a hub as an argument. The issue, of
> course, is that when the hub is reset so are all its ports. Thus it's
> necessary to call usb_disconect() for all the child devices before
> resetting the hub.
>
> (In principle we could get around this. If there were an addition to the
> API for usb_drivers, a notification function for warning about impending
> resets, then we could simply notify all the children's drivers. But there
> isn't such an API, and it's not likely to arrive during 2.6.)
There is. Suspend() and resume().
[..]
> Then there's always the possibility that the reset will itself fail.
> The only ways this can happen are if the hub is suspended or
> unplugged, or if we can't determine which port it plugs into in the
> parent. That last possibility is a "This can't happen" sort of thing,
> so I will ignore it. Failing to reset a hub that is unplugged is
> understandable, of course. What about failure to reset a suspended
The attempt should not be tried. It should fail.
But hubs can develop malfunctions. Reset can fail.
It can even fail with ENOMEM.
Regards
Oliver
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
