Introduce new DSA switch framework #87045
+973
−345
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,129 @@ | ||
| .. _dsa: | ||
|
|
||
| Distributed Switch Architecture (DSA) | ||
| ##################################### | ||
|
|
||
| .. contents:: | ||
| :local: | ||
| :depth: 2 | ||
|
|
||
| Distributed Switch Architecture (DSA) is not something new. It has been a mature | ||
| subsystem in Linux for many years. This document just skips the background, | ||
| terms and any knowledge related description, as user may find all of these in | ||
| `Linux DSA documentation`_. | ||
|
|
||
|
|
||
| DSA switch TX/RX process | ||
| ************************ | ||
|
|
||
| The DSA switch TX/RX process is as below. | ||
|
|
||
| .. image:: dsa_txrx_process.svg | ||
|
|
||
| Host interface | ||
| ************** | ||
|
|
||
| Host interface network devices use regular and unmodified ethernet driver working | ||
| as DSA conduit port, which manages the switch through processor. | ||
|
|
||
| Switch interface | ||
| **************** | ||
|
|
||
| The switch interfaces are also exposed as standard ethernet interfaces in zephyr. | ||
| The one connected to conduit port work as CPU port, and the others for user purpose | ||
| work as user ports. | ||
|
|
||
| Switch tagging protocols | ||
| ************************ | ||
|
|
||
| Generally, switch tagging protocols are vendor specific. They all contain something which: | ||
|
|
||
| - identifies which port the Ethernet frame came from/should be sent to | ||
| - provides a reason why this frame was forwarded to the management interface | ||
|
|
||
| And tag on the packets to give them a switch frame header. But there are also tag-less case. | ||
| It depends on the vendor. | ||
|
|
||
| Networking stack process | ||
| ************************ | ||
|
|
||
| In order to have the DSA subsystem process the Ethernet switch specific tagging protocol | ||
| via conduit port. | ||
|
|
||
| For RX path, put ``dsa_recv()`` at beginning of ``net_recv_data()`` in ``subsys/net/ip/net_core.c`` | ||
| to handle first for untagging and re-directing interface. | ||
|
|
||
| For TX path, the switch interfaces register as standard ethernet devices with ``dsa_xmit()`` | ||
| as ``ethernet_api->send``. The ``dsa_xmit()`` processes the tagging and re-directing to conduit | ||
| port work. | ||
|
|
||
| DSA device driver support | ||
| ************************* | ||
|
|
||
| As the DSA core driver interacts with subsystems/drivers including MDIO, PHY and device tree to | ||
| to support the common DSA setup and working process. The device driver support is much easy. | ||
|
|
||
| For device tree, the switch description should be following the ``dts/bindings/dsa/dsa.yaml``. | ||
|
|
||
| For device driver, all needed to prepare are :c:struct:`dsa_api`, private data if has, and | ||
| :c:struct:`dsa_port_config`. The macro functions could be utilized. And below is an example | ||
| of i.MX NETC. | ||
|
|
||
| - :c:macro:`DSA_SWITCH_INST_INIT` | ||
| - :c:macro:`DSA_PORT_INST_INIT` | ||
|
|
||
| .. code-block:: c | ||
|
|
||
| #define DSA_NETC_PORT_INST_INIT(port, n) \ | ||
| COND_CODE_1(DT_NUM_PINCTRL_STATES(port), \ | ||
| (PINCTRL_DT_DEFINE(port);), (EMPTY)) \ | ||
| struct dsa_netc_port_config dsa_netc_##n##_##port##_config = { \ | ||
| .pincfg = COND_CODE_1(DT_NUM_PINCTRL_STATES(port), \ | ||
| (PINCTRL_DT_DEV_CONFIG_GET(port)), NULL), \ | ||
| .phy_mode = NETC_PHY_MODE(port), \ | ||
| }; \ | ||
| struct dsa_port_config dsa_##n##_##port##_config = { \ | ||
| .use_random_mac_addr = DT_NODE_HAS_PROP(port, zephyr_random_mac_address), \ | ||
| .mac_addr = DT_PROP_OR(port, local_mac_address, {0}), \ | ||
| .port_idx = DT_REG_ADDR(port), \ | ||
| .phy_dev = DEVICE_DT_GET_OR_NULL(DT_PHANDLE(port, phy_handle)), \ | ||
| .phy_mode = DT_PROP_OR(port, phy_connection_type, ""), \ | ||
| .ethernet_connection = DEVICE_DT_GET_OR_NULL(DT_PHANDLE(port, ethernet)), \ | ||
| .prv_config = &dsa_netc_##n##_##port##_config, \ | ||
| }; \ | ||
| DSA_PORT_INST_INIT(port, n, &dsa_##n##_##port##_config) | ||
|
|
||
| #define DSA_NETC_DEVICE(n) \ | ||
| AT_NONCACHEABLE_SECTION_ALIGN(static netc_cmd_bd_t dsa_netc_##n##_cmd_bd[8], \ | ||
| NETC_BD_ALIGN); \ | ||
| static struct dsa_netc_data dsa_netc_data_##n = { \ | ||
| .cmd_bd = dsa_netc_##n##_cmd_bd, \ | ||
| }; \ | ||
| DSA_SWITCH_INST_INIT(n, &dsa_netc_api, &dsa_netc_data_##n, DSA_NETC_PORT_INST_INIT); | ||
|
|
||
| Common pitfalls using DSA setups | ||
| ******************************** | ||
|
|
||
| This is copied from Linux DSA documentation. It applies to zephyr too. Although conduit port and | ||
| cpu port exposed as ethernet device in zephyr, they are not able to be used. | ||
|
|
||
| .. note:: | ||
|
|
||
| Once a conduit network device is configured to use DSA (dev->dsa_ptr becomes non-NULL), and | ||
| the switch behind it expects a tagging protocol, this network interface can only exclusively | ||
| be used as a conduit interface. Sending packets directly through this interface (e.g.: opening | ||
| a socket using this interface) will not make us go through the switch tagging protocol transmit | ||
| function, so the Ethernet switch on the other end, expecting a tag will typically drop this frame. | ||
|
|
||
| TODO work | ||
| ********* | ||
|
|
||
| Comparing to Linux, there are too much features to support in/based on zephyr DSA. But basically | ||
| bridge layer should be supported. Then DSA could provide two options for users to use switch ports. | ||
|
|
||
| - Standalone mode: all user ports work as regular ethernet devices. No switching. | ||
| - Bridge mode: switch mode enabled with adding user ports into virtual bridge device. IP address could | ||
| be assigned to the bridge. | ||
|
|
||
| .. _Linux DSA documentation: | ||
| https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,20 +4,32 @@ | |
| # Lukasz Majewski <[email protected]> | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| config ETH_DSA_SUPPORT_DEPRECATED | ||
| bool | ||
| help | ||
| Set by an ethernet driver that supports DSA. This is obsolete, | ||
| and only used for legacy dsa device. | ||
|
|
||
| menuconfig NET_DSA | ||
| bool "Distributed Switch Architecture support" | ||
| help | ||
| Enable Distributed Switch Architecture support. | ||
|
|
||
| if NET_DSA | ||
|
|
||
| config NET_DSA_DEPRECATED | ||
| bool "Distributed Switch Architecture support for legacy device" | ||
| select DEPRECATED | ||
| depends on ETH_DSA_SUPPORT_DEPRECATED | ||
| help | ||
| This is obsolete, and only used for legacy dsa device. | ||
|
|
||
| config DSA_PORT_MAX_COUNT | ||
| int "DSA port max count" | ||
| default 8 | ||
| help | ||
| Set DSA port max count. | ||
|
|
||
| config DSA_KSZ8XXX | ||
| bool | ||
|
|
||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This board has Ethernet sockets that have factory MAC address marked to them. Why can't we use the factory set MAC addresses here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may need to have some investigation on how to do that in both zephyr and platform.
Not sure if any fuse related driver needed?
Could you share any factory set MAC address case support in zephyr?
I'd like to support that seperately for NETC and RT1180 platform in another PR if it's okay.
Thank you very much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example NXP frdm_rw612 board has both Wi-Fi and Ethernet. The Wi-Fi is properly using factory set MAC address, but the Ethernet is not. I created an issue for it #88336
I have STM nucleo_f767zi board which uses device id by default a mac address.
zephyr/drivers/ethernet/eth_stm32_hal.c
Line 846 in 1e1f944
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having a separate PR for setting MAC address to fixed value is ok. I was just wondering why NXP is using random MAC address for several boards I have been using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have had some investigation but I have no idea on the reason:(
It looks like the way getting the factory mac address varied from soc/board.
I think for i.MXRT it's from fuse which may read via
hal/nxp/mcux/mcux-sdk-ng/drivers/ocotpdriver.For some i.MX8 and i.MX9, it's from fuse too, but it's more complicated to read. As the reading must be via talking with EdgeLock Enclave. I can see below drivers in u-boot for that.
Not sure about other series SoC. I am not sure if all boards are assigned mac addresses either.
Anyway, I will take some time to make this clear, and try to support to use in zephyr if has.
Thanks.