On Thursday 21 June 2012, Mark Brown wrote: > Show Details > 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. Right. It's certainly a trade-off. If a company makes 100 SoCs that all have similar-but-different regulators, then it should be clear win to have the driver be very abstract and fed with DT data for configuragtion. > 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 should never be necessary to add board-specific properties in the nodes that describe the SoC specific bits. What I was referring to is just moving the data that currently resides in the regulator driver into DT. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
