linux-kernel - Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks

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]

Date:	Mon, 12 Dec 2011 22:38:26 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	"Turquette, Mike" <mturquette@...com>
Cc:	Andrew Lunn <andrew@...n.ch>, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	jeremy.kerr@...onical.com, broonie@...nsource.wolfsonmicro.com,
	tglx@...utronix.de, linus.walleij@...ricsson.com,
	amit.kucheria@...aro.org, dsaxena@...aro.org, patches@...aro.org,
	linaro-dev@...ts.linaro.org, aul@...an.com,
	grant.likely@...retlab.ca, sboyd@...cinc.com,
	shawn.guo@...escale.com, skannan@...cinc.com,
	magnus.damm@...il.com, arnd.bergmann@...aro.org,
	eric.miao@...aro.org, richard.zhao@...aro.org
Subject: Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks

> I don't like this approach.  If the bool for a particular clk is
> statically defined then it could be wrong (bootloader/kernel
> mismatch).
> 
> I've been thinking of adding a clk->ops->init callback in clk_init,
> which is defined for a platform to use however the author sees fit.
> There have been a few cases where it would be nice to "init" a clk
> only once, when it is registered.  That code could also handle
> detecting if a clk is enabled or not.
> 
> On the other hand we already have a .get_parent callback which is only
> good for figuring out which parent a mux clk is using... maybe a
> .is_enabled or .get_enabled would be a good idea which also served the
> purpose of dynamically determining whether a clk is disabled or
> running.
> 
> In general though I think we should try to keep the solution in the
> core code, not by having platform code pass in a bool.

Hi Mike

How about simply reading the bit in the control register? You are
already doing a read/modify/write when enabling/disabling the clock,
so it seems reasonably safe to assume the read gives you the current
state. For those platforms which this does not work, you could add
another flag disabling this read to get the initial state.

	Andrew
--
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/