linux-kernel - Re: [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120621161459.GY4037@opensource.wolfsonmicro.com>
Date:	Thu, 21 Jun 2012 17:14:59 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Laxman Dewangan <ldewangan@...dia.com>, lrg@...com,
	rob.herring@...xeda.com, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, lee.jones@...aro.org,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 2/3] regulator: dt: regulator match by
 regulator-compatible

On Thu, Jun 21, 2012 at 02:50:35PM +0000, Arnd Bergmann wrote:

> It seems that the drivers that are changed to use this could also try to
> describe the individual regulators completely, by moving the contents
> of e.g. ab8500_regulator_info into the device tree, but having the string
> identifier with an in-kernel table makes sense when there is only one
> such table.

I'm not that big a fan of moving all the data into device tree as it
means that you need even more parsing code and you need to update the
device trees for every board out there every time you want to add
support for a new feature which doesn't seem like a win.  Right now with
the DT kept in the kernel it's not so bad but if we ever do start
distributing it separately it becomes more of an issue.

I'm also not sure if the tooling works well for allowing people to
include standard DTs for chips and add new properties to nodes for the
board specific configuration, though I think I've seen a few things
which suggested that was dealt with reasonably well.

It also means that the driver becomes useless on non-DT systems; while
for something like ab85xx which is specific to a SoC that's not a
problem it's a serious drawback for devices which may be used on other
architectures (or older ARM systems for that matter).  I'm quite worried
by this tendency to try to just dump all our data structures into DT -
it's similar to the issues with some of the MFDs just wanting to drop in
the current Linux subdivision of the device even though that's often
just reflecting our current internal structures which do change even
without worrying about other OSs.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)