linux-kernel - Re: [PATCH 0/5] Implement devm_of_clk_add

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] [day] [month] [year] [list]

Date:   Fri, 02 Nov 2018 09:05:31 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Cc:     Alan Tull <atull@...nel.org>, linux-clk@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] Implement devm_of_clk_add_provider

Quoting Ricardo Ribalda Delgado (2018-11-01 23:54:50)
> Hi Stephen
> On Fri, Nov 2, 2018 at 12:35 AM Stephen Boyd <sboyd@...nel.org> wrote:
> >
> > Quoting Ricardo Ribalda Delgado (2018-11-01 07:40:39)
> > > All Tull reported that there might be a great ammount of drivers with
> > > imbalance on clk_add_provider. This is an issue for Device tree overlays
> > > (and also a bug) https://lkml.org/lkml/2018/10/18/1103
> > >
> > > This patchset implement a devm_ function of of_clk_add_provider, and
> > > fixes 3 drivers.
> > >
> > > Drivers like clk-gpio will be easily fixed with coccinelle if this set
> > > is accepted. (I volunteer, I want to learn how to use it, just seen the
> > > great presentations from Julia).
> >
> > We already have devm_of_clk_add_hw_provider(), so any instances of
> > of_clk_add_provider() should be replaced with that, instead of
> > propagating the usage of of_clk_add_provider() any further. I'll gladly
> > apply patches to convert drivers from struct clk based APIs to struct
> > clk_hw based APIs so that we can clearly split clk providers from clk
> > consumers. So if you're interested in working on some coccinelle script
> > for that it would be great!
> >
> 
> Will look into that.
> Can you take a look to 1/5 of this patchset? I believe that it is
> valid even if we do not take 2-5.

Sure. Again, that patch is combining code that we eventually want to
delete, so while it is a nice 9 line reduction, it again goes in the
wrong direction by merging two functions together that we'll want to
unmerge later when one of the functions is removed. I'd rather see
effort put into converting all drivers than merging deprecated code.