diff mbox series

[net-next,16/17] Documentation: networking: dsa: Add details about NXP SJA1105 driver

Message ID 20190331174232.22060-17-olteanv@gmail.com
State Changes Requested
Delegated to: David Miller
Headers show
Series NXP SJA1105 DSA driver | expand

Commit Message

Vladimir Oltean March 31, 2019, 5:42 p.m. UTC
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
 Documentation/networking/dsa/sja1105.txt | 83 ++++++++++++++++++++++++
 1 file changed, 83 insertions(+)
 create mode 100644 Documentation/networking/dsa/sja1105.txt

Comments

Andrew Lunn April 2, 2019, 9:24 p.m. UTC | #1
> +The switches do not support switch tagging in hardware. But they do support
> +customizing the TPID by which VLAN traffic is identified as such. The switch
> +driver is leveraging CONFIG_NET_DSA_TAG_8021Q by requesting that special VLANs
> +(with a custom TPID of ETH_P_EDSA instead of ETH_P_8021Q)

Hi Vladimir

Reusing ETH_P_EDSA is possibility going to case problems in tcpdump.
It has code which looks for this Ethertype and uses it to call the
Marvell EDSA header decoder code. This is not going to work for your
switch, where you have a normal VLAN header.

I wounder if we should allocate a new EtherType for this application
of VLANs?

   Andrew
Vladimir Oltean April 3, 2019, 10:09 a.m. UTC | #2
On 4/3/19 12:24 AM, Andrew Lunn wrote:
>> +The switches do not support switch tagging in hardware. But they do support
>> +customizing the TPID by which VLAN traffic is identified as such. The switch
>> +driver is leveraging CONFIG_NET_DSA_TAG_8021Q by requesting that special VLANs
>> +(with a custom TPID of ETH_P_EDSA instead of ETH_P_8021Q)
> 
> Hi Vladimir
> 
> Reusing ETH_P_EDSA is possibility going to case problems in tcpdump.
> It has code which looks for this Ethertype and uses it to call the
> Marvell EDSA header decoder code. This is not going to work for your
> switch, where you have a normal VLAN header.
> 
> I wounder if we should allocate a new EtherType for this application
> of VLANs?
> 
>     Andrew
> 

Hi Andrew,

This makes me wonder whether I would be able to use an EtherType range 
to support cascading switch tags on SJA1105.
In theory if I were to consistently lie to all switches within a switch 
tree, I could make all of them see each other's fake VLAN-tagged traffic 
as untagged.
By the way what is the simple ETH_P_DSA used for?

Thank you,
-Vladimir
Florian Fainelli April 3, 2019, 3:07 p.m. UTC | #3
On 4/3/2019 3:09 AM, Vladimir Oltean wrote:
> On 4/3/19 12:24 AM, Andrew Lunn wrote:
>>> +The switches do not support switch tagging in hardware. But they do
>>> support
>>> +customizing the TPID by which VLAN traffic is identified as such.
>>> The switch
>>> +driver is leveraging CONFIG_NET_DSA_TAG_8021Q by requesting that
>>> special VLANs
>>> +(with a custom TPID of ETH_P_EDSA instead of ETH_P_8021Q)
>>
>> Hi Vladimir
>>
>> Reusing ETH_P_EDSA is possibility going to case problems in tcpdump.
>> It has code which looks for this Ethertype and uses it to call the
>> Marvell EDSA header decoder code. This is not going to work for your
>> switch, where you have a normal VLAN header.
>>
>> I wounder if we should allocate a new EtherType for this application
>> of VLANs?
>>
>>     Andrew
>>
> 
> Hi Andrew,
> 
> This makes me wonder whether I would be able to use an EtherType range
> to support cascading switch tags on SJA1105.
> In theory if I were to consistently lie to all switches within a switch
> tree, I could make all of them see each other's fake VLAN-tagged traffic
> as untagged.
> By the way what is the simple ETH_P_DSA used for?

ETH_P_DSA is not used since commit
3e8a72d1dae374cf6fc1dba97cec663585845ff9 ("net: dsa: reduce number of
protocol hooks") but since it is in an UAPI exported file we probably
cannot remove it.
diff mbox series

Patch

diff --git a/Documentation/networking/dsa/sja1105.txt b/Documentation/networking/dsa/sja1105.txt
new file mode 100644
index 000000000000..b6f2c1bedd02
--- /dev/null
+++ b/Documentation/networking/dsa/sja1105.txt
@@ -0,0 +1,83 @@ 
+NXP SJA1105 switch driver
+=========================
+
+The NXP SJA1105 is a family of 6 devices:
+* 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
+
+These are SPI-managed automotive switches, with all ports being gigabit
+capable, and supporting MII/RMII/RGMII and optionally SGMII on one port.
+
+The switches do not have an MDIO bus of their own and do not support
+in-band autonegotiation, so for proper PHY management, the host's MDIO
+bus controller needs to be used.
+
+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).
+
+So the driver creates the 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.
+
+The switches do not support switch tagging in hardware. But they do support
+customizing the TPID by which VLAN traffic is identified as such. The switch
+driver is leveraging CONFIG_NET_DSA_TAG_8021Q by requesting that special VLANs
+(with a custom TPID of ETH_P_EDSA instead of ETH_P_8021Q) are installed on its
+ports when not in vlan_filtering mode. This does not interfere with the
+reception and transmission of real 802.1Q-tagged traffic, because the switch
+does no longer parse those packets as VLAN after the TPID change.
+The TPID is restored when vlan_filtering is requested, and IP termination
+becomes no longer possible through the switch netdevices in this mode.
+
+The switches have two programmable filters for link-local destination MACs.
+These are used to trap BPDUs and PTP traffic to the master netdevice, and are
+further used to support STP and 1588 ordinary clock/boundary clock
+functionality.
+
+Among other notable features, the switches have a PTP Hardware Clock that can
+be steered through SPI and used for timestamping on ingress and egress.
+Also, the T, Q and S devices support TTEthernet (an implementation of
+SAE AS6802 from TTTech), which is a set of Ethernet QoS enhancements similar in
+behavior to IEEE TSN. Configuring these features is currently not supported in
+the driver.
+