Re: [PATCH V7] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Initialization ordering race in probe where the device is exposed to the system before synchronization primitives are fully initialized.
- [High] Teardown ordering bug leading to Use-After-Destroy of synchronization primitives during device removal.
--

--- Patch [1]: [PATCH V7] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq ---
commit aa33fbd5b00c9432b2b3b5cc158c49ae5ac11d72
Author: Sherry Sun <sherry.sun@nxp.com>

Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
    
Power supply to the M.2 Bluetooth device attached to the host using M.2
connector is controlled using the 'uart' pwrseq device. So add support
for getting the pwrseq device if the OF graph link is present.

> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index 0bb300eef157c..81a11ac051146 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c

[ ... ]

> @@ -1907,13 +1925,16 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
>  	if (bacmp(&ba, BDADDR_ANY))
>  		hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
>  
> -	if (hci_register_dev(hdev) < 0) {
> +	err = hci_register_dev(hdev);
> +	if (err < 0) {
>  		dev_err(&serdev->dev, "Can't register HCI device\n");
>  		goto probe_fail;
>  	}
>  
> -	if (ps_setup(hdev))
> +	if (ps_setup(hdev)) {

[Severity: High]
This isn't a bug introduced by this patch, but does this probe initialization
order expose the device to incoming traffic before its synchronization
primitives are fully set up?

In nxp_serdev_probe(), hci_register_dev() is called before ps_setup().
hci_register_dev() exposes the device and queues the power_on work which
calls hci_dev_do_open() -> btnxpuart_open() -> serdev_device_open().

Once opened, incoming UART data can trigger btnxpuart_receive_buf().
This calls ps_start_timer(), which executes mod_timer(). Because ps_setup()
(which initializes the timer via timer_setup()) hasn't executed yet, could
this cause an Oops on an uninitialized timer?

> +		err = -ENODEV;
>  		goto probe_fail_unregister;
> +	}
>  
>  	hci_devcd_register(hdev, nxp_coredump, nxp_coredump_hdr,
>  			   nxp_coredump_notify);

[ ... ]

> @@ -1952,6 +1976,8 @@ static void nxp_serdev_remove(struct serdev_device *serdev)
>  	ps_cleanup(nxpdev);
>  	hci_unregister_dev(hdev);
>  	reset_control_assert(nxpdev->pdn);

[Severity: High]
This is a pre-existing issue, but does this teardown order lead to a
use-after-destroy of the synchronization primitives?

In nxp_serdev_remove(), ps_cleanup() is called before hci_unregister_dev().
ps_cleanup() explicitly destroys psdata->ps_lock and shuts down
psdata->ps_timer.

However, the underlying UART (serdev) is not closed until
hci_unregister_dev() executes (which calls hci_dev_do_close() ->
btnxpuart_close() -> serdev_device_close()).

If UART data arrives in the window between ps_cleanup() and
hci_unregister_dev(), btnxpuart_receive_buf() will run and call
ps_start_timer(), manipulating the destroyed timer. Additionally, it can
trigger btnxpuart_tx_wakeup() -> btnxpuart_tx_work() -> ps_wakeup(), which
attempts to lock the destroyed psdata->ps_lock.

> +	if (nxpdev->pwrseq)
> +		pwrseq_put(nxpdev->pwrseq);
>  	hci_free_dev(hdev);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721030458.1160824-1-sherry.sun@oss.nxp.com?part=1