From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Julian Vetter <jvetter@kalrayinc.com>,
Arnd Bergmann <arnd@arndb.de>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Andrew Morton <akpm@linux-foundation.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
"James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Naveen N Rao <naveen@kernel.org>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org,
loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org,
linux-alpha@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-sh@vger.kernel.org, linux-um@lists.infradead.org,
linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, mhi@lists.linux.dev,
linux-arm-msm@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-sound@vger.kernel.org,
Yann Sionneau <ysionneau@kalrayinc.com>
Subject: Re: [PATCH v8 11/14] s390: Add wrappers around zpci_memcpy/zpci_memset
Date: Tue, 08 Oct 2024 15:42:23 +0200 [thread overview]
Message-ID: <e8026d75acfcf0eebc7bdb95120efe86c23bb917.camel@linux.ibm.com> (raw)
In-Reply-To: <20241008075023.3052370-12-jvetter@kalrayinc.com>
On Tue, 2024-10-08 at 09:50 +0200, Julian Vetter wrote:
> Add wrapper functions around zpci_memcpy_{from,to}io and zpci_memset_io,
> which have aligned prototypes with the ones from iomap_copy.c. These
> wrappers are necessary because the prototypes of the zpci_ functions
> can't be changed. In s390 arch code they are directly being called and
> the return value is checked, At the same time they serve as generic
> memcpy_{from,to}io and memset_io functions, without a return value.
>
> Reviewed-by: Yann Sionneau <ysionneau@kalrayinc.com>
> Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
> ---
> Changes for v8:
> - New patch
> ---
> arch/s390/include/asm/io.h | 27 +++++++++++++++++++++++----
> arch/s390/include/asm/pci_io.h | 6 +++---
> 2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
> index 0fbc992d7a5e..f3ef6d4130b3 100644
> --- a/arch/s390/include/asm/io.h
> +++ b/arch/s390/include/asm/io.h
> @@ -58,10 +58,6 @@ static inline void ioport_unmap(void __iomem *p)
> #define pci_iomap_wc pci_iomap_wc
> #define pci_iomap_wc_range pci_iomap_wc_range
>
> -#define memcpy_fromio(dst, src, count) zpci_memcpy_fromio(dst, src, count)
> -#define memcpy_toio(dst, src, count) zpci_memcpy_toio(dst, src, count)
> -#define memset_io(dst, val, count) zpci_memset_io(dst, val, count)
> -
> #define mmiowb() zpci_barrier()
>
> #define __raw_readb zpci_read_u8
> @@ -73,6 +69,10 @@ static inline void ioport_unmap(void __iomem *p)
> #define __raw_writel zpci_write_u32
> #define __raw_writeq zpci_write_u64
>
> +#define memcpy_fromio memcpy_fromio
> +#define memcpy_toio memcpy_toio
> +#define memset_io memset_io
> +
> /* combine single writes by using store-block insn */
> static inline void __iowrite32_copy(void __iomem *to, const void *from,
> size_t count)
> @@ -88,6 +88,25 @@ static inline void __iowrite64_copy(void __iomem *to, const void *from,
> }
> #define __iowrite64_copy __iowrite64_copy
>
> +static inline void memcpy_fromio(void *dst, const volatile void __iomem *src,
> + size_t n)
> +{
> + zpci_memcpy_fromio(dst, src, n);
> +}
> +
> +static inline void memcpy_toio(volatile void __iomem *dst,
> + const void *src, size_t n)
> +{
> + zpci_memcpy_toio(dst, src, n);
> +}
> +
> +static inline void memset_io(volatile void __iomem *dst,
> + int val, size_t count)
> +{
> + zpci_memset_io(dst, val, count);
> +}
> +
> +
> #endif /* CONFIG_PCI */
>
> #include <asm-generic/io.h>
> diff --git a/arch/s390/include/asm/pci_io.h b/arch/s390/include/asm/pci_io.h
> index 2686bee800e3..43a5ea4ee20f 100644
> --- a/arch/s390/include/asm/pci_io.h
> +++ b/arch/s390/include/asm/pci_io.h
> @@ -143,7 +143,7 @@ static inline int zpci_get_max_io_size(u64 src, u64 dst, int len, int max)
>
> static inline int zpci_memcpy_fromio(void *dst,
> const volatile void __iomem *src,
> - unsigned long n)
> + size_t n)
> {
> int size, rc = 0;
>
> @@ -162,7 +162,7 @@ static inline int zpci_memcpy_fromio(void *dst,
> }
>
> static inline int zpci_memcpy_toio(volatile void __iomem *dst,
> - const void *src, unsigned long n)
> + const void *src, size_t n)
> {
> int size, rc = 0;
>
> @@ -187,7 +187,7 @@ static inline int zpci_memcpy_toio(volatile void __iomem *dst,
> }
>
> static inline int zpci_memset_io(volatile void __iomem *dst,
> - unsigned char val, size_t count)
> + int val, size_t count)
> {
> u8 *src = kmalloc(count, GFP_KERNEL);
> int rc;
The code makes sense to me. If I understand Arnd's comment correctly
the wrappers may not be necessary if you don't have the global
prototypes though, right? In this case I think we might want to still
align the parameter types as this seems generally cleaner and the
internal callers already use size_t anyway.
Either way I gave the whole series a quick test on s390x with PCI
devices and all looks good. So feel free to add:
Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
next prev parent reply other threads:[~2024-10-08 13:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 7:50 [PATCH v8 00/14] Consolidate IO memcpy functions Julian Vetter
2024-10-08 7:50 ` [PATCH v8 01/14] Consolidate IO memcpy/memset into iomap_copy.c Julian Vetter
2024-10-08 9:27 ` Arnd Bergmann
2024-10-08 9:32 ` Christoph Hellwig
2024-10-08 11:46 ` Christoph Hellwig
2024-10-08 12:29 ` Arnd Bergmann
2024-10-08 7:50 ` [PATCH v8 02/14] arm64: Use generic IO memcpy/memset Julian Vetter
2024-10-08 7:50 ` [PATCH v8 03/14] csky: " Julian Vetter
2024-10-08 7:50 ` [PATCH v8 04/14] loongarch: " Julian Vetter
2024-10-08 7:50 ` [PATCH v8 05/14] m68k: Align prototypes of " Julian Vetter
2024-10-08 7:50 ` [PATCH v8 06/14] alpha: " Julian Vetter
2024-10-08 14:54 ` Richard Henderson
2024-10-08 7:50 ` [PATCH v8 07/14] parisc: " Julian Vetter
2024-10-08 7:50 ` [PATCH v8 08/14] sh: " Julian Vetter
2024-10-08 7:50 ` [PATCH v8 09/14] arm: Align prototype of IO memset Julian Vetter
2024-10-08 7:50 ` [PATCH v8 10/14] powerpc: Align prototypes of IO memcpy and memset Julian Vetter
2024-10-08 7:50 ` [PATCH v8 11/14] s390: Add wrappers around zpci_memcpy/zpci_memset Julian Vetter
2024-10-08 13:42 ` Niklas Schnelle [this message]
2024-10-08 7:50 ` [PATCH v8 12/14] bus: mhi: ep: Add HAS_IOMEM || INDIRECT_IOMEM dependency Julian Vetter
2024-10-08 7:50 ` [PATCH v8 13/14] mtd: " Julian Vetter
2024-10-08 8:33 ` Miquel Raynal
2024-10-08 7:50 ` [PATCH v8 14/14] sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML Julian Vetter
2024-10-08 8:16 ` Takashi Iwai
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=e8026d75acfcf0eebc7bdb95120efe86c23bb917.camel@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=anton.ivanov@cambridgegreys.com \
--cc=arnd@arndb.de \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dalias@libc.org \
--cc=deller@gmx.de \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=gor@linux.ibm.com \
--cc=guoren@kernel.org \
--cc=hca@linux.ibm.com \
--cc=ink@jurassic.park.msu.ru \
--cc=johannes@sipsolutions.net \
--cc=jvetter@kalrayinc.com \
--cc=kernel@xen0n.name \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=maddy@linux.ibm.com \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mattst88@gmail.com \
--cc=mhi@lists.linux.dev \
--cc=miquel.raynal@bootlin.com \
--cc=mpe@ellerman.id.au \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=perex@perex.cz \
--cc=richard.henderson@linaro.org \
--cc=richard@nod.at \
--cc=svens@linux.ibm.com \
--cc=tiwai@suse.com \
--cc=vigneshr@ti.com \
--cc=will@kernel.org \
--cc=ysato@users.sourceforge.jp \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).