On Mon, 11 Feb 2002, Sancho Dauskardt wrote: > > Since the SetInterface request basically implies a reset of the affected > > endpoints it might be required nevertheless. IMHO the request should (at > > least) be sent to the device to give it a chance to act as intended. > > That a point, BUT what if your device doesn't stall ? > Doing this, you'll break (bossibly all) OnSpec-based Card readers (you'll > find chips in ACOMdATA, DataFab, Imation, ... products). > (code path: storage reset -> usb_reset_device() ..)
Ok, wasn't aware such broken guys are out there. > I know this is really a device bug, but a usual, I it works under Win it ...... > And as far as I colud see, WinXX won't do a set iface.. > Sending the 90c36 a SET_INTERFACE totally kills it; only loss of power will > get it back to life. You mean, something like the device's firmware crashed? - i.e. it's not simply the device appears to hang because we lost toggle synchronisation during the SetInterface? Hopefully these devices are sold with the (TM)ed USB-logo so USB-IF could go after them... =:) Anyway, I agree we should try to make even such broken devices working. But breaking things for well-behaving devices in order to provide a workaround for broken ones wouldn't be the way to go, IMHO. > set_interface will never be called from the core, except for a > usb_reset_device(), right ? Right. AFAICS there are only two occasions calling usb_set_interface outside individual drivers: usb_reset_device() and the usbdevfs-wrapper for the SetInterface-request. > Notably: set_interface won't be called automatically during a normal > plug-in sequence, right ? Yes - unless the normal plug-in sequence would call usb_reset_device() (haven't checked). Anyway, I do believe the real solution is to fix usb_reset_device()! > How about my original proposal, checking iface->num_altsetting!=1 there, > and only calling set_interface then ? > Then, in case a drivers knows what it's doing, it can still go ahead.. I do completely agree here. At least for a short term solution. Finally I think the right thing to do is not only the artifical num_altsetting=1 special casing. As explained in the reply to David I'd suggest to remove the usb_set_interface() call unconditionally there. Its either a NOP (if used to set default AS - there is an SetConfiguration request in front of it already doing this) or bogus (if used to restore non-default AS - other drivers which are bound to other interface on same devices don't know what's going on). So I like your suggestion as immediate fix. Next thing would be some idea whether there are drivers actually depending on the current way how usb_reset_device() behaves. If so, they should probably be fixed before we can drop the SetInterface completely. Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
