[PATCH v2] Bluetooth: hci_qca: Reopen port after power on for QCA2066

[PATCH v2] Bluetooth: hci_qca: Reopen port after power on for QCA2066

[Shuai Zhang]

QCA2066 needs the serial port reopened after the controller is powered
on, otherwise the host and the device run into RTS/CTS synchronization
issues.

Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
---
Changes for V2
 - Use a separate case for clearer logic.
 - V1 link
   https://lore.kernel.org/all/20261015092224.262158-1-shuai.zhang@oss.qualcomm.com/
---
 drivers/bluetooth/hci_qca.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 7089e9b63..ee3ccb59e 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1867,6 +1867,19 @@ static int qca_power_on(struct hci_dev *hdev)
 		ret = qca_regulator_init(hu);
 		break;
 
+	case QCA_QCA2066:
+		qcadev = serdev_device_get_drvdata(hu->serdev);
+		if (qcadev->bt_en) {
+			gpiod_set_value_cansleep(qcadev->bt_en, 0);
+			msleep(50);
+			gpiod_set_value_cansleep(qcadev->bt_en, 1);
+			/* Controller needs time to bootup. */
+			msleep(50);
+		}
+
+		ret = qca_port_reopen(hu);
+		break;
+
 	default:
 		qcadev = serdev_device_get_drvdata(hu->serdev);
 		if (qcadev->bt_en) {
-- 
2.34.1

RE: [v2] Bluetooth: hci_qca: Reopen port after power on for QCA2066

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1019 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/series/1186867/

---Test result---

Test Summary:
CheckPatch                    PASS      0.73 seconds
VerifyFixes                   PASS      0.12 seconds
VerifySignedoff               PASS      0.12 seconds
GitLint                       PASS      0.32 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      30.66 seconds
CheckAllWarning               PASS      34.41 seconds
CheckSparse                   PASS      36.25 seconds
BuildKernel32                 PASS      29.04 seconds
CheckKernelLLVM               PASS      33.01 seconds
TestRunnerSetup               PASS      711.70 seconds
IncrementalBuild              PASS      27.64 seconds



https://github.com/bluez/bluetooth-next/pull/955

---
Regards,
Linux Bluetooth

Re: [PATCH v2] Bluetooth: hci_qca: Reopen port after power on for QCA2066

[Bartosz Golaszewski]

On Fri, 16 Oct 2026 04:23:02 +0200, Shuai Zhang
<shuai.zhang@oss.qualcomm.com> said:
> QCA2066 needs the serial port reopened after the controller is powered
> on, otherwise the host and the device run into RTS/CTS synchronization
> issues.
>
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> ---
> Changes for V2
>  - Use a separate case for clearer logic.
>  - V1 link
>    https://lore.kernel.org/all/20261015092224.262158-1-shuai.zhang@oss.qualcomm.com/
> ---
>  drivers/bluetooth/hci_qca.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 7089e9b63..ee3ccb59e 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1867,6 +1867,19 @@ static int qca_power_on(struct hci_dev *hdev)
>  		ret = qca_regulator_init(hu);
>  		break;
>
> +	case QCA_QCA2066:
> +		qcadev = serdev_device_get_drvdata(hu->serdev);
> +		if (qcadev->bt_en) {
> +			gpiod_set_value_cansleep(qcadev->bt_en, 0);
> +			msleep(50);
> +			gpiod_set_value_cansleep(qcadev->bt_en, 1);
> +			/* Controller needs time to bootup. */
> +			msleep(50);
> +		}
> +
> +		ret = qca_port_reopen(hu);
> +		break;
> +
>  	default:
>  		qcadev = serdev_device_get_drvdata(hu->serdev);
>  		if (qcadev->bt_en) {
> --
> 2.34.1
>
>

From sashiko:

If qca_port_reopen() fails to open the device, it returns an error but leaves
the port closed.
Does this returned error propagate back to qca_setup(), causing it to execute
its retry loop and unconditionally call serdev_device_close() again?
Looking at ttyport_close() in drivers/tty/serdev/serdev-ttyport.c, it appears
to lack idempotency checks and does not clear serport->tty after freeing it
via tty_release_struct().
If serdev_device_close() is called twice, could it cause a use-after-free or
double-free by dereferencing the freed tty pointer?
Furthermore, since serdev_device_close() unconditionally calls
pm_runtime_put(), could calling it again trigger a PM runtime usage count
underflow?

I think it's correct.

Bart