Yes the enable/disable should be static. I originally made themnon-static when I converted the prepare/unprepare set, but of courseit's possible to call these with the prepare_lock mutex held so I'llfix this up in the next set.

Yes this code should so something better. I've been focused mostly onthe "write" aspects of the clk API (set_rate, set_parent,enable/disable and prepare/unprepare) and less on the "read" aspectsof the clk API (get_rate, get_parent, round_rate, etc). I'll givethis a closer look for the next set.

>> +/**>> + * DOC: Using the CLK_PARENT_SET_RATE flag>> + *>> + * __clk_set_rate changes the child's rate before the parent's to more>> + * easily handle failure conditions.>> + *>> + * This means clk might run out of spec for a short time if its rate is>> + * increased before the parent's rate is updated.>> + *>> + * To prevent this consider setting the CLK_GATE_SET_RATE flag on any>> + * clk where you also set the CLK_PARENT_SET_RATE flag>> + */>>> Is this standard kerneldoc format?

The next patch in the series uses fail_clk to propagateABORT_RATE_CHANGE notifications to any drivers that have subscribed tothem. The FIXME comment hints at that but doesn't make it clear. Theidea is that the PRE_RATE_CHANGE notifiers will be noisy and stack up(potentially), but I only want to propagate the POST_RATE_CHANGE andABORT_RATE_CHANGE notifications once for any single call toclk_set_rate, which is why __clk_set_rate returns a struct clk *.