* Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> [111020 02:07]: > On Thu, Oct 20, 2011 at 09:12:10AM +0530, Rajendra Nayak wrote: > > On Wednesday 19 October 2011 08:40 PM, Mark Brown wrote: > > > >I don't see any issue with leaving some things out of the DT bindings; > > >you were the one raising that as a concern. > > > The problem is, that there doesn't seem to be a clean way to embed > > *board data* into the kernel with DT, if left out of the DT bindings. > > There is the auxdata way of still attaching platform_data, but that I > > thought was a stopgap for just handling function pointers. > > We can always start off just completely omitting the data and then see > how we go from there. If we only cover 50% of users that's still 50% > more than are currently covered with device tree right now and it means > we can then spin round and look at the bits that are hard again without > review fatigue on the bits that are easy. We still need to pass the board configuration somehow, otherwise we can never remove all the platform data glue layers. And if we can't do that, we'll forever have all the nasty merge conflicts when adding new drivers. And there's an unnecessary dependency between adding drivers and the core SoC code. So we really need to remove all the platform data glue layers so driver probe can initialize things automagically. Kernel cmdline is of course one way to pass options, but probably won't scale for all the board wirings.. And the kernel cmdline should really be for user configurable options. So should we just have a cmdline string for each DT entry to pass the board specific options from DT to the driver? Something along the lines module options? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
