linux/kernel/git/baikal/linux.git, branch gmac/ext2/vlan

net: stmmac: vlan: Extend VLAN filters devices support

2026-08-13T17:35:10+00:00

DW GMAC, DW QoS Ether and DW XGMAC/XLGMAC IP-core supports three types of the VLAN filters: 1. Basic Rx VLAN perfect filter. In some extent it's available on all DW controllers. But in case of DW GMAC the S-VLAN tagged frames filtering has been supported since v3.70a. 2. Extended Rx VLAN perfect filter. It's optionally available on the modern IP-cores: DW QoS Ether, DW XGMAC, DW XLGMAC, etc. The feature has been introduced as a substitution to the Basic Rx VLAn perfect filter to extend the amount of the VLAN tags to filter. 3. Rx VLAN hash filter. It's optionally available on all modern IP-cores and on DW GMACs since v3.70a. As it can be inferred from the name the filter implies to use hash-table as a set of the allowed the VLAN-tags. The notable particularity of this filter is that it' S-VLAN capability is synchronized with the Basic Rx VLAN perfect filter. So as can be seen from the description at least one VLAN filter is always available on the modern DW network controllers, meanwhile the extended Rx VLAN and hash-based filters are optional. Moreover the current VLAN tag filters implementation in the driver support all of these filters working complementarily. Thus the driver can be freely converted to advertise the HW-accelerated VLAN C/S-Tags filtering for all the modern DW network controllers: DW GMAC v3.7x, DW QoS Ether and DW XGMAC/XLGMAC. Signed-off-by: Serge Semin

net: stmmac: dwmac1000: Add VLAN tag insertion support

2026-08-13T17:35:10+00:00

DW GMAC supports the VLAN Tag insertion in the framework of the "SA, VLAN, and CRC Insertion on TX" IP-core option. It' implementation looks very similar to what can be found in the DW QoS Ether and DW XGMAC controllers except it doesn't provide a way to re-initialize the VLAN tag via the specially formed DMA-descriptors. The only way to set the outbound VLAN Tag is to initialize the respective register. But in order to prevent the outbound frames corruption that can be done only if there is no packets pending to be fetched and transmitted via the device DMA engine. Based on the notes above let's add the VLAN Tag insertion support to the DW GMAC submodule of the driver. Basically it means to provide two callbacks: 1. dwmac1000_set_vlan_tag() - setup VLAN tag for the ongoing outbound traffic. 2. enh_desc_set_vlan() - enable VLAN tag insertion for the frame of the passed descriptor. It's also required to selectively enable/disable SVLAN Tags depending on the current network device HW-features state. Signed-off-by: Serge Semin

net: stmmac: vlan: Add VLAN Tag core setter

2026-08-13T17:35:10+00:00

DW MAC IP-cores can be equipped with the "SA, VLAN, and CRC Insertion on TX" feature. In case of VLAN Tag insertion the actual tag can be specified either via a dedicated setup register field or via a context DMA-descriptor. The last option is available on the DW QoS Ether and DW XGMAC IP-cores only, but not on the DW GMAC controllers. As a preparation before adding the VLAN Tag insertion support to the DW GMAC submodule let's add a callback method which would be responsible for initializing the Tx VLAN Tags of the device MAC. Note after this change if none of the VLAN Tx Tag setting up callbacks were successful the driver will try to push the tag inside the payload. Signed-off-by: Serge Semin

net: stmmac: dwmac1000: Add VLAN Rx filtering support

2026-08-13T17:35:10+00:00

DW GMAC IP-core supports two types of the Rx VLAN tag filters. First one is a basic perfect filter consisting a single CSR to place a being allowed VID. Second one is a Hash-based filter. It implies to pass the only VLAN tags which the most significant four bits of their CRC-32 point to a set bit in the VLAN Hash Table register. So basically the filters functionality is the same as could be found in the DW QoS Ether and DW XGMAC IP-cores except there is no Extended VLAN Perfect filter support and the S-VLAN filtering capability can't be enabled independently from the C-VLAN tags filtering - it's either both tag types allowed or just C-Tags. The CSRs layout and their mapping is different. Based on the description provided above let's introduce the VLAN Rx Tags filtering support to the DW GMAC module of the STMMAC driver. It mainly looks similar to what is found in the rest of the VLAN-capable modules except the tags counter isn't utilized since the S-VLAN tags filtering is switched on/off based on the HW-features flag. That leads to passing both C- and S-Tags if the STAG HW-offloaded filtering is enabled. Also note that the VLAN Tag Hash-based filtering availability isn't indicated in the HW-features register. Instead an auto-detection procedure has been implemented based on the fact that the VLAN Hash register is RO if feature is unavailable. Signed-off-by: Serge Semin

net: stmmac: vlan: Extract VLAN TPID from DMA-descriptors

2026-08-13T17:35:10+00:00

DW QoS Eth and DW XGMAC IP-cores are always equipped with the VLAN tag stripping feature. That is the MAC are capable to extract VLAN tag from the L2 header and place it into the dedicated DMA-descriptor field. This feature is already supported by the STMMAC driver. But what is missing is the VLAN tag type extraction in the meantime at least DW XGMAC can determined and report the L2 packet type including VLAN-frame Tag protocol ID. So in order to support the feature denoted above let's introduce the stmmac_desc_ops::get_rx_vlan_tpid() callback which would provide a VLAN TPID of the received frame of course if the frame is detected to be VLAN. Define it for both DW QoS Eth (GMAC4) and DW XGMAC IP-cores which are currently supported by the driver. In case of DW QoS Eth IP-core this callback shall return just 802.1Q tag type since at the state of v5.20a IP-core the wrote-back receive descriptor doesn't provide such information. That's why all the VLAN frames received reported as C-Tagged. Note for a VLAN tag and VLAN Tag protocol ID being valid they must be extracted from the last and not erroneous descriptor. Thus the dwxgmac2_wrback_get_rx_vlan_valid() method fixed accordingly. Signed-off-by: Serge Semin

net: stmmac: vlan: Use hash and perfect VLAN filters complementarily

2026-08-13T17:35:10+00:00

Current hash-based VLAN-filters and extended VLAN-filters implementations are orthogonal. That is they duplicate each other filtering the same VLAN tags. It's not that optimal since the controller supports them to work complementarily. It means to use one filter resources if only the resources of another one have been fully used up. Particularly the Extended VLAN-Filters as being the perfect filters would be utilised first. Only if no free perfect VLAN-filter slots left, the hash-based VLAN-filter will be configured. Let's implement the denoted functionality then. It's not that complicated since the preceding commits have smoothly prepared the code for that. So just invert the filters configuration order and regard the error-values of the extended filter configuration as a hint to fallback to the hash-based filter utilization. Signed-off-by: Serge Semin

net: stmmac: vlan: Convert VLAN filters feature to being switchable

2026-08-13T17:35:10+00:00

Currently if the kernel is built with the VLAN_8021Q config enabled the HW-offloaded VLAN packets filtering is fixed to be enabled and can't be disabled unless the Promiscuous mode is on. This can be fixed so the system administrators could switch the feature on and off when required by means of the ethtool -K command. The denoted functionality can be implemented by moving the MAC_Packet_Filter.VTFE flag switching to the stmmac_ops::set_hw_vlan_mode() callbacks and making sure it's toggled depending on the NETIF_F_HW_VLAN_(C|S)TAG_FILTER feature flag state. But the stmmac_ops::set_filter() callback will still need to be able to permit the VLAN traffic on the Promiscuous mode. Sadly the MAC_Packet_Filter.PR flag doesn't do that, but the MAC_Packet_Filter.RA flag do. Basically both of these flags are responsible for the same functionality - to make the Address Filtering module passing all incoming packets irrespective of the destination or source address. But the MAC_Packet_Filter.RA flag also let the packets to bypass all the filters including the VLAN one preserving the filters status. That fact is utilized by the MAC to deliver the filtering status to the DMA-descriptor and to decide to which Fail-queue the packets must be routed. Here is a table [1] describing the semantics of the denoted flags: +----+-------+--------------+-------------+-------+------------+ | | | SA/DA Filter | VLAN Filter | | Queue | | RA | VTFE | result | result | VFFQE | Routing | +----+-------+--------------+-------------+-------+------------+ | 0 | 0 | PASS | FAIL | 1 | VFFQ | | 0 | 1 | PASS | FAIL | X | DROP | | 1 | X | FAIL | X | 1 | UFFQ*/VFFQ | | 1 | X | PASS | FAIL | 1 | VFFQ | +----+-------+--------------+-------------+-------+------------+ * where X - don't care condition. So by setting the RA flag not only the Promiscouse mode is permitted but the VLAN Fail-queue feature is left supported (currently for the DW QoS Ether devices). So to speak the implemented change not only converts the HW-offloaded VLAN tags filter being switchable, but also preserve the VLAN Fail-queue feature supported in the driver, about which the commit a7602e7332b9 ("net: stmmac: don't reject VLANs when IFF_PROMISC is set") author worried. Note surprisingly the MAC_Packet_Filter CSR layout completely match on all the currently supported IP-cores: DW QoS Ether, DW XGMAC and DW XLGMAC. [1] DesignWare Cores Ethernet Quality-of-Service Databook, Revision 5.20a, April 2020, pp. 241-242. Signed-off-by: Serge Semin

net: stmmac: vlan: Improve hash and perfect VLAN filters security

2026-08-13T17:35:09+00:00

By default all DW GMAC v3.70, DW QoS Ether and DW XGMAC IP-cores are equipped with a single perfect VLAN-tag filter tunable to filter C- and/or S-Tags. Optionally a hash-based VLAN-filter can be synthesized into the IP-cores. But both the basic perfect filter and the hash-based filter are configured by using the same CSR - MAC_VLAN_Tag. So if S-VLAN type tags filtering enabled, it will be applicable for both basic and hash-based filters. From that perspective it would be better to synchronize both types of the filters utilization. Moreover currently the filters configuration is someway insecure. If at least one S-VLAN tags is added to the hash-based filter, then the VLAN type checking will be fully disabled. Thus both C- and S-VLAN tags would be permitted even if S-VLAN tags filtering is only requested. In addition to that the hash-based filter implementation keeps track a united list of the C- and S- tags. So if a tag of both of these tags added and some of the them is removed, then both of the tags filtering will be disabled. Even though it seems unlikely to have both C- and S-VLANs on the same wire, it will be still inappropriate behaviour. So let's fix all the misbehaviours above by improving the basic perfect and hash-based VLAN-filters configuration procedure. First the added/removed C- and S-Tags must be kept tracked in order to properly setup the filters. Second the hash-based filter configuration method must be altered to take these counters state into account. Third both the filters re-configuration must be done synchronously in case if any basic perfect or hash-based state is updated. Finally the core driver VLANs bitmap must be extended to preserve S-Tags too so not to disable the tags pair on one of the tags removal. Thus this shall provide the most optimal and secure basic and hash-based filters utilization. Signed-off-by: Serge Semin

net: stmmac: vlan: Prevent redundant desc allocation for VLAN tags

2026-08-13T17:35:09+00:00

Both DW GMAC4 and DW XGMAC HW-manuals claim that the VLAN tags specified via the context descriptors are stored in the DMA-engine and re-used on the next packet marked as VLAN tagged: > The VLAN Tag IDs and MSS values, provided by the application in a > context descriptor with their corresponding Valid bits set, are stored > internally by the DMA. When the outer or inner VLAN tag is provided > with the Valid bit set, the DMA always passes the last valid VLAN tag to > the MTL. The application cannot invalidate the valid VLAN tag stored by > the DMA. The VLAN tag is inserted or replaced based on the control > inputs provided for the packet. Thus it's redundant to allocate the context DMA-descriptor each time a VLAN tagged packet is transmitted in case if it' tag has already been stored by the DMA-engine of the respective queue. Let's cache the VLAN tag then and skip the allocation if a frame with the same tag is specified. This shall improve the xfer performance and reduce the DMA-descriptors consumption rate. Signed-off-by: Serge Semin

net: stmmac: vlan: Enable S-VLAN feature on device open

2026-08-13T17:35:09+00:00

The MAC_VLAN_Tag.ESVL flag is responsible for the S-VLAN feature activation in the MAC. Here is the bit description: > When this bit is set, the MAC transmitter and receiver consider the > S-VLAN packets (Type = 0x88A8) as valid VLAN tagged packets. From that perspective the flag must be set if S-TAG is supposed to be met in the incoming or outcoming traffic. Thus it must be set if the HW-offloaded S-VLAN is required on any path. But currently it is set on the Rx S-VLAN filter activation only. It's not that a big problem, since normally the S-TAG-ed frames are expected in both directions. Thus if the S-TAG filter feature isn't enabled no S-TAGed outbound frames will be generated. But from the scalability and maintainability perspectives it's better to set the flag in a centralized way if any of the HW-offloaded S-VLAN feature is requested. Let's do that by moving the bit handling to the stmmac_set_hw_vlan_mode() method. Signed-off-by: Serge Semin