Re: [PATCH v6 5/5] 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] 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 <prasad.kumpatla@oss.qualcomm.com>

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?

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

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