- 31 Aug, 2022 40 commits
-
-
Guangbin Huang authored
For some new devices, driver can queries fec ability from firmware to decide which FEC mode can be supported. If devices of old version which not support querying fec ability, driver sets fixed ability according to current speed. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Guangbin Huang authored
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:
-
David S. Miller authored
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: -
Mika Westerberg authored
It is Thunderbolt/USB4 now so reflect that in the module description too to avoid any confusion. No functional changes. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Mika Westerberg authored
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:
-
Mika Westerberg authored
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:
-
Mika Westerberg authored
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:
-
Mika Westerberg authored
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:
-
Maxime Chevallier authored
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:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
David S. Miller authored
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: -
Oleksij Rempel authored
Use chip_id as other places of this code do it Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
This variable is not used. So, remove it. Signed-off-by:
-
Oleksij Rempel authored
This variable is not used on ksz9477 side. Remove it. Signed-off-by:
-
Oleksij Rempel authored
This variable is unused. So, drop it. Signed-off-by:
-
Oleksij Rempel authored
With code refactoring was introduced new variable internal_phy. Let's use it. Signed-off-by:
-
Oleksij Rempel authored
Add register validation for KSZ9477 Signed-off-by:
-
Oleksij Rempel authored
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:
-
Oleksij Rempel authored
Add register validation for KSZ8563. Signed-off-by:
-
Oleksij Rempel authored
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:
-
Oleksij Rempel authored
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:
-
Oleksij Rempel authored
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by:
-
Oleksij Rempel authored
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by:
-
Oleksij Rempel authored
ksz_read*/ksz_write* are able to return errors, so forward it. Signed-off-by:
-
Oleksij Rempel authored
PHY access may end with errors on different levels. So, allow to forward return values where possible. Signed-off-by:
-
Oleksij Rempel authored
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:
-
Oleksij Rempel authored
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:
-
Oleksij Rempel authored
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:
-
Xin Gao authored
'unsigned int' is better than 'unsigned'. Signed-off-by:
Xin Gao <gaoxin@cdjrlc.com> Signed-off-by:
-
Vlad Buslov authored
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:
Vlad Buslov <vladbu@nvidia.com> Tested-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20220829121324.3980376-1-vladbu@nvidia.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
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: -
Amit Cohen authored
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:Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Amit Cohen authored
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:
-
Amit Cohen authored
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: -
Amit Cohen authored
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:
-
Fernando Fernandez Mancera authored
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:
Fernando Fernandez Mancera <ffmancera@riseup.net> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Link: https://lore.kernel.org/r/20220826154738.4039-1-ffmancera@riseup.netSigned-off-by:
-
Dan Carpenter authored
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:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Nathan Chancellor authored
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:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
-
Jiri Pirko authored
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:
Jiri Pirko <jiri@nvidia.com> Acked-by:
Dimitris Michailidis <dmichail@fungible.com> Link: https://lore.kernel.org/r/20220826110411.1409446-1-jiri@resnulli.usSigned-off-by:
-
Jakub Kicinski authored
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:
-
Arınç ÜNAL authored
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:
Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
