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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
> ---
> Changes for V2
>  - Use a separate case for clearer logic.
>  - V1 link
>    https://lore.kernel.org/all/20261015092224.262158-1-shuai.zhang@xxxxxxxxxxxxxxxx/
> ---
>  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