[PATCH] Docs: this_cpu_ops: remove redundant add forms

[PATCH] Docs: this_cpu_ops: remove redundant add forms

[Mark Rutland]

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(-)

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)
-- 
1.9.1

Re: [PATCH] Docs: this_cpu_ops: remove redundant add forms

[Christoph Lameter]

On Wed, 24 Sep 2014, Mark Rutland wrote:

> 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?

Thanks for fixing it.

Acked-by: Christoph Lameter <cl@linux.com>

Re: [PATCH] Docs: this_cpu_ops: remove redundant add forms

[Randy Dunlap]

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