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

On 7/24/2026 8:15 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Premature mutex destruction in the driver removal path creates a potential use-after-destroy race condition.
> --
>
> --- Patch [5]: [PATCH v6 5/5] pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM ---
> commit c233c0ac41f2bc46bdca1d1c9ea5842fe1fcc867
> Author: Prasad Kumpatla <[email protected]>
>
> pinctrl: qcom: hawi-lpass-lpi: add Hawi LPASS LPI TLMM
>
> This commit adds the pin controller driver for the Low Power Audio
> SubSystem (LPASS) Low Power Island (LPI) of the Qualcomm Hawi SoC.
> The controller supports 23 GPIOs and utilizes the LPI_PINGROUP6 macro
> for certain pins due to a test_bus entry.
>
>> diff --git a/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c b/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
>> new file mode 100644
>> --- /dev/null
>> +++ b/drivers/pinctrl/qcom/pinctrl-hawi-lpass-lpi.c
> [ ... ]
>> +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, but I noticed a potential race condition in the
> shared removal path being used here.
>
> Can this lead to a use-after-destroy race condition when the device is
> unbound?
>
> Looking at the shared lpi_pinctrl_remove() in pinctrl-lpass-lpi.c:
>
> void lpi_pinctrl_remove(struct platform_device *pdev)
> {
> 	struct lpi_pinctrl *pctrl = platform_get_drvdata(pdev);
> 	int i;
>
> 	mutex_destroy(&pctrl->lock);
> 	...
>
> Since devres is used to manage the GPIO chip and pinctrl interfaces
> (devm_gpiochip_add_data and devm_pinctrl_register), these interfaces remain
> active until the devres release phase, which occurs after lpi_pinctrl_remove()
> returns.
>
> If a concurrent request (such as a userspace process accessing the exported
> GPIO via sysfs while unbinding) attempts to operate on the GPIOs, won't it
> try to lock this destroyed mutex before the devres cleanup has unregistered
> the interfaces?

Thanks for the review.

Yes this looks to be core LPI driver issue, Not related to Hawi pin ctrl.

Need to address this issue as a separate patch.

Thanks,
Prasad

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