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.
Attachment:
signature.asc
Description: Digital signature
