| Message ID | 20240909133159.2024688-1-jvetter@kalrayinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Consolidate IO memcpy functions | expand |
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
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