| Message ID | 20250313134146.27087-3-kabel@kernel.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Fixes for mv88e6xxx (mainly 6320 family) | expand |
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@kernel.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@vger.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
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 99d8d438e465..aa8ebe9d6bdc 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -5164,8 +5164,8 @@ static const struct mv88e6xxx_ops mv88e6320_ops = { .hardware_reset_pre = mv88e6xxx_g2_eeprom_wait, .hardware_reset_post = mv88e6xxx_g2_eeprom_wait, .reset = mv88e6352_g1_reset, - .vtu_getnext = mv88e6185_g1_vtu_getnext, - .vtu_loadpurge = mv88e6185_g1_vtu_loadpurge, + .vtu_getnext = mv88e6352_g1_vtu_getnext, + .vtu_loadpurge = mv88e6352_g1_vtu_loadpurge, .gpio_ops = &mv88e6352_gpio_ops, .avb_ops = &mv88e6352_avb_ops, .ptp_ops = &mv88e6352_ptp_ops, @@ -5212,8 +5212,8 @@ static const struct mv88e6xxx_ops mv88e6321_ops = { .hardware_reset_pre = mv88e6xxx_g2_eeprom_wait, .hardware_reset_post = mv88e6xxx_g2_eeprom_wait, .reset = mv88e6352_g1_reset, - .vtu_getnext = mv88e6185_g1_vtu_getnext, - .vtu_loadpurge = mv88e6185_g1_vtu_loadpurge, + .vtu_getnext = mv88e6352_g1_vtu_getnext, + .vtu_loadpurge = mv88e6352_g1_vtu_loadpurge, .gpio_ops = &mv88e6352_gpio_ops, .avb_ops = &mv88e6352_avb_ops, .ptp_ops = &mv88e6352_ptp_ops,
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@kernel.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. --- drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)