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: <Z0NaYhtZy89ObgmR@sashalap>
Date: Sun, 24 Nov 2024 11:54:58 -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

Hi Linus,

I've just hit the issue you've described in this PR:

On Sat, Nov 23, 2024 at 05:23:26PM +0100, Linus Walleij wrote:
>- The second issue is more sneaky: a recent fixup patch to one
>   of the rc:s (I think -rc4) fixed some error path bugs in
>   the AW9523 driver, then a patch to the regular devel is
>   improving the use of devres so the fixed errorpath fixes
>   things broken.
>
>I have been applying the following fixup patch for -next to work:

And realized that that proposed fixup:

>diff --git a/drivers/pinctrl/pinctrl-aw9523.c b/drivers/pinctrl/pinctrl-aw9523.c
>index ebd590a3cec6..90059b0d20e5 100644
>--- a/drivers/pinctrl/pinctrl-aw9523.c
>+++ b/drivers/pinctrl/pinctrl-aw9523.c
>@@ -983,11 +983,8 @@ static int aw9523_probe(struct i2c_client *client)
>        lockdep_set_subclass(&awi->i2c_lock,
>i2c_adapter_depth(client->adapter));
>
>        pdesc = devm_kzalloc(dev, sizeof(*pdesc), GFP_KERNEL);
>-       if (!pdesc) {
>-               ret = -ENOMEM;
>-               goto err_disable_vregs;
>-       }
>-
>+       if (!pdesc)
>+               return -ENOMEM;
>        ret = aw9523_hw_init(awi);
>        if (ret)
>                return ret;
>
>This can be folded in as an "evil merge" or applied separately on
>top, your pick.

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

-- 
Thanks,
Sasha