Re: [PATCH V5 3/4] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `devm_pwrseq_get(&serdev->ctrl->dev)` in the child device's probe function binds the resource cleanup to the parent UART controller device, causing a permanent resource and memory leak on probe failures or driver unbind.
--

--- Patch [3]: [PATCH V5 3/4] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq ---
commit e33ed957970d3c81ac733b1991f81b42afce6a94
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..68f84c324113d 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c

[ ... ]

> @@ -1872,11 +1875,26 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
>  		return err;
>  	}
>  
> +	if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> +		struct pwrseq_desc *pwrseq;
> +
> +		pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");

[Severity: High]
The commit message notes that the devm cleanup is tied to the UART controller
device and adds explicit pwrseq_power_off() calls to compensate, but does
this approach leak memory and pwrseq references during bind/unbind cycles?

Because devm_pwrseq_get() is called with the parent device
(&serdev->ctrl->dev), each time nxp_serdev_probe() is executed, a new devres
entry is allocated and attached to the parent's lifecycle.

If the probe fails later, or if the driver is unbound and re-bound, the
child device's devres list is cleaned up, but the parent's devres list
retains the accumulated allocations.

While pwrseq_power_off() balances the power state in the error and remove
paths, the pwrseq descriptor itself is never released. Could this prevent
the power sequencer provider module from ever being unloaded due to the
leaked references?

> +		if (IS_ERR(pwrseq))
> +			return dev_err_probe(&serdev->dev, PTR_ERR(pwrseq),
> +					     "failed to get pwrseq\n");
> +
> +		nxpdev->pwrseq = pwrseq;
> +		err = pwrseq_power_on(pwrseq);
> +		if (err)
> +			return err;
> +	}
> +

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