linux-kernel - Re: [PATCH 3/9] clk: meson: axg-audio: Don't reference clk_init

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1j1rxxoz7q.fsf@starbuckisacylon.baylibre.com>
Date:   Wed, 07 Aug 2019 15:57:13 +0200
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Neil Armstrong <narmstrong@...libre.com>
Subject: Re: [PATCH 3/9] clk: meson: axg-audio: Don't reference clk_init_data after registration

On Tue 06 Aug 2019 at 14:48, Stephen Boyd <sboyd@...nel.org> wrote:

> Quoting Jerome Brunet (2019-08-06 01:49:47)
>> On Wed 31 Jul 2019 at 12:35, Stephen Boyd <sboyd@...nel.org> wrote:
>> 
>> > A future patch is going to change semantics of clk_register() so that
>> > clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid
>> > referencing this member here so that we don't run into NULL pointer
>> > exceptions.
>> 
>> Hi Stephen,
>> 
>> What to do you indend to do with this one ? Will you apply directly or
>> should we take it ?
>
> I said below:
>
>  Please ack so I can take this through clk tree
>

Missed it, sorry.

>> 
>> We have several changes for the controller which may conflict with this
>> one. It is nothing major but the sooner I know how this changes goes in,
>> the sooner I can rebase the rest.
>
> Will it conflict? I can deal with conflicts.

I'll check to be sure and notify you in the PR if necessary

>
>> 
>> Also, We were (re)using the init_data only on register failures.
>> I understand that you want to guarantee .init is NULL when the clock is
>> registered, but it this particular case, the registeration failed so the
>> clock is not registered.
>> 
>> IMO, it would be better if devm_clk_hw_register() left the init_data
>> untouched if the registration fails.
>
> Do you have other usage of the init_data besides printing out the
> name?

No other use

> I think we could have devm_clk_hw_register() print out the name of the
> clk that failed to register instead, and get rid of more code in drivers
> that way.

Sure, why not.

> Unless of course there are other uses of the init struct?

I was just commenting on the fact that initialization function tends to
rollback what they can in case of failures, usually.

>
>> 
>> >
>> > Cc: Neil Armstrong <narmstrong@...libre.com>
>> > Cc: Jerome Brunet <jbrunet@...libre.com>
>> > Signed-off-by: Stephen Boyd <sboyd@...nel.org>
>> > ---
>> >
>> > Please ack so I can take this through clk tree
>> >
>> >  drivers/clk/meson/axg-audio.c | 7 +++++--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >