summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-01-29Bluetooth: hci_qca: Refactor HFP hardware offload capability handlingMengshi Wu1-4/+9
Replace SoC-specific check with capability-based approach for HFP hardware offload configuration. Add QCA_CAP_HFP_HW_OFFLOAD capability flag and support_hfp_hw_offload field to qca_serdev structure. Add QCA_CAP_HFP_HW_OFFLOAD capability flag to QCA2066 device data structures. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mengshi Wu <mengshi.wu@oss.qualcomm.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Add USB ID 7392:e611 for Edimax EW-7611UXBZenm Chen1-0/+2
Add USB ID 7392:e611 for Edimax EW-7611UXB which is RTL8851BU-based Wi-Fi + Bluetooth adapter. 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=01 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=7392 ProdID=e611 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.6.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>
2026-01-29Bluetooth: L2CAP: Fix not tracking outstanding TX identLuiz Augusto von Dentz2-16/+33
This attempts to proper track outstanding request by using struct ida and allocating from it in l2cap_get_ident using ida_alloc_range which would reuse ids as they are free, then upon completion release the id using ida_free. This fixes the qualification test case L2CAP/COS/CED/BI-29-C which attempts to check if the host stack is able to work after 256 attempts to connect which requires Ident field to use the full range of possible values in order to pass the test. Link: https://github.com/bluez/bluez/issues/1829 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
2026-01-29Bluetooth: MGMT: Fix memory leak in set_ssp_completeJianpeng Chang1-0/+3
Fix memory leak in set_ssp_complete() where mgmt_pending_cmd structures are not freed after being removed from the pending list. Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") replaced mgmt_pending_foreach() calls with individual command handling but missed adding mgmt_pending_free() calls in both error and success paths of set_ssp_complete(). Other completion functions like set_le_complete() were fixed correctly in the same commit. This causes a memory leak of the mgmt_pending_cmd structure and its associated parameter data for each SSP command that completes. Add the missing mgmt_pending_free(cmd) calls in both code paths to fix the memory leak. Also fix the same issue in set_advertising_complete(). Fixes: 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_workJia-Hong Su1-2/+2
hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Link: https://lore.kernel.org/linux-bluetooth/6969764f.170a0220.2b9fc4.35a7@mx.google.com/ Signed-off-by: Jia-Hong Su <s11242586@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Remove duplicate entry for 0x13d3/0x3618Linmao Li1-2/+0
The USB device ID 0x13d3/0x3618 is listed twice in the device table. Remove the duplicate entry and keep the one under the correct "Realtek 8852BT/8852BE-VT Bluetooth devices" section. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Add device ID for Realtek RTL8761BUJacopo Scannella1-0/+1
Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella <code@charlie.cat> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btintel: Remove unneeded CONFIG_PM* #ifdef'sBastien Nocera1-8/+2
The functions are already disabled if CONFIG_PM or CONFIG_PM_SLEEP are disabled through the use of SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS(). This increases build coverage and allows to drop a few #ifdef's. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btnxpuart: Remove unneeded CONFIG_PM ifdefBastien Nocera1-4/+2
The functions are already disabled through the use of pm_ptr() when CONFIG_PM is disabled, and will be removed from the final linked code as not needed. This increases build coverage and allows to drop an #ifdef. Signed-off-by: Bastien Nocera <hadess@hadess.net> Reviewed-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Add new VID/PID for RTL8852CEShell Chen1-0/+2
Add VID:PID 13d3:3612 to the quirks_table. This ID pair is found in the Realtek RTL8852CE PCIe module in an ASUS TUF A14 2025 (FA401KM) laptop. Tested on aforementioned laptop. The device info from /sys/kernel/debug/usb/devices is listed as below. T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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 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 Signed-off-by: Shell Chen <w27@sorz.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btintel_pcie: Remove unnecessary check before kfree_skb()Chen Ni1-2/+1
The kfree_skb() function internally checks if the skb is NULL, so an explicit check before calling it is redundant and can be removed. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Reject autosuspend if discovery is activeLinmao Li1-3/+4
If USB autosuspend occurs while discovery is active, the ongoing HCI operation may not complete successfully. On some devices, this can leave discovery.state stuck in DISCOVERY_FINDING. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_core: Export hci_discovery_activeLinmao Li1-0/+1
Export hci_discovery_active() so it can be used by bluetooth drivers built as modules. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Use pm_ptr instead of #ifdef CONFIG_PMBastien Nocera1-6/+2
This increases build coverage and allows to drop an #ifdef. Signed-off-by: Bastien Nocera <hadess@hadess.net> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn7850-bt: Deprecate old suppliesKrzysztof Kozlowski1-0/+5
Commit bd3f305886ad ("dt-bindings: bluetooth: qualcomm: describe the inputs from PMU for wcn7850") changed the binding to new description with a Power Management Unit (PMU), thus certain power-controller properties are considered deprecated and are part of that PMUs binding. Deprecate them to mark clearly that new PMU-based approach is preferred. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn7850-bt: Split to separate schemaKrzysztof Kozlowski1-46/+37
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,wcn7850-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. Re-shuffle few properties to alphabetical order while moving them and drop redundant enable-gpios description. This makes the source qualcomm-bluetooth.yaml binding empty, thus drop it making entire change a variant of file rename. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn6855-bt: Deprecate old suppliesKrzysztof Kozlowski1-0/+5
Commit 5f4f954bba12 ("dt-bindings: bluetooth: bring the HW description closer to reality for wcn6855") changed the binding to new description with a Power Management Unit (PMU), thus certain power-controller properties are considered deprecated and are part of that PMUs binding. Deprecate them to mark clearly that new PMU-based approach is preferred. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn6855-bt: Split to separate schemaKrzysztof Kozlowski2-26/+94
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,wcn6855-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn6750-bt: Deprecate old suppliesKrzysztof Kozlowski1-0/+5
Commit cca4fe34979a ("dt-bindings: bluetooth: Utilize PMU abstraction for WCN6750") changed the binding to new description with a Power Management Unit (PMU), thus certain power-controller properties are considered deprecated and are part of that PMUs binding. Deprecate them to mark clearly that new PMU-based approach is preferred. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn6750-bt: Split to separate schemaKrzysztof Kozlowski2-45/+86
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,wcn6750-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn3990-bt: Split to separate schemaKrzysztof Kozlowski2-47/+66
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,wcn3990-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. This binding is very similar to qcom,wcn3950-bt, however devices have additional VDD_CH1 supply. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,wcn3950-bt: Split to separate schemaKrzysztof Kozlowski2-4/+67
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,wcn3950-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,qca6390-bt: Split to separate schemaKrzysztof Kozlowski2-15/+64
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,qca6390-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,qca9377-bt: Split to separate schemaKrzysztof Kozlowski2-1/+58
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split qcom,qca9377-bt to separate bindings, so device schema will be easier to read/maintain and list only relevant properties. Existing binding has incomplete and incorrect list of supplies (e.g. there is no VDD_XO) and Linux driver does not ask for any, thus keep this state unchanged. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29dt-bindings: bluetooth: qcom,qca2066-bt: Split to separate schemaKrzysztof Kozlowski4-24/+76
One big Qualcomm Bluetooth schema is hardly manageable: it lists all possible properties (19 supplies). Split common part and qcom,qca2066-bt to separate bindings, so each schema will be easier to read/maintain and list only relevant properties. The existing bindings do not mention interrupts, but am335x-sancloud-bbe-extended-wifi.dts already defines such. This issue is not being fixed here. Existing binding also did not mention any supplies (which do exist as confirmed in datasheet) and Linux driver does not ask for any, thus keep this state unchanged. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: Fix using PHYs bitfields as PHY valueLuiz Augusto von Dentz6-36/+52
This renames the PHY fields in bt_iso_io_qos to PHYs (plural) since it represents a bitfield where multiple PHYs can be set and make the same change also to HCI_OP_LE_SET_CIG_PARAMS since both c_phy and p_phy fields are bitfields. This also fixes the assumption that hci_evt_le_cis_established PHYs fields are compatible with bt_iso_io_qos, they are not, the fields in hci_evt_le_cis_established represent just a single PHY value so they need to be converted to bitfield when set in bt_iso_io_qos. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BETechie Ernie1-0/+2
Add USB ID 0489:e112 for the Realtek 8851BE Bluetooth adapter. Without this entry, the device is not handled correctly by btusb and Bluetooth fails to initialise. Adding the ID enables proper Realtek initialization for Bluetooth to work on various motherboards using this Bluetooth adapter. The device identifies as: Bus 001 Device XXX: ID 0489:e112 Foxconn / Hon Hai Bluetooth Radio Tested on Realtek 8851BE. Bluetooth works after this change is made. Signed-off-by: Techie Ernie <techieernie@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btqca: Add WCN6855 firmware priority selection featureShuai Zhang1-3/+18
Historically, WCN685x and QCA2066 shared the same firmware files. Now, changes are planned for the firmware that will make it incompatible with QCA2066, so a new firmware name is required for WCN685x. Test Steps: - Boot device - Check the BTFW loading status via dmesg Sanity pass and Test Log: QCA Downloading qca/wcnhpbftfw21.tlv Direct firmware load for qca/wcnhpbftfw21.tlv failed with error -2 QCA Downloading qca/hpbftfw21.tlv Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btqca: move WCN7850 workaround to the callerShuai Zhang1-20/+17
WCN7850 will first attempt to use ELF_TYPE_PATCH, and if that fails, it will fall back to TLV_TYPE_PATCH. To code uniformity, move WCN7850 workaround to the caller. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: L2CAP: Add support for setting BT_PHYLuiz Augusto von Dentz8-16/+259
This enables client to use setsockopt(BT_PHY) to set the connection packet type/PHY: Example setting BT_PHY_BR_1M_1SLOT: < HCI Command: Change Conne.. (0x01|0x000f) plen 4 Handle: 1 Address: 00:AA:01:01:00:00 (Intel Corporation) Packet type: 0x331e 2-DH1 may not be used 3-DH1 may not be used DM1 may be used DH1 may be used 2-DH3 may not be used 3-DH3 may not be used 2-DH5 may not be used 3-DH5 may not be used > HCI Event: Command Status (0x0f) plen 4 Change Connection Packet Type (0x01|0x000f) ncmd 1 Status: Success (0x00) > HCI Event: Connection Packet Typ.. (0x1d) plen 5 Status: Success (0x00) Handle: 1 Address: 00:AA:01:01:00:00 (Intel Corporation) Packet type: 0x331e 2-DH1 may not be used 3-DH1 may not be used DM1 may be used DH1 may be used 2-DH3 may not be used 3-DH3 may not be used 2-DH5 may not be used Example setting BT_PHY_LE_1M_TX and BT_PHY_LE_1M_RX: < HCI Command: LE Set PHY (0x08|0x0032) plen 7 Handle: 1 Address: 00:AA:01:01:00:00 (Intel Corporation) All PHYs preference: 0x00 TX PHYs preference: 0x01 LE 1M RX PHYs preference: 0x01 LE 1M PHY options preference: Reserved (0x0000) > HCI Event: Command Status (0x0f) plen 4 LE Set PHY (0x08|0x0032) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 6 LE PHY Update Complete (0x0c) Status: Success (0x00) Handle: 1 Address: 00:AA:01:01:00:00 (Intel Corporation) TX PHY: LE 1M (0x01) RX PHY: LE 1M (0x01) Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_sync: Add LE Channel Sounding HCI Command/event structuresNaga Bhavani Akella3-7/+367
1. Implement LE Event Mask to include events required for LE Channel Sounding 2. Enable Channel Sounding feature bit in the LE Host Supported Features command 3. Define HCI command and event structures necessary for LE Channel Sounding functionality Signed-off-by: Naga Bhavani Akella <naga.akella@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: mgmt: Add idle_timeout to configurable system parametersStefan Sørensen1-0/+21
While the configurable system parameters allow controlling the SNIFF mode parameters, they do not include the idle_timeout parameter responsible for enabling SNIFF mode. Add the idle_timeout parameter to allow controlling the idle timeout of BR/EDR connections. Signed-off-by: Stefan Sørensen <ssorensen@roku.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_conn: Set link_policy on incoming ACL connectionsStefan Sørensen2-2/+1
The connection link policy is only set when establishing an outgoing ACL connection causing connection idle modes not to be available on incoming connections. Move the setting of the link policy to the creation of the connection so all ACL connection will use the link policy set on the HCI device. Signed-off-by: Stefan Sørensen <ssorensen@roku.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_conn: use mod_delayed_work for active mode timeoutStefan Sørensen1-2/+2
hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan Sørensen <ssorensen@roku.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btmtksdio: Use pm_ptr instead of #ifdef CONFIG_PMUwe Kleine-König1-7/+1
This increases build coverage and allows to drop an #ifdef. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_bcm4377: Use generic power managementVaibhav Gupta1-4/+7
Switch to the generic PCI power management framework and remove legacy callbacks like .suspend() and .resume(). With the generic framework, the standard PCI related work like: - pci_save/restore_state() - pci_enable/disable_device() - pci_set_power_state() is handled by the PCI core and this driver should implement only hci_bcm4377 specific operations in its respective callback functions. Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: btusb: Add support for MediaTek7920 0489:e158Bluecross1-0/+2
Add support for MediaTek7920 0489:e158 /sys/kernel/debug/usb/devices reports for that device: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e158 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: Andrew Elatsev <elantsew.andrew@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_conn: Fix using conn->le_{tx,rx}_phy as supported PHYsLuiz Augusto von Dentz3-9/+40
conn->le_{tx,rx}_phy is not actually a bitfield as it set by HCI_EV_LE_PHY_UPDATE_COMPLETE it is actually correspond to the current PHY in use not what is supported by the controller, so this introduces different fields (conn->le_{tx,rx}_def_phys) to track what PHYs are supported by the connection. Fixes: eab2404ba798 ("Bluetooth: Add BT_PHY socket option") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up ↵Shuai Zhang1-0/+33
by hw On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw and cannot be controlled by the host. As a result, in case of a firmware crash, the host cannot trigger a cold reset. Instead, the BT controller performs a warm restart on its own, without reloading the firmware. This leads to the controller remaining in IBS_WAKE state, while the host expects it to be in sleep mode. The mismatch causes HCI reset commands to time out. Additionally, the driver does not clear internal flags QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence. If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag is not cleared, so only the first SSR generates a coredump. Tell the driver that the BT controller has undergone a proper restart sequence: - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR. - Add a 50ms delay to allow the controller to complete its warm reset. - Reset tx_idle_timer to prevent the host from entering TX sleep mode. - Clear memcoredump_flag to allow multiple coredump captures. Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set, which indicates that BT_EN is defined in DTS and cannot be toggled. Refer to the comment in include/net/bluetooth/hci.h for details on HCI_QUIRK_NON_PERSISTENT_SETUP. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-29Merge tag 'nf-next-26-01-29' of ↵Paolo Abeni6-81/+408
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next Florian Westphal says: ==================== netfilter: updates for net-next The following patchset contains Netfilter updates for *net-next*: Patches 1 to 4 add IP6IP6 tunneling acceleration to the flowtable infrastructure. Patch 5 extends test coverage for this. From Lorenzo Bianconi. Patch 6 removes a duplicated helper from xt_time extension, we can use an existing helper for this, from Jinjie Ruan. Patch 7 adds an rhashtable to nfnetink_queue to speed up out-of-order verdict processing. Before this list walk was required due to in-order design assumption. netfilter pull request nf-next-26-01-29 * tag 'nf-next-26-01-29' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: netfilter: nfnetlink_queue: optimize verdict lookup with hash table netfilter: xt_time: use is_leap_year() helper selftests: netfilter: nft_flowtable.sh: Add IP6IP6 flowtable selftest netfilter: flowtable: Add IP6IP6 tx sw acceleration netfilter: flowtable: Add IP6IP6 rx sw acceleration netfilter: Introduce tunnel metadata info in nf_flowtable_ctx struct netfilter: Add ctx pointer in nf_flow_skb_encap_protocol/nf_flow_ip4_tunnel_proto signature ==================== Link: https://patch.msgid.link/20260129105427.12494-1-fw@strlen.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-29netfilter: nfnetlink_queue: optimize verdict lookup with hash tableScott Mitchell2-30/+119
The current implementation uses a linear list to find queued packets by ID when processing verdicts from userspace. With large queue depths and out-of-order verdicting, this O(n) lookup becomes a significant bottleneck, causing userspace verdict processing to dominate CPU time. Replace the linear search with a hash table for O(1) average-case packet lookup by ID. A global rhashtable spanning all network namespaces attributes hash bucket memory to kernel but is subject to fixed upper bound. Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29netfilter: xt_time: use is_leap_year() helperJinjie Ruan1-6/+2
Use the is_leap_year() helper from rtc.h instead of writing it by hand Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29selftests: netfilter: nft_flowtable.sh: Add IP6IP6 flowtable selftestLorenzo Bianconi1-9/+53
Similar to IPIP, introduce specific selftest for IP6IP6 flowtable SW acceleration in nft_flowtable.sh Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29netfilter: flowtable: Add IP6IP6 tx sw accelerationLorenzo Bianconi1-2/+106
Introduce sw acceleration for tx path of IP6IP6 tunnels relying on the netfilter flowtable infrastructure. IP6IP6 tx sw acceleration can be tested running the following scenario where the traffic is forwarded between two NICs (eth0 and eth1) and an IP6IP6 tunnel is used to access a remote site (using eth1 as the underlay device): ETH0 -- TUN0 <==> ETH1 -- [IP network] -- TUN1 (2001:db8:3::2) $ip addr show 6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:00:22:33:11:55 brd ff:ff:ff:ff:ff:ff inet6 2001:db8:1::2/64 scope global nodad valid_lft forever preferred_lft forever 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:11:22:33:11:55 brd ff:ff:ff:ff:ff:ff inet6 2001:db8:2::1/64 scope global nodad valid_lft forever preferred_lft forever 8: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/tunnel6 2001:db8:2::1 peer 2001:db8:2::2 permaddr ce9c:2940:7dcc:: inet6 2002:db8:1::1/64 scope global nodad valid_lft forever preferred_lft forever $ip -6 route show 2001:db8:1::/64 dev eth0 proto kernel metric 256 pref medium 2001:db8:2::/64 dev eth1 proto kernel metric 256 pref medium 2002:db8:1::/64 dev tun0 proto kernel metric 256 pref medium default via 2002:db8:1::2 dev tun0 metric 1024 pref medium $nft list ruleset table inet filter { flowtable ft { hook ingress priority filter devices = { eth0, eth1 } } chain forward { type filter hook forward priority filter; policy accept; meta l4proto { tcp, udp } flow add @ft } } Reproducing the scenario described above using veths I got the following results: - TCP stream received from the IPIP tunnel: - net-next: (baseline) ~93Gbps - net-next + IP6IP6 flowtbale support: ~98Gbps Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29netfilter: flowtable: Add IP6IP6 rx sw accelerationLorenzo Bianconi2-13/+97
Introduce sw acceleration for rx path of IP6IP6 tunnels relying on the netfilter flowtable infrastructure. Subsequent patches will add sw acceleration for IP6IP6 tunnels tx path. IP6IP6 rx sw acceleration can be tested running the following scenario where the traffic is forwarded between two NICs (eth0 and eth1) and an IP6IP6 tunnel is used to access a remote site (using eth1 as the underlay device): ETH0 -- TUN0 <==> ETH1 -- [IP network] -- TUN1 (2001:db8:3::2) $ip addr show 6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:00:22:33:11:55 brd ff:ff:ff:ff:ff:ff inet6 2001:db8:1::2/64 scope global nodad valid_lft forever preferred_lft forever 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:11:22:33:11:55 brd ff:ff:ff:ff:ff:ff inet6 2001:db8:2::1/64 scope global nodad valid_lft forever preferred_lft forever 8: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/tunnel6 2001:db8:2::1 peer 2001:db8:2::2 permaddr ce9c:2940:7dcc:: inet6 2002:db8:1::1/64 scope global nodad valid_lft forever preferred_lft forever $ip -6 route show 2001:db8:1::/64 dev eth0 proto kernel metric 256 pref medium 2001:db8:2::/64 dev eth1 proto kernel metric 256 pref medium 2002:db8:1::/64 dev tun0 proto kernel metric 256 pref medium default via 2002:db8:1::2 dev tun0 metric 1024 pref medium $nft list ruleset table inet filter { flowtable ft { hook ingress priority filter devices = { eth0, eth1 } } chain forward { type filter hook forward priority filter; policy accept; meta l4proto { tcp, udp } flow add @ft } } Reproducing the scenario described above using veths I got the following results: - TCP stream received from the IPIP tunnel: - net-next: (baseline) ~ 81Gbps - net-next + IP6IP6 flowtbale support: ~112Gbps Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29netfilter: Introduce tunnel metadata info in nf_flowtable_ctx structLorenzo Bianconi1-16/+25
Add tunnel hdr_size and tunnel proto fields in nf_flowtable_ctx struct in order to store IP tunnel header size and protocol used during IPIP and IP6IP6 tunnel sw offloading decapsulation and avoid recomputing them during tunnel header pop since this is constant for IPv6. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29netfilter: Add ctx pointer in ↵Lorenzo Bianconi1-11/+12
nf_flow_skb_encap_protocol/nf_flow_ip4_tunnel_proto signature Rely on nf_flowtable_ctx struct pointer in nf_flow_ip4_tunnel_proto and nf_flow_skb_encap_protocol routine signature. This is a preliminary patch to introduce IP6IP6 flowtable acceleration since nf_flowtable_ctx will be used to store IP6IP6 tunnel info. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-29net: ethernet: neterion: s2io: remove unused driverEthan Nelson-Moore21-10911/+4
The s2io driver supports Exar (formerly Neterion and S2io) PCI-X 10 Gigabit Ethernet cards. Hardware supporting PCI-X has not been manufactured in years. On x86, it was quickly replaced by PCIe. While it stuck around longer on POWER hardware, the last POWER hardware to support it was POWER7, which is not supported by ppc64le Linux distributions. The last supported mainstream ppc64 Linux distribution was RHEL 7; while it is still supported under ELS, ELS is only available for x86 and IBM Z. It is possible to use many PCI-X cards in standard PCI slots (which are still available on new motherboards), but it does not make sense to do so for 10 Gigabit Ethernet because the maximum bandwidth of standard PCI is only 1067 Mbps. It is therefore highly unlikely that this driver is still being used. Remove the driver, and move the former maintainer to the CREDITS file (restoring credit for the vxge driver, which was removed in commit f05643a0f60b ("eth: remove neterion/vxge"). Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260126031352.22997-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-29ipv6: remove __inet6_csk_dst_check()Eric Dumazet1-7/+1
__inet6_csk_dst_check() is a very simple wrapper with no value, it is used only once. Directly use __sk_dst_check(). Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260127211203.1524339-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-29selftests: drv-net: toeplitz: accept bigger rss keysEric Dumazet1-1/+1
/proc/sys/net/core/netdev_rss_key got bigger (256 bytes instead of 52) Fixes: 37b0ea8fef56 ("net: expand NETDEV_RSS_KEY_LEN to 256 bytes") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260127174806.886561-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-01 12:50:29 +0300