On 11-08-21, 10:48, Quentin Perret wrote: > I think this should work, but perhaps will be a bit tricky for cpufreq > driver developers as they need to have a pretty good understanding of > the stack to know that they should do the registration from here and not > ->init() for instance. Suggested alternative: we introduce a ->register_em() > callback to cpufreq_driver, and turn dev_pm_opp_of_register_em() into a > valid handler for this callback. This should 'document' things a bit > better, avoid some of the problems your other series tried to achieve, and > allow us to call the EM registration in exactly the right place from > cpufreq core. On the plus side, we could easily make this work for e.g. > the SCMI driver which would only need to provide its own version of > ->register_em(). > > Thoughts? I had exactly the same thing in mind, but was thinking of two callbacks, to register and unregister. But yeah, we aren't going to register for now at least :) I wasn't sure if that should be done or not, since we also have ready() callback. So was reluctant to suggest it earlier. But that can work well as well. -- viresh
