Alan Stern wrote:
You're saying that usb_reset_device() doesn't really need to lock the hub?
Doesn't this contradict what you wrote earlier:
If various things changed, it wouldn't need to. And the
last suspend patch I posted did actually change one of them:
to use the top-down (from the root)
I'm only going to respond to a few points here, because this discussion is
getting a little out of hand...
On Wed, 5 May 2004, David Brownell wrote:
> > The big question is how to make device resets work. It's pretty clear
> > that usb_reset_device(udev) needs to lock both the parent hub and u
Alan Stern wrote:
...
One or the other task will lock the hub first. Simple case: khubd
wins, driver's top-down lock acquisition will first block (because it
can't get past khubd) and then later fail (the device is gone, though
that task has an old device pointer that it's still got to release).
And I would find it acceptable
to use hubdev->serialize to protect the links at the inner nodes if only I
could see how to also get usb_reset_device() working reliably. And
useable from within probe().
I think usb_reset_device(dev) would just need to call locktree(dev),
then fail cleanly on -
Talking about simultaneous disconnect and device reset:
On Mon, 3 May 2004, David Brownell wrote:
> That's not _my_ analysis ... :)
>
> One or the other task will lock the hub first. Simple case: khubd
> wins, driver's top-down lock acquisition will first block (because it
> can't get past khu
Let's see if we can't clear away some of the issues.
On Mon, 3 May 2004, David Brownell wrote:
> Alan Stern wrote:
> >
> > I'm talking about protecting the physical topology of the entire tree.
>
> I still don't see why the _entire_ tree needs that sort
> of protection. I hope I'm not missing
On Mon, 3 May 2004, David Brownell wrote:
> You just said you wanted a "topology lock", but there are multiple
> topologies. A lock that protects the logical topology of a given
> non-hub device (SET_CONFIGURATION) doesn't need to protect any other
> device. And a lock that protects the physical
On Mon, 3 May 2004, David Brownell wrote:
> >>Just define usb_reset_device() so the calling task may not hold
> >>the dev->serialize lock, and have its first act be to get the
> >>lock for the hub. That would imply that probe() paths would
> >>(still) not be able to call it directly though. Mayb
Alan Stern wrote:
I'm talking about protecting the physical topology of the entire tree.
I still don't see why the _entire_ tree needs that sort
of protection. I hope I'm not missing something.
And I would find it acceptable
to use hubdev->serialize to protect the links at the inner nodes if on
Alan Stern wrote:
On Mon, 3 May 2004, David Brownell wrote:
If all the locking obeys the same (correct, and presumably top-down)
locking protocol, then deadlocks won't happen. That'd include the
code doing the reset ... which would see -ENODEV faults starting at
some point, and then fail cleanly.
Alan Stern wrote:
On Sun, 2 May 2004, David Brownell wrote:
I think the notion of device-to-parent reset locking is the problem.
What if the device gets unplugged while you try to reset it, or
it was already reset and that's why it failed, making the driver
try to reset it?
With device-to-hub l
Alan Stern wrote:
On Sun, 2 May 2004, David Brownell wrote:
Physical. This would be only for struct usb_device, not for struct
usb_interface, because only usb_device has a children[] array.
But for hub nodes, the two are equivalent. Changing to config 0
will remove child nodes ... I'm afraid t
On Sun, 2 May 2004, David Brownell wrote:
> I think the notion of device-to-parent reset locking is the problem.
> What if the device gets unplugged while you try to reset it, or
> it was already reset and that's why it failed, making the driver
> try to reset it?
With device-to-hub locking, ther
I've got some updates to that code to support top-down suspend
and resume, so that's not really the way that code is heading.
The serialize lock can be held while suspending hubs children.
It was a case of walking before running. :)
Do you have a clear picture of how to make top-down suspend wo
Alan Stern wrote:
On Sun, 2 May 2004, David Brownell wrote:
BTW here's a code fragment showing roughly the tree-locking
algorithm I described at one point. If everyone uses this
for things that can change tree topology, they'll get locks
from root to affected-subtree ... in parallel, not collidi
On Sun, 2 May 2004, David Brownell wrote:
> > Physical. This would be only for struct usb_device, not for struct
> > usb_interface, because only usb_device has a children[] array.
>
> But for hub nodes, the two are equivalent. Changing to config 0
> will remove child nodes ... I'm afraid that
On Sun, 2 May 2004, David Brownell wrote:
> BTW here's a code fragment showing roughly the tree-locking
> algorithm I described at one point. If everyone uses this
> for things that can change tree topology, they'll get locks
> from root to affected-subtree ... in parallel, not colliding.
That l
On Sun, 2 May 2004, David Brownell wrote:
> I've got some updates to that code to support top-down suspend
> and resume, so that's not really the way that code is heading.
> The serialize lock can be held while suspending hubs children.
> It was a case of walking before running. :)
Do you have a
I like the way this idea is leading. We can have a global topology
semaphore protect all the children[] arrays and also the driver-model
lists, since the two data structure views should always be consistent.
Then the ->serialize locks won't be needed for tree traversal.
Which "topology" do you m
BTW here's a code fragment showing roughly the tree-locking
algorithm I described at one point. If everyone uses this
for things that can change tree topology, they'll get locks
from root to affected-subtree ... in parallel, not colliding.
If task #1 locks a subtree, then task #2 wants to lock a
n
Alan Stern wrote:
That's not what I had in mind. Suppose we want to suspend hub B. Then
first we have to go through all of B's children and suspend them. While
that's happening, another child could be connected to B. It would then be
necessary to go back and suspend that child. Not too bad
On Sat, 1 May 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > I like the way this idea is leading. We can have a global topology
> > semaphore protect all the children[] arrays and also the driver-model
> > lists, since the two data structure views should always be consistent.
> > Then t
On Sat, 1 May 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > That's not what I had in mind. Suppose we want to suspend hub B. Then
> > first we have to go through all of B's children and suspend them. While
> > that's happening, another child could be connected to B. It would then be
Alan Stern wrote:
It's a tricky problem, and I haven't figured out all the ramifications
yet...
Me either. That means we haven't hit on the
right simplifications yet ... :)
That's not what I had in mind. Suppose we want to suspend hub B. Then
first we have to go through all of B's children a
Alan Stern wrote:
I like the way this idea is leading. We can have a global topology
semaphore protect all the children[] arrays and also the driver-model
lists, since the two data structure views should always be consistent.
Then the ->serialize locks won't be needed for tree traversal.
Which
On Sat, 1 May 2004, Oliver Neukum wrote:
> Am Samstag, 1. Mai 2004 17:15 schrieb Alan Stern:
> > Instead they can be used by the hub driver to ensure that only one thing
> > happens on a hub at any time. When suspending or resetting a port, the
> > rule should be to acquire the serialize lock on
Am Samstag, 1. Mai 2004 17:15 schrieb Alan Stern:
> Instead they can be used by the hub driver to ensure that only one thing
> happens on a hub at any time. When suspending or resetting a port, the
> rule should be to acquire the serialize lock on the child first, then on
> its parent hub. That m
On Fri, 30 Apr 2004, Pete Zaitcev wrote:
> On Fri, 30 Apr 2004 23:09:31 -0400 (EDT)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > It may be that we're making ->serialize do too much. For example, my
> > recent change to devices.c uses it to prevent topology changes while
> > traversing the tree,
On Fri, 30 Apr 2004 23:09:31 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> It may be that we're making ->serialize do too much. For example, my
> recent change to devices.c uses it to prevent topology changes while
> traversing the tree, but that function could easily be served by something
On Fri, 30 Apr 2004, David Brownell wrote:
> Alan Stern wrote:
> >
> > I interpreted "children" to mean just usbdev->children[], not ports. If
> > you allow it to include the ports as well, you rule out the possibility of
> > manipulating different ports simultaneously. I admit that doesn't com
Alan Stern wrote:
On Thu, 29 Apr 2004, David Brownell wrote:
This is the kind of thing I meant earlier, when I mentioned that
the basic policy for usbdev->serialize would be to own it when
manipulating children. ...
I interpreted "children" to mean just usbdev->children[], not ports. If
you al
On Thu, 29 Apr 2004, David Brownell wrote:
> This is the kind of thing I meant earlier, when I mentioned that
> the basic policy for usbdev->serialize would be to own it when
> manipulating children. Follow that policy and those things WILL
> be safely serialized ... if they were being done with
On Thu, 29 Apr 2004, David Brownell wrote:
> 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.
You're right. I don't know
Alan Stern wrote:
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
Alan Stern wrote:
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 scop
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 secti
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 rev
37 matches
Mail list logo
