I'm starting to get confused by all the applied, partially applied, applied only to usb-gadget, and not-at-all applied patches floating around here.
In _my_ tree, which is a pretty close copy of Greg's gregkh-2.6 development tree, usb_address0_sem is defined at file-level scope in hub.c. The same was true for gadget-2.6 the last I looked. Now, I'm pretty sure that somewhere you had a version in which it was local to hub_port_init(). So that set of changes, if they still exist, hasn't been applied.
Since December, gadget-2.6 has had that particular non-gadget change (address0_sem scope shrank the rest of the way) along with others. Until I added the suspend/resume stuff, last week "hub.c" had only reset changes.
What's the story? Is it true that once the non-{suspend,resume} parts
of hub.c in gadget-2.6 have been merged with Greg's tree then everything will be ready for polishing off usb_reset_device()? If that's so, then I'll go ahead and create a patch to do the merge, then work on usb_reset_device().
Unless I mis-understand you, yes that's true. My question is mostly this: should I submit that basic rewrite of usb_reset_device() myself, or do you want to be the only one submitting such patches starting now? I'd kind of prefer the latter (just to avoid re-testing).
You might not have noticed that the CONFIG_USB_SUSPEND patch (revision upcoming) has also started to follow that new lock hierarchy model.
No, in fact I didn't see any parts of that patch that traversed the device tree.
From hub to child ... dev->serialize protecting usbdev->children[].
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
