[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20150820153922.GE30520@lukather>
Date: Thu, 20 Aug 2015 17:39:22 +0200
From: Maxime Ripard <maxime.ripard@...e-electrons.com>
To: Michael Turquette <mturquette@...libre.com>
Cc: linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
sboyd@...eaurora.org, lee.jones@...aro.org, s.hauer@...gutronix.de,
geert@...ux-m68k.org
Subject: Re: [PATCH RFC RFT 3/3] clk: introduce CLK_ENABLE_HAND_OFF flag
On Tue, Aug 18, 2015 at 09:39:31AM -0700, Michael Turquette wrote:
> > In my mind, the fact that we hand off the clock reference is a direct
> > result to the clock being critical (or whatever name we want to call
> > it). The hand off is a side effect, but the real information we want
> > to carry is that it should not be gated.
>
> I chose the "hand-off" name because I want to set an expectation to
> users of this feature. That expectation is that some day they will have
> a Linux device driver that claims and manages this "critical clock".
> Clearly this is not always the case. Many clocks using this feature will
> never have a driver that "owns" them.
>
> But I wanted to avoid any kind of "always on" or "easy hack to avoid
> writing proper driver code" naming convention that encourages bad
> behavior down the line.
>
> Also, the hand-off thing is sort of a big deal. If driver writers only
> thought of this as an "alway on" mechanism then subtle bugs might creep
> in where drivers are getting and disabling a clock that the author
> incorrectly thought would always be enabled. So I'd like the name to
> reflect that somehow.
>
> As always I am open to suggestions.
For the record, I think always-on would be just as bad, since it has
the same issue of describing the behaviour instead of describing what
the clock is.
I would think critical is better, and if you feel there's some
unexpected behaviour, we can always add some comment / documentation
for that (heresy, I know ;))
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists