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