linux-kernel - Re: regulator_get_optional() no longer returning NULL?

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:   Sat, 4 Feb 2017 11:08:09 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Thierry Reding <treding@...dia.com>,
        Jelle van der Waa <jelle@...aa.nl>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: regulator_get_optional() no longer returning NULL?

On Fri, Feb 03, 2017 at 01:51:20PM -0800, Dmitry Torokhov wrote:

> Like I said, I want people to simply check for error/!error and have all
> errors be fatal, and the rest of the checks (when trying to use said
> regulator) should be in form of:

> 	if (blah->supply)
> 		regulator_enable(supply).

I am very dubious about this sort of pattern, it's fairly rare to get
optional supplies at all and when they're there they tend to be more
clearly described at a higher level than just checking for the
regulator.

> Or even teach regulator_enable() to like NULLs.

We definitely should not do this, we already have far too many problems
with people not writing appropriate error handling code and this just
encourages the "we got an error, set the regulator to NULL" behaviour
that seems to go along with this.  For most of the reasonable use cases
we need explicit handling for the case where the regulator isn't there
so it's not particularly optimising anything.

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