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