Messages in this thread | | | Date | Fri, 12 Dec 2003 10:37:19 -0800 | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1 |
| |
Alan Stern wrote:
> Maybe it will help if I explain how usb_reset_device will work in the > future. > > First of all, as David has said, it does and will grab dev->serialize.
Well, it "does" in my tree, but test11 doesn't (except in the broken DFU path). That's likely a source of some of Duncan's confusion -- my bad, sorry.
> The alternate entry point (...physical...) will require the caller to > hold it already. > > The routine will: > > 1. issue the port reset > 2. make sure the device is still attached > 3. assign it the same address as it had before > 4. read the device and configuration descriptors
I'd split step 4 into "4a" (device descriptors) and "4b" (config descriptors) ... and then re-factor so 1..4a is the same code as normal khubd enumeration. That's what I was looking at a while back. If you like, I'll finish that and forward.
That would also reduce the length of time the address0_sem is held, eliminating a deadlock when a driver probe() from khubd calls "physical" reset_device() after firmware update.
You'll notice that today's "physical reset" codepath doesn't work the same way as the normal "just connected" reset. Up through step (4a) there's no point to that -- it's all just potential bugginess, there's no good reason I can see to have those codepaths do the same thing differently.
> 5. make sure they are equal to the old descriptor values > 6. install the old configuration (if the old state was CONFIGURED) > 7. select the old altsettings for each interface > > ... > > If a problem arises in step 7, I'm not sure what to do. ...
I think that ALL errors in that reset path should be handled the same way: fail the reset, mark the device as gone, hand the device to some task context ... and in that task context, disconnect all the drivers, clean up sysfs, and re-enumerate the device. (Without dropping power to the port; we don't want to need to re-download any firmware.) Maybe there should be exceptiona if the old state wasn't CONFIGURED.
The notion of a device that's "partially reset" sounds like bugs waiting to happen.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |