Date: Tue, 6 Jan 2009 12:58:59 +0000
From: Mark Brown <broonie@sirena.org.uk>
To: dbrownell@users.sourceforge.net
Cc: lrg@slimlogic.co.uk, lkml <linux-kernel@vger.kernel.org>
Message-ID: <20090106125858.GE6783@sirena.org.uk>
References: <200812011335.43551.david-b@pacbell.net> <200901051545.04912.david-b@pacbell.net> <20090106101050.GB6783@sirena.org.uk> <200901060221.26614.david-b@pacbell.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200901060221.26614.david-b@pacbell.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [patch 2.6.28-rc7] regulator: catch some registration errors
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1172
Lines: 24

On Tue, Jan 06, 2009 at 02:21:26AM -0800, David Brownell wrote:
> On Tuesday 06 January 2009, Mark Brown wrote:

> >	[ Long URL for your i.MX3 cpufreq driver elided ] 

> Right, and what's keeping you from providing a "struct device *"
> for that to use?

Well, clearly it can be done but I'd expect review issues from having
the architectures provide a half done representation of the CPU in the
device tree that's essentially private to the cpufreq driver (and then
has no tie in with cpufreq itself).

Personally, I'd be much happier to require a device if there were some
agreement about how CPUs should be done in the device model - at the
minute it all seems very ad-hoc where it's done at all.  For the time
being I'd prefer to bodge in a device for doing printouts in the
regulator core rather than forcing users to have a device when we don't
have a clear story on what to use.  Neither approach is particularly nice.
--
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/