Fwd: Need guidance regarding fixing styleguide error in rtl871x_pwrctrl.h
Hello, I had submitted following patch: ``` --- drivers/staging/rtl8712/rtl871x_pwrctrl.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/rtl8712/rtl871x_pwrctrl.h b/drivers/staging/rtl8712/rtl871x_pwrctrl.h index b35b9c792..29f8b6136 100644 --- a/drivers/staging/rtl8712/rtl871x_pwrctrl.h +++ b/drivers/staging/rtl8712/rtl871x_pwrctrl.h @@ -74,14 +74,14 @@ struct reportpwrstate_parm { struct pwrctrl_priv { struct mutex mutex_lock; - /*volatile*/ u8 rpwm; /* requested power state for fw */ + u8 rpwm; /* requested power state for fw */ /* fw current power state. updated when 1. read from HCPWM or * 2. driver lowers power level */ - /*volatile*/ u8 cpwm; - /*volatile*/ u8 tog; /* toggling */ - /*volatile*/ u8 cpwm_tog; /* toggling */ - /*volatile*/ u8 tgt_rpwm; /* wanted power state */ + u8 cpwm; + u8 tog; /* toggling */ + u8 cpwm_tog; /* toggling */ + u8 tgt_rpwm; /* wanted power state */ uint pwr_mode; uint smart_ps; uint alives; @@ -106,7 +106,7 @@ void r8712_unregister_cmd_alive(struct _adapter *padapter); void r8712_cpwm_int_hdl(struct _adapter *padapter, struct reportpwrstate_parm *preportpwrstate); void r8712_set_ps_mode(struct _adapter *padapter, uint ps_mode, - uint smart_ps); + uint smart_ps); void r8712_set_rpwm(struct _adapter *padapter, u8 val8); void r8712_flush_rwctrl_works(struct _adapter *padapter); ``` And I was asked to verify if there is some specific meaning is attached to comment here (which was causing the issue). I would be glad you could explain me how should I approach this issue? One way would be to rewrite that these variables could be defined as volatile (just add a comment) and then compile driver and see that build goes through without any error. Other way would be that try to understand what this function is supposed to be doing and then figure out author's intent of putting volatile there. How should I take decision on these (or if they are wrong approaches) ? Thanks, Ankit
On Wed, Feb 9, 2022 at 4:15 AM Ankit Pandey <itsankitkp@gmail.com> wrote:
Hello, I had submitted following patch:
``` --- drivers/staging/rtl8712/rtl871x_pwrctrl.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_pwrctrl.h b/drivers/staging/rtl8712/rtl871x_pwrctrl.h index b35b9c792..29f8b6136 100644 --- a/drivers/staging/rtl8712/rtl871x_pwrctrl.h +++ b/drivers/staging/rtl8712/rtl871x_pwrctrl.h @@ -74,14 +74,14 @@ struct reportpwrstate_parm {
struct pwrctrl_priv { struct mutex mutex_lock; - /*volatile*/ u8 rpwm; /* requested power state for fw */ + u8 rpwm; /* requested power state for fw */ /* fw current power state. updated when 1. read from HCPWM or * 2. driver lowers power level */ - /*volatile*/ u8 cpwm; - /*volatile*/ u8 tog; /* toggling */ - /*volatile*/ u8 cpwm_tog; /* toggling */ - /*volatile*/ u8 tgt_rpwm; /* wanted power state */ + u8 cpwm; + u8 tog; /* toggling */ + u8 cpwm_tog; /* toggling */ + u8 tgt_rpwm; /* wanted power state */ uint pwr_mode; uint smart_ps; uint alives; @@ -106,7 +106,7 @@ void r8712_unregister_cmd_alive(struct _adapter *padapter); void r8712_cpwm_int_hdl(struct _adapter *padapter, struct reportpwrstate_parm *preportpwrstate); void r8712_set_ps_mode(struct _adapter *padapter, uint ps_mode, - uint smart_ps); + uint smart_ps); void r8712_set_rpwm(struct _adapter *padapter, u8 val8); void r8712_flush_rwctrl_works(struct _adapter *padapter); ``` And I was asked to verify if there is some specific meaning is attached to comment here (which was causing the issue). I would be glad you could explain me how should I approach this issue? One way would be to rewrite that these variables could be defined as volatile (just add a comment) and then compile driver and see that build goes through without any error. Other way would be that try to understand what this function is supposed to be doing and then figure out author's intent of putting volatile there. How should I take decision on these (or if they are wrong approaches) ?
You need to think how you can come to the point that you understand the intent and the effect of the change you are proposing for the future use and maintenance of this code. Both suggestions you made might help to understand that. By the way, there are much more critical topics to work on in the kernel than purely stylistic issues. You might want to look into those more critical issues. If you need a pointer or two, just let me know. Lukas
Thanks, Ankit
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 08 Feb 2022 23:26:54 +0530, Ankit Pandey said:
And I was asked to verify if there is some specific meaning is attached to comment here (which was causing the issue). I would be glad you could explain me how should I approach this issue? One way would be to rewrite that these variables could be defined as volatile (just add a comment) and then compile driver and see that build goes through without any error.
It turns out that the C keyword 'volatile' usually doesn't actually do what needs to happen if a variable actually *is* volatile and subject to change while the executing thread isn't looking. There's a good documentation file on this: Documentation/process/volatile-considered-harmful.rst But in summary - "If you thought you needed 'volatile' in your code, you probably needed locking primitives instead".
Other way would be that try to understand what this function is supposed to be doing and then figure out author's intent of putting volatile there. How should I take decision on these (or if they are wrong approaches) ?
Given that struct pwrctlr_priv already contains a mutex_lock, what was probably *intended* was "the variables cpwm, tog, cpwm_tog, and tgt_rpwm are protected by the mutex_lock and may only be changed by the mutex holder, while pwr_mode, smart_ps, and alives are not subject to change on the fly". But actually reading and understanding the code would be required to verify that.
Thanks a lot Valdis. These are very helpful pointers to look into. Regards, Ankit On Wed, Feb 9, 2022 at 10:06 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Tue, 08 Feb 2022 23:26:54 +0530, Ankit Pandey said:
And I was asked to verify if there is some specific meaning is attached to comment here (which was causing the issue). I would be glad you could explain me how should I approach this issue? One way would be to rewrite that these variables could be defined as volatile (just add a comment) and then compile driver and see that build goes through without any error.
It turns out that the C keyword 'volatile' usually doesn't actually do what needs to happen if a variable actually *is* volatile and subject to change while the executing thread isn't looking.
There's a good documentation file on this:
Documentation/process/volatile-considered-harmful.rst
But in summary - "If you thought you needed 'volatile' in your code, you probably needed locking primitives instead".
Other way would be that try to understand what this function is supposed to be doing and then figure out author's intent of putting volatile there. How should I take decision on these (or if they are wrong approaches) ?
Given that struct pwrctlr_priv already contains a mutex_lock, what was probably *intended* was "the variables cpwm, tog, cpwm_tog, and tgt_rpwm are protected by the mutex_lock and may only be changed by the mutex holder, while pwr_mode, smart_ps, and alives are not subject to change on the fly".
But actually reading and understanding the code would be required to verify that.
On Wed, Feb 9, 2022 at 11:36 AM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
... It turns out that the C keyword 'volatile' usually doesn't actually do what needs to happen if a variable actually *is* volatile and subject to change while the executing thread isn't looking.
There's a good documentation file on this:
Documentation/process/volatile-considered-harmful.rst
Also see Ian Lance Taylor's https://www.airs.com/blog/archives/154. He's a GCC dev, and he explains how GCC interprets the keyword. Jeff
participants (4)
-
Ankit Pandey -
Jeffrey Walton -
Lukas Bulwahn -
Valdis Klētnieks