summaryrefslogtreecommitdiff
path: root/drivers/clocksource/timer-ti-dm-systimer.c
diff options
context:
space:
mode:
authorTobias Waldekranz <tobias@waldekranz.com>2020-11-12 12:43:35 +0100
committerJakub Kicinski <kuba@kernel.org>2020-11-14 11:29:29 -0800
commit92307069a96c07d9b6e74b96b79390e7cd7d2111 (patch)
tree41df17d4f2f2704667320fc09e46ac0e60c1c413 /drivers/clocksource/timer-ti-dm-systimer.c
parent37344718bd7032639a02053e06b51697f90154ce (diff)
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>
Diffstat (limited to 'drivers/clocksource/timer-ti-dm-systimer.c')
0 files changed, 0 insertions, 0 deletions