Re: [PATCH v4 4/4] pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Use of destroyed mutex during device removal or probe failure.
--

--- Patch [4]: [PATCH v4 4/4] pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM ---
commit d1a3c124f6b76999c46378d71d6ae4c570d93507
Author: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>

pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM

Add pin controller driver for the Low Power Audio SubSystem (LPASS)
Low Power Island (LPI) of Qualcomm Hawi SoC. The controller has 23 GPIOs
with various mux functions.

> diff --git a/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c b/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
> new file mode 100644
> index 0000000000000..7036bf4c66920
> --- /dev/null
> +++ b/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
> @@ -0,0 +1,244 @@
[ ... ]
> +static const struct dev_pm_ops lpi_pinctrl_pm_ops = {
> +	RUNTIME_PM_OPS(pm_clk_suspend, pm_clk_resume, NULL)
> +};
> +
> +static struct platform_driver lpi_pinctrl_driver = {
> +	.driver = {
> +		.name = "qcom-hawi-lpass-lpi-pinctrl",
> +		.of_match_table = lpi_pinctrl_of_match,
> +		.pm = pm_ptr(&lpi_pinctrl_pm_ops),
> +	},
> +	.probe = lpi_pinctrl_probe,
> +	.remove = lpi_pinctrl_remove,

[Severity: High]
This is a pre-existing issue and was not introduced by the patch under review,
but since this driver uses lpi_pinctrl_remove() and lpi_pinctrl_probe()
from drivers/pinctrl/qcom/pinctrl-lpass-lpi.c, I wanted to ask about a
potential mutex lifetime issue.

During device unbind, lpi_pinctrl_remove() explicitly calls
mutex_destroy(&pctrl->lock). However, the driver uses devm_pinctrl_register()
and devm_gpiochip_add_data(), meaning the pinctrl and gpiochip subsystems
are not unregistered until after remove() returns and devres callbacks execute.

In this window, the subsystems remain active. Can a concurrent GPIO access
(e.g., from userspace via sysfs/chardev or another driver) invoke callbacks
like lpi_gpio_set() -> lpi_config_set(), which attempt to acquire the
destroyed mutex?

drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:lpi_config_set() {
    ...
	guard(mutex)(&pctrl->lock);
    ...
}

The probe error path in lpi_pinctrl_probe() similarly destroys the mutex
via err_pinctrl: while the previously registered pinctrl device (via
devm_pinctrl_register) remains active until devres cleanup.

Should the driver use devm_mutex_init() instead of manual mutex_destroy()
to ensure the mutex outlives the devres-managed subsystem devices?

> +};
> +
> +module_platform_driver(lpi_pinctrl_driver);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720130511.493295-1-prasad.kumpatla@oss.qualcomm.com?part=4