linux-kernel - [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks

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: <20110711025344.GA27497@opensource.wolfsonmicro.com>
Date:	Mon, 11 Jul 2011 11:53:44 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jeremy Kerr <jeremy.kerr@...onical.com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-sh@...r.kernel.org, patches@...nsource.wolfsonmicro.com,
	Grant Likely <grant@...retlab.ca>
Subject: [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks

I've just been having a go at implementing generic clk API support for
an off-SoC device on a slow bus, the clocking module in the wm831x/2x
series of PMICs.  Unfortunately as I don't currently have access to a
platform that has been converted to use the API I've not actually been
able to test the code but I'm reasonably optimistic that the code will
Just Work(tm) as the API seems fairly straightforward.

The biggest issue I ran into was that as the clocks are all registered
by name with the API if you've got two instances of the same off-SoC
device in the system you'll not be able to disambiguate between the
clocks it provides.  I've added a simple solution for this in the form
of a patch which takes a struct device as an argument and adds that to
the name of the registered clock.  This isn't ideal but should give
stable names which systems can use together with clkdev to match clocks
up with their users.  I believe that when we have device tree bindings
for clocks we should be able to use the device to access the bindings
and avoid this mangling - Grant, is that correct?

Otherwise everything seems to work pretty well from the driver side for
these devices, I've added some minor updates which came up naturally
while writing the driver code and seemed fairly obvious.  One of these
was a change to provide a user visible Kconfig option for building the
clock drivers, the idea being to make it easier to do build tests.  I
did also wonder if it's worth adding a patch to enable the API on x86
(which doesn't currently have a clock API) for coverage.

These patches (which include the two I posted yesterday) are against the
series you posted in May with the exception of the wm831x patch which
also has an additional dependency on "mfd: Add WM831x clock control
register definitions" which is due for merge in the next merge window.
If this stuff is all OK for you it would be good if you could include
the wm831x driver in your tree for this, especially given that there's
nothing in -next.

Mark Brown (6):
      clk: Prototype and document clk_register()
      clk: Provide a dummy clk_unregister()
      clk: Constify struct clk_hw_ops
      clk: Add Kconfig option to build all generic clk drivers
      clk: Support multiple instances of the same clock provider
      clk: Add initial WM831x clock driver

 MAINTAINERS              |    1 +
 drivers/clk/Kconfig      |   16 ++-
 drivers/clk/Makefile     |    1 +
 drivers/clk/clk-wm831x.c |  389 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/clk.c        |   38 ++++-
 include/linux/clk.h      |   33 ++++
 6 files changed, 472 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/clk-wm831x.c
--
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/