linux-kernel - RE: [PATCH] clk: Add functions to get optional 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <153255822286.48062.3193076486782567960@swboyd.mtv.corp.google.com>
Date:   Wed, 25 Jul 2018 15:37:02 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Phil Edworthy <phil.edworthy@...esas.com>,
        Russell King <linux@...linux.org.uk>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Simon Horman <horms@...ge.net.au>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH] clk: Add functions to get optional clocks

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.