[PATCH] staging: nvec: use guard(mutex) in nvec_write_sync()

[PATCH] staging: nvec: use guard(mutex) in nvec_write_sync()

[Jeremy Dean Clifton]

Use guard(mutex) for sync_write_mutex. The lock is released
automatically on every return path. This removes the three
mutex_unlock() calls and simplifies the -ENOMEM error path.

No functional change.

Assisted-by: LLM
Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
---
 drivers/staging/nvec/nvec.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 41cbdfdc1da6..716b1b482568 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -298,17 +298,15 @@ int nvec_write_sync(struct nvec_chip *nvec,
 		    const unsigned char *data, short size,
 		    struct nvec_msg **msg)
 {
-	mutex_lock(&nvec->sync_write_mutex);
+	guard(mutex)(&nvec->sync_write_mutex);
 
 	if (msg)
 		*msg = NULL;
 
 	nvec->sync_write_pending = (data[1] << 8) + data[0];
 
-	if (nvec_write_async(nvec, data, size) < 0) {
-		mutex_unlock(&nvec->sync_write_mutex);
+	if (nvec_write_async(nvec, data, size) < 0)
 		return -ENOMEM;
-	}
 
 	dev_dbg(nvec->dev, "nvec_sync_write: 0x%04x\n",
 		nvec->sync_write_pending);
@@ -316,7 +314,6 @@ int nvec_write_sync(struct nvec_chip *nvec,
 					  msecs_to_jiffies(2000)))) {
 		dev_warn(nvec->dev,
 			 "Timeout waiting for sync write to complete\n");
-		mutex_unlock(&nvec->sync_write_mutex);
 		return -ETIMEDOUT;
 	}
 
@@ -327,8 +324,6 @@ int nvec_write_sync(struct nvec_chip *nvec,
 	else
 		nvec_msg_free(nvec, nvec->last_sync_msg);
 
-	mutex_unlock(&nvec->sync_write_mutex);
-
 	return 0;
 }
 EXPORT_SYMBOL(nvec_write_sync);
-- 
2.43.0

Re: [PATCH] staging: nvec: use guard(mutex) in nvec_write_sync()

[Julia Lawall]

On Mon, 12 Oct 2026, Jeremy Dean Clifton wrote:

> Use guard(mutex) for sync_write_mutex. The lock is released
> automatically on every return path.

The second sentence seems ambiguous to me.  Is this the motivation for
doing the patch or the result of the patch.

> This removes the three
> mutex_unlock() calls and simplifies the -ENOMEM error path.
>
> No functional change.
>
> Assisted-by: LLM

For Outreachy, I would encourage you to do the work by hand.  You are
welcome to check the work with an LLM.  The goal in the application period
is to learn how the patch submission process works, not necessarily to do
it as fast as possible.

Feel free to introduce yourself on the list as well.

julia

> Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
> ---
>  drivers/staging/nvec/nvec.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> index 41cbdfdc1da6..716b1b482568 100644
> --- a/drivers/staging/nvec/nvec.c
> +++ b/drivers/staging/nvec/nvec.c
> @@ -298,17 +298,15 @@ int nvec_write_sync(struct nvec_chip *nvec,
>  		    const unsigned char *data, short size,
>  		    struct nvec_msg **msg)
>  {
> -	mutex_lock(&nvec->sync_write_mutex);
> +	guard(mutex)(&nvec->sync_write_mutex);
>
>  	if (msg)
>  		*msg = NULL;
>
>  	nvec->sync_write_pending = (data[1] << 8) + data[0];
>
> -	if (nvec_write_async(nvec, data, size) < 0) {
> -		mutex_unlock(&nvec->sync_write_mutex);
> +	if (nvec_write_async(nvec, data, size) < 0)
>  		return -ENOMEM;
> -	}
>
>  	dev_dbg(nvec->dev, "nvec_sync_write: 0x%04x\n",
>  		nvec->sync_write_pending);
> @@ -316,7 +314,6 @@ int nvec_write_sync(struct nvec_chip *nvec,
>  					  msecs_to_jiffies(2000)))) {
>  		dev_warn(nvec->dev,
>  			 "Timeout waiting for sync write to complete\n");
> -		mutex_unlock(&nvec->sync_write_mutex);
>  		return -ETIMEDOUT;
>  	}
>
> @@ -327,8 +324,6 @@ int nvec_write_sync(struct nvec_chip *nvec,
>  	else
>  		nvec_msg_free(nvec, nvec->last_sync_msg);
>
> -	mutex_unlock(&nvec->sync_write_mutex);
> -
>  	return 0;
>  }
>  EXPORT_SYMBOL(nvec_write_sync);
> --
> 2.43.0
>
>
>

Re: [PATCH] staging: nvec: use guard(mutex) in nvec_write_sync()

[Jeremy Clifton]

Thank you so much for your guidance and feedback.

It is the result that the patch will produce. All the unlock calls will
be deleted and the out of memory path will have no braces, as per
the style guidelines.

The motivation behind the patch is to defer usage of manual locks
for new and improved guards, disallowing lock leaks.

This way, there can be no error producing path by not calling unlock.

Shall I send a v2 with motivation included?

On 10/12/26 2:45 PM, Julia Lawall wrote:
> Is this the motivation for
> doing the patch or the result of the patch.

Re: [PATCH] staging: nvec: use guard(mutex) in nvec_write_sync()

[Julia Lawall]

On Mon, 12 Oct 2026, Jeremy Clifton wrote:

> Thank you so much for your guidance and feedback.
>
> It is the result that the patch will produce. All the unlock calls will
> be deleted and the out of memory path will have no braces, as per
> the style guidelines.
>
> The motivation behind the patch is to defer usage of manual locks
> for new and improved guards, disallowing lock leaks.
>
> This way, there can be no error producing path by not calling unlock.
>
> Shall I send a v2 with motivation included?

Please adjust the second sentence to be clear that it is referring to the
result, not the initial state.  If you would like to add something about
the motivation, that would probably be good too.

thanks,
julia

>
> On 10/12/26 2:45 PM, Julia Lawall wrote:
> > Is this the motivation for
> > doing the patch or the result of the patch.
>
>

Re: [PATCH] staging: nvec: use guard(mutex) in nvec_write_sync()

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Mon, Oct 12, 2026 at 03:41:48PM -0600, Jeremy Clifton wrote:
> Thank you so much for your guidance and feedback.
> 
> It is the result that the patch will produce. All the unlock calls will
> be deleted and the out of memory path will have no braces, as per
> the style guidelines.
> 
> The motivation behind the patch is to defer usage of manual locks
> for new and improved guards, disallowing lock leaks.
> 
> This way, there can be no error producing path by not calling unlock.
> 
> Shall I send a v2 with motivation included?

Not a big deal in this case, but you might want to read up on how to
properly reply to emails:

    https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]