linux-kernel - Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200622144402.GH1931@sasha-vm>
Date:   Mon, 22 Jun 2020 10:44:02 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Dmitry Osipenko <digetx@...il.com>,
        alsa-devel@...a-project.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support
 nvidia, headset property

On Mon, Jun 22, 2020 at 02:27:57PM +0100, Mark Brown wrote:
>On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote:
>> On Mon, Jun 22, 2020 at 12:23:21PM +0100, Mark Brown wrote:
>
>> > That's concerning - please don't do this.  It's not what stable is
>> > expected to be and there's no guarantee that you're getting all the
>> > changes required to actually make things work.
>
>> How come? This is one of the things stable rules explicitly call for:
>> "New device IDs and quirks are also accepted".
>
>I would expect that to be data only additions, I would not expect that
>to be adding new code.

These come hand in hand. Take a look at the more complex cases such as
sound/pci/hda/patch_*

>> If we're missing anything, the solution is to make sure we stop missing
>> it rather than not take anything to begin with :)
>
>It would be much better to not have to watch stable constantly like we
>currently do - we're seeing people report breakage often enough to be a
>concern as things are, we don't need to be trying to pile extra stuff in
>there because there's some keywords in a changelog or whatever.  The
>testing coverage for drivers is weak, increasing the change rate puts
>more stress on that.

Shouldn't we instead improve testing here? nvidia for example already
provides Tegra testing for stable releases, if the coverage isn't
sufficient then let's work on making it better.

-- 
Thanks,
Sasha