Fan Gong [Thu, 29 Jan 2026 04:01:08 +0000 (12:01 +0800)]
hinic3: Fix code Style(remove empty lines between error handling)
According to previous review comment, fix code style of removing empty
lines between the actions on the error handling path to make it more
idiomatic in the merged code.
Geetha sowjanya [Tue, 27 Jan 2026 12:51:47 +0000 (18:21 +0530)]
octeontx2-af: Workaround SQM/PSE stalls by disabling sticky
NIX SQ manager sticky mode is known to cause stalls when multiple SQs
share an SMQ and transmit concurrently. Additionally, PSE may deadlock
on transitions between sticky and non-sticky transmissions. There is
also a credit drop issue observed when certain condition clocks are
gated.
work around these hardware errata by:
- Disabling SQM sticky operation:
- Clear TM6 (bit 15)
- Clear TM11 (bit 14)
- Disabling sticky → non-sticky transition path that can deadlock PSE:
- Clear TM5 (bit 23)
- Preventing credit drops by keeping the control-flow clock enabled:
- Set TM9 (bit 21)
These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this
configuration the SQM/PSE maintain forward progress under load without
credit loss, at the cost of disabling sticky optimizations.
The test_rss_flow_label_6only test case fails on devices that do not
support IPv6 flow label hashing. Make it skip neatly, consistent with
the behavior of the test_rss_flow_label case.
====================
net: stmmac: rk: second chunk of cleanups
This series is a cut-down installment of the dwmac-rk cleanups, covering
up to the point that the AI review had its first issue with the patches.
Unfortunately, this means that we introduce ->init but do not add any
users for it yet. That will be in the next round once this has got
through AI review and merged.
====================
All the definitions of the RGMII related xxx_GMAC_CLK_xxx definitions
use the same field values to select the clock rate. Provide common
definitions for these field values, passing them in to a single macro
for each variant that generates the appropriate values for the speed
register.
rk_gmac_setup() delves into the PHY's DT node to retrieve its reset
control using of_reset_control_get(). However, it never releases it
when the driver is removed. Add reset_control_put() to rk_gmac_exit()
to clean this up.
net: phylink: fix NULL pointer deref in phylink_major_config()
When a MAC driver returns a PCS for an interface mode, and then we
attempt to switch to a different mode that doesn't require a PCS,
this causes phylink to oops:
This is caused by "pcs" being NULL when we attempt to execute:
pcs->phylink = pl;
Make this conditional on pcs being non-null.
Fixes: 486dc391ef43 ("net: phylink: allow mac_select_pcs() to remove a PCS") Reported-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vl39Q-00000006utm-229h@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Report the active PHY interface from the point of view of the dwmac
hardware to the kernel log, where the core supports reading this.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1vl36F-00000006url-1fWA@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In commit 9b443e58a896 ("net: stmmac: qcom-ethqos: remove MAC_CTRL_REG
modification"), ethqos->mac_base is only written, never read. Let's
remove it.
Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vl39x-00000006uvc-0A3S@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ivan Vecera [Mon, 26 Jan 2026 16:22:51 +0000 (17:22 +0100)]
dpll: expose fractional frequency offset in ppt
Currently, the dpll subsystem exports the fractional frequency offset
(FFO) in parts per million (ppm). This granularity is insufficient for
high-precision synchronization scenarios which often require parts per
trillion (ppt) resolution.
Add a new netlink attribute DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT
to expose the FFO in ppt.
Update the dpll netlink core to expect the driver-provided FFO value
to be in ppt. To maintain backward compatibility with existing userspace
tools, populate the legacy DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET
attribute by dividing the new ppt value by 1,000,000.
Update the zl3073x and mlx5 drivers to provide the FFO value in ppt:
- zl3073x: adjust the fixed-point calculation to produce ppt (10^12)
instead of ppm (10^6).
- mlx5: scale the existing ppm value by 1,000,000.
Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260126162253.27890-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Andre Carvalho [Tue, 27 Jan 2026 19:39:20 +0000 (19:39 +0000)]
netconsole: selftests: Move netconsole selftests to separate target
This patch moves netconsole selftests from drivers/net to its own target
in drivers/net/netconsole.
This change helps saving some resources from CI since tests in
drivers/net automatically run against real hardware which are not used
by netconsole tests as they rely solely on netdevsim.
lib_netcons.sh is kept under drivers/net/lib since it is also used by
bonding selftests. Finally, drivers/net config remains unchanged as
netpoll_basic.py requires netconsole (and does leverage real HW testing).
Jakub Kicinski [Fri, 30 Jan 2026 01:22:35 +0000 (17:22 -0800)]
Merge tag 'for-net-next-2026-01-29' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Luiz Augusto von Dentz says:
====================
bluetooth-next pull request for net-next:
core:
- L2CAP: Add support for setting BT_PHY
- HCI: Add LE Channel Sounding HCI Command/event structures
- hci_conn: Set link_policy on incoming ACL connections
- MGMT: Add idle_timeout to configurable system parameters
drivers:
- btusb: Add support for MediaTek7920 0489:e158
- btusb: Add device ID for Realtek RTL8761BU
- btusb: Reject autosuspend if discovery is active
- btusb: Add new VID/PID for RTL8852CE
- btusb: Add USB ID 0489:e112 for Realtek 8851BE
- dt-bindings: qcom: Split to separate schema
- btqca: Add WCN6855 firmware priority selection feature
* tag 'for-net-next-2026-01-29' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (40 commits)
Bluetooth: hci_qca: Enable HFP hardware offload for WCN6855 and WCN7850
Bluetooth: hci_qca: Refactor HFP hardware offload capability handling
Bluetooth: btusb: Add USB ID 7392:e611 for Edimax EW-7611UXB
Bluetooth: L2CAP: Fix not tracking outstanding TX ident
Bluetooth: MGMT: Fix memory leak in set_ssp_complete
Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
Bluetooth: btusb: Remove duplicate entry for 0x13d3/0x3618
Bluetooth: btusb: Add device ID for Realtek RTL8761BU
Bluetooth: btintel: Remove unneeded CONFIG_PM* #ifdef's
Bluetooth: btnxpuart: Remove unneeded CONFIG_PM ifdef
Bluetooth: btusb: Add new VID/PID for RTL8852CE
Bluetooth: btintel_pcie: Remove unnecessary check before kfree_skb()
Bluetooth: btusb: Reject autosuspend if discovery is active
Bluetooth: hci_core: Export hci_discovery_active
Bluetooth: btusb: Use pm_ptr instead of #ifdef CONFIG_PM
dt-bindings: bluetooth: qcom,wcn7850-bt: Deprecate old supplies
dt-bindings: bluetooth: qcom,wcn7850-bt: Split to separate schema
dt-bindings: bluetooth: qcom,wcn6855-bt: Deprecate old supplies
dt-bindings: bluetooth: qcom,wcn6855-bt: Split to separate schema
dt-bindings: bluetooth: qcom,wcn6750-bt: Deprecate old supplies
...
====================
Mengshi Wu [Tue, 27 Jan 2026 02:54:23 +0000 (10:54 +0800)]
Bluetooth: hci_qca: Enable HFP hardware offload for WCN6855 and WCN7850
Add QCA_CAP_HFP_HW_OFFLOAD capability flag to WCN6855 and WCN7850
device data structures to enable Hands-Free Profile (HFP) hardware
offload support on these Qualcomm Bluetooth chipsets.
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>
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>
Bluetooth: L2CAP: Fix not tracking outstanding TX ident
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.
Jianpeng Chang [Wed, 21 Jan 2026 05:29:26 +0000 (13:29 +0800)]
Bluetooth: MGMT: Fix memory leak in set_ssp_complete
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>
Jia-Hong Su [Sun, 18 Jan 2026 12:08:59 +0000 (20:08 +0800)]
Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
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.
Linmao Li [Wed, 21 Jan 2026 02:52:20 +0000 (10:52 +0800)]
Bluetooth: btusb: Remove duplicate entry for 0x13d3/0x3618
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>
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>
Linmao Li [Fri, 9 Jan 2026 02:05:38 +0000 (10:05 +0800)]
Bluetooth: btusb: Reject autosuspend if discovery is active
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>
Bastien Nocera [Mon, 12 Jan 2026 10:51:13 +0000 (11:51 +0100)]
Bluetooth: btusb: Use pm_ptr instead of #ifdef CONFIG_PM
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>
dt-bindings: bluetooth: qcom,wcn7850-bt: Deprecate old supplies
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>
dt-bindings: bluetooth: qcom,wcn7850-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,wcn6855-bt: Deprecate old supplies
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>
dt-bindings: bluetooth: qcom,wcn6855-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,wcn6750-bt: Deprecate old supplies
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>
dt-bindings: bluetooth: qcom,wcn6750-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,wcn3990-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,wcn3950-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,qca6390-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,qca9377-bt: Split to separate schema
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>
dt-bindings: bluetooth: qcom,qca2066-bt: Split to separate schema
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>
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>
Techie Ernie [Wed, 24 Dec 2025 03:31:29 +0000 (11:31 +0800)]
Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BE
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>
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>
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>
Bluetooth: hci_sync: Add LE Channel Sounding HCI Command/event structures
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>
Stefan Sørensen [Tue, 16 Dec 2025 09:20:11 +0000 (10:20 +0100)]
Bluetooth: mgmt: Add idle_timeout to configurable system parameters
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>
Stefan Sørensen [Tue, 16 Dec 2025 09:20:10 +0000 (10:20 +0100)]
Bluetooth: hci_conn: Set link_policy on incoming ACL connections
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>
Stefan Sørensen [Tue, 16 Dec 2025 09:20:09 +0000 (10:20 +0100)]
Bluetooth: hci_conn: use mod_delayed_work for active mode timeout
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>
Vaibhav Gupta [Wed, 10 Dec 2025 23:21:09 +0000 (23:21 +0000)]
Bluetooth: hci_bcm4377: Use generic power management
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>
Bluetooth: hci_conn: Fix using conn->le_{tx,rx}_phy as supported PHYs
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>
Shuai Zhang [Wed, 3 Dec 2025 03:37:12 +0000 (11:37 +0800)]
Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up 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>
Linus Torvalds [Thu, 29 Jan 2026 17:07:17 +0000 (09:07 -0800)]
Merge tag 'for-6.19-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- fix leaked folio refcount on s390x when using hw zlib compression
acceleration
- remove own threshold from ->writepages() which could collide with
cgroup limits and lead to a deadlock when metadadata are not written
because the amount is under the internal limit
* tag 'for-6.19-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: zlib: fix the folio leak on S390 hardware acceleration
btrfs: do not strictly require dirty metadata threshold for metadata writepages
Paolo Abeni [Thu, 29 Jan 2026 13:56:13 +0000 (14:56 +0100)]
Merge tag 'nf-next-26-01-29' of 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
====================
Jibin Zhang [Mon, 26 Jan 2026 15:21:11 +0000 (23:21 +0800)]
net: fix segmentation of forwarding fraglist GRO
This patch enhances GSO segment handling by properly checking
the SKB_GSO_DODGY flag for frag_list GSO packets, addressing
low throughput issues observed when a station accesses IPv4
servers via hotspots with an IPv6-only upstream interface.
Specifically, it fixes a bug in GSO segmentation when forwarding
GRO packets containing a frag_list. The function skb_segment_list
cannot correctly process GRO skbs that have been converted by XLAT,
since XLAT only translates the header of the head skb. Consequently,
skbs in the frag_list may remain untranslated, resulting in protocol
inconsistencies and reduced throughput.
To address this, the patch explicitly sets the SKB_GSO_DODGY flag
for GSO packets in XLAT's IPv4/IPv6 protocol translation helpers
(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO
packets as potentially modified after protocol translation. As a
result, GSO segmentation will avoid using skb_segment_list and
instead falls back to skb_segment for packets with the SKB_GSO_DODGY
flag. This ensures that only safe and fully translated frag_list
packets are processed by skb_segment_list, resolving protocol
inconsistencies and improving throughput when forwarding GRO packets
converted by XLAT.
Paolo Abeni [Thu, 29 Jan 2026 12:21:35 +0000 (13:21 +0100)]
Merge tag 'wireless-2026-01-29' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Just one fix, for a parsing error in mac80211 that might
result in a one byte out-of-bounds read.
* tag 'wireless-2026-01-29' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
wifi: mac80211: correctly decode TTLM with default link map
====================
Benjamin Berg [Thu, 29 Jan 2026 10:33:50 +0000 (11:33 +0100)]
wifi: mac80211: correctly decode TTLM with default link map
TID-To-Link Mapping (TTLM) elements do not contain any link mapping
presence indicator if a default mapping is used and parsing needs to be
skipped.
Note that access points should not explicitly report an advertised TTLM
with a default mapping as that is the implied mapping if the element is
not included, this is even the case when switching back to the default
mapping. However, mac80211 would incorrectly parse the frame and would
also read one byte beyond the end of the element.
Reported-by: Ruikai Peng <ruikai@pwno.io> Closes: https://lore.kernel.org/linux-wireless/CAFD3drMqc9YWvTCSHLyP89AOpBZsHdZ+pak6zVftYoZcUyF7gw@mail.gmail.com Fixes: 702e80470a33 ("wifi: mac80211: support handling of advertised TID-to-link mapping") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20260129113349.d6b96f12c732.I69212a50f0f70db185edd3abefb6f04d3cb3e5ff@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Scott Mitchell [Fri, 23 Jan 2026 22:09:30 +0000 (14:09 -0800)]
netfilter: nfnetlink_queue: optimize verdict lookup with hash table
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>
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):
$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
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>
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):
$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
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>
Lorenzo Bianconi [Thu, 22 Jan 2026 17:46:14 +0000 (18:46 +0100)]
netfilter: Introduce tunnel metadata info in nf_flowtable_ctx struct
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>
Lorenzo Bianconi [Thu, 22 Jan 2026 17:46:13 +0000 (18:46 +0100)]
netfilter: Add ctx pointer in 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>
====================
mptcp: avoid dup NL events and propagate error
Here are two fixes affecting the MPTCP Netlink events with their tests:
- Patches 1 & 2: a subflow closed NL event was visible multiple times in
some specific conditions. A fix for v5.12.
- Patches 3 & 4: subflow closed NL events never contained the error
code, even when expected. A fix for v5.11.
Plus an extra fix:
- Patch 5: fix a false positive with the "signal addresses race test"
subtest when validating the MPTCP Join selftest on a v5.15.y stable
kernel.
====================
selftests: mptcp: join: fix local endp not being tracked
When running this mptcp_join.sh selftest on older kernel versions not
supporting local endpoints tracking, this test fails because 3 MP_JOIN
ACKs have been received, while only 2 were expected.
It is not clear why only 2 MP_JOIN ACKs were expected on old kernel
versions, while 3 MP_JOIN SYN and SYN+ACK were expected. When testing on
the v5.15.197 kernel, 3 MP_JOIN ACKs are seen, which is also what is
expected in the selftests included in this kernel version, see commit f4480eaad489 ("selftests: mptcp: add missing join check").
Switch the expected MP_JOIN ACKs to 3. While at it, move this
chk_join_nr helper out of the special condition for older kernel
versions as it is now the same as with more recent ones. Also, invert
the condition to be more logical: what's expected on newer kernel
versions having such helper first.
Fixes: d4c81bbb8600 ("selftests: mptcp: join: support local endpoint being tracked or not") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260127-net-mptcp-dup-nl-events-v1-5-7f71e1bc4feb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
selftests: mptcp: check subflow errors in close events
This validates the previous commit: subflow closed events should contain
an error field when a subflow got closed with an error, e.g. reset or
timeout.
For this test, the chk_evt_nr helper has been extended to check
attributes in the matched events.
In this test, the 2 subflow closed events should have an error.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
Some subflow socket errors need to be reported to the MPTCP socket: the
initial subflow connect (MP_CAPABLE), and the ones from the fallback
sockets. The others are not propagated.
The issue is that sock_error() was used to retrieve the error, which was
also resetting the sk_err field. Because of that, when notifying the
userspace about subflow close events later on from the MPTCP worker, the
ssk->sk_err field was always 0.
Now, the error (sk_err) is only reset when propagating it to the msk.
selftests: mptcp: check no dup close events after error
This validates the previous commit: subflow closed events are re-sent
with less info when the initial subflow is disconnected after an error
and each time a subflow is closed after that.
In this new test, the userspace PM is involved because that's how it was
discovered, but it is not specific to it. The initial subflow is
terminated with a RESET, and that will cause the subflow disconnect.
Then, a new subflow is initiated, but also got rejected, which cause a
second subflow closed event, but not a third one.
While at it, in case of failure to get the expected amount of events,
the events are printed.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.
mptcp: avoid dup SUB_CLOSED events after disconnect
In case of subflow disconnect(), which can also happen with the first
subflow in case of errors like timeout or reset, mptcp_subflow_ctx_reset
will reset most fields from the mptcp_subflow_context structure,
including close_event_done. Then, when another subflow is closed, yet
another SUB_CLOSED event for the disconnected initial subflow is sent.
Because of the previous reset, there are no source address and
destination port.
A solution is then to also check the subflow's local id: it shouldn't be
negative anyway.
Another solution would be not to reset subflow->close_event_done at
disconnect time, but when reused. But then, probably the whole reset
could be done when being reused. Let's not change this logic, similar
to TCP with tcp_disconnect().
Jianbo Liu [Tue, 27 Jan 2026 08:52:41 +0000 (10:52 +0200)]
net/mlx5e: Skip ESN replay window setup for IPsec crypto offload
Commit a5e400a985df ("net/mlx5e: Honor user choice of IPsec replay
window size") introduced logic to setup the ESN replay window size.
This logic is only valid for packet offload.
However, the check to skip this block only covered outbound offloads.
It was not skipped for crypto offload, causing it to fall through to
the new switch statement and trigger its WARN_ON default case (for
instance, if a window larger than 256 bits was configured).
Fix this by amending the condition to also skip the replay window
setup if the offload type is not XFRM_DEV_OFFLOAD_PACKET.
Fixes: a5e400a985df ("net/mlx5e: Honor user choice of IPsec replay window size") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1769503961-124173-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Parav Pandit [Tue, 27 Jan 2026 08:52:40 +0000 (10:52 +0200)]
net/mlx5: Fix vhca_id access call trace use before alloc
HCA CAP structure is allocated in mlx5_hca_caps_alloc().
mlx5_mdev_init()
mlx5_hca_caps_alloc()
And HCA CAP is read from the device in mlx5_init_one().
The vhca_id's debugfs file is published even before above two
operations are done.
Due to this when user reads the vhca id before the initialization,
following call trace is observed.
Fix this by deferring debugfs publication until the HCA CAP is
allocated and read from the device.
Shay Drory [Tue, 27 Jan 2026 08:52:38 +0000 (10:52 +0200)]
net/mlx5: fs, Fix inverted cap check in tx flow table root disconnect
The capability check for reset_root_to_default was inverted, causing
the function to return -EOPNOTSUPP when the capability IS supported,
rather than when it is NOT supported.
Fix the capability check condition.
Fixes: 3c9c34c32bc6 ("net/mlx5: fs, Command to control TX flow table root") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1769503961-124173-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wei Fang [Mon, 26 Jan 2026 08:15:44 +0000 (16:15 +0800)]
net: phy: micrel: fix clk warning when removing the driver
Since the commit 25c6a5ab151f ("net: phy: micrel: Dynamically control
external clock of KSZ PHY"), the clock of Micrel PHY has been enabled
by phy_driver::resume() and disabled by phy_driver::suspend(). However,
devm_clk_get_optional_enabled() is used in kszphy_probe(), so the clock
will automatically be disabled when the device is unbound from the bus.
Therefore, this could cause the clock to be disabled twice, resulting
in clk driver warnings.
For example, this issue can be reproduced on i.MX6ULL platform, and we
can see the following logs when removing the FEC MAC drivers.
$ echo 2188000.ethernet > /sys/bus/platform/drivers/fec/unbind
$ echo 20b4000.ethernet > /sys/bus/platform/drivers/fec/unbind
[ 109.758207] ------------[ cut here ]------------
[ 109.758240] WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0xb4/0xd0, CPU#0: sh/639
[ 109.771011] enet2_ref already disabled
[ 109.793359] Call trace:
[ 109.822006] clk_core_disable from clk_disable+0x28/0x34
[ 109.827340] clk_disable from clk_disable_unprepare+0xc/0x18
[ 109.833029] clk_disable_unprepare from devm_clk_release+0x1c/0x28
[ 109.839241] devm_clk_release from devres_release_all+0x98/0x100
[ 109.845278] devres_release_all from device_unbind_cleanup+0xc/0x70
[ 109.851571] device_unbind_cleanup from device_release_driver_internal+0x1a4/0x1f4
[ 109.859170] device_release_driver_internal from bus_remove_device+0xbc/0xe4
[ 109.866243] bus_remove_device from device_del+0x140/0x458
[ 109.871757] device_del from phy_mdio_device_remove+0xc/0x24
[ 109.877452] phy_mdio_device_remove from mdiobus_unregister+0x40/0xac
[ 109.883918] mdiobus_unregister from fec_enet_mii_remove+0x40/0x78
[ 109.890125] fec_enet_mii_remove from fec_drv_remove+0x4c/0x158
[ 109.896076] fec_drv_remove from device_release_driver_internal+0x17c/0x1f4
[ 109.962748] WARNING: drivers/clk/clk.c:1047 at clk_core_unprepare+0xfc/0x13c, CPU#0: sh/639
[ 109.975805] enet2_ref already unprepared
[ 110.002866] Call trace:
[ 110.031758] clk_core_unprepare from clk_unprepare+0x24/0x2c
[ 110.037440] clk_unprepare from devm_clk_release+0x1c/0x28
[ 110.042957] devm_clk_release from devres_release_all+0x98/0x100
[ 110.048989] devres_release_all from device_unbind_cleanup+0xc/0x70
[ 110.055280] device_unbind_cleanup from device_release_driver_internal+0x1a4/0x1f4
[ 110.062877] device_release_driver_internal from bus_remove_device+0xbc/0xe4
[ 110.069950] bus_remove_device from device_del+0x140/0x458
[ 110.075469] device_del from phy_mdio_device_remove+0xc/0x24
[ 110.081165] phy_mdio_device_remove from mdiobus_unregister+0x40/0xac
[ 110.087632] mdiobus_unregister from fec_enet_mii_remove+0x40/0x78
[ 110.093836] fec_enet_mii_remove from fec_drv_remove+0x4c/0x158
[ 110.099782] fec_drv_remove from device_release_driver_internal+0x17c/0x1f4
After analyzing the process of removing the FEC driver, as shown below,
it can be seen that the clock was disabled twice by the PHY driver.
fec_drv_remove()
--> fec_enet_close()
--> phy_stop()
--> phy_suspend()
--> kszphy_suspend() #1 The clock is disabled
--> fec_enet_mii_remove()
--> mdiobus_unregister()
--> phy_mdio_device_remove()
--> device_del()
--> devm_clk_release() #2 The clock is disabled again
Therefore, devm_clk_get_optional() is used to fix the above issue. And
to avoid the issue mentioned by the commit 985329462723 ("net: phy:
micrel: use devm_clk_get_optional_enabled for the rmii-ref clock"), the
clock is enabled by clk_prepare_enable() to get the correct clock rate.
Fixes: 25c6a5ab151f ("net: phy: micrel: Dynamically control external clock of KSZ PHY") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260126081544.983517-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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").
Daniel Zahka [Mon, 26 Jan 2026 19:38:17 +0000 (11:38 -0800)]
net/mlx5e: don't assume psp tx skbs are ipv6 csum handling
mlx5e_psp_handle_tx_skb() assumes skbs are ipv6 when doing a partial
TCP checksum with tso. Make correctly mlx5e_psp_handle_tx_skb() handle
ipv4 packets.
Jakub Kicinski [Thu, 29 Jan 2026 03:40:54 +0000 (19:40 -0800)]
Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2026-01-27 (ixgbe, ice)
For ixgbe:
Kohei Enju adjusts the cleanup path on firmware error to resolve some
memory leaks and removes an instance of double init, free on ACI mutex.
For ice:
Aaron Ma adds NULL checks for q_vectors to avoid NULL pointer
dereference.
Jesse Brandeburg removes UDP checksum mismatch from being counted in Rx
errors.
* '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
ice: stop counting UDP csum mismatch as rx_errors
ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues
ixgbe: don't initialize aci lock in ixgbe_recovery_probe()
ixgbe: fix memory leaks in the ixgbe_recovery_probe() path
====================
Daniel Zahka [Tue, 27 Jan 2026 16:30:55 +0000 (08:30 -0800)]
selftests: drv-net: psp: fix test flakes from racy connection close
There is a bug in assoc_sk_only_mismatch() and
assoc_sk_only_mismatch_tx() that creates a race condition which
triggers test flakes in later test cases e.g. data_send_bad_key().
The problem is that the client uses the "conn clr" rpc to setup a data
connection with psp_responder, but never uses a matching "data close"
rpc. This creates a race condition where if the client can queue
another data sock request, like in data_send_bad_key(), before the
server can accept the old connection from the backlog we end up in a
situation where we have two connections in the backlog: one for the
closed connection we have received a FIN for, and one for the new PSP
connection which is expecting to do key exchange.
From there the server pops the closed connection from the backlog, but
the data_send_bad_key() test case in psp.py hangs waiting to perform
key exchange.
The fix is to properly use _conn_close, which fill force the server to
remove the closed connection from the backlog before sending the RPC
ack to the client.
Passing IRQF_ONESHOT ensures that the interrupt source is masked until
the secondary (threaded) handler is done. If only a primary handler is
used then the flag makes no sense because the interrupt can not fire
(again) while its handler is running.
The flag also disallows force-threading of the primary handler and the
irq-core will warn about this as of commit aef30c8d569c0 ("genirq: Warn
about using IRQF_ONESHOT without a threaded handler").
The IRQF_ONESHOT flag was added in commit 0fabe1021f8bc ("MIPS:
DECstation I/O ASIC DMA interrupt classes"). It moved
clear_ioasic_dma_irq() from the driver into the irq-chip.
For EOI interrupts the clear_ioasic_dma_irq() callback is now invoked as
->irq_eoi() which is invoked after the IRQ was handled while the
interrupt is masked due to IRQF_ONESHOT. Without IRQF_ONESHOT it would
be invoked while interrupt is unmasked (but interrupts are disabled).
If it is *required* to invoke EOI-ack while the interrupt is masked (and
not a misunderstanding) due to irq-chip cascading/ hierarchical reasons
then using handle_fasteoi_mask_irq() as flow-handler would be the right
way to do so.
Remove IRQF_ONESHOT to irqflags.
Cc: Andrew Lunn <andrew+netdev@lunn.ch> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/20260127135334.qUEaYP9G@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test tcp_tx_timestamp() behavior after ("tcp: tcp_tx_timestamp()
must look at the rtx queue").
Without the fix, this new test fails like this:
tcp_timestamping_tcp_tx_timestamp_bug.pkt:55: runtime error in recvmsg call: Expected result 0 but got -1 with errno 11 (Resource temporarily unavailable)
Martin Kaiser [Tue, 27 Jan 2026 10:19:23 +0000 (11:19 +0100)]
net: bridge: fix static key check
Fix the check if netfilter's static keys are available. netfilter defines
and exports static keys if CONFIG_JUMP_LABEL is enabled. (HAVE_JUMP_LABEL
is never defined.)
Fixes: 971502d77faa ("bridge: netfilter: unroll NF_HOOK helper in bridge input path") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Florian Westphal <fw@strlen.de> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260127101925.1754425-1-martin@kaiser.cx Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260127043528.514160-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
nfc: nci: Fix race between rfkill and nci_unregister_device().
syzbot reported the splat below [0] without a repro.
It indicates that struct nci_dev.cmd_wq had been destroyed before
nci_close_device() was called via rfkill.
nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which
(I think) was called from virtual_ncidev_close() when syzbot close()d
an fd of virtual_ncidev.
The problem is that nci_unregister_device() destroys nci_dev.cmd_wq
first and then calls nfc_unregister_device(), which removes the
device from rfkill by rfkill_unregister().
So, the device is still visible via rfkill even after nci_dev.cmd_wq
is destroyed.
Let's unregister the device from rfkill first in nci_unregister_device().
Note that we cannot call nfc_unregister_device() before
nci_close_device() because
1) nfc_unregister_device() calls device_del() which frees
all memory allocated by devm_kzalloc() and linked to
ndev->conn_info_list
2) nci_rx_work() could try to queue nci_conn_info to
ndev->conn_info_list which could be leaked
Thus, nfc_unregister_device() is split into two functions so we
can remove rfkill interfaces only before nci_close_device().
projects / thirdparty / kernel / linux.git / log
