netdev - Re: [PATCH net 02/13] net: dsa: mv88e6xxx: fix VTU methods for 6320 family

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2e88876c-0d08-464a-89e9-75e2fd597022@lunn.ch>
Date: Thu, 13 Mar 2025 15:33:00 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Marek Behún <kabel@...nel.org>
Cc: Vladimir Oltean <olteanv@...il.com>,
	"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
	Vivien Didelot <vivien.didelot@...il.com>,
	Tobias Waldekranz <tobias@...dekranz.com>, netdev@...r.kernel.org,
	Lev Olshvang <lev_o@....com>
Subject: Re: [PATCH net 02/13] net: dsa: mv88e6xxx: fix VTU methods for 6320
 family

On Thu, Mar 13, 2025 at 02:41:35PM +0100, Marek Behún wrote:
> The VTU registers of the 6320 family use the 6352 semantics, not 6185.
> Fix it.
> 
> Fixes: b8fee9571063 ("net: dsa: mv88e6xxx: add VLAN Get Next support")
> Signed-off-by: Marek Behún <kabel@...nel.org>
> ---
> This bug goes way back to 2015 to commit b8fee9571063 ("net: dsa:
> mv88e6xxx: add VLAN Get Next support") where mv88e6xxx_vtu_getnext() was
> first implemented: the check for whether the switch has STU did not
> contain the 6320 family.
> 
> Therefore I put that commit into the Fixes tag.
> 
> But the driver was heavily refactored since then, and the actual commits
> that this patch depends on are
>   f1394b78a602 ("net: dsa: mv88e6xxx: add VTU GetNext operation")
>   0ad5daf6ba80 ("net: dsa: mv88e6xxx: add VTU Load/Purge operation")
> But I don't know how to declare it properly.
> Using the "Cc: stable" method with these commits tagged would mean they
> should be cherry-picked, but these commits in turn depend on other
> changes in the driver.

What happens when you try to cherry-pick this patch back to
b8fee9571063. If it explodes with all sorts of conflicts, whoever is
doing the backport will quickly give up and report the backport
failed. You can then step in and provide a backported version for a
particular stable kernel.

Or you can extend the Cc: stable:

Cc: <stable@...r.kernel.org> # 3.3.x

Anybody backporting the patch should not go further back than 3.3.x,
but the Fixes tag indicates older versions are broken, which is useful
knowledge to hit people over the head with when they refuse to update
to the latest LTS.

	Andrew