linux-kernel - Re: [GIT PULL] pin control changes for v6.13

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: <Z0R7iGP-0cQwmY7A@sashalap>
Date: Mon, 25 Nov 2024 08:28:40 -0500
From: Sasha Levin <sashal@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] pin control changes for v6.13

On Mon, Nov 25, 2024 at 09:48:59AM +0100, Linus Walleij wrote:
>On Sun, Nov 24, 2024 at 5:55 PM Sasha Levin <sashal@...nel.org> wrote:
>
>> I've just hit the issue you've described in this PR:
>(...)
>> Is effectively a revert of one of the commits that are part of this PR:
>>
>> >      pinctrl: aw9523: add missing mutex_destroy
>>
>> Would it make more sense to just re-do this PR without the offending
>> commit? I understand that this is a fairly small fixup, but I'm
>> concerned that this will just create confusion later on...
>
>I don't follow what you mean I should do. The offending commit is a
>fix and it is already upstream since -rc4.

Oh, there's something off in the PR itself: it lists "pinctrl: aw9523:
add missing mutex_destroy" as a commit that is included in this PR, but
really it's already upstream.

Sorry, I got confused by that.

>Torvalds could probably fix the issue by simply reverting
>393c554093c0c4cbc8e2f178d36df169016384da
>instead of applying the fixup though, it has the same textual and
>semantic effect. I just tested it and it works fine.
>
>^Torvalds: looks like revert on top is a better idea than fixups
>so we don't upset the stable maintainer scripts.

Yes, a revert would be nicer as it'll make sure we can easily get it to
older stable trees.

-- 
Thanks,
Sasha