[PATCH v2 10/11] pinctrl: rockchip: Simplify locking with scoped_guard()

[Krzysztof Kozlowski]

On 23/02/2026 01:12, David Lechner wrote:
> On 1/18/26 12:09 PM, Krzysztof Kozlowski wrote:
>> Simplify error handling by removing two mutex_unlock() calls with
>> scoped_guard().
>>
>> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
>> ---
>>  drivers/pinctrl/pinctrl-rockchip.c | 19 +++++++++----------
>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
>> index e44ef262beec..bbe1cf712965 100644
>> --- a/drivers/pinctrl/pinctrl-rockchip.c
>> +++ b/drivers/pinctrl/pinctrl-rockchip.c
>> @@ -3640,17 +3640,16 @@ static int rockchip_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
> 
> Filling in some context from the existing code...
> 
> 	for (i = 0; i < num_configs; i++) {
> 		param = pinconf_to_config_param(configs[i]);
> 		arg = pinconf_to_config_argument(configs[i]);
> 
> 		if (param == PIN_CONFIG_LEVEL || param == PIN_CONFIG_INPUT_ENABLE) {
> 			/*
> 			 * Check for gpio driver not being probed yet.
> 
>>  			 * The lock makes sure that either gpio-probe has completed
>>  			 * or the gpio driver hasn't probed yet.
>>  			 */
>> -			mutex_lock(&bank->deferred_lock);
>> -			if (!gpio || !gpio->direction_output) {
>> -				rc = rockchip_pinconf_defer_pin(bank, pin - bank->pin_base, param,
>> -								arg);
>> -				mutex_unlock(&bank->deferred_lock);
>> -				if (rc)
>> -					return rc;
>> -
>> -				break;
>> +			scoped_guard(mutex, &bank->deferred_lock) {
>> +				if (!gpio || !gpio->direction_output) {
>> +					rc = rockchip_pinconf_defer_pin(bank,
>> +									pin - bank->pin_base,
>> +									param, arg);
>> +					if (rc)
>> +						return rc;
>> +					break;
> 
> I think there is an unintentional change here.
> 
> scoped_guard() is implemented by a for loop. So the break statement is now
> breaking out of the scoped_guard() scope rather than breaking out of the
> outer for loop.

Yes, you are right, thanks for catching this. I think the code can be
fixed with "return 0".

I need to check my other patches as well.


Best regards,
Krzysztof