On Fri, Aug 25, 2017 at 04:28:46PM -0700, Stephen Boyd wrote: > On 08/24, Linus Walleij wrote: > > On Mon, Aug 14, 2017 at 6:05 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > > Side note: Maybe we _should_ introduce devm_watchdog_clk_prepare_enable() > > > since this problem affects several watchdog drivers. > > > > Hmmmmmmmmm a special watchdog primitive may be apropriate. > > Dunno what the clk maintainers think? > > > > Stephen/Mike: do you like that or would you rather see a primitive > > inside the clock subsystem for this? > > > > devm_clk_prepare_enable() was already proposed and then the > thread went quiet. Re-kickstart it? > It was propsed several times, and each time it went nowhere. I got the impression that it won't be accepted, presumably because it can be misused. I have all but given up on it, and I have it on my task list to replace pretty much each pair of clk_prepare_enable() / clk_prepare_disable() calls in the watchdog subsystem with devm_add_action(). Not that I like that "solution", but life isn't perfect. Guenter > I'd still prefer we just disable clks on clk_put(), but Russell > said we needed to fix all non-common clk implementations of the > clk API to do that and then I forgot about the topic (so > anti-climatic). I'm pretty much OK with us merging the temporary > solution. We can churn again later and remove it all once we > convert everything into one CCF. > > I'd prefer we also change common clk framework to actually do the > disable on put though so we flush out any issues early. If the > two things are packaged together I would be ultra happy. It's not > like people are going to convert to CCF just so they can get clk > disable on clk_put() as a feature, but at least we can have it as > a feature. > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html