Am Dienstag, 27. Mai 2003 22:35 schrieb David Brownell:
> Alan Stern wrote:
> > I want to propose a reorganization of the way the USB core handles device
> > resets, configuration changes, connects, and disconnects. The motivation
> > for this is to fix a number of weaknesses in the way device resets and
> > configuration changes are currently being handled. A good deal of
> > functionality is lacking, and adding it will require either duplicating
> > or sharing code with the connect/disconnect pathways.
>
> Yes, there are problems there. I think the changes you're talking
> about can now be done with only usbcore changes: no more changes
> at the HCD level should be needed.
I can't think of any. It looks like a core problem.
> > If something goes wrong during a device reset, the device won't be
> > available under either its old incarnation or its new one. This has to
> > be treated as though a disconnect occurred. Furthermore, it's
> > conceivable that some aspect of the device has changed, so that following
> > the reset it appears to be a different, new device. (I suppose a
> > firmware download might have this effect.) This needs to be treated as a
> > disconnect followed by a connect, i.e., unbind the old drivers and
> > reprobe.
Well, no. Doing a functional reset, as opposed to a purely physical,
which usb_reset_device() does, can mean several steps, like, as
you mentioned, downloading a firmware. The core has not enough
information to tell whether a driver can no longer be bound to its
interface. It cannot tell an error from a legitimate intermediate condition.
IMHO precisely the opposite is needed. During a reset the core must
leave a device entirely alone until a driver tells the core that it's finished
successfully or that there's an irrecoverable error.
The core needs to handle errors only as far as there must not be
a device with adr 0 on the bus and that unplugging during reset
isn't lethal, which can be done via timeouts on the control messages.
What to do on an irrecoverable error is another question.
Reset and config changes are inherently ugly because they are a break
in a model of interfaces by being operations on devices. Firmware
downloading belongs into the same category.
> So sysfs firmware support might need to hook in there too! ... but
> it can't realistically do so until some of the cleanups you mention
> have been achieved.
Hardly doable. You cannot know which firmware to download.
A device may have several.
> > There are also potential problems involving other connect/disconnect
> > processing on the device during a reset. The best way to solve all these
> > difficulties is to arrange for all device resets to be carried out by the
> > khubd thread.
>
> I'm not sure I'd agree with that. I already find khubd too fragile,
> mostly because it's a single point-of-failure and things can easily
> go strange. So I'd rather not create more faults that would wedge
> all of USB, starting with khubd (wedging rmmod, so reboot is needed).
The cat is out of the bag. Usbfs and module load/unload already
take things out of khubd. Solving all that with IPC is unelegant.
We'd be better off with using a big semaphore for each bus.
> Much of what khubd does could reasonably be done in the callback
> for hub status change, or in parallel so state transition bugs
> affecting a given hub port won't lock up all hubs and ports.
Running in task context makes a lot of things much easier.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
