1 =========================
2 NXP SJA1105 switch driver
3 =========================
8 The NXP SJA1105 is a family of 10 SPI-managed automotive switches:
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
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
22 Being automotive parts, their configuration interface is geared towards
23 set-and-forget use, with minimal dynamic interaction at runtime. They
24 require a static configuration to be composed by software and packed
25 with CRC and table headers, and sent over SPI.
27 The static configuration is composed of several configuration tables. Each
28 table takes a number of entries. Some configuration tables can be (partially)
29 reconfigured at runtime, some not. Some tables are mandatory, some not:
31 ============================= ================== =============================
32 Table Mandatory Reconfigurable
33 ============================= ================== =============================
35 Schedule entry points if Scheduling no
37 VL Policing if VL Lookup no
38 VL Forwarding if VL Lookup no
42 L2 Forwarding yes partially (fully on P/Q/R/S)
43 MAC Config yes partially (fully on P/Q/R/S)
44 Schedule Params if Scheduling no
45 Schedule Entry Points Params if Scheduling no
46 VL Forwarding Params if VL Forwarding no
47 L2 Lookup Params no partially (fully on P/Q/R/S)
48 L2 Forwarding Params yes no
49 Clock Sync Params no no
51 General Params yes partially
55 ============================= ================== =============================
58 Also the configuration is write-only (software cannot read it back from the
59 switch except for very few exceptions).
61 The driver creates a static configuration at probe time, and keeps it at
62 all times in memory, as a shadow for the hardware state. When required to
63 change a hardware setting, the static configuration is also updated.
64 If that changed setting can be transmitted to the switch through the dynamic
65 reconfiguration interface, it is; otherwise the switch is reset and
66 reprogrammed with the updated static configuration.
71 The switches do not have hardware support for DSA tags, except for "slow
72 protocols" for switch control as STP and PTP. For these, the switches have two
73 programmable filters for link-local destination MACs.
74 These are used to trap BPDUs and PTP traffic to the master netdevice, and are
75 further used to support STP and 1588 ordinary clock/boundary clock
76 functionality. For frames trapped to the CPU, source port and switch ID
77 information is encoded by the hardware into the frames.
79 But by leveraging ``CONFIG_NET_DSA_TAG_8021Q`` (a software-defined DSA tagging
80 format based on VLANs), general-purpose traffic termination through the network
81 stack can be supported under certain circumstances.
83 Depending on VLAN awareness state, the following operating modes are possible
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).
102 To summarize, in each mode, the following types of traffic are supported over
103 the switch net devices:
105 +-------------+-----------+--------------+------------+
106 | | Mode 1 | Mode 2 | Mode 3 |
107 +=============+===========+==============+============+
108 | Regular | Yes | No | Yes |
109 | traffic | | (use master) | |
110 +-------------+-----------+--------------+------------+
111 | Management | Yes | Yes | Yes |
113 | (BPDU, PTP) | | | |
114 +-------------+-----------+--------------+------------+
116 To configure the switch to operate in Mode 3, the following steps can be
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
137 swp5 1 PVID Egress Untagged
139 swp2 1 PVID Egress Untagged
143 swp3 1 PVID Egress Untagged
145 swp4 1 PVID Egress Untagged
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
157 \* "maximum of 7 non-pvid VLANs per port": Decoding VLAN-tagged packets on the
158 CPU in mode 3 is possible through VLAN retagging of packets that go from the
159 switch to the CPU. In cross-chip topologies, the port that goes to the CPU
160 might also go to other switches. In that case, those other switches will see
161 only a retagged packet (which only has meaning for the CPU). So if they are
162 interested in this VLAN, they need to apply retagging in the reverse direction,
163 to recover the original value from it. This consumes extra hardware resources
164 for this switch. There is a maximum of 32 entries in the Retagging Table of
167 As an example, consider this cross-chip topology::
169 +-------------------------------------------------+
171 | +-------------------------+ |
172 | | DSA master for embedded | |
173 | | switch (non-sja1105) | |
174 | +--------+-------------------------+--------+ |
175 | | embedded L2 switch | |
177 | | +--------------+ +--------------+ | |
178 | | |DSA master for| |DSA master for| | |
179 | | | SJA1105 1 | | SJA1105 2 | | |
180 +--+---+--------------+-----+--------------+---+--+
182 +-----------------------+ +-----------------------+
183 | SJA1105 switch 1 | | SJA1105 switch 2 |
184 +-----+-----+-----+-----+ +-----+-----+-----+-----+
185 |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3|
186 +-----+-----+-----+-----+ +-----+-----+-----+-----+
188 To reach the CPU, SJA1105 switch 1 (spi/spi2.1) uses the same port as is uses
189 to reach SJA1105 switch 2 (spi/spi2.2), which would be port 4 (not drawn).
190 Similarly for SJA1105 switch 2.
192 Also consider the following commands, that add VLAN 100 to every sja1105 user
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
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
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
213 sw1p0 1 PVID Egress Untagged
216 sw1p1 1 PVID Egress Untagged
219 sw1p2 1 PVID Egress Untagged
222 sw1p3 1 PVID Egress Untagged
225 sw2p0 1 PVID Egress Untagged
228 sw2p1 1 PVID Egress Untagged
231 sw2p2 1 PVID Egress Untagged
234 sw2p3 1 PVID Egress Untagged
236 br0 1 PVID Egress Untagged
239 SJA1105 switch 1 consumes 1 retagging entry for each VLAN on each user port
240 towards the CPU. It also consumes 1 retagging entry for each non-pvid VLAN that
241 it is also interested in, which is configured on any port of any neighbor
244 In this case, SJA1105 switch 1 consumes a total of 11 retagging entries, as
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
254 SJA1105 switch 2 also consumes 11 retagging entries, but organized as follows:
256 - 7 retagging entries for the bridge VLANs on its user ports (``sw2p0`` -
258 - 4 retagging entries for VLAN 100 installed on the user ports of SJA1105
259 switch 1 (``sw1p0`` - ``sw1p3``).
264 The driver supports the configuration of L2 forwarding rules in hardware for
265 port bridging. The forwarding, broadcast and flooding domain between ports can
266 be restricted through two methods: either at the L2 forwarding level (isolate
267 one 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
269 the hardware is a logical AND of these two sets of rules.
271 The hardware tags all traffic internally with a port-based VLAN (pvid), or it
272 decodes the VLAN information from the 802.1Q tag. Advanced VLAN classification
273 is not possible. Once attributed a VLAN tag, frames are checked against the
274 port's membership rules and dropped at ingress if they don't match any VLAN.
275 This behavior is available when switch ports are enslaved to a bridge with
276 ``vlan_filtering 1``.
278 Normally the hardware is not configurable with respect to VLAN awareness, but
279 by changing what TPID the switch searches 802.1Q tags for, the semantics of a
280 bridge with ``vlan_filtering 0`` can be kept (accept all traffic, tagged or
281 untagged), and therefore this mode is also supported.
283 Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but
284 all 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
286 that 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
288 ports are no longer available for standalone traffic termination.
290 Topology and loop detection through STP is supported.
292 L2 FDB manipulation (add/delete/dump) is currently possible for the first
293 generation devices. Aging time of FDB entries, as well as enabling fully static
294 management (no address learning and no flooding of unknown traffic) is not yet
295 configurable in the driver.
297 A special comment about bridging with other netdevices (illustrated with an
300 A board has eth0, eth1, swp0@eth1, swp1@eth1, swp2@eth1, swp3@eth1.
301 The switch ports (swp0-3) are under br0.
302 It is desired that eth0 is turned into another switched port that communicates
305 If br0 has vlan_filtering 0, then eth0 can simply be added to br0 with the
307 If br0 has vlan_filtering 1, then a new br1 interface needs to be created that
308 enslaves eth0 and eth1 (the DSA master of the switch ports). This is because in
309 this mode, the switch ports beneath br0 are not capable of regular traffic, and
310 are only used as a conduit for switchdev operations.
315 Time-aware scheduling
316 ---------------------
318 The switch supports a variation of the enhancements for scheduled traffic
319 specified in IEEE 802.1Q-2018 (formerly 802.1Qbv). This means it can be used to
320 ensure deterministic latency for priority traffic that is sent in-band with its
321 gate-open event in the network schedule.
323 This capability can be managed through the tc-taprio offload ('flags 2'). The
324 difference compared to the software implementation of taprio is that the latter
325 would only be able to shape traffic originated from the CPU, but not
326 autonomously forwarded flows.
328 The device has 8 traffic classes, and maps incoming frames to one of them based
329 on the VLAN PCP bits (if no VLAN is present, the port-based default is used).
330 As described in the previous sections, depending on the value of
331 ``vlan_filtering``, the EtherType recognized by the switch as being VLAN can
332 either be the typical 0x8100 or a custom value used internally by the driver
333 for tagging. Therefore, the switch ignores the VLAN PCP if used in standalone
334 or bridge mode with ``vlan_filtering=0``, as it will not recognize the 0x8100
335 EtherType. In these modes, injecting into a particular TX queue can only be
336 done by the DSA net devices, which populate the PCP field of the tagging header
337 on egress. Using ``vlan_filtering=1``, the behavior is the other way around:
338 offloaded flows can be steered to TX queues based on the VLAN PCP, but the DSA
339 net devices are no longer able to do that. To inject frames into a hardware TX
340 queue with VLAN awareness active, it is necessary to create a VLAN
341 sub-interface on the DSA master port, and send normal (0x8100) VLAN-tagged
342 towards the switch, with the VLAN PCP bits set appropriately.
344 Management traffic (having DMAC 01-80-C2-xx-xx-xx or 01-19-1B-xx-xx-xx) is the
345 notable exception: the switch always treats it with a fixed priority and
346 disregards any VLAN PCP bits even if present. The traffic class for management
347 traffic has a value of 7 (highest priority) at the moment, which is not
348 configurable in the driver.
350 Below 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,
352 and the gates for all other traffic classes are open for 400 us::
356 set -e -u -o pipefail
358 NSEC_PER_SEC="1000000000"
364 for tc in ${tc_list}; do
365 mask=$((${mask} | (1 << ${tc})))
368 printf "%02x" ${mask}
371 if ! systemctl is-active --quiet ptp4l; then
372 echo "Please start the ptp4l service"
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}))"
381 tc qdisc add dev swp5 parent root handle 100 taprio \
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 \
390 It is possible to apply the tc-taprio offload on multiple egress ports. There
391 are hardware restrictions related to the fact that no gate event may trigger
392 simultaneously on two ports. The driver checks the consistency of the schedules
393 against this restriction and errors out when appropriate. Schedule analysis is
394 needed to avoid this, which is outside the scope of the document.
396 Routing actions (redirect, trap, drop)
397 --------------------------------------
399 The switch is able to offload flow-based redirection of packets to a set of
400 destination ports specified by the user. Internally, this is implemented by
401 making use of Virtual Links, a TTEthernet concept.
403 The driver supports 2 types of keys for Virtual Links:
405 - VLAN-aware virtual links: these match on destination MAC address, VLAN ID and
407 - VLAN-unaware virtual links: these match on destination MAC address only.
409 The VLAN awareness state of the bridge (vlan_filtering) cannot be changed while
410 there are virtual link rules installed.
412 Composing multiple actions inside the same rule is supported. When only routing
413 actions are requested, the driver creates a "non-critical" virtual link. When
414 the action list also contains tc-gate (more details below), the virtual link
415 becomes "time-critical" (draws frame buffers from a reserved memory partition,
418 The 3 routing actions that are supported are "trap", "drop" and "redirect".
420 Example 1: send frames received on swp2 with a DA of 42:be:24:9b:76:20 to the
421 CPU and to swp3. This type of key (DA only) when the port's VLAN awareness
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 \
429 Example 2: drop frames received on swp2 with a DA of 42:be:24:9b:76:20, a VID
430 of 100 and a PCP of 0::
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
435 Time-based ingress policing
436 ---------------------------
438 The TTEthernet hardware abilities of the switch can be constrained to act
439 similarly to the Per-Stream Filtering and Policing (PSFP) clause specified in
440 IEEE 802.1Q-2018 (formerly 802.1Qci). This means it can be used to perform
441 tight timing-based admission control for up to 1024 flows (identified by a
442 tuple composed of destination MAC address, VLAN ID and VLAN PCP). Packets which
443 are received outside their expected reception window are dropped.
445 This capability can be managed through the offload of the tc-gate action. As
446 routing actions are intrinsic to virtual links in TTEthernet (which performs
447 explicit routing of time-critical traffic and does not leave that in the hands
448 of the FDB, flooding etc), the tc-gate action may never appear alone when
449 asking sja1105 to offload it. One (or more) redirect or trap actions must also
452 Example: create a tc-taprio schedule that is phase-aligned with a tc-gate
453 schedule (the clocks must be synchronized by a 1588 application stack, which is
454 outside the scope of this document). No packet delivered by the sender will be
455 dropped. 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
457 delay of the link (which can be determined by the 1588 application stack).
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 \
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 \
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 \
488 The engine used to schedule the ingress gate operations is the same that the
489 one used for the tc-taprio offload. Therefore, the restrictions regarding the
490 fact that no two gate actions (either tc-gate or tc-taprio gates) may fire at
491 the same time (during the same 200 ns slot) still apply.
493 To come in handy, it is possible to share time-triggered virtual links across
494 more than 1 ingress port, via flow blocks. In this case, the restriction of
495 firing at the same time does not apply because there is a single schedule in
496 the system, that of the shared virtual link::
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 \
503 sched-entry OPEN 50000000 -1 -1 \
504 sched-entry CLOSE 50000000 -1 -1 \
507 Hardware statistics for each flow are also available ("pkts" counts the number
508 of dropped frames, which is a sum of frames dropped due to timing violations,
509 lack of destination ports and MTU enforcement checks). Byte-level counters are
512 Device Tree bindings and board design
513 =====================================
515 This section references ``Documentation/devicetree/bindings/net/dsa/sja1105.txt``
516 and aims to showcase some potential switch caveats.
518 RMII PHY role and out-of-band signaling
519 ---------------------------------------
521 In the RMII spec, the 50 MHz clock signals are either driven by the MAC or by
522 an external oscillator (but not by the PHY).
523 But the spec is rather loose and devices go outside it in several ways.
524 Some PHYs go against the spec and may provide an output pin where they source
525 the 50 MHz clock themselves, in an attempt to be helpful.
526 On the other hand, the SJA1105 is only binary configurable - when in the RMII
527 MAC role it will also attempt to drive the clock signal. To prevent this from
528 happening it must be put in RMII PHY role.
529 But doing so has some unintended consequences.
530 In the RMII spec, the PHY can transmit extra out-of-band signals via RXD[1:0].
531 These are practically some extra code words (/J/ and /K/) sent prior to the
532 preamble of each frame. The MAC does not have this out-of-band signaling
533 mechanism defined by the RMII spec.
534 So when the SJA1105 port is put in PHY role to avoid having 2 drivers on the
535 clock signal, inevitably an RMII PHY-to-PHY connection is created. The SJA1105
536 emulates a PHY interface fully and generates the /J/ and /K/ symbols prior to
537 frame preambles, which the real PHY is not expected to understand. So the PHY
538 simply encodes the extra symbols received from the SJA1105-as-PHY onto the
540 On the other side of the wire, some link partners might discard these extra
541 symbols, while others might choke on them and discard the entire Ethernet
542 frames that follow along. This looks like packet loss with some link partners
544 The take-away is that in RMII mode, the SJA1105 must be let to drive the
545 reference clock if connected to a PHY.
547 RGMII fixed-link and internal delays
548 ------------------------------------
550 As mentioned in the bindings document, the second generation of devices has
551 tunable delay lines as part of the MAC, which can be used to establish the
552 correct RGMII timing budget.
553 When powered up, these can shift the Rx and Tx clocks with a phase difference
554 between 73.8 and 101.7 degrees.
555 The catch is that the delay lines need to lock onto a clock signal with a
556 stable frequency. This means that there must be at least 2 microseconds of
557 silence between the clock at the old vs at the new frequency. Otherwise the
558 lock is lost and the delay lines must be reset (powered down and back up).
559 In RGMII the clock frequency changes with link speed (125 MHz at 1000 Mbps, 25
560 MHz at 100 Mbps and 2.5 MHz at 10 Mbps), and link speed might change during the
562 In the situation where the switch port is connected through an RGMII fixed-link
563 to 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
565 inactive) until there is manual intervention (ifdown/ifup on the switch port).
566 The take-away is that in RGMII mode, the switch's internal delays are only
567 reliable if the link partner never changes link speeds, or if it does, it does
568 so in a way that is coordinated with the switch port (practically, both ends of
569 the fixed-link are under control of the same Linux system).
570 As to why would a fixed-link interface ever change link speeds: there are
571 Ethernet controllers out there which come out of reset in 100 Mbps mode, and
572 their driver inevitably needs to change the speed and clock frequency if it's
573 required to work at gigabit.
575 MDIO bus and PHY management
576 ---------------------------
578 The SJA1105 does not have an MDIO bus and does not perform in-band AN either.
579 Therefore there is no link state notification coming from the switch device.
580 A board would need to hook up the PHYs connected to the switch to any other
581 MDIO bus available to Linux within the system (e.g. to the DSA master's MDIO
582 bus). 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.
585 By comparison, the SJA1110 supports an MDIO slave access point over which its
586 internal 100base-T1 PHYs can be accessed from the host. This is, however, not
587 used by the driver, instead the internal 100base-T1 and 100base-TX PHYs are
588 accessed through SPI commands, modeled in Linux as virtual MDIO buses.
590 The microcontroller attached to the SJA1110 port 0 also has an MDIO controller
591 operating in master mode, however the driver does not support this either,
592 since the microcontroller gets disabled when the Linux driver operates.
593 Discrete PHYs connected to the switch ports should have their MDIO interface
594 attached to an MDIO controller from the host system and not to the switch,
597 Port compatibility matrix
598 -------------------------
600 The SJA1105 port compatibility matrix is:
602 ===== ============== ============== ==============
603 Port SJA1105E/T SJA1105P/Q SJA1105R/S
604 ===== ============== ============== ==============
610 ===== ============== ============== ==============
613 The SJA1110 port compatibility matrix is:
615 ===== ============== ============== ============== ==============
616 Port SJA1110A SJA1110B SJA1110C SJA1110D
617 ===== ============== ============== ============== ==============
618 0 RevMII (uC) RevMII (uC) RevMII (uC) RevMII (uC)
619 1 100base-TX 100base-TX 100base-TX
621 2 xMII xMII xMII xMII
624 or SGMII or SGMII SGMII
625 or 2500base-X or 2500base-X or 2500base-X
626 4 SGMII SGMII SGMII SGMII
627 or 2500base-X or 2500base-X or 2500base-X or 2500base-X
628 5 100base-T1 100base-T1 100base-T1 100base-T1
629 6 100base-T1 100base-T1 100base-T1 100base-T1
630 7 100base-T1 100base-T1 100base-T1 100base-T1
631 8 100base-T1 100base-T1 n/a n/a
632 9 100base-T1 100base-T1 n/a n/a
633 10 100base-T1 n/a n/a n/a
634 ===== ============== ============== ============== ==============