fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
Documentation/process/volatile-considered-harmful.rst
Signed-off-by: MugilRaj <[email protected]>
---
drivers/staging/speakup/speakup_decext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/speakup_decext.c b/drivers/staging/speakup/speakup_decext.c
index ddbb7e9..22baaeb 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -21,7 +21,7 @@
#define SYNTH_CLEAR 0x03
#define PROCSPEECH 0x0b
-static volatile unsigned char last_char;
+static unsigned char last_char;
static void read_buff_add(u_char ch)
{
--
2.7.4
Hello,
MugilRaj, le ven. 22 mai 2020 14:46:28 +0530, a ecrit:
> fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
> Documentation/process/volatile-considered-harmful.rst
Yes, but the proper fix is usually not to just remove the volatile
qualifier, which will not fix anything and potentially break things.
Fixing this requires really understanding what is at stake here, between
the read_buff_add function and the use of synth_full(). That goes
through interrupt handlers, tty disciplines, and the actual behavior
expected by speakup. Not a simple task, henceforth :)
> Signed-off-by: MugilRaj <[email protected]>
> ---
> drivers/staging/speakup/speakup_decext.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/speakup/speakup_decext.c b/drivers/staging/speakup/speakup_decext.c
> index ddbb7e9..22baaeb 100644
> --- a/drivers/staging/speakup/speakup_decext.c
> +++ b/drivers/staging/speakup/speakup_decext.c
> @@ -21,7 +21,7 @@
> #define SYNTH_CLEAR 0x03
> #define PROCSPEECH 0x0b
>
> -static volatile unsigned char last_char;
> +static unsigned char last_char;
>
> static void read_buff_add(u_char ch)
> {
> --
> 2.7.4
>
On Fri, May 22, 2020 at 02:46:28PM +0530, MugilRaj wrote:
> fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
> Documentation/process/volatile-considered-harmful.rst
> Signed-off-by: MugilRaj <[email protected]>
As Samuel said, you can't "just remove this", otherwise it would have
been done a long time ago, don't you think?
But for your next patch, you need to have a blank line before the
signed-off-by: line in order for it to be in a format the patch could be
merged in.
thanks,
greg k-h
On Fri, May 22, 2020 at 02:46:28PM +0530, MugilRaj wrote:
> fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
> Documentation/process/volatile-considered-harmful.rst
> Signed-off-by: MugilRaj <[email protected]>
Please put a blank before the Signed-off-by line.
Probably there should be a space between your first and last name. It's
supposed to your legal name like for signing a legal document so use
whatever is appropriate legal documents in your country.
Also the Documentation/process/volatile-considered-harmful.rst explains
that people often use "volatile" when they should be using locking for
synchronization. That seems to be the case here. So the correct fix is
to add locking. That's a little bit complicated to do and requires
testing.
If we apply this patch, then we have silenced the warning so now someone
will have to look for the bug. But if we leave it as-is, then everyone
will know that the code is buggy. So let's leave it as-is until we are
able to fix the bug.
It's always better to have easy to find bugs, than hidden bugs.
regards,
dan carpenter
On Fri, 2020-05-22 at 13:34 +0300, Dan Carpenter wrote:
> On Fri, May 22, 2020 at 02:46:28PM +0530, MugilRaj wrote:
> > fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
> > Documentation/process/volatile-considered-harmful.rst
> > Signed-off-by: MugilRaj <[email protected]>
>
> Please put a blank before the Signed-off-by line.
>
> Probably there should be a space between your first and last name. It's
> supposed to your legal name like for signing a legal document so use
> whatever is appropriate legal documents in your country.
>
> Also the Documentation/process/volatile-considered-harmful.rst explains
> that people often use "volatile" when they should be using locking for
> synchronization. That seems to be the case here. So the correct fix is
> to add locking. That's a little bit complicated to do and requires
> testing.
>
> If we apply this patch, then we have silenced the warning so now someone
> will have to look for the bug. But if we leave it as-is, then everyone
> will know that the code is buggy. So let's leave it as-is until we are
> able to fix the bug.
>
> It's always better to have easy to find bugs, than hidden bugs.
And better still to comment known opportunities to
improve the code so the next time someone tries to
remove this volatile, there's a comment right there
showing what's necessary instead.
Something like:
---
drivers/staging/speakup/speakup_decext.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/speakup/speakup_decext.c b/drivers/staging/speakup/speakup_decext.c
index 7408eb29cf38..e68e6046bb51 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -21,6 +21,7 @@
#define SYNTH_CLEAR 0x03
#define PROCSPEECH 0x0b
+/* TODO: Remove volatile, maybe add locks to read_buff_add and synth_full() ? */
static volatile unsigned char last_char;
static void read_buff_add(u_char ch)
Joe Perches, le ven. 22 mai 2020 09:36:05 -0700, a ecrit:
> On Fri, 2020-05-22 at 13:34 +0300, Dan Carpenter wrote:
> > On Fri, May 22, 2020 at 02:46:28PM +0530, MugilRaj wrote:
> > > fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
> > > Documentation/process/volatile-considered-harmful.rst
> > > Signed-off-by: MugilRaj <[email protected]>
> >
> > Please put a blank before the Signed-off-by line.
> >
> > Probably there should be a space between your first and last name. It's
> > supposed to your legal name like for signing a legal document so use
> > whatever is appropriate legal documents in your country.
> >
> > Also the Documentation/process/volatile-considered-harmful.rst explains
> > that people often use "volatile" when they should be using locking for
> > synchronization. That seems to be the case here. So the correct fix is
> > to add locking. That's a little bit complicated to do and requires
> > testing.
> >
> > If we apply this patch, then we have silenced the warning so now someone
> > will have to look for the bug. But if we leave it as-is, then everyone
> > will know that the code is buggy. So let's leave it as-is until we are
> > able to fix the bug.
> >
> > It's always better to have easy to find bugs, than hidden bugs.
>
> And better still to comment known opportunities to
> improve the code so the next time someone tries to
> remove this volatile, there's a comment right there
> showing what's necessary instead.
Actually I don't think adding the suggestion is a good thing if it's
only a "rule-of-thumb-replace-volatile-with-lock".
Actually possibly volatile might not even be needed because there could
be already a lock protecting this.
Put another way: I don't think putting any hint here would help, on the
contrary, somebody has to really look at what protection is needed,
without getting influenced by rules-of-thumb.
Samuel
On Fri, 2020-05-22 at 19:13 +0200, Samuel Thibault wrote:
> Joe Perches, le ven. 22 mai 2020 09:36:05 -0700, a ecrit:
> > On Fri, 2020-05-22 at 13:34 +0300, Dan Carpenter wrote:
> > > On Fri, May 22, 2020 at 02:46:28PM +0530, MugilRaj wrote:
> > > > fix checkpatch.pl warning, which is Use of volatile is usually wrong: see
> > > > Documentation/process/volatile-considered-harmful.rst
> > > > Signed-off-by: MugilRaj <[email protected]>
> > >
> > > Please put a blank before the Signed-off-by line.
> > >
> > > Probably there should be a space between your first and last name. It's
> > > supposed to your legal name like for signing a legal document so use
> > > whatever is appropriate legal documents in your country.
> > >
> > > Also the Documentation/process/volatile-considered-harmful.rst explains
> > > that people often use "volatile" when they should be using locking for
> > > synchronization. That seems to be the case here. So the correct fix is
> > > to add locking. That's a little bit complicated to do and requires
> > > testing.
> > >
> > > If we apply this patch, then we have silenced the warning so now someone
> > > will have to look for the bug. But if we leave it as-is, then everyone
> > > will know that the code is buggy. So let's leave it as-is until we are
> > > able to fix the bug.
> > >
> > > It's always better to have easy to find bugs, than hidden bugs.
> >
> > And better still to comment known opportunities to
> > improve the code so the next time someone tries to
> > remove this volatile, there's a comment right there
> > showing what's necessary instead.
>
> Actually I don't think adding the suggestion is a good thing if it's
> only a "rule-of-thumb-replace-volatile-with-lock".
>
> Actually possibly volatile might not even be needed because there could
> be already a lock protecting this.
>
> Put another way: I don't think putting any hint here would help, on the
> contrary, somebody has to really look at what protection is needed,
> without getting influenced by rules-of-thumb.
checkpatch newbies/robots will submit this change again otherwise.
Comment wording can always be improved.
Joe Perches, le ven. 22 mai 2020 10:22:03 -0700, a ecrit:
> > Put another way: I don't think putting any hint here would help, on the
> > contrary, somebody has to really look at what protection is needed,
> > without getting influenced by rules-of-thumb.
>
> checkpatch newbies/robots will submit this change again otherwise.
Ah, ok, right.
I don't think removing volatiles is a thing for newbies,
> Comment wording can always be improved.
I'd then suggest
/* TODO: determine what proper synchronization "volatile" should be
* replaced with. */
Samuel
I did *really look* at the code when I was reviewing this patch. :P
regards,
dan carpenter