Add a define for the number of priority queues on lan966x. Because there
will be more checks for this, so instead of using hardcoded value all
over the place add a define for this.
Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

use kstrdup instead of open-coding it.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Acked-by: NWei Liu <wei.liu@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Read link status from SGMII PCS for in-band managed 2500Base-X and
1000Base-X connection on a MAC port of the MT7531. This is needed to
get the SFP cage working which is connected to SGMII interface of
port 5 of the MT7531 switch IC on the Bananapi BPi-R3 board.
While at it also handle an_complete for both the autoneg and the
non-autoneg codepath.
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This adds support for rate matching for phys similar to the AQR107. We
assume that all phys using aqr107_read_status support rate matching.
However, it could be possible to determine support based on the firmware
revision if there are phys discovered which do not support rate
matching.  However, as rate matching is advertised in the datasheets for
these phys, I suspect it is supported most boards.

Despite the name, the "config" registers are updated with the current
rate matching method (if any). Because they appear to be updated
automatically, I don't know if these registers can be used to disable
rate matching.
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These are documented in the AQR115 register reference. I haven't tested
them, but perhaps they'll be useful to someone.
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This adds support for adjusting the advertisement for pause-based rate
matching. This may result in a lossy link, since the final link settings
are not adjusted. Asymmetric pause support is necessary. It would be
possible for a MAC supporting only symmetric pause to use pause-based rate
adaptation, but only if pause reception was enabled as well.
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the phy is configured to use pause-based rate matching, ensure that
the link is full duplex with pause frame reception enabled. As
suggested, if pause-based rate matching is enabled by the phy, then
pause reception is unconditionally enabled.

The interface duplex is determined based on the rate matching type.
When rate matching is enabled, so is the speed. We assume the maximum
interface speed is used. This is only relevant for MLO_AN_PHY. For
MLO_AN_INBAND, the MAC/PCS's view of the interface speed will be used.

Although there are no RATE_ADAPT_CRS phys in-tree, it has been added for
comparison (and the implementation is quite simple).
Co-developed-by: NRussell King <linux@armlinux.org.uk>
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This adds support for rate matching (also known as rate adaptation) to
the phy subsystem. The general idea is that the phy interface runs at
one speed, and the MAC throttles the rate at which it sends packets to
the link speed. There's a good overview of several techniques for
achieving this at [1]. This patch adds support for three: pause-frame
based (such as in Aquantia phys), CRS-based (such as in 10PASS-TS and
2BASE-TL), and open-loop-based (such as in 10GBASE-W).

This patch makes a few assumptions and a few non assumptions about the
types of rate matching available. First, it assumes that different phys
may use different forms of rate matching. Second, it assumes that phys
can use rate matching for any of their supported link speeds (e.g. if a
phy supports 10BASE-T and XGMII, then it can adapt XGMII to 10BASE-T).
Third, it does not assume that all interface modes will use the same
form of rate matching. Fourth, it does not assume that all phy devices
will support rate matching (even if some do). Relaxing or strengthening
these (non-)assumptions could result in a different API. For example, if
all interface modes were assumed to use the same form of rate matching,
then a bitmask of interface modes supportting rate matching would
suffice.

For some better visibility into the process, the current rate matching
mode is exposed as part of the ethtool ksettings. For the moment, only
read access is supported. I'm not sure what userspace might want to
configure yet (disable it altogether, disable just one mode, specify the
mode to use, etc.). For the moment, since only pause-based rate
adaptation support is added in the next few commits, rate matching can
be disabled altogether by adjusting the advertisement.

802.3 calls this feature "rate adaptation" in clause 49 (10GBASE-R) and
"rate matching" in clause 61 (10PASS-TL and 2BASE-TS). Aquantia also calls
this feature "rate adaptation". I chose "rate matching" because it is
shorter, and because Russell doesn't think "adaptation" is correct in this
context.
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we call phylink_caps_to_linkmodes directly from
phylink_get_linkmodes, it is difficult to re-use this functionality in
MAC drivers. This is because MAC drivers must then work with an ethtool
linkmode bitmap, instead of with mac capabilities. Instead, let the
caller of phylink_get_linkmodes do the conversion. To reflect this
change, rename the function to phylink_get_capabilities.
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This function is convenient for MAC drivers. They can use it to add or
remove particular link modes based on capabilities (such as if half
duplex is not supported for a particular interface mode).
Signed-off-by: NSean Anderson <sean.anderson@seco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for offloading ets qdisc to sparx5 switch.

The ets qdisc makes it possible to configure a mix og strict and
bandwidth-sharing bands. The ets qdisc must be attached as a root qdisc.
Signed-off-by: NDaniel Machon <daniel.machon@microchip.com>
Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for offloading tbf qdisc to sparx5 qdisc.

The tbf qdisc makes it possible to attach a shaper on traffic egressing
from a port or a queue. Per-port tbf qdiscs are attached as a root qdisc
directly and queue tbf qdiscs are attached to one of the classes of a
parent qdisc (such as mqprio).
Signed-off-by: NDaniel Machon <daniel.machon@microchip.com>
Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for offloading mqprio qdisc to sparx5 switch.

The offloaded mqprio qdisc currently does nothing by itself, but serves
as an attachment point for other qdiscs (tbf, ets etc.)
Signed-off-by: NDaniel Machon <daniel.machon@microchip.com>
Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add tc setup hook for QoS features.
Signed-off-by: NDaniel Machon <daniel.machon@microchip.com>
Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary set_drvdata(NULL) function in ->remove(),
the driver_data will be set to NULL in device_unbind_cleanup()
after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary spi_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary platform_set_drvdata() in ->remove(), the driver_data
will be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary set_drvdata(NULL) function in ->remove(),
the driver_data will be set to NULL in device_unbind_cleanup()
after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Acked-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary set_drvdata(NULL) function in ->remove(),
the driver_data will be set to NULL in device_unbind_cleanup()
after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary set_drvdata(NULL) function in ->remove(),
the driver_data will be set to NULL in device_unbind_cleanup()
after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary platform_set_drvdata() in ->remove(), the driver_data
will be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary platform_set_drvdata() in ->remove(), the driver_data
will be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Acked-by: NKurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will
be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary platform_set_drvdata() in ->remove(), the driver_data
will be set to NULL in device_unbind_cleanup() after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary set_drvdata(NULL) function in ->remove(),
the driver_data will be set to NULL in device_unbind_cleanup()
after calling ->remove().
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Support setting replay window size for MACsec offload.
Currently supported window size of 32, 64, 128 and 256
bit. Other values will be returned as invalid parameter.
Reviewed-by: NRaed Salem <raeds@nvidia.com>
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

MACsec EPN splits the packet number (PN) into two 32-bits fields,
epn_lsb (32 least significant bits (LSBs) of PN) and epn_msb (32
most significant bits (MSBs) of PN).
Epn_msb bits are managed by SW and for that HW is required to send
an object change event of type EPN event notifying the SW to update
the epn_msb in addition, once epn_msb is updated SW update HW with
the new epn_msb value for HW to perform replay protection.
To prevent HW from stopping while handling the event, SW manages
another bit for HW called epn_overlap, HW uses the latter to get
an indication regarding how to read the epn_msb value correctly
while still receiving packets.
Add epn event handling that updates the epn_overlap and epn_msb for
every 2^31 packets according to the following logic:
if epn_lsb crosses 2^31 (half sequence number wraparound) upon HW
relevant event, SW updates the esn_overlap value to OLD (value = 1).
When the epn_lsb crosses 2^32 (full sequence number wraparound)
upon HW relevant event, SW updates the esn_overlap to NEW
(value = 0) and increment the esn_msb.
When using MACsec EPN a salt and short secure channel id (ssci)
needs to be provided by the user, when offloading EPN need to pass
this salt and ssci to the HW to be used in the initial vector (IV)
calculations.
Reviewed-by: NRaed Salem <raeds@nvidia.com>
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Postpone MACsec initialization to the mlx5e profile enable stage to have
user access region (UAR) pages and other resources ready before MACsec
initialization to initialize advanced steering operation (ASO) hardware
resources.
Reviewed-by: NRaed Salem <raeds@nvidia.com>
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add support for ASO work queue entry (WQE) data to allow reading
data upon querying the ASO work queue (WQ).
Register user mode memory registration (UMR) upon ASO WQ init,
de-register UMR upon ASO WQ cleanup.
MACsec uses UMR to determine the cause of the event triggered
by the HW since different scenarios could trigger the same event.
Setup MACsec ASO object to sync HW with SW about various macsec
flow stateful features like: replay window, lifetime limits e.t.c
Reviewed-by: NRaed Salem <raeds@nvidia.com>
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Expose mlx5e_create_mkey function, for future patches in the
macsec series to use.
The above function creates a memory key which describes a
region in memory that can be later used by both HW and SW.
The counterpart destroy functionality is already exposed.
Reviewed-by: NRaed Salem <raeds@nvidia.com>
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently when creating MACsec object, next_pn which represents
the initial packet number (PN) is considered only in TX flow.
The above causes mismatch between TX and RX initial PN which
is reflected in packet drops.
Fix by considering next_pn in RX flow too.

Fixes: aae3454e ("net/mlx5e: Add MACsec offload Rx command support")
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently MACsec initialization error path does not
destroy sci hash table in case of failure.
Fix by destroying hash table in case of failure.

Fixes: 9515978e ("net/mlx5e: Implement MACsec Tx data path using MACsec skb_metadata_dst")
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently macsec invokes HW offload path before reading extended packet
number (EPN) related user properties i.e. salt and short secure channel
identifier (ssci), hence preventing macsec EPN HW offload.
Expose those by moving macsec EPN properties reading prior to HW offload
path.
Signed-off-by: NEmeel Hakim <ehakim@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>