[PATCH v11 0/4] Replace fallback for IO memcpy and IO memset

Julian Vetter posted 4 patches 3 weeks, 6 days ago
arch/arm64/include/asm/io.h     |  11 ---
arch/arm64/kernel/io.c          |  87 --------------------
arch/csky/include/asm/io.h      |  11 ---
arch/csky/kernel/Makefile       |   2 +-
arch/csky/kernel/io.c           |  91 ---------------------
arch/loongarch/include/asm/io.h |  10 ---
arch/loongarch/kernel/Makefile  |   2 +-
arch/loongarch/kernel/io.c      |  94 ----------------------
include/asm-generic/io.h        |  22 +-----
lib/Makefile                    |   2 +-
lib/iomem_copy.c                | 136 ++++++++++++++++++++++++++++++++
11 files changed, 142 insertions(+), 326 deletions(-)
delete mode 100644 arch/csky/kernel/io.c
delete mode 100644 arch/loongarch/kernel/io.c
create mode 100644 lib/iomem_copy.c
[PATCH v11 0/4] Replace fallback for IO memcpy and IO memset
Posted by Julian Vetter 3 weeks, 6 days ago
Thank you Arnd for your feedback and no problem. I should have asked
before, to clarify what you meant. I have now addressed what you
proposed. I have kept the iomem_copy.c and only made the minimal changes
to asm-generic/io.h and kept them in place just modifiying the content.
Not sure though about the commit message of patch 1. Let me know if I
should rephrase it.

Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
---
Changes for v11:
- Restored iomem_copy.c
- Updated asm-generic/io.h to just contain the changes suggested by Arnd

Changes for v10:
- Removed libs/iomem_copy.c again
- Replaced the three functions in asm-generic/io.h directly
- Updated description for the first patch to clarify the matter
- Slightly updated description in patches 2 to 4

Changes for v9:
- Moved functions into a new file iomem_copy.c which is built
  unconditionally
- Guard prototypes with '#ifndef memcpy_fromio', etc.
- Dropped patches 5 to 14 for now. I will send some of the changes in
  separate patches or patchsets to the appropriate mailinglists
- Added proper reviewed-by and acked-by to arm64 and csky patches

Changes for v8:
- Dropped the arch/um patch that adds dummy implementations for IO
  memcpy functions
- Added 3 new patches that fix the dependency problem for UM (added
  dependencies on HAS_IOMEM || INDIRECT_IOMEM)
- Added new patch for s390 to internally call the zpci_memcpy functions
  and not the generic ones from libs/iomap_copy.c
- Addressed reviewer comments and replaced 2 or 3 shifts by
  'qc *= ~0UL / 0xff;'
- Addressed reviewer comments on pasrisc (masking the int value)
- Addressed reviewer comments on alpha (masking the int value)

Changes for v7:
- Added dummy implementations for memcpy_{to,from}io and memset_io on um
  architecture so drivers that use these functions build for um
- Replaced all accesses and checks by long type
- Added function prototypes as extern to asm-generic/io.h
- Removed '__' from the 3 new function names
- Some archs implement their own version of these IO functions with
  slightly different prototypes. So, I added 3 new patches to align
  prototypes with new ones in iomap_copy.c + io.h

Changes for v6:
- Added include of linux/align.h to fix build on arm arch
- Replaced compile-time check by ifdef for the CONFIG_64BIT otherwise we
  get a warning for the 'qc << 32' for archs with 32bit int types
- Suffixed arch commits by arch name

Changes for v5:
- Added functions to iomap_copy.c as proposed by Arndt
- Removed again the new io_copy.c and related objects
- Removed GENERIC_IO_COPY symbol and instead rely on the existing
  HAS_IOMEM symbol
- Added prototypes of __memcpy_{to,from}io and __memset_io functions to
  asm-generic/io.h

Changes for v4:
- Replaced memcpy/memset in asm-generic/io.h by the new
  __memcpy_{to,from}io and __memset_io, so individual architectures can
  use it instead of using their own implementation.

Changes for v3:
- Replaced again 'if(IS_ENABLED(CONFIG_64BIT))' by '#ifdef CONFIG_64BIT'
  because on 32bit architectures (e.g., csky), __raw_{read,write}q are
  not defined. So, it leads to compilation errors

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):
  New implementation for IO memcpy and IO memset
  arm64: Use new fallback IO memcpy/memset
  csky: Use new fallback IO memcpy/memset
  loongarch: Use new fallback IO memcpy/memset

 arch/arm64/include/asm/io.h     |  11 ---
 arch/arm64/kernel/io.c          |  87 --------------------
 arch/csky/include/asm/io.h      |  11 ---
 arch/csky/kernel/Makefile       |   2 +-
 arch/csky/kernel/io.c           |  91 ---------------------
 arch/loongarch/include/asm/io.h |  10 ---
 arch/loongarch/kernel/Makefile  |   2 +-
 arch/loongarch/kernel/io.c      |  94 ----------------------
 include/asm-generic/io.h        |  22 +-----
 lib/Makefile                    |   2 +-
 lib/iomem_copy.c                | 136 ++++++++++++++++++++++++++++++++
 11 files changed, 142 insertions(+), 326 deletions(-)
 delete mode 100644 arch/csky/kernel/io.c
 delete mode 100644 arch/loongarch/kernel/io.c
 create mode 100644 lib/iomem_copy.c

-- 
2.34.1
Re: [PATCH v11 0/4] Replace fallback for IO memcpy and IO memset
Posted by Arnd Bergmann 3 weeks, 6 days ago
On Mon, Oct 28, 2024, at 13:42, Julian Vetter wrote:
> Thank you Arnd for your feedback and no problem. I should have asked
> before, to clarify what you meant. I have now addressed what you
> proposed. I have kept the iomem_copy.c and only made the minimal changes
> to asm-generic/io.h and kept them in place just modifiying the content.
> Not sure though about the commit message of patch 1. Let me know if I
> should rephrase it.
>
> Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
> ---
> Changes for v11:
> - Restored iomem_copy.c
> - Updated asm-generic/io.h to just contain the changes suggested by Arnd

I've applied it to the asm-generic tree now.

It's always possible to improve the commit messages, but I'll
call this good enough, as it's more important to give this some
time testing in linux-next.

Thanks for your work work on this!

     Arnd