[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: klists and struct device semaphores
On Wed, 30 Mar 2005, Patrick Mochel wrote:

> > Having thought it through, I believe all we need for USB support is this:
> >
> > Whenever usb_register() in the USB core calls driver_register()
> > and the call filters down to driver_attach(), that routine
> > should lock dev->parent->sem before calling driver_probe_device()
> > (and unlock it afterward, of course).
> >
> > (For the corresponding remove pathway, where usb_deregister()
> > calls driver_unregister(), it would be nice if __remove_driver()
> > locked dev->parent->sem before calling device_release_driver().
> > This is not really needed, however, since USB drivers aren't
> > supposed to touch the device in their disconnect() method.)
> Why can't you just lock it in ->probe() and ->remove() yourself?

Aha! There you go... This explains why you need explicit locking rules.

When probe() and remove() are called, the driver-model core already owns
the device's lock. If the driver then tried to lock the parent, it would
mean acquiring locks in the wrong order. This could easily lead to

Furthermore, it will often happen during probe() and remove() that the
parent's lock is already owned by the USB core. So the driver _mustn't_
try to lock it.

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.091 / U:4.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site