On Tue, Aug 18, 2015 at 09:43:56AM -0700, Michael Turquette wrote: > Quoting Maxime Ripard (2015-08-18 08:45:52) > > Hi Mike, > > > > On Fri, Aug 07, 2015 at 12:09:27PM -0700, Michael Turquette wrote: > > > All of the other kitchen sink stuff (DT binding, passing the flag back > > > to the framework when the clock consumer driver calls clk_put) was left > > > out because I do not see a real use case for it. If one can demonstrate > > > a real use case (and not a hypothetical one) then this patch series can > > > be expanded further. > > > > I think there is a very trivial use case for passing back the > > reference to the framework, if during the probed, we have something > > like: > > > > clk = clk_get() > > clk_prepare_enable(clk) > > foo_framework_register() > > > > if foo_framework_register fails, the sensible thing to do would be to > > call clk_disable_unprepare. If the clock was a critical clock, you > > just gated it. > > Hmm, a good point. Creating the "pass the reference back" call is not > hard technically. But how to keep from abusing it? E.g. I do not want > that call to become an alternative to correct use of clk_enable. > > Maybe I'll need a Coccinelle script or just some regular sed to > occasionally search for new users of this api and audit them? > > I was hoping to not add any new consumer api at all :-/
I don't think there's any abuse that can be done with the current API, nor do I think you need to have new functions either. If the clock is critical, when the customer calls clk_unprepare_disable on it, simply take back the reference you gave in the framework, and you're done. Or am I missing something? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature