* Re: [PATCH v6 1/2] dt-bindings: net: bluetooth: Add brcm,bcm4384-bt
From: Krzysztof Kozlowski @ 2026-05-20 11:19 UTC (permalink / raw)
To: kaihsin Chung, linux-bluetooth
Cc: marcel, luiz.von.dentz, linux-kernel, Kaihsin Chung
In-Reply-To: <20260520090131.3505676-2-kaihsin.chung@synaptics.com>
On 20/05/2026 11:01, kaihsin Chung wrote:
> From: Kaihsin Chung <kaihsin.chung@synaptics.com>
>
> Add the compatible string for the Broadcom BCM4384
> Bluetooth controller.
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.
You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.
Please kindly resend and include all necessary To/Cc entries.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
>
> Signed-off-by: Kaihsin Chung <kaihsin.chung@synaptics.com>
> ---
> .../bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> index 37cb39a3a62e..139d9b47329c 100644
> --- a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> +++ b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
> @@ -23,7 +23,7 @@ properties:
> - pci14e4,5fa0 # BCM4377
> - pci14e4,5f69 # BCM4378
> - pci14e4,5f71 # BCM4387
> -
Why?
> + - brcm,bcm4384-bt
> reg:
> maxItems: 1
>
I really doubt you tested it. What sort of bus is used for your device?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Loic Poulain @ 2026-05-20 11:01 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Loic Poulain
In-Reply-To: <20260520-monza-wireless-v1-0-9f6942310653@oss.qualcomm.com>
Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
Arduino VENTUNO Q board. The module is interfaced via LGA and is
compatible with the M.2 Key E.
Add wireless-lga-connector node using pcie-m2-e-connector binding,
connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
the Bluetooth interface.
Add pcie@1,0 downstream port node with pciclass,0604 compatible so
the pci-pwrctrl driver can acquire the power sequencer and enable
the M.2 slot before PCIe enumeration.
Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
(gpio56/gpio55) used by the power sequencer.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
--- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
@@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
enable-active-high;
startup-delay-us = <20000>;
};
+
+ wireless-lga-connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <&vdc_3v3>;
+ vpcie1v8-supply = <&vdc_1v8>;
+ w-disable1-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
+ w-disable2-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&nfa725b_default_state>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* WiFi/PCIe */
+ port@0 {
+ reg = <0>;
+
+ lga_pcie_ep: endpoint {
+ remote-endpoint = <&pcie_bridge_ep>;
+ };
+ };
+
+ /* Bluetooth/UART */
+ port@3 {
+ reg = <3>;
+
+ lga_uart_ep: endpoint {
+ remote-endpoint = <&uart10_ep>;
+ };
+ };
+ };
+ };
};
&cci1 {
@@ -408,6 +441,22 @@ pci@0,0 {
ranges;
reg = <0x010000 0x00 0x00 0x00 0x00>;
+ pcie@1,0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ compatible = "pciclass,0604";
+ bus-range = <0x00 0xff>;
+ ranges;
+ reg = <0x020800 0x00 0x00 0x00 0x00>;
+
+ port {
+ pcie_bridge_ep: endpoint {
+ remote-endpoint = <&lga_pcie_ep>;
+ };
+ };
+ };
+
pci@2,0 {
#address-cells = <3>;
#size-cells = <2>;
@@ -500,6 +549,12 @@ max98091_default: max98091-default-state {
bias-pull-up;
};
+ nfa725b_default_state: nfa725b-default-state {
+ pins = "gpio55", "gpio56";
+ function = "gpio";
+ bias-disable;
+ };
+
pcie1_default_state: pcie1-default-state {
wake-pins {
pins = "gpio21";
@@ -540,6 +595,16 @@ &uart7 {
status = "okay";
};
+&uart10 {
+ status = "okay";
+
+ port {
+ uart10_ep: endpoint {
+ remote-endpoint = <&lga_uart_ep>;
+ };
+ };
+};
+
&usb_1 {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Loic Poulain @ 2026-05-20 11:01 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Loic Poulain
In-Reply-To: <20260520-monza-wireless-v1-0-9f6942310653@oss.qualcomm.com>
For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable
is controlled by the W_DISABLE2# signal managed by the pcie-m2 power
sequencer rather than a dedicated BT enable GPIO.
When the serdev controller has an OF graph (indicating it is connected
to an M.2 connector), acquire the 'uart' pwrseq target from the
connector's power sequencer and use it to control BT power instead of
the bt-enable GPIO.
Also allocate bt_power unconditionally for all SOC types since the
pwrseq path is independent of the SOC type switch.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/bluetooth/hci_qca.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index b5439b9956cfb0497e6ba6ccd9ed61224d23a9dd..de5cba7b7f44e280a48dad5d670fa2758d3268d0 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1873,6 +1873,9 @@ static int qca_power_on(struct hci_dev *hdev)
/* Controller needs time to bootup. */
msleep(150);
}
+
+ if (qcadev->bt_power && qcadev->bt_power->pwrseq)
+ pwrseq_power_on(qcadev->bt_power->pwrseq);
}
clear_bit(QCA_BT_OFF, &qca->flags);
@@ -2415,25 +2418,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
else
qcadev->btsoc_type = QCA_ROME;
- switch (qcadev->btsoc_type) {
- case QCA_QCA6390:
- case QCA_WCN3950:
- case QCA_WCN3988:
- case QCA_WCN3990:
- case QCA_WCN3991:
- case QCA_WCN3998:
- case QCA_WCN6750:
- case QCA_WCN6855:
- case QCA_WCN7850:
- qcadev->bt_power = devm_kzalloc(&serdev->dev,
- sizeof(struct qca_power),
- GFP_KERNEL);
- if (!qcadev->bt_power)
- return -ENOMEM;
- break;
- default:
- break;
- }
+ qcadev->bt_power = devm_kzalloc(&serdev->dev, sizeof(struct qca_power), GFP_KERNEL);
+ if (!qcadev->bt_power)
+ return -ENOMEM;
switch (qcadev->btsoc_type) {
case QCA_WCN3950:
@@ -2543,7 +2530,13 @@ static int qca_serdev_probe(struct serdev_device *serdev)
return PTR_ERR(qcadev->bt_en);
}
- if (!qcadev->bt_en)
+ if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
+ qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");
+ if (IS_ERR(qcadev->bt_power->pwrseq))
+ return PTR_ERR(qcadev->bt_power->pwrseq);
+ }
+
+ if (!qcadev->bt_en && !qcadev->bt_power->pwrseq)
bt_en_available = false;
qcadev->susclk = devm_clk_get_optional_enabled_with_rate(
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] power: sequencing: pcie-m2: Add QCA2066 (QCNFA765) BT serdev ID
From: Loic Poulain @ 2026-05-20 11:01 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Loic Poulain
In-Reply-To: <20260520-monza-wireless-v1-0-9f6942310653@oss.qualcomm.com>
Add PCI device ID 17cb:1103 (Qualcomm QCA2066/QCNFA765) to the M.2
serdev ID table, mapping it to the qcom,qca2066-bt compatible string.
This allows the pwrseq-pcie-m2 driver to automatically create the
Bluetooth serdev device when a QCA2066-based M.2 card is enumerated.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index efeb25ba9c79e20fc8bc8354def8ae423d0f2f2e..f90df88c663985c7702c19911f0c147e3b68984b 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -188,6 +188,8 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
static const struct pci_device_id pwrseq_m2_pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1107),
.driver_data = (kernel_ulong_t)"qcom,wcn7850-bt" },
+ { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1103),
+ .driver_data = (kernel_ulong_t)"qcom,qca2066-bt" },
{ } /* Sentinel */
};
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: monaco-arduino-monza: Add support for LGA WiFi/BT module
From: Loic Poulain @ 2026-05-20 11:01 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Loic Poulain
This series describes support for the onboard WiFi/Bluetooth module
present on the Arduino VENTUNO Q (monaco) platform.
The board provides LGA pads for a wireless module. On the VENTUNO Q
these pads are populated with an NFA725B module featuring the
QCA2066 WiFi/BT combo chip. While implemented as an LGA footprint,
the design is functionally compatible with the M.2 Key E.
The NFA725B exposes WiFi over PCIe and Bluetooth over a UART.
Both interfaces are gated through the W_DISABLE1# and W_DISABLE2#
signals, as defined by the M.2 specification and handled here via
the pcie-m2 power sequencer.
This series models the hardware using the existing pwrseq framework
and connector bindings, allowing coordinated PCIe and UART bring-up.
Patch 1 registers the QCA2066 PCI device ID (17cb:1103) in the
pwrseq-pcie-m2 serdev ID table so the Bluetooth device is created
automatically when the PCIe function is enumerated.
Patch 2 updates hci_qca to retrieve the "uart" power sequencer
target via the OF graph and use it for Bluetooth power control
instead of a dedicated GPIO.
Patch 3 adds the required Device Tree description for the board.
This series depends on:
https://lore.kernel.org/linux-pci/20260507-pwrseq-m2-bt-v2-0-1740bd478539@oss.qualcomm.com
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Loic Poulain (3):
power: sequencing: pcie-m2: Add QCA2066 (QCNFA765) BT serdev ID
Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
drivers/bluetooth/hci_qca.c | 33 +++++-------
drivers/power/sequencing/pwrseq-pcie-m2.c | 2 +
3 files changed, 80 insertions(+), 20 deletions(-)
---
base-commit: aa61612ab641d7d62b0b6889f2c7c9251489f6e3
change-id: 20260520-monza-wireless-e6ce7f013f38
prerequisite-message-id: <20260507-pwrseq-m2-bt-v2-0-1740bd478539@oss.qualcomm.com>
prerequisite-patch-id: f4a7d1957c1776051608bf3d808b2786606c1ae2
prerequisite-patch-id: 6cd3c33583a9af16b3f6f71517b16b32d8155b7c
prerequisite-patch-id: 0550c57d69cf112fd4830e62f4388db6f8bf397c
prerequisite-patch-id: cc10d8079e37ef0ba0c33d0984c95d76361df9dd
prerequisite-patch-id: d7f4bb2bb4498ac619e67a94f8b59119a5caaf26
prerequisite-patch-id: c00ce9095b2d3a412229796194828b55642d3d96
prerequisite-patch-id: 09600595c2e80b12eda3aae39af192847d0f03d0
prerequisite-patch-id: a6118ed2894c176780ba933750e1068f2819fa4c
prerequisite-patch-id: 1dee41a33e032094e8dda74ac4e0bada928573d7
Best regards,
--
Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v6 2/2] Bluetooth: btbcm: Add Synaptics 4384 chip support
From: kaihsin Chung @ 2026-05-20 9:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.von.dentz, linux-kernel, Kaihsin Chung
In-Reply-To: <20260520090131.3505676-1-kaihsin.chung@synaptics.com>
From: Kaihsin Chung <kaihsin.chung@synaptics.com>
Add support for the Synaptics 4384 Bluetooth controller
by adding the corresponding chip IDs and device tree
matching support
Signed-off-by: Kaihsin Chung <kaihsin.chung@synaptics.com>
---
drivers/bluetooth/btbcm.c | 6 +++++-
drivers/bluetooth/hci_bcm.c | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index f9a7c790d7e2..1164cca40324 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -31,6 +31,7 @@
#define BDADDR_BCM4334B0 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb0, 0x34, 0x43}})
#define BDADDR_BCM4345C5 (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0xc5, 0x45, 0x43}})
#define BDADDR_BCM43341B (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0x1b, 0x34, 0x43}})
+#define BDADDR_BCM4384B0 (&(bdaddr_t) {{0x93, 0x76, 0x00, 0xb0, 0x84, 0x43}})
#define BCM_FW_NAME_LEN 64
#define BCM_FW_NAME_COUNT_MAX 4
@@ -130,7 +131,8 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
!bacmp(&bda->bdaddr, BDADDR_BCM4345C5) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43430A0) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43430A1) ||
- !bacmp(&bda->bdaddr, BDADDR_BCM43341B)) {
+ !bacmp(&bda->bdaddr, BDADDR_BCM43341B) ||
+ !bacmp(&bda->bdaddr, BDADDR_BCM4384B0)) {
/* Try falling back to BDADDR EFI variable */
if (btbcm_set_bdaddr_from_efi(hdev) != 0) {
bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
@@ -515,6 +517,8 @@ static const struct bcm_subver_table bcm_uart_subver_table[] = {
{ 0x4106, "BCM4335A0" }, /* 002.001.006 */
{ 0x410c, "BCM43430B0" }, /* 002.001.012 */
{ 0x2119, "BCM4373A0" }, /* 001.001.025 */
+ { 0x2128, "BCM4384A0" },/* 001.001.040 */
+ { 0x4119, "BCM4384B0"},/* 002.001.025 */
{ }
};
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 874d23089b39..783346a4a59b 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -1609,6 +1609,7 @@ static const struct of_device_id bcm_bluetooth_of_match[] = {
{ .compatible = "brcm,bcm4335a0" },
{ .compatible = "cypress,cyw4373a0-bt", .data = &cyw4373a0_device_data },
{ .compatible = "infineon,cyw55572-bt", .data = &cyw55572_device_data },
+ { .compatible = "brcm,bcm4384-bt" },
{ },
};
MODULE_DEVICE_TABLE(of, bcm_bluetooth_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH v6 1/2] dt-bindings: net: bluetooth: Add brcm,bcm4384-bt
From: kaihsin Chung @ 2026-05-20 9:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.von.dentz, linux-kernel, Kaihsin Chung
In-Reply-To: <20260520090131.3505676-1-kaihsin.chung@synaptics.com>
From: Kaihsin Chung <kaihsin.chung@synaptics.com>
Add the compatible string for the Broadcom BCM4384
Bluetooth controller.
Signed-off-by: Kaihsin Chung <kaihsin.chung@synaptics.com>
---
.../bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
index 37cb39a3a62e..139d9b47329c 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
@@ -23,7 +23,7 @@ properties:
- pci14e4,5fa0 # BCM4377
- pci14e4,5f69 # BCM4378
- pci14e4,5f71 # BCM4387
-
+ - brcm,bcm4384-bt
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/2] Add Synaptics BCM4384 Bluetooth support
From: kaihsin Chung @ 2026-05-20 9:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.von.dentz, linux-kernel, kaihsin Chung
In-Reply-To: <20260408083217.1915419-1-kaihsin.chung@synaptics.com>
This series adds support for the Synaptics BCM4384 Bluetooth
controller.
Patch 1 adds the DT compatible string.
Patch 2 adds Bluetooth driver support.
kaihsin Chung (2):
dt-bindings: net: bluetooth: Add brcm,bcm4384-bt
Bluetooth: btbcm: Add Synaptics 4384 chip support
.../bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml | 2 +-
drivers/bluetooth/btbcm.c | 6 +++++-
drivers/bluetooth/hci_bcm.c | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
--
2.43.0
^ permalink raw reply
* [Bug 221552] btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920) Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-20 7:58 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221552-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221552
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Artem S. Tashkinov (aros@gmx.com) ---
Are you sure this patch doesn't fix it for you?
https://lore.kernel.org/all/770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi/
Upcoming Linux 7.0.10 includes it.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-20 7:52 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |olle@vixit.nu
--- Comment #13 from Artem S. Tashkinov (aros@gmx.com) ---
*** Bug 221547 has been marked as a duplicate of this bug. ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221547] MT7902 Bluetooth: Failed to send wmt func ctrl (-22) regression in 6.18.31 and 6.12.32
From: bugzilla-daemon @ 2026-05-20 7:52 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221547-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221547
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from Artem S. Tashkinov (aros@gmx.com) ---
It's been queued in stable, either apply it immediately or wait for the next
stable release.
*** This bug has been marked as a duplicate of bug 221521 ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: 转发: 回复: About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4)
From: Chris Lu (陸稚泓) @ 2026-05-20 7:38 UTC (permalink / raw)
To: luiz.dentz@gmail.com, yjg0107@163.com; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <h8u6o3dq4p0sir056l06sja8.1779260604813@email.vivo.com>
On Wed, 2026-05-20 at 15:03 +0800, yjg0107 wrote:
Hi Luiz,
I received a question about the restrictions of HCI_CHANNEL_USER and
HCI_MAX_FRAME_SIZE. Since this involves changes related to Kernel HCI
layer, what's your view on relaxing HCI_MAX_FRAME_SIZE limit?
I saw that there was some discussion about this on bluez github, but it
seems there hasn't been any activity for a while. Would you suggest
they directly upload a patch they want and continue the discussion with
you?
>
> ---------- 转发的邮件 ----------
> 发件人：yjg0107 <yjg0107@163.com>
> 日期：2026年5月7日 17:55
> 主题：回复: About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4)
> 收件人："luiz.dentz" <luiz.dentz@gmail.com>
> 抄送：linux-bluetooth <linux-bluetooth@vger.kernel.org>
>
>
>
>
>
>
>
>
> Hi Vudentz,
>
> In the future, BT SIG will introduce the High Data Throughput (HDT),
> which may require transmit larger data size, not just 1024.
> So what's your opinions? Could kernel remove the limitation that
> HCI_CHANNEL_USER can not change MTU?
> Looking forward to your reply, thank you very much.
>
> B.R.
> Jigong Yin(殷吉功)
> ---------- 回复的原邮件 ----------
> 发件人：yjg0107 <yjg0107@163.com>
> 日期：2026年4月27日 14:40
> 主题：About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4)
> 收件人："luiz.dentz" <luiz.dentz@gmail.com>
> 抄送：linux-bluetooth <linux-bluetooth@vger.kernel.org>
>
>
>
>
>
>
>
>
> Hi Luiz,
>
> Question is same as https://github.com/bluez/bluez/issues/2073.
> About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4), you said that
> this will be fixed to enable user space changed, from #201 (comment).
> The patch commit is torvalds/linux@09572fc, right?
>
> However, why HCI_CHANNEL_USER type can not change MTU value? Google
> bluetooth aidl uses HCI_CHANNEL_USER type
> fromhttps://cs.android.com/android/platform/superproject/+/android-la
> test-
> release:hardware/interfaces/bluetooth/aidl/default/net_bluetooth_mgmt
> .cpp line 282.
>
> Could kernel remove the limitation that HCI_CHANNEL_USER can not
> change MTU?
>
> Thanks.
> B.R.
> Jigong Yin
>
>
>
> 发自vivo电子邮件
>
>
Best Regards,
Chris Lu
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
From: Shuai Zhang @ 2026-05-20 6:26 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
In-Reply-To: <CABBYNZLP+rBrjhdKJLE7N47Bg-g4-6E3vS3yZXvMKwYQ2rMcUA@mail.gmail.com>
Hi Luiz
On 4/29/2026 11:17 PM, Luiz Augusto von Dentz wrote:
> Hi Shuai,
>
> On Wed, Apr 29, 2026 at 8:12 AM Shuai Zhang
> <shuai.zhang@oss.qualcomm.com> wrote:
>> The Bluetooth host decides whether to download firmware by reading the
>> controller firmware download completion flag and firmware version
>> information.
>>
>> If a USB error occurs during the firmware download process (for example
>> due to a USB disconnect), the download is aborted immediately. An
>> incomplete firmware transfer does not cause the controller to set the
>> download completion flag, but the firmware version information may be
>> updated at an early stage of the download process.
> Hold on, if the download has been aborted then the version should be
> reverted, or rather just update once the firmware loading is complete,
> so this indicates there is a bug somewhere that needs fixing, not
> worked around.
>
>> In this case, after USB reconnection, the host attempts to re-download
>> the firmware because the download completion flag is not set. However,
>> since the controller reports the same firmware version as the target
>> firmware, the download is skipped. This ultimately results in the
>> firmware not being properly updated on the controller.
>>
>> This change removes the restriction that skips firmware download when
>> the versions are equal. It covers scenarios where the USB connection
>> can be disconnected at any time and ensures that firmware download can
>> be retriggered after USB reconnection, allowing the Bluetooth firmware
>> to be correctly and completely updated.
>>
>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>> ---
>> Changes v2:
>> - Update code comments and commit message to reflect the correct logic.
>> - Align the commit title with upstream conventions.
>> - Link v1
>> https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
>> ---
>> drivers/bluetooth/btusb.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index 572091e60..70abbabea 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
>> "firmware rome 0x%x build 0x%x",
>> rver_rom, rver_patch, ver_rom, ver_patch);
>>
>> - if (rver_rom != ver_rom || rver_patch <= ver_patch) {
>> + /* Allow rampatch when the patch version equals the firmware version.
>> + * A firmware download may be aborted by a transient USB error (e.g.
>> + * disconnect) after the controller updates version info but before
>> + * completion.
>> + * Allowing equal versions enables re-flashing during recovery.
>> + */
>> + if (rver_rom != ver_rom || rver_patch < ver_patch) {
> As I said above, this sounds more like a workaround. That said, I
> wonder why it would print an error if the version matches, it sounds
> to be that if the version matches it should just skip and consider it
> has been loaded already in case the actual problem is fixed by setting
> the new version only when loading has been completed.
>
>> bt_dev_err(hdev, "rampatch file version did not match with firmware");
>> err = -EINVAL;
>> goto done;
>> --
>> 2.34.1
Just checking if there are any updates on this
Thanks,
Shuai
>
^ permalink raw reply
* RE: Bluetooth: btmtk: remove extra copy in cmd array init
From: bluez.test.bot @ 2026-05-20 6:15 UTC (permalink / raw)
To: linux-bluetooth, liujiajia
In-Reply-To: <20260520021500.13504-1-liujiajia@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1097683
---Test result---
Test Summary:
CheckPatch PASS 0.63 seconds
GitLint PASS 0.28 seconds
SubjectPrefix PASS 0.10 seconds
BuildKernel PASS 26.60 seconds
CheckAllWarning PASS 29.08 seconds
CheckSparse PASS 28.09 seconds
BuildKernel32 PASS 26.71 seconds
TestRunnerSetup PASS 534.54 seconds
IncrementalBuild PASS 24.40 seconds
https://github.com/bluez/bluetooth-next/pull/219
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluetooth-next:master] BUILD SUCCESS 7db62a762f613961a9ed0582902abd0295a385e9
From: kernel test robot @ 2026-05-20 5:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
branch HEAD: 7db62a762f613961a9ed0582902abd0295a385e9 Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
elapsed time: 733m
configs tested: 177
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260520 gcc-8.5.0
arc randconfig-002-20260520 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm dove_defconfig gcc-15.2.0
arm randconfig-001-20260520 gcc-8.5.0
arm randconfig-002-20260520 gcc-8.5.0
arm randconfig-003-20260520 gcc-8.5.0
arm randconfig-004-20260520 gcc-8.5.0
arm sp7021_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260520 gcc-10.5.0
arm64 randconfig-002-20260520 gcc-10.5.0
arm64 randconfig-003-20260520 gcc-10.5.0
arm64 randconfig-004-20260520 gcc-10.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260520 gcc-10.5.0
csky randconfig-002-20260520 gcc-10.5.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260520 gcc-11.5.0
hexagon randconfig-002-20260520 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260520 clang-20
i386 buildonly-randconfig-002-20260520 clang-20
i386 buildonly-randconfig-003-20260520 clang-20
i386 buildonly-randconfig-004-20260520 clang-20
i386 buildonly-randconfig-005-20260520 clang-20
i386 buildonly-randconfig-006-20260520 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260520 clang-20
i386 randconfig-002-20260520 clang-20
i386 randconfig-003-20260520 clang-20
i386 randconfig-004-20260520 clang-20
i386 randconfig-005-20260520 clang-20
i386 randconfig-006-20260520 clang-20
i386 randconfig-007-20260520 clang-20
i386 randconfig-011 gcc-14
i386 randconfig-011-20260520 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260520 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260520 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260520 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260520 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260520 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260520 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260520 gcc-11.5.0
loongarch randconfig-002-20260520 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260520 gcc-11.5.0
nios2 randconfig-002-20260520 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260520 clang-23
parisc randconfig-002-20260520 clang-23
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260520 clang-23
powerpc randconfig-002-20260520 clang-23
powerpc64 randconfig-001-20260520 clang-23
powerpc64 randconfig-002-20260520 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv nommu_k210_sdcard_defconfig gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260520 gcc-8.5.0
sparc randconfig-002-20260520 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260520 gcc-8.5.0
sparc64 randconfig-002-20260520 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260520 gcc-8.5.0
um randconfig-002-20260520 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260520 gcc-14
x86_64 buildonly-randconfig-002-20260520 gcc-14
x86_64 buildonly-randconfig-003-20260520 gcc-14
x86_64 buildonly-randconfig-004-20260520 gcc-14
x86_64 buildonly-randconfig-005-20260520 gcc-14
x86_64 buildonly-randconfig-006-20260520 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260520 gcc-14
x86_64 randconfig-002-20260520 gcc-14
x86_64 randconfig-003-20260520 gcc-14
x86_64 randconfig-004-20260520 gcc-14
x86_64 randconfig-005-20260520 gcc-14
x86_64 randconfig-006-20260520 gcc-14
x86_64 randconfig-011-20260520 gcc-14
x86_64 randconfig-012-20260520 gcc-14
x86_64 randconfig-013-20260520 gcc-14
x86_64 randconfig-014-20260520 gcc-14
x86_64 randconfig-015-20260520 gcc-14
x86_64 randconfig-016-20260520 gcc-14
x86_64 randconfig-071-20260520 gcc-14
x86_64 randconfig-072-20260520 gcc-14
x86_64 randconfig-073-20260520 gcc-14
x86_64 randconfig-074-20260520 gcc-14
x86_64 randconfig-075-20260520 gcc-14
x86_64 randconfig-076-20260520 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260520 gcc-8.5.0
xtensa randconfig-002-20260520 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] Bluetooth: btmtk: remove extra copy in cmd array init
From: Jiajia Liu @ 2026-05-20 2:15 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jiajia Liu
In btmtk_setup_firmware_79xx, the data length indicated by wmt_params.dlen
in the cmd buffer is MTK_SEC_MAP_NEED_SEND_SIZE + 1. Except for the first
byte, the remaining length is MTK_SEC_MAP_NEED_SEND_SIZE. memcpy copied one
more byte to cmd + 1 than the remaining length. Align the length passed to
memcpy to avoid exceeding current section map.
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
drivers/bluetooth/btmtk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index ea7a031000cd..53cba71cb07f 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -188,7 +188,7 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
MTK_FW_ROM_PATCH_GD_SIZE +
MTK_FW_ROM_PATCH_SEC_MAP_SIZE * i +
MTK_SEC_MAP_COMMON_SIZE,
- MTK_SEC_MAP_NEED_SEND_SIZE + 1);
+ MTK_SEC_MAP_NEED_SEND_SIZE);
wmt_params.op = BTMTK_WMT_PATCH_DWNLD;
wmt_params.status = &status;
--
2.53.0
^ permalink raw reply related
* RE: [v4] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: bluez.test.bot @ 2026-05-19 19:50 UTC (permalink / raw)
To: linux-bluetooth, meatuni001
In-Reply-To: <20260519184821.18925-1-meatuni001@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1097567
---Test result---
Test Summary:
CheckPatch PASS 0.73 seconds
GitLint PASS 0.55 seconds
SubjectPrefix PASS 0.12 seconds
BuildKernel PASS 25.91 seconds
CheckAllWarning PASS 29.40 seconds
CheckSparse PASS 26.90 seconds
BuildKernel32 PASS 24.98 seconds
TestRunnerSetup PASS 526.66 seconds
TestRunner_rfcomm-tester PASS 63.53 seconds
IncrementalBuild PASS 24.66 seconds
https://github.com/bluez/bluetooth-next/pull/218
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v4] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Muhammad Bilal @ 2026-05-19 18:48 UTC (permalink / raw)
To: linux-bluetooth
Cc: netdev, linux-kernel, Marcel Holtmann, Luiz Augusto von Dentz,
Kees Cook, Jakub Kicinski, stable, Muhammad Bilal
In-Reply-To: <20260519042017.29564-1-meatuni001@gmail.com>
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr * and
immediately dereferences hdr->addr and hdr->ctrl without first
validating that skb->len is large enough to hold the header. A
remote device can send a crafted short RFCOMM frame over L2CAP to
trigger an out-of-bounds read before any session state is checked.
The FCS trimming code that follows compounds the problem:
skb->len--; skb->tail--;
If skb->len is already zero the decrement wraps to UINT_MAX, causing
skb_tail_pointer() to return a pointer far outside the skb and
producing a second out-of-bounds read when the FCS byte is consumed.
Replace the open-coded cast with skb_pull_data() which validates
skb->len against sizeof(*hdr) and advances skb->data atomically.
Save the original skb->data as frame_start before the pull so that
__check_fcs() receives the header bytes as required by the RFCOMM
FCS specification. Guard against a missing FCS byte with an explicit
skb->len < 1 check. Replace the unsafe skb->tail decrement and
skb_tail_pointer() call with a direct end-of-data index and skb_trim().
Note: SeungJu Cheon posted a related patch that adds equivalent
length checks inside the individual MCC sub-handlers
(rfcomm_recv_pn, rfcomm_recv_rpn, rfcomm_recv_rls, rfcomm_recv_msc,
rfcomm_recv_mcc). That fix and this one are complementary and
independent; neither subsumes the other.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
v4:
- Keep no-session comment and add blank line after header/len guard
v3:
- Replace open-coded cast with skb_pull_data() per Luiz's review
- Save frame_start before skb_pull_data(); pass it to __check_fcs()
to preserve correct FCS validation over the header bytes
- Replace skb->tail decrement with skb_trim() per Luiz's review
v2:
- Fix GitLint B3: replace tab with spaces in commit body
- Add Cc: stable@vger.kernel.org
---
net/bluetooth/rfcomm/core.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d11bd5337..e78ce11fa 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1741,7 +1741,8 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
struct sk_buff *skb)
{
- struct rfcomm_hdr *hdr = (void *) skb->data;
+ struct rfcomm_hdr *hdr;
+ u8 *frame_start;
u8 type, dlci, fcs;
if (!s) {
@@ -1750,14 +1751,21 @@ static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
return s;
}
+ frame_start = skb->data;
+ hdr = skb_pull_data(skb, sizeof(*hdr));
+ if (!hdr || skb->len < 1) {
+ kfree_skb(skb);
+ return s;
+ }
+
dlci = __get_dlci(hdr->addr);
type = __get_type(hdr->ctrl);
/* Trim FCS */
- skb->len--; skb->tail--;
- fcs = *(u8 *)skb_tail_pointer(skb);
+ fcs = skb->data[skb->len - 1];
+ skb_trim(skb, skb->len - 1);
- if (__check_fcs(skb->data, type, fcs)) {
+ if (__check_fcs(frame_start, type, fcs)) {
BT_ERR("bad checksum in packet");
kfree_skb(skb);
return s;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Luiz Augusto von Dentz @ 2026-05-19 18:25 UTC (permalink / raw)
To: Muhammad Bilal
Cc: linux-bluetooth, netdev, linux-kernel, Marcel Holtmann, Kees Cook,
Jakub Kicinski, stable
In-Reply-To: <20260519181749.15746-1-meatuni001@gmail.com>
Hi Muhammad,
On Tue, May 19, 2026 at 2:18 PM Muhammad Bilal <meatuni001@gmail.com> wrote:
>
> rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr * and
> immediately dereferences hdr->addr and hdr->ctrl without first
> validating that skb->len is large enough to hold the header. A
> remote device can send a crafted short RFCOMM frame over L2CAP to
> trigger an out-of-bounds read before any session state is checked.
>
> The FCS trimming code that follows compounds the problem:
>
> skb->len--; skb->tail--;
>
> If skb->len is already zero the decrement wraps to UINT_MAX, causing
> skb_tail_pointer() to return a pointer far outside the skb and
> producing a second out-of-bounds read when the FCS byte is consumed.
>
> Replace the open-coded cast with skb_pull_data() which validates
> skb->len against sizeof(*hdr) and advances skb->data atomically.
> Save the original skb->data as frame_start before the pull so that
> __check_fcs() receives the header bytes as required by the RFCOMM
> FCS specification. Guard against a missing FCS byte with an explicit
> skb->len < 1 check. Replace the unsafe skb->tail decrement and
> skb_tail_pointer() call with a direct end-of-data index and skb_trim().
>
> Note: SeungJu Cheon posted a related patch that adds equivalent
> length checks inside the individual MCC sub-handlers
> (rfcomm_recv_pn, rfcomm_recv_rpn, rfcomm_recv_rls, rfcomm_recv_msc,
> rfcomm_recv_mcc). That fix and this one are complementary and
> independent; neither subsumes the other.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
>
> ---
> v3:
> - Replace open-coded cast with skb_pull_data() per Luiz's review
> - Save frame_start before skb_pull_data(); pass it to __check_fcs()
> to preserve correct FCS validation over the header bytes
> - Replace skb->tail decrement with skb_trim() per Luiz's review
> v2:
> - Fix GitLint B3: replace tab with spaces in commit body
> - Add Cc: stable@vger.kernel.org
> ---
> net/bluetooth/rfcomm/core.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index d11bd5337..66eee8a86 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1741,23 +1741,29 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
> static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
> struct sk_buff *skb)
> {
> - struct rfcomm_hdr *hdr = (void *) skb->data;
> + struct rfcomm_hdr *hdr;
> + u8 *frame_start;
> u8 type, dlci, fcs;
>
> if (!s) {
> - /* no session, so free socket data */
Doesn't seem relevant to remove this comment.
> kfree_skb(skb);
> return s;
> }
>
> + frame_start = skb->data;
> + hdr = skb_pull_data(skb, sizeof(*hdr));
> + if (!hdr || skb->len < 1) {
> + kfree_skb(skb);
> + return s;
> + }
Add a empty line after if blocks.
> dlci = __get_dlci(hdr->addr);
> type = __get_type(hdr->ctrl);
>
> /* Trim FCS */
> - skb->len--; skb->tail--;
> - fcs = *(u8 *)skb_tail_pointer(skb);
> + fcs = skb->data[skb->len - 1];
> + skb_trim(skb, skb->len - 1);
>
> - if (__check_fcs(skb->data, type, fcs)) {
> + if (__check_fcs(frame_start, type, fcs)) {
> BT_ERR("bad checksum in packet");
> kfree_skb(skb);
> return s;
> --
> 2.54.0
Other than that looks good.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v3] Bluetooth: RFCOMM: add minimum length check in rfcomm_recv_frame
From: Muhammad Bilal @ 2026-05-19 18:17 UTC (permalink / raw)
To: linux-bluetooth
Cc: netdev, linux-kernel, Marcel Holtmann, Luiz Augusto von Dentz,
Kees Cook, Jakub Kicinski, stable, Muhammad Bilal
In-Reply-To: <20260519042017.29564-1-meatuni001@gmail.com>
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr * and
immediately dereferences hdr->addr and hdr->ctrl without first
validating that skb->len is large enough to hold the header. A
remote device can send a crafted short RFCOMM frame over L2CAP to
trigger an out-of-bounds read before any session state is checked.
The FCS trimming code that follows compounds the problem:
skb->len--; skb->tail--;
If skb->len is already zero the decrement wraps to UINT_MAX, causing
skb_tail_pointer() to return a pointer far outside the skb and
producing a second out-of-bounds read when the FCS byte is consumed.
Replace the open-coded cast with skb_pull_data() which validates
skb->len against sizeof(*hdr) and advances skb->data atomically.
Save the original skb->data as frame_start before the pull so that
__check_fcs() receives the header bytes as required by the RFCOMM
FCS specification. Guard against a missing FCS byte with an explicit
skb->len < 1 check. Replace the unsafe skb->tail decrement and
skb_tail_pointer() call with a direct end-of-data index and skb_trim().
Note: SeungJu Cheon posted a related patch that adds equivalent
length checks inside the individual MCC sub-handlers
(rfcomm_recv_pn, rfcomm_recv_rpn, rfcomm_recv_rls, rfcomm_recv_msc,
rfcomm_recv_mcc). That fix and this one are complementary and
independent; neither subsumes the other.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
v3:
- Replace open-coded cast with skb_pull_data() per Luiz's review
- Save frame_start before skb_pull_data(); pass it to __check_fcs()
to preserve correct FCS validation over the header bytes
- Replace skb->tail decrement with skb_trim() per Luiz's review
v2:
- Fix GitLint B3: replace tab with spaces in commit body
- Add Cc: stable@vger.kernel.org
---
net/bluetooth/rfcomm/core.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d11bd5337..66eee8a86 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1741,23 +1741,29 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
struct sk_buff *skb)
{
- struct rfcomm_hdr *hdr = (void *) skb->data;
+ struct rfcomm_hdr *hdr;
+ u8 *frame_start;
u8 type, dlci, fcs;
if (!s) {
- /* no session, so free socket data */
kfree_skb(skb);
return s;
}
+ frame_start = skb->data;
+ hdr = skb_pull_data(skb, sizeof(*hdr));
+ if (!hdr || skb->len < 1) {
+ kfree_skb(skb);
+ return s;
+ }
dlci = __get_dlci(hdr->addr);
type = __get_type(hdr->ctrl);
/* Trim FCS */
- skb->len--; skb->tail--;
- fcs = *(u8 *)skb_tail_pointer(skb);
+ fcs = skb->data[skb->len - 1];
+ skb_trim(skb, skb->len - 1);
- if (__check_fcs(skb->data, type, fcs)) {
+ if (__check_fcs(frame_start, type, fcs)) {
BT_ERR("bad checksum in packet");
kfree_skb(skb);
return s;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH BlueZ] media: use custom DBus timeouts only when remote side is waiting
From: Luiz Augusto von Dentz @ 2026-05-19 18:17 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <60b9da865b9beb482f914818c31866ebb00960f7.1779011736.git.pav@iki.fi>
Hi Pauli,
On Sun, May 17, 2026 at 5:59 AM Pauli Virtanen <pav@iki.fi> wrote:
>
> Under high system load (VM instance on boot) it's observed the 3 sec
> timeout BlueZ uses for BAP broadcast SetConfiguration may be missed by
> Wireplumber, as these are set up immediately on startup together with
> any other setup (eg ALSA) that may need time.
>
> There's no actual need for using a short custom timeout in BlueZ for
> this, as in this case there is no remote side that is waiting for a reply.
>
> Fix by limiting custom timeouts to cases where there is a waiting
> remote. A2DP-specific timeout should be used only for A2DP
> SetConfiguration. Similarly, using timeout for BAP only makes sense for
> unicast, and should derive from the ATT timeout.
> ---
> profiles/audio/media.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/profiles/audio/media.c b/profiles/audio/media.c
> index cdaafb04e..0297e4c79 100644
> --- a/profiles/audio/media.c
> +++ b/profiles/audio/media.c
> @@ -71,7 +71,11 @@
> #define MEDIA_ENDPOINT_INTERFACE "org.bluez.MediaEndpoint1"
> #define MEDIA_PLAYER_INTERFACE "org.mpris.MediaPlayer2.Player"
>
> -#define REQUEST_TIMEOUT (3 * 1000) /* 3 seconds */
> +/* Timeout should be less than avdtp request timeout (4 seconds) */
> +#define A2DP_REQUEST_TIMEOUT_MSEC (3 * 1000)
> +
> +/* Timeout should be less than ATT timeout (30 seconds) */
> +#define BAP_REQUEST_TIMEOUT_MSEC (20 * 1000)
Is there any particular reason for this to be so long? We don't have
any custom timeout other than ATT, in the other hand, I'd rather not
wait 20 seconds for the endpoint to respond. 3 seconds might be too
short depending on the environment but in a real environment, even one
second to respond sounds plenty. Perhaps we should only use such a
high timeout if testing has been set which hints that the environment
may have been modified to allow the testing harness.
>
> struct media_app {
> struct media_adapter *adapter;
> @@ -465,16 +469,16 @@ static gboolean media_endpoint_async_call(DBusMessage *msg,
> struct media_transport *transport,
> media_endpoint_cb_t cb,
> void *user_data,
> - GDestroyNotify destroy)
> + GDestroyNotify destroy,
> + int timeout_msec)
> {
> struct endpoint_request *request;
>
> request = g_new0(struct endpoint_request, 1);
>
> - /* Timeout should be less than avdtp request timeout (4 seconds) */
> if (g_dbus_send_message_with_reply(btd_get_dbus_connection(),
> msg, &request->call,
> - REQUEST_TIMEOUT) == FALSE) {
> + timeout_msec) == FALSE) {
> error("D-Bus send failed");
> g_free(request);
> return FALSE;
> @@ -521,7 +525,7 @@ static gboolean select_configuration(struct media_endpoint *endpoint,
> DBUS_TYPE_INVALID);
>
> return media_endpoint_async_call(msg, endpoint, NULL,
> - cb, user_data, destroy);
> + cb, user_data, destroy, -1);
> }
>
> static int transport_device_cmp(gconstpointer data, gconstpointer user_data)
> @@ -604,7 +608,8 @@ static gboolean set_configuration(struct media_endpoint *endpoint,
> g_dbus_get_properties(conn, path, "org.bluez.MediaTransport1", &iter);
>
> return media_endpoint_async_call(msg, endpoint, transport,
> - cb, user_data, destroy);
> + cb, user_data, destroy,
> + A2DP_REQUEST_TIMEOUT_MSEC);
> }
> #endif
>
> @@ -1093,7 +1098,7 @@ static int pac_select(struct bt_bap_pac *lpac, struct bt_bap_pac *rpac,
> dbus_message_iter_close_container(&iter, &dict);
>
> if (!media_endpoint_async_call(msg, endpoint, NULL, pac_select_cb,
> - data, free))
> + data, free, -1))
> return -EIO;
>
> return 0;
> @@ -1233,6 +1238,7 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
> DBusMessage *msg;
> DBusMessageIter iter;
> const char *path;
> + int timeout_msec;
>
> DBG("endpoint %p stream %p", endpoint, stream);
>
> @@ -1243,9 +1249,11 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
> switch (bt_bap_stream_get_type(stream)) {
> case BT_BAP_STREAM_TYPE_UCAST:
> transport = pac_ucast_config(stream, cfg, endpoint);
> + timeout_msec = BAP_REQUEST_TIMEOUT_MSEC;
> break;
> case BT_BAP_STREAM_TYPE_BCAST:
> transport = pac_bcast_config(stream, cfg, endpoint);
> + timeout_msec = -1;
> break;
> default:
> transport = NULL;
> @@ -1279,7 +1287,8 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
> g_dbus_get_properties(conn, path, "org.bluez.MediaTransport1", &iter);
>
> if (!media_endpoint_async_call(msg, endpoint, transport,
> - pac_config_cb, data, free))
> + pac_config_cb, data, free,
> + timeout_msec))
> return -EIO;
>
> return 0;
> --
> 2.54.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: [RFC] Bluetooth: btusb: wait for rx_work before freeing data on disconnect
From: bluez.test.bot @ 2026-05-19 17:51 UTC (permalink / raw)
To: linux-bluetooth, kernel
In-Reply-To: <20260519154431.13471-1-kernel@phwe.de>
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1097482
---Test result---
Test Summary:
CheckPatch PASS 0.83 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.52 seconds
CheckAllWarning PASS 27.59 seconds
CheckSparse PASS 26.62 seconds
BuildKernel32 PASS 24.53 seconds
TestRunnerSetup PASS 529.44 seconds
IncrementalBuild PASS 24.21 seconds
https://github.com/bluez/bluetooth-next/pull/217
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221547] MT7902 Bluetooth: Failed to send wmt func ctrl (-22) regression in 6.18.31 and 6.12.32
From: bugzilla-daemon @ 2026-05-19 17:39 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221547-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221547
--- Comment #2 from ljotom (olle@vixit.nu) ---
Yes, the patch fixes the issue for me as well. Device: Foxconn/Hon Hai
0489:e0f5 (MT7902). Tested on Arch Linux with linux-lts 6.12.32, manually
applied the patch and rebuilt the kernel. Bluetooth works correctly, no "Failed
to send wmt func ctrl (-22)" in dmesg.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-14
From: August Wikerfors @ 2026-05-19 17:37 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Greg KH
Cc: Thorsten Leemhuis, stable@vger.kernel.org, Sasha Levin,
linux-bluetooth, netdev, davem, kuba,
Linux kernel regressions list, Linus Torvalds
In-Reply-To: <CABBYNZKzWgL3nmeA=CtN9s80LRyDiJ97aQXgvfSm9vYUBw_SpA@mail.gmail.com>
On 2026-05-19 17:49, Luiz Augusto von Dentz wrote:
> Hi Greg,
>
> On Tue, May 19, 2026 at 11:19 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> On Tue, May 19, 2026 at 09:44:39AM -0400, Luiz Augusto von Dentz wrote:
>>> Hi Greg,
>>>
>>> On Tue, May 19, 2026 at 8:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Tue, May 19, 2026 at 12:53:49PM +0200, Thorsten Leemhuis wrote:
>>>>> On 5/19/26 12:30, Greg KH wrote:
>>>>>> On Tue, May 19, 2026 at 09:04:38AM +0200, Thorsten Leemhuis wrote:
>>>>>>> On 5/15/26 17:10, Thorsten Leemhuis wrote:
>>>>>>>> On 5/14/26 19:23, Luiz Augusto von Dentz wrote:
>>>>>>>>
>>>>>>>>> The following changes since commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac:
>>>>>>>>> net: phy: DP83TC811: add reading of abilities (2026-05-14 15:17:12 +0200)
>>>>>>>>>
>>>>>>>>> are available in the Git repository at:
>>>>>>>>>
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-14
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to 375ba7484132662a4a8c7547d088fb6275c00282:
>>>>>>>>>
>>>>>>>>> Bluetooth: hci_qca: Convert timeout from jiffies to ms (2026-05-14 09:58:08 -0400)
>>>>>>>>
>>>>>>>> It seems this PR sadly came too late for this week's net PR to mainline
>>>>>>>> that was merged yesterday.
>>>>>>>>
>>>>>>>> TWIMC, from my point of view, it would be great if we somehow could
>>>>>>>> still get the changes from this PR or at least the btmtk fix it
>>>>>>>> contains[1] to mainline this week before -rc4, as it is fixing a
>>>>>>>> regression known since 2026-04-24 that at least five people encountered
>>>>>>>> with mainline since -rc3 due to 634a4408c0615c ("Bluetooth: btmtk:
>>>>>>>> validate WMT event SKB length before struct access") [006b9943b982 in
>>>>>>>> -next].
>>>>>>>
>>>>>>> Greg, Sasha, that [1] fix I was talking about now reached -next as
>>>>>>> 162b1adeb057d2 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL
>>>>>>> events") and will likely hit mainline on Thursday or so with the weekly
>>>>>>> -net PR to -mainline. If that's good enough for you, I'd say it would be
>>>>>>> good to pick this up for the next round of stable kernels.
>>>>>>
>>>>>> That "Fixes:" tag is referring to something that is also not in any
>>>>>> tree, but that commit does have a cc: stable in it. So do we need both
>>>>>> of these:
>>>>>
>>>>> Valid question, as yes, there is a slight mixup here:
>>>>>
>>>>>> 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before struct access")
>>>>>
>>>>> That is already in v7.0.7, v6.18.30, v6.12.88, as 041e88fb0c08 is the
>>>>> -next commit-id for mainline commit-id 634a4408c0615c ("Bluetooth:
>>>>> btmtk: validate WMT event SKB length before struct access") -- the one
>>>>> that is causing the regression that I want to get fixed. So we now only
>>>>> need:
>>>>>
>>>>>> 162b1adeb057 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events")
>>>>
>>>> Ok, but that "Fixes:" tag pointing to an invalid commit is going to be a
>>>> nightmare to track over time, ugh.
>>>
>>> Hmm, did we get the wrong hash or something? Usually, that would show
>>> up in the verify-fixes.sh, but perhaps it didn't capture it this time
>>> for some reason, perhaps I'm running an outdated version or something
>>> similar.
>>
>> Something went wrong if we ended up with a patch in the stable trees,
>> yet this fix is referring to it as a different git sha. Don't know
>> where the disconnect happend :(
>
> 041e88fb0c08 ("Bluetooth: btmtk: validate WMT event SKB length before
> struct access")
>
> I don't have that in any of our tree either, this is actually
> 634a4408c061 on all trees in the chain:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=634a4408c061
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=634a4408c061
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=634a4408c061
>
> Or actually that was the hash before it got rebased on bluetooth-next tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=041e88fb0c08
>
> But I didn't send the PR from that three so perhaps somebody else sent
> it to stable with the wrong fixes tag?
I believe the confusion comes from "Bluetooth: btmtk: accept too short
WMT FUNC_CTRL events" itself currently having different commit hashes in
bluetooth (e3ac0d9f1a20) and bluetooth-next (162b1adeb057). The former
correctly refers to "Bluetooth: btmtk: validate WMT event SKB length
before struct access" as 634a4408c061 in the Fixes tag and was merged
into net yesterday heading for 7.1-rc5. The latter still refers to it as
041e88fb0c08. Both are now in next-20260519 but only the latter was in
next-20260518 which was the latest at the time of Thorsten's message.
Greg, this means picking e3ac0d9f1a20 instead of 162b1adeb057 should
result in a valid Fixes tag.
Regards,
August Wikerfors
^ permalink raw reply
* [Bug 221552] New: btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920) Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-19 17:29 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=221552
Bug ID: 221552
Summary: btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920)
Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does
not cover this PID
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: blocking
Priority: P3
Component: Bluetooth
Assignee: linux-bluetooth@vger.kernel.org
Reporter: gagnieux.virgil@proton.me
Regression: No
Created attachment 310159
--> https://bugzilla.kernel.org/attachment.cgi?id=310159&action=edit
dmesg kernel (from 7.0.9-hardened1-1-hardened)
Regression: Bluetooth controller fails to initialise on a MediaTek MT7921
(Legion Pro 5 16ADR10, Realtek-branded module) since kernel 7.0.7.
Last known good: 7.0.6. Same dmesg symptom as the regression already
patched for USB ID 0489:e0e2, but the fix does NOT resolve it for this
device (USB 0e8d:e020), which suggests the patch missed a code path or
device-ID entry.
Hardware
--------
lspci -nnk:
03:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7920]
DeviceName: Realtek
Subsystem: Lenovo Device [17aa:e020]
Kernel driver in use: mt7921e
lsusb:
Bus 003 Device 006: ID 0e8d:e020 MediaTek Inc. Wireless_Device
Kernels tested
--------------
7.0.6 : Bluetooth works
7.0.8 / 7.0.9 (mainline) : broken
7.0.9-hardened1-1 : broken (linux-hardened — current)
This build includes the backport
https://github.com/anthraxx/linux-hardened/commit/<…81d80fcd09>
which adds the fix for USB ID 0489:e0e2. It does NOT fix 0e8d:e020.
uname -r : 7.0.9-hardened1-1-hardened
dmesg (from kernel 7.0.9, relevant lines)
-----------------------------------------
[ 23.898011] Bluetooth: Core ver 2.22
[ 23.898032] NET: Registered PF_BLUETOOTH protocol family
[ 23.898033] Bluetooth: HCI device and connection manager initialized
[ 23.898041] Bluetooth: HCI socket layer initialized
[ 23.898043] Bluetooth: L2CAP socket layer initialized
[ 23.898045] Bluetooth: SCO socket layer initialized
[ 24.800153] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time:
20260224111231
[ 24.922472] Bluetooth: hci0: Failed to send wmt func ctrl (-22)
[ 24.922477] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection
command is advertised, but not supported.
[ 25.517793] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 25.517796] Bluetooth: BNEP filters: protocol multicast
[ 25.517800] Bluetooth: BNEP socket layer initialized
Userspace state
---------------
bluetoothctl list → (no output)
bluetoothctl show → No default controller available
Module
------
modinfo btmtk:
filename:
/lib/modules/7.0.9-hardened1-1-hardened/kernel/drivers/bluetooth/btmtk.ko.zst
firmware: mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin
firmware: mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
firmware: mediatek/mt7668pr2h.bin
Versions (Arch Linux)
---------------------
linux-firmware : 20260410-1
linux-firmware-mediatek : 20260410-1
bluez : 5.86-6
Steps to reproduce
------------------
1. Boot kernel >= 7.0.7 on a system with MediaTek 14c3:7920 / USB 0e8d:e020.
2. Bluetooth controller fails to initialise; -EINVAL (-22) on wmt func ctrl.
Expected
--------
Controller comes up, same as on 7.0.6.
Related
-------
- Arch forum thread: https://bbs.archlinux.org/viewtopic.php?id=313552
- Same symptom, different PID 0489:e0d8:
https://bbs.archlinux.org/viewtopic.php?id=313561
- Existing fix that targets 0489:e0e2 only:
https://github.com/anthraxx/linux-hardened/commit/d019930b0049fc2648a6b279893d8ad330596e81
(does not cover USB ID 0e8d:e020 — a second device-ID / code-path entry
appears to be needed)
I can test patches.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox