sja1105.rst 26 KB

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