Thank you for your feedback Arnd. In regards to the filename, etc. I
went with the first route and created a new file called io_copy.c.
Although, I'm not sure if it's a good idea to create yet another file
that serves a limited purpose. But I'm a bit afraid to add the
functions to iomap_copy.c because there is no common consus in the
architecture code about memcpy_{from,to}io. Some specify it with
_memcpy_xx, some directly with memcpy_xx, and another bunch uses
__memcpy_xx. So, if we want to merge it with iomap_copy.c, I would need
to export the __memcpy_xx symbols for all architectures that don't want
to use the "generic" memcpy_xx functions for now or rename their given
implementation to __memcpy_xx, right? But if you think it's better to
merge the two, I will have another look and modify the code for all
remaining architectures as well.

Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>

---
Changes for v2:
- Renamed io.c -> io_copy.c
- Updated flag to 'GENERIC_IO_COPY'
- Replaced pointer dereferences by 'put_unaligned()'/'get_unaligned()'
- Replaced '#ifdef CONFIG_64BIT' by 'if(IS_ENABLED(CONFIG_64BIT))'
- Removed '__raw_{read,write}_native' and replaced by
  'if(IS_ENABLED(CONFIG_64BIT))' -> '__raw_write{l,q}'
---
Julian Vetter (4):
  Consolidate __memcpy_{to,from}io and __memset_io into a single lib
  Use generic io memcpy functions on the arm64 architecture
  Use generic io memcpy functions on the csky architecture
  Use generic io memcpy functions on the loongarch architecture

 arch/arm64/Kconfig             |   1 +
 arch/arm64/kernel/io.c         |  87 ---------------------------
 arch/csky/Kconfig              |   1 +
 arch/csky/kernel/Makefile      |   2 +-
 arch/csky/kernel/io.c          |  91 ----------------------------
 arch/loongarch/Kconfig         |   1 +
 arch/loongarch/kernel/Makefile |   2 +-
 arch/loongarch/kernel/io.c     |  94 -----------------------------
 lib/Kconfig                    |   3 +
 lib/Makefile                   |   1 +
 lib/io_copy.c                  | 107 +++++++++++++++++++++++++++++++++
 11 files changed, 116 insertions(+), 274 deletions(-)
 delete mode 100644 arch/csky/kernel/io.c
 delete mode 100644 arch/loongarch/kernel/io.c
 create mode 100644 lib/io_copy.c

-- 
2.34.1

On Mon, Sep 9, 2024, at 13:31, Julian Vetter wrote:
> Thank you for your feedback Arnd. In regards to the filename, etc. I
> went with the first route and created a new file called io_copy.c.
> Although, I'm not sure if it's a good idea to create yet another file
> that serves a limited purpose. But I'm a bit afraid to add the
> functions to iomap_copy.c because there is no common consus in the
> architecture code about memcpy_{from,to}io. Some specify it with
> _memcpy_xx, some directly with memcpy_xx, and another bunch uses
> __memcpy_xx.

Just for clarification: the idea in that file is to have a
generic implementation and use that on all architectures that
do not define their own, hence the "#define __iowrite32_copy
__iowrite32_copy" for the three that do. The exact same method
would clearly work for memcpy_fromio().

At the moment, there are 13 architectures that define a custom
memcpy_fromio/memcpy_toio/memset_io, and nine that rely on the
fallback using memcpy()/memset() in include/asm-generic/io.h.

What we could do here is to first change the fallback
implementation in asm-generic/io.h to your new generic
version and then remove the three extra copies.

> So, if we want to merge it with iomap_copy.c, I would need
> to export the __memcpy_xx symbols for all architectures that don't want
> to use the "generic" memcpy_xx functions for now or rename their given
> implementation to __memcpy_xx, right? But if you think it's better to
> merge the two, I will have another look and modify the code for all
> remaining architectures as well.

No, this would not be necessary: the architectures that
already have a custom memcpy_fromio() etc can just keep
using the same one. Cleaning those up is something we
can do later, in which case most of them would probably
converge on the generic version.

     Arnd