On Tue, Feb 12, 2002 at 02:11:59PM +0100, Martin Diehl wrote: > > IMHO, if a device comes with multiple AS and the driver wants to use an > AS other than the default one, it is the driver's job to manage the AS. > The driver has all the knowledge to do so - I don't see how the device > probe loop should know, which AS some driver would like to see on probing. > Drivers bind on the level of USB device or interface abstraction, not AS.
Driver bind at the interface abstraction. > I would even go one step further: > I personally don't see any good reason, why usbcore should _ever_ call > usb_set_interface(). Again, managing AS and/or resetting interfaces is > IMHO not something that should be done by the usbcore. With the exception of usb_reset_device() (which you explain below), I do not see the usb core calling usb_set_interface() from anywhere. Am I missing something? > In particular for usb_reset_device() the only reason why usb_set_interface > is called there (immediately after usb_set_configuration() btw.) is > because usb_reset_device() tries to restore the interface-as after the > reset. As indicated by the comment above usb_reset_interface() this leads > to all sorts of trouble for multi-interface devices since it creates > artifical mutual dependencies between interfaces. A sane approach should > leave this up to the driver(s) which are responsible for handling the > interfaces/as. Not to mention my personal expectation of a "reset" > operation is to return the object to a well-defined state, not to cycle > through this and try to restore whatever the state was before the reset. > > So I think the real issue to discuss is whether we could completely drop > the whole SetInterface request from usb_reset_device(). Not only would > this clean up the api - it would also provide a simple way to create > workaround for misfeatured devices like the card readers without breaking > standard conformance for well-behaving ones. > > Anybody knows good reason why we should not do so? No I do not. Work with the mass-storage and other scsi like driver people to change this if you wish. thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
