NXP SJA1105 switch driver

제품군과 정적 구성

NXP SJA1105 제품군은 SPI로 관리하는 차량용 스위치 10종입니다. 1세대 E는 TTEthernet이 없고 T는 지원합니다. 2세대 P는 TTEthernet과 SGMII가 없고, Q는 TTEthernet만, R은 SGMII만, S는 둘 다 지원합니다. 3세대 SJA1110 A/B/C/D는 TTEthernet과 SGMII를 지원하며 모델별로 통합 100base-T1 및 100base-TX PHY 수가 다릅니다.

차량용 부품 특성상 설정 후 거의 건드리지 않는 방식에 맞춰져 있습니다. 소프트웨어는 여러 설정 테이블을 조합하고 CRC와 테이블 헤더를 붙여 SPI로 전송합니다. 일부 테이블은 런타임에 전부 또는 일부 재구성할 수 있지만 나머지는 정적입니다. 설정은 몇 가지 예외를 제외하면 읽어 올 수 없는 write-only입니다.

드라이버는 probe 때 정적 구성을 만들고 하드웨어 상태의 shadow로 메모리에 계속 보관합니다. 설정을 바꾸면 shadow도 갱신합니다. 동적 재구성 인터페이스로 보낼 수 있는 항목은 즉시 전송하고, 그렇지 않으면 스위치를 reset한 뒤 갱신한 정적 구성 전체를 다시 프로그램합니다.

=========================
NXP SJA1105 switch driver
=========================

Overview
========

The NXP SJA1105 is a family of 10 SPI-managed automotive switches:

- SJA1105E: First generation, no TTEthernet
- SJA1105T: First generation, TTEthernet
- SJA1105P: Second generation, no TTEthernet, no SGMII
- SJA1105Q: Second generation, TTEthernet, no SGMII
- SJA1105R: Second generation, no TTEthernet, SGMII
- SJA1105S: Second generation, TTEthernet, SGMII
- SJA1110A: Third generation, TTEthernet, SGMII, integrated 100base-T1 and
  100base-TX PHYs
- SJA1110B: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX
- SJA1110C: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX
- SJA1110D: Third generation, TTEthernet, SGMII, 100base-T1

Being automotive parts, their configuration interface is geared towards
set-and-forget use, with minimal dynamic interaction at runtime. They
require a static configuration to be composed by software and packed
with CRC and table headers, and sent over SPI.

The static configuration is composed of several configuration tables. Each
table takes a number of entries. Some configuration tables can be (partially)
reconfigured at runtime, some not. Some tables are mandatory, some not:

============================= ================== =============================
Table                          Mandatory          Reconfigurable
============================= ================== =============================
Schedule                       no                 no
Schedule entry points          if Scheduling      no
VL Lookup                      no                 no
VL Policing                    if VL Lookup       no
VL Forwarding                  if VL Lookup       no
L2 Lookup                      no                 no
L2 Policing                    yes                no
VLAN Lookup                    yes                yes
L2 Forwarding                  yes                partially (fully on P/Q/R/S)
MAC Config                     yes                partially (fully on P/Q/R/S)
Schedule Params                if Scheduling      no
Schedule Entry Points Params   if Scheduling      no
VL Forwarding Params           if VL Forwarding   no
L2 Lookup Params               no                 partially (fully on P/Q/R/S)
L2 Forwarding Params           yes                no
Clock Sync Params              no                 no
AVB Params                     no                 no
General Params                 yes                partially
Retagging                      no                 yes
xMII Params                    yes                no
SGMII                          no                 yes
============================= ================== =============================


Also the configuration is write-only (software cannot read it back from the
switch except for very few exceptions).

The driver creates a static configuration at probe time, and keeps it at
all times in memory, as a shadow for the hardware state. When required to
change a hardware setting, the static configuration is also updated.
If that changed setting can be transmitted to the switch through the dynamic
reconfiguration interface, it is; otherwise the switch is reset and
reprogrammed with the updated static configuration.

스위칭 기능

드라이버는 포트 브리징을 위한 L2 전달 규칙을 하드웨어에 설정합니다. 브리지 사이의 격리는 L2 forwarding 수준에서, 같은 브리지 안 포트의 격리는 VLAN membership 수준에서 수행할 수 있으며 최종 전달 결정은 두 규칙 집합의 논리 AND입니다.

하드웨어는 모든 트래픽에 포트 기반 VLAN(PVID)을 내부적으로 붙이거나 802.1Q 태그를 해석합니다. 고급 VLAN 분류는 지원하지 않습니다. VLAN이 정해진 프레임은 입구 포트 membership 규칙과 맞지 않으면 ingress에서 폐기합니다. 이 동작은 포트가 `vlan_filtering 1`인 브리지에 가입할 때 사용됩니다.

하드웨어의 VLAN 인지 여부를 직접 끌 수는 없지만, 스위치가 802.1Q 태그로 찾는 TPID를 바꿔 `vlan_filtering 0`의 의미, 즉 태그 유무와 관계없이 모든 트래픽 수용을 구현합니다. 여러 브리지로 포트를 나눌 수 있지만 모든 브리지는 같은 VLAN 인지 상태여야 합니다. STP를 통한 토폴로지 및 loop 탐지도 지원합니다.

Switching features
==================

The driver supports the configuration of L2 forwarding rules in hardware for
port bridging. The forwarding, broadcast and flooding domain between ports can
be restricted through two methods: either at the L2 forwarding level (isolate
one bridge's ports from another's) or at the VLAN port membership level
(isolate ports within the same bridge). The final forwarding decision taken by
the hardware is a logical AND of these two sets of rules.

The hardware tags all traffic internally with a port-based VLAN (pvid), or it
decodes the VLAN information from the 802.1Q tag. Advanced VLAN classification
is not possible. Once attributed a VLAN tag, frames are checked against the
port's membership rules and dropped at ingress if they don't match any VLAN.
This behavior is available when switch ports join a bridge with
``vlan_filtering 1``.

Normally the hardware is not configurable with respect to VLAN awareness, but
by changing what TPID the switch searches 802.1Q tags for, the semantics of a
bridge with ``vlan_filtering 0`` can be kept (accept all traffic, tagged or
untagged), and therefore this mode is also supported.

Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but
all bridges should have the same level of VLAN awareness (either both have
``vlan_filtering`` 0, or both 1).

Topology and loop detection through STP is supported.

시간 인지 송신 스케줄링

스위치는 IEEE 802.1Q-2018의 scheduled traffic 기능(이전 802.1Qbv)을 변형해 지원합니다. 네트워크 스케줄에서 gate가 열리는 시점과 맞춘 우선순위 트래픽에 결정적 지연 시간을 제공하며 `tc-taprio` 하드웨어 오프로드의 `flags 2`로 설정합니다. 소프트웨어 taprio가 CPU 발생 트래픽만 shaping하는 것과 달리 자율 전달 흐름도 제어합니다.

8개 traffic class가 있으며 VLAN이 있으면 PCP, 없으면 포트 기본값으로 분류합니다. `vlan_filtering=0`에서는 스위치가 일반 `0x8100`을 VLAN으로 인식하지 않으므로 PCP를 무시하고 DSA netdev가 송신 태깅 헤더의 PCP를 채워야 합니다. `vlan_filtering=1`에서는 반대로 오프로드 흐름을 VLAN PCP로 TX queue에 보낼 수 있지만 DSA netdev가 직접 queue를 고를 수 없습니다. 이때 특정 queue로 주입하려면 DSA conduit에 VLAN 하위 인터페이스를 만들고 올바른 PCP의 일반 0x8100 프레임을 보내야 합니다.

DMAC `01-80-C2-xx-xx-xx` 또는 `01-19-1B-xx-xx-xx`인 관리 트래픽은 예외로, PCP와 무관하게 고정 최고 우선순위 traffic class 7을 사용하며 현재 드라이버에서 바꿀 수 없습니다.

예제는 `swp5`에 500us 주기 스케줄을 만들고 class 7 gate를 100us, 나머지 class gate를 400us 엽니다. `ptp4l`이 실행 중인지 확인하고 PHC 시간에서 다음 정각 초를 base time으로 계산한 다음 `tc qdisc ... taprio`를 설치합니다. 여러 출구 포트에 적용할 수 있지만 두 포트의 gate event가 동시에 발생할 수 없으므로 드라이버가 스케줄 충돌을 검사하고 오류를 반환합니다. 충돌을 피할 스케줄 분석은 이 문서 범위 밖입니다.

Offloads
========

Time-aware scheduling
---------------------

The switch supports a variation of the enhancements for scheduled traffic
specified in IEEE 802.1Q-2018 (formerly 802.1Qbv). This means it can be used to
ensure deterministic latency for priority traffic that is sent in-band with its
gate-open event in the network schedule.

This capability can be managed through the tc-taprio offload ('flags 2'). The
difference compared to the software implementation of taprio is that the latter
would only be able to shape traffic originated from the CPU, but not
autonomously forwarded flows.

The device has 8 traffic classes, and maps incoming frames to one of them based
on the VLAN PCP bits (if no VLAN is present, the port-based default is used).
As described in the previous sections, depending on the value of
``vlan_filtering``, the EtherType recognized by the switch as being VLAN can
either be the typical 0x8100 or a custom value used internally by the driver
for tagging. Therefore, the switch ignores the VLAN PCP if used in standalone
or bridge mode with ``vlan_filtering=0``, as it will not recognize the 0x8100
EtherType. In these modes, injecting into a particular TX queue can only be
done by the DSA net devices, which populate the PCP field of the tagging header
on egress. Using ``vlan_filtering=1``, the behavior is the other way around:
offloaded flows can be steered to TX queues based on the VLAN PCP, but the DSA
net devices are no longer able to do that. To inject frames into a hardware TX
queue with VLAN awareness active, it is necessary to create a VLAN
sub-interface on the DSA conduit port, and send normal (0x8100) VLAN-tagged
towards the switch, with the VLAN PCP bits set appropriately.

Management traffic (having DMAC 01-80-C2-xx-xx-xx or 01-19-1B-xx-xx-xx) is the
notable exception: the switch always treats it with a fixed priority and
disregards any VLAN PCP bits even if present. The traffic class for management
traffic has a value of 7 (highest priority) at the moment, which is not
configurable in the driver.

Below is an example of configuring a 500 us cyclic schedule on egress port
``swp5``. The traffic class gate for management traffic (7) is open for 100 us,
and the gates for all other traffic classes are open for 400 us::

  #!/bin/bash

  set -e -u -o pipefail

  NSEC_PER_SEC="1000000000"

  gatemask() {
          local tc_list="$1"
          local mask=0

          for tc in ${tc_list}; do
                  mask=$((${mask} | (1 << ${tc})))
          done

          printf "%02x" ${mask}
  }

  if ! systemctl is-active --quiet ptp4l; then
          echo "Please start the ptp4l service"
          exit
  fi

  now=$(phc_ctl /dev/ptp1 get | gawk '/clock time is/ { print $5; }')
  # Phase-align the base time to the start of the next second.
  sec=$(echo "${now}" | gawk -F. '{ print $1; }')
  base_time="$(((${sec} + 1) * ${NSEC_PER_SEC}))"

  tc qdisc add dev swp5 parent root handle 100 taprio \
          num_tc 8 \
          map 0 1 2 3 5 6 7 \
          queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
          base-time ${base_time} \
          sched-entry S $(gatemask 7) 100000 \
          sched-entry S $(gatemask "0 1 2 3 4 5 6") 400000 \
          flags 2

It is possible to apply the tc-taprio offload on multiple egress ports. There
are hardware restrictions related to the fact that no gate event may trigger
simultaneously on two ports. The driver checks the consistency of the schedules
against this restriction and errors out when appropriate. Schedule analysis is
needed to avoid this, which is outside the scope of the document.

라우팅 동작: redirect, trap, drop

스위치는 사용자가 지정한 목적지 포트 집합으로 흐름 기반 패킷 redirect를 오프로드하며 내부적으로 TTEthernet의 Virtual Link를 사용합니다. VLAN 인지 Virtual Link는 목적지 MAC, VLAN ID와 VLAN PCP를 키로 쓰고, VLAN 비인지 Virtual Link는 목적지 MAC만 일치시킵니다. Virtual Link 규칙이 설치된 동안에는 브리지의 `vlan_filtering` 상태를 바꿀 수 없습니다.

한 규칙에 여러 action을 조합할 수 있습니다. routing action만 있으면 non-critical Virtual Link를 만들고, `tc-gate`까지 있으면 예약 frame buffer 영역을 사용하는 time-critical Virtual Link가 됩니다. 지원 action은 `trap`, `drop`, `redirect` 세 가지입니다.

첫 예제는 `swp2`에서 목적지 MAC `42:be:24:9b:76:20`인 프레임을 `swp3`와 CPU로 보내기 위해 `clsact`, `flower skip_sw`, `mirred redirect`, `trap`을 조합합니다. 두 번째 예제는 VID 100, PCP 0, 같은 목적지 MAC인 802.1Q 프레임을 `drop`합니다.

Routing actions (redirect, trap, drop)
--------------------------------------

The switch is able to offload flow-based redirection of packets to a set of
destination ports specified by the user. Internally, this is implemented by
making use of Virtual Links, a TTEthernet concept.

The driver supports 2 types of keys for Virtual Links:

- VLAN-aware virtual links: these match on destination MAC address, VLAN ID and
  VLAN PCP.
- VLAN-unaware virtual links: these match on destination MAC address only.

The VLAN awareness state of the bridge (vlan_filtering) cannot be changed while
there are virtual link rules installed.

Composing multiple actions inside the same rule is supported. When only routing
actions are requested, the driver creates a "non-critical" virtual link. When
the action list also contains tc-gate (more details below), the virtual link
becomes "time-critical" (draws frame buffers from a reserved memory partition,
etc).

The 3 routing actions that are supported are "trap", "drop" and "redirect".

Example 1: send frames received on swp2 with a DA of 42:be:24:9b:76:20 to the
CPU and to swp3. This type of key (DA only) when the port's VLAN awareness
state is off::

  tc qdisc add dev swp2 clsact
  tc filter add dev swp2 ingress flower skip_sw dst_mac 42:be:24:9b:76:20 \
          action mirred egress redirect dev swp3 \
          action trap

Example 2: drop frames received on swp2 with a DA of 42:be:24:9b:76:20, a VID
of 100 and a PCP of 0::

  tc filter add dev swp2 ingress protocol 802.1Q flower skip_sw \
          dst_mac 42:be:24:9b:76:20 vlan_id 100 vlan_prio 0 action drop

시간 기반 ingress policing

TTEthernet 기능을 IEEE 802.1Q-2018의 Per-Stream Filtering and Policing(이전 802.1Qci)처럼 제한해 최대 1,024개 흐름에 정밀한 시간 기반 admission control을 적용할 수 있습니다. 흐름은 목적지 MAC, VLAN ID, VLAN PCP 튜플로 식별하며 예상 수신 창 밖의 패킷은 폐기합니다.

기능은 `tc-gate` action 오프로드로 관리합니다. TTEthernet의 Virtual Link는 FDB나 flood에 맡기지 않고 목적지를 명시해야 하므로 `tc-gate`를 단독으로 사용할 수 없고 하나 이상의 redirect 또는 trap action이 뒤따라야 합니다.

예제는 IEEE 1588 애플리케이션이 동기화한 clock을 전제로 수신기의 `tc-gate`와 송신기의 `tc-taprio` base time을 맞춥니다. 전파 지연을 보상하기 위해 수신 창을 송신 창보다 크게 잡습니다. ingress gate와 taprio는 같은 스케줄 엔진을 사용하므로 어느 두 gate action도 같은 200ns slot에서 발화할 수 없습니다.

flow block을 이용하면 하나의 time-triggered Virtual Link를 여러 ingress 포트가 공유할 수 있습니다. 이때 시스템에 공유 Virtual Link 스케줄 하나만 있으므로 동시 발화 제한이 적용되지 않습니다. 흐름별 하드웨어 통계의 `pkts`는 timing 위반, 목적지 포트 부재, MTU enforcement 때문에 폐기된 프레임 합계이며 byte counter는 제공하지 않습니다.

Time-based ingress policing
---------------------------

The TTEthernet hardware abilities of the switch can be constrained to act
similarly to the Per-Stream Filtering and Policing (PSFP) clause specified in
IEEE 802.1Q-2018 (formerly 802.1Qci). This means it can be used to perform
tight timing-based admission control for up to 1024 flows (identified by a
tuple composed of destination MAC address, VLAN ID and VLAN PCP). Packets which
are received outside their expected reception window are dropped.

This capability can be managed through the offload of the tc-gate action. As
routing actions are intrinsic to virtual links in TTEthernet (which performs
explicit routing of time-critical traffic and does not leave that in the hands
of the FDB, flooding etc), the tc-gate action may never appear alone when
asking sja1105 to offload it. One (or more) redirect or trap actions must also
follow along.

Example: create a tc-taprio schedule that is phase-aligned with a tc-gate
schedule (the clocks must be synchronized by a 1588 application stack, which is
outside the scope of this document). No packet delivered by the sender will be
dropped. Note that the reception window is larger than the transmission window
(and much more so, in this example) to compensate for the packet propagation
delay of the link (which can be determined by the 1588 application stack).

Receiver (sja1105)::

  tc qdisc add dev swp2 clsact
  now=$(phc_ctl /dev/ptp1 get | awk '/clock time is/ {print $5}') && \
          sec=$(echo $now | awk -F. '{print $1}') && \
          base_time="$(((sec + 2) * 1000000000))" && \
          echo "base time ${base_time}"
  tc filter add dev swp2 ingress flower skip_sw \
          dst_mac 42:be:24:9b:76:20 \
          action gate base-time ${base_time} \
          sched-entry OPEN  60000 -1 -1 \
          sched-entry CLOSE 40000 -1 -1 \
          action trap

Sender::

  now=$(phc_ctl /dev/ptp0 get | awk '/clock time is/ {print $5}') && \
          sec=$(echo $now | awk -F. '{print $1}') && \
          base_time="$(((sec + 2) * 1000000000))" && \
          echo "base time ${base_time}"
  tc qdisc add dev eno0 parent root taprio \
          num_tc 8 \
          map 0 1 2 3 4 5 6 7 \
          queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
          base-time ${base_time} \
          sched-entry S 01  50000 \
          sched-entry S 00  50000 \
          flags 2

The engine used to schedule the ingress gate operations is the same that the
one used for the tc-taprio offload. Therefore, the restrictions regarding the
fact that no two gate actions (either tc-gate or tc-taprio gates) may fire at
the same time (during the same 200 ns slot) still apply.

To come in handy, it is possible to share time-triggered virtual links across
more than 1 ingress port, via flow blocks. In this case, the restriction of
firing at the same time does not apply because there is a single schedule in
the system, that of the shared virtual link::

  tc qdisc add dev swp2 ingress_block 1 clsact
  tc qdisc add dev swp3 ingress_block 1 clsact
  tc filter add block 1 flower skip_sw dst_mac 42:be:24:9b:76:20 \
          action gate index 2 \
          base-time 0 \
          sched-entry OPEN 50000000 -1 -1 \
          sched-entry CLOSE 50000000 -1 -1 \
          action trap

Hardware statistics for each flow are also available ("pkts" counts the number
of dropped frames, which is a sum of frames dropped due to timing violations,
lack of destination ports and MTU enforcement checks). Byte-level counters are
not available.

Virtual Link의 한계

SJA1105 계열은 항상 VLAN 처리를 합니다. VLAN 비인지 모드에서도 독립 포트인지 VLAN 비인지 브리지 포트인지에 따라 서로 다른 내부 VLAN 태그가 붙습니다. Virtual Link 하드웨어 키는 항상 `{MAC DA, VLAN ID, VLAN PCP}`로 고정됩니다. VLAN 인지 브리지에서는 사용자가 VLAN ID와 PCP를 제공하고, 그 밖에는 드라이버가 포트 상태에 따라 자동으로 채우며 MAC DA만 있는 VLAN 비인지 `tc-flower` 키를 받습니다.

독립 포트가 브리지에 가입하거나, 브리지의 VLAN 인지 상태가 바뀌거나, 브리지 포트가 독립 포트가 되거나, 다른 포트가 VLAN 인지 브리지에 가입해 전역 VLAN 인지 상태가 바뀌면 기존 Virtual Link 기반 `tc-flower` 오프로드 키가 더 이상 동작하지 않습니다. 드라이버는 이 모든 변화를 거부할 수도, 기존 필터를 자동 갱신·삭제할 수도 없습니다. 따라서 포트 전달 구성을 끝낸 뒤 필터를 설치하고 구성을 바꾸기 전에 사용자 공간에서 제거해야 합니다.

Limitations
===========

The SJA1105 switch family always performs VLAN processing. When configured as
VLAN-unaware, frames carry a different VLAN tag internally, depending on
whether the port is standalone or under a VLAN-unaware bridge.

The virtual link keys are always fixed at {MAC DA, VLAN ID, VLAN PCP}, but the
driver asks for the VLAN ID and VLAN PCP when the port is under a VLAN-aware
bridge. Otherwise, it fills in the VLAN ID and PCP automatically, based on
whether the port is standalone or in a VLAN-unaware bridge, and accepts only
"VLAN-unaware" tc-flower keys (MAC DA).

The existing tc-flower keys that are offloaded using virtual links are no
longer operational after one of the following happens:

- port was standalone and joins a bridge (VLAN-aware or VLAN-unaware)
- port is part of a bridge whose VLAN awareness state changes
- port was part of a bridge and becomes standalone
- port was standalone, but another port joins a VLAN-aware bridge and this
  changes the global VLAN awareness state of the bridge

The driver cannot veto all these operations, and it cannot update/remove the
existing tc-flower filters either. So for proper operation, the tc-flower
filters should be installed only after the forwarding configuration of the port
has been made, and removed by user space before making any changes to it.

Device Tree와 보드 설계

이 절은 `Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml` 바인딩을 바탕으로 RMII, RGMII, MDIO 및 포트 호환성에서 발생할 수 있는 보드 설계상의 주의점을 설명합니다.

Device Tree bindings and board design
=====================================

This section references ``Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml``
and aims to showcase some potential switch caveats.

RMII PHY 역할과 대역 외 신호

RMII 규격에서 50MHz clock은 MAC 또는 외부 oscillator가 구동하며 PHY가 구동하지 않는 것이 원칙입니다. 하지만 일부 PHY가 편의상 clock 출력 핀을 제공할 수 있습니다. SJA1105는 RMII MAC 역할이면 자신도 clock을 구동하므로 두 출력의 충돌을 막으려면 RMII PHY 역할로 둘 수 있지만 부작용이 생깁니다.

RMII PHY는 RXD[1:0]으로 프레임 preamble 앞에 `/J/`, `/K/` 대역 외 code word를 보낼 수 있지만 MAC에는 이 방식이 정의되지 않습니다. SJA1105를 PHY 역할로 두면 실제 PHY와 PHY-to-PHY 연결이 되어 SJA1105가 생성한 `/J/`, `/K/`를 실제 PHY가 100Base-TX 선로에 그대로 인코딩합니다. 원격 link partner에 따라 이를 무시하거나 뒤의 전체 프레임을 폐기해 상대에 따른 packet loss처럼 보일 수 있습니다. 결론적으로 PHY에 연결한 RMII 구성에서는 SJA1105가 reference clock을 구동하게 해야 합니다.

RMII PHY role and out-of-band signaling
---------------------------------------

In the RMII spec, the 50 MHz clock signals are either driven by the MAC or by
an external oscillator (but not by the PHY).
But the spec is rather loose and devices go outside it in several ways.
Some PHYs go against the spec and may provide an output pin where they source
the 50 MHz clock themselves, in an attempt to be helpful.
On the other hand, the SJA1105 is only binary configurable - when in the RMII
MAC role it will also attempt to drive the clock signal. To prevent this from
happening it must be put in RMII PHY role.
But doing so has some unintended consequences.
In the RMII spec, the PHY can transmit extra out-of-band signals via RXD[1:0].
These are practically some extra code words (/J/ and /K/) sent prior to the
preamble of each frame. The MAC does not have this out-of-band signaling
mechanism defined by the RMII spec.
So when the SJA1105 port is put in PHY role to avoid having 2 drivers on the
clock signal, inevitably an RMII PHY-to-PHY connection is created. The SJA1105
emulates a PHY interface fully and generates the /J/ and /K/ symbols prior to
frame preambles, which the real PHY is not expected to understand. So the PHY
simply encodes the extra symbols received from the SJA1105-as-PHY onto the
100Base-Tx wire.
On the other side of the wire, some link partners might discard these extra
symbols, while others might choke on them and discard the entire Ethernet
frames that follow along. This looks like packet loss with some link partners
but not with others.
The take-away is that in RMII mode, the SJA1105 must be let to drive the
reference clock if connected to a PHY.

RGMII fixed-link와 내부 지연

2세대 장치의 MAC에는 RGMII timing budget을 맞추는 조정 가능한 delay line이 있으며 전원 인가 시 Rx/Tx clock을 73.8~101.7도 위상차로 이동할 수 있습니다. 이 회로는 안정된 주파수에 lock해야 하므로 이전 주파수와 새 주파수 clock 사이에 최소 2us의 무신호 구간이 필요합니다. 그렇지 않으면 lock을 잃고 전원을 내렸다 다시 올려 reset해야 합니다.

RGMII clock은 1Gbps에서 125MHz, 100Mbps에서 25MHz, 10Mbps에서 2.5MHz이며 자동 협상 중 속도가 바뀔 수 있습니다. 다른 SoC처럼 Linux가 link 수명 주기를 제어하지 못하는 상대와 fixed-link로 연결하면 delay line이 unlock 상태로 남아 `ifdown`/`ifup` 전까지 비활성일 수 있습니다. 따라서 내부 delay는 상대 속도가 바뀌지 않거나 같은 Linux 시스템이 양쪽 변화를 조정할 때만 신뢰할 수 있습니다. 일부 컨트롤러가 reset 뒤 100Mbps로 시작해 드라이버가 1Gbps로 바꾸는 경우도 주의해야 합니다.

RGMII fixed-link and internal delays
------------------------------------

As mentioned in the bindings document, the second generation of devices has
tunable delay lines as part of the MAC, which can be used to establish the
correct RGMII timing budget.
When powered up, these can shift the Rx and Tx clocks with a phase difference
between 73.8 and 101.7 degrees.
The catch is that the delay lines need to lock onto a clock signal with a
stable frequency. This means that there must be at least 2 microseconds of
silence between the clock at the old vs at the new frequency. Otherwise the
lock is lost and the delay lines must be reset (powered down and back up).
In RGMII the clock frequency changes with link speed (125 MHz at 1000 Mbps, 25
MHz at 100 Mbps and 2.5 MHz at 10 Mbps), and link speed might change during the
AN process.
In the situation where the switch port is connected through an RGMII fixed-link
to a link partner whose link state life cycle is outside the control of Linux
(such as a different SoC), then the delay lines would remain unlocked (and
inactive) until there is manual intervention (ifdown/ifup on the switch port).
The take-away is that in RGMII mode, the switch's internal delays are only
reliable if the link partner never changes link speeds, or if it does, it does
so in a way that is coordinated with the switch port (practically, both ends of
the fixed-link are under control of the same Linux system).
As to why would a fixed-link interface ever change link speeds: there are
Ethernet controllers out there which come out of reset in 100 Mbps mode, and
their driver inevitably needs to change the speed and clock frequency if it's
required to work at gigabit.

MDIO 버스와 PHY 관리

SJA1105에는 MDIO 버스가 없고 in-band 자동 협상도 하지 않으므로 스위치 자체에서 link 상태 알림이 오지 않습니다. 보드는 각 포트 PHY를 DSA conduit의 MDIO 버스 같은 Linux가 접근 가능한 다른 MDIO 컨트롤러에 연결해야 합니다. 드라이버는 PHY가 협상한 설정과 MAC link 속도를 SPI 명령으로 수동 동기화합니다.

SJA1110은 내부 100base-T1 PHY에 접근할 MDIO slave access point가 있지만 드라이버는 이를 쓰지 않고 SPI 명령을 Linux의 가상 MDIO 버스로 모델링해 내부 100base-T1/100base-TX PHY에 접근합니다. 포트 0 microcontroller의 master MDIO 컨트롤러도 Linux 드라이버 동작 중 microcontroller가 비활성화되므로 지원하지 않습니다. 외부 PHY의 MDIO는 SJA1105와 마찬가지로 스위치가 아닌 호스트 MDIO 컨트롤러에 연결해야 합니다.

MDIO bus and PHY management
---------------------------

The SJA1105 does not have an MDIO bus and does not perform in-band AN either.
Therefore there is no link state notification coming from the switch device.
A board would need to hook up the PHYs connected to the switch to any other
MDIO bus available to Linux within the system (e.g. to the DSA conduit's MDIO
bus). Link state management then works by the driver manually keeping in sync
(over SPI commands) the MAC link speed with the settings negotiated by the PHY.

By comparison, the SJA1110 supports an MDIO slave access point over which its
internal 100base-T1 PHYs can be accessed from the host. This is, however, not
used by the driver, instead the internal 100base-T1 and 100base-TX PHYs are
accessed through SPI commands, modeled in Linux as virtual MDIO buses.

The microcontroller attached to the SJA1110 port 0 also has an MDIO controller
operating in master mode, however the driver does not support this either,
since the microcontroller gets disabled when the Linux driver operates.
Discrete PHYs connected to the switch ports should have their MDIO interface
attached to an MDIO controller from the host system and not to the switch,
similar to SJA1105.

포트 호환성 표

SJA1105E/T와 P/Q의 포트 0~4는 모두 xMII를 지원합니다. SJA1105R/S는 포트 0~3이 xMII이고 포트 4가 SGMII입니다.

SJA1110의 포트 0은 모든 모델에서 microcontroller용 RevMII입니다. 포트 1은 A/B/C에서 100base-TX이고 A는 SGMII도 지원하며 D는 SGMII입니다. 포트 2는 모두 xMII이고 D는 SGMII도 지원합니다. 포트 3은 모델별로 xMII, SGMII, 2500base-X 조합이 다르며 포트 4는 모두 SGMII 또는 2500base-X입니다. 포트 5~7은 모두 100base-T1, 포트 8~9는 A/B만 100base-T1, 포트 10은 A만 100base-T1입니다.

Port compatibility matrix
-------------------------

The SJA1105 port compatibility matrix is:

===== ============== ============== ==============
Port   SJA1105E/T     SJA1105P/Q     SJA1105R/S
===== ============== ============== ==============
0      xMII           xMII           xMII
1      xMII           xMII           xMII
2      xMII           xMII           xMII
3      xMII           xMII           xMII
4      xMII           xMII           SGMII
===== ============== ============== ==============


The SJA1110 port compatibility matrix is:

===== ============== ============== ============== ==============
Port   SJA1110A       SJA1110B       SJA1110C       SJA1110D
===== ============== ============== ============== ==============
0      RevMII (uC)    RevMII (uC)    RevMII (uC)    RevMII (uC)
1      100base-TX     100base-TX     100base-TX
       or SGMII                                     SGMII
2      xMII           xMII           xMII           xMII
       or SGMII                                     or SGMII
3      xMII           xMII           xMII
       or SGMII       or SGMII                      SGMII
       or 2500base-X  or 2500base-X                 or 2500base-X
4      SGMII          SGMII          SGMII          SGMII
       or 2500base-X  or 2500base-X  or 2500base-X  or 2500base-X
5      100base-T1     100base-T1     100base-T1     100base-T1
6      100base-T1     100base-T1     100base-T1     100base-T1
7      100base-T1     100base-T1     100base-T1     100base-T1
8      100base-T1     100base-T1     n/a            n/a
9      100base-T1     100base-T1     n/a            n/a
10     100base-T1     n/a            n/a            n/a
===== ============== ============== ============== ==============