On Fri, Jul 01, 2011 at 10:40:39AM -0400, Alan Stern wrote: > On Thu, 30 Jun 2011, Sarah Sharp wrote: > > > On Thu, Jun 30, 2011 at 05:01:36PM -0400, Alan Stern wrote: > > > While iterating through a single bus, all you need to do is lock each > > > device as you come to it (including the root hub), using > > > usb_lock_device() and usb_unlock_device(). While you hold a device's > > > lock, it can't be unregistered and it can't have any children added or > > > removed. > > > > Say I have this tree: > > > > port 2 > > | > > HS hub 1 > > / \ > > HS hub 2 HS device 3 > > > > If I call usb_lock_device() for HS device 3, and then for HS hub 1, > > does that prevent children from being added or removed from HS hub 2? > > Ack! Don't do that! The device-model locking rules require that locks > be acquired going _down_ the tree, never _up_. Therefore you must > never call usb_lock_device() for hub 1 while holding the lock for > either hub 2 or device 3. Ok, that's why I was asking about locking order. :) But in the case where I have to walk up the tree from a newly added device to get the roothub port number, it's not very useful to lock from top-down. > To answer your question: The only way to prevent children from being > added to hub 2 is to lock hub 2. You can prevent a child from being > removed from hub 2 by locking hub 2, the child, or any of the child's > descendants. If I take the bus list lock, does that prevent *any* device from being added to or removed from the bus? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
