From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Ankit Pandey <itsankitkp@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Fwd: Need guidance regarding fixing styleguide error in rtl871x_pwrctrl.h
Date: Wed, 09 Feb 2022 11:36:34 -0500 [thread overview]
Message-ID: <76570.1644424594@turing-police> (raw)
In-Reply-To: <CALbMxBxS=ku3mY80VXhwGLhPhH220fWbuZFZ7GKjRc2DxEJ+Fg@mail.gmail.com>
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.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2022-02-09 16:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CALbMxBxHhhaFGvtxxtfVsgv_PqEHgV-5SU=Xy8b_=y8OBeW_Xw@mail.gmail.com>
2022-02-08 17:56 ` Fwd: Need guidance regarding fixing styleguide error in rtl871x_pwrctrl.h Ankit Pandey
2022-02-09 9:32 ` Lukas Bulwahn
2022-02-09 16:36 ` Valdis Klētnieks [this message]
2022-02-09 16:40 ` Fwd: " Ankit Pandey
2022-02-09 20:49 ` Jeffrey Walton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76570.1644424594@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=itsankitkp@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.