[PATCH] powerpc/cputable: Use pointer from memcpy() call for assignment in set_cur_cpu_spec()

Markus Elfring posted 1 patch 3 months, 1 week ago
arch/powerpc/kernel/cputable.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
[PATCH] powerpc/cputable: Use pointer from memcpy() call for assignment in set_cur_cpu_spec()
Posted by Markus Elfring 3 months, 1 week ago
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 30 Oct 2025 21:10:11 +0100

A pointer was assigned to a variable. The same pointer was used for
the destination parameter of a memcpy() call.
This function is documented in the way that the same value is returned.
Thus convert two separate statements into a direct variable assignment for
the return value from a memory copy action.

The source code was transformed by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 arch/powerpc/kernel/cputable.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 6f6801da9dc1..a69ea88b780f 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -34,12 +34,11 @@ void __init set_cur_cpu_spec(struct cpu_spec *s)
 {
 	struct cpu_spec *t = &the_cpu_spec;
 
-	t = PTRRELOC(t);
 	/*
 	 * use memcpy() instead of *t = *s so that GCC replaces it
 	 * by __memcpy() when KASAN is active
 	 */
-	memcpy(t, s, sizeof(*t));
+	t = memcpy(PTRRELOC(t), s, sizeof(*t));
 
 	*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
 }
-- 
2.51.1
Re: [PATCH] powerpc/cputable: Use pointer from memcpy() call for assignment in set_cur_cpu_spec()
Posted by Christophe Leroy 3 months ago

Le 30/10/2025 à 21:15, Markus Elfring a écrit :
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 30 Oct 2025 21:10:11 +0100
> 
> A pointer was assigned to a variable. The same pointer was used for
> the destination parameter of a memcpy() call.
> This function is documented in the way that the same value is returned.
> Thus convert two separate statements into a direct variable assignment for
> the return value from a memory copy action.

I can't see the added value of this change. For me it degrades 
readability. Many places in cputable.c have that t = PTRRELOC(t) 
pattern, I can't see why that one should be changed while other ones remain.

Can you elaborate why this change is desirable ?

Thanks
Christophe

> 
> The source code was transformed by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   arch/powerpc/kernel/cputable.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 6f6801da9dc1..a69ea88b780f 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -34,12 +34,11 @@ void __init set_cur_cpu_spec(struct cpu_spec *s)
>   {
>   	struct cpu_spec *t = &the_cpu_spec;
>   
> -	t = PTRRELOC(t);
>   	/*
>   	 * use memcpy() instead of *t = *s so that GCC replaces it
>   	 * by __memcpy() when KASAN is active
>   	 */
> -	memcpy(t, s, sizeof(*t));
> +	t = memcpy(PTRRELOC(t), s, sizeof(*t));
>   
>   	*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
>   }

Re: [PATCH] powerpc/cputable: Use pointer from memcpy() call for assignment in set_cur_cpu_spec()
Posted by Markus Elfring 3 months ago
>> A pointer was assigned to a variable. The same pointer was used for
>> the destination parameter of a memcpy() call.
>> This function is documented in the way that the same value is returned.
>> Thus convert two separate statements into a direct variable assignment for
>> the return value from a memory copy action.
> 
> I can't see the added value of this change. For me it degrades readability.

I dared to present another coding style view.


> Many places in cputable.c have that t = PTRRELOC(t) pattern,

Several assignment statements can occur.


> I can't see why that one should be changed while other ones remain.

Copy calls influenced the suggested source code transformation.


> Can you elaborate why this change is desirable ?

I imagine that selected variable assignments might be avoidable.

Regards,
Markus