linux-kernel - Re: [PATCH v5 4/5] clk: add CLK_SET_RATE_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130725180557.7598.20285@quantum>
Date:	Thu, 25 Jul 2013 11:05:57 -0700
From:	Mike Turquette <mturquette@...aro.org>
To:	James Hogan <james.hogan@...tec.com>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>
Cc:	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	<linux-kernel@...r.kernel.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Doug Anderson <dianders@...omium.org>,
	Sascha Hauer <kernel@...gutronix.de>,
	Russell King <linux@....linux.org.uk>,
	Viresh Kumar <viresh.linux@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Chao Xie <xiechao.mail@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Emilio López <emilio@...pez.com.ar>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Prashant Gaikwad <pgaikwad@...dia.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	Joseph Lo <josephl@...dia.com>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	"Pawel Moll" <pawel.moll@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>
Subject: Re: [PATCH v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag

Quoting James Hogan (2013-07-25 05:55:09)
> Hi Sylwester
> 
> On 25/07/13 13:34, Sylwester Nawrocki wrote:
> > On 06/13/2013 06:06 PM, James Hogan wrote:
> >> Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes
> >> being reparented during clk_set_rate.
> >>
> >> To avoid breaking existing platforms, all callers of clk_register_mux()
> >> are adjusted to pass the new flag. Platform maintainers are encouraged
> >> to remove the flag if they wish to allow mux reparenting on set_rate.
> > [..]
> >> Changes in v3:
> >>
> >> * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
> >>   to this new patch.
> >> * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of
> >>   clk_register_mux. If you don't mind your clocks being reparented in
> >>   response to set_rate please let me know and I'll drop the relevant
> >>   portion of the patch.
> > 
> > Why is this better to change current behaviour of the clock core
> > and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT
> > set in drivers of hardware that supports clock re-parenting while
> > setting clock rate ?
> 
> See this message from Mike Turquette which first suggested it:
> 
> http://marc.info/?l=linux-kernel&m=136847508109344&w=2
> 
> > Is there intention to just have the automatic clock re-parenting
> > as a default feature in the common clock API ?
> 
> Yes, that would be the result (except where explicitly disallowed).
> Unfortunately where such policy should ideally be defined is still up in
> the air.
> 
> It's not a property of the hardware, but then it is arguably a property
> of the environment the bootloader has configured (like the stuff in the
> /chosen device tree node).

I'm happy to get feedback on this decision. Looking back on
CLK_SET_RATE_PARENT flag I wish I had made that behavior the default.
Instead there would only be a flag for the case where you explicitly do
not wish to propagate the rate change request up the tree.

Another thing to consider here is that only users of .determine_rate are
affected. If your mux clock implements .set_parent and .round_rate, but
not .determine_rate then you are not affected by this change.

The whole thing gets messy because we're pushing policy into the clock
framework, but there is no way to avoid that if we're going to achieve
the goal of having drivers know only about the leaf clocks they consume
and not requiring those drivers to understand the greater clock tree
topology.

Regards,
Mike

> 
> Presuming that the usual reason not to reparent a mux is because other
> important clocks depend on it, the kernel might know enough to work out
> whether it's safe (unless of course there are other cores/threads in the
> SoC using the clock that Linux isn't aware of, which brings us back to
> it being a bootloader environment thing).
> 
> > My apologies if this has already been answered, I haven't been
> > following this thread.
> 
> No problem :)
> 
> Cheers
> James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/