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




------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to