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

[Alan Stern]

On Fri, 12 Dec 2003, David Brownell wrote:

> Alan Stern wrote:
> 
> > 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.

Sure.  Although depending how you do it, step 3 might be different (reuse 
the old address vs. assign a new address).  Also the failure paths will be 
different.  But that could all be handled with proper refactoring.

I intended to share common code as much as possible.  Since you've already 
got part of that (almost) written, I'll be happy to use your work.

> That would also reduce the length of time the address0_sem
> is held,

It would?  How so?

>  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.

Agreed.


> 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.

Your choice makes error handling easier.  And failure to restore an 
altsetting is a pathological case anyhow, so it's not worth worrying 
about.

Alan Stern

-
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/