RFC CPUFreq: create platform-dev for DT based cpufreq drivers
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 8 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC V1 0/8] CPUFreq: create platform-dev for DT based cpufreq drivers
Quoted 17 lines · Viresh Kumar
Quoted 1 line · Arnd Bergmann
Thanks a lot for working on this, we really need to figure it out one day!
:)
Quoted 11 lines
Your patches seem well-implemented, so if everybody thinks the general approach is the best solution, we should do that. From my point of view, there are two things I would do differently:
- In the DT binding, I would strongly prefer anything but the root compatible property as the key for the new platforms. Clearly we have to keep using it for the backwards-compatibility case, as you do, but I think there are more appropriate places to put it. Sorting from most favorite to least favorite, my list would be:
1. a new property in /cpus/
2. a new property each /cpus/cpu at ... node.
Quoted 6 lines
I did it this way earlier and named it dvfs-method but probably putting this into the /cpus/ node is far better. But then Sudeep asked to utilize compatible property only..
Are you fine with the name here? "dvfs-method"
That's right, I don't like driver specific method in the cpu node as you initially did. But if it's a property in the chosen node (where we usually put the Linux specific properties), I am fine with that as Arnd has illustrated in his patch.
Regards,
Sudeep