On 01-04-16, 14:30, Mason wrote: > Hmmm... I'm using the older operating-points prop in my platform's DT. > Why can't we define a new property (e.g. "enable-generic-cpufreq") > which registers the "cpufreq-dt" pseudo-device?
DT is all about expressing hardware in a file. The same bindings should be usable across any operating system, not just Linux. And so we shouldn't have any OS or software-implementation specific properties here. > And platforms that manually register "cpufreq-dt" would be > automatically white-listed, even if they don't have the new > property, to maintain backward-compat? Its not about just making it work, otherwise we would have done it long time back by creating a DT node for cpufreq-dt driver. > > @Rob: Will that be acceptable to you? We are discussing (again) about how to > > probe cpufreq-dt driver automatically for platforms :) > > > > The cpus node doesn't have any 'compatible' property today, and I will be > > required to add that in this case. > > Why does it need a compatible prop? That compatible property will describe how to parse/describe operating-points for a CPU. Any driver, which has the ability to parse those bindings can do things base on such a compatibility string. I hope you got the idea. -- viresh
