#
9e3d9ae5 |
|
09-Dec-2022 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: mv88e6xxx: replace VTU violation prints with trace points It is possible to trigger these VTU violation messages very easily, it's only necessary to send packets with an unknown VLAN ID to a port that belongs to a VLAN-aware bridge. Do a similar thing as for ATU violation messages, and hide them in the kernel's trace buffer. New usage model: $ trace-cmd list | grep mv88e6xxx mv88e6xxx mv88e6xxx:mv88e6xxx_vtu_miss_violation mv88e6xxx:mv88e6xxx_vtu_member_violation $ trace-cmd report Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Saeed Mahameed <saeed@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
49c98c1d |
|
16-Mar-2022 |
Tobias Waldekranz <tobias@waldekranz.com> |
net: dsa: mv88e6xxx: Disentangle STU from VTU In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states were kept in the VTU - there was no concept of a SID. Later, the information was split into two tables, where the VTU only tracked memberships and deferred the STP state tracking to the STU via a pointer (SID). This meant that a group of VLANs could share the same STU entry. Most likely, this was done to align with MSTP (802.1Q-2018, Clause 13), which is built on this principle. While the VTU is still 4k lines on most devices, the STU is capped at 64 entries. This means that the current stategy, updating STU info whenever a VTU entry is updated, can not easily support MSTP because: - The maximum number of VIDs would also be capped at 64, as we would have to allocate one SID for every VTU entry - even if many VLANs would effectively share the same MST. - MSTP updates would be unnecessarily slow as you would have to iterate over all VLANs that share the same MST. In order to support MSTP offloading in the future, manage the STU as a separate entity from the VTU. Only add support for newer hardware with separate VTU and STU. VTU-only devices can also be supported, but essentially this requires a software implementation of an STU (fanning out state changed to all VLANs tied to the same MST). Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
bb03b280 |
|
03-Feb-2022 |
Tobias Waldekranz <tobias@waldekranz.com> |
net: dsa: mv88e6xxx: Support policy entries in the VTU A VTU entry with policy enabled is used in combination with a port's VTU policy setting to override normal switching behavior for frames assigned to the entry's VID. A typical example is to Treat all frames in a particular VLAN as control traffic, and trap them to the CPU. In which case the relevant user port's VTU policy would be set to TRAP. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b28f3f3c |
|
25-Jan-2021 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: use mv88e6185_g1_vtu_loadpurge() for the 6250 Apart from the mask used to get the high bits of the fid, mv88e6185_g1_vtu_loadpurge() and mv88e6250_g1_vtu_loadpurge() are identical. Since the entry->fid passed in should never exceed the number of databases, we can simply use the former as-is as replacement for the latter. Suggested-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
67c9ed1c |
|
25-Jan-2021 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: use mv88e6185_g1_vtu_getnext() for the 6250 mv88e6250_g1_vtu_getnext is almost identical to mv88e6185_g1_vtu_getnext, except for the 6250 only having 64 databases instead of 256. We can reduce code duplication by simply masking off the extra two garbage bits when assembling the fid from VTU op [3:0] and [11:8]. Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Tested-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
87fe0436 |
|
15-Jan-2021 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Tested-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
92307069 |
|
11-Nov-2020 |
Tobias Waldekranz <tobias@waldekranz.com> |
net: dsa: mv88e6xxx: Avoid VTU corruption on 6097 As soon as you add the second port to a VLAN, all other port membership configuration is overwritten with zeroes. The HW interprets this as all ports being "unmodified members" of the VLAN. In the simple case when all ports belong to the same VLAN, switching will still work. But using multiple VLANs or trying to set multiple ports as tagged members will not work. On the 6352, doing a VTU GetNext op, followed by an STU GetNext op will leave you with both the member- and state- data in the VTU/STU data registers. But on the 6097 (which uses the same implementation), the STU GetNext will override the information gathered from the VTU GetNext. Separate the two stages, parsing the result of the VTU GetNext before doing the STU GetNext. We opt to update the existing implementation for all applicable chips, as opposed to creating a separate callback for 6097, because although the previous implementation did work for (at least) 6352, the datasheet does not mention the masking behavior. Fixes: ef6fcea37f01 ("net: dsa: mv88e6xxx: get STU entry on VTU GetNext") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Link: https://lore.kernel.org/r/20201112114335.27371-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
ca4d632a |
|
09-Nov-2020 |
Tobias Waldekranz <tobias@waldekranz.com> |
net: dsa: mv88e6xxx: Export VTU as devlink region Export the raw VTU data and related registers in a devlink region so that it can be inspected from userspace and compared to the current bridge configuration. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201109082927.8684-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
8ddf0b56 |
|
06-Jan-2020 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Unique ATU and VTU IRQ names Dynamically generate a unique interrupt name for the VTU and ATU, based on the device name. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
19fb7f69 |
|
09-Aug-2019 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: introduce wait bit routine Many portions of the driver need to wait until a given bit is set or cleared. Some busses even have a specific implementation for this operation. In preparation for such variant, implement a generic Wait Bit routine that can be used by the driver core functions. This allows us to get rid of the custom implementations we may find in the driver. Note that for the EEPROM bits, BUSY and RUNNING bits are independent, thus it is more efficient to wait independently for each bit instead of waiting for their mask. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c9acece0 |
|
20-Jun-2019 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: introduce helpers for handling chip->reg_lock This is a no-op that simply moves all locking and unlocking of ->reg_lock into trivial helpers. I did that to be able to easily add some ad hoc instrumentation to those helpers to get some information on contention and hold times of the mutex. Perhaps others want to do something similar at some point, so this frees them from doing the 'sed -i' yoga, and have a much smaller 'git diff' while fiddling. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e41d4bc5 |
|
19-Jun-2019 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: fix shift of FID bits in mv88e6250_g1_vtu_loadpurge() The comment is correct, but the code ends up moving the bits four places too far, into the VTUOp field. Fixes: bec8e5725281 (net: dsa: mv88e6xxx: implement vtu_getnext and vtu_loadpurge for mv88e6250) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
48620e34 |
|
19-Jun-2019 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: fix shift of FID bits in mv88e6185_g1_vtu_loadpurge() The comment is correct, but the code ends up moving the bits four places too far, into the VTUOp field. Fixes: 11ea809f1a74 (net: dsa: mv88e6xxx: support 256 databases) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
bec8e572 |
|
04-Jun-2019 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
net: dsa: mv88e6xxx: implement vtu_getnext and vtu_loadpurge for mv88e6250 These are almost identical to the 6185 variants, but have fewer bits for the FID. Bit 10 of the VTU_OP register (offset 0x05) is the VidPolicy bit, which one should probably preserve in mv88e6xxx_g1_vtu_op(), instead of always writing a 0. However, on the 6352 family, that bit is located at bit 12 in the VTU FID register (offset 0x02), and is always unconditionally cleared by the mv88e6xxx_g1_vtu_fid_write() function. Since nothing in the existing driver seems to know or care about that bit, it seems reasonable to not add the boilerplate to preserve it for the 6250 (which would require adding a chip-specific vtu_op function, or adding chip-quirks to the existing one). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2874c5fd |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7f20d834 |
|
28-Mar-2018 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Make VTU miss violations less spammy VTU miss violations can happen under normal conditions. Don't spam the kernel log, downgrade the output to debug level only. The statistics counter will indicate it is happening, if anybody not debugging is interested. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reported-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
65f60e45 |
|
28-Mar-2018 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Keep ATU/VTU violation statistics Count the numbers of various ATU and VTU violation statistics and return them as part of the ethtool -S statistics. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9b662a3e |
|
18-Jan-2018 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Return error from irq_find_mapping() Fix a cut/paste error. When irq_find_mapping() returns an error for the ATU or VTU interrupt, return that error, not the value of chip->device_irq. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
62eb1162 |
|
13-Jan-2018 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Decode VTU problem interrupt When there is a problem with the VTU, an interrupt can be generated. Trap this interrupt and decode the registers to determine what the problem was, then log the error. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7ec60d6e |
|
14-Jun-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: prefix Global VTU macros Prefix and document the Global VTU registers macros and give a clear 16-bit registers representation. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4d5f2ba7 |
|
02-Jun-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: rename chip header The mv88e6xxx.h is meant to contains the chip structures and data. Rename it to chip.h, as for other source/header pairs of the driver. At the same time, ensure that relative header inclusions are separated by a newline and sorted alphabetically. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
931d1822 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: add VTU support for 88E6390 The 6390 family of chips use only 2 of the 3 VTU Data registers to pack the MemberTag and PortState VLAN data. This means that they must be written or read before or after each VTU/STU operations. Implement this variant to add support for VTU with such chips. These chips have a 13th bit for the VID thus set their max_vid to 8191. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1ac75864 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: support the VTU Page bit Newer chips such as the 88E6390 have a VTU Page bit in the VTU VID register to specify a 13th bit for the VID. This can be used to support 8K VLANs. When dumping the whole VTU, all VID bits must be set to one, including this VTU Page bit. Add support for VID greater than 4095. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
bf7d71c0 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: make VTU helpers static Now that we have chip operations for VTU accesses, mark all helpers from global1_vtu.c as static. Only the various implementations of the GetNext, LoadPurge and Flush operations need to be exposed. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0ad5daf6 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: add VTU Load/Purge operation Add a new vtu_loadpurge operation to the chip info structure to differ the various implementations of the VTU accesses. Now that the STU handling is abstracted behind VTU operations, kill the obsolete MV88E6XXX_FLAG_STU flag. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f1394b78 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: add VTU GetNext operation Add a new vtu_getnext operation to the chip info structure to differ the various implementations of the VTU accesses. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ef6fcea3 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: get STU entry on VTU GetNext Now that the code reads both VTU and STU data on VTU GetNext operation, fetch the STU entry data of a VTU entry at the same time. The STU data bits are masked with the VTU data bits and they are now all read at the same time a VTU GetNext operation is issued. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
66a8e1f9 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move STU GetNext operation Extract the generic portion of code to issue an STU GetNext operation, which will be used in other implementations. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c499a64f |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move VTU Data accessors The code to access the VTU Data registers currently only supports the 88E6185 family and alike: 2-bit membership adjacent to 2-bit port state. Even though the 88E6352 family introduced an indirect table to program the VLAN Spanning Tree states, the usage of the VTU Data registers remains the same regardless the VTU or STU operation. Now that the mv88e6xxx_vtu_entry structure contains both port membership and states data, factorize the code to access them in global1_vtu.c. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f169e5ee |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move generic VTU GetNext Even though every switch model has a different way to access the VTU Data bits, the base implementation of the VTU GetNext operation remains the same: wait, write the first VID to iterate from, start the operation, and read the next VID. Move this generic implementation into global1_vtu.c and abstract the handling of the start VID (similarly to the ATU GetNext implementation), before introducing a new chip operation for specific chips. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3afb4bde |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move VTU VID accessors Add helpers to access the VTU VID register in the global1_vtu.c file. At the same time, move mv88e6xxx_g1_vtu_vid_write at the beginning of _mv88e6xxx_vtu_loadpurge, which adds no functional changes but makes future patches simpler. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d2ca1ea1 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move VTU SID accessors Add helpers to access the VTU SID register in the global1_vtu.c file. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8ee51f6b |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move VTU FID accessors Add helpers to access the VTU FID register in the global1_vtu.c file. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b486d7c9 |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move VTU flush Move the VTU flush operation to global1_vtu.c and call it from a mv88e6xxx_vtu_setup helper, similarly to the ATU and PVT setup. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
332aa5cc |
|
01-May-2017 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: move VTU Operation accessors Move the helper functions to access the Global 1 VTU Operation register to a new global1_vtu.c file, and get rid of the old underscore prefix naming convention. This file will be extended will all VTU/STU related code. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|