1========================= 2NXP SJA1105 switch driver 3========================= 4 5Overview 6======== 7 8The NXP SJA1105 is a family of 6 devices: 9 10- SJA1105E: First generation, no TTEthernet 11- SJA1105T: First generation, TTEthernet 12- SJA1105P: Second generation, no TTEthernet, no SGMII 13- SJA1105Q: Second generation, TTEthernet, no SGMII 14- SJA1105R: Second generation, no TTEthernet, SGMII 15- SJA1105S: Second generation, TTEthernet, SGMII 16 17These are SPI-managed automotive switches, with all ports being gigabit 18capable, and supporting MII/RMII/RGMII and optionally SGMII on one port. 19 20Being automotive parts, their configuration interface is geared towards 21set-and-forget use, with minimal dynamic interaction at runtime. They 22require a static configuration to be composed by software and packed 23with CRC and table headers, and sent over SPI. 24 25The static configuration is composed of several configuration tables. Each 26table takes a number of entries. Some configuration tables can be (partially) 27reconfigured at runtime, some not. Some tables are mandatory, some not: 28 29============================= ================== ============================= 30Table Mandatory Reconfigurable 31============================= ================== ============================= 32Schedule no no 33Schedule entry points if Scheduling no 34VL Lookup no no 35VL Policing if VL Lookup no 36VL Forwarding if VL Lookup no 37L2 Lookup no no 38L2 Policing yes no 39VLAN Lookup yes yes 40L2 Forwarding yes partially (fully on P/Q/R/S) 41MAC Config yes partially (fully on P/Q/R/S) 42Schedule Params if Scheduling no 43Schedule Entry Points Params if Scheduling no 44VL Forwarding Params if VL Forwarding no 45L2 Lookup Params no partially (fully on P/Q/R/S) 46L2 Forwarding Params yes no 47Clock Sync Params no no 48AVB Params no no 49General Params yes partially 50Retagging no yes 51xMII Params yes no 52SGMII no yes 53============================= ================== ============================= 54 55 56Also the configuration is write-only (software cannot read it back from the 57switch except for very few exceptions). 58 59The driver creates a static configuration at probe time, and keeps it at 60all times in memory, as a shadow for the hardware state. When required to 61change a hardware setting, the static configuration is also updated. 62If that changed setting can be transmitted to the switch through the dynamic 63reconfiguration interface, it is; otherwise the switch is reset and 64reprogrammed with the updated static configuration. 65 66Traffic support 67=============== 68 69The switches do not have hardware support for DSA tags, except for "slow 70protocols" for switch control as STP and PTP. For these, the switches have two 71programmable filters for link-local destination MACs. 72These are used to trap BPDUs and PTP traffic to the master netdevice, and are 73further used to support STP and 1588 ordinary clock/boundary clock 74functionality. For frames trapped to the CPU, source port and switch ID 75information is encoded by the hardware into the frames. 76 77But by leveraging ``CONFIG_NET_DSA_TAG_8021Q`` (a software-defined DSA tagging 78format based on VLANs), general-purpose traffic termination through the network 79stack can be supported under certain circumstances. 80 81Depending on VLAN awareness state, the following operating modes are possible 82with the switch: 83 84- Mode 1 (VLAN-unaware): a port is in this mode when it is used as a standalone 85 net device, or when it is enslaved to a bridge with ``vlan_filtering=0``. 86- Mode 2 (fully VLAN-aware): a port is in this mode when it is enslaved to a 87 bridge with ``vlan_filtering=1``. Access to the entire VLAN range is given to 88 the user through ``bridge vlan`` commands, but general-purpose (anything 89 other than STP, PTP etc) traffic termination is not possible through the 90 switch net devices. The other packets can be still by user space processed 91 through the DSA master interface (similar to ``DSA_TAG_PROTO_NONE``). 92- Mode 3 (best-effort VLAN-aware): a port is in this mode when enslaved to a 93 bridge with ``vlan_filtering=1``, and the devlink property of its parent 94 switch named ``best_effort_vlan_filtering`` is set to ``true``. When 95 configured like this, the range of usable VIDs is reduced (0 to 1023 and 3072 96 to 4094), so is the number of usable VIDs (maximum of 7 non-pvid VLANs per 97 port*), and shared VLAN learning is performed (FDB lookup is done only by 98 DMAC, not also by VID). 99 100To summarize, in each mode, the following types of traffic are supported over 101the switch net devices: 102 103+-------------+-----------+--------------+------------+ 104| | Mode 1 | Mode 2 | Mode 3 | 105+=============+===========+==============+============+ 106| Regular | Yes | No | Yes | 107| traffic | | (use master) | | 108+-------------+-----------+--------------+------------+ 109| Management | Yes | Yes | Yes | 110| traffic | | | | 111| (BPDU, PTP) | | | | 112+-------------+-----------+--------------+------------+ 113 114To configure the switch to operate in Mode 3, the following steps can be 115followed:: 116 117 ip link add dev br0 type bridge 118 # swp2 operates in Mode 1 now 119 ip link set dev swp2 master br0 120 # swp2 temporarily moves to Mode 2 121 ip link set dev br0 type bridge vlan_filtering 1 122 [ 61.204770] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering 123 [ 61.239944] sja1105 spi0.1: Disabled switch tagging 124 # swp3 now operates in Mode 3 125 devlink dev param set spi/spi0.1 name best_effort_vlan_filtering value true cmode runtime 126 [ 64.682927] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering 127 [ 64.711925] sja1105 spi0.1: Enabled switch tagging 128 # Cannot use VLANs in range 1024-3071 while in Mode 3. 129 bridge vlan add dev swp2 vid 1025 untagged pvid 130 RTNETLINK answers: Operation not permitted 131 bridge vlan add dev swp2 vid 100 132 bridge vlan add dev swp2 vid 101 untagged 133 bridge vlan 134 port vlan ids 135 swp5 1 PVID Egress Untagged 136 137 swp2 1 PVID Egress Untagged 138 100 139 101 Egress Untagged 140 141 swp3 1 PVID Egress Untagged 142 143 swp4 1 PVID Egress Untagged 144 145 br0 1 PVID Egress Untagged 146 bridge vlan add dev swp2 vid 102 147 bridge vlan add dev swp2 vid 103 148 bridge vlan add dev swp2 vid 104 149 bridge vlan add dev swp2 vid 105 150 bridge vlan add dev swp2 vid 106 151 bridge vlan add dev swp2 vid 107 152 # Cannot use mode than 7 VLANs per port while in Mode 3. 153 [ 3885.216832] sja1105 spi0.1: No more free subvlans 154 155\* "maximum of 7 non-pvid VLANs per port": Decoding VLAN-tagged packets on the 156CPU in mode 3 is possible through VLAN retagging of packets that go from the 157switch to the CPU. In cross-chip topologies, the port that goes to the CPU 158might also go to other switches. In that case, those other switches will see 159only a retagged packet (which only has meaning for the CPU). So if they are 160interested in this VLAN, they need to apply retagging in the reverse direction, 161to recover the original value from it. This consumes extra hardware resources 162for this switch. There is a maximum of 32 entries in the Retagging Table of 163each switch device. 164 165As an example, consider this cross-chip topology:: 166 167 +-------------------------------------------------+ 168 | Host SoC | 169 | +-------------------------+ | 170 | | DSA master for embedded | | 171 | | switch (non-sja1105) | | 172 | +--------+-------------------------+--------+ | 173 | | embedded L2 switch | | 174 | | | | 175 | | +--------------+ +--------------+ | | 176 | | |DSA master for| |DSA master for| | | 177 | | | SJA1105 1 | | SJA1105 2 | | | 178 +--+---+--------------+-----+--------------+---+--+ 179 180 +-----------------------+ +-----------------------+ 181 | SJA1105 switch 1 | | SJA1105 switch 2 | 182 +-----+-----+-----+-----+ +-----+-----+-----+-----+ 183 |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| 184 +-----+-----+-----+-----+ +-----+-----+-----+-----+ 185 186To reach the CPU, SJA1105 switch 1 (spi/spi2.1) uses the same port as is uses 187to reach SJA1105 switch 2 (spi/spi2.2), which would be port 4 (not drawn). 188Similarly for SJA1105 switch 2. 189 190Also consider the following commands, that add VLAN 100 to every sja1105 user 191port:: 192 193 devlink dev param set spi/spi2.1 name best_effort_vlan_filtering value true cmode runtime 194 devlink dev param set spi/spi2.2 name best_effort_vlan_filtering value true cmode runtime 195 ip link add dev br0 type bridge 196 for port in sw1p0 sw1p1 sw1p2 sw1p3 \ 197 sw2p0 sw2p1 sw2p2 sw2p3; do 198 ip link set dev $port master br0 199 done 200 ip link set dev br0 type bridge vlan_filtering 1 201 for port in sw1p0 sw1p1 sw1p2 sw1p3 \ 202 sw2p0 sw2p1 sw2p2; do 203 bridge vlan add dev $port vid 100 204 done 205 ip link add link br0 name br0.100 type vlan id 100 && ip link set dev br0.100 up 206 ip addr add 192.168.100.3/24 dev br0.100 207 bridge vlan add dev br0 vid 100 self 208 209 bridge vlan 210 port vlan ids 211 sw1p0 1 PVID Egress Untagged 212 100 213 214 sw1p1 1 PVID Egress Untagged 215 100 216 217 sw1p2 1 PVID Egress Untagged 218 100 219 220 sw1p3 1 PVID Egress Untagged 221 100 222 223 sw2p0 1 PVID Egress Untagged 224 100 225 226 sw2p1 1 PVID Egress Untagged 227 100 228 229 sw2p2 1 PVID Egress Untagged 230 100 231 232 sw2p3 1 PVID Egress Untagged 233 234 br0 1 PVID Egress Untagged 235 100 236 237SJA1105 switch 1 consumes 1 retagging entry for each VLAN on each user port 238towards the CPU. It also consumes 1 retagging entry for each non-pvid VLAN that 239it is also interested in, which is configured on any port of any neighbor 240switch. 241 242In this case, SJA1105 switch 1 consumes a total of 11 retagging entries, as 243follows: 244 245- 8 retagging entries for VLANs 1 and 100 installed on its user ports 246 (``sw1p0`` - ``sw1p3``) 247- 3 retagging entries for VLAN 100 installed on the user ports of SJA1105 248 switch 2 (``sw2p0`` - ``sw2p2``), because it also has ports that are 249 interested in it. The VLAN 1 is a pvid on SJA1105 switch 2 and does not need 250 reverse retagging. 251 252SJA1105 switch 2 also consumes 11 retagging entries, but organized as follows: 253 254- 7 retagging entries for the bridge VLANs on its user ports (``sw2p0`` - 255 ``sw2p3``). 256- 4 retagging entries for VLAN 100 installed on the user ports of SJA1105 257 switch 1 (``sw1p0`` - ``sw1p3``). 258 259Switching features 260================== 261 262The driver supports the configuration of L2 forwarding rules in hardware for 263port bridging. The forwarding, broadcast and flooding domain between ports can 264be restricted through two methods: either at the L2 forwarding level (isolate 265one bridge's ports from another's) or at the VLAN port membership level 266(isolate ports within the same bridge). The final forwarding decision taken by 267the hardware is a logical AND of these two sets of rules. 268 269The hardware tags all traffic internally with a port-based VLAN (pvid), or it 270decodes the VLAN information from the 802.1Q tag. Advanced VLAN classification 271is not possible. Once attributed a VLAN tag, frames are checked against the 272port's membership rules and dropped at ingress if they don't match any VLAN. 273This behavior is available when switch ports are enslaved to a bridge with 274``vlan_filtering 1``. 275 276Normally the hardware is not configurable with respect to VLAN awareness, but 277by changing what TPID the switch searches 802.1Q tags for, the semantics of a 278bridge with ``vlan_filtering 0`` can be kept (accept all traffic, tagged or 279untagged), and therefore this mode is also supported. 280 281Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but 282all bridges should have the same level of VLAN awareness (either both have 283``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact 284that VLAN awareness is global at the switch level is that once a bridge with 285``vlan_filtering`` enslaves at least one switch port, the other un-bridged 286ports are no longer available for standalone traffic termination. 287 288Topology and loop detection through STP is supported. 289 290L2 FDB manipulation (add/delete/dump) is currently possible for the first 291generation devices. Aging time of FDB entries, as well as enabling fully static 292management (no address learning and no flooding of unknown traffic) is not yet 293configurable in the driver. 294 295A special comment about bridging with other netdevices (illustrated with an 296example): 297 298A board has eth0, eth1, swp0@eth1, swp1@eth1, swp2@eth1, swp3@eth1. 299The switch ports (swp0-3) are under br0. 300It is desired that eth0 is turned into another switched port that communicates 301with swp0-3. 302 303If br0 has vlan_filtering 0, then eth0 can simply be added to br0 with the 304intended results. 305If br0 has vlan_filtering 1, then a new br1 interface needs to be created that 306enslaves eth0 and eth1 (the DSA master of the switch ports). This is because in 307this mode, the switch ports beneath br0 are not capable of regular traffic, and 308are only used as a conduit for switchdev operations. 309 310Offloads 311======== 312 313Time-aware scheduling 314--------------------- 315 316The switch supports a variation of the enhancements for scheduled traffic 317specified in IEEE 802.1Q-2018 (formerly 802.1Qbv). This means it can be used to 318ensure deterministic latency for priority traffic that is sent in-band with its 319gate-open event in the network schedule. 320 321This capability can be managed through the tc-taprio offload ('flags 2'). The 322difference compared to the software implementation of taprio is that the latter 323would only be able to shape traffic originated from the CPU, but not 324autonomously forwarded flows. 325 326The device has 8 traffic classes, and maps incoming frames to one of them based 327on the VLAN PCP bits (if no VLAN is present, the port-based default is used). 328As described in the previous sections, depending on the value of 329``vlan_filtering``, the EtherType recognized by the switch as being VLAN can 330either be the typical 0x8100 or a custom value used internally by the driver 331for tagging. Therefore, the switch ignores the VLAN PCP if used in standalone 332or bridge mode with ``vlan_filtering=0``, as it will not recognize the 0x8100 333EtherType. In these modes, injecting into a particular TX queue can only be 334done by the DSA net devices, which populate the PCP field of the tagging header 335on egress. Using ``vlan_filtering=1``, the behavior is the other way around: 336offloaded flows can be steered to TX queues based on the VLAN PCP, but the DSA 337net devices are no longer able to do that. To inject frames into a hardware TX 338queue with VLAN awareness active, it is necessary to create a VLAN 339sub-interface on the DSA master port, and send normal (0x8100) VLAN-tagged 340towards the switch, with the VLAN PCP bits set appropriately. 341 342Management traffic (having DMAC 01-80-C2-xx-xx-xx or 01-19-1B-xx-xx-xx) is the 343notable exception: the switch always treats it with a fixed priority and 344disregards any VLAN PCP bits even if present. The traffic class for management 345traffic has a value of 7 (highest priority) at the moment, which is not 346configurable in the driver. 347 348Below is an example of configuring a 500 us cyclic schedule on egress port 349``swp5``. The traffic class gate for management traffic (7) is open for 100 us, 350and the gates for all other traffic classes are open for 400 us:: 351 352 #!/bin/bash 353 354 set -e -u -o pipefail 355 356 NSEC_PER_SEC="1000000000" 357 358 gatemask() { 359 local tc_list="$1" 360 local mask=0 361 362 for tc in ${tc_list}; do 363 mask=$((${mask} | (1 << ${tc}))) 364 done 365 366 printf "%02x" ${mask} 367 } 368 369 if ! systemctl is-active --quiet ptp4l; then 370 echo "Please start the ptp4l service" 371 exit 372 fi 373 374 now=$(phc_ctl /dev/ptp1 get | gawk '/clock time is/ { print $5; }') 375 # Phase-align the base time to the start of the next second. 376 sec=$(echo "${now}" | gawk -F. '{ print $1; }') 377 base_time="$(((${sec} + 1) * ${NSEC_PER_SEC}))" 378 379 tc qdisc add dev swp5 parent root handle 100 taprio \ 380 num_tc 8 \ 381 map 0 1 2 3 5 6 7 \ 382 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ 383 base-time ${base_time} \ 384 sched-entry S $(gatemask 7) 100000 \ 385 sched-entry S $(gatemask "0 1 2 3 4 5 6") 400000 \ 386 flags 2 387 388It is possible to apply the tc-taprio offload on multiple egress ports. There 389are hardware restrictions related to the fact that no gate event may trigger 390simultaneously on two ports. The driver checks the consistency of the schedules 391against this restriction and errors out when appropriate. Schedule analysis is 392needed to avoid this, which is outside the scope of the document. 393 394Routing actions (redirect, trap, drop) 395-------------------------------------- 396 397The switch is able to offload flow-based redirection of packets to a set of 398destination ports specified by the user. Internally, this is implemented by 399making use of Virtual Links, a TTEthernet concept. 400 401The driver supports 2 types of keys for Virtual Links: 402 403- VLAN-aware virtual links: these match on destination MAC address, VLAN ID and 404 VLAN PCP. 405- VLAN-unaware virtual links: these match on destination MAC address only. 406 407The VLAN awareness state of the bridge (vlan_filtering) cannot be changed while 408there are virtual link rules installed. 409 410Composing multiple actions inside the same rule is supported. When only routing 411actions are requested, the driver creates a "non-critical" virtual link. When 412the action list also contains tc-gate (more details below), the virtual link 413becomes "time-critical" (draws frame buffers from a reserved memory partition, 414etc). 415 416The 3 routing actions that are supported are "trap", "drop" and "redirect". 417 418Example 1: send frames received on swp2 with a DA of 42:be:24:9b:76:20 to the 419CPU and to swp3. This type of key (DA only) when the port's VLAN awareness 420state is off:: 421 422 tc qdisc add dev swp2 clsact 423 tc filter add dev swp2 ingress flower skip_sw dst_mac 42:be:24:9b:76:20 \ 424 action mirred egress redirect dev swp3 \ 425 action trap 426 427Example 2: drop frames received on swp2 with a DA of 42:be:24:9b:76:20, a VID 428of 100 and a PCP of 0:: 429 430 tc filter add dev swp2 ingress protocol 802.1Q flower skip_sw \ 431 dst_mac 42:be:24:9b:76:20 vlan_id 100 vlan_prio 0 action drop 432 433Time-based ingress policing 434--------------------------- 435 436The TTEthernet hardware abilities of the switch can be constrained to act 437similarly to the Per-Stream Filtering and Policing (PSFP) clause specified in 438IEEE 802.1Q-2018 (formerly 802.1Qci). This means it can be used to perform 439tight timing-based admission control for up to 1024 flows (identified by a 440tuple composed of destination MAC address, VLAN ID and VLAN PCP). Packets which 441are received outside their expected reception window are dropped. 442 443This capability can be managed through the offload of the tc-gate action. As 444routing actions are intrinsic to virtual links in TTEthernet (which performs 445explicit routing of time-critical traffic and does not leave that in the hands 446of the FDB, flooding etc), the tc-gate action may never appear alone when 447asking sja1105 to offload it. One (or more) redirect or trap actions must also 448follow along. 449 450Example: create a tc-taprio schedule that is phase-aligned with a tc-gate 451schedule (the clocks must be synchronized by a 1588 application stack, which is 452outside the scope of this document). No packet delivered by the sender will be 453dropped. Note that the reception window is larger than the transmission window 454(and much more so, in this example) to compensate for the packet propagation 455delay of the link (which can be determined by the 1588 application stack). 456 457Receiver (sja1105):: 458 459 tc qdisc add dev swp2 clsact 460 now=$(phc_ctl /dev/ptp1 get | awk '/clock time is/ {print $5}') && \ 461 sec=$(echo $now | awk -F. '{print $1}') && \ 462 base_time="$(((sec + 2) * 1000000000))" && \ 463 echo "base time ${base_time}" 464 tc filter add dev swp2 ingress flower skip_sw \ 465 dst_mac 42:be:24:9b:76:20 \ 466 action gate base-time ${base_time} \ 467 sched-entry OPEN 60000 -1 -1 \ 468 sched-entry CLOSE 40000 -1 -1 \ 469 action trap 470 471Sender:: 472 473 now=$(phc_ctl /dev/ptp0 get | awk '/clock time is/ {print $5}') && \ 474 sec=$(echo $now | awk -F. '{print $1}') && \ 475 base_time="$(((sec + 2) * 1000000000))" && \ 476 echo "base time ${base_time}" 477 tc qdisc add dev eno0 parent root taprio \ 478 num_tc 8 \ 479 map 0 1 2 3 4 5 6 7 \ 480 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ 481 base-time ${base_time} \ 482 sched-entry S 01 50000 \ 483 sched-entry S 00 50000 \ 484 flags 2 485 486The engine used to schedule the ingress gate operations is the same that the 487one used for the tc-taprio offload. Therefore, the restrictions regarding the 488fact that no two gate actions (either tc-gate or tc-taprio gates) may fire at 489the same time (during the same 200 ns slot) still apply. 490 491To come in handy, it is possible to share time-triggered virtual links across 492more than 1 ingress port, via flow blocks. In this case, the restriction of 493firing at the same time does not apply because there is a single schedule in 494the system, that of the shared virtual link:: 495 496 tc qdisc add dev swp2 ingress_block 1 clsact 497 tc qdisc add dev swp3 ingress_block 1 clsact 498 tc filter add block 1 flower skip_sw dst_mac 42:be:24:9b:76:20 \ 499 action gate index 2 \ 500 base-time 0 \ 501 sched-entry OPEN 50000000 -1 -1 \ 502 sched-entry CLOSE 50000000 -1 -1 \ 503 action trap 504 505Hardware statistics for each flow are also available ("pkts" counts the number 506of dropped frames, which is a sum of frames dropped due to timing violations, 507lack of destination ports and MTU enforcement checks). Byte-level counters are 508not available. 509 510Device Tree bindings and board design 511===================================== 512 513This section references ``Documentation/devicetree/bindings/net/dsa/sja1105.txt`` 514and aims to showcase some potential switch caveats. 515 516RMII PHY role and out-of-band signaling 517--------------------------------------- 518 519In the RMII spec, the 50 MHz clock signals are either driven by the MAC or by 520an external oscillator (but not by the PHY). 521But the spec is rather loose and devices go outside it in several ways. 522Some PHYs go against the spec and may provide an output pin where they source 523the 50 MHz clock themselves, in an attempt to be helpful. 524On the other hand, the SJA1105 is only binary configurable - when in the RMII 525MAC role it will also attempt to drive the clock signal. To prevent this from 526happening it must be put in RMII PHY role. 527But doing so has some unintended consequences. 528In the RMII spec, the PHY can transmit extra out-of-band signals via RXD[1:0]. 529These are practically some extra code words (/J/ and /K/) sent prior to the 530preamble of each frame. The MAC does not have this out-of-band signaling 531mechanism defined by the RMII spec. 532So when the SJA1105 port is put in PHY role to avoid having 2 drivers on the 533clock signal, inevitably an RMII PHY-to-PHY connection is created. The SJA1105 534emulates a PHY interface fully and generates the /J/ and /K/ symbols prior to 535frame preambles, which the real PHY is not expected to understand. So the PHY 536simply encodes the extra symbols received from the SJA1105-as-PHY onto the 537100Base-Tx wire. 538On the other side of the wire, some link partners might discard these extra 539symbols, while others might choke on them and discard the entire Ethernet 540frames that follow along. This looks like packet loss with some link partners 541but not with others. 542The take-away is that in RMII mode, the SJA1105 must be let to drive the 543reference clock if connected to a PHY. 544 545RGMII fixed-link and internal delays 546------------------------------------ 547 548As mentioned in the bindings document, the second generation of devices has 549tunable delay lines as part of the MAC, which can be used to establish the 550correct RGMII timing budget. 551When powered up, these can shift the Rx and Tx clocks with a phase difference 552between 73.8 and 101.7 degrees. 553The catch is that the delay lines need to lock onto a clock signal with a 554stable frequency. This means that there must be at least 2 microseconds of 555silence between the clock at the old vs at the new frequency. Otherwise the 556lock is lost and the delay lines must be reset (powered down and back up). 557In RGMII the clock frequency changes with link speed (125 MHz at 1000 Mbps, 25 558MHz at 100 Mbps and 2.5 MHz at 10 Mbps), and link speed might change during the 559AN process. 560In the situation where the switch port is connected through an RGMII fixed-link 561to a link partner whose link state life cycle is outside the control of Linux 562(such as a different SoC), then the delay lines would remain unlocked (and 563inactive) until there is manual intervention (ifdown/ifup on the switch port). 564The take-away is that in RGMII mode, the switch's internal delays are only 565reliable if the link partner never changes link speeds, or if it does, it does 566so in a way that is coordinated with the switch port (practically, both ends of 567the fixed-link are under control of the same Linux system). 568As to why would a fixed-link interface ever change link speeds: there are 569Ethernet controllers out there which come out of reset in 100 Mbps mode, and 570their driver inevitably needs to change the speed and clock frequency if it's 571required to work at gigabit. 572 573MDIO bus and PHY management 574--------------------------- 575 576The SJA1105 does not have an MDIO bus and does not perform in-band AN either. 577Therefore there is no link state notification coming from the switch device. 578A board would need to hook up the PHYs connected to the switch to any other 579MDIO bus available to Linux within the system (e.g. to the DSA master's MDIO 580bus). Link state management then works by the driver manually keeping in sync 581(over SPI commands) the MAC link speed with the settings negotiated by the PHY. 582