linux-kernel - Propagating clock rate constraints

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-next>] [day] [month] [year] [list]

Date:	Fri, 27 Mar 2015 00:40:54 +0100
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Mike Turquette <mturquette@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Propagating clock rate constraints

Hello,

I recently had a problem with the at91 clk implementation: the
programmable clock driver is not forwarding set_rate() requests to its
parent, meaning that, if the PLLB is set to 0, it will choose another
parent which might be inappropriate to generate the requested clock.
ITOH, if we authorize forwarding set_rate requests without taking care
of constraints imposed by other users of the PLLB we might end-up
with a erroneous rate for the USB clock.

I thought using set_rate_range() would be a good idea to address this
issue, but apparently rate constraints are not propagated to parent
clocks, and PLLB is never exposed to devices (it is accessed through
clk muxers, divisors, etc).

Is there a plan to support propagating rate constraints to parent
clocks ?

Here is an example where propagating rate constraints would be useful:

The USB controller wants a 48MHz clock and the audio controller needs a
programmable clock running at 12MHz.

1/ The USB driver calls set_rate() on the USB clock, which in turn
   configures the PLLB to generate a 96MHz signal and sets its divisor
   to 2.
   Then it should call set_rate_range(usb_clk, 48Mhz, 48MHz) to prevent
   anyone from messing up with his USB clock.

2/ The audio controller calls set_rate on the prog clock, which in
   turn configures the PLLB to generate a 12MHz.
   Since nobody explicitly set a constraint on the PLLB, the set_rate()
   call should work, right ?
   If it works, after this call, the USB clk will generate a 6MHz
   signal instead of 48MHz one. 

I started to look at how rate constraint propagation could be handled:
here [1] is a quick&dirty/untested patch adding several things to deal
with such cases.
The idea is to declare each clock as a clk user of its parent, and then
modify rate range appropriately so that all children clk constraints are
taken into account by the parent clock when a rate change is requested.

Anyway, just tell me if you're already working on a solution for this
problem or if you need any help with that ?

Best Regards,

Boris

[1]http://code.bulix.org/dcm4c8-88137

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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/