summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-09-18wifi: rtw89: phy: initialize AFE by firmware element tablePing-Ke Shih
A power-on sequence table is introduced to initialize AFE (Analogue Front End) connecting to RF components. Build the sequence in firmware file, and use a parser to execute the sequences including write/poll/delay actions. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065314.38846-1-pkshih@realtek.com
2025-09-18wifi: rtw89: obtain RX path from ppdu status IE00Chih-Kang Chang
The header v2 of ppdu status is optional, If it is not enabled, the RX path must be obtained from IE00 or IE01. Append the IE00 part. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-5-pkshih@realtek.com
2025-09-18wifi: rtw89: disable RTW89_PHYSTS_IE09_FTR_0 for ppdu statusChih-Kang Chang
The IE length of RTW89_PHYSTS_IE09_FTR_0 is dynamic, need to calculate more to get it. This IE is not necessary now, disable it to avoid get wrong IE length to let the parse function check failed. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-4-pkshih@realtek.com
2025-09-18wifi: rtw89: use ieee80211_tx_info::driver_data to store driver TX infoPing-Ke Shih
It makes more sense to use ieee80211_tx_info::driver_data instead of ieee80211_tx_info::status.status_driver_data which is used to share TX status reporting to mac80211, because actually driver calls ieee80211_tx_info_clear_status() to clear the content including status_driver_data in rtw89_pci_tx_status() before filling the status. Review and point out the scope (by comments) driver can safely use ieee80211_tx_info::driver_data between rtw89_hci_tx_write() and calling ieee80211_tx_info_clear_status(). Add BUILD_BUG_ON() to assert that driver struct size is smaller than the size defined by mac80211. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-3-pkshih@realtek.com
2025-09-18wifi: rtw89: chan: allow callers to check if a link has no managed chanctxZong-Zhe Yang
Originally, to directly align with the chanctx design, getter of managed chanctx returned a default channel when a link doesn't own a chanctx yet. Then, callers could simply use the return without trivial NULL checking. But in MLD HW settings of next chip, there will be a special case that a caller needs to check if a link has owned chanctx or not to determine CCK hardware circuit working on HW-x. So, add a func *_or_null for this first. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-2-pkshih@realtek.com
2025-09-17Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-09-16 (ice, i40e, ixgbe, igc) For ice: Jake resolves leaking pages with multi-buffer frames when a 0-sized descriptor is encountered. For i40e: Maciej removes a redundant, and incorrect, memory barrier. For ixgbe: Jedrzej adjusts lifespan of ACI lock to ensure uses are while it is valid. For igc: Kohei Enju does not fail probe on LED setup failure which resolves a kernel panic in the cleanup path, if we were to fail. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: igc: don't fail igc_probe() on LED setup error ixgbe: destroy aci.lock later within ixgbe_remove path ixgbe: initialize aci.lock before it's used i40e: remove redundant memory barrier when cleaning Tx descs ice: fix Rx page leak on multi-buffer frames ==================== Link: https://patch.msgid.link/20250916212801.2818440-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17Merge tag 'wireless-2025-09-17' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Just two fixes: - fix crash in rfkill due to uninitialized type_name - fix aggregation in iwlwifi 7000/8000 devices * tag 'wireless-2025-09-17' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer wifi: iwlwifi: pcie: fix byte count table for some devices ==================== Link: https://patch.msgid.link/20250917105159.161583-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17octeon_ep: fix VF MAC address lifecycle handlingSathesh B Edara
Currently, VF MAC address info is not updated when the MAC address is configured from VF, and it is not cleared when the VF is removed. This leads to stale or missing MAC information in the PF, which may cause incorrect state tracking or inconsistencies when VFs are hot-plugged or reassigned. Fix this by: - storing the VF MAC address in the PF when it is set from VF - clearing the stored VF MAC address when the VF is removed This ensures that the PF always has correct VF MAC state. Fixes: cde29af9e68e ("octeon_ep: add PF-VF mailbox communication") Signed-off-by: Sathesh B Edara <sedara@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250916133207.21737-1-sedara@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: phy: remove mdio_board_info support from phylibHeiner Kallweit
After having removed mdio_board_info usage from dsa_loop, there's no user left. So let's drop support for it from phylib. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/01542a2e-05f5-4f13-acef-72632b33b5be@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: dsa_loop: remove usage of mdio_board_infoHeiner Kallweit
dsa_loop is the last remaining user of mdio_board_info. Let's remove using mdio_board_info, so that support for it can be dropped from phylib. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/da9563a4-8e14-41cf-bfea-cf5f1b58a4b7@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17Revert "net: ethernet: stmmac: dwmac-rk: Make the clk_phy could be used for ↵Chaoyi Chen
external phy" This reverts commit da114122b83149d1f1db0586b1d67947b651aa20. As discussed, the PHY clock should be managed by PHY driver instead of other driver like dwmac-rk. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/a30a8c97-6b96-45ba-bad7-8a40401babc2@samsung.com Fixes: da114122b831 ("net: ethernet: stmmac: dwmac-rk: Make the clk_phy could be used for external phy") Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Link: https://patch.msgid.link/0A3F1D1604FEE424+20250916012628.1819-1-kernel@airkyi.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17bonding: don't set oif to bond dev when getting NS target destinationHangbin Liu
Unlike IPv4, IPv6 routing strictly requires the source address to be valid on the outgoing interface. If the NS target is set to a remote VLAN interface, and the source address is also configured on a VLAN over a bond interface, setting the oif to the bond device will fail to retrieve the correct destination route. Fix this by not setting the oif to the bond device when retrieving the NS target destination. This allows the correct destination device (the VLAN interface) to be determined, so that bond_verify_device_path can return the proper VLAN tags for sending NS messages. Reported-by: David Wilder <wilder@us.ibm.com> Closes: https://lore.kernel.org/netdev/aGOKggdfjv0cApTO@fedora/ Suggested-by: Jay Vosburgh <jv@jvosburgh.net> Tested-by: David Wilder <wilder@us.ibm.com> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20250916080127.430626-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: cadence: macb: Add support for Raspberry Pi RP1 ethernet controllerDave Stevenson
The RP1 chip has the Cadence GEM block, but wants the tx_clock to always run at 125MHz, in the same way as sama7g5. Add the relevant configuration. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://patch.msgid.link/20250916081059.3992108-1-svarbanov@suse.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: pcs: Kconfig: Fix unmet dependency warningLad Prabhakar
Fix the Kconfig dependencies for PCS_RZN1_MIIC to avoid the unmet direct dependency warning when enabling DWMAC_RENESAS_GBETH. The PCS driver is used on multiple Renesas SoCs including RZ/N1, RZ/N2H and RZ/T2H, but the existing condition only allowed ARCH_RZN1, ARCH_R9A09G077, or ARCH_R9A09G087. This conflicted with the GBETH/GMAC driver which selects PCS_RZN1_MIIC under ARCH_RENESAS. Update the dependency to ARCH_RENESAS || COMPILE_TEST so that the PCS driver is available on all Renesas platforms. Fixes: 08f89e42121d ("net: pcs: rzn1-miic: Add RZ/T2H MIIC support") Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/all/aMlgg_QpJOEDGcEA@monster/ Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250916162335.3339558-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17Merge tag 'iwlwifi-fixes-2025-09-15' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi fix ==================== The fix is for byte count tables in 7000/8000 family devices. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-17net/mlx5e: Prevent WQE metadata conflicts between timestamping and offloadsCarolina Jubran
Update the WQE metadata assignment to avoid overriding existing metadata when setting the sysport timestamp ID. Since timestamp IDs are limited to 256 values, they use only the lower 8 bits of the metadata field. To avoid conflicts, move IPsec and MACsec metadata ID to bits 8 and 9, and shift the MACsec fs_id accordingly. This ensures safe coexistence of timestamping and offload features that use the same metadata field. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757574619-604874-4-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-17net/mlx5: Refactor MACsec WQE metadata shiftsCarolina Jubran
Introduce MLX5_ETH_WQE_FT_META_SHIFT as a shared base offset for features that use the lower 8 bits of the WQE flow_table_metadata field, currently used for timestamping, IPsec, and MACsec. Define MLX5_ETH_WQE_FT_META_MACSEC_FS_ID_MASK so that fs_id occupies bits 2–5, making it clear that fs_id occupies bits in the metadata. Set MLX5_ETH_WQE_FT_META_MACSEC_MASK as the OR of the MACsec flag and MLX5_ETH_WQE_FT_META_MACSEC_FS_ID_MASK, corresponding to the original 0x3E mask. Update the fs_id macro to right-shift the MACsec flag by MLX5_ETH_WQE_FT_META_SHIFT and update the RoCE modify-header action to use it. Introduce the helper macro MLX5_MACSEC_TX_METADATA(fs_id) to compose the full shifted MACsec metadata value. These changes make it explicit exactly which metadata bits carry MACsec information, simplifying future feature exclusions when multiple features share the WQE flowtable metadata. In addition, drop the incorrect “RX flow steering” comment, since this applies to TX flow steering. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757574619-604874-3-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-09-16net/mlx5: Lag, add net namespace supportShay Drory
Update the LAG implementation to support net namespace isolation. Recent devcom changes added namespace-aware client matching. Align LAG with this model so that hardware LAG forms only between mlx5 interfaces that share the same network namespace. This avoids cross-namespace interference and matches user expectations when devices are placed in different netns. Make LAG netns-aware by storing the device’s namespace in mlx5_lag and registering the devcom client with that namespace. As a result, only peers in the same netns are eligible to form a LAG. Adjust reload handling so LAG teardown/re-evaluation happens in the correct namespace context. Remove the blanket restriction that prevented devlink reload when LAG was active. Remove the reload restriction here allowing devlink reload in LAG mode is part of delivering complete netns aware LAG support: With per-netns devcom registration, reload no longer risks cross-namespace coupling. The devcom client is torn down and re-registered in the device’s current netns, and LAG is re-evaluated within that scope. The change is trivial and self-contained, and keeping it in this patch avoids splitting a feature that is functionally one unit. Only devices in same netns can form hardware LAG. devlink reload no longer fails just because LAG is active. LAG is torn down/re-created as needed within the correct namespace. No change for setups that don’t use namespaces. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757940070-618661-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net/mlx5: Add net namespace support to devcomShay Drory
Extend the devcom framework to support namespace-aware components. The existing devcom matching logic was based solely on numeric keys, limiting its use to the global (init_net) scope or requiring clients to ignore namespaces altogether, both of which are incorrect in multi-namespace environments. This patch introduces namespace support by allowing devcom clients to provide a namespace match attribute. The devcom pairing mechanism is updated to compare the namespace, enabling proper isolation and interaction of components across different net namespaces. With this change, components that require namespace aware pairing, such as SD groups or LAG, can now work correctly in multi-namespace scenarios. In particular, this opens the way to support hardware LAG within a net namespace. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757940070-618661-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net/mlx5: Lag, move devcom registration to LAG layerShay Drory
Move the devcom registration for the HCA_PORTS component from the core initialization path into the LAG logic. This better reflects the logical ownership of this component and ensures proper alignment with the LAG lifecycle. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757940070-618661-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net/mlx5: Refactor devcom to use match attributesShay Drory
Refactor the devcom interface to use a match attribute structure instead of passing raw keys. This change lays the groundwork for extending devcom matching logic with additional fields like net namespace, improving its flexibility and robustness. No functional changes. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757940070-618661-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net/mlx5e: Add a miss level for ipsec crypto offloadLama Kayal
The cited commit adds a miss table for switchdev mode. But it uses the same level as policy table. Will hit the following error when running command: # ip xfrm state add src 192.168.1.22 dst 192.168.1.21 proto \ esp spi 1001 reqid 10001 aead 'rfc4106(gcm(aes))' \ 0x3a189a7f9374955d3817886c8587f1da3df387ff 128 \ mode tunnel offload dev enp8s0f0 dir in Error: mlx5_core: Device failed to offload this state. The dmesg error is: mlx5_core 0000:03:00.0: ipsec_miss_create:578:(pid 311797): fail to create IPsec miss_rule err=-22 Fix it by adding a new miss level to avoid the error. Fixes: 7d9e292ecd67 ("net/mlx5e: Move IPSec policy check after decryption") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Chris Mi <cmi@nvidia.com> Signed-off-by: Lama Kayal <lkayal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757939074-617281-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net/mlx5e: Harden uplink netdev access against device unbindJianbo Liu
The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: <TASK> mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use. Fixes: 7a9fb35e8c3a ("net/mlx5e: Do not reload ethernet ports when changing eswitch mode") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1757939074-617281-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net: dsa: mv88e6xxx: clean up PTP clock during setup failureRussell King (Oracle)
If an error occurs during mv88e6xxx_setup() and the PTP clock has been registered, the clock will not be unregistered as mv88e6xxx_ptp_free() will not be called. mv88e6xxx_hwtstamp_free() also is not called. As mv88e6xxx_ptp_free() can cope with being called without a successful call to mv88e6xxx_ptp_setup(), and mv88e6xxx_hwtstamp_free() is empty, add both these *_free() calls to the error cleanup paths in mv88e6xxx_setup(). Moreover, mv88e6xxx_teardown() should teardown setup done in mv88e6xxx_setup() - see dsa_switch_setup(). However, instead *_free() are called from mv88e6xxx_remove() function that is only called when a device is unbound, which omits cleanup should a failure occur later in dsa_switch_setup(). Move the *_free() calls from mv88e6xxx_remove() to mv88e6xxx_teardown(). Note that mv88e6xxx_ptp_setup() must be called holding the reg_lock, but mv88e6xxx_ptp_free() must never be. This is especially true after commit "ptp: rework ptp_clock_unregister() to disable events". This patch does not change this, but adds a comment to that effect. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/E1uy84w-00000005Spi-46iF@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16net: mvpp2: add support for hardware timestampsRussell King
Add support for hardware timestamps in (e.g.) the PHY by calling skb_tx_timestamp() as close as reasonably possible to the point that the hardware is instructed to send the queued packets. As this also introduces software timestamping support, report those capabilities via the .get_ts_info() method. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uy82E-00000005Sll-0SSy@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16libie: fix linking with libie_{adminq,fwlog} when CONFIG_LIBIE=nAlexander Lobakin
Initially, libie contained only 1 module and I assumed that new modules in its folder would depend on it. However, Michał did a good job and libie_{adminq,fwlog} are completely independent, but libie/ is still traversed by Kbuild only under CONFIG_LIBIE != n. This results in undefined references with certain kernel configs. Tell Kbuild to always descend to libie/ to be able to build each module regardless of whether the basic one is enabled. If none of CONFIG_LIBIE* is set, Kbuild will just create an empty built-in.a there with no side effects. Fixes: 641585bc978e ("ixgbe: fwlog support for e610") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/202509140606.j8z3rE73-lkp@intel.com Reported-by: Breno Leitao <leitao@debian.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/CA+G9fYvH8d6pJRbHpOCMZFjgDCff3zcL_AsXL-nf5eB2smS8SA@mail.gmail.com Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250916160118.2209412-1-aleksander.lobakin@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16igc: don't fail igc_probe() on LED setup errorKohei Enju
When igc_led_setup() fails, igc_probe() fails and triggers kernel panic in free_netdev() since unregister_netdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2] Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic. [1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:free_netdev+0x278/0x2b0 [...] Call Trace: <TASK> igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind Fixes: ea578703b03d ("igc: Add support for LEDs on i225/i226") Signed-off-by: Kohei Enju <enjuk@amazon.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-16ixgbe: destroy aci.lock later within ixgbe_remove pathJedrzej Jagielski
There's another issue with aci.lock and previous patch uncovers it. aci.lock is being destroyed during removing ixgbe while some of the ixgbe closing routines are still ongoing. These routines use Admin Command Interface which require taking aci.lock which has been already destroyed what leads to call trace. [ +0.000004] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ +0.000007] WARNING: CPU: 12 PID: 10277 at kernel/locking/mutex.c:155 mutex_lock+0x5f/0x70 [ +0.000002] Call Trace: [ +0.000003] <TASK> [ +0.000006] ixgbe_aci_send_cmd+0xc8/0x220 [ixgbe] [ +0.000049] ? try_to_wake_up+0x29d/0x5d0 [ +0.000009] ixgbe_disable_rx_e610+0xc4/0x110 [ixgbe] [ +0.000032] ixgbe_disable_rx+0x3d/0x200 [ixgbe] [ +0.000027] ixgbe_down+0x102/0x3b0 [ixgbe] [ +0.000031] ixgbe_close_suspend+0x28/0x90 [ixgbe] [ +0.000028] ixgbe_close+0xfb/0x100 [ixgbe] [ +0.000025] __dev_close_many+0xae/0x220 [ +0.000005] dev_close_many+0xc2/0x1a0 [ +0.000004] ? kernfs_should_drain_open_files+0x2a/0x40 [ +0.000005] unregister_netdevice_many_notify+0x204/0xb00 [ +0.000006] ? __kernfs_remove.part.0+0x109/0x210 [ +0.000006] ? kobj_kset_leave+0x4b/0x70 [ +0.000008] unregister_netdevice_queue+0xf6/0x130 [ +0.000006] unregister_netdev+0x1c/0x40 [ +0.000005] ixgbe_remove+0x216/0x290 [ixgbe] [ +0.000021] pci_device_remove+0x42/0xb0 [ +0.000007] device_release_driver_internal+0x19c/0x200 [ +0.000008] driver_detach+0x48/0x90 [ +0.000003] bus_remove_driver+0x6d/0xf0 [ +0.000006] pci_unregister_driver+0x2e/0xb0 [ +0.000005] ixgbe_exit_module+0x1c/0xc80 [ixgbe] Same as for the previous commit, the issue has been highlighted by the commit 337369f8ce9e ("locking/mutex: Add MUTEX_WARN_ON() into fast path"). Move destroying aci.lock to the end of ixgbe_remove(), as this simply fixes the issue. Fixes: 4600cdf9f5ac ("ixgbe: Enable link management in E610 device") Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-16ixgbe: initialize aci.lock before it's usedJedrzej Jagielski
Currently aci.lock is initialized too late. A bunch of ACI callbacks using the lock are called prior it's initialized. Commit 337369f8ce9e ("locking/mutex: Add MUTEX_WARN_ON() into fast path") highlights that issue what results in call trace. [ 4.092899] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 4.092910] WARNING: CPU: 0 PID: 578 at kernel/locking/mutex.c:154 mutex_lock+0x6d/0x80 [ 4.098757] Call Trace: [ 4.098847] <TASK> [ 4.098922] ixgbe_aci_send_cmd+0x8c/0x1e0 [ixgbe] [ 4.099108] ? hrtimer_try_to_cancel+0x18/0x110 [ 4.099277] ixgbe_aci_get_fw_ver+0x52/0xa0 [ixgbe] [ 4.099460] ixgbe_check_fw_error+0x1fc/0x2f0 [ixgbe] [ 4.099650] ? usleep_range_state+0x69/0xd0 [ 4.099811] ? usleep_range_state+0x8c/0xd0 [ 4.099964] ixgbe_probe+0x3b0/0x12d0 [ixgbe] [ 4.100132] local_pci_probe+0x43/0xa0 [ 4.100267] work_for_cpu_fn+0x13/0x20 [ 4.101647] </TASK> Move aci.lock mutex initialization to ixgbe_sw_init() before any ACI command is sent. Along with that move also related SWFW semaphore in order to reduce size of ixgbe_probe() and that way all locks are initialized in ixgbe_sw_init(). Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Fixes: 4600cdf9f5ac ("ixgbe: Enable link management in E610 device") Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-16i40e: remove redundant memory barrier when cleaning Tx descsMaciej Fijalkowski
i40e has a feature which writes to memory location last descriptor successfully sent. Memory barrier in i40e_clean_tx_irq() was used to avoid forward-reading descriptor fields in case DD bit was not set. Having mentioned feature in place implies that such situation will not happen as we know in advance how many descriptors HW has dealt with. Besides, this barrier placement was wrong. Idea is to have this protection *after* reading DD bit from HW descriptor, not before. Digging through git history showed me that indeed barrier was before DD bit check, anyways the commit introducing i40e_get_head() should have wiped it out altogether. Also, there was one commit doing s/read_barrier_depends/smp_rmb when get head feature was already in place, but it was only theoretical based on ixgbe experiences, which is different in these terms as that driver has to read DD bit from HW descriptor. Fixes: 1943d8ba9507 ("i40e/i40evf: enable hardware feature head write back") Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-16ice: fix Rx page leak on multi-buffer framesJacob Keller
The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver. It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet. For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss. The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame. Move the increment of the ntc local variable to ensure its updated *before* all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame. Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring. Cc: Christoph Petrausch <christoph.petrausch@deepl.com> Cc: Jesper Dangaard Brouer <hawk@kernel.org> Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com> Closes: https://lore.kernel.org/netdev/CAK8fFZ4hY6GUJNENz3wY9jaYLZXGfpr7dnZxzGMYoE44caRbgw@mail.gmail.com/ Fixes: 743bbd93cf29 ("ice: put Rx buffers after being done with current frame") Tested-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Tested-by: Priya Singh <priyax.singh@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-16can: Add Nuvoton NCT6694 CANFD supportMing Yu
This driver supports Socket CANFD functionality for NCT6694 MFD device based on USB interface. Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Ming Yu <a0282524688@gmail.com> Link: https://lore.kernel.org/r/20250912091952.1169369-5-a0282524688@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-16net: spacemit: Add K1 Ethernet MACVivian Wang
The Ethernet MACs found on SpacemiT K1 appears to be a custom design that only superficially resembles some other embedded MACs. SpacemiT refers to them as "EMAC", so let's just call the driver "k1_emac". Supports RGMII and RMII interfaces. Includes support for MAC hardware statistics counters. PTP support is not implemented. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Tested-by: Junhui Liu <junhui.liu@pigmoral.tech> Tested-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20250914-net-k1-emac-v12-2-65b31b398f44@iscas.ac.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16net: phy: nxp-c45-tja11xx: use bitmap_empty() where appropriateYury Norov (NVIDIA)
The driver opencodes bitmap_empty() in a couple of funcitons. Switch to the proper and more verbose API. Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Link: https://patch.msgid.link/20250913182837.206800-1-yury.norov@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Fix code style (Missing a blank line before return)Fan Gong
Fix code style of missing a blank line before return. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/e4b34db5ee423ca554ff60b49a9ecd7f84c32110.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Fix missing napi->dev in netif_queue_set_napiFan Gong
As netif_queue_set_napi checks napi->dev, if it doesn't have it and it will warn_on and return. So we should use netif_napi_add before netif_queue_set_napi because netif_napi_add has "napi->dev = dev". Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/a17a5a087350eaf2e081dcd879779ca2c69b0908.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Add port managementFan Gong
Add port management of enable/disable/query/flush function. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/122cbde6dec03e091340bda32c8b0d7fac3a2fb4.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Add Rss functionFan Gong
Initialize rss functions. Configure rss hash data and HW resources. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/a69336e9b174950be5fe2c14f3450790f18eb293.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Tx & Rx configurationFan Gong
Configure Tx & Rx queue common attributes. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/22e71492cd7c819fca45200fcf4030c32f4f924d.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Queue pair context initializationFan Gong
Initialize queue pair context of hardware interaction. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/92b9c23f21cd37fb30066c7f075ec196e11f1fb2.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Queue pair resource initializationFan Gong
Add Tx & Rx queue resources and functions for packet transmission and reception. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/8d72eefd38d1c3b106eeb830d9e149df247b2906.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Queue pair endianness improvementsFan Gong
Explicitly use little-endian & big-endian structs to support big endian hosts. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/9b995a10f1e209a878bf98e4e1cdfb926f386695.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Nic_io initializationFan Gong
Add nic_io initialization to enable NIC service, configure the function table, initialize hwdev dev_id and negotiate activation of NIC features. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/fab9c4235c0fc0f65c9ac1add20dba5ac2160328.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: Command Queue flush interfacesFan Gong
Add the data structures and functions for command queue flushing. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/2cfd5dfbccb5265e22bdb5a2b279122a57795bb1.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: HW capability initializationFan Gong
Use mailbox to get device capability for initializing driver capability. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/8f4cbd99306a14cee1b7621714c269a02a5082dc.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: HW common function initializationFan Gong
Add initialization for data structures and functions(cmdq ceq mbox ceq) that interact with hardware. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/717fc839f415996d6f2540f9208fb038c367c050.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: HW management interfacesFan Gong
Initialize hardware management config of irq, aeq and ceq. These will send hardware messages to driver. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/91c2ec3178bd1f28b4f9c509fd49b86a289ff79e.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-16hinic3: HW initializationFan Gong
Add the hardware resource data structures, functions for HW initialization, configuration and releasement. Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/e3381375e3d4a89e11d4816a0a20a1db4df93b66.1757653621.git.zhuyikai1@h-partners.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-15net: natsemi: fix `rx_dropped` double accounting on `netif_rx()` failureYeounsu Moon
`netif_rx()` already increments `rx_dropped` core stat when it fails. The driver was also updating `ndev->stats.rx_dropped` in the same path. Since both are reported together via `ip -s -s` command, this resulted in drops being counted twice in user-visible stats. Keep the driver update on `if (unlikely(!skb))`, but skip it after `netif_rx()` errors. Fixes: caf586e5f23c ("net: add a core netdev->rx_dropped counter") Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250913060135.35282-3-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-15net: ravb: Fix -Wmaybe-uninitialized warningNiklas Söderlund
Fix a -Wmaybe-uninitialized warning by initializing the variable to NULL. The warning is bogus and should not happen, but fixing it allows running the check on the driver to catch potential future problems. $ make CFLAGS_ravb_main.o=-Wmaybe-uninitialized In function 'ravb_rx_csum_gbeth', inlined from 'ravb_rx_gbeth' at .../linux/drivers/net/ethernet/renesas/ravb_main.c:923:6: .../linux/drivers/net/ethernet/renesas/ravb_main.c:765:25: error: 'skb' may be used uninitialized [-Werror=maybe-uninitialized] 765 | if (unlikely(skb->len < csum_len)) | ~~~^~~~~ .../linux/include/linux/compiler.h:77:45: note: in definition of macro 'unlikely' 77 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ .../linux/drivers/net/ethernet/renesas/ravb_main.c: In function 'ravb_rx_gbeth': .../linux/drivers/net/ethernet/renesas/ravb_main.c:806:25: note: 'skb' was declared here 806 | struct sk_buff *skb; | ^~~ cc1: all warnings being treated as errors Warning was found when cross compiling using aarch64-linux-gnu-gcc (GCC) 15.1.0. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20250913133229.2087822-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-10 16:00:07 +0000