summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-03-05eth: fbnic: Add protection against pause stormMohsin Bashir
Add protection against TX pause storms. A pause storm occurs when a device fails to send received packets up to the stack. When a pause storm is detected (pause state persists beyond the configured timeout), the device stops sending the pause frames and begins dropping packets instead of back-pressuring. The timeout is configurable via ethtool tunable (pfc-prevention-tout) with a maximum value of 10485ms, and the default value of 500ms. Once the device transitions to the storm-detected state, the service task periodically attempts recovery, returning the device to normal operation to handle any subsequent pause storm episodes. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20260302230149.1580195-4-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05gve: Enable hw-gro by default if device supportedAnkit Garg
Change the driver's default behavior to enable hw-gro whenever supported for device. Performance observations: - We observed ~10% improvement in RX single stream throughput across various MTU sizes. - No change in TCP_RR/TCP_CRR latencies Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20260303195549.2679070-5-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05gve: pull network headers into skb linear partAnkit Garg
Currently, in DQO mode with hw-gro enabled, entire received packet is placed into skb fragments when header-split is disabled. This leaves the skb linear part empty, forcing the networking stack to do multiple small memory copies to access eth, IP and TCP headers. This patch adds a single memcpy to put all headers into linear portion before packet reaches the SW GRO stack; thus eliminating multiple smaller memcpy calls. Additionally, the criteria for calling napi_gro_frags() was updated. Since skb->head is now populated, we instead check if the SKB is the cached NAPI scratchpad to ensure we continue using the zero-allocation path. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20260303195549.2679070-4-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05gve: fix SW coalescing when hw-GRO is usedAnkit Garg
Leaving gso_segs unpopulated on hardware GRO packet prevents further coalescing by software stack because the kernel's GRO logic marks the SKB for flush because the expected length of all segments doesn't match actual payload length. Setting gso_segs correctly results in significantly more segments being coalesced as measured by the result of dev_gro_receive(). gso_segs are derived from payload length. When header-split is enabled, payload is in the non-linear portion of skb. And when header-split is disabled, we have to parse the headers to determine payload length. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20260303195549.2679070-3-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05gve: Advertise NETIF_F_GRO_HW instead of NETIF_F_LROAnkit Garg
The device behind DQO format has always coalesced packets per stricter hardware GRO spec even though it was being advertised as LRO. Update advertised capability to match device behavior. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20260303195549.2679070-2-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error in ↵Lorenzo Bianconi
mtk_xdp_setup() Reset eBPF program pointer to old_prog and do not decrease its ref-count if mtk_open routine in mtk_xdp_setup() fails. Fixes: 7c26c20da5d42 ("net: ethernet: mtk_eth_soc: add basic XDP support") Suggested-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260303-mtk-xdp-prog-ptr-fix-v2-1-97b6dbbe240f@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05r8169: add support for RTL8125cpJaven Xu
This patch adds support for chip RTL8125cp. Its XID is 0x708. We apply different configuration and firmware for RTL8125cp. Signed-off-by: Javen Xu <javen_xu@realsil.com.cn> Link: https://patch.msgid.link/20260303094611.450-1-javen_xu@realsil.com.cn [pabeni@redhat.com: changelog cleanup] Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05ppp: don't store tx skb in the fastpathQingfang Deng
Currently, ppp->xmit_pending is used in ppp_send_frame() to pass a skb to ppp_push(), and holds the skb when a PPP channel cannot immediately transmit it. This state is redundant because the transmit queue (ppp->file.xq) can already handle the backlog. Furthermore, during normal operation, an skb is queued in file.xq only to be immediately dequeued, causing unnecessary overhead. Refactor the transmit path to avoid stashing the skb when possible: - Remove ppp->xmit_pending. - Rename ppp_send_frame() to ppp_prepare_tx_skb(), and don't call ppp_push() in it. It returns 1 if the skb is consumed (dropped/handled) or 0 if it can be passed to ppp_push(). - Update ppp_push() to accept the skb. It returns 1 if the skb is consumed, or 0 if the channel is busy. - Optimize __ppp_xmit_process(): - Fastpath: If the queue is empty, attempt to send the skb directly via ppp_push(). If busy, queue it. - Slowpath: If the queue is not empty, process the backlog in file.xq. Split dequeuing loop into a separate function ppp_xmit_flush() so ppp_channel_push() uses that directly instead of passing a NULL skb to __ppp_xmit_process(). This simplifies the states and reduces locking in the fastpath. Signed-off-by: Qingfang Deng <dqfext@gmail.com> Link: https://patch.msgid.link/20260303093219.234403-1-dqfext@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05net: mana: Add MAC address to vPort logs and clarify error messagesErni Sri Satya Vennela
Add MAC address to vPort configuration success message and update error message to be more specific about HWC message errors in mana_send_request. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260302174204.234837-1-ernis@linux.microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05Add support for TLP emulationLeon Romanovsky
This series adds support for Transaction Layer Packet (TLP) emulation response gateway regions, enabling userspace device emulation software to write TLP responses directly to lower layers without kernel driver involvement. Currently, the mlx5 driver exposes VirtIO emulation access regions via the MLX5_IB_METHOD_VAR_OBJ_ALLOC ioctl. This series extends that ioctl to also support allocating TLP response gateway channels for PCI device emulation use cases. Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-03-05net/mlx5: Expose TLP emulation capabilitiesMaher Sanalla
Expose and query TLP device emulation caps on driver load. Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-03-05amd-xgbe: add support for P100a platformRaju Rangoju
Add hardware support for the AMD P100a platform featuring the ethernet controller PCI device ID 0x1122. Platform-specific changes include: 1. PCI device ID and register configuration: - Add XGBE_P100a_PCI_DEVICE_ID (0x1122) for recognition - Configure platform-specific XPCS window registers - Disable CDR workaround and RRC for this platform 2. XPCS window offset calculation fix: The P100a platform uses a different memory mapping scheme for XPCS register access. The offset calculation differs between platforms: - Older platforms (YC): offset = base + (addr & mask) The address is masked first, then added to the window base. - P100a: offset = (base + addr) & mask The full address is added to base first, then masked. This is critical because using the wrong calculation causes register reads/writes to access incorrect addresses, leading to incorrect behaviour. 3. 2.5G speed mode handling: P100a uses XGMII mode (ss=0x06) for 2.5G instead of GMII mode (ss=0x02) used by older platforms. The MAC version check determines which mode to use. 4. Port speed bits extended: Extend XP_PROP_0_PORT_SPEEDS from 5 bits to 6 bits to support the additional 5G speed capability. 5. Rx adaptation disabled: Rx adaptation is disabled for P100a (MAC version 0x33) as this feature requires further development for this platform. 6. Rate change command for 2.5G: Use XGBE_MB_SUBCMD_2_5G_KX subcommand for 2.5G mode on P100a instead of XGBE_MB_SUBCMD_NONE used on older platforms. Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20260302044634.1388661-2-Raju.Rangoju@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05amd-xgbe: define macros for MAC versions and speed select valuesRaju Rangoju
Define symbolic constants for MAC hardware version numbers and speed select register values to improve code readability and maintainability. This replaces magic numbers like 0x30, 0x33, 0x07, 0x06, etc. with descriptive macro names that indicate their purpose: MAC versions: - XGBE_MAC_VER_30: Baseline version supporting Rx adaptation - XGBE_MAC_VER_33: P100a platform version Speed select values for MAC_TCR_SS register: - XGBE_MAC_SS_10G: 10Gbps XGMII mode - XGBE_MAC_SS_2_5G_GMII: 2.5Gbps GMII mode (older platforms) - XGBE_MAC_SS_2_5G_XGMII: 2.5Gbps XGMII mode (P100a) - XGBE_MAC_SS_1G: 1Gbps mode - XGBE_MAC_SS_100M: 100Mbps mode - XGBE_MAC_SS_10M: 10Mbps mode No functional changes. Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20260302044634.1388661-1-Raju.Rangoju@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-04net: stmmac: Defer VLAN HW configuration when interface is downOvidiu Panait
VLAN register accesses on the MAC side require the PHY RX clock to be active. When the network interface is down, the PHY is suspended and the RX clock is unavailable, causing VLAN operations to fail with timeouts. The VLAN core automatically removes VID 0 after the interface goes down and re-adds it when it comes back up, so these timeouts happen during normal interface down/up: # ip link set end1 down renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter renesas-gbeth 15c40000.ethernet end1: failed to kill vid 0081/0 Adding VLANs while the interface is down also fails: # ip link add link end1 name end1.10 type vlan id 10 renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter RTNETLINK answers: Device or resource busy To fix this, check if the interface is up before accessing VLAN registers. The software state is always kept up to date regardless of interface state. When the interface is brought up, stmmac_vlan_restore() is called to write the VLAN state to hardware. Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-5-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Fix VLAN HW state restoreOvidiu Panait
When the network interface is opened or resumed, a DMA reset is performed, which resets all hardware state, including VLAN state. Currently, only the resume path is restoring the VLAN state via stmmac_restore_hw_vlan_rx_fltr(), but that is incomplete: the VLAN hash table and the VLAN_TAG control bits are not restored. Therefore, add stmmac_vlan_restore(), which restores the full VLAN state by updating both the HW filter entries and the hash table, and call it from both the open and resume paths. The VLAN restore is moved outside of phylink_rx_clk_stop_block/unblock in the resume path because receive clock stop is already disabled when stmmac supports VLAN. Also, remove the hash readback code in vlan_restore_hw_rx_fltr() that attempts to restore VTHM by reading VLAN_HASH_TABLE, as it always reads zero after DMA reset, making it dead code. Fixes: 3cd1cfcba26e ("net: stmmac: Implement VLAN Hash Filtering in XGMAC") Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-4-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Improve double VLAN handlingOvidiu Panait
The double VLAN bits (EDVLP, ESVL, DOVLTC) are handled inconsistently between the two vlan_update_hash() implementations: - dwxgmac2_update_vlan_hash() explicitly clears the double VLAN bits when is_double is false, meaning that adding a 802.1Q VLAN will disable double VLAN mode: $ ip link add link eth0 name eth0.200 type vlan id 200 protocol 802.1ad $ ip link add link eth0 name eth0.100 type vlan id 100 # Double VLAN bits no longer set - vlan_update_hash() sets these bits and only clears them when the last VLAN has been removed, so double VLAN mode remains enabled even after all 802.1AD VLANs are removed. Address both issues by tracking the number of active 802.1AD VLANs in priv->num_double_vlans. Pass this count to stmmac_vlan_update() so both implementations correctly set the double VLAN bits when any 802.1AD VLAN is active, and clear them only when none remain. Also update vlan_update_hash() to explicitly clear the double VLAN bits when is_double is false, matching the dwxgmac2 behavior. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-3-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Fix error handling in VLAN add and delete pathsOvidiu Panait
stmmac_vlan_rx_add_vid() updates active_vlans and the VLAN hash register before writing the HW filter entry. If the filter write fails, it leaves a stale VID in active_vlans and the hash register. stmmac_vlan_rx_kill_vid() has the reverse problem: it clears active_vlans before removing the HW filter. On failure, the VID is gone from active_vlans but still present in the HW filter table. To fix this, reorder the operations to update the hash table first, then attempt the HW filter operation. If the HW filter fails, roll back both the active_vlans bitmap and the hash table by calling stmmac_vlan_update() again. Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-2-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-03-02 (ice, i40e, ixgbe) For ice: Simon Horman adds const modifier to read only member of a struct. For i40e: Yury Norov removes an unneeded check of bitmap_weight(). Andy Shevchenko adds a missing include. For ixgbe: Aleksandr changes declaration of a bitmap to utilize DECLARE_BITMAP() macro. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ixgbe: refactor: use DECLARE_BITMAP for ring state field i40e: Add missing wordpart.h header i40e: drop useless bitmap_weight() call in i40e_set_rxfh_fields() ice: Make name member of struct ice_cgu_pin_desc const ==================== Link: https://patch.msgid.link/20260304000800.3536872-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge 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 2026-03-03 (ice, libie, iavf, igb, igc) Larysa removes VF restriction for LLDP filters on ice to allow for LLDP traffic to reach the correct destination. Jakub adds retry mechanism for AdminQ Read/Write SFF EEPROM call to follow hardware specification on ice. Zilin Guan adds cleanup path to free XDP rings on failure in ice_set_ringparam(). Michal bypasses firmware logging unroll in libie when it isn't supported. Kohei Enju fixes iavf to take into account hardware MTU support when setting max MTU values. Vivek Behera fixes issues on igb and igc using incorrect IRQs when Tx/Rx queues do not share the same IRQ. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: igc: Fix trigger of incorrect irq in igc_xsk_wakeup function igb: Fix trigger of incorrect irq in igb_xsk_wakeup iavf: fix netdev->max_mtu to respect actual hardware limit libie: don't unroll if fwlog isn't supported ice: Fix memory leak in ice_set_ringparam() ice: fix retry for AQ command 0x06EE ice: reintroduce retry mechanism for indirect AQ ice: fix adding AQ LLDP filter for VF ==================== Link: https://patch.msgid.link/20260303231155.2895065-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge tag 'linux-can-fixes-for-7.0-20260302' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2026-03-02 The first 2 patches are by Oliver Hartkopp. The first fixes the locking for CAN Broadcast Manager op runtime updates, the second fixes the packet statisctics for the CAN dummy driver. Alban Bedel's patch fixes a potential problem in the error path of the mcp251x's ndo_open callback. A patch by Ziyi Guo add USB endpoint type validation to the esd_usb driver. The next 6 patches are by Greg Kroah-Hartman and fix URB data parsing for the ems_usb and ucan driver, fix URB anchoring in the etas_es58x, and in the f81604 driver fix URB data parsing, add URB error handling and fix URB anchoring. A patch by me targets the gs_usb driver and fixes interoperability with the CANable-2.5 firmware by always configuring the bit rate before starting the device. The last patch is by Frank Li and fixes a CHECK_DTBS warning for the nxp,sja1000 dt-binding. * tag 'linux-can-fixes-for-7.0-20260302' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: dt-bindings: net: can: nxp,sja1000: add reference to mc-peripheral-props.yaml can: gs_usb: gs_can_open(): always configure bitrates before starting device can: usb: f81604: correctly anchor the urb in the read bulk callback can: usb: f81604: handle bulk write errors properly can: usb: f81604: handle short interrupt urb messages properly can: usb: etas_es58x: correctly anchor the urb in the read bulk callback can: ucan: Fix infinite loop from zero-length messages can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message can: esd_usb: add endpoint type validation can: mcp251x: fix deadlock in error path of mcp251x_open can: dummy_can: dummy_can_init(): fix packet statistics can: bcm: fix locking for bcm_op runtime updates ==================== Link: https://patch.msgid.link/20260302152755.1700177-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: dsa: mxl862xx: rename MDIO op argumentsDaniel Golle
The use of the 'port' argument name for functions implementing the MDIO bus operations is misleading as the port address isn't equal to the PHY address. Rename the MDIO operation argument name to match the prototypes of mdiobus_write, mdiobus_read, mdiobus_c45_read and mdiobus_c45_write. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/e1f4cb3bcffc7df9af0f2c9b673b14c7e1201c9a.1772507674.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge tag 'wireless-next-2026-03-04' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Notable features this time: - cfg80211/mac80211 - finished assoc frame encryption/EPPKE/802.1X-over-auth (also hwsim) - radar detection improvements - 6 GHz incumbent signal detection APIs - multi-link support for FILS, probe response templates and client probling - ath12k: - monitor mode support on IPQ5332 - basic hwmon temperature reporting * tag 'wireless-next-2026-03-04' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (38 commits) wifi: UHR: define DPS/DBE/P-EDCA elements and fix size parsing wifi: mac80211_hwsim: change hwsim_class to a const struct wifi: mac80211: give the AP more time for EPPKE as well wifi: ath12k: Remove the unused argument from the Rx data path wifi: ath12k: Enable monitor mode support on IPQ5332 wifi: ath12k: Set up MLO after SSR wifi: ath11k: Silence remoteproc probe deferral prints wifi: cfg80211: support key installation on non-netdev wdevs wifi: cfg80211: make cluster id an array wifi: mac80211: update outdated comment wifi: mac80211: Advertise IEEE 802.1X authentication support wifi: mac80211: Add support for IEEE 802.1X authentication protocol in non-AP STA mode wifi: cfg80211: add support for IEEE 802.1X Authentication Protocol wifi: mac80211: Advertise EPPKE support based on driver capabilities wifi: mac80211_hwsim: Advertise support for (Re)Association frame encryption wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO wifi: rt2x00: use generic nvmem_cell_get wifi: mac80211: fetch unsolicited probe response template by link ID wifi: mac80211: fetch FILS discovery template by link ID wifi: nl80211: don't allow DFS channels for NAN ... ==================== Link: https://patch.msgid.link/20260304113707.175181-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge tag 'wireless-2026-03-04' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Some more fixes: - mt76 gets three almost identical new length checks - cw1200 & ti: locking fixes - mac80211 has a fix for the recent EML frame handling - rsi driver no longer oddly responds to config, which had triggered a warning in mac80211 - ath12k has two fixes for station statistics handling * tag 'wireless-2026-03-04' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mt76: Fix possible oob access in mt76_connac2_mac_write_txwi_80211() wifi: mt76: mt7925: Fix possible oob access in mt7925_mac_write_txwi_80211() wifi: mt76: mt7996: Fix possible oob access in mt7996_mac_write_txwi_80211() wifi: wlcore: Fix a locking bug wifi: cw1200: Fix locking in error paths wifi: mac80211: fix missing ieee80211_eml_params member initialization wifi: rsi: Don't default to -EOPNOTSUPP in rsi_mac80211_config wifi: ath12k: fix station lookup failure when disconnecting from AP wifi: ath12k: use correct pdev id when requesting firmware stats ==================== Link: https://patch.msgid.link/20260304112500.169639-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04xenbus: add xenbus_device parameter to xenbus_read_driver_state()Juergen Gross
In order to prepare checking the xenbus device status in xenbus_read_driver_state(), add the pointer to struct xenbus_device as a parameter. Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: "Martin K. Petersen" <martin.petersen@oracle.com> # SCSI Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/xen-pcifront.c Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20260218095205.453657-2-jgross@suse.com>
2026-03-04wifi: mac80211_hwsim: change hwsim_class to a const structJori Koolstra
The class_create() call has been deprecated in favor of class_register() as the driver core now allows for a struct class to be in read-only memory. Change hwsim_class to be a const struct class and drop the class_create() call. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260303165938.3773998-1-jkoolstra@xs4all.nl Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-04Merge tag 'ath-next-20260303' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v7.1 (PR #1) For ath12k: Add basic hwmon temperature reporting. Enable monitor mode on IPQ5332. Also a few small cleanups and bug fixes across ath drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-03-03net: macvlan: support multicast rx for bridge ports with shared source MACKibaek Yoo
Macvlan bridge mode currently does not handle the case where an external source shares its MAC address with a local macvlan interface. When such a frame arrives, macvlan_hash_lookup() matches the source MAC to the local macvlan, and macvlan_multicast_rx() assumes bridge ports already received the frame during local transmission. Since the frame actually originated externally, bridge ports never saw it. This situation arises with protocols like VRRP, where multiple hosts use the same virtual MAC address. Support this by passing NULL as the source device and including MACVLAN_MODE_BRIDGE in the mode mask for the else branch of macvlan_multicast_rx(). This ensures all VEPA and bridge mode macvlan interfaces receive incoming multicast regardless of source MAC matching. The trade-off is that looped-back locally-originated multicasts may be delivered to bridge ports a second time, but multicast consumers already handle duplicate frames. Signed-off-by: Kibaek Yoo <psykibaek@gmail.com> Link: https://patch.msgid.link/20260228071613.4360-1-psykibaek@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03amd-xgbe: fix sleep while atomic on suspend/resumeRaju Rangoju
The xgbe_powerdown() and xgbe_powerup() functions use spinlocks (spin_lock_irqsave) while calling functions that may sleep: - napi_disable() can sleep waiting for NAPI polling to complete - flush_workqueue() can sleep waiting for pending work items This causes a "BUG: scheduling while atomic" error during suspend/resume cycles on systems using the AMD XGBE Ethernet controller. The spinlock protection in these functions is unnecessary as these functions are called from suspend/resume paths which are already serialized by the PM core Fix this by removing the spinlock. Since only code that takes this lock is xgbe_powerdown() and xgbe_powerup(), remove it completely. Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver") Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20260302042124.1386445-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03netconsole: fix sysdata_release_enabled_show checking wrong flagBreno Leitao
sysdata_release_enabled_show() checks SYSDATA_TASKNAME instead of SYSDATA_RELEASE, causing the configfs release_enabled attribute to reflect the taskname feature state rather than the release feature state. This is a copy-paste error from the adjacent sysdata_taskname_enabled_show() function. The corresponding _store function already uses the correct SYSDATA_RELEASE flag. Fixes: 343f90227070 ("netconsole: implement configfs for release_enabled") Signed-off-by: Breno Leitao <leitao@debian.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260302-sysdata_release_fix-v1-1-e5090f677c7c@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03net: ipa: Grab IMEM slice base/size from DTSKonrad Dybcio
This is a detail that differ per chip, and not per IPA version (and there are cases of the same IPA versions being implemented across very very very different SoCs). This region isn't actually used by the driver, but we most definitely want to iommu-map it, so that IPA can poke at the data within. Reviewed-by: Alex Elder <elder@riscstar.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260302-topic-ipa_imem-v6-3-c0ebbf3eae9f@oss.qualcomm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03net: macb: use ethtool_sprintf to fill ethtool stats stringsSean Chang
The RISC-V toolchain triggers a stringop-truncation warning when using snprintf() with a fixed ETH_GSTRING_LEN (32 bytes) buffer. Convert the driver to use the modern ethtool_sprintf() API from linux/ethtool.h. This removes the need for manual snprintf() and memcpy() calls, handles the 32-byte padding automatically, and simplifies the logic by removing manual pointer arithmetic. Suggested-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sean Chang <seanwascoding@gmail.com> Link: https://patch.msgid.link/20260302142931.49108-1-seanwascoding@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-03igc: Fix trigger of incorrect irq in igc_xsk_wakeup functionVivek Behera
This patch addresses the issue where the igc_xsk_wakeup function was triggering an incorrect IRQ for tx-0 when the i226 is configured with only 2 combined queues or in an environment with 2 active CPU cores. This prevented XDP Zero-copy send functionality in such split IRQ configurations. The fix implements the correct logic for extracting q_vectors saved during rx and tx ring allocation and utilizes flags provided by the ndo_xsk_wakeup API to trigger the appropriate IRQ. Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy") Fixes: 15fd021bc427 ("igc: Add Tx hardware timestamp request for AF_XDP zero-copy packet") Signed-off-by: Vivek Behera <vivek.behera@siemens.com> Reviewed-by: Jacob Keller <jacob.keller@intel.com> Reviewed-by: Aleksandr loktinov <aleksandr.loktionov@intel.com> Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Reviewed-by: Song Yoong Siang <yoong.siang.song@intel.com> Tested-by: Avigail Dahan <avigailx.dahan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03igb: Fix trigger of incorrect irq in igb_xsk_wakeupVivek Behera
The current implementation in the igb_xsk_wakeup expects the Rx and Tx queues to share the same irq. This would lead to triggering of incorrect irq in split irq configuration. This patch addresses this issue which could impact environments with 2 active cpu cores or when the number of queues is reduced to 2 or less cat /proc/interrupts | grep eno2 167: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 0-edge eno2 168: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 1-edge eno2-rx-0 169: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 2-edge eno2-rx-1 170: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 3-edge eno2-tx-0 171: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 4-edge eno2-tx-1 Furthermore it uses the flags input argument to trigger either rx, tx or both rx and tx irqs as specified in the ndo_xsk_wakeup api documentation Fixes: 80f6ccf9f116 ("igb: Introduce XSK data structures and helpers") Signed-off-by: Vivek Behera <vivek.behera@siemens.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Saritha Sanigani <sarithax.sanigani@intel.com> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03iavf: fix netdev->max_mtu to respect actual hardware limitKohei Enju
iavf sets LIBIE_MAX_MTU as netdev->max_mtu, ignoring vf_res->max_mtu from PF [1]. This allows setting an MTU beyond the actual hardware limit, causing TX queue timeouts [2]. Set correct netdev->max_mtu using vf_res->max_mtu from the PF. Note that currently PF drivers such as ice/i40e set the frame size in vf_res->max_mtu, not MTU. Convert vf_res->max_mtu to MTU before setting netdev->max_mtu. [1] # ip -j -d link show $DEV | jq '.[0].max_mtu' 16356 [2] iavf 0000:00:05.0 enp0s5: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 5692 ms iavf 0000:00:05.0 enp0s5: NIC Link is Up Speed is 10 Gbps Full Duplex iavf 0000:00:05.0 enp0s5: NETDEV WATCHDOG: CPU: 6: transmit queue 3 timed out 5312 ms iavf 0000:00:05.0 enp0s5: NIC Link is Up Speed is 10 Gbps Full Duplex ... Fixes: 5fa4caff59f2 ("iavf: switch to Page Pool") Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03libie: don't unroll if fwlog isn't supportedMichal Swiatkowski
The libie_fwlog_deinit() function can be called during driver unload even when firmware logging was never properly initialized. This led to call trace: [ 148.576156] Oops: Oops: 0000 [#1] SMP NOPTI [ 148.576167] CPU: 80 UID: 0 PID: 12843 Comm: rmmod Kdump: loaded Not tainted 6.17.0-rc7next-queue-3oct-01915-g06d79d51cf51 #1 PREEMPT(full) [ 148.576177] Hardware name: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10 Plus, BIOS A42 07/18/2020 [ 148.576182] RIP: 0010:__dev_printk+0x16/0x70 [ 148.576196] Code: 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 55 41 54 49 89 d4 55 48 89 fd 53 48 85 f6 74 3c <4c> 8b 6e 50 48 89 f3 4d 85 ed 75 03 4c 8b 2e 48 89 df e8 f3 27 98 [ 148.576204] RSP: 0018:ffffd2fd7ea17a48 EFLAGS: 00010202 [ 148.576211] RAX: ffffd2fd7ea17aa0 RBX: ffff8eb288ae2000 RCX: 0000000000000000 [ 148.576217] RDX: ffffd2fd7ea17a70 RSI: 00000000000000c8 RDI: ffffffffb68d3d88 [ 148.576222] RBP: ffffffffb68d3d88 R08: 0000000000000000 R09: 0000000000000000 [ 148.576227] R10: 00000000000000c8 R11: ffff8eb2b1a49400 R12: ffffd2fd7ea17a70 [ 148.576231] R13: ffff8eb3141fb000 R14: ffffffffc1215b48 R15: ffffffffc1215bd8 [ 148.576236] FS: 00007f5666ba6740(0000) GS:ffff8eb2472b9000(0000) knlGS:0000000000000000 [ 148.576242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 148.576247] CR2: 0000000000000118 CR3: 000000011ad17000 CR4: 0000000000350ef0 [ 148.576252] Call Trace: [ 148.576258] <TASK> [ 148.576269] _dev_warn+0x7c/0x96 [ 148.576290] libie_fwlog_deinit+0x112/0x117 [libie_fwlog] [ 148.576303] ixgbe_remove+0x63/0x290 [ixgbe] [ 148.576342] pci_device_remove+0x42/0xb0 [ 148.576354] device_release_driver_internal+0x19c/0x200 [ 148.576365] driver_detach+0x48/0x90 [ 148.576372] bus_remove_driver+0x6d/0xf0 [ 148.576383] pci_unregister_driver+0x2e/0xb0 [ 148.576393] ixgbe_exit_module+0x1c/0xd50 [ixgbe] [ 148.576430] __do_sys_delete_module.isra.0+0x1bc/0x2e0 [ 148.576446] do_syscall_64+0x7f/0x980 It can be reproduced by trying to unload ixgbe driver in recovery mode. Fix that by checking if fwlog is supported before doing unroll. Fixes: 641585bc978e ("ixgbe: fwlog support for e610") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.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>
2026-03-03ice: Fix memory leak in ice_set_ringparam()Zilin Guan
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> 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>
2026-03-03ice: fix retry for AQ command 0x06EEJakub Staniszewski
Executing ethtool -m can fail reporting a netlink I/O error while firmware link management holds the i2c bus used to communicate with the module. According to Intel(R) Ethernet Controller E810 Datasheet Rev 2.8 [1] Section 3.3.10.4 Read/Write SFF EEPROM (0x06EE) request should to be retried upon receiving EBUSY from firmware. Commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") implemented it only for part of ice_get_module_eeprom(), leaving all other calls to ice_aq_sff_eeprom() vulnerable to returning early on getting EBUSY without retrying. Remove the retry loop from ice_get_module_eeprom() and add Admin Queue (AQ) command with opcode 0x06EE to the list of commands that should be retried on receiving EBUSY from firmware. Cc: stable@vger.kernel.org Fixes: e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") Signed-off-by: Jakub Staniszewski <jakub.staniszewski@linux.intel.com> Co-developed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html [1] Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03ice: reintroduce retry mechanism for indirect AQJakub Staniszewski
Add retry mechanism for indirect Admin Queue (AQ) commands. To do so we need to keep the command buffer. This technically reverts commit 43a630e37e25 ("ice: remove unused buffer copy code in ice_sq_send_cmd_retry()"), but combines it with a fix in the logic by using a kmemdup() call, making it more robust and less likely to break in the future due to programmer error. Cc: Michal Schmidt <mschmidt@redhat.com> Cc: stable@vger.kernel.org Fixes: 3056df93f7a8 ("ice: Re-send some AQ commands, as result of EBUSY AQ error") Signed-off-by: Jakub Staniszewski <jakub.staniszewski@linux.intel.com> Co-developed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03ice: fix adding AQ LLDP filter for VFLarysa Zaremba
The referenced commit came from a misunderstanding of the FW LLDP filter AQ (Admin Queue) command due to the error in the internal documentation. Contrary to the assumptions in the original commit, VFs can be added and deleted from this filter without any problems. Introduced dev_info message proved to be useful, so reverting the whole commit does not make sense. Without this fix, trusted VFs do not receive LLDP traffic, if there is an AQ LLDP filter on PF. When trusted VF attempts to add an LLDP multicast MAC address, the following message can be seen in dmesg on host: ice 0000:33:00.0: Failed to add Rx LLDP rule on VSI 20 error: -95 Revert checking VSI type when adding LLDP filter through AQ. Fixes: 4d5a1c4e6d49 ("ice: do not add LLDP-specific filter if not necessary") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03ixgbe: refactor: use DECLARE_BITMAP for ring state fieldAleksandr Loktionov
Convert the ring state field from 'unsigned long' to a proper bitmap using DECLARE_BITMAP macro, aligning with the implementation pattern already used in the i40e driver. This change: - Adds __IXGBE_RING_STATE_NBITS as the bitmap size sentinel to enum ixgbe_ring_state_t (consistent with i40e's __I40E_RING_STATE_NBITS) - Changes 'unsigned long state' to 'DECLARE_BITMAP(state, __IXGBE_RING_STATE_NBITS)' in struct ixgbe_ring - Removes the address-of operator (&) when passing ring->state to bit manipulation functions, as bitmap arrays naturally decay to pointers The change maintains functional equivalence while using the more appropriate kernel bitmap API, consistent with other Intel Ethernet drivers. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03i40e: Add missing wordpart.h headerAndy Shevchenko
When cleaning up another header I have met this build error: drivers/net/ethernet/intel/i40e/i40e_hmc.h:105:22: error: implicit declaration of function 'upper_32_bits' [-Wimplicit-function-declaration] 105 | val1 = (u32)(upper_32_bits(pa)); \ This is due to missing header, add it to fix the possible issue. Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03i40e: drop useless bitmap_weight() call in i40e_set_rxfh_fields()Yury Norov (NVIDIA)
bitmap_weight() is O(N) and useless here, because the following for_each_set_bit() returns immediately in case of empty flow_pctypes. Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.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>
2026-03-03ice: Make name member of struct ice_cgu_pin_desc constSimon Horman
The name member of struct ice_cgu_pin_desc never modified. Make it const. Found by inspection. Compile tested only. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03net: phy: improve mdiobus_stats_acctHeiner Kallweit
- Remove duplicated preempt disable. Disabling preemption has been added to functions like u64_stats_update_begin() in the meantime. - Simplify branch structure Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/2ceeb542-986a-404e-ad0f-62e0a938ce7c@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-03net: phy: inline helper mdio_bus_get_global_statHeiner Kallweit
mdio_bus_get_global_stat() has only one user. Inline it to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/7876625a-bd6f-42b4-8eb3-420f39d2f59a@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-03net: mdio: use macro __ATTRIBUTE_GROUPSHeiner Kallweit
Use macro __ATTRIBUTE_GROUPS() to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/260fb184-c662-415c-b288-e1423097f2b9@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-03net: mdio: constify attributes and attribute arraysHeiner Kallweit
Constify attributes and attribute arrays, using new member attrs_const of struct attribute_group. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/c20f17bb-3489-42b5-b8fe-457245ac6cb3@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-03net: phy: avoid extra casting in mdio_bus_get_statHeiner Kallweit
Using void * instead of char * allows to remove one cast. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/054bbf60-d8ac-45ce-8b80-9c396469b7f9@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-03net: phy: consider that mdio_bus_device_stat_field_show doesn't use member ↵Heiner Kallweit
address mdio_bus_device_stat_field_show() doesn't use the address member, so we don't have to initialize it. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/03a812a7-6871-4cc0-b5bf-ee80c6d6b5fd@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-03net: mdio: use macro __ATTR to simplify the codeHeiner Kallweit
Use macro __ATTR to simplify the code. Note that __ATTR can't be used in MDIO_BUS_STATS_ADDR_ATTR_DECL because the included stringification would conflict with how argument file is passed. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/4877a4dc-247c-4453-b281-20a8d969b15b@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>