Do not log a temporary failure to get a regulator (EPROBE_DEFER) while
the driver is requesting retries.
Signed-off-by: Jorge Ramirez-Ortiz <[email protected]>
---
drivers/regulator/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 186a37675b50..0ca18bbdcd32 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4342,8 +4342,9 @@ 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);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get supply '%s': %d\n",
+ consumers[i].supply, ret);
consumers[i].consumer = NULL;
goto err;
}
--
2.21.0
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?
On 4/17/19 17:46, Mark Brown wrote:
> 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.
you mean replacing dev_err with dev_dbg on all cases or only on defer
leaving dev_err on the rest?
>
> BTW does an e-mail address need updating somewhere here?
>
dont know, whose email? I got these from get_maintainer.pl (below); or
are you referring to mine (in which case it is correct, I am back at
least for a bit longer)
Liam Girdwood <[email protected]> (supporter:VOLTAGE AND CURRENT
REGULATOR FRAMEWORK)
Mark Brown <[email protected]> (supporter:VOLTAGE AND CURRENT REGULATOR
FRAMEWORK)
[email protected] (open list:VOLTAGE AND CURRENT REGULATOR
FRAMEWORK)
On Wed, Apr 17, 2019 at 07:05:52PM +0200, Jorge Ramirez wrote:
> On 4/17/19 17:46, Mark Brown wrote:
> > 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.
> you mean replacing dev_err with dev_dbg on all cases or only on defer
> leaving dev_err on the rest?
Only on defer.
> > BTW does an e-mail address need updating somewhere here?
> dont know, whose email? I got these from get_maintainer.pl (below); or
> are you referring to mine (in which case it is correct, I am back at
> least for a bit longer)
It was yours - you didn't show up in meet the team yet so I wasn't clear
if it was just an old patch where the e-mail address had been copied
over.