| Message ID | 20190121183723.25231-2-martin.blumenstingl@googlemail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | pwm-regulator: reduce noise on EPROBE_DEFER | expand |
Hi Martin, On Tue, 22 Jan 2019 at 00:07, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Suppress the "Failed to get PWM" error output if the actual error code > is EPROBE_DEFER. This makes the behavior of the pwm-regulator driver > consistent with what most other drivers do (which is: print all errors > except EPROBE_DEFER). > > An example where this cleans up the kernel log are the 32-bit Amlogic > Meson boards: > multi_v7_defconfig has CONFIG_REGULATOR_PWM=y and CONFIG_PWM_MESON=m. > When booting such a board (for example the Meson8b Odroid-C1) the > following message is printed five times during boot: > pwm-regulator regulator-vcck: Failed to get PWM: -517 > On the sixth call the pwm-meson driver is finally loaded (as rootfs > becomes ready) and the "VCCK" pwm-regulator comes up fine. > > Fixes: aa66cc6630a408 ("regulator: pwm-regulator: get voltage and duty table from dts") > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > --- > drivers/regulator/pwm-regulator.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c > index 3f53f9134b32..7789d181ae67 100644 > --- a/drivers/regulator/pwm-regulator.c > +++ b/drivers/regulator/pwm-regulator.c > @@ -357,7 +357,9 @@ static int pwm_regulator_probe(struct platform_device *pdev) > drvdata->pwm = devm_pwm_get(&pdev->dev, NULL); > if (IS_ERR(drvdata->pwm)) { > ret = PTR_ERR(drvdata->pwm); > - dev_err(&pdev->dev, "Failed to get PWM: %d\n", ret); > + if (ret != -EPROBE_DEFER) > + dev_err(&pdev->dev, "Failed to get PWM: %d\n", ret); > + > return ret; > } > > -- > 2.20.1 > Please add my. tested on Odroid c1+ Tested-by: Anand Moon <linux.amoon@gmail.com> Best Regards -Anand > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic
On Mon, Jan 21, 2019 at 07:37:23PM +0100, Martin Blumenstingl wrote: > Suppress the "Failed to get PWM" error output if the actual error code > is EPROBE_DEFER. This makes the behavior of the pwm-regulator driver > consistent with what most other drivers do (which is: print all errors > except EPROBE_DEFER). > > An example where this cleans up the kernel log are the 32-bit Amlogic > Meson boards: > multi_v7_defconfig has CONFIG_REGULATOR_PWM=y and CONFIG_PWM_MESON=m. This also cleans up the kernel log in the case where you've not got a driver enabled that you need (or it's not loading for some reason) which isn't super helpful when you're trying to figure out why the driver won't probe. There's not even anything at debug level, that would probably be fine. The ideal thing here would be to work on setting up the dependency information based on DT and using that to try to sort initialization order so we try things in an order that minimizes the number of failed tries.
On 2019-01-23 16:04, Mark Brown wrote: > On Mon, Jan 21, 2019 at 07:37:23PM +0100, Martin Blumenstingl wrote: >> Suppress the "Failed to get PWM" error output if the actual error code >> is EPROBE_DEFER. This makes the behavior of the pwm-regulator driver >> consistent with what most other drivers do (which is: print all errors >> except EPROBE_DEFER). >> >> An example where this cleans up the kernel log are the 32-bit Amlogic >> Meson boards: >> multi_v7_defconfig has CONFIG_REGULATOR_PWM=y and CONFIG_PWM_MESON=m. > > This also cleans up the kernel log in the case where you've not got a > driver enabled that you need (or it's not loading for some reason) > which > isn't super helpful when you're trying to figure out why the driver > won't probe. There's not even anything at debug level, that would > probably be fine. > > The ideal thing here would be to work on setting up the dependency > information based on DT and using that to try to sort initialization > order so we try things in an order that minimizes the number of failed > tries. Hmm, would it be useful to have a devfs file which holds the last probe code?
On Wed, Jan 23, 2019 at 04:14:49PM +0000, Ben Dooks wrote: > On 2019-01-23 16:04, Mark Brown wrote: > > This also cleans up the kernel log in the case where you've not got a > > driver enabled that you need (or it's not loading for some reason) which > > isn't super helpful when you're trying to figure out why the driver > > won't probe. There's not even anything at debug level, that would > > probably be fine. > > The ideal thing here would be to work on setting up the dependency > > information based on DT and using that to try to sort initialization > > order so we try things in an order that minimizes the number of failed > > tries. > Hmm, would it be useful to have a devfs file which holds the last probe > code? You really also want the bit that says why it's deferring - "failed to get clock X" or whatever.
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c index 3f53f9134b32..7789d181ae67 100644 --- a/drivers/regulator/pwm-regulator.c +++ b/drivers/regulator/pwm-regulator.c @@ -357,7 +357,9 @@ static int pwm_regulator_probe(struct platform_device *pdev) drvdata->pwm = devm_pwm_get(&pdev->dev, NULL); if (IS_ERR(drvdata->pwm)) { ret = PTR_ERR(drvdata->pwm); - dev_err(&pdev->dev, "Failed to get PWM: %d\n", ret); + if (ret != -EPROBE_DEFER) + dev_err(&pdev->dev, "Failed to get PWM: %d\n", ret); + return ret; }
Suppress the "Failed to get PWM" error output if the actual error code is EPROBE_DEFER. This makes the behavior of the pwm-regulator driver consistent with what most other drivers do (which is: print all errors except EPROBE_DEFER). An example where this cleans up the kernel log are the 32-bit Amlogic Meson boards: multi_v7_defconfig has CONFIG_REGULATOR_PWM=y and CONFIG_PWM_MESON=m. When booting such a board (for example the Meson8b Odroid-C1) the following message is printed five times during boot: pwm-regulator regulator-vcck: Failed to get PWM: -517 On the sixth call the pwm-meson driver is finally loaded (as rootfs becomes ready) and the "VCCK" pwm-regulator comes up fine. Fixes: aa66cc6630a408 ("regulator: pwm-regulator: get voltage and duty table from dts") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- drivers/regulator/pwm-regulator.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)