On Wed, May 13, 2015 at 7:32 PM, Michael Turquette <mike.turquette@xxxxxxxxxx> wrote: > Quoting Mark Brown (2015-05-13 04:03:57) >> On Wed, May 13, 2015 at 02:25:28PM +0530, Viresh Kumar wrote: >> > On 12-05-15, 14:42, Michael Turquette wrote: >> > > Quoting Viresh Kumar (2015-04-30 05:07:59) >> > >> > > Why should this new binding exist? >> >> > The answer to this particular query is perhaps simple, i.e. we have >> > unsolved problems that we wanted to solve in a generic way. >> >> > But probably the bigger question is "Should we really put the OPPs >> > (new or old bindings) in DT". >> >> And also is trying to do this in a completely generic manner the right >> way of going about things - do we really understand the problem area >> well enough to create a completely generic solution for all cases, >> bearing in mind that once things go into a DT binding they become an ABI? > > No, we don't understand the problem space well enough to form an ABI. > And even if we did understand it perfectly today, the constraints and > expressions will change tomorrow. > > Putting this stuff in C without any philosophical constraints on whether > or not we can change it later is the way to go. Having a binding does not preclude you from doing your own thing in C. You can choose to ignore it (or parts of it). It also doesn't mean you have to use a generic driver with a generic binding. While yes, we could do the same thing in C, the reality is that we often don't force common data into common structures. This leads to obfuscating what are the real h/w differences because everyone does things their own way. Conveniently, struct dev_pm_opp is a perfect example here. We already know that just freq and volt alone are not enough, yet that is all the kernel structure has. The way you avoid the ABI issue is you create a new one which is what we've done here. I'm not saying we want 10 different OPP bindings. If we are back here in a year with v3, then yes you are probably right. But I believe v2 is a framework that can last. Most of the review issues have resulted in simply dropping properties (until needed) without otherwise changing the binding. I think that demonstrates this bindiing is flexible and extendable. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
