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: <1387577327-5007-1-git-send-email-james.hogan@imgtec.com>
Date:	Fri, 20 Dec 2013 22:08:45 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Mike Turquette <mturquette@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, James Hogan <james.hogan@...tec.com>
Subject: [RFC 0/2] clk: dt: generic DT preset clock frequency bindings

These patches add a property "clock-N-frequency" to the clock consumer
bindings to specify the frequency that a clock should be configured to
when it is made use of. N is the index of a clock specifier in the
clocks property, starting at 0.

It's RFC since there are plenty of ways it could be handled, I've pretty
much just tried the simplest, but I'd like to get some thoughts from
others:
 - Adding such properties to individual device drivers / bindings. The
   bindings could be standardised and handled generically like in this
   patch, although it's not very nicely extensible to more complex
   settings (e.g. setting a particular clock's parent up the hierarchy a
   bit).
 - Adding named phandles like pinctrl clients do for pin configuration
   but to describe clock configuration, the "default" of which is set up
   automatically when a device is probed. This is more extensible, and
   certainly more complex. I suspect it may be overkill.

The point is to avoid the need to add clock-frequency properties to
individual device bindings or modify drivers to set the frequency of
clocks to that requested in device tree. Instead the driver can just
read the rate of the clock as if it was fixed without needing to know
how it has been configured.

This is aimed at devices where it's difficult for drivers to determine
what a clock should be set to, and either there is a recommended
frequency for the particular system or a chosen frequency for the
particular application of the system (which makes it essentially
configuration data).

James Hogan (2):
  dt: binding: add clock-N-frequency to common clock bindings
  clk: implement generic DT preset clock frequency

 .../devicetree/bindings/clock/clock-bindings.txt   |  3 ++
 drivers/clk/clk.c                                  | 34 ++++++++++++++++++++++
 drivers/clk/clkdev.c                               |  3 ++
 include/linux/clk.h                                |  5 ++++
 4 files changed, 45 insertions(+)

-- 
1.8.3.2

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ