From: Julian Vetter <jvetter@kalrayinc.com>
To: Arnd Bergmann <arnd@arndb.de>,
Julian Vetter <jvetter@kalrayinc.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, guoren <guoren@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org,
loongarch@lists.linux.dev,
Yann Sionneau <ysionneau@kalrayinc.com>
Subject: Re: [PATCH v6 1/5] Consolidate __memcpy_{to,from}io and __memset_io into iomap_copy.c
Date: Fri, 27 Sep 2024 10:19:31 +0200 [thread overview]
Message-ID: <b9f3f692-d4fa-473b-9bdf-4ea73b22ccde@kalrayinc.com> (raw)
In-Reply-To: <f47e66f9-ec20-4e75-b88f-d412339e797d@app.fastmail.com>
On 26.09.24 09:14, Arnd Bergmann wrote:
> On Wed, Sep 25, 2024, at 13:24, Julian Vetter wrote:
>> Various architectures have almost the same implementations for
>> __memcpy_{to,from}io and __memset_io functions. So, consolidate them
>> into the existing lib/iomap_copy.c.
>>
>> Reviewed-by: Yann Sionneau <ysionneau@kalrayinc.com>
>> Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
>> ---
>> Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
>
> You have a duplicated signoff here.
Yes, thank you. I will remove it in the next patch revision.
>
>
>> +#ifndef __memcpy_fromio
>> +void __memcpy_fromio(void *to, const volatile void __iomem *from,
>> size_t count);
>> +#endif
>> +
>> +#ifndef __memcpy_toio
>> +void __memcpy_toio(volatile void __iomem *to, const void *from, size_t
>> count);
>> +#endif
>> +
>> +#ifndef __memset_io
>> +void __memset_io(volatile void __iomem *dst, int c, size_t count);
>> +#endif
>
> I'm not entirely sure about the purpose of the #ifdef here, since
> nothing ever overrides the double-underscore versions, both before
> and after your patches.
>
> Unless I'm missing something here, I think a more logical
> sequence would be:
>
> 1. add the definitions in this file without the underscores,
by: "...in this file..." you mean the 'lib/iomap_copy.c' file, right?
But what if an architecture does not select 'CONFIG_HAS_IOMEM'. Then
'iomap_copy.c' is not compiled and we don't have an implementation,
right? I tried to compile with ARCH=um, with some MTD chip driver, like
the robot did and it indeed fails, because um has 'NO_IOMEM' set. and
the driver uses memcpy_fromio. I mean it's a strange combination,
because apparently we try to use IO memory? Is this an invalid
combination? But shouldn't the driver then 'depends on HAS_IOMEM'?
> as memcpy_fromio/memcpy_toio/memset_io, with the #ifdef
> for that name that is always set at this point
>
Right. I will remove it in my next patch revision.
> 2. replace the default implementation in asm-generic/io.h
> with extern prototypes, remove the #define from those
>
Yes, I have done this now.
> 3. convert the other architectures, removing both the
> implementations and the prototypes.
>
I have removed the prototypes and have aligned the function arguments in
m68k, alpha, parisc, and sh, which all have their own implementation,
but had slightly different function arguments. Btw, I have not removed
their implementations because some of them seem to have optimized
implementations (e.g., alpha and m68k), that I didn't want to touch. But
you're right others (e.g., sh) just do byte wise accesses and have a
comment "This needs to be optimized." Maybe I should remove these and
let them use the new version?!
> Arnd
>
>
>
>
next prev parent reply other threads:[~2024-09-27 8:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 13:24 [PATCH v6 0/5] Consolidate IO memcpy functions Julian Vetter
2024-09-25 13:24 ` [PATCH v6 1/5] Consolidate __memcpy_{to,from}io and __memset_io into iomap_copy.c Julian Vetter
2024-09-26 7:14 ` Arnd Bergmann
2024-09-27 8:19 ` Julian Vetter [this message]
2024-09-27 10:59 ` Arnd Bergmann
2024-09-29 20:37 ` David Laight
2024-09-25 13:24 ` [PATCH v6 2/5] Replace generic memcpy and memset by IO memcpy functions Julian Vetter
2024-09-27 5:28 ` kernel test robot
2024-09-27 5:49 ` kernel test robot
2024-09-25 13:24 ` [PATCH v6 3/5] arm64: Use generic io " Julian Vetter
2024-09-25 13:24 ` [PATCH v6 4/5] csky: " Julian Vetter
2024-09-26 3:22 ` Guo Ren
2024-09-25 13:24 ` [PATCH v6 5/5] loongarch: " Julian Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9f3f692-d4fa-473b-9bdf-4ea73b22ccde@kalrayinc.com \
--to=jvetter@kalrayinc.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=guoren@kernel.org \
--cc=kernel@xen0n.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=will@kernel.org \
--cc=ysionneau@kalrayinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.