[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200429071553.GW3559@dell>
Date: Wed, 29 Apr 2020 08:15:53 +0100
From: Lee Jones <lee.jones@...aro.org>
To: Mark Brown <broonie@...nel.org>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
patches@...nsource.cirrus.com, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Charles Keepax <ckeepax@...nsource.cirrus.com>,
Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH 4/4] ASoC: wm8994: Silence warnings during deferred probe
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
Powered by blists - more mailing lists