linux-kernel - Locking in the clk API

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]

Message-Id: <201101111016.42819.jeremy.kerr@canonical.com>
Date:	Tue, 11 Jan 2011 10:16:42 +0800
From:	Jeremy Kerr <jeremy.kerr@...onical.com>
To:	linux-sh@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Cc:	Ben Herrenschmidt <benh@...nel.crashing.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	"Uwe Kleine-König" <u.kleine-koenig@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>
Subject: Locking in the clk API

Hi all,

I'd like to define some locking semantics for the clk API, so that device 
driver can have some assurance about when it is safe to call various clk_ 
functions from atomic contexts.

Vincent - you mentioned in a conversation that your code had some specific 
requirements for clock enable/disable at interrupt time - could you reply with 
an outline of this? Also, Sascha and Uwe: do you have any thoughts from your 
work with the common struct clk?

== Requirements ==

To get things started, here are some basic requirements from the external API 
side:

1) clk_enable: the clock should be outputting a valid clock signal before
   returning from this function.

    - drivers may require valid clock signal to be present for subsequent
      device interactions.

3) clk_disable: may be called from atomic context

    - Vincent: this is what I recall from our conversation, is it still true?

4) clk_set_rate: clock should change to the new rate before this returns

5) clk_get_rate: may be called from atomic context

6) in general, drivers shouldn't require details about the clock
   implementation

And from the clock implementation side:

7) interactions with clock hardware may require sleeping (eg, clocks on an i2c
   bus)

8) clk_enable() may require enabling a parent, which may also require
   sleeping. Ideally, we shouldn't have to care about the parent's
   implementation.

I'm sure there are others, please feel free to add to this list.

== Implementation ==

At present, we can satisfy these with:

* clk_enable: may sleep

* clk_disable: may not sleep, but it's possible to make the global
  clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
  non-atomic context.

* clk_get_rate: may not sleep

* clk_set_rate: may sleep

As we build up our requirements, we can adjust as suitable.

I'm excluding clk_{get,set}_parent at present, as I'm not sure we want these 
as part of the device-driver API (ie, they require knowledge of the platform 
clock infrastructure).

Thanks,

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