linux-kernel - Re: [PATCH] BUG: clk_find() misses some 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-prev] [day] [month] [year] [list]

Message-ID: <20120817113442.GN18957@n2100.arm.linux.org.uk>
Date:	Fri, 17 Aug 2012 12:34:42 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Richard Genoud <richard.genoud@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] BUG: clk_find() misses some clocks

On Fri, Aug 17, 2012 at 12:23:06PM +0200, Richard Genoud wrote:
> Ok, so I have to declare it like that :
> CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioAB_clk)

Yes, because the wildcarding is in the clkdev tables, not in the driver.
If you think about what's going on, that's the way it has to be.  Remember
that it's the _device_ that defines what the connection name is (there's
the hint: it's the connection name on the device itself) and it isn't a
global clock name.

So, for example, if set of devices used in multiple different SoCs have a
clock input called "apbclk" and on some SoCs this clock is uncontrollable,
but on others it can be individually controlled, we can cater for this:

- the SoC where this clock is uncontrollable can create a dummy clock with
  a connection ID of "apbclk" and a NULL device name, which will match
  against any device asking for an "apbclk".
- the SoC where the clock is individually controllable would list the
  individual "apbclk" entries in the clkdev table, and clkdev will return
  the appropriate one.

In mixed environments, this also works, because we return the "best match"
from clkdev.

Same goes for devices where they have an "iclk" and an "fclk" (iow, two
clocks) - the connection ID can be wildcarded in the clkdev tables so that
the same clock can be returned for the same device where the driver asks
for the clocks individually - if that's what the SoC support desires.

It makes no sense for a driver to ask for "any clock on this device"
because drivers always want the clock for a particular purpose.  Hence
why NULL arguments to clk_get() don't act as wildcards.
--
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/