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.
Certainly.
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.
Yes. Likewise there's a problem in the current driver probe logic ... drivers expect it's their responsibility to choose altsettings, but there's now code that sets the host-side record to every legal value (not the device!).
I'd rather seee it formal: drivers own altsettings, usbcore leaves them alone except for when drivers change them. That'd apply for probes during reset() too, not just first-enumeration.
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.
The issue is a general one with control requests. SET_ADDRESS is an interesting example, where pre-filtering ought to reject requests.
But there are similar issues for SET_CONFIGURATION and SET_INTERFACE, both of which affect usbcore deeply enough to oops drivers that don't use the "approved" API calls.
- 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
