summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2024-10-29net: marvell: use ethtool string helpersRosen Penev
The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Cleans up the code quite well. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024195833.176843-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29mlx5: simplify EQ interrupt polling logicCaleb Sander Mateos
Use a while loop in mlx5_eq_comp_int() and mlx5_eq_async_int() to clarify the EQE polling logic. This consolidates the next_eqe_sw() calls for the first and subequent iterations. It also avoids a goto. Turn the num_eqes < MLX5_EQ_POLLING_BUDGET check into a break condition. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241023205113.255866-1-csander@purestorage.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29mlx5: fix typo in "mlx5_cqwq_get_cqe_enahnced_comp"Caleb Sander Mateos
"enahnced" looks to be a misspelling of "enhanced". Rename "mlx5_cqwq_get_cqe_enahnced_comp" to "mlx5_cqwq_get_cqe_enhanced_comp". Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Link: https://patch.msgid.link/20241023164840.140535-1-csander@purestorage.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29amd-xgbe: use ethtool string helpersRosen Penev
The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241022233203.9670-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: mana: use ethtool string helpersRosen Penev
The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the data pointer. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Link: https://patch.msgid.link/20241022204908.511021-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29ibmvnic: use ethtool string helpersRosen Penev
They are the preferred way to copy ethtool strings. Avoids manually incrementing the data pointer. Signed-off-by: Rosen Penev <rosenp@gmail.com> Tested-by: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241022203240.391648-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: ftgmac100: refactor getting phy device handleJacky Chou
Consolidate the handling of dedicated PHY and fixed-link phy by taking advantage of logic in of_phy_get_and_connect() which handles both of these cases, rather than open coding the same logic in ftgmac100_probe(). Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241022084214.1261174-1-jacky_chou@aspeedtech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: phylink: simplify how SFP PHYs are attachedRussell King (Oracle)
There are a few issues with how SFP PHYs are attached: a) The phylink_sfp_connect_phy() and phylink_sfp_config_phy() code validates the configuration three times: 1. To discover the support/advertising masks that the PHY/PCS/MAC can support in order to select an interface. 2. To validate the selected interface. 3. When the PHY is brought up after being attached, another validation is done. This is needlessly complex. b) The configuration is set prior to the PHY being attached, which means we don't have the PHY available in phylink_major_config() for phylink_pcs_neg_mode() to make decisions upon. We have already added an extra step to validate the selected interface, so we can now move the attachment and bringup of the PHY earlier, inside phylink_sfp_config_phy(). This results in the validation at step 2 above becoming entirely unnecessary, so remove that too. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1t3bcb-000c8H-3e@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: phylink: validate sfp_select_interface() returned interfaceRussell King (Oracle)
Validate that the returned interface from sfp_select_interface() is supportable by the MAC/PCS. If it isn't, print an error and return the NA interface type. This is a preparatory step to reorganising how a PHY on a SFP module is handled. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1t3bcV-000c8B-Vz@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: phylink: add common validation for sfp_select_interface()Russell King (Oracle)
Whenever we call sfp_select_interface(), we check the returned value and print an error. There are two cases where this happens with the same message. Provide a common function to do this. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1t3bcQ-000c85-S4@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: phylink: simplify phylink_parse_fixedlink()Russell King (Oracle)
phylink_parse_fixedlink() wants to preserve the pause, asym_pause and autoneg bits in pl->supported. Rather than reading the bits into separate bools, zeroing pl->supported, and then setting them if they were previously set, use a mask and linkmode_and() to achieve the same result. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/E1t3Fh5-000aQi-Nk@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: usb: qmi_wwan: add Quectel RG650VBenoît Monin
Add support for Quectel RG650V which is based on Qualcomm SDX65 chip. The composition is DIAG / NMEA / AT / AT / QMI. T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=0122 Rev=05.15 S: Manufacturer=Quectel S: Product=RG650V-EU S: SerialNumber=xxxxxxx C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=9ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=9ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=9ms Signed-off-by: Benoît Monin <benoit.monin@gmx.fr> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024151113.53203-1-benoit.monin@gmx.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net/mlx5e: Update features on ring size changeDragos Tatulea
When the ring size changes successfully, trigger netdev_update_features() to enable features in wanted state if applicable. An example of such scenario: $ ip link set dev eth1 up $ ethtool --set-ring eth1 rx 8192 $ ip link set dev eth1 mtu 9000 $ ethtool --features eth1 rx-gro-hw on --> fails $ ethtool --set-ring eth1 rx 1024 With this patch, HW GRO will be turned on automatically because it is set in the device's wanted_features. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024164134.299646-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net/mlx5e: Update features on MTU changeDragos Tatulea
When the MTU changes successfully, trigger netdev_update_features() to enable features in wanted state if applicable. An example of such scenario: $ ip link set dev eth1 up $ ethtool --set-ring eth1 rx 8192 $ ip link set dev eth1 mtu 9000 $ ethtool --features eth1 rx-gro-hw on --> fails $ ip link set dev eth1 mtu 7000 With this patch, HW GRO will be turned on automatically because it is set in the device's wanted_features. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024164134.299646-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29wwan: core: Pass string literal as format argument of dev_set_name()Simon Horman
Both gcc-14 and clang-18 report that passing a non-string literal as the format argument of dev_set_name() is potentially insecure. E.g. clang-18 says: drivers/net/wwan/wwan_core.c:442:34: warning: format string is not a string literal (potentially insecure) [-Wformat-security] 442 | return dev_set_name(&port->dev, buf); | ^~~ drivers/net/wwan/wwan_core.c:442:34: note: treat the string as an argument to avoid this 442 | return dev_set_name(&port->dev, buf); | ^ | "%s", It is always the case where the contents of mod is safe to pass as the format argument. That is, in my understanding, it never contains any format escape sequences. But, it seems better to be safe than sorry. And, as a bonus, compiler output becomes less verbose by addressing this issue as suggested by clang-18. Compile tested only. No functional change intended. Signed-off-by: Simon Horman <horms@kernel.org> Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Link: https://patch.msgid.link/20241023-wwan-fmt-v1-1-521b39968639@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29netdevsim: Add trailing zero to terminate the string in ↵Zichen Xie
nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly. Fixes: c6385c0b67c5 ("netdevsim: Allow reporting activity on nexthop buckets") Signed-off-by: Zichen Xie <zichenxie0106@gmail.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20241022171907.8606-1-zichenxie0106@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29gtp: allow -1 to be specified as file description from userspacePablo Neira Ayuso
Existing user space applications maintained by the Osmocom project are breaking since a recent fix that addresses incorrect error checking. Restore operation for user space programs that specify -1 as file descriptor to skip GTPv0 or GTPv1 only sockets. Fixes: defd8b3c37b0 ("gtp: fix a potential NULL pointer dereference") Reported-by: Pau Espin Pedrol <pespin@sysmocom.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Tested-by: Oliver Smith <osmith@sysmocom.de> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241022144825.66740-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29mctp i2c: handle NULL header addressMatt Johnston
daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Cc: stable@vger.kernel.org Reported-by: Dung Cao <dung@os.amperecomputing.com> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241022-mctp-i2c-null-dest-v3-1-e929709956c5@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29net: ibm: emac: generate random MAC if not foundRosen Penev
On this Cisco MX60W, u-boot sets the local-mac-address property. Unfortunately by default, the MAC is wrong and is actually located on a UBI partition. Which means nvmem needs to be used to grab it. In the case where that fails, EMAC fails to initialize instead of generating a random MAC as many other drivers do. Match behavior with other drivers to have a working ethernet interface. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29net: ibm: emac: use devm for mutex_initRosen Penev
It seems since inception that mutex_destroy was never called for these in _remove. Instead of handling this manually, just use devm for simplicity. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29net: ibm: emac: use platform_get_irqRosen Penev
No need for irq_of_parse_and_map since we have platform_device. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29net: ibm: emac: use devm_platform_ioremap_resourceRosen Penev
No need to have a struct resource. Gets rid of the TODO. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29net: ibm: emac: use netif_receive_skb_listRosen Penev
Small rx improvement. Would use napi_gro_receive instead but that's a lot more involved than netif_receive_skb_list because of how the function is implemented. Before: > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 51556 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.04 sec 559 MBytes 467 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 48228 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.03 sec 558 MBytes 467 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 47600 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.04 sec 557 MBytes 466 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 37252 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.05 sec 559 MBytes 467 Mbits/sec After: > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 40786 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.05 sec 572 MBytes 478 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 52482 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.04 sec 571 MBytes 477 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 48370 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.04 sec 572 MBytes 478 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 46086 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.05 sec 571 MBytes 476 Mbits/sec > iperf -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.101 port 46062 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-10.04 sec 572 MBytes 478 Mbits/sec Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29ice: fix crash on probe for DPLL enabled E810 LOMArkadiusz Kubalewski
The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: <TASK> ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on "per HW design" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Reviewed-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29ice: block SF port creation in legacy modeMichal Swiatkowski
There is no support for SF in legacy mode. Reflect it in the code. Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Fixes: eda69d654c7e ("ice: add basic devlink subfunctions support") Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29igb: Disable threaded IRQ for igb_msix_otherWander Lairson Costa
During testing of SR-IOV, Red Hat QE encountered an issue where the ip link up command intermittently fails for the igbvf interfaces when using the PREEMPT_RT variant. Investigation revealed that e1000_write_posted_mbx returns an error due to the lack of an ACK from e1000_poll_for_ack. The underlying issue arises from the fact that IRQs are threaded by default under PREEMPT_RT. While the exact hardware details are not available, it appears that the IRQ handled by igb_msix_other must be processed before e1000_poll_for_ack times out. However, e1000_write_posted_mbx is called with preemption disabled, leading to a scenario where the IRQ is serviced only after the failure of e1000_write_posted_mbx. To resolve this, we set IRQF_NO_THREAD for the affected interrupt, ensuring that the kernel handles it immediately, thereby preventing the aforementioned error. Reproducer: #!/bin/bash # echo 2 > /sys/class/net/ens14f0/device/sriov_numvfs ipaddr_vlan=3 nic_test=ens14f0 vf=${nic_test}v0 while true; do ip link set ${nic_test} mtu 1500 ip link set ${vf} mtu 1500 ip link set $vf up ip link set ${nic_test} vf 0 vlan ${ipaddr_vlan} ip addr add 172.30.${ipaddr_vlan}.1/24 dev ${vf} ip addr add 2021:db8:${ipaddr_vlan}::1/64 dev ${vf} if ! ip link show $vf | grep 'state UP'; then echo 'Error found' break fi ip link set $vf down done Signed-off-by: Wander Lairson Costa <wander@redhat.com> Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver") Reported-by: Yuying Ma <yuma@redhat.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB dataFurong Xu
In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a Reported-by: Suraj Jaiswal <quic_jsuraj@quicinc.com> Fixes: f748be531d70 ("stmmac: support new GMAC4") Signed-off-by: Furong Xu <0x1207@gmail.com> Reviewed-by: Hariprasad Kelam <hkelam@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241021061023.2162701-1-0x1207@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29net: stmmac: dwmac4: Fix high address display by updating reg_space[] from ↵Ley Foon Tan
register values The high address will display as 0 if the driver does not set the reg_space[]. To fix this, read the high address registers and update the reg_space[] accordingly. Fixes: fbf68229ffe7 ("net: stmmac: unify registers dumps methods") Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241021054625.1791965-1-leyfoon.tan@starfivetech.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-29wifi: rtw88: 8812a: Mitigate beacon lossBitterblue Smith
The RTL8812AU has a reception problem, maybe only in the 5 GHz band. Sometimes, in some positions, it stops receiving anything even though the distance to the AP is only ~3 meters and there are no obstacles. Moving it a few centimeters fixes it. Switch the initial gain to maximum coverage when there is beacon loss. This only helps sometimes. This is similar to what the official driver does. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/203f5043-4fe1-4f35-8b8f-d3b6f44e1fd9@gmail.com
2024-10-29wifi: rtw88: 8821a: Regularly ask for BT info updatesBitterblue Smith
The RTL8821AU firmware sends C2H_BT_INFO by itself when bluetooth headphones are connected, but not when they are disconnected. This leads to the coexistence code still using the A2DP algorithm long after the headphones are disconnected, which means the wifi speeds are much lower than they should be. Work around this by asking for updates every two seconds if the chip is RTL8821AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/358acdd2-6aae-46c1-9c66-fcce4e700b96@gmail.com
2024-10-29wifi: rtw88: coex: Support chips without a scoreboardBitterblue Smith
All the chips currently supported have a "scoreboard": the chip keeps track of certain things related to bluetooth, for example, whether bluetooth is active. The information can be read from register 0xaa. RTL8821AU doesn't have this. Implement bluetooth activity detection in rtw_coex_monitor_bt_enable() based on the bluetooth TX/RX counters. This is mostly important for RTL8811AU, the version of RTL8821AU without bluetooth. Without this change, the driver thinks bluetooth is active and the wifi speeds are low. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5058f23d-2086-42cd-82ad-eef31a348467@gmail.com
2024-10-29wifi: rtw88: Detect beacon loss with chips other than 8822cBitterblue Smith
The driver is supposed to avoid entering LPS (power saving) when there is beacon loss, but only RTL8822C detects the beacon loss (because it has beacon filtering in the firmware). Detect beacon loss with the other chips by checking if we received less than half the expected number of beacons in the last 2-second interval. This gets rid of the occasional "failed to get tx report from firmware" warnings with RTL8821AU. It may also avoid some disconnections. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/f52b2fcf-bf94-48bc-89bd-e55ebc3a2f2d@gmail.com
2024-10-29wifi: rtw88: usb: Set pkt_info.ls for the reserved pageBitterblue Smith
"ls" meaning "last segment". Without this RTL8812AU can't upload the reserved page in USB 2 mode. (Somehow it's fine in USB 3 mode.) Also tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8723DU, RTL8811AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/e443f5d9-4b53-4f64-985c-64313ec80bef@gmail.com
2024-10-29wifi: rtw88: Move pwr_track_tbl to struct rtw_rfe_defBitterblue Smith
RTL8812AU uses one set of TX power tracking tables for RFE 3, and another set for everything else. Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in order to load the right set of tables for each RFE (RF front end) type. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com
2024-10-29wifi: rtw88: Support TX page sizes bigger than 128Bitterblue Smith
All the chips supported so far have a TX page size of 128 bytes. Change the type of the page_size member of struct rtw_chip_info from u8 to u16 in order to support RTL8821AU (page size of 256 bytes) and RTL8812AU (page size of 512 bytes). Also change the types of several related variables and function parameters from u8 to u16. The TX page size is used, among other things, to construct the beacon, null data, QOS null data, and PS poll templates which are uploaded to the chip's reserved page. Each template needs to be aligned on a multiple of the TX page size. Power saving can't work if the TX page size is wrong. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/acdefbb1-3daf-4349-9e03-9472754d5f1e@gmail.com
2024-10-29wifi: rtw88: Make txagc_remnant_ofdm an arrayBitterblue Smith
txagc_remnant_ofdm member of struct rtw_dm_info should be different for each RF path, so make it an array of size RTW_RF_PATH_MAX (4). Until now all the chips using this had only one RF path, but RTL8812AU has two, and RTL8814AU has four. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/68571ba9-e504-4b2d-bfa1-62f468753649@gmail.com
2024-10-29wifi: rtw88: Enable data rate fallback for older chipsBitterblue Smith
RTL8811AU fails to perform the 4-way handshake when the AP is too far because it transmits the EAPOL frames at MCS9 and when that doesn't work it retries 48 times with the same rate, to no avail. Retrying 48 times with the same rate seems pointless. Set the appropriate field in the TX descriptor to allow it to use lower rates when retrying. Set it for RTL8723D and RTL8703B because they interpret this field the same way as RTL8811A. The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in the TX descriptor differently, so leave it alone for those chips. Tested with RTL8811AU and RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com
2024-10-29wifi: rtw88: Let each driver control the power on/off processBitterblue Smith
RTL8821AU and RTL8812AU have to do some things differently, so let them have full control. The other chips use the same functions as before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
2024-10-29wifi: rtw88: Allow rtw_chip_info.ltecoex_addr to be NULLBitterblue Smith
RTL8821A doesn't have this. Trying to use it results in error messages, so don't try if ltecoex_addr is NULL. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com
2024-10-29wifi: rtw88: Extend the init table parsing for RTL8812AUBitterblue Smith
The chips supported so far only use the first condition, and so the parsing code ignores the second condition. RTL8812AU's init tables use the second condition also. Make the parsing code check it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com
2024-10-29wifi: rtw88: Allow different C2H RA report sizesBitterblue Smith
The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes. Avoid the "invalid ra report c2h length" error. Also, use a struct and u8_get_bits() to access the RA report C2H. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
2024-10-29wifi: rtw88: Dump the HW features only for some chipsBitterblue Smith
RTL8821AU and RTL8812AU don't support this. They hit the "failed to read hw feature report" error. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8becd851-8760-4480-8e8c-c4869ce72507@gmail.com
2024-10-29wifi: rtw88: Add some definitions for RTL8821AU/RTL8812AUBitterblue Smith
Add 8821A and 8812A chip type enums. Add cck_high_power member to struct rtw_hal. This will be used to calculate the RX signal strength of RTL8812AU. Add various register definitions which will be used by the new drivers. Move some existing register definitions from rtw8821c.h and rtw8822b.h. They were duplicated in those headers and will also be used by the new drivers. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com
2024-10-29wifi: rtw88: Report the signal strength only if it's knownBitterblue Smith
RTL8811CU doesn't report the signal strength for many (any?) data frames. When the signal strength is not known, set RX_FLAG_NO_SIGNAL_VAL in order to avoid reporting a signal strength of 0. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/f7e1e448-2c9b-498f-b8b1-a14dd967d7d3@gmail.com
2024-10-29wifi: rtw89: 8922a: extend RFK handling and consider MLOZong-Zhe Yang
Extend FW and driver handling on RFK to support it on both HW bands. Then, according to MLO cases, do the corresponding RF settings. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-6-pkshih@realtek.com
2024-10-29wifi: rtw89: tweak setting of channel and TX power for MLOZong-Zhe Yang
Setting of channel and TX power depend on channel contexts, but original code cannot handle combination of MCC (multi-channel concurrency) and MLO well. So according to active interfaces, we generate a table for current channel contexts. And then based on entity mode, we get the corresponding channel context to apply during channel or TX power setting. When MLO is supported, there will be dual-PHY and we will apply the channel context of the 2nd link to the 2nd PHY. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-5-pkshih@realtek.com
2024-10-29wifi: rtw89: chan: manage active interfacesZong-Zhe Yang
To set channel well for combination of MCC (multi-channel concurrency) and impending MLO support, we need a method to manage relation between active interfaces and channel contexts. If an interface owns at least one active link, we call it an active interface. We add a list to manage active ones. Basically, the list follows the active order except for the below case. To be compatible with legacy behavior, the first interface that owns the first channel context will put at the first entry in the list when recalculating. Besides, MCC can also select and fill roles based on the above active list. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-4-pkshih@realtek.com
2024-10-29wifi: rtw89: Add encryption support for MLO connectionsPo-Hao Huang
In order to make encryption/decryption work properly with MLO connections, MLD address needs to be filled in so circuits can operate with the correct information. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-3-pkshih@realtek.com
2024-10-29wifi: rtw89: Add header conversion for MLO connectionsPo-Hao Huang
For MLO connections, this setting replaces 802.11 header addresses to according link addresses based on each packet's destination. The fields most likely to be replaced would be both A1 and A2. For legacy connections, it's the same with or without the conversion. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-2-pkshih@realtek.com
2024-10-28net/mlx5: unique names for per device cachesSebastian Ott
Add the device name to the per device kmem_cache names to ensure their uniqueness. This fixes warnings like this: "kmem_cache of name 'mlx5_fs_fgs' already exists". Signed-off-by: Sebastian Ott <sebott@redhat.com> Reviewed-by: Breno Leitao <leitao@debian.org> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241023134146.28448-1-sebott@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-13 09:50:49 +0000