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@xxxxxxx>
> Cc: Pranith Kumar <bobby.prani@xxxxxxxxx>
> Cc: Christoph Lameter <cl@xxxxxxxxx>
> Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
