[PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible
Mark Brown
broonie at opensource.wolfsonmicro.com
Fri Jun 22 02:14:59 EST 2012
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120621/108032da/attachment.sig>
More information about the devicetree-discuss
mailing list