RE: [PATCH] clk: Add functions to get optional clocks

[Stephen Boyd <sboyd@kernel.org>]

Quoting Phil Edworthy (2018-07-18 06:56:26)
> Hi Russell,
> 
> On 18 July 2018 14:19, Geert Uytterhoeven wrote:
> > On Wed, Jul 18, 2018 at 3:02 PM Russell King - ARM Linux  wrote:
> > > On Wed, Jul 18, 2018 at 01:57:38PM +0100, Phil Edworthy wrote:
> > > > 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.