On Wed, 28 Apr 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > That means changing the code that populates the devices file and changing
> > the code that adds and removes USB device structures. This patch takes
> > care of the first part. I'm delaying the second part because that section
> > of usbcore is still under change -- David Brownell's revisions have not
> > yet been fully integrated.
>
> Could you clarify that slightly ... are you talking about the updates
> for usb_reset_device() patches in my tree, or maybe something else?
> If you like, I can submit those soon; I kind of thought you were going
> to submit those, as well as additions.
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.
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().
> 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.
Here is a related matter. This is something I've mulled over for a few
months but haven't mentioned before: The hub driver needs to have some
way to mark ports as in-use by other threads.
Consider. With the CONFIG_USB_SUSPEND patch, we have the possibility that
a user process might be suspending a port, while simultaneously a driver
is trying to perform a port reset, and meanwhile khubd is trying to handle
a PORT_STAT_C_CONNECTION notification! (Okay, it can't be quite that bad
since usbdev->serialize will prevent some of these things from happening
together.)
A slightly less bizarre example is this. When usb_reset_device() is doing
its port reset, the hub will set the PORT_STAT_C_RESET bit. If the timing
works out, khubd will notice this during its periodic status polling. As
it happens, this isn't such a bad case -- khubd will merely tell the hub
to turn the status bit off -- but it violates the principle that only one
thread should affect a port at a time.
There are ramifications to this. When the hub driver's disconnect()
routine runs, should it wait until all the ports are no longer in use?
What if the hub is suspended? No doubt you can come up with other
questions in addition.
Alan Stern
-------------------------------------------------------
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
