summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-09-28firewire: core: fix undefined reference error in ARM EABITakashi Sakamoto
For ARM EABI, GCC generates a reference to __aeabi_uldivmod when compiling a division of 64-bit integer with 32-bit integer. This function is not available in Linux kernel. In such cases, helper macros are defined in include/linux/math64.h. This commit replaces the division with div_u64(). Fixes: 8ec6a8ec23b9 ("firewire: core: suppress overflow warning when computing jiffies from isochronous cycle") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202509270428.FZaO2PPq-lkp@intel.com/ Link: https://lore.kernel.org/r/20250928011910.581475-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-09-28i2c: i801: Add support for Intel Wildcat Lake-UJarkko Nikula
Add SMBus IDs on Intel Wildcat Lake-U. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-28i2c: rtl9300: Drop unsupported I2C_FUNC_SMBUS_I2C_BLOCKSven Eckelmann
While applying the patch for commit ede965fd555a ("i2c: rtl9300: remove broken SMBus Quick operation support"), a conflict was incorrectly solved by adding the I2C_FUNC_SMBUS_I2C_BLOCK feature flag. But the code to handle I2C_SMBUS_I2C_BLOCK_DATA requests will be added by a separate commit. Fixes: ede965fd555a ("i2c: rtl9300: remove broken SMBus Quick operation support") Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-28thermal/drivers/renesas/rzg3e: Fix add thermal driver for the Renesas RZ/G3E SoCJohn Madieu
When applied the change commit 19d3a401a617, a conflict appeared resulting into a manual fix. However the new file rzg3e_thermal.c was not added but stayed locally in source tree and miss to be merged with the entire change. Fix this by adding the file back. Fixes: 19d3a401a617 ("Add thermal driver for the Renesas RZ/G3E SoC") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202509272225.sARVqv2G-lkp@intel.com Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-28Merge tag 'i2c-host-6.18' of ↵Wolfram Sang
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-mergewindow i2c-host for v6.18 - Add support for MediaTek MT6878 I2C - Drop support for S3C2410
2025-09-27net/mlx5: Expose uar access and odp page fault countersAkiva Goldberger
Add three counters to vnic health reporter: bar_uar_access, odp_local_triggered_page_fault, and odp_remote_triggered_page_fault. - bar_uar_access number of WRITE or READ access operations to the UAR on the PCIe BAR. - odp_local_triggered_page_fault number of locally-triggered page-faults due to ODP. - odp_remote_triggered_page_fault number of remotly-triggered page-faults due to ODP. Example access: $ devlink health diagnose pci/0000:08:00.0 reporter vnic vNIC env counters: total_error_queues: 0 send_queue_priority_update_flow: 0 comp_eq_overrun: 0 async_eq_overrun: 0 cq_overrun: 0 invalid_command: 0 quota_exceeded_command: 0 nic_receive_steering_discard: 0 icm_consumption: 1032 bar_uar_access: 1279 odp_local_triggered_page_fault: 20 odp_remote_triggered_page_fault: 34 Signed-off-by: Akiva Goldberger <agoldberger@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1758797130-829564-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-27Bluetooth: bcsp: receive data only if registeredIvan Pravdin
Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: <TASK> hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH. Reported-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4ed6852d4da4606c93da Tested-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btusb: Add new VID/PID 13d3/3633 for MT7922Chris Lu
Add VID 13d3 & PID 3633 for MediaTek MT7922 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3633 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btusb: Add new VID/PID 13d3/3627 for MT7925Chris Lu
Add VID 13d3 & PID 3627 for MediaTek MT7922 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3627 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: remove duplicate h4_recv_buf() in headerCalvin Owens
The "h4_recv.h" header contains a duplicate h4_recv_buf() that is nearly but not quite identical to the h4_recv_buf() in hci_h4.c. This duplicated header was added in commit 07eb96a5a7b0 ("Bluetooth: bpa10x: Use separate h4_recv_buf helper"). I wasn't able to find any explanation for duplicating the code in the discussion: https://lore.kernel.org/all/20180320181855.37297-1-marcel@holtmann.org/ https://lore.kernel.org/all/20180324091954.73229-2-marcel@holtmann.org/ Unfortunately, in the years since, several other drivers have come to also rely on this duplicated function, probably by accident. This is, at the very least, *extremely* confusing. It's also caused real issues when it's become out-of-sync, see the following: ef564119ba83 ("Bluetooth: hci_h4: Add support for ISO packets") 61b27cdf025b ("Bluetooth: hci_h4: Add support for ISO packets in h4_recv.h") This is the full diff between the two implementations today: --- orig.c +++ copy.c @@ -1,117 +1,100 @@ { - struct hci_uart *hu = hci_get_drvdata(hdev); - u8 alignment = hu->alignment ? hu->alignment : 1; - /* Check for error from previous call */ if (IS_ERR(skb)) skb = NULL; while (count) { int i, len; - /* remove padding bytes from buffer */ - for (; hu->padding && count > 0; hu->padding--) { - count--; - buffer++; - } - if (!count) - break; - if (!skb) { for (i = 0; i < pkts_count; i++) { if (buffer[0] != (&pkts[i])->type) continue; skb = bt_skb_alloc((&pkts[i])->maxlen, GFP_ATOMIC); if (!skb) return ERR_PTR(-ENOMEM); hci_skb_pkt_type(skb) = (&pkts[i])->type; hci_skb_expect(skb) = (&pkts[i])->hlen; break; } /* Check for invalid packet type */ if (!skb) return ERR_PTR(-EILSEQ); count -= 1; buffer += 1; } len = min_t(uint, hci_skb_expect(skb) - skb->len, count); skb_put_data(skb, buffer, len); count -= len; buffer += len; /* Check for partial packet */ if (skb->len < hci_skb_expect(skb)) continue; for (i = 0; i < pkts_count; i++) { if (hci_skb_pkt_type(skb) == (&pkts[i])->type) break; } if (i >= pkts_count) { kfree_skb(skb); return ERR_PTR(-EILSEQ); } if (skb->len == (&pkts[i])->hlen) { u16 dlen; switch ((&pkts[i])->lsize) { case 0: /* No variable data length */ dlen = 0; break; case 1: /* Single octet variable length */ dlen = skb->data[(&pkts[i])->loff]; hci_skb_expect(skb) += dlen; if (skb_tailroom(skb) < dlen) { kfree_skb(skb); return ERR_PTR(-EMSGSIZE); } break; case 2: /* Double octet variable length */ dlen = get_unaligned_le16(skb->data + (&pkts[i])->loff); hci_skb_expect(skb) += dlen; if (skb_tailroom(skb) < dlen) { kfree_skb(skb); return ERR_PTR(-EMSGSIZE); } break; default: /* Unsupported variable length */ kfree_skb(skb); return ERR_PTR(-EILSEQ); } if (!dlen) { - hu->padding = (skb->len + 1) % alignment; - hu->padding = (alignment - hu->padding) % alignment; - /* No more data, complete frame */ (&pkts[i])->recv(hdev, skb); skb = NULL; } } else { - hu->padding = (skb->len + 1) % alignment; - hu->padding = (alignment - hu->padding) % alignment; - /* Complete frame */ (&pkts[i])->recv(hdev, skb); skb = NULL; } } return skb; } -EXPORT_SYMBOL_GPL(h4_recv_buf) As I read this: If alignment is one, and padding is zero, padding remains zero throughout the loop. So it seems to me that the two functions behave strictly identically in that case. All the duplicated defines are also identical, as is the duplicated h4_recv_pkt structure declaration. All four drivers which use the duplicated function use the default alignment of one, and the default padding of zero. I therefore conclude the duplicate function may be safely replaced with the core one. I raised this in an RFC a few months ago, and didn't get much interest: https://lore.kernel.org/all/CABBYNZ+ONkYtq2fR-8PtL3X-vetvJ0BdP4MTw9cNpjLDzG3HUQ@mail.gmail.com/ ...but I'm still wary I've missed something, and I'd really appreciate more eyeballs on it. I tested this successfully on btnxpuart a few months ago, but unfortunately I no longer have access to that hardware. Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Calvin Owens <calvin@wbinvd.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI framesArkadiusz Bokowy
Some Barrot based USB Bluetooth dongles erroneously send one extra random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The consequence of that is that the next HCI transfer is misaligned by one byte causing undefined behavior. In most cases the response event for the next command fails with random error code. Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI controller initialization, the initialization fails rendering the USB dongle not usable. > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91 > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110 This patch was tested with the 33fa:0012 device. The info from the /sys/kernel/debug/usb/devices is shown below: T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 12 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33fa ProdID=0012 Rev=88.91 S: Product=UGREEN BT6.0 Adapter C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Now the device is initialized properly: > [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg > [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91 > [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter > [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes > [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes > [43.750141] Bluetooth: MGMT ver 1.23 Link: https://github.com/bluez/bluez/issues/1326 Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com> Tested-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Refactor Device CoredumpKiran K
As device coredumps are not HCI traces, maintain the device coredump at the driver level and eliminate the dependency on hdev_devcd*() Signed-off-by: Kiran K <kiran.k@intel.com> Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Use strscpy() instead of strscpy_pad()Thorsten Blum
kzalloc() already zero-initializes the destination buffer 'data', making strscpy() sufficient for safely copying 'name'. The additional NUL-padding performed by strscpy_pad() is unnecessary. Add a new local variable to store the length of 'name' and reuse it instead of recalculating the same length. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Define hdev->wakeup() callbackChandrashekar Devegowda
Implement hdev->wakeup() callback to support Wake On BT feature. Test steps: 1. echo enabled > /sys/bus/pci/devices/0000:00:14.7/power/wakeup 2. connect bluetooth hid device 3. put the system to suspend - rtcwake -m mem -s 300 4. press any key on hid to wake up the system Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1Zenm Chen
Add USB ID 2001:332a for D-Link AX9U rev. A1 which is based on a Realtek RTL8851BU chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=332a Rev= 0.00 S: Manufacturer=Realtek S: Product=802.11ax WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw89_8851bu_git E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org # 6.12.x Signed-off-by: Zenm Chen <zenmchen@gmail.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Move model comment before its definitionLuiz Augusto von Dentz
This prevents the comments going over 80 columns which is still required for Bluetooth code. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484Kiran K
sudo lspci -v -k -d 8086:e376 00:14.7 Bluetooth: Intel Corporation Device e376 Subsystem: Intel Corporation Device 0011 Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 14 Memory at 14815368000 (64-bit, non-prefetchable) [size=16K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [80] MSI-X: Enable+ Count=32 Masked- Capabilities: [100] Latency Tolerance Reporting Kernel driver in use: btintel_pcie Kernel modules: btintel_pcie Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Add Bluetooth core/platform as commentsKiran K
Add Bluetooth CNVi core and platform names to the PCI device table for each device ID as a comment. Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Add support for _suspend() / _resume()Chandrashekar Devegowda
This patch implements _suspend() and _resume() functions for the Bluetooth controller. When the system enters a suspended state, the driver notifies the controller to perform necessary housekeeping tasks by writing to the sleep control register and waits for an alive interrupt. The firmware raises the alive interrupt when it has transitioned to the D3 state. The same flow occurs when the system resumes. Command to test host initiated wakeup after 60 seconds sudo rtcwake -m mem -s 60 dmesg log (tested on Whale Peak2 on Panther Lake platform) On system suspend: [Fri Jul 25 11:05:37 2025] Bluetooth: hci0: device entered into d3 state from d0 in 80 us On system resume: [Fri Jul 25 11:06:36 2025] Bluetooth: hci0: device entered into d0 state from d3 in 7117 us Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel: Add support for BlazarIW coreKiran K
Add support for the BlazarIW Bluetooth core used in the Wildcat Lake platform. HCI traces: < HCI Command: Intel Read Version (0x3f|0x0005) plen 1 Requested Type: All Supported Types(0xff) > HCI Event: Command Complete (0x0e) plen 122 Intel Read Version (0x3f|0x0005) ncmd 1 Status: Success (0x00) ..... CNVi BT(18): 0x00223700 - BlazarIW(0x22) ..... ..... Signed-off-by: Vijay Satija <vijay.satija@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27PM: sleep: Do not wait on SYNC_STATE_ONLY device linksPin-yen Lin
Device links with DL_FLAG_SYNC_STATE_ONLY should not affect system suspend and resume, and functions like device_reorder_to_tail() and device_link_add() don't try to reorder the consumers with that flag. However, dpm_wait_for_consumers() and dpm_wait_for_suppliers() don't check thas flag before triggering dpm_wait(), leading to potential hang during suspend/resume. This can be reproduced on MT8186 Corsola Chromebook with devicetree like: usb-a-connector { compatible = "usb-a-connector"; port { usb_a_con: endpoint { remote-endpoint = <&usb_hs>; }; }; }; usb_host { compatible = "mediatek,mt8186-xhci", "mediatek,mtk-xhci"; port { usb_hs: endpoint { remote-endpoint = <&usb_a_con>; }; }; }; In this case, the two nodes form a cycle and a SYNC_STATE_ONLY devlink between usb_host (supplier) and usb-a-connector (consumer) is created. Address this by exporting device_link_flag_is_sync_state_only() and making dpm_wait_for_consumers() and dpm_wait_for_suppliers() use it when deciding if dpm_wait() should be called. Fixes: 05ef983e0d65a ("driver core: Add device link support for SYNC_STATE_ONLY flag") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Link: https://patch.msgid.link/20250926102320.4053167-1-treapking@chromium.org [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-27PM: runtime: Make put{,_sync}() return 1 when already suspendedBrian Norris
The pm_runtime.h docs say pm_runtime_put() and pm_runtime_put_sync() return 1 when already suspended, but this is not true -- they return -EAGAIN. On the other hand, pm_runtime_put_sync_suspend() and pm_runtime_put_sync_autosuspend() *do* return 1. This is an artifact of the fact that the former are built on rpm_idle(), whereas the latter are built on rpm_suspend(). There are precious few pm_runtime_put()/pm_runtime_put_sync() callers that check the return code at all, but most of them only log errors, and usually only for negative error codes. None of them should be treating this as an error, so: * at best, this may fix some case where a driver treats this condition as an error, when it shouldn't; * at worst, this should make no effect; and * somewhere in between, we could potentially clear up non-fatal log messages. Fix the pm_runtime_already_suspended_test() while tweaking the behavior. The test makes a lot more sense when these all return 1 when the device is already suspended: pm_runtime_put_sync(dev); pm_runtime_suspend(dev); pm_runtime_autosuspend(dev); pm_request_autosuspend(dev); pm_runtime_put_sync_autosuspend(dev); Notably, I've avoided testing the return codes for these, since they really should be ignored by callers, and we may make them 'void' altogether: pm_runtime_put(dev); pm_runtime_put_autosuspend(dev); Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-27PM: runtime: Add basic kunit tests for API contractsBrian Norris
In exploring the various return codes and failure modes of runtime PM APIs, I found it helpful to verify and codify many of them in unit tests, especially given that even the kerneldoc can be rather complex to reason through, and it also has had subtle errors of its own. Notably, I avoid testing the return codes for pm_runtime_put() and pm_runtime_put_autosuspend(), since code that checks them is probably wrong, and we're considering making them return 'void' altogether. I still test the sync() variants, since those have a bit more meaning to them. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-26net: macb: avoid dealing with endianness in macb_set_hwaddr()Théo Lebrun
bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32 pointer and dereferencing implies dealing manually with endianness, which is error-prone. Replace by calls to get_unaligned_le32|le16() helpers. This was found using sparse: ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o warning: incorrect type in assignment (different base types) expected unsigned int [usertype] bottom got restricted __le32 [usertype] warning: incorrect type in assignment (different base types) expected unsigned short [usertype] top got restricted __le16 [usertype] ... Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-5-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: single dma_alloc_coherent() for DMA descriptorsThéo Lebrun
Move from 2*NUM_QUEUES dma_alloc_coherent() for DMA descriptor rings to 2 calls overall. Issue is with how all queues share the same register for configuring the upper 32-bits of Tx/Rx descriptor rings. Taking Tx, notice how TBQPH does *not* depend on the queue index: #define GEM_TBQP(hw_q) (0x0440 + ((hw_q) << 2)) #define GEM_TBQPH(hw_q) (0x04C8) queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma)); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT if (bp->hw_dma_cap & HW_DMA_CAP_64B) queue_writel(queue, TBQPH, upper_32_bits(queue->tx_ring_dma)); #endif To maximise our chances of getting valid DMA addresses, we do a single dma_alloc_coherent() across queues. This improves the odds because alloc_pages() guarantees natural alignment. Other codepaths (IOMMU or dev/arch dma_map_ops) don't give high enough guarantees (even page-aligned isn't enough). Two consideration: - dma_alloc_coherent() gives us page alignment. Here we remove this constraint meaning each queue's ring won't be page-aligned anymore. - This can save some tiny amounts of memory. Fewer allocations means (1) less overhead (constant cost per alloc) and (2) less wasted bytes due to alignment constraints. Example for (2): 4 queues, default ring size (512), 64-bit DMA descriptors, 16K pages: - Before: 8 allocs of 8K, each rounded to 16K => 64K wasted. - After: 2 allocs of 32K => 0K wasted. Fixes: 02c958dd3446 ("net/macb: add TX multiqueue support for gem") Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com> # on sam9x75 Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-4-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: move ring size computation to functionsThéo Lebrun
The tx/rx ring size calculation is somewhat complex and partially hidden behind a macro. Move that out of the {RX,TX}_RING_BYTES() macros and macb_{alloc,free}_consistent() functions into neat separate functions. In macb_free_consistent(), we drop the size variable and directly call the size helpers in the arguments list. In macb_alloc_consistent(), we keep the size variable that is used by netdev_dbg() calls. Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-3-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: remove illusion about TBQPH/RBQPH being per-queueThéo Lebrun
The MACB driver acts as if TBQPH/RBQPH are configurable on a per queue basis; this is a lie. A single register configures the upper 32 bits of each DMA descriptor buffers for all queues. Concrete actions: - Drop GEM_TBQPH/GEM_RBQPH macros which have a queue index argument. Only use MACB_TBQPH/MACB_RBQPH constants. - Drop struct macb_queue->TBQPH/RBQPH fields. - In macb_init_buffers(): do a single write to TBQPH and RBQPH for all queues instead of a write per queue. - In macb_tx_error_task(): drop the write to TBQPH. - In macb_alloc_consistent(): if allocations give different upper 32-bits, fail. Previously, it would have lead to silent memory corruption as queues would have used the upper 32 bits of the alloc from queue 0 and their own low 32 bits. - In macb_suspend(): if we use the tie off descriptor for suspend, do the write once for all queues instead of once per queue. Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM") Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues") Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-2-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26octeon_ep_vf: Add support to retrieve hardware channel informationSathesh B Edara
This patch introduces support for retrieving hardware channel configuration through the ethtool interface. Signed-off-by: Sathesh B Edara <sedara@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250925125134.22421-3-sedara@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26octeon_ep: Add support to retrieve hardware channel informationSathesh B Edara
This patch introduces support for retrieving hardware channel configuration through the ethtool interface. Signed-off-by: Sathesh B Edara <sedara@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250925125134.22421-2-sedara@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: phy: micrel: Fix lan8814_config_initHoratiu Vultur
The blamed commit introduced the function lanphy_modify_page_reg which as name suggests it, it modifies the registers. In the same commit we have started to use this function inside the drivers. The problem is that in the function lan8814_config_init we passed the wrong page number when disabling the aneg towards host side. We passed extended page number 4(LAN8814_PAGE_COMMON_REGS) instead of extended page 5(LAN8814_PAGE_PORT_REGS) Fixes: a0de636ed7a264 ("net: phy: micrel: Introduce lanphy_modify_page_reg") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250925064702.3906950-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26vhost: vringh: Fix copy_to_iter return value checkMichael S. Tsirkin
The return value of copy_to_iter can't be negative, check whether the copied length is equal to the requested length instead of checking for negative values. Cc: zhang jiao <zhangjiao2@cmss.chinamobile.com> Link: https://lore.kernel.org/all/20250910091739.2999-1-zhangjiao2@cmss.chinamobile.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 309bba39c945 ("vringh: iterate on iotlb_translate to handle large translations") Link: https://patch.msgid.link/cd637504a6e3967954a9e80fc1b75e8c0978087b.1758723310.git.mst@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: airoha: npu: Add a NPU callback to initialize flow statsLorenzo Bianconi
Introduce a NPU callback to initialize flow stats and remove NPU stats initialization from airoha_npu_get routine. Add num_stats_entries to airoha_npu_ppe_stats_setup routine. This patch makes the code more readable since NPU statistic are now initialized on demand by the NPU consumer (at the moment NPU statistic are configured just by the airoha_eth driver). Moreover this patch allows the NPU consumer (PPE module) to explicitly enable/disable NPU flow stats. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250924-airoha-npu-init-stats-callback-v1-1-88bdf3c941b2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26eth: fbnic: Add support to read lane countMohsin Bashir
We are reporting the lane count in the link settings but the flag is not set to indicate that the driver supports lanes. Set the flag to report lane count. ~]# ethtool eth0 | grep Lanes Lanes: 2 Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250924184445.2293325-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26Wangxun: vf: Implement some ethtool apis for get_xxxMengyuan Lou
Implement some ethtool interfaces for obtaining the status of Wangxun Virtual Function Ethernet. Just like connection status, version information, queue depth and so on. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250924082140.41612-1-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net/mlx5e: Report RS-FEC histogram statistics via ethtoolCarolina Jubran
Add support for reporting RS-FEC histogram counters by reading them from the RS_FEC_HISTOGRAM_GROUP in the PPCNT register. Co-developed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Link: https://patch.msgid.link/20250924124037.1508846-5-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net/mlx5e: Add logic to read RS-FEC histogram bin ranges from PPHCRCarolina Jubran
Introduce support for querying the Ports Phy Histogram Configuration Register (PPHCR) to retrieve RS-FEC histogram bin ranges. The ranges are stored in a static array and will be used to map histogram counters to error levels. The actual RS-FEC histogram statistics are not yet reported in this commit and will be handled in a downstream patch. Co-developed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250924124037.1508846-4-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net/mlx5e: Don't query FEC statistics when FEC is disabledCarolina Jubran
Update mlx5e_stats_fec_get() to check the active FEC mode and skip statistics collection when FEC is disabled. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250924124037.1508846-3-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26ethtool: add FEC bins histogram reportVadim Fedorenko
IEEE 802.3ck-2022 defines counters for FEC bins and 802.3df-2024 clarifies it a bit further. Implement reporting interface through as addition to FEC stats available in ethtool. Drivers can leave bin counter uninitialized if per-lane values are provided. In this case the core will recalculate summ for the bin. Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250924124037.1508846-2-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: qed: Remove redundant NULL checks after list_first_entry()Zhen Ni
list_first_entry() never returns NULL — if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. The calls to list_first_entry() are always guarded by !list_empty(), which guarantees a valid entry is returned. Therefore, the additional `if (!p_buffer) break;` checks in qed_ooo_release_connection_isles(), qed_ooo_release_all_isles(), and qed_ooo_free() are redundant and unreachable. Remove the dead code for clarity and consistency with common list handling patterns in the kernel. No functional change intended. Signed-off-by: Zhen Ni <zhen.ni@easystack.cn> Link: https://patch.msgid.link/20250924030219.1252773-1-zhen.ni@easystack.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26ptp: Add a upper bound on max_vclocksI Viswanath
syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc Reported-by: syzbot+94d20db923b9f51be0df@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=94d20db923b9f51be0df Tested-by: syzbot+94d20db923b9f51be0df@syzkaller.appspotmail.com Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: I Viswanath <viswanathiyyappan@gmail.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Link: https://patch.msgid.link/20250925155908.5034-1-viswanathiyyappan@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26dpll: zl3073x: Fix double free in zl3073x_devlink_flash_update()Dan Carpenter
The zl3073x_devlink_flash_prepare() function calls zl3073x_fw_free() and the caller, zl3073x_devlink_flash_update(), also calls that same free function so it leads to a double free. Delete the extra free. Fixes: a1e891fe4ae8 ("dpll: zl3073x: Implement devlink flash callback") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/aNVDbcIQq4RmU_fl@stanley.mountain Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26Merge branch '200GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== idpf: add XSk support Alexander Lobakin says: Add support for XSk xmit and receive using libeth_xdp. This includes adding interfaces to reconfigure/enable/disable only a particular set of queues and support for checksum offload XSk Tx metadata. libeth_xdp's implementation mostly matches the one of ice: batched allocations and sending, unrolled descriptor writes etc. But unlike other Intel drivers, XSk wakeup is implemented using CSD/IPI instead of HW "software interrupt". In lots of different tests, this yielded way better perf than SW interrupts, but also, this gives better control over which CPU will handle the NAPI loop (SW interrupts are a subject to irqbalance and stuff, while CSDs are strictly pinned 1:1 to the core of the same index). Note that the header split is always disabled for XSk queues, as for now we see no reasons to have it there. XSk xmit perf is up to 3x comparing to ice. XSk XDP_PASS is also faster a bunch as it uses system percpu page_pools, so that the only overhead left is memcpy(). The rest is at least comparable. * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: idpf: enable XSk features and ndo_xsk_wakeup idpf: implement Rx path for AF_XDP idpf: implement XSk xmit idpf: add XSk pool initialization idpf: add virtchnl functions to manage selected queues ==================== Link: https://patch.msgid.link/20250924175230.1290529-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: wan: framer: Add version sysfs attribute for the Lantiq PEF2256 framerChristophe Leroy
Lantiq PEF2256 framer has some little differences in behaviour depending on its version. Add a sysfs attribute to allow user applications to know the version. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://patch.msgid.link/77a27941d6924b1009df0162ed9f0fa07ed6e431.1758726302.git.christophe.leroy@csgroup.eu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicastI Viswanath
syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb. This is the sequence of events that leads to the warning: rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); } rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done } rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission } rtl8150_set_multicast being the ndo_set_rx_mode callback should not be calling netif_stop_queue and notif_start_queue as these handle TX queue synchronization. The net core function dev_set_rx_mode handles the synchronization for rtl8150_set_multicast making it safe to remove these locks. Reported-and-tested-by: syzbot+78cae3f37c62ad092caa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=78cae3f37c62ad092caa Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: I Viswanath <viswanathiyyappan@gmail.com> Link: https://patch.msgid.link/20250924134350.264597-1-viswanathiyyappan@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26dibs: Check correct variable in dibs_init()Dan Carpenter
There is a typo in this code. It should check "dibs_class" instead of "&dibs_class". Remove the &. Fixes: 804737349813 ("dibs: Create class dibs") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Link: https://patch.msgid.link/aNP-XcrjSUjZAu4a@stanley.mountain Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: renesas: rswitch: Remove unneeded semicolonsGeert Uytterhoeven
Semicolons after end of function braces are not needed, remove them. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Link: https://patch.msgid.link/e6b57123f319c03b3f078981cb452be49e86253b.1758719832.git.geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: enetc: Fix probing error message typo for the ENETCv4 PF driverClaudiu Manoil
Blamed commit wrongly indicates VF error in case of PF probing error. Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF") Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250924082755.1984798-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26Merge tag 'linux-can-next-for-6.18-20250924' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2025-09-25 this is a pull request of 48 patches for net-next/main, which supersedes tags/linux-can-next-for-6.18-20250923. The 1st patch is by Xichao Zhao and converts ns_to_ktime() to us_to_ktime() in the m_can driver. Vincent Mailhol contributes 2 patches: Updating the MAINTAINERS and mailmap files to Vincent's new email address and sorting the includes in the CAN helper library alphabeticaly. Stéphane Grosjean's patch modifies all peak CAN drivers and the mailmap to reflect Stéphane's new email address. 4 patches by Biju Das update the CAN-FD handling in the rcar_canfd driver. Followed by 11 patches by Geert Uytterhoeven updating and improving the rcar_can driver. Stefan Mätje contributes 2 patches for the esd_usb driver updating the error messages. The next 3 patch series are all by Vincent Mailhol: 3 patches to optimize the size of struct raw_sock and struct uniqframe. 4 patches which rework the CAN MTU logic as preparation for CAN-XL interfaces. And finally 20 patches that prepare and refactor the CAN netlink code for the upcoming CAN-XL support. * tag 'linux-can-next-for-6.18-20250924' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (48 commits) can: netlink: add userland error messages can: dev: add can_get_ctrlmode_str() can: calc_bittiming: make can_calc_tdco() FD agnostic can: netlink: make can_tdc_fill_info() FD agnostic can: netlink: add can_bitrate_const_fill_info() can: netlink: add can_bittiming_const_fill_info() can: netlink: add can_bittiming_fill_info() can: netlink: add can_data_bittiming_get_size() can: netlink: make can_tdc_get_size() FD agnostic can: netlink: add can_ctrlmode_changelink() can: netlink: add can_dtb_changelink() can: netlink: make can_tdc_changelink() FD agnostic can: netlink: remove useless check in can_tdc_changelink() can: netlink: refactor CAN_CTRLMODE_TDC_{AUTO,MANUAL} flag reset logic can: netlink: add can_validate_databittiming() can: netlink: add can_validate_tdc() can: netlink: refactor can_validate_bittiming() can: netlink: document which symbols are FD specific can: dev: make can_get_relative_tdco() FD agnostic and move it to bittiming.h can: dev: move struct data_bittiming_params to linux/can/bittiming.h ... ==================== Link: https://patch.msgid.link/20250925121332.848157-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26Merge tag 'wireless-next-2025-09-25' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a bit more things, including pull requests from drivers: - mt76: MLO support, HW restart improvements - rtw88/89: small features, prep for RTL8922DE support - ath10k: GTK rekey fixes - cfg80211/mac80211: - additions for more NAN support - S1G channel representation cleanup * tag 'wireless-next-2025-09-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (167 commits) wifi: libertas: add WQ_UNBOUND to alloc_workqueue users Revert "wifi: libertas: WQ_PERCPU added to alloc_workqueue users" wifi: libertas: WQ_PERCPU added to alloc_workqueue users wifi: cfg80211: fix width unit in cfg80211_radio_chandef_valid() wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again wifi: ath12k: enforce CPU endian format for all QMI data wifi: ath12k: Use 1KB Cache Flush Command for QoS TID Descriptors wifi: ath12k: Fix flush cache failure during RX queue update wifi: ath12k: Add Retry Mechanism for REO RX Queue Update Failures wifi: ath12k: Refactor REO command to use ath12k_dp_rx_tid_rxq wifi: ath12k: Refactor RX TID buffer cleanup into helper function wifi: ath12k: Refactor RX TID deletion handling into helper function wifi: ath12k: Increase DP_REO_CMD_RING_SIZE to 256 wifi: cfg80211: remove IEEE80211_CHAN_{1,2,4,8,16}MHZ flags wifi: rtw89: avoid circular locking dependency in ser_state_run() wifi: rtw89: fix leak in rtw89_core_send_nullfunc() wifi: rtw89: avoid possible TX wait initialization race wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() wifi: ath12k: Fix peer lookup in ath12k_dp_mon_rx_deliver_msdu() wifi: mac80211: fix Rx packet handling when pubsta information is not available ... ==================== Link: https://patch.msgid.link/20250925232341.4544-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26PCI: dwc: Support 16-lane operationKonrad Dybcio
Some hosts support 16 lanes of PCIe. Make num-lanes accept that number. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250926-topic-pcie_16ln-v1-1-c249acc18790@oss.qualcomm.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-07 02:49:10 +0000