drivers/char/nvram.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
v2:
- Added missing Suggested-by tag from Ritesh Harjani (IBM)
drivers/char/nvram.c defines a static mutex 'nvram_mutex' which is never
used. This results in a compiler warning on linux-next builds:
warning: 'nvram_mutex' defined but not used [-Wunused-variable]
Remove the unused definition to avoid the warning.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
---
drivers/char/nvram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index 9eff426a9286..2ce3307663ed 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -53,7 +53,7 @@
#include <asm/nvram.h>
#endif
-static DEFINE_MUTEX(nvram_mutex);
+static __maybe_unused DEFINE_MUTEX(nvram_mutex);
static DEFINE_SPINLOCK(nvram_state_lock);
static int nvram_open_cnt; /* #times opened */
static int nvram_open_mode; /* special open modes */
--
2.45.2
Le 23/03/2026 à 08:32, Venkat Rao Bagalkote a écrit :
> v2:
> - Added missing Suggested-by tag from Ritesh Harjani (IBM)
>
Patch history must go _after_ the --- below, otherwise it will appear in
the commit message when applied, which is pointless.
> drivers/char/nvram.c defines a static mutex 'nvram_mutex' which is never
> used. This results in a compiler warning on linux-next builds:
It is probably not only linux-next builds, I think the problem exists
since 20e07af71f34 ("powerpc: Adopt nvram module for PPC64")
>
> warning: 'nvram_mutex' defined but not used [-Wunused-variable]
>
> Remove the unused definition to avoid the warning.
It is not what you are doing.
You are just hiding the probleme by saying 'maybe it is used, maybe it
is not used, I don't know I don't care". Please properly fix the problem
instead.
I think the fix is probably to remove the #ifdef CONFIG_PPC32 around
IOC_NVRAM_SYNC.
If you think it is important to return -ENOTTY on CONFIG_PPC64, just add:
diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index 9eff426a9286..2fd744bf9093 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -308,8 +308,10 @@ static long nvram_misc_ioctl(struct file *file,
unsigned int cmd,
}
#endif
break;
-#ifdef CONFIG_PPC32
case IOC_NVRAM_SYNC:
+ if (IS_ENABLED(CONFIG_PPC64))
+ break;
+
if (ppc_md.nvram_sync != NULL) {
mutex_lock(&nvram_mutex);
ppc_md.nvram_sync();
@@ -317,7 +319,6 @@ static long nvram_misc_ioctl(struct file *file,
unsigned int cmd,
}
ret = 0;
break;
-#endif
#elif defined(CONFIG_X86) || defined(CONFIG_M68K)
case NVRAM_INIT:
/* initialize NVRAM contents and checksum */
>
> Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Signed-off-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> ---
> drivers/char/nvram.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
> index 9eff426a9286..2ce3307663ed 100644
> --- a/drivers/char/nvram.c
> +++ b/drivers/char/nvram.c
> @@ -53,7 +53,7 @@
> #include <asm/nvram.h>
> #endif
>
> -static DEFINE_MUTEX(nvram_mutex);
> +static __maybe_unused DEFINE_MUTEX(nvram_mutex);
> static DEFINE_SPINLOCK(nvram_state_lock);
> static int nvram_open_cnt; /* #times opened */
> static int nvram_open_mode; /* special open modes */
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org> writes:
> Le 23/03/2026 à 08:32, Venkat Rao Bagalkote a écrit :
>> v2:
>> - Added missing Suggested-by tag from Ritesh Harjani (IBM)
>>
>
> Patch history must go _after_ the --- below, otherwise it will appear in
> the commit message when applied, which is pointless.
>
>> drivers/char/nvram.c defines a static mutex 'nvram_mutex' which is never
>> used. This results in a compiler warning on linux-next builds:
>
> It is probably not only linux-next builds, I think the problem exists
> since 20e07af71f34 ("powerpc: Adopt nvram module for PPC64")
>
>>
>> warning: 'nvram_mutex' defined but not used [-Wunused-variable]
>>
>> Remove the unused definition to avoid the warning.
>
> It is not what you are doing.
>
> You are just hiding the probleme by saying 'maybe it is used, maybe it
> is not used, I don't know I don't care".
Venkat, do cares about this warning, and hence he sent the patch in trying to fix it ;)
I think, I missed seeing the upper #ifdef block of PPC, and hence
suggested him to use __maybe_unused, instead of complicating it
further with... #if defined(CONFIG_PPC32) || defined(CONFIG_X86) || defined(CONFIG_M68K),
> Please properly fix the problem instead.
>
I agree, make sense.
> I think the fix is probably to remove the #ifdef CONFIG_PPC32 around
> IOC_NVRAM_SYNC.
> If you think it is important to return -ENOTTY on CONFIG_PPC64, just add:
>
That make sense and I should have thought of that.
However, I looked at the suggestions from Arnd, and I too agree that all
underneath function operations already do their own locking, so I agree
that we could just kill this nvram_mutex lock itself.
-ritesh
On Mon, Mar 23, 2026, at 11:14, Christophe Leroy (CS GROUP) wrote:
> Le 23/03/2026 à 08:32, Venkat Rao Bagalkote a écrit :
> diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
> index 9eff426a9286..2fd744bf9093 100644
> --- a/drivers/char/nvram.c
> +++ b/drivers/char/nvram.c
> @@ -308,8 +308,10 @@ static long nvram_misc_ioctl(struct file *file,
> unsigned int cmd,
> }
> #endif
> break;
> -#ifdef CONFIG_PPC32
> case IOC_NVRAM_SYNC:
> + if (IS_ENABLED(CONFIG_PPC64))
> + break;
> +
> if (ppc_md.nvram_sync != NULL) {
> mutex_lock(&nvram_mutex);
> ppc_md.nvram_sync();
Right, this works as well, though I still like the idea better
of removing the mutex and all its callers, leaving the locking
to be done inside of the individual operations, as they all
do.
Arnd
On Mon, Mar 23, 2026 at 01:02:20PM +0530, Venkat Rao Bagalkote wrote: > v2: > - Added missing Suggested-by tag from Ritesh Harjani (IBM) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/process/submitting-patches.rst for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
© 2016 - 2026 Red Hat, Inc.