linux-kernel - Re: Applied "regulator: core: do not report EPROBE_DEFER as error but as debug" to the regulator tree

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: <1f14ee5a-3ea3-9d15-d148-dadee20ddcca@linaro.org>
Date:   Tue, 23 Apr 2019 11:49:16 +0200
From:   Jorge Ramirez <jorge.ramirez-ortiz@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     khasim.mohammed@...aro.org, lgirdwood@...il.com,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Applied "regulator: core: do not report EPROBE_DEFER as error but
 as debug" to the regulator tree

On 4/18/19 12:26, Mark Brown wrote:
> The patch
> 
>    regulator: core: do not report EPROBE_DEFER as error but as debug
> 
> has been applied to the regulator tree at
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.2


hi Mark, I cant find the commit in the tree. Can you check if it was merged?



> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
>>>From 317f0111220921e87a168e4e6cec275df4e9be01 Mon Sep 17 00:00:00 2001
> From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>
> Date: Wed, 17 Apr 2019 21:24:43 +0200
> Subject: [PATCH] regulator: core: do not report EPROBE_DEFER as error but as
>  debug
> 
> Temporary failures to get a regulator (EPROBE_DEFER) should be logged
> as debug information instead of errors.
> 
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  drivers/regulator/core.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 5a9ebcf7fe7a..08ccabe07fe3 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -4345,8 +4345,6 @@ int regulator_bulk_get(struct device *dev, int num_consumers,
>  						      consumers[i].supply);
>  		if (IS_ERR(consumers[i].consumer)) {
>  			ret = PTR_ERR(consumers[i].consumer);
> -			dev_err(dev, "Failed to get supply '%s': %d\n",
> -				consumers[i].supply, ret);
>  			consumers[i].consumer = NULL;
>  			goto err;
>  		}
> @@ -4355,6 +4353,13 @@ int regulator_bulk_get(struct device *dev, int num_consumers,
>  	return 0;
>  
>  err:
> +	if (ret != -EPROBE_DEFER)
> +		dev_err(dev, "Failed to get supply '%s': %d\n",
> +			consumers[i].supply, ret);
> +	else
> +		dev_dbg(dev, "Failed to get supply '%s', deferring\n",
> +			consumers[i].supply);
> +
>  	while (--i >= 0)
>  		regulator_put(consumers[i].consumer);
>  
>