linux-kernel - Re: [PATCH AUTOSEL 5.12 32/63] ASoC: cs43130: handle errors in cs43130

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] [day] [month] [year] [list]

Message-ID: <YK13izCA4E8Vey2h@sirena.org.uk>
Date:   Tue, 25 May 2021 23:17:47 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, alsa-devel@...a-project.org,
        patches@...nsource.cirrus.com
Subject: Re: [PATCH AUTOSEL 5.12 32/63] ASoC: cs43130: handle errors in
 cs43130_probe() properly

On Tue, May 25, 2021 at 04:43:52PM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 25, 2021 at 03:00:28PM +0100, Mark Brown wrote:
> > On Mon, May 24, 2021 at 10:45:49AM -0400, Sasha Levin wrote:
> > > From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

> > > [ Upstream commit 2da441a6491d93eff8ffff523837fd621dc80389 ]

> This is now in 5.13-rc3.

> You should have been cc:ed on it a few times already.

Hrm, I've managed to find a *single* copy mixed in with a revert
as part of a huge series (it was almost 70 patches) with no cover
letter that got copied to me - I think what happened here is that
this looked like this was something where you'd done a revert and
then dropped that revert (which was what things I'd heard from
other sources suggested was what was going on with that series).
I'd certainly have expected to get a standalone patch submission
or other communication for something that was entirely new code,
and if you're not getting review for new code like this that
isn't super urgent I'd expect some attempts to get it before
bypassing.

This sort of stuff is not great, especially when half of what you
were doing was to address bad practice on the part of the UMN
people - I would have really expected any completely new changes
like these that came up to be sent as new patches through the
normal process rather than mixed in with what look like
mechanical, treewide changes.  It's a recipe for things getting
missed, as I said in followup to the copy of the patch I found
there's some issues with the rt5645 changes.  On rechecking
everything the only issue I actually spotted with any of that
code (use of devm at the component level, which realistically is
at worst very minor) is not fixed by the additional patch.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)