| Age | Commit message (Collapse) | Author |
|---|
|
The PCS module currently supports in-band getting the PHY link status for
the SGMII interface only. But the DW GMAC and DW QoS Ether controllers are
also capable to use in-band signals of RGMII. Let's convert the STMMAC PCS
module to supporting it.
Basically it means to permit the integrated PCS initialization in case if
the RGMII interface is enabled. That's done by checking the ActPhyIF
capability detected from the GMAC.
Note the link status is now determined irrespective to the PCS negotiation
mode. It's fine since in case or SGMII the AN mode is always enabled so
the PHY link status will be always reported in-band-ly. In case of RGMII
there is no MAC-PHY negotiation and the PHY link status will be delivered
for as long as the PHY supports reporting it (MLO_AN_INBAND mode is on).
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW GMAC and DW QoS Ether controllers support getting PHY link status
reported via the RGMII, SGMII or SMII interfaces. The status reading has
already been added in the commit 083757866735 ("net: stmmac: add support
for reading inband SGMII status"). The interface link change support has
been implemented long before that but just recently has been converted to
properly working with phylink. What has been missing is the SRGMII IRQ
enabling and handling in case if in-band getting the status is supported.
Let's do that in the framework of so well prepared PCS module.
Note the stmmac_integrated_pcs_irq() method doesn't pass the link state to
the PCS core intentionally, so to be compatible with the case when
PCS-based AN isn't support. It's relevant for the RGMII in-band PHY-link
status signaling which is going to be added in one of the next commits.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Report the link, speed and duplex for SGMII links, read from the
SGMII, RGMII and SMII status and control register.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
We need to describe one more register (offset and field bitmask) to
the PCS code. Move the existing PCS offset and interrupt enable bits
to a new struct and pass that in to stmmac_integrated_pcs_init().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
Synopsys DW GMAC v3.7x can be synthesized with up to four GPIs and four GPOs
support, which in case if enabled can be configured via a MAC CSR 0xe0.
In order to have the DW GMAC GPIO interface supported in the STMMAC GPIO
driver the GPIO CSR accessors and MAC/DMA gentle stop/cleanup methods are
introduced. These are utilized as the low-level feature implementation
abstracting out the DW GMAC GPIO-specifics. The GPIO-chip related code
using that infrastructure has already been added to the driver.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Synopsys DesignWare Ethernet controllers can be synthesized with
General-Purpose IOs support. GPIOs are divided into two ports: gpi_i -
inputs and gpo_o - outputs. While the GPIOs semantics is identical on all
DW Ethernet controllers the ports width (number of possible
inputs/outputs) and the configuration registers layout depend on the
IP-core version. For instance, DW GMAC can have from 0 to 4 GPIs and from
0 to 4 GPOs, while DW QoS Ether/xGMAC/etc have a wider ports width up to
16 pins of each one. In the framework of provided implementation any
DesignWare Ethernet controllers GPIO block can be supported as soon as the
GPIO registers accessors and the cleanup methods are defined for the
respective IP-core.
Total number of GPIOs MAC supports is supposed to be passed via the
platform descriptor. If it's an OF-based platform, then the standard
"ngpios" DT-property will be parsed for it as well.
Before registering the GPIO-chip in the kernel, the driver will try to
auto-detect the number of GPIs and GPOs by writing 1s into the GPI type
config register. Reading the written value back and calculating the number
of actually set bits will give the GPI port width the device has been
synthesized with.
If GPIs have been detected then GPIO IRQ-chip will be also initialized and
only in that case the GPIO IRQs handling will be activated. Since the
pending events are cleared just by reading from the GPI event status
register, only the edged IRQs type can be implemented. For the same reason
and for the reason of having the rest of GPIO configs reside in the same
CSR, the GPI type, GPI mask and GPO state caches have been added. So the
driver would avoid RMW CSR update code to minimize the pending GPI events
clearing.
Note in case of GPIOs being available the core soft-resetting mustn't be
executed otherwise the GPIO configs will be reset to the initial state. Instead
MAC/DMA stop and CSRs cleanup has been added.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Synopsys DesignWare Ethernet controllers can be synthesized with
General-Purpose IOs support. In general these GPIOs can be used for
anything (but most likely for the network-specific stuff). Thus the
subsequent commits will add the STMMAC sub-module registering a respective
GPIO-chip. But before it's done the STMMAC low-level programming interface
must be extended.
First of all the GPIO data accessors is added. Even though all DW *MAC
GPIOs are semantically equivalent their CSR-wise implementation might be
different. That is the GPI type set/get, GPI IRQ en/dis, GPI get and GPO
set/get functions are either exposed via a single CSR (DW GMAC v3.7x case)
or as two control/status registers (DW QoS/XGMAC/etc case). So in order to
implement a generic GPIO-chip sub-module in the STMMAC driver these
differences will be abstracted out by the stmmac_gpio_ops accessors.
Secondly there is an issue connected with the controller resets. The GPIOs
embedded into the DW MACs are a subject of the reset-related actions. That
is if any hard- or soft-reset of the controller is performed the GPIO
settings will be reset as well. If the hard-reset is happening on the
device probing stage the soft-reset is executed on each network device
open. So should the GPIOs support is added as is to the driver, their
hardware implementation will be reset on each network device open cycle.
This is definitely not how generic GPIO-chip supposed to work.
The only way to fix that is to avoid the soft-reset procedure anyhow. But
the rest of the driver code relies on the controller being in a default
state on each device opening. Thus the best approach to solve the denoted
issue is to replace the controller soft-reset with a proper device cleanup
procedure. That's what the second part of the change about - to provide
such infrastructure.
So the provided programming interface is dedicated to solve the denoted
issues above and to prepare the driver for further GPIO-related
extensions. It's left unused for now up until the DW MAC GPIO-chip support
is added to the driver.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Synopsys DesignWare Ethernet controllers can be synthesized with
General-Purpose IOs support. GPIOs can work either as inputs or as outputs
depending on the gpi_i/gpo_o ports they belong. The ports width (number of
possible inputs/outputs) and the configuration registers layout depend on
the IP-core version and on the GIW/GOW (GP I/O port diwth) IP-core
synthesize parameter. For instance, DW GMAC can have from 0 to 4 GPIs and
from 0 to 4 GPOs, meanwhile DW QoS/xGMAC have wider ports width up to 16
pins of each type.
Since these GPIOs can be used as generic platform GPIOs the DW MAC DT-node
is supposed to describe them accordingly. So the DW MAC DT-bindings are
extended to permit the "ngpios" property, which can't have a value greater
than 32, standard GPIO-related properties like "gpio-controller" and
"#gpio-cells", and, if GPIs are supposed to be detected, IRQ-controller
related properties.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW GMAC low-level code considers the DMA_STATUS.GLI flag being set as
unexpected and prints an ugly warning to the system log. The bit indicates
an PCS/RGMII/GPI interrupt. Since the RGMII PCS IRQs handling has been
already added and the GPI IRQ handling is about to be added let's remove
that semantics since the respective IRQs are now expected.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The MAC IRQs are enabled early on the NET-device open stage by means of
the stmmac_core_init() method execution. This also concerns the MAC LPI
IRQ. There is no point in handling the event while the link is down, since
the device won't track LPI events anyway. Moreover having the LPI IRQ
unmasked before the respective IRQ-handler is installed will cause the
early LPI IRQ being considered as spurious on the shared-IRQ case thus
force-converting the IRQ-line to being polled.
Considering all the above let's enable the LPI IRQ only on the MAC Link Up
event. Thus preventing the IRQ from happening before the respective
IRQ-handler is installed and the link is established.
This change is also required for the DW MAC GPI IRQs handling in the
shared IRQ-line manner.
Fixes: d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The MAC IRQs are enabled early on the NET-device open stage by means of
the stmmac_core_init() method execution. But the IRQ-line is requested
only after the main part of the DMA/MAC blocks are initialized and even
after the PHY-link is set up. That causes the unhandled IRQs being caught
in case if the MAC IRQ is really shared.
Let's fix that by performing the IRQ-line request procedure earlier -
before the PHY-link is brought up thus making sure that all the
link-related IRQs will happen afterwards and won't be missed.
Note this change is also required for the DW MAC GPI IRQs handling in the
shared IRQ-line manner.
Fixes: 523f11b5d4fd ("net: stmmac: move hardware setup for stmmac_open to new function")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The stmmac_dma_ops::enable_dma_transmission() callback implements the Tx
Poll Demand command implying to charge Tx DMA to be seeking for the next
DMA-own descriptor and start transmitting the respective frames to the
wire. The stmmac_dma_ops::set_tx_tail_ptr() implements the same logic
except that it also updates the Tx tail pointer and if the former method
is specific for the DW MAC100/GMAC IP-cores the later callback is
available on the most modern IP-cores: DW QoS Ether, DW XGMAC, etc.
Thus both callbacks must be called in sync otherwise the respective xmit
procedures will work differently on different controllers. Currently it's
correctly implemented for the simple net_device_ops::stmmac_xmit() method.
But for some mysterious reason the XDP ZC (stmmac_xdp_xmit_zc()) and
XDP Tx/Redirect (stmmac_xdp_xmit_xdpf()) features get to call the
stmmac_enable_dma_transmission() method right after each Tx-frame
submission to Tx DMA engine way before the stmmac_flush_tx_descriptors()
invocation thus delivering poorer XDP-performance on DW MAC100/GMAC
devices.
Let's fix that by moving the stmmac_enable_dma_transmission() method call
to stmmac_flush_tx_descriptors() where the stmmac_set_tx_tail_ptr()
function invocation resides. Thus both Tx DMA charging methods will be
called in sync delivering the same Tx procedure semantics on all the
supported DW network controllers.
Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket")
Fixes: be8b38a722e6 ("net: stmmac: Add support for XDP_TX action")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In case of DW XGMAC/XLGMAC IP-cores the secondary Rx DMA-buffer can be
specified in the framework of the Split Packet Header feature
implementation. But the feature can be disabled in runtime if an XDP BPF
program is installed meanwhile the secondary buffer address won't be
properly cleaned up. As a result the secondary buffer will be left enabled
in the Rx DMA-descriptors even though it isn't utilized in the driver.
In the worst-case scenario a part of the Rx-frames will be received to the
already long freed memory page thus corrupting it' content. It's possible
in case of a sudden Jumbo frame reception.
[1] DesignWare Cores XGMAC - 10G Ethernet MAC Databook, Revision 3.20a,
September 2022, p.251.
Fixes: 67afd6d1cfdf ("net: stmmac: Add Split Header support and enable it in XGMAC cores")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
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 <fancer.lancer@gmail.com>
|
|
The flag has been introduced in the commit 750011e239a5 ("net: stmmac: Add
support for HW-accelerated VLAN stripping") in order to logically split up
the HW-offloaded VLAN tag stripping and the stripping implemented in the
driver. As the commit log says it's supposed to be in sync with the
NETIF_F_HW_VLAN_CTAG_RX feature-flag, otherwise the software-based VLAN
tag stripping will be performed.
First of all the denoted semantics is incorrect, since the MAC and
driver-based VLAN tag stripping are mutually exclusive features and are
supposed to be enabled/disabled by the
NETIF_F_HW_VLAN_CTAG_RX/NETIF_F_HW_VLAN_STAG_RX feature flags. Secondly
the flags can be directly retrieved from the net_device::features field
anytime in the driver. So introducing another mirror-flag for that was
unnecessary. Finally the MAC-based VLAN tag stripping is always persistent
in the DW *MAC IP-cores supporting VLANs (at least DW Ether QoS and DW
XGMAC). Thus as long as the HW-offloaded VLAN tag stripping is implemented
in the respective VLAN driver it can be utilized instead of the
software-based tag stripping code.
So to speak let's drop the mac_device_info::hw_vlan_en flag and just
switch on/off the VLAN tags stripping feature based on the respective
flags set in the net_device::features field. Please note that since the
VLAN-based features are available on the kernel with the CONFIG_VLAN_8021Q
config enabled it is pointless to parse VLAN Ethernet-header if the config
is disable. In that case the entire stmmac_get_rx_vlan() body can be
compiled off thus speeding up the Rx fast-path of the driver.
Note as a nice side effect of this change the VLAN tag stripping feature
is now capable to be switched on/off by the system administrator
irrespective whether it's HW-offloaded or not.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Indeed there has been no need in adding the
stmmac_vlan_ops::add_hw_vlan_rx_fltr() and
stmmac_vlan_ops::del_hw_vlan_rx_fltr()
execution dependent from the mac_device_info::num_vlan field value. If the
VLAN perfect filters feature is supported by the driver (DW QoS Ether and
DW XGMAC) then mac_device_info::num_vlan will be always initialized at
least with one. That's because the modern IP-cores (DW QoS Ether and DW
XGMAC) always support at least a Basic VLAN perfect filter engine. If the
driver doesn't support the VLAN perfect filters functionality for the
particular IP-core then the denoted callbacks just won't be available and
their execution attempt will cause the -EINVAL error returned. Thus let's
just correctly parse the return value of the methods call and drop the
mac_device_info::num_vlan conditional statement.
This change is a short preparation before adding a comprehensive
VLAN-engine support to the driver.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
---
Note if the dma_features::nrvf_num was accessible in the VLAN-related
callbacks the mac_device_info::num_vlan field could have been completely
dropped as redundant. Do that when it is.
|
|
The commit 041cc86b3653 ("net: stmmac: Enable TSO on VLANs") stated that
the TSO feature was malfunction on DW QoS Eth and DW XGMAC for the VLAN
tagged frames. In particular the commit log claims that the very first TCP
segment is VLAN tagged, but the proceeding ones aren't. This hasn't been
confirmed at least on a DW XGMAC 2.11a device. All the transferred
TCP/IPv4 segments are VLAN tagged.
Moreover the blamed commit stated that it enabled TSO for VLANs while it
actually disabled it. Instead the driver now just inserts the VLAN
TPID/TCI fields to the payload. It's also strange to see that the
HW-accelerated VLAN IDs were actually specified for the TSO SKBs since
before that commit the NETIF_F_TSO flag had been cleared for the VLAN
interfaces. All of that makes me thinking that if there was a problem it
has been purely investigated. Revert the change until the actually broken
hardware is met.
Fixes: 041cc86b3653 ("net: stmmac: Enable TSO on VLANs")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Originally the VLAN Insertion Offload feature was configured to always
insert S-VLAN type due to the MAC_VLAN_Incl.CSVL flag being always set. So
as long as there was at least one 802.1ad virtual interface created any
other virtual VLAN-interface would have generated S-TAG'ed frames, which
was caused by having both MAC_VLAN_Incl.CSVL and MAC_VLAN_Tag.ESVL flags
set. The former flag wouldn't work without the later one - that's why at
least one 802.1ad virtual interface needed to be created to meet the
problem. That has been fixed in the commit c657f86106c8 ("net: stmmac:
vlan: Disable 802.1AD tag insertion offload") just by removing the VLAN
S-TAG Insertion support from the driver with justification that the
controller doesn't support inserting both VLAN C-TAG and S-TAG at a time.
That is only one VLAN tag type can be enabled at a time.
That's true but it doesn't mean the feature should have been just deleted.
The driver can be enabled to support only one of these tags type insertion
at a time. That can be easily achieved by having the networking core
net_device_ops::{ndo_fix_features(),ndo_set_features()} callbacks
utilized. So let's use them to make sure that only one of VLAN tags type
insertion is enabled at a time - NETIF_F_HW_VLAN_CTAG_TX or
NETIF_F_HW_VLAN_STAG_TX. The MAC_VLAN_Incl.CSVL flag will be enabled only
if the NETIF_F_HW_VLAN_STAG_TX feature is requested.
Please note if there is no 802.1ad virtual interface (basically no S-TAG
filter enabled) it won't be possible to generate S-TAG'ed frames no mater
what due to the VLAN_TAG.ESVL flag cleared. This will be fixed in another
commit sometime later.
Fixes: c657f86106c8 ("net: stmmac: vlan: Disable 802.1AD tag insertion offload")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The commit bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore") fixed
the problem with the VLAN filters not being restored if the device was
closed or after resume. That could have been done in a clearer and more
coherent way just by calling the stmmac_restore_hw_vlan_rx_fltr() method
in the stmmac_set_filter() method. The later in its turn is called in the
net_device_ops::ndo_set_rx_mode() callback of the driver, which in its
turn is called on device open and resumes. The only
problematic part is to store the HASH/perfect filters context. But it can
be done by adding two more mac_device_info fields aside with the Extended
VLAN perfect filter settings. A similar approach with cacheing and using
ndo_set_rx_mode() to restore VLAN-filters is implemented in some another
network drivers.
Let's do that then. As a nice side-effect the stmmac_vlan_restore() will
be no longer needed. Also the stmmac_ops::set_filter() methods now look
more coherent setting up the all MAC and VLAN filters.
Note the vlan_write_filter() method must be altered to call the
atomic-version of the CSR polling function, since it's caller -
vlan_restore_hw_vlan_rx_fltr() is now called from the BH-disabled context
(see dev_set_rx_mode()).
bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
It was found out that the problem with the VLAN filters setting up is in
the missing PHY RXC clock when EEE is enabled and the interface being
down. As a result any attempt to create a virtual VLAN interface causes
the error like:
# ip link add link end1 name end1.5 type vlan id 5
15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter
RTNETLINK answers: Device or resource busy
# ip link set end1 down
renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter
renesas-gbeth 15c40000.ethernet end1: failed to kill vid 0081/0
This was fixed in the commit c171e679ee66 ("net: stmmac: Disable EEE RX
clock stop when VLAN is enabled") and commit 2cd70e3968f5 ("net: stmmac:
Defer VLAN HW configuration when interface is down"). So the problem is no
longer exist. But the later commit has turned to be too aggressive in
fixing it by adding the netif_running() check on each VLAN CSRs access. In
the meantime writing to the normal MAC VLAN CSRs won't cause any problem,
the timeout happens only in the MAC_VLAN_Tag_Filter indirect access. See
the log messages above.
So let's drop the redundant netif_running() checks and add a single one to
the vlan_write_filter() method. The method will return -EAGAIN error in
case if the access could be performed right now so the callee would do
that again later when the interface is brought up.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The commit c657f86106c8 ("net: stmmac: vlan: Disable 802.1AD tag insertion
offload") has dropped the double VLAN erroneous insertion for Tx frames.
The Rx VLAN-frames filtering code also suffers from that feature being
enabled but with much less harm. The feature is enabled if VLAN S-TAG
filtering is requested, but it never actually activated since the ERIVLT
and EIVLS flags aren't touched by the code.
Presumably the EDVLP flag setting up used to be working in conjunction
with the VLAN-insertion feature, since it enables the double VLAN
processing for both Rx and _Tx_ paths. So without it no inner VLAN would
be inserted if requested. But that feature has been incorrectly enabled
for the S-VLAN frames and dropped in the framework of the commit
c657f86106c8 ("net: stmmac: vlan: Disable 802.1AD tag insertion offload")
thus fixing a completely broken 802.1ad tags support added in the initial
commit 30d932279dc2 ("net: stmmac: Add support for VLAN Insertion
Offload").
So let's drop the code currently handling the EDVLP flag setting up. Also
fix the naming around the just dropped code to describing the actual
feature the entities are utilized for - enable S-VLAN filtering. After
this change there will be almost no the double VLAN feature trace left in
the driver. The only leftovers are stmmac_desc_ops::set_vlan_tag()
callbacks but the respective part doesn't effect the controller state, so
be it for now.
Note though based on [1, 2, 3] Double VLAN processing feature must be
available and enabled so the *GMACs could properly perform the L2/L3
checksum verification of the frames with one-level inner VLAN tagged.
Let's unconditionally enable it thus speeding up the incoming Double VLAN
tagged frames handling.
[1] DesignWare Cores XLGMAC - Enterprise Ethernet MAC, Revision 2.00a,
September 2017, p.181.
[1] DesignWare Cores XGMAC - 10G Ethernet MAC Databook, Revision 3.20a,
September 2022, p.253.
[2] DesignWare® Cores Ethernet Quality-of-Service, Revision 5.20a,
April 2020, p.368.
Fixes: 3cd1cfcba26e ("net: stmmac: Implement VLAN Hash Filtering in XGMAC")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Originally that functionality was added in the commit c7ab0b8088d7 ("net:
stmmac: Fallback to VLAN Perfect filtering if HASH is not available") in
order to initialize at least some filter if no HASH-based VLAN filter
available since at least one slot of the VLAN perfect filter always
available. But earlier another commit 3cd1cfcba26e ("net: stmmac:
Implement VLAN Hash Filtering in XGMAC") had made sure that no
HW-offloaded VLAN frames filter utilized if no HASH-based VLAN filter
provided in a controller. Thus that functionality has never been actually
used in practice. Moreover the later commit ed64639bc1e0 ("net: stmmac:
Add support for VLAN Rx filtering") implied using that perfect-filter
register if no Extended VLAN filter feature is available thus partly
duplicating what has already been implemented in the driver.
So to speak let's drop the unused code especially seeing the respective
device feature is utilized in a framework of the perfect-filter
initialization procedure already.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The dwxgmac2_update_vlan_hash() method now completely match to
vlan_update_hash(). In the meantime the rest of the callbacks utilized in
dwmac_vlan_ops and dwxgmac210_vlan_ops are the same. Thus drop the
dwxgmac210_vlan_ops descriptor and use now common dwmac_vlan_ops
descriptor instead. Rename it to dwmac4_vlan_ops so not to be accidentally
utilized for the older IP-cores which have a bit different VLAN engine and
isn't compatible with current VLAN implementation in the driver.
Note the current VLAN module can be fully utilized for DW XLGMAC IP-cores
too. But leave it be as is for the engineers with the compatible hardware
at hand. Don't bother with that right now.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The MAC_HW_Feature3.DVLAN flag has been available since the DW XGMAC
IP-core v3.00a, but the Double VLAN Processing feature can be enable since
the v2.00a version (or later than v1.20a). Thus it's incorrect to
determine the DVLAN feature availability based on the flag state on the
early versions of the IP-core. Since we don't know since what particular
IP-core version the Double VLAN Processing feature is available let's
provide the auto-detection procedure for any of them if DVLAN flag has
been met cleared.
The auto-detection procedure is created by checking the
MAC_VLAN_Tag.EIVLRXS (Enable Inner VLAN Tag in Rx Status) flag
writability. The IP-cores databooks define the flag as 0x0 after reset and
available only if the DWCXG_DOUBLE_VLAN_EN parameter is enabled. Otherwise
it's reserved, RO and zero.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The amount of the Extended Rx Perfect Filter slots is reported via the
FEATURE3.NRVF field on the DW IP-core supporting that features: DW QoS
Ether and DW XGMAC/XLGMAC/etc. The field encrypts the size of the filter
as follows:
- 000: No Extended Rx VLAN Filters
- 001: 4 Extended Rx VLAN Filters
- 010: 8 Extended Rx VLAN Filters
- 011: 16 Extended Rx VLAN Filters
- 100: 24 Extended Rx VLAN Filters
- 101: 32 Extended Rx VLAN Filters
- 110-111: Reserved
In the meantime the dma_cap DebugFS node incorrectly decrypts the field as
(nrvf << 1) and only for the DW XGMAC IP-core. Let's fix that by
appropriately parsing the FEATURE3.NRVF field on the both IP-cores
supporting the Extended Rx Perfect Filter feature.
Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering")
Fixes: 669a55560e4b ("net: stmmac: Check more MAC HW features for XGMAC Core 3.20")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In fact the always strip mode enabled in the vlan_set_hw_mode() method
means stripping both VLAN tag types C and S ones. Thus both of these
NET-device features must be enabled/disabled simultaneously if requested
by ethtool.
Fix that by adding the respective conditionals to the ndo_fix_feature()
method and making sure that both of these features are synchronously
switchable.
Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Commit 8eb301bd7b0f ("net: stmmac: enable HW-accelerated VLAN stripping
for gmac4 only") attempted to fix the problem of the HW-accelerated VLAN
tag stripping feature being enabled for all MAC cores even despite of
having it supported by the DW GMAC4 driver only. But the solution only
works up until the ndo_set_features() method is called. When it's done the
mac_device_info::hw_vlan_en field will be set to true thus disabling the
software-based VLAN tag stripping implementation and relying on the MAC to
do that. Of course that won't be done on the DW GMAC- nor DW XLGMAC-based
devices since the driver currently doesn't support the feature on these
IP-cores.
Let's completely fix the denoted problem just by changing the HW-offloaded
VLAN tag detection flag only if the NETIF_F_HW_VLAN_CTAG_RX flag is set in
ndt_device::hw_features. The later condition is only met for the DW GMAC4
and DW XGMAC IP-cores currently.
Fixes: 8eb301bd7b0f ("net: stmmac: enable HW-accelerated VLAN stripping for gmac4 only")
Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The stmmac_vlan_update() method falls back to the basic perfect filter
case if no VLAN hash filter detected. In that case the method completely
overrides the VLAN_TAG register clearing the settings like EVLRXS or EVLS,
which are required for the VLAN interface to work correctly. For instance
EVLRXS activates VLAN Tag in Rx status getting the Rx DMA-descriptors.
So let's fix that in a way it has been done for DW XGMAC VLAN in commit
907a076881f1 ("net: stmmac: xgmac: fix incorrect XGMAC_VLAN_TAG register
writting") - by using the already read value of the VLAN_TAG register.
Fixes: c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
If no Extended VLAN filter Filtering supported, then a basic perfect
VLAN-filter will be available. That filter regards VID=0 as a special value
which if specified in the filter register basically means to accept any
VLAN frame irrespective to the hash-based VLAN-filter settings. Here is
the MAC_VLAN_Tag.VID field description actual for both DW QoS Eth and DW
XGMAC IP-cores:
> If this field ([11:0] if ETV is set) is all zeros, the MAC does not
> check the 15th and 16th bytes for VLAN tag comparison and
> declares all packets with Type field value of 0x8100 or 0x88a8
> as VLAN packets.
This is also documented by the table "VLAN Match Status" in the IP-cores
databooks:
VID | VLAN Perfect Filter | VTHM | VLAN Hash Filter | Final VLAN |
| Match Result | Bit | Match Result | Match Status |
----+---------------------+------+------------------+--------------+
0 | Pass | 0 | Any | Pass |
0 | Pass | 1 | Any | Pass |
So in order to have the VLAN-filtering actually working for hardware with
no Extended VLAN filter support by default let's always initialize the
MAC_VLAN_Tag.VID with 0xffff's if no real VID specified. Thus no real VLAN
frames would be permitted except the packets with the reserved VID, which
is better than permitting all VIDs and making VLAN hash filter basically
useless.
Fixes: 3cd1cfcba26e ("net: stmmac: Implement VLAN Hash Filtering in XGMAC")
Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The blamed commit added the Extended VLAN Tag Perfect filtering support to
the DW Ether QoS part of the driver. Then the implementation has been
reused for DW XGMACs in commit 534df0c1724b ("net: stmmac: dwxgmac2: Add
support for HW-accelerated VLAN stripping").
Originally it was intended for the VLAN TAG perfect filters to be used
orthogonally with the VLAN Tag Hash filtering. So one functionality
would work irrespective to another one being available. Well, with some
flaws but it has worked. The problem comes when you get to have a device
with no VLAN Tag Hash filter but with the Extended VLAN Tag filter
support. In such case by default the S-TAG filter won't be activated
causing C-TAG frames filtering instead, because no ERSVLM or DOVLTC flag
set in the MAC_VLAN_Tag_Filter register. These flags are responsible for
VLAN S-TAG tag activating or disabling VLAN tag type checking. Anyway in
case if the VLAN Tag Hash filtering is supported it will be _responsible_
for permitting both C- and S-Tags of the same VID, which at least isn't
secure. But the VLAN perfect filter S-TAG entries will be misconfigured.
Let's fix the problem denoted above by setting up the ERSVLM flag in case
if the 802.1ad VLAN-protocol requested. The flag will be preserved in the
private-data VIDs cache so to be properly restored after system resume and
to differentiate the tags with the same VIDs but different types.
Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The commit 8c5f48d99de2 ("net: stmmac: dwxgmac2: Also pass control frames
while in promisc mode") made sure that the Ethernet flow-control packets
get to be passed to the system memory when IFF_PROMISC by setting the
MAC_Packet_Filter.PCF flag. But it forgot to have the bit cleared after
the promiscuous mode was disabled. Let's fix that.
Fixes: 8c5f48d99de2 ("net: stmmac: dwxgmac2: Also pass control frames while in promisc mode")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Currently the promiscuous mode doesn't work for VLAN frames. So if there
is a VLAN interface created on top of an DW XGMAC native interface only
VLAN-frames with the specified VIDs will be received despite of having the
promiscuous mode activated. That's because the stmmac_ops::set_filter()
callback doesn't disable the VLAN-filters when the IFF_PROMISC mode is
detected.
Let's fix the problem the way it has already been done for DW Ether QoS
GMAC in commit Fixes: a7602e7332b9 ("net: stmmac: don't reject VLANs when
IFF_PROMISC is set"). The only thing that needs to be done is moving the
PACKET_FILTER.VTFE flag toggling to the denoted set_filter() callback.
Thus if the IFF_PROMISC flag is set the PACKET_FILTER.VTFE flag will be
cleared and VLAN-filter will be de-activated. Otherwise the flag will be
left set permitting VLAN-filters to work (if any was configured).
Fixes: 3cd1cfcba26e ("net: stmmac: Implement VLAN Hash Filtering in XGMAC")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Tx/Rx COE and TSO features apply additional constraint to DMA-mode and
MTU. First of all DMA Store-and-forward mode implies that the frames
length mustn't exceed the Tx/Rx FIFO depth. Secondly all DW GMAC, DW QoS
Ether and DW XGMAC/XLGMAC demands to apply additional constraint on the Tx
frames size if Tx COE is active [1, 2, 3]:
"You must make sure that the Transmit FIFO is deep enough to store a
complete frame before that frame is transferred to the MAC transmitter.
The reason being that when space is not available to accept the programmed
burst length of data, then the MTL Tx FIFO starts reading to avoid
dead-lock. When reading starts, the COE fails and consequently all
succeeding frames may get corrupted because of improper recovery.
Therefore, you must enable the checksum insertion only in the frames that
are less than the following number of bytes in size (even in the
store-and-forward mode): TXFIFO_SIZE - ((PBL + N)*(DATAWIDTH/8))"
Thirdly similar but less strict constraint exist if TSO feature is
enabled on DW QoS Ether or DW XGMAC/XLGMAC [2, 3]:
"The header length plus the MSS size (which is equal to the size of each
TCP segment) must not exceed 16383 bytes, otherwise, the MAC transmitter
truncates the packet after 16383 bytes causing a CRC error. The header
length plus MSS size plus programmed PBL value in register must be lesser
than the programmed Tx Queue size."
It was surprising to realize that almost none of these constraints are
taken into account in the driver, except MTU being less than Tx FIFO size.
In the meantime exceeding any of them will cause frames full corruption.
That's what happens in case if Jumbo/Giant frames activated.
Let's fix the denoted problem by adding the comprehensive procedure
to support the net_device::max_mtu field in the correct state. For that
the driver now performs the max MTU constraint calculation on:
1. device probe stage so to start device using with a correct constraing.
2. on each change of the active Tx/Rx queues since it causes Tx/Rx FIFO
size change on the modern DW network controllers.
3. on each Tx COE feature activation/de-activation due to the
feature-specify frame size requirement.
Note on each action causing net_device::max_mtu change the driver now has
to make sure the current MTU doesn't exceed the new constraint otherwise
the action won't be accepted.
As a nice consequence of this change the net_device_ops::ndo_change_mtu()
callback won't need to have FIFO-specific MTU sanity checks. The
respective constraints are now reflected in net_device::max_mtu.
[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 185.
[2] DesignWare Cores Ethernet Quality-of-Service Databook, Revision 5.20a,
April 2020, p. 364/380.
[3] DesignWare Cores XGMAC - 10G Ethernet MAC Databook, Revision 3.20a,
October 2022, p. 249/257.
Fixes: eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
Fixes: d6ddfacd95c7 ("net: stmmac: Add DMA related callbacks for XGMAC2")
Fixes: f748be531d70 ("stmmac: support new GMAC4")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In accordance with [1,2,3] the PBL (Programmable Burst Length) values are
only valid if they belong to the set [1, 2, 4, 8, 16, 32]. Specifying any
different value results to Undefined Behaviour. Moreover the maximum value
is also limited. The maximum burst length must not exceed the half of
the Tx/Rx Queue Depth (Queue Depth = Queue or FIFO size / Data width).
Without this requirement being fulfilled the communications will be
fully broken.
Since the system interface data bus width is now available in the driver
private data let's use it to calculate the effective MTL FIFO depth and
make sure that the DMA PBL specified by the platform is correct at least
for a single activated queue in order to avoid hardware UB-related errors.
The best place to do that is to introduce a new stmmac_dma_verify()
method, which would be called on the driver probing stage. It will ensure
that the PBL is valid at least for the default device setup. Besides the
method will contain the rest of the DMA settings verification and
adjustment so to be as coherent as possible.
[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 380, Table 6-5.
[2] DesignWare Cores Ethernet Quality-of-Service Databook, Revision 5.20a,
April 2020, p. 1185, Table 17-303 and p. 1190, Table 17-304.
[3] DesignWare Cores XGMAC - 10G Ethernet MAC Databook, Revision 2.11a,
September 2015, p. 471, Table 7-17 and p. 474, Table 7-18.
Fixes: d6ddfacd95c7 ("net: stmmac: Add DMA related callbacks for XGMAC2")
Fixes: f748be531d70 ("stmmac: support new GMAC4")
Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
As a preparation to the PBL and MTU constraint implementation let's
introduce a dedicated method which would just calculate the Tx/Rx FIFO
sizes based on the currently active queues settings. Thus the driver would
have the duplicated code of the FIFO depth calculation moved to one
coherent method and be prepare for the announced fixes.
Note there is no point in checking whether there is a FIFO size passed via
the platform configs storage each time the Tx/Rx FIFO size values are
required, since neither the FIFO size platform setting nor the FIFO size
DMA-capability get changed after the corresponding devices are probed and
added to the system. Thus the total Tx/Rx FIFO size can be set just once
on the device probe (HW-initialization) procedure: if non-zero platform
FIFO size is detected then the FIFO size DMA-capability will be ignored.
Also note this change fixes the Loongson GMAC/GNET device support which
the only DW GMAC v3.70a device currently declared to support the
multi-channel feature. The commit ad72f783de06 ("net: stmmac: Add
multi-channel support") has forgotten to fix stmmac_change_mtu() so the
method wouldn't divide the MTL FIFO memory between the queues/channels.
The multi-channels DW GMACs have the per-channel non-configurable MTL FIFO
memory. So the stmmac_change_mtu() has been wrong in unconditionally
dividing the total MTL FIFO memory and using the resultant as the upper
limit of MTU.
Fixes: ad72f783de06 ("net: stmmac: Add multi-channel support")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Currently the driver initialize the maximum MTU value as follows:
1. DW XGMAC/XLGMAC: 16KiB
2. DW GMAC with Enhanced DMA-descriptors and DW QoS Ether: 9000 bytes
3. DW MAX100 and DW GMAC with Normal DMA-descriptors: PAGE_SIZE.
This is wrong in the aspects 2. and 3. Here is why. First of all DW QoS
Ether have always supported Tx and Rx up to 16KiB frames size in the same
way as DW XGMAC-like devices. The latest Jumbo-related commit has enabled
that in the driver too. Secondly no matter what type of the DMA-descriptor
selected DMA GMACs have always supported up to 9K frames at least in the
cross-descriptor manner. Thirdly the legacy DW MAC100 controllers have
never been able to xmit/recv frames greater than 1500 bytes. There is no
any Jumbo-like setup in the MAC config registers. It has been even more
wrong to use SKB_MAX_HEAD() macro to calculate max MTU constraint since
it's basically converted to PAGE_SIZE which is platform-specific, can be
even greater than 16KiB and doesn't determine the actual MTU constraint
applicable for the particular DW network controller. Finally the MTU
verification procedure isn't complete in the net_device:ndo_change_mtu()
method. The upper-limit is specific to the DW XGMACs only (and actually
redundant). Moreover the Tx FIFO size-based constraint is also incorrect -
it isn't enough to set up the upper MTU-limit based on the Tx-FIFO size
(but it will be fixed later).
Let's fix all of the inconsistencies above by activating the 16KiB Jumbos
for DW QoS Ethernet, setting up 9000 max MTU for any DW GMAC, getting
back the normal max MTU for the legacy controllers and dropping the manual
max MTU verification in the net_device:ndo_change_mtu() method.
Fixes: eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
Fixes: f748be531d70 ("stmmac: support new GMAC4")
Fixes: 45db81e1590c ("stmmac: limit max_mtu in case of 4KiB and use __netdev_alloc_skb (V2)")
Fixes: 48febf7e6476 ("stmmac: allow mtu bigger than 1500 in case of normal desc (V4)")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW *MAC IP-cores can be synthesized with various system interface data bus
widths. For instance DW GMACs and DW QoS Ether can work with buses of 32,
64 and 128 bits width, while DW xGMACs can be created with system bus of
64 and 128 bits width. The bus width value affects several very important
parameters like DMA transfers granularity and performance, DMA maximum
burst length, Rx DMA buffers alignment. So in order to be able to tune and
verify these parameters let's add the data bus width device property
support. It can be passed either by the platform code or via the DT-node
property. For some reason HW capability register doesn't contain that
parameter in its fields.
Note if the data bus width isn't specified then the driver will use the
default value of 16 bytes. That will apply the strongest constraint on the
PBL values and Rx DMA buffers alignment (the later one is actually
currently hard-coded anyway). In order to get a better HW performance it's
preferable to specify the actual value for a particular version of the
controller.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW *MAC IP-cores can be synthesized with various system interface data bus
widths. The bus width normally depends on the SoC system bus capability and
is selected by the hardware engineers in a way to deliver the best
interface throughput.
In accordance with the IP-cores databooks the system bus width is fixed to
a single value for all system bus transfers. For instance if it's set to
16 bytes (data bus width of 128 bits) then each DMA bus transfer size will
be a multiple of 16 bytes and can't be smaller than that value (that's
where the Rx DMA buffer alignment restriction comes from). In addition to
that aside with the system interface performance the bus width determines
the DW MAC Programmable Burst Length upper limit and Rx descriptors buffer
size alignment.
Since the system bus width is selected during DW *MAC IP-core synthesize
procedure, is specific to each controller and can't be detected on runtime
let's add a new property "snps,data-width" to the DW MAC DT-bindings file.
The property needs to be placed in the root DW MAC DT-nodes because no
matter which system bus interface type has been selected during the
IP-core synthesize (AXI, AHB, MTL), the parameter mainly determines the
internal MTL core data bus width. The external system/application bus data
width is then fixed with that value.
Note the system bus width can be of 32, 64 and 128-bits for DW GMAC and DW
QoS Ether, while DW xGMAC can have only 64 and 128 bits wide system data
bus.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Similarly to what has been relevant for DW XGMAC the driver currently
always enable the Jumbo frames up to 16K bytes to receive and transmit for
DW QoS Ether too (DW GMAC4). It's done by permanently setting the
MAC_CONFIG.JD and MAC_CONFIG.JE flags. Basically it means the driver
completely ignores the MTU settings permitting up to 16K outgoing frames
and no greater than 9K incoming frames.
It isn't right to disregard the MTU setting especially such asymmetrically
since the MTU value might be an important parameter of an Ethernet network
segment. Moreover based on what is said in [1] the most preferred way to
support MTU would be to drop the oversized frames instead of passing them
up to the networking core subsystem. It's also important to note that even
though [1] says that the upper layer protocols must not pass a socket
buffer (skb) to a device to transmit with more data than the MTU in fact
it does at least in case of the pktgen module.
The driver currently doesn't fulfill these requirements and
passes/transfers the incoming/outcoming frames further ignoring the MTU
value. Let's fix that by activating the Giant frame setting and by setting
the internal watchdog up to drop the incoming frames which size is greater
then MTU and truncate the outgoing 2048/16383-octets oversized frames.
Thus the behaviour will match to what is already implemented for DW
GMACs/XGMACs and follow the networking subsystem recommendations. This
shall significantly speed up the oversized frames handling.
Note the driver currently just drops the frames with over Giant frame size
so the describes recv truncation seems unnecessary. But it will be
utilized in the NETIF_F_RXALL feature implementation.
Also note since this change the driver will support DW QoS Ether
controller to send/receive frames up to MTU=16K. The net_device::max_mtu
parameter will be accordingly fixed a bit later.
[1] Documentation/networking/netdevices.rst
Fixes: 41f2a3e6367e ("net: stmmac: dwmac4: Enable RX Jumbo frame support")
Fixes: 477286b53f55 ("stmmac: add GMAC4 core support")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The driver currently always enables the Jumbo frames up to 16K bytes to
receive and transmit. It's done by setting the MAC_TX_CONFIG.JD flag and
initializing the MAC_RX_CONFIG.GPSL field with the 16K frame size.
Basically it means the driver completely ignores the MTU settings despite
of what was said in the commit 8a488c3f97cd ("net: stmmac: xgmac: Enable
RX Jumbo frame support").
It isn't right to disregard the MTU setting since the MTU value might be
an important parameter of an Ethernet network segment. Moreover based on
what is said in [1] the most preferred way to support MTU would be to drop
the oversized frames instead of passing them up to the networking core
subsystem. It's also important to note that even though [1] says that the
upper layer protocols must not pass a socket buffer (skb) to a device to
transmit with more data than the MTU in fact it does at least in case of
the pktgen module.
So currently the driver doesn't fulfill these requirements and
passes/transfers the incoming/outcoming frames further ignoring the MTU
value. Let's fix that by activating the Giant frame setting and by setting
the internal watchdog up to drop the incoming frames which size is greater
then MTU and truncate the outgoing oversized frames with size threshold
2048/16383. Thus the behaviour will get to be closer to what is already
implemented for DW GMACs (except a more accurate Giant frame setting and
one truncation threshold less of the Tx frames) and follow the networking
subsystem recommendations. This shall significantly speed up the oversized
frames handling.
Note the driver currently just drops the frames with over Giant frame size
so the describes recv truncation seems unnecessary. But it will be
utilized in the NETIF_F_RXALL feature implementation.
[1] Documentation/networking/netdevices.rst
Fixes: 8a488c3f97cd ("net: stmmac: xgmac: Enable RX Jumbo frame support")
Fixes: 2142754f8b9c ("net: stmmac: Add MAC related callbacks for XGMAC2")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The driver setups the frame size limits by using the MAC_CONTROL.JD and
MAC_CONTROL.JE flags. The former one is responsible for the transmit
Jabber engine disabling and the later one enables the Jumbo frames support
for both Rx and Tx path. But if the MAC_CONTROL.JD is set MAC_CONTROL.JE
won't affect the Tx path and only works for the Rx traffic. Thus the
driver currently permits to transmit frames up to 16K bytes irrespective
to the MTU value, to receive frames of up to 1518(1522), 2000, 9018(9022)
bytes with no packet dropped due to the giant frame status, to get
truncated frames over 2048 and 10240 bytes. Moreover giant frames dropping
isn't working by default for the DW GMAC controllers of v3.70a and newer
when there is no Giant frame status reported via the Rx DMA-descriptors
(if Advanced Timestamp or Rx COE v1/v2 features is selected during the
IP-core synthesizing).
It isn't right to consider the MTU setting that relaxed and to have the
device working so much differently depending on the controller version.
Moreover based on what is said in [1] the most preferred solution would be
to drop the oversized frames instead of passing them up to the networking
core subsystem. Also note even though [1] says that the upper layer
protocols must not pass a socket buffer (skb) to a device to transmit with
more data than the MTU in fact it does at least in case of the pktgen
module.
In case of DW GMAC the driver can work way better to comply with what the
networking subsystem requires. First of all the MAC_CONTROL.JD can be
cleared thus enabling the MAC internal watchdog to truncate the oversized
frames transmission on 2048 or 10240 outgoing octets. Secondly starting
from v3.70a there is a watchdog timeout register which can be used to
fine-tune the MAC to truncate the recv frames of the size greater than
specified. Finally since the v3.70a IP-core there has been the
DMA_CONTROL.DGF flag activating the Giant frames dropping.
All the features above can be used to implement a more clever Jumbo frames
support so the network interface behaviour would be unified across various
DW GMAC IP-core versions (and looking a bit ahead across modern DW QoS
Ether/XGMAC/etc). So DW GMAC v3.70a and newer controllers will have
implemented the next MTU semantics in the driver:
1. MTU <= 1500: truncate xmit frames greater than 2048, drop recv
frames greater than 1518(1522).
2. MTU <= 1978: truncate xmit frames greater than 2048, drop recv
frames greater than 1996(2000).
3. 1978 < MTU <= 9000: truncate xmit frames greater than 10240 and recv
frames greater than ALIGN_UP(MTU+22, 1024), drop recv frames greater than
9018(9022).
4. 9000 < MTU <= 16383: truncate xmit and recv frames greater than 16K
bytes, drop recv frames greater than 9018(9022).
This shall not only extend the Jumbo-frames support, but also shall speed
up the oversized frames handling since the truncated packets will likely
to fit into a single Rx DMA-descriptor, which then will be just dropped as
erroneous and re-initialized.
In case of the DW GMAC older than v3.70a version the semantics will be as
follows:
1. MTU <= 1500: truncate xmit and recv frames greater than 2048,
drop recv frames greater than 1518(1522).
2. 1500 < MTU <= 9000: truncate xmit and recv frames greater than 10240,
drop recv frames greater than 9018(9022).
3. 9000 < MTU <= 16383: truncate xmit and recv frames greater than 16K,
drop recv frames greater than 9018(9022).
It's almost the same as before except that the oversized transmitted
frames will be truncated from now.
Note the driver currently just drops the frames with over Giant frame size
so the describes recv truncation seems unnecessary. But it will be
utilized in the NETIF_F_RXALL feature implementation.
[1] Documentation/networking/netdevices.rst
Fixes: 2618abb73c89 ("stmmac: Fix kernel crashes for jumbo frames")
Fixes: 84c9f8c41df9 ("net: stmmac: Add ip version to dts bindings")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
