linux-kernel - Re: [RFC 00/19] clk: imx: Switch the imx6 and imx7 to clk

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:   Tue, 23 Apr 2019 14:49:59 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Abel Vesa <abel.vesa@....com>, Fabio Estevam <festevam@...il.com>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Fabio Estevam <fabio.estevam@....com>,
        Aisheng Dong <aisheng.dong@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 00/19] clk: imx: Switch the imx6 and imx7 to clk_hw based API

Quoting Stephen Boyd (2019-04-10 15:00:07)
> Quoting Fabio Estevam (2019-03-22 09:24:54)
> > Hi Abel,
> > 
> > On Fri, Mar 22, 2019 at 12:37 PM Abel Vesa <abel.vesa@....com> wrote:
> > >
> > > This work is part of the effort of switching the entire imx clock drivers
> > > towards clk_hw based API. In order to do that, we have to keep the old
> > 
> > Maybe I missed some earlier discussions on this topic, but let me ask
> > a fundamental question first: what is the motivation for this API
> > change?
> > 
> > I could not find the reasoning inside the series.
> 
> The reasoning should be added to the series, but I would like to see clk
> providers only deal with clk_hw structures and not with clk structures.
> This clearly divides the line between clk consumers and clk providers so
> that we know if clk providers are using the clk API themselves. That's
> why I introduced clk_hw_register() in the first place.
> 

FYI, I'm dropping this from my review queue under the assumption it will
be sent again. Also, it would be nice to not have the wrappers at all in
the next series so that everything is clk_hw based instead of clk based.
Otherwise, it looks good to me and I'd like to see this work completed.
Thanks!