Revision tags: 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.15.30, 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, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, 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 |
|
#
3c9cfb52 |
| 17-Sep-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: update NXP copyright text
NXP Legal insists that the following are not fine:
- Saying "NXP Semiconductors" instead of "NXP", since the company's registered name is "NXP"
- Putting a "(c)" s
net: update NXP copyright text
NXP Legal insists that the following are not fine:
- Saying "NXP Semiconductors" instead of "NXP", since the company's registered name is "NXP"
- Putting a "(c)" sign in the copyright string
- Putting a comma in the copyright string
The only accepted copyright string format is "Copyright <year-range> NXP".
This patch changes the copyright headers in the networking files that were sent by me, or derived from code sent by me.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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 |
|
#
1303e7f9 |
| 18-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: allow the TTEthernet configuration in the static config for SJA1110
Currently sja1105_static_config_check_valid() is coded up to detect whether TTEthernet is supported based on de
net: dsa: sja1105: allow the TTEthernet configuration in the static config for SJA1110
Currently sja1105_static_config_check_valid() is coded up to detect whether TTEthernet is supported based on device ID, and this check was not updated to cover SJA1110.
However, it is desirable to have as few checks for the device ID as possible, so the driver core is more generic. So what we can do is look at the static config table operations implemented by that specific switch family (populated by sja1105_static_config_init) whether the schedule table has a non-zero maximum entry count (meaning that it is supported) or not.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4913b8eb |
| 11-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: add support for the SJA1110 native tagging protocol
The SJA1110 has improved a few things compared to SJA1105:
- To send a control packet from the host port with SJA1105, one needed to
net: dsa: add support for the SJA1110 native tagging protocol
The SJA1110 has improved a few things compared to SJA1105:
- To send a control packet from the host port with SJA1105, one needed to program a one-shot "management route" over SPI. This is no longer true with SJA1110, you can actually send "in-band control extensions" in the packets sent by DSA, these are in fact DSA tags which contain the destination port and switch ID.
- When receiving a control packet from the switch with SJA1105, the source port and switch ID were written in bytes 3 and 4 of the destination MAC address of the frame (which was a very poor shot at a DSA header). If the control packet also had an RX timestamp, that timestamp was sent in an actual follow-up packet, so there were reordering concerns on multi-core/multi-queue DSA masters, where the metadata frame with the RX timestamp might get processed before the actual packet to which that timestamp belonged (there is no way to pair a packet to its timestamp other than the order in which they were received). On SJA1110, this is no longer true, control packets have the source port, switch ID and timestamp all in the DSA tags.
- Timestamps from the switch were partial: to get a 64-bit timestamp as required by PTP stacks, one would need to take the partial 24-bit or 32-bit timestamp from the packet, then read the current PTP time very quickly, and then patch in the high bits of the current PTP time into the captured partial timestamp, to reconstruct what the full 64-bit timestamp must have been. That is awful because packet processing is done in NAPI context, but reading the current PTP time is done over SPI and therefore needs sleepable context.
But it also aggravated a few things:
- Not only is there a DSA header in SJA1110, but there is a DSA trailer in fact, too. So DSA needs to be extended to support taggers which have both a header and a trailer. Very unconventional - my understanding is that the trailer exists because the timestamps couldn't be prepared in time for putting them in the header area.
- Like SJA1105, not all packets sent to the CPU have the DSA tag added to them, only control packets do:
* the ones which match the destination MAC filters/traps in MAC_FLTRES1 and MAC_FLTRES0 * the ones which match FDB entries which have TRAP or TAKETS bits set
So we could in theory hack something up to request the switch to take timestamps for all packets that reach the CPU, and those would be DSA-tagged and contain the source port / switch ID by virtue of the fact that there needs to be a timestamp trailer provided. BUT:
- The SJA1110 does not parse its own DSA tags in a way that is useful for routing in cross-chip topologies, a la Marvell. And the sja1105 driver already supports cross-chip bridging from the SJA1105 days. It does that by automatically setting up the DSA links as VLAN trunks which contain all the necessary tag_8021q RX VLANs that must be communicated between the switches that span the same bridge. So when using tag_8021q on sja1105, it is possible to have 2 switches with ports sw0p0, sw0p1, sw1p0, sw1p1, and 2 VLAN-unaware bridges br0 and br1, and br0 can take sw0p0 and sw1p0, and br1 can take sw0p1 and sw1p1, and forwarding will happen according to the expected rules of the Linux bridge. We like that, and we don't want that to go away, so as a matter of fact, the SJA1110 tagger still needs to support tag_8021q.
So the sja1110 tagger is a hybrid between tag_8021q for data packets, and the native hardware support for control packets.
On RX, packets have a 13-byte trailer if they contain an RX timestamp. That trailer is padded in such a way that its byte 8 (the start of the "residence time" field - not parsed by Linux because we don't care) is aligned on a 16 byte boundary. So the padding has a variable length between 0 and 15 bytes. The DSA header contains the offset of the beginning of the padding relative to the beginning of the frame (and the end of the padding is obviously the end of the packet minus 13 bytes, the length of the trailer). So we discard it.
Packets which don't have a trailer contain the source port and switch ID information in the header (they are "trap-to-host" packets). Packets which have a trailer contain the source port and switch ID in the trailer.
On TX, the destination port mask and switch ID is always in the trailer, so we always need to say in the header that a trailer is present.
The header needs a custom EtherType and this was chosen as 0xdadc, after 0xdada which is for Marvell and 0xdadb which is for VLANs in VLAN-unaware mode on SJA1105 (and SJA1110 in fact too).
Because we use tag_8021q in concert with the native tagging protocol, control packets will have 2 DSA tags.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.43 |
|
#
ceec8bc0 |
| 08-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: make sure the retagging port is enabled for SJA1110
The SJA1110 has an extra configuration in the General Parameters Table through which the user can select the buffer reservation
net: dsa: sja1105: make sure the retagging port is enabled for SJA1110
The SJA1110 has an extra configuration in the General Parameters Table through which the user can select the buffer reservation config.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3e77e59b |
| 08-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add support for the SJA1110 switch family
The SJA1110 is basically an SJA1105 with more ports, some integrated PHYs (100base-T1 and 100base-TX) and an embedded microcontroller whi
net: dsa: sja1105: add support for the SJA1110 switch family
The SJA1110 is basically an SJA1105 with more ports, some integrated PHYs (100base-T1 and 100base-TX) and an embedded microcontroller which can be disabled, and the switch core can be controlled by a host running Linux, over SPI.
This patch contains: - the static and dynamic config packing functions, for the tables that are common with SJA1105 - one more static config tables which is "unique" to the SJA1110 (actually it is a rehash of stuff that was placed somewhere else in SJA1105): the PCP Remapping Table - a reset and clock configuration procedure for the SJA1110 switch. This resets just the switch subsystem, and gates off the clock which powers on the embedded microcontroller. - an RGMII delay configuration procedure for SJA1110, which is very similar to SJA1105, but different enough for us to be unable to reuse it (this is a pattern that repeats itself) - some adaptations to dynamic config table entries which are no longer programmed in the same way. For example, to delete a VLAN, you used to write an entry through the dynamic reconfiguration interface with the desired VLAN ID, and with the VALIDENT bit set to false. Now, the VLAN table entries contain a TYPE_ENTRY field, which must be set to zero (in a backwards-incompatible way) in order for the entry to be deleted, or to some other entry for the VLAN to match "inner tagged" or "outer tagged" packets. - a similar thing for the static config: the xMII Mode Parameters Table encoding for SGMII and MII (the latter just when attached to a 100base-TX PHY) just isn't what it used to be in SJA1105. They are identical, except there is an extra "special" bit which needs to be set. Set it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40 |
|
#
1bf658ee |
| 24-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: allow the frame buffer size to be customized
The shared frame buffer of the SJA1110 is larger than that of SJA1105, which is natural due to the fact that there are more ports.
In
net: dsa: sja1105: allow the frame buffer size to be customized
The shared frame buffer of the SJA1110 is larger than that of SJA1105, which is natural due to the fact that there are more ports.
Introduce yet another property in struct sja1105_info which encodes the maximum number of 128 byte blocks that can be used for frame buffers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18 |
|
#
fcd4ba3b |
| 23-Feb-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
net: dsa: sja1105: Remove unneeded cast in sja1105_crc32()
sja1105_unpack() takes a "const void *buf" as its first parameter, so there is no need to cast away the "const" of the "buf" variable befor
net: dsa: sja1105: Remove unneeded cast in sja1105_crc32()
sja1105_unpack() takes a "const void *buf" as its first parameter, so there is no need to cast away the "const" of the "buf" variable before calling it.
Drop the cast, as it prevents the compiler performing some checks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20210223112003.2223332-1-geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, 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, 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 |
|
#
718e44b6 |
| 20-Jun-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: make config table operation structures constant
The per-chip instantiations of struct sja1105_table_ops and struct sja1105_dynamic_table_ops can be made constant, so do that.
Sig
net: dsa: sja1105: make config table operation structures constant
The per-chip instantiations of struct sja1105_table_ops and struct sja1105_dynamic_table_ops can be made constant, so do that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
be3fb56d |
| 20-Jun-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: remove empty structures from config table ops
Sparse is complaining and giving the following warning message: 'Using plain integer as NULL pointer'.
This is not what's going on,
net: dsa: sja1105: remove empty structures from config table ops
Sparse is complaining and giving the following warning message: 'Using plain integer as NULL pointer'.
This is not what's going on, instead {0} is used as a zero initializer for the structure members, to indicate that the particular chip revision does not support those particular config tables.
But since the config tables are declared globally, the unpopulated elements are zero-initialized anyway. So, to make sparse shut up, let's remove the zero initializers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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 |
|
#
99b981f4 |
| 30-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix port mirroring for P/Q/R/S
The dynamic configuration interface for the General Params and the L2 Lookup Params tables was copy-pasted between E/T devices and P/Q/R/S devices.
net: dsa: sja1105: fix port mirroring for P/Q/R/S
The dynamic configuration interface for the General Params and the L2 Lookup Params tables was copy-pasted between E/T devices and P/Q/R/S devices. Nonetheless, these interfaces are bitwise different.
The driver is using dynamic reconfiguration of the General Parameters table for the port mirroring feature, which was therefore broken on P/Q/R/S.
Note that this patch can't be backported easily very far to stable trees (since it conflicts with some other development done since the introduction of the driver). So the Fixes: tag is purely informational.
Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.43, v5.4.42, v5.4.41 |
|
#
88cac0fa |
| 12-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add packing ops for the Retagging Table
The Retagging Table is an optional feature that allows the switch to match frames against a {ingress port, egress port, vid} rule and chang
net: dsa: sja1105: add packing ops for the Retagging Table
The Retagging Table is an optional feature that allows the switch to match frames against a {ingress port, egress port, vid} rule and change their VLAN ID. The retagged frames are by default clones of the original ones (since the hardware-foreseen use case was to mirror traffic for debugging purposes and to tag it with a special VLAN for this purpose), but we can force the original frames to be dropped by removing the pre-retagging VLAN from the port membership list of the egress port.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.40, v5.4.39 |
|
#
94f94d4a |
| 05-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add static tables for virtual links
This patch adds the register definitions for the: - VL Lookup Table - VL Policing Table - VL Forwarding Table - VL Forwarding Parameters Table
net: dsa: sja1105: add static tables for virtual links
This patch adds the register definitions for the: - VL Lookup Table - VL Policing Table - VL Forwarding Table - VL Forwarding Parameters Table
These are needed in order to perform TTEthernet operations: QoS classification, flow-based policing and/or frame redirecting with the switch.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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 |
|
#
747e5eb3 |
| 23-Mar-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: configure the PTP_CLK pin as EXT_TS or PER_OUT
The SJA1105 switch family has a PTP_CLK pin which emits a signal with fixed 50% duty cycle, but variable frequency and programmable
net: dsa: sja1105: configure the PTP_CLK pin as EXT_TS or PER_OUT
The SJA1105 switch family has a PTP_CLK pin which emits a signal with fixed 50% duty cycle, but variable frequency and programmable start time.
On the second generation (P/Q/R/S) switches, this pin supports even more functionality. The use case described by the hardware documents talks about synchronization via oneshot pulses: given 2 sja1105 switches, arbitrarily designated as a master and a slave, the master emits a single pulse on PTP_CLK, while the slave is configured to timestamp this pulse received on its PTP_CLK pin (which must obviously be configured as input). The difference between the timestamps then exactly becomes the slave offset to the master.
The only trouble with the above is that the hardware is very much tied into this use case only, and not very generic beyond that: - When emitting a oneshot pulse, instead of being told when to emit it, the switch just does it "now" and tells you later what time it was, via the PTPSYNCTS register. [ Incidentally, this is the same register that the slave uses to collect the ext_ts timestamp from, too. ] - On the sync slave, there is no interrupt mechanism on reception of a new extts, and no FIFO to buffer them, because in the foreseen use case, software is in control of both the master and the slave pins, so it "knows" when there's something to collect.
These 2 problems mean that: - We don't support (at least yet) the quirky oneshot mode exposed by the hardware, just normal periodic output. - We abuse the hardware a little bit when we expose generic extts. Because there's no interrupt mechanism, we need to poll at double the frequency we expect to receive a pulse. Currently that means a non-configurable "twice a second".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
0a7e984c |
| 23-Mar-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: make the AVB table dynamically reconfigurable
The AVB table contains the CAS_MASTER field (to be added in the next patch) which decides the direction of the PTP_CLK pin.
Reconfig
net: dsa: sja1105: make the AVB table dynamically reconfigurable
The AVB table contains the CAS_MASTER field (to be added in the next patch) which decides the direction of the PTP_CLK pin.
Reconfiguring this field dynamically is highly preferable to having to reset the switch and upload a new static configuration, so we add support for exactly that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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, v5.4.8, v5.4.7 |
|
#
54fa49ee |
| 26-Dec-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/S
For first-generation switches (SJA1105E and SJA1105T): - TPID means C-Tag (typically 0x8100) - TPID2 means S-Tag (typic
net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/S
For first-generation switches (SJA1105E and SJA1105T): - TPID means C-Tag (typically 0x8100) - TPID2 means S-Tag (typically 0x88A8)
While for the second generation switches (SJA1105P, SJA1105Q, SJA1105R, SJA1105S) it is the other way around: - TPID means S-Tag (typically 0x88A8) - TPID2 means C-Tag (typically 0x8100)
In other words, E/T tags untagged traffic with TPID, and P/Q/R/S with TPID2.
So the patch mentioned below fixed VLAN filtering for P/Q/R/S, but broke it for E/T.
We strive for a common code path for all switches in the family, so just lie in the static config packing functions that TPID and TPID2 are at swapped bit offsets than they actually are, for P/Q/R/S. This will make both switches understand TPID to be ETH_P_8021Q and TPID2 to be ETH_P_8021AD. The meaning from the original E/T was chosen over P/Q/R/S because E/T is actually the one with public documentation available (UM10944.pdf).
Fixes: f9a1a7646c0d ("net: dsa: sja1105: Reverse TPID and TPID2") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: 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, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3 |
|
#
7f1e4ba8 |
| 14-Sep-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Add static config tables for scheduling
In order to support tc-taprio offload, the TTEthernet egress scheduling core registers must be made visible through the static interface.
net: dsa: sja1105: Add static config tables for scheduling
In order to support tc-taprio offload, the TTEthernet egress scheduling core registers must be made visible through the static interface.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16 |
|
#
6c56e167 |
| 25-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Make P/Q/R/S learn MAC addresses
At the end of the commit 1da73821343c ("net: dsa: sja1105: Add FDB operations for P/Q/R/S series") message, I said that:
At the moment only F
net: dsa: sja1105: Make P/Q/R/S learn MAC addresses
At the end of the commit 1da73821343c ("net: dsa: sja1105: Add FDB operations for P/Q/R/S series") message, I said that:
At the moment only FDB entries installed statically through 'bridge fdb' are visible in the dump callback - the dynamically learned ones are still under investigation.
It looks like the reason why they were not visible in 'bridge fdb' was that they were never learned - always flooded.
SJA1105 P/Q/R/S manual says about the MAXADDRP[port] field:
Specify the maximum number of MAC address dynamically learned from the respective port. It is used to limit the number of learned MAC addresses per port.
It looks like not providing a value in the static config (aka providing zeroes) is enough for it to not store the learned addresses in the FDB.
For now we divide the 1024 entry FDB "equally" amongst the 5 ports. This may be revisited if the situation calls for that - for now I'm happy that learning works.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
0803948e |
| 25-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Actually implement the P/Q/R/S FDB bits
In commit 1da73821343c ("net: dsa: sja1105: Add FDB operations for P/Q/R/S series"), these bits were set in the static config, but apparent
net: dsa: sja1105: Actually implement the P/Q/R/S FDB bits
In commit 1da73821343c ("net: dsa: sja1105: Add FDB operations for P/Q/R/S series"), these bits were set in the static config, but apparently they did not do anything. The reason is that the packing accessors for them were part of a patch I forgot to send.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3d64ea38 |
| 25-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Build PTP support in main DSA driver
As Arnd Bergmann pointed out in commit 78fe8a28fb96 ("net: dsa: sja1105: fix ptp link error"), there is no point in having PTP support as a se
net: dsa: sja1105: Build PTP support in main DSA driver
As Arnd Bergmann pointed out in commit 78fe8a28fb96 ("net: dsa: sja1105: fix ptp link error"), there is no point in having PTP support as a separate loadable kernel module.
So remove the exported symbols and make sja1105.ko contain PTP support or not based on CONFIG_NET_DSA_SJA1105_PTP.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8 |
|
#
24c01949 |
| 08-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Add support for the AVB Parameters Table
This table is used to program the switch to emit "meta" follow-up Ethernet frames (which contain partial RX timestamps) after each link-lo
net: dsa: sja1105: Add support for the AVB Parameters Table
This table is used to program the switch to emit "meta" follow-up Ethernet frames (which contain partial RX timestamps) after each link-local frame that was trapped to the CPU port through MAC filtering. This includes PTP frames.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
28e8fb3e |
| 08-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Export symbols for upcoming PTP driver
These are needed for the situation where the switch driver and the PTP driver are both built as modules.
Signed-off-by: Vladimir Oltean <ol
net: dsa: sja1105: Export symbols for upcoming PTP driver
These are needed for the situation where the switch driver and the PTP driver are both built as modules.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.1.7 |
|
#
9c5098d9 |
| 02-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Add missing L2 Forwarding Table definitions for P/Q/R/S
This appends to the L2 Forwarding and L2 Forwarding Parameters tables (originally added for first-generation switches) the
net: dsa: sja1105: Add missing L2 Forwarding Table definitions for P/Q/R/S
This appends to the L2 Forwarding and L2 Forwarding Parameters tables (originally added for first-generation switches) the bits that are new in the second generation.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.1.6 |
|
#
5ee907f7 |
| 29-May-2019 |
YueHaibing <yuehaibing@huawei.com> |
net: dsa: sja1105: Make static_config_check_memory_size static
Fix sparse warning:
drivers/net/dsa/sja1105/sja1105_static_config.c:446:1: warning: symbol 'static_config_check_memory_size' was not
net: dsa: sja1105: Make static_config_check_memory_size static
Fix sparse warning:
drivers/net/dsa/sja1105/sja1105_static_config.c:446:1: warning: symbol 'static_config_check_memory_size' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12 |
|
#
6666cebc |
| 02-May-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Add support for VLAN operations
VLAN filtering cannot be properly disabled in SJA1105. So in order to emulate the "no VLAN awareness" behavior (not dropping traffic that is tagged
net: dsa: sja1105: Add support for VLAN operations
VLAN filtering cannot be properly disabled in SJA1105. So in order to emulate the "no VLAN awareness" behavior (not dropping traffic that is tagged with a VID that isn't configured on the port), we need to hack another switch feature: programmable TPID (which is 0x8100 for 802.1Q). We are reprogramming the TPID to a bogus value which leaves the switch thinking that all traffic is untagged, and therefore accepts it.
Under a vlan_filtering bridge, the proper TPID of ETH_P_8021Q is installed again, and the switch starts identifying 802.1Q-tagged traffic.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
8aa9ebcc |
| 02-May-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch
At this moment the following is supported: * Link state management through phylib * Autonomous L2 forwarding managed through iproute2 brid
net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch
At this moment the following is supported: * Link state management through phylib * Autonomous L2 forwarding managed through iproute2 bridge commands.
IP termination must be done currently through the master netdevice, since the switch is unmanaged at this point and using DSA_TAG_PROTO_NONE.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Georg Waibel <georg.waibel@sensor-technik.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|