As some new devices may not support GRO offload and flow table director,
to support these devices, driver needs to querying capabilities of GRO
offload and flow table director from firmware. Whether the driver
supports these two features depends on capabilities.

For old device of version HNAE3_DEVICE_VERSION_V2, driver sets their
capabilities of these two features to fixed value.

Setting default features of netdev and debugfs also need to identify
whether support these two features.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Mika Westerberg says:

====================
thunderbolt: net: Enable full end-to-end flow control

Thunderbolt/USB4 host controllers support full end-to-end flow control
that prevents dropping packets if there are not enough hardware receive
buffers. So far it has not been enabled for the networking driver yet
but this series changes that. There is one snag though: the second
generation (Intel Falcon Ridge) had a bug that needs special quirk to
get it working. We had that in the early stages of the Thunderbolt/USB4
driver but it got dropped because it was not needed at the time. Now we
add it back as a quirk for the host controller (NHI).

The first patch of this series is a bugfix that I'm planning to push for
v6.0-rc. Rest are v6.1 material. This also includes a patch that shows
the XDomain link type in sysfs the same way we do for USB4 routers and
updates the networking driver module description.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is Thunderbolt/USB4 now so reflect that in the module description too
to avoid any confusion. No functional changes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

USB4NET protocol allows the networking drivers to take advantage of
end-to-end flow control supported by the USB4 host interface. This
should prevent the receiving side from dropping network packets.

In adddition add a module parameter that can be used to turn this off
just in case it causes problems.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As we are now enabling full end-to-end flow control to the Thunderbolt
networking driver, in order for it to work properly on second generation
Thunderbolt hardware (Falcon Ridge), we need to add back the workaround
that was removed with commit 53f13319 ("thunderbolt: Get rid of E2E
workaround"). However, this time we only apply it for Falcon Ridge
controllers as a form of an additional quirk. For non-Falcon Ridge this
does nothing.

While there fix a typo 'reqister' -> 'register' in the comment.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Following what we do for routers already, extend this to XDomain
connections as well. This will show in sysfs whether the link is in USB4
or Thunderbolt mode.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the other host starts sending packets early on it is possible that we
are still in the middle of populating the initial Rx ring packets to the
ring. This causes the tbnet_poll() to mess over the queue and causes
list corruption. This happens specifically when connected with macOS as
it seems start sending various IP discovery packets as soon as its side
of the paths are configured.

To prevent this we move the DMA path enabling to happen after we have
primed the Rx ring. This makes sure no incoming packets can arrive
before we are ready to handle them.

Fixes: e69b6c02 ("net: Add support for networking over Thunderbolt cable")
Cc: stable@vger.kernel.org
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Makes so that the serdes driver also takes QUSGMII in consideration.
It's configured exactly as QSGMII as far as the serdes driver is
concerned.
Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Oleksij Rempel says:

====================
net: dsa: microchip: add error handling and register access validation

changes v4:
- add Reviewed-by: Vladimir Oltean <olteanv@gmail.com> to all patches
- fix checkpatch warnings.

changes v3:
- fix build error in the middle of the patch stack.

changes v2:
- add regmap_ranges for KSZ9477
- drop output clock devicetree in driver validation patches. DTs need
  some more refactoring and can be done in a separate patch set.
- remove some unused variables.

This patch series adds error handling for the PHY read/write path and optional
register access validation.
After adding regmap_ranges for KSZ8563 some bugs was detected, so
critical bug fixes are sorted before ragmap_range patch.

Potentially this bug fixes can be ported to stable kernels, but need to be
reworked.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use chip_id as other places of this code do it
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This variable is not used. So, remove it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This variable is not used on ksz9477 side. Remove it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This variable is unused. So, drop it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With code refactoring was introduced new variable internal_phy. Let's
use it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add register validation for KSZ9477
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The reason why PHYlib may access MII_CTRL1000 on the chip without GBit
support is only if chip provides wrong information about extended caps
register. This issue is now handled by ksz9477_r_phy_quirks()

With proper regmap_ranges provided for all chips we will be able to
catch this kind of bugs any way. So, remove this sanity check.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add register validation for KSZ8563.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is complex driver with support for different chips with different
layouts. To detect at least some bugs earlier, we should validate register
accesses by using regmap_access_table support.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This issue was detected after adding regmap register access validation.
KSZ9893 compatible chips do not have "Output Clock Control Register
0x0103". So, avoid writing to it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now ksz_pread/ksz_pwrite can return error value. So, make use of it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now ksz_pread/ksz_pwrite can return error value. So, make use of it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ksz_read*/ksz_write* are able to return errors, so forward it.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

PHY access may end with errors on different levels. So, allow to forward
return values where possible.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This issue was detected after adding support of regmap_ranges for KSZ8563R
chip. This chip is reporting extended registers support without having
actual extended registers. This made PHYlib request not existing
registers.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

KSZ8563 has two 100Mbit PHYs and CPU port with RGMII support. Since
1000Mbit configuration for the RGMII capable MAC is present, we should
use per port validation.

As main part of migration to per-port validation we need to rework
ksz9477_switch_init() function. Which is using undocumented
REG_GLOBAL_OPTIONS register to detect per-chip Gbit support. So, it is
related to some sort of risk for regressions.

To reduce this risk I compared the code with publicly available
documentations. This function will executed on following currently
supported chips:
struct ksz_chip_data            OF compatible
KSZ9477				KSZ9477
KSZ9897				KSZ9897
KSZ9893				KSZ9893, KSZ9563
KSZ8563				KSZ8563
KSZ9567				KSZ9567

Only KSZ9893, KSZ9563, KSZ8563 document existence of 0xf ==
REG_GLOBAL_OPTIONS register with bit field description "SKU ID":
KSZ9893 0x0C
KSZ9563 0x1C
KSZ8563 0x3C

The existence of hidden flags is not documented.

KSZ9477, KSZ9897, KSZ9567 do not document this register at all.

Only KSZ8563 is documented as non Gbit chip: 100Mbit PHYs and RGMII CPU
port. So, this change should not introduce a regression for
configurations with properly used OF compatibles.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add separate entry for the KSZ8563 chip. According to the documentation
it can support Gbit only on RGMII port. So, we will need to be able to
describe in the followup patch.
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

'unsigned int' is better than 'unsigned'.
Signed-off-by: NXin Gao <gaoxin@cdjrlc.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 6005a8ae.

The assertion was intentionally removed in commit 043b8413 ("net:
devlink: remove redundant rtnl lock assert") and, contrary what is
described in the commit message, the comment reflects that: "Caller must
hold RTNL mutex or reference to dev...".
Signed-off-by: NVlad Buslov <vladbu@nvidia.com>
Tested-by: NLeon Romanovsky <leonro@nvidia.com>
Link: https://lore.kernel.org/r/20220829121324.3980376-1-vladbu@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Petr Machata says:

====================
mlxsw: Configure max LAG ID for Spectrum-4

Amit Cohen writes:

In the device, LAG identifiers are stored in the port group table (PGT).
During initialization, firmware reserves a certain amount of entries at
the beginning of this table for LAG identifiers.

In Spectrum-4, the size of the PGT table did not increase, but the
maximum number of LAG identifiers was doubled, leaving less room for
others entries (e.g., flood entries) that also reside in the PGT.

Therefore, in order to avoid a regression and as long as there is no
explicit requirement to support 256 LAGs, configure the firmware to
allocate the same amount of LAG entries (128) as in Spectrum-{2,3}.

This can be done via the 'max_lag' field in CONFIG_PROFILE command.

Patch set overview:
Patch #1 edits the comment of the existing 'max_lag' field.
Patch #2 adds support for configuring 'max_lag' field via CONFIG_PROFILE
command.
Patch #3 adds an helper function to get the actual 'max_lag' in the
device.
Patch #4 adjusts Spectrum-4 to configure 'max_lag' field.
====================

Link: https://lore.kernel.org/r/cover.1661527928.git.petrm@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Starting from Spectrum-4, the maximum number of LAG IDs can be configured
by software via CONFIG_PROFILE command during driver initialization.

Add a dedicated instance of 'struct mlxsw_config_profile' for Spectrum-4
and set the 'max_lag' field to 128, which is the same amount of LAG entries
as in Spectrum-{2,3}. Without this configuration, firmware reserves 256
(the value of 'cap_max_lag' resource) entries at beginning of PGT table for
LAG identifiers, which means that less entries in PGT will be available.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Reviewed-by: NPetr Machata <petrm@nvidia.com>
Signed-off-by: NPetr Machata <petrm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently the driver queries the maximum supported LAG ID from firmware.
This will not be accurate anymore once the driver will configure 'max_lag'
via CONFIG_PROFILE command.

For resource query, firmware returns the maximum LAG ID which is supported
by hardware. Software can configure firmware to do not allocate entries for
all the supported LAGs, and to limit LAG IDs. In this case, the resource
query will not return the actual maximum LAG ID.

Add a helper function for getting this value. In case that 'max_lag' field
was set during initialization, return the value which was used, otherwise,
query firmware for the maximum supported ID.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Reviewed-by: NPetr Machata <petrm@nvidia.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NPetr Machata <petrm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

In the device, LAG identifiers are stored in the port group table (PGT).
During initialization, firmware reserves a certain amount of entries at
the beginning of this table for LAG identifiers.

In Spectrum-4, the size of the PGT table did not increase, but the maximum
number of LAG identifiers was doubled, leaving less room for others entries
(e.g., flood entries) that also reside in the PGT.

Therefore, in order to avoid a regression and as long as there is no
explicit requirement to support 256 LAGs, mlxsw driver will configure the
firmware to allocate the same amount of LAG entries (128) as in
Spectrum-{2,3}. This configuration is done using 'max_lag' field in
CONFIG_PROFILE command. Extend 'struct mlxsw_config_profile' to support
'max_lag' field and configure firmware accordingly.

A next patch will adjust Spectrum-4 to configure 'max_lag' field.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Reviewed-by: NPetr Machata <petrm@nvidia.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NPetr Machata <petrm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Starting from Spectrum-4, the maximum number of LAG IDs can be configured
by software via CONFIG_PROFILE command during driver initialization.

Edit the comment of 'max_lag' field to mention that this field is reserved
in Spectrum-1/2/3 and describe firmware behavior.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Reviewed-by: NPetr Machata <petrm@nvidia.com>
Signed-off-by: NPetr Machata <petrm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

tlb_dynamic_lb bonding option is compatible with balance-tlb and balance-alb
modes. In order to be consistent with other option documentation, it should
mention both modes not only balance-tlb.
Signed-off-by: NFernando Fernandez Mancera <ffmancera@riseup.net>
Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
Link: https://lore.kernel.org/r/20220826154738.4039-1-ffmancera@riseup.netSigned-off-by: NJakub Kicinski <kuba@kernel.org>

These error paths return success but they should return -ENOMEM.

Fixes: 01328e23 ("mlxsw: minimal: Extend module to port mapping with slot index")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NPetr Machata <petrm@nvidia.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/YwjgwoJ3M7Kdq9VK@kiliSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Clang warns:

  drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:481:6: error: variable 'err' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
          if (IS_ERR(flow_rule)) {
              ^~~~~~~~~~~~~~~~~
  drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:489:9: note: uninitialized use occurs here
          return err;
                ^~~
  drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:481:2: note: remove the 'if' if its condition is always true
          if (IS_ERR(flow_rule)) {
          ^~~~~~~~~~~~~~~~~~~~~~~
  drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:474:9: note: initialize the variable 'err' to silence this warning
          int err;
                ^
                  = 0
  1 error generated.

There is little reason to have the 'goto + error variable' construct in
this function. Get rid of it and just return the PTR_ERR value in the if
statement and 0 at the end.

Fixes: 430e2d5e ("net/mlx5: E-Switch, Move send to vport meta rule creation")
Link: https://github.com/ClangBuiltLinux/linux/issues/1695Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Link: https://lore.kernel.org/r/20220825180607.2707947-1-nathan@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Once devlink port is successfully registered, the devlink pointer is not
NULL. Therefore, the check is going to be always true and therefore
pointless. Remove it.
Signed-off-by: NJiri Pirko <jiri@nvidia.com>
Acked-by: NDimitris Michailidis <dmichail@fungible.com>
Link: https://lore.kernel.org/r/20220826110411.1409446-1-jiri@resnulli.usSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Arınç ÜNAL says:

====================
completely rework mediatek,mt7530 binding

This patch series brings complete rework of the mediatek,mt7530 binding.

The binding is checked with "make dt_binding_check
DT_SCHEMA_FILES=mediatek,mt7530.yaml".

If anyone knows the GIC bit for interrupt for multi-chip module MT7530 in
MT7623AI SoC, let me know. I'll add it to the examples.

If anyone got a Unielec U7623 or another MT7623AI board, please reach out.
====================

Link: https://lore.kernel.org/r/20220825082301.409450-1-arinc.unal@arinc9.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Update the description of the binding.

- Describe the switches, which SoCs they are in, or if they are standalone.
- Explain the various ways of configuring MT7530's port 5.
- Remove phy-mode = "rgmii-txid" from description. Same code path is
followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c.
Signed-off-by: NArınç ÜNAL <arinc.unal@arinc9.com>
Acked-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Define acceptable phy-mode values for the CPU ports of mt7530 and mt7531
switches. Remove relevant information from the description of the binding.
Signed-off-by: NArınç ÜNAL <arinc.unal@arinc9.com>
Reviewed-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>