[<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