From: Randy Dunlap <rdunlap@infradead.org>
To: Mark Rutland <mark.rutland@arm.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Cc: Pranith Kumar <bobby.prani@gmail.com>, Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH] Docs: this_cpu_ops: remove redundant add forms
Date: Thu, 25 Sep 2014 10:18:32 -0700 [thread overview]
Message-ID: <54244E68.90109@infradead.org> (raw)
In-Reply-To: <1411566583-22220-1-git-send-email-mark.rutland@arm.com>
On 09/24/14 06:49, Mark Rutland wrote:
> Hi,
>
> I spotted the below while trying to figure out how to use this_cpu ops,
> and it left me confused for a short while.
>
> I guess that this is a refactoring fallout rather than there being a
> special this_cpu_add variant?
>
> Mark.
>
> ---->8----
> Commit ac490f4dca94 (Documentation: this_cpu_ops.txt: Update description
> of this_cpu_ops) added lists of {__,}this_cpu operations, but these have
> duplicate, parameter-less entries for {__,}this_cpu_add which don't
> correspond to any implementation. No other operations have such
> duplicate entries.
>
> Given both are also listed with their full complement of arguments, the
> empty forms are redundant and can be removed. This patch performs said
> removal.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Pranith Kumar <bobby.prani@gmail.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> ---
> Documentation/this_cpu_ops.txt | 2 --
> 1 file changed, 2 deletions(-)
Applied, thanks.
> diff --git a/Documentation/this_cpu_ops.txt b/Documentation/this_cpu_ops.txt
> index 0ec9957..2cbf719 100644
> --- a/Documentation/this_cpu_ops.txt
> +++ b/Documentation/this_cpu_ops.txt
> @@ -41,7 +41,6 @@ The following this_cpu() operations with implied preemption protection
> are defined. These operations can be used without worrying about
> preemption and interrupts.
>
> - this_cpu_add()
> this_cpu_read(pcp)
> this_cpu_write(pcp, val)
> this_cpu_add(pcp, val)
> @@ -225,7 +224,6 @@ still occur while an operation is in progress and if the interrupt too
> modifies the variable, then RMW actions can not be guaranteed to be
> safe.
>
> - __this_cpu_add()
> __this_cpu_read(pcp)
> __this_cpu_write(pcp, val)
> __this_cpu_add(pcp, val)
>
--
~Randy
prev parent reply other threads:[~2014-09-25 17:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 13:49 [PATCH] Docs: this_cpu_ops: remove redundant add forms Mark Rutland
2014-09-24 14:40 ` Christoph Lameter
2014-09-25 17:18 ` Randy Dunlap [this message]
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=54244E68.90109@infradead.org \
--to=rdunlap@infradead.org \
--cc=bobby.prani@gmail.com \
--cc=cl@linux.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
/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.