linux-kernel - Re: [patch 2.6.28-rc7] regulator: catch some registration errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090106125858.GE6783@sirena.org.uk>
Date:	Tue, 6 Jan 2009 12:58:59 +0000
From:	Mark Brown <broonie@...ena.org.uk>
To:	dbrownell@...rs.sourceforge.net
Cc:	lrg@...mlogic.co.uk, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2.6.28-rc7] regulator: catch some registration errors

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/