[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33199802-d83d-48e8-9032-f1c4c61cfee7@web.de>
Date: Fri, 31 Oct 2025 09:46:25 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Geert Uytterhoeven <geert@...ux-m68k.org>, sparclinux@...r.kernel.org
Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>,
Andreas Larsson <andreas@...sler.com>, Christoph Lameter <cl@...ux.com>,
"David S. Miller" <davem@...emloft.net>, Finn Thain <fthain@...ux-m68k.org>,
Tejun Heo <tj@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org, Miaoqian Lin <linmq006@...il.com>
Subject: Re: [PATCH] sparc: time: Use pointer from memcpy() call for
assignment in setup_sparc64_timer()
…>> +++ b/arch/sparc/kernel/time_64.c
>> @@ -760,9 +760,7 @@ void setup_sparc64_timer(void)
>> : /* no outputs */
>> : "r" (pstate));
>>
>> - sevt = this_cpu_ptr(&sparc64_events);
>> -
>> - memcpy(sevt, &sparc64_clockevent, sizeof(*sevt));
>> + sevt = memcpy(this_cpu_ptr(&sparc64_events), &sparc64_clockevent, sizeof(*sevt));
>
> IMHO this makes the code harder to read:
> - Only 0.15% of the memcpy() calls in the kernel use the
> memcpy() chaining feature,
I obviously propose to refactor this implementation detail.
> - The line is now longer than the 80-character limit, which is still
> customary for this file.
Would you like to get a subsequent patch variant?
Regards,
Markus
Powered by blists - more mailing lists