linux-kernel - Re: [PATCH] regulator: core: do not report 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 17 Apr 2019 16:46:38 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>
Cc:     lgirdwood@...il.com, linux-kernel@...r.kernel.org,
        khasim.mohammed@...aro.org
Subject: Re: [PATCH] regulator: core: do not report EPROBE_DEFER as error.

On Wed, Apr 17, 2019 at 10:54:11AM +0200, Jorge Ramirez-Ortiz wrote:
> Do not log a temporary failure to get a regulator (EPROBE_DEFER) while
> the driver is requesting retries.

> -			dev_err(dev, "Failed to get supply '%s': %d\n",
> -				consumers[i].supply, ret);
> +			if (ret != -EPROBE_DEFER)
> +				dev_err(dev, "Failed to get supply '%s': %d\n",
> +					consumers[i].supply, ret);

Please leave at least a debug log in place, it's not good to just
silently fail - even if we will retry someone might still need some help
debugging (eg, figuring out that they need to enable whatever driver is
providing the supply in their config) so we should tell them why we're
deferring.

BTW does an e-mail address need updating somewhere here?

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