Messages in this thread | | | Date | Fri, 12 Dec 2003 14:17:04 -0500 (EST) | From | Alan Stern <> | Subject | Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |