- Aug 31, 2022
-
-
Oleksij Rempel authored
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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:
-
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:
Jakub Kicinski <kuba@kernel.org>
-
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:
-
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/1695 Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20220825180607.2707947-1-nathan@kernel.org Signed-off-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.us Signed-off-by:
-
- Aug 30, 2022
-
-
Mengyuan Lou authored
Add build options and guidance doc. Initialize pci device access for Wangxun Gigabit Ethernet devices. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://lore.kernel.org/r/20220826034609.51854-1-mengyuanlou@net-swift.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Baowen Zheng authored
Add support for eeprom get and set operation with ethtool command. with this change, we can support commands as: #ethtool -e enp101s0np0 offset 0 length 6 Offset Values ------ ------ 0x0000: 00 15 4d 16 66 33 #ethtool -E enp101s0np0 magic 0x400019ee offset 5 length 1 value 0x88 We make this change to persist MAC change during driver reload and system reboot. Signed-off-by:
Baowen Zheng <baowen.zheng@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Yinjun Zhang authored
A new tlv type is introduced to indicate if application firmware is indifferent to port speed, and inform management firmware of the result. And the result is always true for flower application firmware since it's indifferent to port speed from the start and will never change. Signed-off-by:
Yinjun Zhang <yinjun.zhang@corigine.com> Reviewed-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
-
Yinjun Zhang authored
In future releases the NIC application firmware may be indifferent to port speeds - not built for specific port speeds - and consequently it will not be able to report VF port speeds to the driver without first learning them. With this change, the driver will pass the speed of physical ports from management firmware to application firmware, and the latter will copy the speed of port 0 to all the active VFs. So that the driver can get VF port speed as before. The port speed of a VF may be requested from userspace using: ethtool <vf-intf> Signed-off-by:
-
- Aug 29, 2022
-
-
Casper Andersson authored
All multicast should be forwarded to mrouter ports. Mrouter ports must therefore be part of all active multicast groups, and override flooding from being disabled. Signed-off-by:
Casper Andersson <casper.casan@gmail.com> Signed-off-by:
-
Casper Andersson authored
Keep track of all mdb entries in software for easy access. Signed-off-by:
-
Jakub Kicinski authored
We had historically not checked that genlmsghdr.reserved is 0 on input which prevents us from using those precious bytes in the future. One use case would be to extend the cmd field, which is currently just 8 bits wide and 256 is not a lot of commands for some core families. To make sure that new families do the right thing by default put the onus of opting out of validation on existing families. Signed-off-by:
-
- Aug 27, 2022
-
-
Dan Carpenter authored
The "fixed_link" is only allocated sometimes but it's freed unconditionally in the error handling. Set it to NULL so we don't free uninitialized data. Fixes: 9ea4742a ("net: fman: Configure fixed link in memac_initialization") Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/Ywd2X6gdKmTfYBxD@kili Signed-off-by:
-
Sergei Antonov authored
This driver always generated a random ethernet address. Leave it as a fallback solution, but add a call to platform_get_ethdev_address(). Handle EPROBE_DEFER returned from platform_get_ethdev_address() to retry when EEPROM is ready. Signed-off-by:
Sergei Antonov <saproj@gmail.com> Reviewed-by:
-
Marcus Carlberg authored
p0_mode set to one of the supported serial mode should not prevent configuring the external SMI interface in mv88e6xxx_g2_scratch_gpio_set_smi. The current masking of the p0_mode only checks the first 2 bits. This results in switches supporting serial mode cannot setup external SMI on certain serial modes (Ex: 1000BASE-X and SGMII). Extend the mask of the p0_mode to include the reduced modes and serial modes as allowed modes for the external SMI interface. Signed-off-by:
Marcus Carlberg <marcus.carlberg@axis.com> Link: https://lore.kernel.org/r/20220824093706.19049-1-marcus.carlberg@axis.com Signed-off-by:
-
Jack Wang authored
dma_map_sg return 0 on error. Signed-off-by:
Jack Wang <jinpu.wang@ionos.com> Reviewed-by:
-
Jiri Pirko authored
Whenever the type_set() is called on a devlink port, accompany it by matching type_clear() during cleanup. Signed-off-by:
-
- Aug 26, 2022
-
-
Marcus Carlberg authored
Since the probe defaults all interfaces to the highest speed possible (10GBASE-X in mv88e6393x) before the phy mode configuration from the devicetree is considered it is currently impossible to use port 0 in RGMII mode. This change will allow RGMII modes to be configurable for port 0 enabling port 0 to be configured as RGMII as well as serial depending on configuration. Signed-off-by:
-
Jean-Francois Le Fillatre authored
The Lenovo OneLink+ Dock contains an RTL8153 controller that behaves as a broken CDC device by default. Add the custom Lenovo PID to the r8152 driver to support it properly. Also, systems compatible with this dock provide a BIOS option to enable MAC address passthrough (as per Lenovo document "ThinkPad Docking Solutions 2017"). Add the custom PID to the MAC passthrough list too. Tested on a ThinkPad 13 1st gen with the expected results: passthrough disabled: Invalid header when reading pass-thru MAC addr passthrough enabled: Using pass-thru MAC addr XX:XX:XX:XX:XX:XX Signed-off-by:
Jean-Francois Le Fillatre <jflf_kernel@gmx.com> Signed-off-by:
-
Ping-Ke Shih authored
clang reports uninitialized use: >> drivers/net/wireless/realtek/rtw88/main.c:731:2: warning: variable 'primary_channel_idx' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~~~~~ drivers/net/wireless/realtek/rtw88/main.c:754:39: note: uninitialized use occurs here hal->current_primary_channel_index = primary_channel_idx; ^~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw88/main.c:687:24: note: initialize the variable 'primary_channel_idx' to silence this warning u8 primary_channel_idx; ^ = '\0' This situation could not happen, because possible channel bandwidth 20/40/80MHz are enumerated. Fixes: 341dd1f7 ("wifi: rtw88: add the update channel flow to support setting by parameters") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Reviewed-by:
Johannes Berg <johannes.berg@intel.com>
-
Qingfang DENG authored
As per RGMII specification v2.0, section 3.4.1, RGMII/RTBI has an optional in-band status feature where the PHY's link status, speed and duplex mode can be passed to the MAC. Allow RGMII/RTBI to use in-band status. Signed-off-by:
Qingfang DENG <dqfext@gmail.com> Signed-off-by:
-
Maksym Glubokiy authored
matchall rules can be added only to chain 0 and their priorities have limitations: - new matchall ingress rule's priority must be higher (lower value) than any existing flower rule; - new matchall egress rule's priority must be lower (higher value) than any existing flower rule. The opposite works for flower rule adding: - new flower ingress rule's priority must be lower (higher value) than any existing matchall rule; - new flower egress rule's priority must be higher (lower value) than any existing matchall rule. This is a hardware limitation and thus must be properly handled in driver by reporting errors to the user when newly added rule has such a priority that cannot be installed into the hardware. To achieve this, the driver must maintain both min/max matchall priorities for every flower block when user adds/deletes a matchall rule, as well as both min/max flower priorities for chain 0 for every adding/deletion of flower rules for chain 0. Cc: Serhiy Boiko <serhiy.boiko@plvision.eu> Signed-off-by:
Maksym Glubokiy <maksym.glubokiy@plvision.eu> Signed-off-by:
-
Serhiy Boiko authored
This enables adding matchall rules for egress: tc filter add .. egress .. matchall skip_sw \ action mirred egress mirror dev .. Signed-off-by:Serhiy Boiko <serhiy.boiko@plvision.eu> Signed-off-by:
-
Serhiy Boiko authored
This commit adds more clarity to handling of TC_CLSMATCHALL_REPLACE and TC_CLSMATCHALL_DESTROY events by calling newly added *_mall_*() handlers instead of directly calling SPAN API. This also extracts matchall rules management out of SPAN API since SPAN is a hardware module which is used to implement 'matchall egress mirred' action only. Signed-off-by:
Taras Chornyi <tchornyi@marvell.com> Signed-off-by:
-
Oleksij Rempel authored
Add phylink based ethtool pause configuration Signed-off-by:
-
Oleksij Rempel authored
There are some exotic ax88772 based devices which may require functionality provide by the phylink framework. For example: - US100A20SFP, USB 2.0 auf LWL Converter with SFP Cage - AX88772B USB to 100Base-TX Ethernet (with RMII) demo board, where it is possible to switch between internal PHY and external RMII based connection. So, convert this driver to phylink as soon as possible. Tested with: - AX88772A + internal PHY - AX88772B + external DP83TD510E T1L PHY Signed-off-by:
-
- Aug 25, 2022
-
-
Jiri Pirko authored
Function mlxsw_core_port_type_get() is no longer used. So remove it. Signed-off-by:
-
Jiri Pirko authored
port_type_set devlink op is no longer used by any mlxsw driver, so remove it. Signed-off-by:
-
Jiri Pirko authored
There are some IB leftovers that are no longer used in the code. So remove them. Signed-off-by:
-
Jiri Pirko authored
Limit the acceptance of component name passed to cmd_flash_update() to match one of the versions returned by info_get(), marked by version type. This makes things clearer and enforces 1:1 mapping between exposed version and accepted flash component. Check VERSION_TYPE_COMPONENT version type during cmd_flash_update() execution by calling info_get() with different "req" context. That causes info_get() to lookup the component name instead of filling-up the netlink message. Remove "UPDATE_COMPONENT" flag which becomes used. Signed-off-by:
-
Jiri Pirko authored
Fix the only component user which is netdevsim. It uses component named "fw.mgmt" in selftests. So add this version to info_get() output with version type component. Signed-off-by:
-
Aleksander Jan Bajkowski authored
In a situation where memory allocation fails, an invalid buffer address is stored. When this descriptor is used again, the system panics in the build_skb() function when accessing memory. Fixes: 7ea6cd16 ("lantiq: net: fix duplicated skb in rx descriptor ring") Signed-off-by:
Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by:
-
