Am Freitag, 30. Mai 2003 16:35 schrieb Alan Stern:
> Okay. I don't have answers to everything, but I will try to make the
> questions as explicit as possible.
>
>
> Regarding device resets and error handling:
>
> As discussed earlier, we need a way for a driver to inform the core that a
> device's descriptors have changed (following a firmware download, for
> example). Let's call this new function usb_device_altered(). It will
We need two versions. One that will simply rebind the device and another
that handles errors by resetting, etc... .
> queue a request to be handled in another thread (necessary to prevent
> deadlock). When the request is carried out, it will first do the
Why? The driver could very well be expected to release its locks before
calling this function.
> equivalent of setting config 0: remove the existing interfaces and unbind
> the drivers. I'm undecided about whether it should actually send this
Why all interfaces?
> command to the device; that will most likely be unnecessary. It will then
> release the host-side configuration records and proceed as though this
> was a new device just entering the ADDRESS state. It will re-read the
> device and configuration descriptors from the device, select a
> configuration, and create the sysfs interface devices.
>
> BTW, we will also have to add a DEVICE_ALTERED ioctl to usbfs.
>
> Oliver is concerned about what will happen following a failed device reset
>
> or if the device driver doesn't call usb_device_altered():
> > To a certain extend we need to deal with it. It's core's business if it
> > happens with adr 0 state. And we need to deal with it if the driver gives
> > up. Which means that the core gets the hard irrecoverable errors ;-) And
> > we need a means for the drivers to tell the core about such cases.
>
> Some of the failures of usb_device_reset() are straightforward. If we
> can't tell the port to reset the hub, then we just return an error code.
> If the reset succeeds but there is no device connected afterwards, we can
> just return an error code because khubd will learn about the disconnection
> all by itself in due course. If the device is still connected but we
> can't set its address, we can disable the port and return an error code.
> (If disabling the port fails we must power-down the port, and if that
> fails we must reset the hub. This could get tricky... but it's the same
> processing that must happen for every new connection.)
Why reset after powering down? We should strive to keep ports alive.
Secondly, you are an optimist ;-)
A device may show errors because a hub higher in the tree is heading
for the scrapyard. We need to be prepared to go up the tree in error
handling in emergency.
> If we can set the address back to what it was but can't select the
> original configuration or the original interface settings, things get more
> interesting. My feeling is that we should return an error code and
> proceed with the possibly-incorrect kernel data structures still in place.
> The device driver, if it is working properly, will shortly call
> usb_device_altered() and thereby fix everything up.
Yes, but locking is screwed. While the device is not in sync, probing
must be locked against. We need to export the locking to the drivers.
[..]
> On a different tack... The operation of setting a new configuration will
> need to be handled by a separate thread (separate from the calling device
> driver, I mean), just like usb_device_altered(). Fitting a proper API for
Again, why?
1. A driver for well behaved devices has no business setting configurations
during the normal course of operations.
2. For crappy devices which need it, we can provide a version without locking.
> this may require some effort; I notice that several drivers already call
> usb_set_configuration() synchronously. Some set the config to its
> already-existing value, others blindly set it to 1. This will have to be
> examined closely and in some cases changed. Trying to set a new value
> synchronously will almost certainly result in deadlock. Even trying to
> reset the current value, which normally should be innocuous, might cause
> deadlock if the call failed.
Generally these calls should be eliminated.
> Concerning parallelization of the operations involved in
>
> connect/reset/disconnect processing, David writes:
> > I suspect a per-hub "struct work_struct" would suffice,
> > though it's TBD exactly what work would be done there.
>
> Note that there operations require a separate thread or work-queue
> equivalent, because they have to take place in process context. I can
> think of several other possible arrangements:
>
> (A) One work-queue entry per request, created on demand. This
> would involve creating lots of little kernel processes and would make it
> difficult to handle requests in the correct order.
>
> (B) One persistent kernel thread per bus. This could result in a
> large number of largely dormant threads. On the plus side, this is a
> natural level for handling address-0 serialization.
>
> (C) One single kernel thread to do everything -- i.e., khubd.
> That's what we've got now.
>
> I don't know what's best; maybe something not listed here. Also, bear in
> mind that the work being discussed doesn't crop up too often.
> Parallelization is not needed for performance reasons, only for
> reliability.
I would prefer B but I see no clean way to to do this. This laptop has
3 UHCI and 1 EHCI for two ports. What's a bus here? The idea of
controllers associated with two busses is horrible.
And now for the additional things.
1. Reset currently puts the burden of disconnecting the other interfaces
on the driver. This is wrong. Usbcore should do it with proper locking.
2. Reset should not mean disconnecting the other interfaces. The properties
internal to the drivers of the other interfaces should be retained and restored.
Suspend/resume is the correct model, not disconnect/probe. Kicking off all drivers
but restoring the altsettings like we do is flat out wrong.
3. Usbfs is a security problem and needs filtering of control requests. You can use
it to set a device to an occupied address thereby crashing any device.
Regards
Oliver
-------------------------------------------------------
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
