On Tue, Jun 13, 2000, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 13, 2000 at 06:37:46PM -0700, Johannes Erdfelt wrote:
> > After talking to Matthew Dharm, Randy Dunlap and a couple of other people
> > it became apparent that we probably want different semantics for
> > usb_reset_device to make it more useful.
>
> I was just talking to someone else about this too, great timing, thanks.
>
> > This patch resets the device, then it programs the address, programs the
> > active configuration previously set and then sets the alternate setting
> > for all of the interfaces.
>
> What happens if the configuration changes after the device is reset?
> Firmware download could cause this to happen.
Hmm, problem. I'll reload the configuration from the device. If it has
changed, it will not go through the rest of the process of programming
the active configuration, etc. It will only program the device id.
The calling driver is then responsible for doing the right thing.
> I guess it is up to the driver to change the configuration back to a
> different one if it want to after the reset?
I guess that could be done, but could cause some problems with out of spec
devices which don't like setting the configuration multiple times.
> > The calling driver still retains control of the device and it does not
> > simulate a disconnect() and then probe() call on the device.
> >
> > I've also added an address 0 semaphore. If we reset a device while a new
> > device was plugged in, we can have 2 devices on address 0 which will
> > most likely cause problems.
> >
> > I've also added an ioctl() call to reset the device through usbdevfs.
>
> If usbdevfs calls the ioctl, then the disconnect and probe will not
> happen for the driver that is currently connected to this device,
> correct? That isn't a good thing, is it?
I'll make the ioctl() simulate disconnect() and probe() for all interfaces
the calling process doesn't have claimed. Sound good?
> > WARNING - If a driver calls usb_reset_device, you should simulate a
> > disconnect() and probe() for other interfaces you doesn't claim. This
> > is left up to the driver writer right now. This insures other drivers
> > have a chance to re-setup their interface.
> >
> > If you wish to still have the old semantics. Make a call to usb_disconnect
> > and then usb_connect (to get a new address) and then usb_new_device.
>
> You might want to put the above two paragraphs in the code as comments,
> as I know people will need to know this in the future.
Good point. Will do.
> I like this patch. Thanks for beating me to it :)
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
