Re: [PATCH] BUG: clk_find() misses some clocks

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

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.