linux-kernel - Re: [PATCH] regulator: core: resolve supply voltage deferral silently

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

Message-ID: <20210901150840.GF5976@sirena.org.uk>
Date:   Wed, 1 Sep 2021 16:08:40 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Chen-Yu Tsai <wenst@...omium.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: core: resolve supply voltage deferral silently

On Thu, Aug 26, 2021 at 12:40:17PM -0700, Brian Norris wrote:

>  		if (current_uV < 0) {
> -			rdev_err(rdev,
> -				 "failed to get the current voltage: %pe\n",
> -				 ERR_PTR(current_uV));
> +			if (current_uV != -EPROBE_DEFER)
> +				rdev_err(rdev,
> +					 "failed to get the current voltage: %pe\n",
> +					 ERR_PTR(current_uV));

This doesn't make sense to me.  Why are we getting as far as trying to
read the voltage if we've been told to defer probe?  This suggests that
we ought to be doing this earlier on.  I see that the logic is already
there to handle a deferral being generated here but it looks off.

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