[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251031095132.3db72d29@pumpkin>
Date: Fri, 31 Oct 2025 09:51:32 +0000
From: David Laight <david.laight.linux@...il.com>
To: Markus Elfring <Markus.Elfring@....de>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, sparclinux@...r.kernel.org,
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()
On Fri, 31 Oct 2025 09:46:25 +0100
Markus Elfring <Markus.Elfring@....de> wrote:
> …>> +++ 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.
Reduce it to 0% and the kernel memcpy() can be made 'void'. :-)
That will simplify the architecture specific implementations.
The same can be done for strcpy() and strcat() (etc).
Where the 'useful' return value would be the address of the '\0'.
David
Powered by blists - more mailing lists