Locking in the clk API
From: Jeremy Kerr <hidden>
Date: 2011-01-11 14:36:02
Also in:
linux-sh, lkml
From: Jeremy Kerr <hidden>
Date: 2011-01-11 14:36:02
Also in:
linux-sh, lkml
Hi Paul,
Again, you are approaching it from the angle that an atomic clock is a special requirement rather than the default behaviour.
I'm not considering it a special requirement, but it's still a requirement (that the called function does not sleep). The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that now you've made the caller need to know what kind of clock it has, or might have one day. * For clk_enable/clk_enable_atomic, the decision is: is this call in an atomic context? * For clk_enable/clk_enable_sleepable, the decision is: might the clock code have given us a sleeping clock? Note that it's much easier to guarantee correctness for the first than it is for the second. Cheers, Jeremy