Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

[David Brownell]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/