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

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

[Jeremy Dean Clifton]

The three return paths of nvec_write_sync() each release
sync_write_mutex with explicit unlock calls.

Use guard(mutex) to unlock the lock automatically on any return
path.

This removes the three mutex_unlock() calls.

No functional change.

Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
---
v2:
 - Reword the commit message to state the motivation and to make
   clear that removing the mutex_unlock() calls is the result of
   the change (Julia Lawall).
v1: https://lore.kernel.org/all/20261012171312.5998-1-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 v2] staging: nvec: use guard(mutex) in nvec_write_sync()

[Greg Kroah-Hartman]

On Mon, Oct 12, 2026 at 10:29:26PM +0000, Jeremy Dean Clifton wrote:
> The three return paths of nvec_write_sync() each release
> sync_write_mutex with explicit unlock calls.
> 
> Use guard(mutex) to unlock the lock automatically on any return
> path.
> 
> This removes the three mutex_unlock() calls.
> 
> No functional change.
> 
> Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
> ---
> v2:
>  - Reword the commit message to state the motivation and to make
>    clear that removing the mutex_unlock() calls is the result of
>    the change (Julia Lawall).
> v1: https://lore.kernel.org/all/20261012171312.5998-1-deaner92@yahoo.com/

Please read the archives for why I will not take guard() rewrites of
staging drivers (nor do I want to see you use a LLM in here either.)

sorry,

greg k-h

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

[Jeremy Clifton]

OK, it's understood. I'll look for another candidate.

Thanks for your feedback.

Jeremy

On 10/13/26 12:15 AM, Greg Kroah-Hartman wrote:
> On Mon, Oct 12, 2026 at 10:29:26PM +0000, Jeremy Dean Clifton wrote:
>> The three return paths of nvec_write_sync() each release
>> sync_write_mutex with explicit unlock calls.
>>
>> Use guard(mutex) to unlock the lock automatically on any return
>> path.
>>
>> This removes the three mutex_unlock() calls.
>>
>> No functional change.
>>
>> Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
>> ---
>> v2:
>>   - Reword the commit message to state the motivation and to make
>>     clear that removing the mutex_unlock() calls is the result of
>>     the change (Julia Lawall).
>> v1: https://lore.kernel.org/all/20261012171312.5998-1-deaner92@yahoo.com/
> 
> Please read the archives for why I will not take guard() rewrites of
> staging drivers (nor do I want to see you use a LLM in here either.)
> 
> sorry,
> 
> greg k-h

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

[Jeremy Dean Clifton]

On 10/13/26 12:15 AM, Greg Kroah-Hartman wrote:
> On Mon, Oct 12, 2026 at 10:29:26PM +0000, Jeremy Dean Clifton wrote:
>> The three return paths of nvec_write_sync() each release
>> sync_write_mutex with explicit unlock calls.
>>
>> Use guard(mutex) to unlock the lock automatically on any return
>> path.
>>
>> This removes the three mutex_unlock() calls.
>>
>> No functional change.
>>
>> Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
>> ---
>> v2:
>>   - Reword the commit message to state the motivation and to make
>>     clear that removing the mutex_unlock() calls is the result of
>>     the change (Julia Lawall).
>> v1: https://lore.kernel.org/all/20261012171312.5998-1-deaner92@yahoo.com/
> 
> Please read the archives for why I will not take guard() rewrites of
> staging drivers (nor do I want to see you use a LLM in here either.)
> 
> sorry,
> 
> greg k-h

Hello Greg + Everyone,


It turns out that I was unknowingly subscribed to this list and started 
creating patches for the Outreachy group without ever having submitted 
an application to Outreachy. I just wanted to learn how to contribute to 
the Linux Kernel and I saw https://kernelnewbies.org/ as a direct 
connection to Outreachy.

While I am technically not part of this cohort, I can still review 
patches. What is preferred?

I assume that the same rules apply outside of Outreachy? No LLMs and no 
guard() rewrites.

Jeremy

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

[Julia Lawall]

On Thu, 15 Oct 2026, Jeremy Dean Clifton wrote:

> On 10/13/26 12:15 AM, Greg Kroah-Hartman wrote:
> > On Mon, Oct 12, 2026 at 10:29:26PM +0000, Jeremy Dean Clifton wrote:
> > > The three return paths of nvec_write_sync() each release
> > > sync_write_mutex with explicit unlock calls.
> > >
> > > Use guard(mutex) to unlock the lock automatically on any return
> > > path.
> > >
> > > This removes the three mutex_unlock() calls.
> > >
> > > No functional change.
> > >
> > > Signed-off-by: Jeremy Dean Clifton <deaner92@yahoo.com>
> > > ---
> > > v2:
> > >   - Reword the commit message to state the motivation and to make
> > >     clear that removing the mutex_unlock() calls is the result of
> > >     the change (Julia Lawall).
> > > v1: https://lore.kernel.org/all/20261012171312.5998-1-deaner92@yahoo.com/
> >
> > Please read the archives for why I will not take guard() rewrites of
> > staging drivers (nor do I want to see you use a LLM in here either.)
> >
> > sorry,
> >
> > greg k-h
>
> Hello Greg + Everyone,
>
>
> It turns out that I was unknowingly subscribed to this list and started
> creating patches for the Outreachy group without ever having submitted an
> application to Outreachy. I just wanted to learn how to contribute to the
> Linux Kernel and I saw https://kernelnewbies.org/ as a direct connection to
> Outreachy.
>
> While I am technically not part of this cohort, I can still review patches.
> What is preferred?
>
> I assume that the same rules apply outside of Outreachy? No LLMs and no
> guard() rewrites.

Yes, to my understanding.

julia

>
> Jeremy
>
>
>