Quoting Phil Edworthy (2018-07-18 06:56:26)

Hi Russell,

On 18 July 2018 14:19, Geert Uytterhoeven wrote:

quoted

On Wed, Jul 18, 2018 at 3:02 PM Russell King - ARM Linux  wrote:

quoted

On Wed, Jul 18, 2018 at 01:57:38PM +0100, Phil Edworthy wrote:

quoted

Behaves the same as (devm_)clk_get except where there is no clock
producer. In this case, instead of returning -ENOENT, the function
returns NULL. This makes error checking simpler and allows
clk_prepare_enable, etc to be called on the returned reference
without additional checks.

How does this work with non-DT systems, where looking a clock up which
isn't yet registered with clkdev returns -ENOENT ?

(clkdev doesn't know when all clocks are registered with it.)

Good question.

I guess all drivers trying to handle optional clocks this way are already broken
on non-DT systems where clocks may be registered late...

So how do non-DT systems that look a clock up which isn't yet
registered with clkdev, determine that an optional clock is there
or not?

Short answer is they don't. I'd still prefer we have this API though.

Can you rework this patch to be a little more invasive into the
clk_get() path, perhaps by reworking __of_clk_get_by_name() a little to
take an 'optional' argument, so that it only returns NULL when the clk
is looked up from DT? The fallback path in clkdev where we have a DT
based system looking up a clk through clkdev lookups doesn't seem to be
a real scenario that we should worry about here. I think sometimes
people use clkdev lookups when they're migrating to DT systems and
things aren't wired up properly in DT, but that isn't the norm.