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]
Message-ID: <154117473137.88331.9628947623071045450@swboyd.mtv.corp.google.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ