On Sun, 10 Feb 2002, David Brownell wrote: > > Well, as the comment suggests, according to 9.1.1.5 we have to reset the > > toggles - but only "with endpoints in the affected interfaces". The above > > code however resets the toggles for _all_ endpoints, regardless whether > > they belong to the interface which we have just set or not. > > Good point. Got patch? :)
Will follow - just needs some testing :) > Good point. Right now that code acts as if the caller should expect > toggles to have been reset whenever it succeeds ... which is a NOP > when it's called during initial probe, and might matter otherwise. Right. That's why I prefer usb_set_interface() _not_ to mask the STALL so drivers just know what's going on. > > Hence I tend to suggest not to add any special handling for this 9.4.10 > > optional behavior in usbcore and let the individual drivers handle this. > > A simple improved error test in the driver [... deleted ...] > > would do the job and having this duplicated in several drivers shouldn't > > be worth the trouble, IMHO. > > Plausible, but we'd need updates for some drivers to go with > such a change. And it won't affect (most) calls during probe(). I don't think there would be much to change: the problematic code was just introduced very recently during 2.4.18-pre. Hence it would be pretty suprising should existing drivers really depend on this. Existing drivers are either unaffected by this issue or do already have the required test. In fact only the card reader stuff from Sancho Dauskardt should need it due to the misbehaving hardware. He did already suggest to put the special treatment into usb_reset_device() as this is the only location in usbcore which deliberately calls usb_set_interface() without driver request. > In fact as it stands, I think this area needs some work because the > device probe loop during enumeration isn't actually telling devices > what altsetting to use, if it's anything other than the default after > setting the configuration... 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. 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. 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? Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
