Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 6 Sep 2019 14:29:17 -0400
From:   Sasha Levin <sashal@kernel.org>
To:     Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mark Brown <broonie@kernel.org>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org
Subject: Re: revert: ASoC: Fail card instantiation if DAI format setup fails
Message-ID: <20190906182917.GA1528@sasha-vm>
References: <alpine.DEB.2.20.1909061658580.3985@lnxricardw1.se.axis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1909061658580.3985@lnxricardw1.se.axis.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Sep 06, 2019 at 05:00:28PM +0200, Ricard Wanderlof wrote:
>
>Sorry for the repost, I relized I stupidly got Greg's email adress wrong
>first time around.
>
>> > On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
>> > > On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
>> > > > On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
>> > >
>> > > > > > If the DAI format setup fails, there is no valid communication format
>> > > > > > between CPU and CODEC, so fail card instantiation, rather than
>> > > > continue
>> > > > > > with a card that will most likely not function properly.
>> > >
>> > > > > This is another one where if nobody noticed a problem already and things
>> > > > > just happened to be working this might break things, it's vanishingly
>> > > > > unlikely to fix anything that was broken.
>> > >
>> > > > Same as the other patch: this patch suggests it fixes a real bug, and if
>> > > > this patch is broken let's fix it.
>> > >
>> > > If anyone ran into this on the older kernel and fixed or worked
>> > > around it locally there's a reasonable chance this will then
>> > > break what they're doing.  The patch itself is perfectly fine but
>
>(Sorry about the mangled subject line, I'd accidentally deleted the
>original message from my inbox.)
>
>I'm a bit bewildered here. As the author of the original patch I'm of
>course biased, and I can certainly understand the patch being dropped from
>existing release branches, since as Mark correctly states, it does not fix
>any broken behavior and might even break things that happen to work by
>chance.
>
>But is this being dropped from the master branch as well? To me it makes
>the kernel behave in an inconsistent way, first reporting a failure to
>instantiate a specific sound card in the kernel log, but then seemingly
>bringing it up anyway.

Hi Richard,

This patch is only dropped from the stable branches, it still remains in
the mainline branch.

--
Thanks,
Sasha