Hi!
This is a resend of the minor WM8994 MFD/codec driver fixes posted in
last days of the February 2020:
https://lore.kernel.org/patchwork/project/lkml/list/?series=431296
https://lore.kernel.org/patchwork/project/lkml/list/?series=431721
I hope this time the patches will find their way to mainline.
Best regards,
Marek Szyprowski
Patch summary:
Marek Szyprowski (4):
mfd: wm8994: Fix driver operation if loaded as modules
mfd: wm8994: Fix unbalanced calls to regulator_bulk_disable()
mfd: wm8994: Silence warning about supplies during deferred probe
ASoC: wm8994: Silence warnings during deferred probe
drivers/mfd/wm8994-core.c | 8 +++++++-
sound/soc/codecs/wm8994.c | 3 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
--
2.17.1
Don't confuse user with meaningless warning about the failure in getting
supplies in case of deferred probe.
Signed-off-by: Marek Szyprowski <[email protected]>
---
drivers/mfd/wm8994-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c
index 69d973ec42bf..3b2b93c5bbcb 100644
--- a/drivers/mfd/wm8994-core.c
+++ b/drivers/mfd/wm8994-core.c
@@ -393,7 +393,9 @@ static int wm8994_device_init(struct wm8994 *wm8994, int irq)
ret = regulator_bulk_get(wm8994->dev, wm8994->num_supplies,
wm8994->supplies);
if (ret != 0) {
- dev_err(wm8994->dev, "Failed to get supplies: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(wm8994->dev, "Failed to get supplies: %d\n",
+ ret);
goto err;
}
--
2.17.1
Don't confuse user with meaningless warning about the failure in getting
clocks in case of deferred probe.
Signed-off-by: Marek Szyprowski <[email protected]>
---
sound/soc/codecs/wm8994.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index 55d0b9be6ff0..7426df1f806c 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -4593,7 +4593,8 @@ static int wm8994_probe(struct platform_device *pdev)
ret = devm_clk_bulk_get_optional(pdev->dev.parent, ARRAY_SIZE(wm8994->mclk),
wm8994->mclk);
if (ret < 0) {
- dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
return ret;
}
--
2.17.1
On Mon, Apr 27, 2020 at 09:48:32AM +0200, Marek Szyprowski wrote:
> Don't confuse user with meaningless warning about the failure in getting
> clocks in case of deferred probe.
>
> Signed-off-by: Marek Szyprowski <[email protected]>
> ---
Acked-by: Charles Keepax <[email protected]>
Thanks,
Charles
On Mon, Apr 27, 2020 at 09:48:31AM +0200, Marek Szyprowski wrote:
> Don't confuse user with meaningless warning about the failure in getting
> supplies in case of deferred probe.
>
> Signed-off-by: Marek Szyprowski <[email protected]>
> ---
Acked-by: Charles Keepax <[email protected]>
Thanks,
Charles
On Mon, Apr 27, 2020 at 09:48:32AM +0200, Marek Szyprowski wrote:
> Don't confuse user with meaningless warning about the failure in getting
> clocks in case of deferred probe.
> if (ret < 0) {
> - dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
This completely eliminates the diagnostics which means that if the clock
isn't there the user is a bit stuck trying to work out what's missing.
There should still be a diagnostic.
On Mon, 27 Apr 2020, Mark Brown wrote:
> On Mon, Apr 27, 2020 at 09:48:32AM +0200, Marek Szyprowski wrote:
> > Don't confuse user with meaningless warning about the failure in getting
> > clocks in case of deferred probe.
>
> > if (ret < 0) {
> > - dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
>
> This completely eliminates the diagnostics which means that if the clock
> isn't there the user is a bit stuck trying to work out what's missing.
> There should still be a diagnostic.
The driver won't defer forever though. The final pass should fail
with a different error. At which point the error will be released to
the system log, no?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, Apr 28, 2020 at 11:36:38AM +0100, Lee Jones wrote:
> On Mon, 27 Apr 2020, Mark Brown wrote:
> > This completely eliminates the diagnostics which means that if the clock
> > isn't there the user is a bit stuck trying to work out what's missing.
> > There should still be a diagnostic.
> The driver won't defer forever though. The final pass should fail
> with a different error. At which point the error will be released to
> the system log, no?
One of the really common cases is that someone forgot to build the
driver for the dependency so it'll just defer forever waiting for
something that never loads.
On Tue, 28 Apr 2020, Mark Brown wrote:
> On Tue, Apr 28, 2020 at 11:36:38AM +0100, Lee Jones wrote:
> > On Mon, 27 Apr 2020, Mark Brown wrote:
>
> > > This completely eliminates the diagnostics which means that if the clock
> > > isn't there the user is a bit stuck trying to work out what's missing.
> > > There should still be a diagnostic.
>
> > The driver won't defer forever though. The final pass should fail
> > with a different error. At which point the error will be released to
> > the system log, no?
>
> One of the really common cases is that someone forgot to build the
> driver for the dependency so it'll just defer forever waiting for
> something that never loads.
Need to find another way to identify these failures. There are 10's
if not 100's of cases of silently returning if -EPROBE_DEFER is
caught.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Wed, Apr 29, 2020 at 08:15:53AM +0100, Lee Jones wrote:
> On Tue, 28 Apr 2020, Mark Brown wrote:
> > One of the really common cases is that someone forgot to build the
> > driver for the dependency so it'll just defer forever waiting for
> > something that never loads.
> Need to find another way to identify these failures. There are 10's
> if not 100's of cases of silently returning if -EPROBE_DEFER is
> caught.
Or someone could go through and improve the diagnostics on those cases.
Hi All,
On 27.04.2020 09:48, Marek Szyprowski wrote:
> This is a resend of the minor WM8994 MFD/codec driver fixes posted in
> last days of the February 2020:
>
> https://lore.kernel.org/patchwork/project/lkml/list/?series=431296
> https://lore.kernel.org/patchwork/project/lkml/list/?series=431721
>
> I hope this time the patches will find their way to mainline.
Gentle ping. Lee: could you queue at least the first 2 patches if you
consider the latter 2 a bit controversial?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On Mon, 27 Apr 2020, Marek Szyprowski wrote:
> Don't confuse user with meaningless warning about the failure in getting
> supplies in case of deferred probe.
>
> Signed-off-by: Marek Szyprowski <[email protected]>
> ---
> drivers/mfd/wm8994-core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog