linux-kernel - Re: [PATCH] mux: mmio: Do not use syscon helper to build regmap

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: <20250124143301.om526lwkvcw2hmq5@shaping>
Date: Fri, 24 Jan 2025 08:33:01 -0600
From: Nishanth Menon <nm@...com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: Andrew Davis <afd@...com>, Peter Rosin <peda@...ntia.se>,
        Vignesh
 Raghavendra <vigneshr@...com>, <linux-kernel@...r.kernel.org>,
        "Rob Herring
 (Arm)" <robh@...nel.org>, Lee Jones <lee@...nel.org>
Subject: Re: [PATCH] mux: mmio: Do not use syscon helper to build regmap

On 06:26-20250124, Greg Kroah-Hartman wrote:
[...]
> > Greg, Peter,
> > 
> > This is part of the fixes TI K3 platforms boot issues reported in
> > https://lore.kernel.org/all/b2413460-ec8b-4c77-99b8-4c32b262439a@ti.com/
> > on the latest linus master v6.13-5001-gd0d106a2bd21 + linux
> > next-20250123
> > 
> > Total set of patches tested with:
> > https://lore.kernel.org/all/20250119182121.3956546-1-vaishnav.a@ti.com/
> > https://lore.kernel.org/r/20250123181726.597144-1-afd@ti.com
> > https://lore.kernel.org/r/20250123181913.597304-1-afd@ti.com
> > https://lore.kernel.org/r/20250123182059.597491-1-afd@ti.com
> > https://lore.kernel.org/r/20250123182234.597665-1-afd@ti.com
> > 
> > Could we get this routed to master as fixes asap please to get a sane 6.14?
> 
> Our trees are of course closed right now due to the merge window, you
> know that :)

Yes, of course.

> 
> So we can take things after -rc1 is out, and route bugfixes for
> 6.14-final and new stuff for 6.15-rc1, like always.  It's hard to see
> that this is just a bugfix, but if it is, it needs a Fixes: tag at the
> very least, right?

I am not entirely sure which commit to use for fixes.

On one hand, we can use
https://lore.kernel.org/all/b2413460-ec8b-4c77-99b8-4c32b262439a@ti.com/
as the cause of the Fixes. Since, the change in behavior of the subsystem late
in the merge cycle caused this side effect, but, we could argue that
this patch fixes the subsystem for it's intended behavior and
unfortunately exposed issues in users of the syscon subsystem depending
on the "wrong" behavior.

OR

The code introduced long back which depended on the older syscon
behavior. but, then, we can argue that it was working fine at that
point.. and if we cherry-pick the fixup for stable, it is probably
inaccurate for the syscon behavior in older kernels?

Lee, Rob: Could you chime in with your suggestion?

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D