On Tue, 8 Jun 2004, Marcel Holtmann wrote: > as I know this firmware loading model doesn't need a reset after > changing its configuration.
If the new firmware uses _exactly_ the same device and configuration descriptors as the original ones, then you probably don't need a reset. Otherwise you do. > > > If I add the following two lines after the control message > > > > > > udev->toggle[0] = udev->toggle[1] = 0; > > > udev->halted[0] = udev->halted[1] = 0; > > > > > > everything is working as before. > > > > I wouldn't rely on it for a minute. Thing is, there's state inside > > usbcore that only gets properly adjusted by usb_set_configuration(). > > It's not limited to endpoint halt and toggle status, there's also > > driver model state. Even if you happen to fall into a special case > > that doesn't involve oopsing (for now), why risk it? > > Me neither and this is why I am asking here. I don't see any need of a > re-enumeration. I will ask the company how they think there firmware > loading mechanism should work and what USB specific operation they > expected. > > > Is there some problem calling usb_set_configuration() from keventd > > as I suggested? > > It will make the driver more complex and I don't think it is needed. It might be enough to call usb_reset_configuration(), which _is_ allowed from within probe(). However, if you really do want to load a different configuration then you have no choice but to use something like the schedule_work() approach or else have a hotplug script do it for you. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
