Messages in this thread | | | Date | Sun, 30 Aug 2009 12:27:32 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [PATCH] AB3100 regulator support v1 |
| |
On Sun, 30 Aug 2009, Mark Brown wrote:
> On Sun, Aug 30, 2009 at 01:03:38AM +0200, Linus Walleij wrote: > > [While setting up a child platform device from a platform driver > probe...] > > > >> + /* This would seem logical but makes everything break... */ > > >> + /* pdev->dev.parent = parent; */ > > > > Err... it does? In what way? > > > The sub-platform devices are added, but when I add a platform driver for > > them, the probing does not commence, because they hang in > > driver base/dd.c: __driver_attach() trying to take the parent semaphore, > > i.e. this line: > > > if (dev->parent) /* Needed for USB */ > > down(&dev->parent->sem); > > > In this case the parent is ab3100-regulators, the platform device for > > the set of regulators. > > On the face of it (and without having actually looked at a running > system or anything yet) I'm rather surprised that platform based MFD > drivers aren't running into this issue more often. CCing in Alan who > made the change.
I'm not at all familiar with the detailed issues involved here. Perhaps because of this, I don't see why there's any reason for deadlocking. __driver_attach() is invoked when a new driver is registered; to avoid problems all you have to do is make sure you aren't holding any device locks when you register a driver.
In general, drivers are registered as part of a module initialization routine, which is quite separate from device probing. Hence the code doing the registration doesn't hold any locks.
Is the problem that the probe routine for a platform device is registering some child devices and then registering a driver for them? If that's the case, the problem can be solved by doing thing in the opposite order: Register the driver _before_ registering the devices it is supposed to manage. Then __driver_attach() won't run -- device_attach() will instead -- so the problem won't arise.
Alan Stern
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |