| Age | Commit message (Collapse) | Author |
|---|
|
Marvell 88x2222 PHY is equipped with a basic TWSI/SMBus controller which
SDA/SCL pins are multiplexed with GPIO pins 10 and 11. The main purpose of
the interface is to access the externally attached modules EEPROM (for
that sake there is even an internal cache which if enabled can be filled
with the EEPROM data) but in general it can be used to access any I2C
peripheral device as long as it supports the SMBus transfers the
I2C-controller provides. Alas the SMBus controller functionality is very
limited. It's just SMBus byte data read and write transfers, which should
be enough for the EEPROM IO operations but won't provide a full support of
the SFP+ equipments like MDIO-I2C-based PHY or thermal sensors. Anyway if
a respective platform is already designed to rely on the Marvell 88x2222
I2C-interface it will be handy to have the interface registered in kernel
so the SFP-port driver would at least access the module EEPROM.
The provided driver first probes whether the I2C-interface functionality
is available and supported by the current platform setup. That is it makes
sure that there is no GPIO-function activated on the SDA/SCL pins and
there is no device hard-reset capability. Then it pre-initializes the
I2C-interface: disables the EEPROM caching and Read-after-write
functionality. After that the I2C-adapter is ready to be registered and
utilized then by the client drivers (mainly by the SFP-port driver) for
the basic SMBus Byte Data Read/Write operations.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Marvell 88x2222 PHY is equipped with 11 general purpose pins, which can be
configured to work either as a special-function pins (LEDs, TWSI SDA/SCL,
SFP+, etc) or as GPIOs. In the later case they can be registered in the
kernel GPIO subsystem and used then either for some platform-specific sake
or as the SFP+ port GPIOs seeing there is no MMD-based SFP+ implementation
currently supported by the kernel.
All eleven GPIOs can support input and output (open-drain) modes
determined by the TRISTATE control register. In case of the input mode the
state change is reported by means of the PHY IRQ line. Each GPIO interrupt
can be individually enabled/disabled by the IRQ Enable register. There are
all five interrupt types supported: high/low level triggered,
rising/falling/both edges triggered. Note GPIO IRQs are handled in a
separate ISR instead of doing that in the phy_driver.handle_interrupt()
function. The later handler is utilized only if the PHY is attached to a
network device. It's unacceptable for the general-purpose IO pins since
they can be utilized anytime the device is successfully probed. For a
similar reason the GPIOs aren't supported if the device-specific
hard-reset line is specified. It's toggled during the PHY re-attachment
which will clear the entire device state out and will break the GPIOs
driver functionality for sure.
Note 1. In case of some of the GPIOs are marked as invalid the respective
pins special-function is activated/preserved. The pins can be defined as
reserved for instance by means of the "gpio-reserved-ranges" property. It
will be useful for the platforms which rely on the special-functions, like
LEDs, activated.
Note 2. The private data caches are utilized in order to implement the
access to some of the GPIO CSRs. It's done for several reasons: in order
to implement the IRQ-chip support for a device living on a slow
asynchronous bus; in order speed up the CSRs access; in order to overcome
a race condition around the GPIO Data register RMW-access (see the commit
body for details).
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
At least on debug-stage it gets to be handy to know what side causes the
link being unavailable: host or line side. Add debug printouts activated
depending on the respective conditional statement being true in the
Marvell 88x2222 status read procedure.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
It's possible to have the controller reporting the device events via an
IRQ line. It's polarity is active-low by default, but also can be
configured by means of the Chip-level Global Interrupt Control register
(out of this change scope). There are three types of events reported by
the interrupt: line-side PCS link state, host-side PCS link state and
GPIOs. This update concerns the first two events as they are of the
particular PHY subsystem interest.
As it's intended by the Network PHY subsystem two callbacks are
implemented: config_intr() and handle_interrupt(). The former one is
responsible for activating/de-activating the host-side (XAUI and
10GBase-R) and line-side (1000Base-X/SGMII and 10GBase-R) link state
interrupts. The host-side IRQs are configured depending on the selected
interface mode meanwhile all relevant line-side IRQs are just enabled
since there is no info regarding the line-side link type at the moment of
the configuration procedure and might get to be available only after the
auto-negation is completed or when a SFP module is inserted. The later
callback is responsible for the IRQs handling. If there is a MDIO-based
communication is detected to be malfunction PHY will get to be halted by
means of the phy_error() method. Otherwise the Port-level Interrupt
Status value will be utilized to check whether the device has any pending
interrupt. Any link state change or errors detection will cause the PHY
state machine been triggered. Info regarding the detected errors will be
also sent to the system log as a debug-message for now since the errors
may happen due to normal link up/down procedures.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Prepare the driver to adding the interrupts support by making sure that
the actual status is handled during the network link state machine work.
Currently it concerns the link status flags in various PHY MMD registers.
They are latched-low so the respective CSRs need to be read twice to get
the actual flag state at the moment of the event handling.
Note there are other latched flags can be discovered in the Marvell
88x2222 registers. For instance AN Page Received status or 1GBase-X Remote
fault status. Since the semantic of the respective events handling may
differ from the link up/down handling procedure, the
mv2222_read_mmd_latched() function is defined to accept an additional
argument forcing the registers double read if it's required by the caller.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Depending on the setups nature it isn't always required to fully
soft-reset the PHY-device. For instance the config_init() procedure
implies the interface-type setups. Thus the host-side need to be only
performed. Meanwhile the external link settings like Auto-negotiation
configs or link protocol (type, speed, duplex, etc) need to be followed by
the line-reset only. Thus the setup procedures can be sped up a bit by
splitting the resets up into the host- or line-side resets performed after
the setups which require one or another reset only. Note the soft_reset()
PHY-driver callback still implies a full soft-reset.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Marvell 88x2222 provides 10GBase-X4/XAUI, 10GBase-R, 1000Base-X and SGMII
host interfaces. Fill in the phy_device::possible_interfaces field with
the currently supported by the driver modes: XAUI and 10GBase-R.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Aside with XAUI it's possible enable the 10GBase-R link between MAC/PCS
and Marvell 88x2222 Host-side (XFI). It doesn't require much driver
modification. The 10GBse-R host-side PCS must be selected in the Port PCS
configuration register. It can be done in the config_init() phy_device
callback. Due to that the locally defined mv2222_config_line() method must
be modified in order not to override the activated interface mode.
Note the read_status() callback is altered to take the host-side link
state into account.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
bits.h and bitfield.h provides useful helpers with the bit fields
operations. Let's use them in driver instead of hard-coded bitwise shift
operation. The update concerns the PCS Host/Line mode select procedure
only.
Note while at it let's convert the mv2222_config_line() method to
collecting the fields in the local variable and then calling the
phy_write_mmd() method from a single place of the function. Thus it will
look a bit more coherent and the generated code smaller.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
There is a Marvell 88X2222 PHY revision with R suffix, which is mainly
compatible with the original PHY but has different ID. Let's add it to the
known Marvell PHY IDs table defined in the marvell_phy.h file.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DT-bindings wise the Marvell 88X2222 transceiver is a normal 10G PHY with
up to four host-side ports (support 10GBASE-R, XAUI/RXAUI, 1000BASE-X
protocols) and two line-side ports (support 10GBASE-R and 1000BASE-X
interfaces). Besides it is equipped with 12 GPIOs multiplexed with the
special functions like LEDs, TWSI SDA/SCL, etc. They can be used to
communicate with the SFP+ ports soldered to the device line-side
interfaces.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Baikal-T1 SoC is synthesized with the DW XPCS v3.11b IP-core attached to
DW xGMAC v2.11a over the XGMII interface. DW XPCS is configured to be of
the Back-plane multi-mode with KR/KX4 speeds support (no 1G speed). Thus
the PCS sublayer supports Clause 73 and 72 auto-negotiations performed
over the 10GBASE-KR and 10GBASE-KX4 link modes.
So in order to have the denoted features enabled for the Baikal-T1
XGMAC/XPCS chain the DW XPCS driver is updated with the Baikal-T1
XPCS-specific compat-list. It will be selected in case if the platform
detects the "baikal,bt1-xpcs" compatible device or a device with the
custom BT1_XGMAC_XPCS_ID id.
Note the XPCS device is synthesized with the Synopsys 10G Gen5 PMA. Thus
the corresponding PMA-id is specified in order activate the PMA-specific
config methods.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Baikal-T1 SoC is synthesized with the DW XPCS v3.11b IP-core attached to
DW xGMAC v2.11a over the XGMII interface. Externally it's equipped with
the Synopsys Enterprise 10G Gen5 PMA working with the KR/KX4 links. XPCS
can deliver events by means of a single IRQ line. In addition it can be
clocked either from the internal clock source ("core" mode) or from the
external pad ("pad" mode).
Note using internal clock source may cause link instability. It's
preferable to have an externally generated clock signal.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The drivers/net/pcs/pcs-xpcs-pma.c file has just been added to the DW XPCS
driver. It contains the DW XPCS PMA layer initialization functions called
from the main part of the driver. Add it to the list of the files
maintained in the framework of the generic DW XPCS driver parts.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW XPCS can be synthesized with 10GBASE-X/XAUI link support. In that case
xGMAC is still connected to the XPCS device by means of normally
multi-lane high-speed interface (XGMII, USXGMII, etc) meanwhile an
external interface is defined as 10GBASE-X. From the network subsystem
point of view it's as if DW XPCS is fully integrated into the MAC with no
need in setting any intermediate interface up.
Similarly to the 10GBASE-R, in accordance with the IEEE 802.3 standard
10GBASE-X doesn't intent any auto-negotiations but it's defined as also
being utilized by XGXS (Clause 47). Thus a new AN-less mode is defined
DW_10GBASEX in the driver. It implies PCS and PMA setups required for the
device to work in the denoted mode. The respective actions are executed in
the xpcs_do_config() method. At the same time xpcs_link_up() makes sure
that the PCS/PMA<->PHY link actually works and it has compatible speed and
duplex: 10Gbps speed and full-duplex mode.
Note 1. Synopsys 10G Gen5 PMA requires the reference clock switch in case
if the respective flag doesn't correspond to the specified clock sources.
Note 2. XPCS 10GBASE-X interface features list contains all
speed-compatible link modes in order to have the pcs_validate() permitting
these modes for the externally attached PHYs.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The interface is defined by IEEE 802.3 Clause 48 as a PCS and PMA
sublayer. It is normally utilized to connect XGMII with the 10GBASE-CX4
(Clause 54), 10GBASE-KX4 (Clause 71), and 10GBASE-LX4 (Clause 53) PHYs.
It's an independent four Tx and Rx lanes interface with 8b/10b coding of
the full-duplex stream with constant 10Gb/s speed. 10GBASE-X PCS/PMA is
utlized by the XGXS/XAUI specifications (Clause 47).
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Add 10gbase-x to the list of accepted PHY connection types between MAC and
a physical PHY. It's physically compatible with xaui but defines PCS and
PMA interface (Clause 48) towards the 10GBASE-CX4 (see Clause 54),
10GBASE-KX4 (see Clause 71), and 10GBASE-LX4 (see Clause 53). Network
subsystem will be updated in the next commit.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW XPCS can be synthesized with 10GBASE-R link support. In that case xGMAC
is still connected to the XPCS device by means of normally multi-lane
interface meanwhile an external interface is defined as 10GBASE-R. From
network subsystem point of view it's as if DW XPCS is fully integrated
into the MAC with no need in setting any intermediate interface up.
So based on the IEEE 802.3 standard 10GBASE-R doesn't intent any
auto-negotiations. Instead it works with the 10Gbps speed and in the
Full-duplex mode. Thus a new AN-less mode is defined DW_10GBASER in the
driver. It implies PCS and PMA setups required for the device to work in
the denoted mode. The respective actions are executed in the
xpcs_do_config() method. At the same time xpcs_link_up() makes sure that
the PCS/PMA<->PHY link actually works and it has compatible speed and
duplex (though having the pcs_link_up() method returning the operation
status would look better or at least having pcs_get_state() working for
the non-inband setups).
Note 1. 10GBASE-R PMA config implies reference clock switch in case if the
respective flag doesn't correspond to the specified clock sources.
Note 2. XPCS 10GBASE-R interface features list contains all
speed-compatible link modes in order to have the pcs_validate() permitting
these modes for the externally attached PHYs.
Note 3. Soft-reset and poll-mode are activated on the XPCS-descriptor
create procedure since the interface initialization is now comprehensive
enough to configure device from scratch.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In order have the XPCS CSRs read, write, modify, poll and device
soft-reset methods accessible from separate objects let's globally define
them. They will be utilized from the PMA-config methods which in its
turned will be later defined separately in order to simplify the main
driver object file.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Various DW XPCS setups require vendor-specific reset procedure
implementation, i.e. PCS type (KR, KX4, KX, etc) selection. It implies the
reset of all DWC_xpcs internal blocks except the Management interface and
CSR blocks (the standard reset clears the CSR block too). Since a
multi-type XPCS support is about to be added let's add the vendor-specific
reset as a preparation before that.
Note 1. Since vendor-specific reset doesn't imply the CSR blocks reset we
can't just write the flag to the corresponding register because thus we
may override/clear some valuable CSR fields. Instead the MDIO-device
modify method is utilized.
Note 2. xpcs_poll_reset() method is converted to accepting CSR and flag to
poll. It is done intentionally even though currently it's used to poll
BIT(15) in the specified register. It may and will be used to poll some
other fields in the DW XPCS space like reference clock stabilization, etc.
Thus the renaming.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
It's very much inconvenient to have the soft-reset method requiring the
xpcs_compat structure instance passed. The later one is found based on the
PHY-interface type which isn't always available. Such design makes an
ordinary reset-method context depended and unnecessary limits its usage
area. Indeed based on [1,2] all Soft-RST flags exported by the PMA/PMD,
PCS, AN or MII MMDs are _shared_. It means it resets all the DWX_xpcs
internal blocks including CSRs, but except the Management Interface (MDIO,
MCI, APB). Thus it doesn't really matter which MMDs soft-reset flag is
set, the result will be the same. So the AN-mode-depended code can be
freely dropped from the soft-reset method. But depending on the DW XPCS
device capabilities (basically it depends on the IP-core synthesize
parameters) it can lack some of the MMDs. In order to solve that
difficulty the Vendor-Specific 1 MMD can be utilized. It is also called as
Control MMD and exports some generic device info about the device
including a list of the available MMDs: PMA/PMD, XS/PCS, AN or MII. This
MMD persists on all the DW XPCS device [3]. Thus it can be freely utilize
to cross-platformly determine actual MMD to perform the soft-reset.
[1] DesignWare® Cores Ethernet PCS, Version 3.11b, June 2015, p.111.
[2] DesignWare® Cores Ethernet PCS, Version 3.11b, June 2015, p.268.
[3] DesignWare® Cores Ethernet PCS, Version 3.11b, June 2015, p.269.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Natively DW XPCS (v3.xx) supports two upstream interfaces: XGMII and
GMII/MII. Former one is responsible for the 10G link speed. It's a 32-bits
interface normally connected to MAC and which is supposed to be used for
the PCS-R and 10G PCS-X data paths. Despite of the USXGMII it doesn't
support speed change. So just the only thing what needs to be done is to
add the interface and features for the XGMII interface and rely on the
auto-negotiation procedure to establish the link.
Note DW xGMII PHY-mode support must be added to the STMMAC driver in order
to have DW XGMAC/XPCS chain working correctly.
TODO add some configs to the xpcs_config_xgmii() method.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
XGMII is an interface between MAC and PCS. So it's a subject of the PCS
device implementation whether it supports passing link information in-band
between PHY and MAC PCS. Anyway add XGMII to the list of protocols that
support in-band AN mode and let the PCS driver to decide the supported
link modes.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Based on the IEEE Std 802.3 Clause 73 specification 10GBASE-KR interface
must support auto-negotiation for any KR and legacy R links (see Table
72–1 in the spec). Thus the link speed is supposed to be determined based
on the link-partner modes retrieved on the negotiation stage. Let's fix
that by adding the Autoneg flag to the list of the 10GBASE-KR features so
the xpcs_get_state_c73() procedure would initialize the phylink state
descriptor based on the link-partner abilities.
Note since the max link speed is now determined based on the modes
retrieved from the remote device there is no need in manual speed setting
up in the xpcs_resolve_pma() method. So the respective case clause can be
freely dropped from there.
Fixes: fcb26bd2b6ca ("net: phy: Add Synopsys DesignWare XPCS MDIO module")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The phylink_link_state->pause field can have some flags being pre-set
(i.e. MLO_PAUSE_AN) by the phylink core before it's passed to the
phylink_pcs_ops.pcs_get_state() callback. Moreover based on the
phylink_pcs_ops.pcs_get_state() kernel doc it is intended to update the
MLO_PAUSE_RX and MLO_PAUSE_TX flags state only. So drop zeroing out the
phylink_link_state->pause field from the xpcs_get_state_c37_sgmii() method
as pointless and potentially harmful.
Link: https://lore.kernel.org/netdev/ZTuvwnGZKEueGDwa@shell.armlinux.org.uk
Fixes: b97b5331b8ab ("net: pcs: add C37 SGMII AN support for intel mGbE controller")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Besides of MLO_PAUSE_RX and MLO_PAUSE_TX flags the
phylink_link_state->pause field can have other flags set (i.e.
MLO_PAUSE_AN) by the phylink core. Moreover based on the
phylink_pcs_ops.pcs_get_state() kernel doc the later callback is intended
to update the MLO_PAUSE_RX and MLO_PAUSE_TX flags state only. So drop
overriding the entire phylink_link_state->pause field from the
xpcs_resolve_pma() method as pointless and potentially harmful.
Link: https://lore.kernel.org/netdev/ZTuvwnGZKEueGDwa@shell.armlinux.org.uk
Fixes: fcb26bd2b6ca ("net: phy: Add Synopsys DesignWare XPCS MDIO module")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
By default CSR clock is disabled upon request. It makes the PM-runtime
state matching the default PM-state of the device - suspended. Thus let's
drop the PM-runtime setting up to be active as incorrect. Otherwise the
clock-subsystem will be unhappily printing a big fat warning about
n-preparing an already unprepared clock.
Fixes: f6bb3e9d98c2 ("net: pcs: xpcs: Add Synopsys DW xPCS platform device driver")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
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>
|
