Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29 |
|
#
a4702791 |
| 23-Apr-2024 |
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPR
net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
[ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state.
The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully.
For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on.
On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload.
Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5 |
|
#
6ccf50d4 |
| 22-Sep-2023 |
Fabio Estevam <festevam@denx.de> |
net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent
Since commit 23d775f12dcd ("net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset") the following error is seen on a imx8mn board
net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent
Since commit 23d775f12dcd ("net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset") the following error is seen on a imx8mn board with a 88E6320 switch:
mv88e6085 30be0000.ethernet-1:00: Timeout waiting for EEPROM done
This board does not have an EEPROM attached to the switch though.
This problem is well explained by Andrew Lunn:
"If there is an EEPROM, and the EEPROM contains a lot of data, it could be that when we perform a hardware reset towards the end of probe, it interrupts an I2C bus transaction, leaving the I2C bus in a bad state, and future reads of the EEPROM do not work.
The work around for this was to poll the EEInt status and wait for it to go true before performing the hardware reset.
However, we have discovered that for some boards which do not have an EEPROM, EEInt never indicates complete. As a result, mv88e6xxx_g1_wait_eeprom_done() spins for a second and then prints a warning.
We probably need a different solution than calling mv88e6xxx_g1_wait_eeprom_done(). The datasheet for 6352 documents the EEPROM Command register:
bit 15 is:
EEPROM Unit Busy. This bit must be set to a one to start an EEPROM operation (see EEOp below). Only one EEPROM operation can be executing at one time so this bit must be zero before setting it to a one. When the requested EEPROM operation completes this bit will automatically be cleared to a zero. The transition of this bit from a one to a zero can be used to generate an interrupt (the EEInt in Global 1, offset 0x00).
and more interesting is bit 11:
Register Loader Running. This bit is set to one whenever the register loader is busy executing instructions contained in the EEPROM."
Change to using mv88e6xxx_g2_eeprom_wait() to fix the timeout error when the EEPROM chip is not present.
Fixes: 23d775f12dcd ("net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset") Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6 |
|
#
9627c981 |
| 13-Jan-2023 |
Kurt Kanzenbach <kurt@linutronix.de> |
net: dsa: mv88e6xxx: Enable PTP receive for mv88e6390
The switch receives management traffic such as STP and LLDP. However, PTP messages are not received, only transmitted.
Ideally, the switch woul
net: dsa: mv88e6xxx: Enable PTP receive for mv88e6390
The switch receives management traffic such as STP and LLDP. However, PTP messages are not received, only transmitted.
Ideally, the switch would trap all PTP messages to the management CPU. This particular switch has a PTP block which identifies PTP messages and traps them to a dedicated port. There is a register to program this destination. This is not used at the moment.
Therefore, program it to the same port as the MGMT traffic is trapped to. This allows to receive PTP messages as soon as timestamping is enabled.
In addition, the datasheet mentions that this register is not valid e.g., for 6190 variants. So, add a new PTP operation which is added for the 6390 and 6290 devices.
Tested simply like this on Marvell 88E6390, revision 1:
|/ # ptp4l -2 -i lan4 --tx_timestamp_timeout=40 -m |[...] |ptp4l[147.450]: master offset 56 s2 freq +1262 path delay 413 |ptp4l[148.450]: master offset 22 s2 freq +1244 path delay 434 |ptp4l[149.450]: master offset 5 s2 freq +1234 path delay 446 |ptp4l[150.451]: master offset 3 s2 freq +1233 path delay 451 |ptp4l[151.451]: master offset 1 s2 freq +1232 path delay 451 |ptp4l[152.451]: master offset -3 s2 freq +1229 path delay 451 |ptp4l[153.451]: master offset 9 s2 freq +1240 path delay 451
Link: https://lore.kernel.org/r/CAFSKS=PJBpvtRJxrR4sG1hyxpnUnQpiHg4SrUNzAhkWnyt9ivg@mail.gmail.com Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30 |
|
#
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 s
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>
show more ...
|
Revision tags: v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20 |
|
#
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 assign
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>
show more ...
|
Revision tags: v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
de776d0d |
| 17-Mar-2021 |
Pavana Sharma <pavana.sharma@digi.com> |
net: dsa: mv88e6xxx: add support for mv88e6393x family
The Marvell 88E6393X device is a single-chip integration of a 11-port Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
net: dsa: mv88e6xxx: add support for mv88e6393x family
The Marvell 88E6393X device is a single-chip integration of a 11-port Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers and three 10-Gigabit interfaces.
This patch adds functionalities specific to mv88e6393x family (88E6393X, 88E6193X and 88E6191X).
The main differences between previous devices and this one are: - port 0 can be a SERDES port - all SERDESes are one-lane, eg. no XAUI nor RXAUI - on the other hand the SERDESes can do USXGMII, 10GBASER and 5GBASER (on 6191X only one SERDES is capable of more than 1g; USXGMII is not yet supported with this change) - Port Policy CTL register is changed to Port Policy MGMT CTL register, via which several more registers can be accessed indirectly - egress monitor port is configured differently - ingress monitor/CPU/mirror ports are configured differently and can be configured per port (ie. each port can have different ingress monitor port, for example) - port speed AltBit works differently than previously - PHY registers can be also accessed via MDIO address 0x18 and 0x19 (on previous devices they could be accessed only via Global 2 offsets 0x18 and 0x19, which means two indirections; this feature is not yet leveraged with thiis commit)
Co-developed-by: Ashkan Boldaji <ashkan.boldaji@digi.com> Signed-off-by: Ashkan Boldaji <ashkan.boldaji@digi.com> Signed-off-by: Pavana Sharma <pavana.sharma@digi.com> Co-developed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
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 identic
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>
show more ...
|
#
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
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>
show more ...
|
Revision tags: v5.10 |
|
#
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 conf
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>
show more ...
|
#
a3dcb3e7 |
| 16-Nov-2020 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Wait for EEPROM done after HW reset
When the switch is hardware reset, it reads the contents of the EEPROM. This can contain instructions for programming values into registers a
net: dsa: mv88e6xxx: Wait for EEPROM done after HW reset
When the switch is hardware reset, it reads the contents of the EEPROM. This can contain instructions for programming values into registers and to perform waits between such programming. Reading the EEPROM can take longer than the 100ms mv88e6xxx_hardware_reset() waits after deasserting the reset GPIO. So poll the EEPROM done bit to ensure it is complete.
Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ruslan Sushko <rus@sushko.dev> Link: https://lore.kernel.org/r/20201116164301.977661-1-rus@sushko.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54 |
|
#
1baf0fac |
| 23-Jul-2020 |
Chris Packham <chris.packham@alliedtelesis.co.nz> |
net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU
Some of the chips in the mv88e6xxx family don't support jumbo configuration per port. But they do have a chip-wide max frame size that can b
net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU
Some of the chips in the mv88e6xxx family don't support jumbo configuration per port. But they do have a chip-wide max frame size that can be used. Use this to approximate the behaviour of configuring a port based MTU.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9 |
|
#
d8dc2c96 |
| 04-Jan-2020 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Preserve priority when setting CPU port.
The 6390 family uses an extended register to set the port connected to the CPU. The lower 5 bits indicate the port, the upper three bits
net: dsa: mv88e6xxx: Preserve priority when setting CPU port.
The 6390 family uses an extended register to set the port connected to the CPU. The lower 5 bits indicate the port, the upper three bits are the priority of the frames as they pass through the switch, what egress queue they should use, etc. Since frames being set to the CPU are typically management frames, BPDU, IGMP, ARP, etc set the priority to 7, the reset default, and the highest.
Fixes: 33641994a676 ("net: dsa: mv88e6xxx: Monitor and Management tables") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10 |
|
#
5c74c54c |
| 07-Nov-2019 |
Iwan R Timmer <irtimmer@gmail.com> |
net: dsa: mv88e6xxx: Split monitor port configuration
Separate the configuration of the egress and ingress monitor port. This allows the port mirror functionality to do ingress and egress port mirro
net: dsa: mv88e6xxx: Split monitor port configuration
Separate the configuration of the egress and ingress monitor port. This allows the port mirror functionality to do ingress and egress port mirroring to separate ports.
Signed-off-by: Iwan R Timmer <irtimmer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.3.9 |
|
#
c5f299d5 |
| 04-Nov-2019 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: global1_atu: Add helper for get next
When retrieving the ATU statistics, and ATU get next has to be performed to trigger the ATU to collect the statistics. Export a helper from
net: dsa: mv88e6xxx: global1_atu: Add helper for get next
When retrieving the ATU statistics, and ATU get next has to be performed to trigger the ATU to collect the statistics. Export a helper from global1_atu to perform this.
Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.3.8 |
|
#
23e8b470 |
| 24-Oct-2019 |
Andrew Lunn <andrew@lunn.ch> |
net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.
Some of the marvell switches have bits controlling the hash algorithm the ATU uses for MAC addresses. In some industrial settings, wher
net: dsa: mv88e6xxx: Add devlink param for ATU hash algorithm.
Some of the marvell switches have bits controlling the hash algorithm the ATU uses for MAC addresses. In some industrial settings, where all the devices are from the same manufacture, and hence use the same OUI, the default hashing algorithm is not optimal. Allow the other algorithms to be selected via devlink.
Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8 |
|
#
d8291a95 |
| 07-Sep-2019 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: complete ATU state definitions
Marvell has different values for the state of a MAC address, depending on its multicast bit. This patch completes the definitions for these states
net: dsa: mv88e6xxx: complete ATU state definitions
Marvell has different values for the state of a MAC address, depending on its multicast bit. This patch completes the definitions for these states.
At the same time, use 0 which is intuitive enough and simplifies the code a bit, instead of the UC or MC unused value.
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9 |
|
#
2ad4da77 |
| 09-Aug-2019 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: remove wait and update routines
Now that we have proper Wait Bit and Wait Mask routines, remove the unused mv88e6xxx_wait routine and its Global 1 and Global 2 variants.
The in
net: dsa: mv88e6xxx: remove wait and update routines
Now that we have proper Wait Bit and Wait Mask routines, remove the unused mv88e6xxx_wait routine and its Global 1 and Global 2 variants.
The indirect tables such as the Device Mapping Table or Priority Override Table make use of an Update bit to distinguish reading (0) from writing (1) operations. After a write operation occurs, the bit self clears right away so there's no need to wait on it. Thus keep things simple and remove the mv88e6xxx_update helper as well.
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
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 p
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>
show more ...
|
#
683f2244 |
| 09-Aug-2019 |
Vivien Didelot <vivien.didelot@gmail.com> |
net: dsa: mv88e6xxx: introduce wait mask routine
The current mv88e6xxx_wait routine is used to wait for a given mask to be cleared to zero. However in some cases, the driver may have to wait for a g
net: dsa: mv88e6xxx: introduce wait mask routine
The current mv88e6xxx_wait routine is used to wait for a given mask to be cleared to zero. However in some cases, the driver may have to wait for a given mask to be of a certain non-zero value.
Thus provide a generic wait mask routine that will be used to implement the current mv88e6xxx_wait function, and use it to wait for 88E6185 PPU states.
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|