[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090830100857.GC4334@sirena.org.uk>
Date: Sun, 30 Aug 2009 11:08:57 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Linus Walleij <linus.ml.walleij@...il.com>
Cc: linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...ricsson.com>,
Liam Girdwood <lrg@...mlogic.co.uk>,
Samuel Ortiz <sameo@...ux.intel.com>,
Russell King <linux@....linux.org.uk>,
linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [PATCH] AB3100 regulator support v1
On Sun, Aug 30, 2009 at 02:37:51AM +0200, Linus Walleij wrote:
> 2009/8/30 Linus Walleij <linus.ml.walleij@...il.com>:
> > So this is because I am in the parents probe() function of course,
> > and it's all expected.
> I was curious how wm8350 on MX31 did this while using only subsys_initcalls()
> (wm8400 doesn't look like it's completed yet) and found:
What makes you say that wm8400 is not completed? If you're looking for
a current example of regulator driver probing the most current regulator
drivers I've merged are the wm831x drivers in -next via the MFD tree.
Though...
> which creates a platform device and sets the parent to
> the struct wm8350->dev. But this is actually the i2c_client dev
> and then it is not so strange that it works nicely to have both
> the 8350 core device as parent and the platform devices as
> children in a subsys_initcall() since the i2c core does not
> use the regular device driver matching scheme, but rolls it's
> own (which does NOT try to take the parent's semaphore...)
...though since the WM8400 and WM831x are I2C/SPI devices too they won't
have this issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists