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]
Date:   Thu, 15 Mar 2018 11:47:12 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Rajan Vaja <RAJANV@...inx.com>
Cc:     "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jolly Shah <JOLLYS@...inx.com>,
        Michal Simek <michals@...inx.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>
Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER

Quoting Rajan Vaja (2018-03-09 11:27:40)
> > From: Stephen Boyd [mailto:sboyd@...nel.org]
> > 
> > Is the intent to register the clk twice? I believe things are working as
> > intended without this patch, so maybe you can explain a little more what
> > you're trying to fix.
> [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has
> parent which is neither mentioned in output-clock-names of clock
> controller nor registered as clock provider, of_clk_init() will try to
> forcefully register in second loop. 
> 
>                         if (force || parent_ready(clk_provider->np)) {
> 
>                                 /* Don't populate platform devices */
>                                 of_node_set_flag(clk_provider->np,
>                                                  OF_POPULATED);
> 
> So registration of this DT fixed-factor clock would fail as parent
> would be NULL as below (called from _of_fixed_factor_clk_setup()):
> parent_name = of_clk_get_parent_name(node, 0);
> 
> On the other hand, even if registration failed, that node will be
> marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not
> be called and that DT fixed-factor clock would never be registered. 
> 
> Same thing is discussed at  https://lkml.org/lkml/2017/6/5/681 .

Ok. I believe the answer is to fix the DT to describe the parent chain
properly with clock-output-names. Otherwise, we have no good way of
figuring out what the name should be.

The alternative is to start working on a solution for having the clk
framework stop using strings to describe clk topology. My plan there is
to allow clk registration to indicate that another parent names array
should be used with clk_get() of the device or node pointer that's
associated with the clk during registration to find the parent . If we
had that, then we could hook up clks into the tree by calling clk_get()
in the framework and map through the clock-names property. This also
gets us to a point where clk names don't have to be globally unique,
which would be nice.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ