* RE: [v2] Bluetooth: btusb: Add USB ID 13d3:3625 for MediaTek MT7922
From: bluez.test.bot @ 2026-06-25 10:16 UTC (permalink / raw)
To: linux-bluetooth, monesss315
In-Reply-To: <20260625083230.300651-1-monesss315@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1449 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=1116370
---Test result---
Test Summary:
CheckPatch PASS 1.08 seconds
VerifyFixes PASS 0.27 seconds
VerifySignedoff PASS 0.21 seconds
GitLint FAIL 0.52 seconds
SubjectPrefix PASS 0.24 seconds
BuildKernel PASS 27.04 seconds
CheckAllWarning PASS 29.69 seconds
CheckSparse PASS 29.46 seconds
BuildKernel32 PASS 26.30 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 500.16 seconds
IncrementalBuild PASS 25.76 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v2] Bluetooth: btusb: Add USB ID 13d3:3625 for MediaTek MT7922
63: B1 Line exceeds max length (82>80): " - Add /sys/kernel/debug/usb/devices output to the commit message (Paul Menzel)"
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/351
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v2] Bluetooth: btusb: Add USB ID 13d3:3625 for MediaTek MT7922
From: Gustavo Evgucci @ 2026-06-25 8:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Marcel Holtmann
Cc: linux-bluetooth, linux-kernel, Paul Menzel, Gustavo Evgucci
In-Reply-To: <20260623114937.6385-1-monesss315@gmail.com>
The IMC Networks MT7922 Bluetooth adapter with USB ID 13d3:3625 is not
recognized as a MediaTek device because it is missing from the btusb
device ID table. As a result, btmtk firmware loading is never triggered
and the HCI reset command times out with -ETIMEDOUT.
Add the device with BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH flags,
consistent with the neighboring 13d3:3627, 13d3:3628 and 13d3:3630
entries which use the same chip.
Tested on: MediaTek MT7922 (Wi-Fi 6E combo card, IMC Networks BT USB
interface), kernel 7.0.11-arch1-1.
/sys/kernel/debug/usb/devices:
T: Bus=01 Lev=01 Prnt=01 Port=12 Cnt=03 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3625 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Signed-off-by: Gustavo Evgucci <monesss315@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
Notes:
v2:
- Add /sys/kernel/debug/usb/devices output to the commit message (Paul Menzel)
- Add Reviewed-by: Paul Menzel
- Resend to all maintainers from scripts/get_maintainer.pl
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7f14ce9..f829203 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -798,6 +798,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3613), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3625), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3627), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3628), .driver_info = BTUSB_MEDIATEK |
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: virtio_bt: fix cleanup paths
From: Dan Carpenter @ 2026-06-25 8:06 UTC (permalink / raw)
To: Haoxiang Li
Cc: marcel, luiz.dentz, yangyingliang, mst, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <20260625020159.3446736-1-haoxiang_li2024@163.com>
On Thu, Jun 25, 2026 at 10:01:59AM +0800, Haoxiang Li wrote:
> virtbt_probe() registers the HCI device before opening the virtio
> Bluetooth device. If virtbt_open_vdev() fails, the error path frees
> the HCI device without unregistering it first. The probe error paths
> also leak the virtio_bluetooth structure after it has been allocated.
>
> Rework the probe error handling into an unwind ladder so each failure
> path releases the resources acquired earlier. Also close the virtio
> device before unregistering the HCI device in virtbt_remove(), matching
> the cleanup order used by the probe failure path.
>
> Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver")
> Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> Changes in v2:
> - Rework virtbt_probe() error paths into an unwind ladder.
> - Free vbt on probe failures.
> - Reset the virtio device and unregister the HCI device before freeing it
> when virtbt_open_vdev() fails.
> - Close the virtio device before unregistering the HCI device in remove().
>
> Thanks Dan for the suggestions. The blog is very helpful.
> ---
> drivers/bluetooth/virtio_bt.c | 23 ++++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
> index 140ab55c9fc5..4ca9b76f6410 100644
> --- a/drivers/bluetooth/virtio_bt.c
> +++ b/drivers/bluetooth/virtio_bt.c
> @@ -311,12 +311,12 @@ static int virtbt_probe(struct virtio_device *vdev)
>
> err = virtio_find_vqs(vdev, VIRTBT_NUM_VQS, vbt->vqs, vqs_info, NULL);
> if (err)
> - return err;
> + goto err_free_vbt;
>
> hdev = hci_alloc_dev();
> if (!hdev) {
> err = -ENOMEM;
> - goto failed;
> + goto err_del_vqs;
> }
>
> vbt->hdev = hdev;
> @@ -383,23 +383,28 @@ static int virtbt_probe(struct virtio_device *vdev)
> if (virtio_has_feature(vdev, VIRTIO_BT_F_AOSP_EXT))
> hci_set_aosp_capable(hdev);
>
> - if (hci_register_dev(hdev) < 0) {
> - hci_free_dev(hdev);
> + err = hci_register_dev(hdev);
> + if (err < 0) {
> err = -EBUSY;
> - goto failed;
> + goto err_free_hdev;
> }
>
> virtio_device_ready(vdev);
> err = virtbt_open_vdev(vbt);
> if (err)
> - goto open_failed;
> + goto err_reset_vdev;
>
> return 0;
>
> -open_failed:
> +err_reset_vdev:
> + virtio_reset_device(vdev);
I'm not sure that this reset is necessary. I suspect that it isn't,
but I don't know for sure. In a situation like this, I'd probably
err on the side of only fixing things which I know and leaving the
rest as a leak or whatever.
Otherwise it looks correct to me.
regards,
dan carpenter
^ permalink raw reply
* RE: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-06-25 7:25 UTC (permalink / raw)
To: Frank Li (OSS)
Cc: Sherry Sun (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Amitkumar Karwar,
Neeraj Sanjay Kale, marcel@holtmann.org, luiz.dentz@gmail.com,
Hongxing Zhu, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <ajwOvZUlOEQzmjsu@SMW015318>
> Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
>
> On Wed, Jun 24, 2026 at 07:09:26AM +0000, Sherry Sun wrote:
> > > Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag
> > > support
> > >
> > > On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > > > From: Sherry Sun <sherry.sun@nxp.com>
> > > >
> > > > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices
> > > > during suspend to preserve wakeup capability of the devices and
> > > > also not to power on the devices in the init path.
> > > > This allows controller power-off to be skipped when some devices(e.g.
> > > > M.2 cards key E without auxiliary power) required to support PCIe
> > > > L2 link state and wake-up mechanisms.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pci-imx6.c | 36
> > > > +++++++++++++++++----------
> > > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > > index 0fa716d1ed75..ff5a9565dbbf 100644
> > > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct
> > > > dw_pcie_rp
> > > *pp)
> > > > }
> > > > }
> > > >
> > > > - ret = pci_pwrctrl_create_devices(dev);
> > > > - if (ret) {
> > > > - dev_err(dev, "failed to create pwrctrl devices\n");
> > > > - goto err_reg_disable;
> > > > + if (!pci->suspended) {
> > > > + ret = pci_pwrctrl_create_devices(dev);
> > >
> > > Is possible move pci_pwrctrl_create_devices() of
> > > pci_pwrctrl_create_devices
> > >
> > > and call it direct at probe() function, like other regulator_get function.
> > >
> >
> > Hi Frank,
> > That makes sense. However, if we move pci_pwrctrl_create_devices () to
> > probe(), we may need to add the following goto err_pwrctrl_destroy
> > path in imx_pcie_probe() to properly handle errors from
> > pci_pwrctrl_power_on_devices(), is that acceptable?
>
> Can you add a API devm_pci_pwrctrl_create_devices() ?
>
Hi Frank, we cannot unconditionally destroy the pwrctrl devices
when probing fails by using devm API.
Since we need to check the return value of
pci_pwrctrl_power_on_devices() for example EPROBE_DEFER to decide
whether to destroy the pwrctrl devices to avoid the deferred probe loop.
You can find more related discussion here.
https://lore.kernel.org/all/tutxwjciedqoje5wxvtin4h637auni5zzpvb7rtfg4uticxoux@yfl6xg7oht7t/
Best Regards
Sherry
>
> >
> > @@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct
> platform_device *pdev)
> > if (ret)
> > return ret;
> >
> > + ret = pci_pwrctrl_create_devices(dev);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "failed to create
> > + pwrctrl devices\n");
> > +
> > pci->use_parent_dt_ranges = true;
> > if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> > ret = imx_add_pcie_ep(imx_pcie, pdev);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > /*
> > * FIXME: Only single Device (EPF) is supported due to
> > the @@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct
> platform_device *pdev)
> > pci->pp.use_atu_msg = true;
> > ret = dw_pcie_host_init(&pci->pp);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > if (pci_msi_enabled()) {
> > u8 offset = dw_pcie_find_capability(pci,
> > PCI_CAP_ID_MSI); @@ -1991,6 +1984,11 @@ static int
> imx_pcie_probe(struct platform_device *pdev)
> > }
> >
> > return 0;
> > +
> > +err_pwrctrl_destroy:
> > + if (ret != -EPROBE_DEFER)
> > + pci_pwrctrl_destroy_devices(dev);
> > + return ret;
> > }
> >
> > Best Regards
> > Sherry
> >
> > >
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to create pwrctrl devices\n");
> > > > + goto err_reg_disable;
> > > > + }
> > > > }
> > > >
> > > > - ret = pci_pwrctrl_power_on_devices(dev);
> > > > - if (ret) {
> > > > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > > > - goto err_pwrctrl_destroy;
> > > > + if (!pp->skip_pwrctrl_off) {
> > > > + ret = pci_pwrctrl_power_on_devices(dev);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > > > + goto err_pwrctrl_destroy;
> > > > + }
> > > > }
> > > >
> > > > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> > > static
> > > > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > > > err_clk_disable:
> > > > imx_pcie_clk_disable(imx_pcie);
> > > > err_pwrctrl_power_off:
> > > > - pci_pwrctrl_power_off_devices(dev);
> > > > + if (!pp->skip_pwrctrl_off)
> > > > + pci_pwrctrl_power_off_devices(dev);
> > > > err_pwrctrl_destroy:
> > > > - if (ret != -EPROBE_DEFER)
> > > > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > > > pci_pwrctrl_destroy_devices(dev);
> > > > err_reg_disable:
> > > > if (imx_pcie->vpcie)
> > > > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct
> > > > dw_pcie_rp
> > > *pp)
> > > > }
> > > > imx_pcie_clk_disable(imx_pcie);
> > > >
> > > > - pci_pwrctrl_power_off_devices(pci->dev);
> > > > + if (!pci->pp.skip_pwrctrl_off)
> > > > + pci_pwrctrl_power_off_devices(pci->dev);
> > > > if (imx_pcie->vpcie)
> > > > regulator_disable(imx_pcie->vpcie);
> > > > }
> > > > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > > > platform_device *pdev) static void imx_pcie_shutdown(struct
> > > > platform_device *pdev) {
> > > > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > > > + struct dw_pcie *pci = imx_pcie->pci;
> > > > + struct dw_pcie_rp *pp = &pci->pp;
> > > >
> > > > /* bring down link, so bootloader gets clean state in case of reboot */
> > > > imx_pcie_assert_core_reset(imx_pcie);
> > > > imx_pcie_assert_perst(imx_pcie, true);
> > > > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > > > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > > > + if (!pp->skip_pwrctrl_off)
> > > > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > > > + if (!pci->suspended)
> > > > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > > > }
> > > >
> > > > static const struct imx_pcie_drvdata drvdata[] = {
> > > > --
> > > > 2.50.1
> > > >
> > > >
^ permalink raw reply
* RE: [v2] Bluetooth: virtio_bt: fix cleanup paths
From: bluez.test.bot @ 2026-06-25 2:41 UTC (permalink / raw)
To: linux-bluetooth, haoxiang_li2024
In-Reply-To: <20260625020159.3446736-1-haoxiang_li2024@163.com>
[-- Attachment #1: Type: text/plain, Size: 1181 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=1116220
---Test result---
Test Summary:
CheckPatch PASS 1.39 seconds
VerifyFixes PASS 0.34 seconds
VerifySignedoff PASS 0.27 seconds
GitLint PASS 0.57 seconds
SubjectPrefix PASS 0.28 seconds
BuildKernel PASS 25.78 seconds
CheckAllWarning PASS 28.53 seconds
CheckSparse PASS 27.60 seconds
BuildKernel32 PASS 25.17 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 458.20 seconds
IncrementalBuild PASS 25.61 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/350
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re:Re: [PATCH] Bluetooth: virtio_bt: unregister HCI device on open failure
From: haoxiang_li2024 @ 2026-06-25 2:09 UTC (permalink / raw)
To: Paul Menzel, martin.petersen@oracle.com
Cc: marcel, luiz.dentz, yangyingliang, mst, error27, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <17c94df1-3659-4d21-b327-ad52d498ba9c@molgen.mpg.de>
Hi Paul,
At 2026-06-24 17:10:55, "Paul Menzel" <pmenzel@molgen.mpg.de> wrote:
>
>Should you resend, please re-flow for 72/75 characters, so only three
>lines are used.
>
Thank you for the review!
Following Dan's suggestions, I reworked the patch in v2. I also made the
commit message more compact based on your suggestion.
>
>PS: gemini/gemini-3.1-pro-preview found an unrelated issue to the patch
>during review of this patch [1].
>
>> This is a pre-existing issue, but does this error path safely clean up the
>> active virtqueues?
>> Earlier in virtbt_probe(), virtio_device_ready(vdev) marks the device as
>> active. If virtbt_open_vdev() subsequently fails, the code jumps to the
>> open_failed label and eventually reaches here to call del_vqs(vdev).
>> Deleting virtqueues without calling virtio_reset_device(vdev) first violates
>> the VirtIO API contract for active devices. It could allow the host or
>> hypervisor to access guest memory that has already been freed by del_vqs(),
>> potentially leading to a use-after-free.
>> Should virtio_reset_device(vdev) be called before tearing down the
>> virtqueues in this error path?
>
>No idea, how to best track these things.
>
The issue noted in your PS is now handled by resetting the virtio device
before tearing down the virtqueues in the virtbt_open_vdev() failure path.
Since v2 changes more than the original one-line fix, I did not carry your
Reviewed-by tag. Thanks again!
Thanks,
Haoxiang
^ permalink raw reply
* Re: [PATCH 12/13] Bluetooth: btqca: Fix undetected error HCI status in qca_send_reset()
From: Zijun Hu @ 2026-06-25 2:08 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Rocky Liao, Bartosz Golaszewski,
Ben Young Tae Kim, Balakrishna Godavarthi, Matthias Kaehlcke,
Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm
In-Reply-To: <CABBYNZKx3+08Ajisy7-sHi0TZJNrbgzBzdszcKfiZUiNOdhByA@mail.gmail.com>
On 6/23/2026 11:15 PM, Luiz Augusto von Dentz wrote:
>> u8 cmd;
>> @@ -990,7 +971,8 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>> }
>>
>> /* Perform HCI reset */
>> - err = qca_send_reset(hdev);
>> + bt_dev_dbg(hdev, "QCA HCI_RESET");
>> + err = __hci_reset_sync(hdev);
> So All the fuss about the reset is just to use it here? Actually the
> distinction between -err and status is rather important. The first
> means the command didn't run (timeout, cancel, etc), or it did run but
> returned a status != 0. If you want to capture both then you must use
> if (err). And yes there are parts of the code that test for < 0, but
> that is either a bug or they are intentionally ignoring the reset
> status as it is probably a non-recoverable error at that point.
1. Agree: > 0 for HCI status code (controller-side error), < 0 for command not executed
(timeout, cancel, transport failure). __hci_reset_sync() was introduced in this series and will
be refactored to follow this convention in v2.
2. Looking at drivers/bluetooth/, 7 out of 12 HCI reset call sites in the init/setup phase
silently ignore the controller status — not sure if this is intentional or not.
3. qca_set_bdaddr() and qca_send_reset() will be fixed to return the HCI status code and let the
caller decide whether to ignore it.
Will address all of the above in v2.
^ permalink raw reply
* [PATCH v2] Bluetooth: virtio_bt: fix cleanup paths
From: Haoxiang Li @ 2026-06-25 2:01 UTC (permalink / raw)
To: marcel, luiz.dentz, yangyingliang, error27, mst
Cc: linux-bluetooth, linux-kernel, Haoxiang Li, stable
virtbt_probe() registers the HCI device before opening the virtio
Bluetooth device. If virtbt_open_vdev() fails, the error path frees
the HCI device without unregistering it first. The probe error paths
also leak the virtio_bluetooth structure after it has been allocated.
Rework the probe error handling into an unwind ladder so each failure
path releases the resources acquired earlier. Also close the virtio
device before unregistering the HCI device in virtbt_remove(), matching
the cleanup order used by the probe failure path.
Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver")
Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
Changes in v2:
- Rework virtbt_probe() error paths into an unwind ladder.
- Free vbt on probe failures.
- Reset the virtio device and unregister the HCI device before freeing it
when virtbt_open_vdev() fails.
- Close the virtio device before unregistering the HCI device in remove().
Thanks Dan for the suggestions. The blog is very helpful.
---
drivers/bluetooth/virtio_bt.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
index 140ab55c9fc5..4ca9b76f6410 100644
--- a/drivers/bluetooth/virtio_bt.c
+++ b/drivers/bluetooth/virtio_bt.c
@@ -311,12 +311,12 @@ static int virtbt_probe(struct virtio_device *vdev)
err = virtio_find_vqs(vdev, VIRTBT_NUM_VQS, vbt->vqs, vqs_info, NULL);
if (err)
- return err;
+ goto err_free_vbt;
hdev = hci_alloc_dev();
if (!hdev) {
err = -ENOMEM;
- goto failed;
+ goto err_del_vqs;
}
vbt->hdev = hdev;
@@ -383,23 +383,28 @@ static int virtbt_probe(struct virtio_device *vdev)
if (virtio_has_feature(vdev, VIRTIO_BT_F_AOSP_EXT))
hci_set_aosp_capable(hdev);
- if (hci_register_dev(hdev) < 0) {
- hci_free_dev(hdev);
+ err = hci_register_dev(hdev);
+ if (err < 0) {
err = -EBUSY;
- goto failed;
+ goto err_free_hdev;
}
virtio_device_ready(vdev);
err = virtbt_open_vdev(vbt);
if (err)
- goto open_failed;
+ goto err_reset_vdev;
return 0;
-open_failed:
+err_reset_vdev:
+ virtio_reset_device(vdev);
+ hci_unregister_dev(hdev);
+err_free_hdev:
hci_free_dev(hdev);
-failed:
+err_del_vqs:
vdev->config->del_vqs(vdev);
+err_free_vbt:
+ kfree(vbt);
return err;
}
@@ -408,10 +413,10 @@ static void virtbt_remove(struct virtio_device *vdev)
struct virtio_bluetooth *vbt = vdev->priv;
struct hci_dev *hdev = vbt->hdev;
- hci_unregister_dev(hdev);
virtio_reset_device(vdev);
virtbt_close_vdev(vbt);
+ hci_unregister_dev(hdev);
hci_free_dev(hdev);
vbt->hdev = NULL;
--
2.25.1
^ permalink raw reply related
* RE: Bluetooth: sco: Fix a race condition in sco_sock_timeout()
From: bluez.test.bot @ 2026-06-25 0:22 UTC (permalink / raw)
To: linux-bluetooth, iam
In-Reply-To: <20260624213304.1460149-2-iam@sung-woo.kim>
[-- Attachment #1: Type: text/plain, Size: 3865 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=1116158
---Test result---
Test Summary:
CheckPatch FAIL 1.08 seconds
VerifyFixes PASS 0.21 seconds
VerifySignedoff PASS 0.20 seconds
GitLint FAIL 0.45 seconds
SubjectPrefix PASS 0.18 seconds
BuildKernel PASS 28.74 seconds
CheckAllWarning PASS 29.24 seconds
CheckSparse PASS 28.03 seconds
BuildKernel32 PASS 26.10 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 491.15 seconds
TestRunner_sco-tester PASS 31.94 seconds
IncrementalBuild PASS 26.32 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: sco: Fix a race condition in sco_sock_timeout()
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#109:
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
total: 0 errors, 1 warnings, 0 checks, 24 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14643876.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: sco: Fix a race condition in sco_sock_timeout()
15: B3 Line contains hard tab characters (\t): " sco_conn_free()"
16: B3 Line contains hard tab characters (\t): " disable_delayed_work_sync()"
17: B3 Line contains hard tab characters (\t): " lock(sk) // <-- SAME LOCK"
28: B1 Line exceeds max length (155>80): "ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]"
29: B1 Line exceeds max length (152>80): "ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]"
30: B1 Line exceeds max length (148>80): "ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]"
31: B1 Line exceeds max length (146>80): "ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195"
34: B1 Line exceeds max length (128>80): "ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]"
35: B1 Line exceeds max length (133>80): "ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524"
47: B1 Line exceeds max length (82>80): " process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310"
63: B1 Line exceeds max length (81>80): " disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514"
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/349
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: sco: Fix a race condition in sco_sock_timeout()
From: Sungwoo Kim @ 2026-06-24 22:32 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Dave Tian, Luiz Augusto von Dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260624213304.1460149-2-iam@sung-woo.kim>
On Wed, Jun 24, 2026 at 5:36 PM Sungwoo Kim <iam@sung-woo.kim> wrote:
>
> sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket
> is closing while the timer is running, it holds the same lock
> (lock_sock(sk)) twice, leading to a deadlock.
>
> CPU 0 CPU 1
> ==================== ======================
> sco_sock_close()
> sco_sock_timeout()
> lock_sock(sk) // <-- LOCK
> __sco_sock_close()
> sco_chan_del()
> sco_conn_put()
> sco_conn_free()
> disable_delayed_work_sync()
> lock(sk) // <-- SAME LOCK
>
> Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk),
> ensuring that no lock_sock(sk) is held before sco_sock_timeout().
>
> Lockdep splat:
>
> WARNING: possible circular locking dependency detected
> 6.13.0-rc4 #7 Not tainted
>
> syz-executor292/9514 is trying to acquire lock:
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]
> ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
>
> but task is already holding lock:
> ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
> ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
> lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
> lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622
> lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
> sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158
> process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline]
> process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310
> worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391
> kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389
> ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244
>
> -> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}:
> check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline]
> check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline]
> validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904
> __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226
> lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
> touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline]
> start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline]
> __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
> __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline]
> disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514
> sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline]
> kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline]
> sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107
> sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236
> sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526
> sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/bluetooth/sco.c:1300
> __sock_release+0xe1/0x2d0 sect/v6.13-rc4/net/socket.c:640
> sock_close+0x1c/0x30 sect/v6.13-rc4/net/socket.c:1408
> __fput+0x2bd/0xa80 sect/v6.13-rc4/fs/file_table.c:450
> __fput_sync+0x15e/0x1c0 sect/v6.13-rc4/fs/file_table.c:535
> __do_sys_close sect/v6.13-rc4/fs/open.c:1554 [inline]
> __se_sys_close sect/v6.13-rc4/fs/open.c:1539 [inline]
> __x64_sys_close+0x93/0x120 sect/v6.13-rc4/fs/open.c:1539
> do_syscall_x64 sect/v6.13-rc4/arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xee/0x210 sect/v6.13-rc4/arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn")
> Acked-by: Dave Tian <daveti@purdue.edu>
> Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
> ---
> net/bluetooth/sco.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index fcc597be5bbd..c05f79b7aa31 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -570,10 +570,23 @@ static void __sco_sock_close(struct sock *sk)
> /* Must be called on unlocked socket. */
> static void sco_sock_close(struct sock *sk)
> {
> + struct sco_conn *conn;
> +
> + lock_sock(sk);
> + conn = sco_pi(sk)->conn;
> + if (conn)
> + sco_conn_hold(conn);
> + release_sock(sk);
> +
> + if (conn)
> + disable_delayed_work_sync(&conn->timeout_work);
> +
> lock_sock(sk);
> - sco_sock_clear_timer(sk);
> __sco_sock_close(sk);
> release_sock(sk);
> +
> + if (conn)
> + sco_conn_put(conn);
> }
>
> static void sco_sock_init(struct sock *sk, struct sock *parent)
> --
> 2.47.3
>
Although Sashiko [1] pointed out some interesting bugs in this patch,
they appear to be pre-existing.
I can send another patch for this.
[1] https://sashiko.dev/#/patchset/20260624213304.1460149-2-iam%40sung-woo.kim
^ permalink raw reply
* [PATCH] Bluetooth: sco: Fix a race condition in sco_sock_timeout()
From: Sungwoo Kim @ 2026-06-24 21:33 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: Sungwoo Kim, Dave Tian, Luiz Augusto von Dentz, linux-bluetooth,
linux-kernel
sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket
is closing while the timer is running, it holds the same lock
(lock_sock(sk)) twice, leading to a deadlock.
CPU 0 CPU 1
==================== ======================
sco_sock_close()
sco_sock_timeout()
lock_sock(sk) // <-- LOCK
__sco_sock_close()
sco_chan_del()
sco_conn_put()
sco_conn_free()
disable_delayed_work_sync()
lock(sk) // <-- SAME LOCK
Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk),
ensuring that no lock_sock(sk) is held before sco_sock_timeout().
Lockdep splat:
WARNING: possible circular locking dependency detected
6.13.0-rc4 #7 Not tainted
syz-executor292/9514 is trying to acquire lock:
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
but task is already holding lock:
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622
lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158
process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310
worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391
kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389
ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244
-> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}:
check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline]
check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline]
validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904
__lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline]
start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline]
__flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
__cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline]
disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514
sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline]
kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline]
sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107
sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236
sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526
sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/bluetooth/sco.c:1300
__sock_release+0xe1/0x2d0 sect/v6.13-rc4/net/socket.c:640
sock_close+0x1c/0x30 sect/v6.13-rc4/net/socket.c:1408
__fput+0x2bd/0xa80 sect/v6.13-rc4/fs/file_table.c:450
__fput_sync+0x15e/0x1c0 sect/v6.13-rc4/fs/file_table.c:535
__do_sys_close sect/v6.13-rc4/fs/open.c:1554 [inline]
__se_sys_close sect/v6.13-rc4/fs/open.c:1539 [inline]
__x64_sys_close+0x93/0x120 sect/v6.13-rc4/fs/open.c:1539
do_syscall_x64 sect/v6.13-rc4/arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xee/0x210 sect/v6.13-rc4/arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn")
Acked-by: Dave Tian <daveti@purdue.edu>
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
---
net/bluetooth/sco.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index fcc597be5bbd..c05f79b7aa31 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -570,10 +570,23 @@ static void __sco_sock_close(struct sock *sk)
/* Must be called on unlocked socket. */
static void sco_sock_close(struct sock *sk)
{
+ struct sco_conn *conn;
+
+ lock_sock(sk);
+ conn = sco_pi(sk)->conn;
+ if (conn)
+ sco_conn_hold(conn);
+ release_sock(sk);
+
+ if (conn)
+ disable_delayed_work_sync(&conn->timeout_work);
+
lock_sock(sk);
- sco_sock_clear_timer(sk);
__sco_sock_close(sk);
release_sock(sk);
+
+ if (conn)
+ sco_conn_put(conn);
}
static void sco_sock_init(struct sock *sk, struct sock *parent)
--
2.47.3
^ permalink raw reply related
* [bluez/bluez]
From: BluezTestBot @ 2026-06-24 20:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1114334
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-24 20:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1114528
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-24 20:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1115319
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH BlueZ] unit: test-bap: disable optimization to speed up compilation
From: patchwork-bot+bluetooth @ 2026-06-24 19:31 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <e0650488e684f464f69cf013d1654f46bb862d46.1782046466.git.pav@iki.fi>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sun, 21 Jun 2026 15:54:34 +0300 you wrote:
> Compilation of this file with optimization takes 12 min with ASAN, 1 min
> without. This is too long, and the -O2 doesn't serve purpose for unit
> tests.
>
> Disable optimization to reduce to 30 sec with ASAN (5 sec without).
>
> autoconf puts global -O2 in CFLAGS that cannot be overridden eg. with
> unit_test_bap_CFLAGS. Use pragma instead.
>
> [...]
Here is the summary with links:
- [BlueZ] unit: test-bap: disable optimization to speed up compilation
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=eb9b35c8d13d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v1] shared/rap: Fix step payload pointer in parse_step
From: patchwork-bot+bluetooth @ 2026-06-24 19:31 UTC (permalink / raw)
To: Prathibha Madugonde
Cc: linux-bluetooth, luiz.dentz, quic_mohamull, quic_hbandi,
quic_anubhavg
In-Reply-To: <20260623111112.1332742-1-prathm@qti.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 23 Jun 2026 16:41:12 +0530 you wrote:
> From: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
>
> util_iov_pull advances iov_base before returning the new pointer, so
> mode_iov.iov_base was set to the start of the *next* step's data.
> Every step was therefore parsed using its successor's bytes.
>
> Switch to util_iov_pull_mem which saves the original base, advances
> iov, and returns the pre-advance pointer — correctly pointing to the
> current step's payload.
>
> [...]
Here is the summary with links:
- [BlueZ,v1] shared/rap: Fix step payload pointer in parse_step
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=40a58272a58f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v1] shared: rap: Defer CS Event registration until connection setup
From: patchwork-bot+bluetooth @ 2026-06-24 19:31 UTC (permalink / raw)
To: Naga Bhavani Akella
Cc: linux-bluetooth, luiz.dentz, quic_mohamull, quic_hbandi,
quic_anubhavg
In-Reply-To: <20260622062905.3525480-1-naga.akella@oss.qualcomm.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 22 Jun 2026 11:59:05 +0530 you wrote:
> Move LE CS event registration from rap_probe()
> to rap_accept(). rap_probe() runs during service discovery
> while no ACL connection or connection handle exists,
> so connection-scoped CS events cannot be delivered or
> associated with a device. rap_accept() is called
> after the ACL link is established, when a valid
> connection handle is available and the HCI layer
> can route events correctly.
> Registering events at this point ensures
> proper handling of CS events.
>
> [...]
Here is the summary with links:
- [BlueZ,v1] shared: rap: Defer CS Event registration until connection setup
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=7efd9383f0a1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [bluez/bluez] 7efd93: shared: rap: Defer CS Event registration until con...
From: Pauli Virtanen @ 2026-06-24 17:44 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: 7efd9383f0a1ea20226c63494bc0bcb9a3e2a8fa
https://github.com/bluez/bluez/commit/7efd9383f0a1ea20226c63494bc0bcb9a3e2a8fa
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
M profiles/ranging/rap.c
Log Message:
-----------
shared: rap: Defer CS Event registration until connection setup
Move LE CS event registration from rap_probe()
to rap_accept(). rap_probe() runs during service discovery
while no ACL connection or connection handle exists,
so connection-scoped CS events cannot be delivered or
associated with a device. rap_accept() is called
after the ACL link is established, when a valid
connection handle is available and the HCI layer
can route events correctly.
Registering events at this point ensures
proper handling of CS events.
Commit: 40a58272a58fdfb00081289ab41fa6d4cebfb935
https://github.com/bluez/bluez/commit/40a58272a58fdfb00081289ab41fa6d4cebfb935
Author: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
M src/shared/rap.c
Log Message:
-----------
shared/rap: Fix step payload pointer in parse_step
util_iov_pull advances iov_base before returning the new pointer, so
mode_iov.iov_base was set to the start of the *next* step's data.
Every step was therefore parsed using its successor's bytes.
Switch to util_iov_pull_mem which saves the original base, advances
iov, and returns the pre-advance pointer — correctly pointing to the
current step's payload.
Commit: eb9b35c8d13dffcaf4f6f4b5bee29a18c860ba04
https://github.com/bluez/bluez/commit/eb9b35c8d13dffcaf4f6f4b5bee29a18c860ba04
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
M unit/test-bap.c
Log Message:
-----------
unit: test-bap: disable optimization to speed up compilation
Compilation of this file with optimization takes 12 min with ASAN, 1 min
without. This is too long, and the -O2 doesn't serve purpose for unit
tests.
Disable optimization to reduce to 30 sec with ASAN (5 sec without).
autoconf puts global -O2 in CFLAGS that cannot be overridden eg. with
unit_test_bap_CFLAGS. Use pragma instead.
Compare: https://github.com/bluez/bluez/compare/912f5efb0dd9...eb9b35c8d13d
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-24 17:07 UTC (permalink / raw)
To: Sherry Sun
Cc: Sherry Sun (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Amitkumar Karwar,
Neeraj Sanjay Kale, marcel@holtmann.org, luiz.dentz@gmail.com,
Hongxing Zhu, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <VI0PR04MB121147C305022511469FB603A92ED2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Jun 24, 2026 at 07:09:26AM +0000, Sherry Sun wrote:
> > Subject: Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
> >
> > On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> > > From: Sherry Sun <sherry.sun@nxp.com>
> > >
> > > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > > suspend to preserve wakeup capability of the devices and also not to
> > > power on the devices in the init path.
> > > This allows controller power-off to be skipped when some devices(e.g.
> > > M.2 cards key E without auxiliary power) required to support PCIe L2
> > > link state and wake-up mechanisms.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 36
> > > +++++++++++++++++----------
> > > 1 file changed, 23 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 0fa716d1ed75..ff5a9565dbbf 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> > *pp)
> > > }
> > > }
> > >
> > > - ret = pci_pwrctrl_create_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to create pwrctrl devices\n");
> > > - goto err_reg_disable;
> > > + if (!pci->suspended) {
> > > + ret = pci_pwrctrl_create_devices(dev);
> >
> > Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
> >
> > and call it direct at probe() function, like other regulator_get function.
> >
>
> Hi Frank,
> That makes sense. However, if we move pci_pwrctrl_create_devices () to
> probe(), we may need to add the following goto err_pwrctrl_destroy path
> in imx_pcie_probe() to properly handle errors from
> pci_pwrctrl_power_on_devices(), is that acceptable?
Can you add a API devm_pci_pwrctrl_create_devices() ?
Frank
>
> @@ -1960,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1979,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1991,6 +1984,11 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
> }
>
> Best Regards
> Sherry
>
> >
> > > + if (ret) {
> > > + dev_err(dev, "failed to create pwrctrl devices\n");
> > > + goto err_reg_disable;
> > > + }
> > > }
> > >
> > > - ret = pci_pwrctrl_power_on_devices(dev);
> > > - if (ret) {
> > > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > > - goto err_pwrctrl_destroy;
> > > + if (!pp->skip_pwrctrl_off) {
> > > + ret = pci_pwrctrl_power_on_devices(dev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > > + goto err_pwrctrl_destroy;
> > > + }
> > > }
> > >
> > > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,9 +1464,10 @@
> > static
> > > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > > err_clk_disable:
> > > imx_pcie_clk_disable(imx_pcie);
> > > err_pwrctrl_power_off:
> > > - pci_pwrctrl_power_off_devices(dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(dev);
> > > err_pwrctrl_destroy:
> > > - if (ret != -EPROBE_DEFER)
> > > + if (ret != -EPROBE_DEFER && !pci->suspended)
> > > pci_pwrctrl_destroy_devices(dev);
> > > err_reg_disable:
> > > if (imx_pcie->vpcie)
> > > @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> > *pp)
> > > }
> > > imx_pcie_clk_disable(imx_pcie);
> > >
> > > - pci_pwrctrl_power_off_devices(pci->dev);
> > > + if (!pci->pp.skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(pci->dev);
> > > if (imx_pcie->vpcie)
> > > regulator_disable(imx_pcie->vpcie);
> > > }
> > > @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct
> > > platform_device *pdev) static void imx_pcie_shutdown(struct
> > > platform_device *pdev) {
> > > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > > + struct dw_pcie *pci = imx_pcie->pci;
> > > + struct dw_pcie_rp *pp = &pci->pp;
> > >
> > > /* bring down link, so bootloader gets clean state in case of reboot */
> > > imx_pcie_assert_core_reset(imx_pcie);
> > > imx_pcie_assert_perst(imx_pcie, true);
> > > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > > - pci_pwrctrl_destroy_devices(&pdev->dev);
> > > + if (!pp->skip_pwrctrl_off)
> > > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > > + if (!pci->suspended)
> > > + pci_pwrctrl_destroy_devices(&pdev->dev);
> > > }
> > >
> > > static const struct imx_pcie_drvdata drvdata[] = {
> > > --
> > > 2.50.1
> > >
> > >
^ permalink raw reply
* RE: [v2] Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: bluez.test.bot @ 2026-06-24 16:39 UTC (permalink / raw)
To: linux-bluetooth, sammiee5311
In-Reply-To: <20260624143222.883120-1-sammiee5311@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2389 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=1115967
---Test result---
Test Summary:
CheckPatch PASS 1.15 seconds
VerifyFixes PASS 0.34 seconds
VerifySignedoff PASS 0.34 seconds
GitLint PASS 0.54 seconds
SubjectPrefix PASS 0.80 seconds
BuildKernel PASS 26.37 seconds
CheckAllWarning PASS 28.90 seconds
CheckSparse PASS 28.03 seconds
BuildKernel32 PASS 25.68 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 567.29 seconds
TestRunner_l2cap-tester PASS 57.85 seconds
TestRunner_iso-tester PASS 98.51 seconds
TestRunner_bnep-tester PASS 18.83 seconds
TestRunner_mgmt-tester FAIL 214.90 seconds
TestRunner_rfcomm-tester PASS 25.00 seconds
TestRunner_sco-tester PASS 32.03 seconds
TestRunner_ioctl-tester PASS 25.36 seconds
TestRunner_mesh-tester FAIL 25.01 seconds
TestRunner_smp-tester PASS 23.05 seconds
TestRunner_userchan-tester PASS 19.97 seconds
TestRunner_6lowpan-tester PASS 22.74 seconds
IncrementalBuild PASS 25.12 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.248 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 1.986 seconds
Mesh - Send cancel - 2 Timed out 1.990 seconds
https://github.com/bluez/bluetooth-next/pull/348
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-24 15:53 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100512
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH v2] Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: HyeongJun An @ 2026-06-24 14:32 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, linux-kernel, HyeongJun An, stable
In-Reply-To: <20260624115439.868817-1-sammiee5311@gmail.com>
eir_get_service_data() walks the advertising data looking for a Service
Data field with a matching UUID. eir_get_data() returns a pointer to the
matched field's data (field + 2) and reports dlen = field_len - 1 (the
data length only), while the field actually spans field_len + 1 = dlen + 2
bytes once its length and type bytes are counted.
On a UUID mismatch the loop advances:
eir += dlen;
eir_len -= dlen;
The pointer advance is correct, but eir_len is decremented by only dlen --
2 less than the bytes the field really spans (and less still when
eir_get_data() skipped preceding non-Service-Data fields). eir_len thus
over-counts the remaining buffer, and the error compounds across fields.
As eir_get_data() bounds its walk by this inflated eir_len, it ends up
reading the length/type bytes of a "field" past the end of the buffer.
For an ISO broadcast sink the buffer is hcon->le_per_adv_data[], filled
from the periodic-advertising reports of a remote broadcaster and parsed
by eir_get_service_data() in net/bluetooth/iso.c. A crafted PA payload
packed with mismatching Service Data fields drives the walk past the
array into adjacent struct hci_conn memory -- a remotely triggerable
out-of-bounds read; when a drifted field happens to match the BAA UUID
the out-of-bounds bytes are copied into iso_pi(sk)->base and become
readable from user space via getsockopt(BT_ISO_BASE).
Keep eir_len in sync with the pointer by recomputing it from the end of
the buffer on each iteration.
Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
---
Changes in v2:
- Untab the commit-message code snippet to satisfy the gitlint check; no
code change.
net/bluetooth/eir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c
index 1de5f9df6eec..a55696820b22 100644
--- a/net/bluetooth/eir.c
+++ b/net/bluetooth/eir.c
@@ -369,6 +369,7 @@ u8 eir_create_scan_rsp(struct hci_dev *hdev, u8 instance, u8 *ptr)
void *eir_get_service_data(u8 *eir, size_t eir_len, u16 uuid, size_t *len)
{
+ const u8 *eir_end = eir + eir_len;
size_t dlen;
while ((eir = eir_get_data(eir, eir_len, EIR_SERVICE_DATA, &dlen))) {
@@ -381,7 +382,7 @@ void *eir_get_service_data(u8 *eir, size_t eir_len, u16 uuid, size_t *len)
}
eir += dlen;
- eir_len -= dlen;
+ eir_len = eir_end - eir;
}
return NULL;
--
2.43.0
^ permalink raw reply related
* RE: Bluetooth: eir: Fix OOB read in eir_get_service_data()
From: bluez.test.bot @ 2026-06-24 14:19 UTC (permalink / raw)
To: linux-bluetooth, sammiee5311
In-Reply-To: <20260624115439.868817-1-sammiee5311@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2653 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=1115877
---Test result---
Test Summary:
CheckPatch PASS 1.35 seconds
VerifyFixes PASS 0.31 seconds
VerifySignedoff PASS 0.20 seconds
GitLint FAIL 0.71 seconds
SubjectPrefix PASS 0.37 seconds
BuildKernel PASS 27.00 seconds
CheckAllWarning PASS 29.24 seconds
CheckSparse PASS 27.97 seconds
BuildKernel32 PASS 25.97 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 574.54 seconds
TestRunner_l2cap-tester PASS 57.98 seconds
TestRunner_iso-tester PASS 78.50 seconds
TestRunner_bnep-tester PASS 18.88 seconds
TestRunner_mgmt-tester FAIL 209.96 seconds
TestRunner_rfcomm-tester PASS 25.44 seconds
TestRunner_sco-tester PASS 32.55 seconds
TestRunner_ioctl-tester PASS 25.60 seconds
TestRunner_mesh-tester FAIL 26.07 seconds
TestRunner_smp-tester PASS 22.95 seconds
TestRunner_userchan-tester PASS 19.95 seconds
TestRunner_6lowpan-tester PASS 22.94 seconds
IncrementalBuild PASS 25.85 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: eir: Fix OOB read in eir_get_service_data()
11: B3 Line contains hard tab characters (\t): " eir += dlen;"
12: B3 Line contains hard tab characters (\t): " eir_len -= dlen;"
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.233 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.439 seconds
Mesh - Send cancel - 2 Timed out 1.991 seconds
https://github.com/bluez/bluetooth-next/pull/347
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v8] Bluetooth: btbcm: Add Synaptics 4384 chip support
From: Paul Menzel @ 2026-06-24 12:30 UTC (permalink / raw)
To: Kaihsin Chung
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, Kaihsin Chung
In-Reply-To: <20260624081947.2495351-1-kaihsin.chung@synaptics.com>
Dear Kaihsin,
Thank you for your patch. Just a note, that your given name should also
start with a capital letter.
Am 24.06.26 um 10:19 schrieb kaihsin Chung:
> Add support for the Synaptics 4384 Bluetooth controller
> by adding the corresponding chip IDs.
Please mention the source for the ids, like a datasheet name.
Also, please document in the commit message, how you tested this.
> 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 463d59890bef..1caa1c9468d8 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)",
> @@ -514,6 +516,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 */
Please align everything with the existing lines (} and /*).
> { }
> };
>
> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
> index 1a4fc3882fd2..d306da6a46ff 100644
> --- a/drivers/bluetooth/hci_bcm.c
> +++ b/drivers/bluetooth/hci_bcm.c
> @@ -1594,6 +1594,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" },
Put it two lines above below the existing brcm line?
> { },
> };
> MODULE_DEVICE_TABLE(of, bcm_bluetooth_of_match);
Kind regards,
Paul
^ permalink raw reply
* RE: Bluetooth: virtio_bt: unregister HCI device on open failure
From: bluez.test.bot @ 2026-06-24 11:57 UTC (permalink / raw)
To: linux-bluetooth, haoxiang_li2024
In-Reply-To: <20260624084333.2885144-1-haoxiang_li2024@163.com>
[-- Attachment #1: Type: text/plain, Size: 1181 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=1115809
---Test result---
Test Summary:
CheckPatch PASS 0.77 seconds
VerifyFixes PASS 0.27 seconds
VerifySignedoff PASS 0.17 seconds
GitLint PASS 0.47 seconds
SubjectPrefix PASS 0.20 seconds
BuildKernel PASS 20.84 seconds
CheckAllWarning PASS 23.20 seconds
CheckSparse PASS 31.01 seconds
BuildKernel32 PASS 20.39 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 414.24 seconds
IncrementalBuild PASS 19.89 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/346
---
Regards,
Linux Bluetooth
^ 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