Am Dienstag, 21. Januar 2003 21:19 schrieb Alan Stern:
> On Mon, 20 Jan 2003, David Brownell wrote:
> > Oliver Neukum wrote:
> > > So here's the list of things related to the core I remember so we can
> > > look at the issues and see which need attention before 2.6.0
> > >
> > > - reseting during probe will deadlock
> > > - reseting through usbfs will not reprobe
> > > - usb_reset_device() and usb_set_configuration() race with probe()
> > > - bandwidth checking is broken
> > >
> > > Removals? Additions? Comments?
>
> What is the cause of all these problems relating to device resetting and
> probing?
Several things:
- reseting during probe will deadlock: known problem, deadlock on a semaphore
during address setting. Johannes is aware of the issue.
- reseting through usbfs will not reprobe: cause unknown
- usb_reset_device() and usb_set_configuration() race with probe():
known problem, my safe configuration patch is supposed to address the issue
> Does reset sometimes result in a probe and other times not? Under what
> circumstances should this happen?
Reset through usbfs?
I've never observed a reprobe, which should happen in all cases.
It's a sure way to kill my mouse :-(
> What is the proper conceptual model for a reset? Should it appear to the
> core essentially the same as a disconnect swiftly followed by an attach?
No. At least not for the driver doing it. Currently all responsiblity
to handle this is left with the driver. IMHO the core has to make sure
that no probing() on the device happens while a reset is running.
The patch I sent is supposed to fix that.
> When a driver bound to one interface decides to reset the device, how
> should drivers bound to other interfaces be notified? Is calling their
> disconnect() and then probe() routines sufficient? Right now, this is
Yes.
> relegated to the driver that does the reset; shouldn't it be centralized
> in the core?
Probably. Feel free to provide the code ;-)
> On a slightly different but related note, who gets to decide which
> configuration a device should use?
IMHO user space in the general case.
There might be vendor specific devices which require the configuration
to be changed during normal operation.
But as you cannot give a general rule for selecting a configuration
I see no choice but to leave it to policy to be decided by hotplugging
scripts.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
