linux-kernel - Re: [PATCH 3/3] regulator: core: make regulator_register() EPROBE

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]

Date:   Wed, 18 Sep 2019 17:08:42 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Marco Felsch <m.felsch@...gutronix.de>, zhang.chunyan@...aro.org,
        Doug Anderson <dianders@...omium.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        ckeepax@...nsource.cirrus.com, lkml <linux-kernel@...r.kernel.org>,
        Sascha Hauer <kernel@...gutronix.de>
Subject: Re: [PATCH 3/3] regulator: core: make regulator_register()
 EPROBE_DEFER aware

On Wed, Sep 18, 2019 at 08:53:40AM -0700, Dmitry Torokhov wrote:
> On Wed, Sep 18, 2019 at 1:18 AM Marco Felsch <m.felsch@...gutronix.de> wrote:

> > Those errors are handled but the behaviour of this funciton is to return
> > NULL in such errors which is fine for the caller of this function. I
> > only want to handle EPROBE_DEFER special..

> And I am saying it is wrong to handle only EPROBE_DEFER.
> regulator_of_get_init_data() should always return ERR_PTR()-encoded
> error code when parsing callback returns error, so that regulator core
> does not mistakenly believe that there is no configuration/init data
> when in fact there is, but we failed to handle it properly.

> IOW I'm advocating for extending you patch so that it reads:

> +               ret = desc->of_parse_cb(child, desc, config);
> +               if (ret) {
> +                       of_node_put(child);
> +                       return ERR_PTR(ret);
> +               }

> Thanks.

That's a more invasive change and we do have a fallback after DT for
configuration passed in when the regulator is registered, we want to
distinguish between the valid case where there just wasn't anything
there and the error case where we found something but it wasn't parsable
which is always a bit annoying to do.  The logic around this could
really do with a bigger refactoring TBH.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)