linux-kernel - [PATCH 0/2] [RFC] reentrancy in the common clk framework

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, 13 Jul 2012 17:16:39 -0700
From:	Mike Turquette <mturquette@...aro.org>
To:	<linux-kernel@...r.kernel.org>
CC:	<shawn.guo@...aro.org>, <linus.walleij@...aro.org>,
	<rob.herring@...xeda.com>, <pdeschrijver@...dia.com>,
	<pgaikwad@...dia.com>, <viresh.kumar@...aro.org>, <rnayak@...com>,
	<paul@...an.com>, <broonie@...nsource.wolfsonmicro.com>,
	<tglx@...utronix.de>, <ccross@...roid.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...aro.org>
Subject: [PATCH 0/2] [RFC] reentrancy in the common clk framework

Hi all,

This RFC series is meant to kick off some discussion around two related
problems in the current clk framework implementation.

First, clk_prepare for i2c devices might result in nested calls to
clk_prepare (for preparing the clocks of the i2c controller).  So
basically we need to make clk_prepare reentrant for these cases.  Due to
the global prepare_lock mutex this currently results in a deadlock.

Second, dynamic voltage and frequency scaling (dvfs) through the clock
framework suffers from a similar issue as describe above.  To date
several folks have expressed the desire to put voltage scaling logic
into the clk rate change notifier handlers as a way to implement dvfs
without creating a new driver-level api.  There are many benefits to
this approach, but on many platforms it is likely that calling
regulator_set_voltage within a rate change notifier handler will
generate a call to clk_prepare while clk_set_rate is holding the global
prepare_lock mutex.  This also results in a deadlock.

The first patch in this series is an attempt to solve the locking
problem via per-clock locks.  I do not like per-clock locks, but after
some experimentation it held more promise than other approaches.  The
implementation is only partially complete.  If you have any alternative
ideas to that sort of approach please let me know as per-clock locks are
really painful.

The second patch in this series simply demonstrates dvfs via clk rate
change notifiers.  The patch modifies the .target callback in OMAP's
cpufreq driver by removing direct calls to regulator_set_voltage and
instead registers a clk rate change notifier handler to do the same.
And whaddaya know it works!  In a perfect world any cpufreq or devfreq
driver would only need to call clk_set_rate within the .target callback
and everything would Just Work(tm).

Thanks in advance for any feedback, ideas or flames about how I don't
understand lockdep and broke everything and per-clock locking is stupid,
etc.

Mike Turquette (2):
  [RFC] clk: reentrancy via per-clock locking
  [RFC] cpufreq: omap: scale regulator from clk notifier

 drivers/clk/clk.c              |  202 +++++++++++++++++++++++++++++-----------
 drivers/cpufreq/omap-cpufreq.c |  154 ++++++++++++++++++------------
 include/linux/clk-private.h    |    5 +
 3 files changed, 250 insertions(+), 111 deletions(-)

-- 
1.7.9.5

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