All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christoph Hellwig" <hch@lst.de>, "Arnd Bergmann" <arnd@kernel.org>
Cc: linux-kernel@vger.kernel.org, "Vineet Gupta" <vgupta@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, guoren <guoren@kernel.org>,
	"Brian Cain" <bcain@quicinc.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Michal Simek" <monstr@monstr.eu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Dinh Nguyen" <dinguyen@kernel.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Rich Felker" <dalias@libc.org>,
	"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>,
	"David S . Miller" <davem@davemloft.net>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"Conor.Dooley" <conor.dooley@microchip.com>,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"linux-oxnas@groups.io" <linux-oxnas@groups.io>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	"linux-openrisc@vger.kernel.org" <linux-openrisc@vger.kernel.org>,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Date: Fri, 31 Mar 2023 15:04:23 +0200	[thread overview]
Message-ID: <f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com> (raw)
In-Reply-To: <20230327222514.GA17904@lst.de>

On Tue, Mar 28, 2023, at 00:25, Christoph Hellwig wrote:
>> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback(paddr, size);
>> +}
>>  
>> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> +{
>> +	dma_cache_inv(paddr, size);
>>  }
>
>> +static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback_inv(paddr, size);
>> +}
>
> There are the only calls for the three functions for each of the
> involved functions.  So I'd rather rename the low-level symbols
> (and drop the pointless exports for two of them) rather than adding
> these wrapppers.
>
> The same is probably true for many other architectures.

Ok, done that now.

>> +static inline bool arch_sync_dma_clean_before_fromdevice(void)
>> +{
>> +	return false;
>> +}
>>  
>> +static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
>> +{
>> +	return true;
>>  }
>
> Is there a way to cut down on this boilerplate code by just having
> sane default, and Kconfig options to override them if they are not
> runtime decisions?

I've changed arch_sync_dma_clean_before_fromdevice() to a
Kconfig symbol now, as this is never a runtime decision.

For arch_sync_dma_cpu_needs_post_dma_flush(), I have this
version now in common code, which lets mips and arm have
their own logic and has the same effect elsewhere:

+#ifndef arch_sync_dma_cpu_needs_post_dma_flush
+static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
+{
+       return IS_ENABLED(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU);
+}
+#endif

>> +#include <linux/dma-sync.h>
>
> I can't really say I like the #include version here despite your
> rationale in the commit log.  I can probably live with it if you
> think it is absolutely worth it, but I'm really not in favor of it.
>
>> +config ARCH_DMA_MARK_DCACHE_CLEAN
>> +	def_bool y
>
> What do we need this symbol for?  Unless I'm missing something it is
> always enable for arm32, and only used in arm32 code.

This was left over from an earlier draft and accidentally duplicates
the thing that I have in the Arm version for the existing
ARCH_HAS_DMA_MARK_CLEAN. I dropped this one and the
generic copy of the arch_dma_mark_dcache_clean() function
now, but still need to revisit the arm version, as it sounds
like it has slightly different semantics from the ia64 version.

     Arnd

WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christoph Hellwig" <hch@lst.de>, "Arnd Bergmann" <arnd@kernel.org>
Cc: linux-kernel@vger.kernel.org, "Vineet Gupta" <vgupta@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, guoren <guoren@kernel.org>,
	"Brian Cain" <bcain@quicinc.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Michal Simek" <monstr@monstr.eu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Dinh Nguyen" <dinguyen@kernel.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Rich Felker" <dalias@libc.org>,
	"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>,
	"David S . Miller" <davem@davemloft.net>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"Conor.Dooley" <conor.dooley@microchip.com>,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"linux-oxnas@groups.io" <linux-oxnas@groups.io>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	"linux-openrisc@vger.kernel.org" <linux-openrisc@vger.kernel.org>,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Date: Fri, 31 Mar 2023 15:04:23 +0200	[thread overview]
Message-ID: <f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com> (raw)
In-Reply-To: <20230327222514.GA17904@lst.de>

On Tue, Mar 28, 2023, at 00:25, Christoph Hellwig wrote:
>> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback(paddr, size);
>> +}
>>  
>> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> +{
>> +	dma_cache_inv(paddr, size);
>>  }
>
>> +static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback_inv(paddr, size);
>> +}
>
> There are the only calls for the three functions for each of the
> involved functions.  So I'd rather rename the low-level symbols
> (and drop the pointless exports for two of them) rather than adding
> these wrapppers.
>
> The same is probably true for many other architectures.

Ok, done that now.

>> +static inline bool arch_sync_dma_clean_before_fromdevice(void)
>> +{
>> +	return false;
>> +}
>>  
>> +static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
>> +{
>> +	return true;
>>  }
>
> Is there a way to cut down on this boilerplate code by just having
> sane default, and Kconfig options to override them if they are not
> runtime decisions?

I've changed arch_sync_dma_clean_before_fromdevice() to a
Kconfig symbol now, as this is never a runtime decision.

For arch_sync_dma_cpu_needs_post_dma_flush(), I have this
version now in common code, which lets mips and arm have
their own logic and has the same effect elsewhere:

+#ifndef arch_sync_dma_cpu_needs_post_dma_flush
+static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
+{
+       return IS_ENABLED(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU);
+}
+#endif

>> +#include <linux/dma-sync.h>
>
> I can't really say I like the #include version here despite your
> rationale in the commit log.  I can probably live with it if you
> think it is absolutely worth it, but I'm really not in favor of it.
>
>> +config ARCH_DMA_MARK_DCACHE_CLEAN
>> +	def_bool y
>
> What do we need this symbol for?  Unless I'm missing something it is
> always enable for arm32, and only used in arm32 code.

This was left over from an earlier draft and accidentally duplicates
the thing that I have in the Arm version for the existing
ARCH_HAS_DMA_MARK_CLEAN. I dropped this one and the
generic copy of the arch_dma_mark_dcache_clean() function
now, but still need to revisit the arm version, as it sounds
like it has slightly different semantics from the ia64 version.

     Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christoph Hellwig" <hch@lst.de>, "Arnd Bergmann" <arnd@kernel.org>
Cc: linux-kernel@vger.kernel.org, "Vineet Gupta" <vgupta@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, guoren <guoren@kernel.org>,
	"Brian Cain" <bcain@quicinc.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Michal Simek" <monstr@monstr.eu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Dinh Nguyen" <dinguyen@kernel.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Rich Felker" <dalias@libc.org>,
	"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>,
	"David S . Miller" <davem@davemloft.net>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"Conor.Dooley" <conor.dooley@microchip.com>,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"linux-oxnas@groups.io" <linux-oxnas@groups.io>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	"linux-openrisc@vger.kernel.org" <linux-openrisc@vger.kernel.org>,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Date: Fri, 31 Mar 2023 15:04:23 +0200	[thread overview]
Message-ID: <f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com> (raw)
In-Reply-To: <20230327222514.GA17904@lst.de>

On Tue, Mar 28, 2023, at 00:25, Christoph Hellwig wrote:
>> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback(paddr, size);
>> +}
>>  
>> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> +{
>> +	dma_cache_inv(paddr, size);
>>  }
>
>> +static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback_inv(paddr, size);
>> +}
>
> There are the only calls for the three functions for each of the
> involved functions.  So I'd rather rename the low-level symbols
> (and drop the pointless exports for two of them) rather than adding
> these wrapppers.
>
> The same is probably true for many other architectures.

Ok, done that now.

>> +static inline bool arch_sync_dma_clean_before_fromdevice(void)
>> +{
>> +	return false;
>> +}
>>  
>> +static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
>> +{
>> +	return true;
>>  }
>
> Is there a way to cut down on this boilerplate code by just having
> sane default, and Kconfig options to override them if they are not
> runtime decisions?

I've changed arch_sync_dma_clean_before_fromdevice() to a
Kconfig symbol now, as this is never a runtime decision.

For arch_sync_dma_cpu_needs_post_dma_flush(), I have this
version now in common code, which lets mips and arm have
their own logic and has the same effect elsewhere:

+#ifndef arch_sync_dma_cpu_needs_post_dma_flush
+static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
+{
+       return IS_ENABLED(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU);
+}
+#endif

>> +#include <linux/dma-sync.h>
>
> I can't really say I like the #include version here despite your
> rationale in the commit log.  I can probably live with it if you
> think it is absolutely worth it, but I'm really not in favor of it.
>
>> +config ARCH_DMA_MARK_DCACHE_CLEAN
>> +	def_bool y
>
> What do we need this symbol for?  Unless I'm missing something it is
> always enable for arm32, and only used in arm32 code.

This was left over from an earlier draft and accidentally duplicates
the thing that I have in the Arm version for the existing
ARCH_HAS_DMA_MARK_CLEAN. I dropped this one and the
generic copy of the arch_dma_mark_dcache_clean() function
now, but still need to revisit the arm version, as it sounds
like it has slightly different semantics from the ia64 version.

     Arnd

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christoph Hellwig" <hch@lst.de>, "Arnd Bergmann" <arnd@kernel.org>
Cc: Rich Felker <dalias@libc.org>,
	linux-sh@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	linux-mips@vger.kernel.org, Max Filippov <jcmvbkbc@gmail.com>,
	"Conor.Dooley" <conor.dooley@microchip.com>,
	guoren <guoren@kernel.org>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
	Will Deacon <will@kernel.org>, Helge Deller <deller@gmx.de>,
	Russell King <linux@armlinux.org.uk>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Vineet Gupta <vgupta@kernel.org>,
	linux-snps-arc@lists.infradead.org,
	linux-xtensa@linux-xtensa.org, Brian Cain <bcain@quicinc.com>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	linux-m68k@lists.linux-m68k.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Stafford Horne <shorne@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	linux-parisc@vger.kernel.org,
	"linux-openrisc@vger.kernel.org" <linux-openrisc@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	Dinh Nguyen <dinguyen@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	linux-hexagon@vger.kernel.org,
	"linux-oxnas@groups.io" <linux-oxnas@groups.io>,
	Robin Murphy <robin.murphy@arm.com>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Date: Fri, 31 Mar 2023 15:04:23 +0200	[thread overview]
Message-ID: <f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com> (raw)
In-Reply-To: <20230327222514.GA17904@lst.de>

On Tue, Mar 28, 2023, at 00:25, Christoph Hellwig wrote:
>> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback(paddr, size);
>> +}
>>  
>> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> +{
>> +	dma_cache_inv(paddr, size);
>>  }
>
>> +static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback_inv(paddr, size);
>> +}
>
> There are the only calls for the three functions for each of the
> involved functions.  So I'd rather rename the low-level symbols
> (and drop the pointless exports for two of them) rather than adding
> these wrapppers.
>
> The same is probably true for many other architectures.

Ok, done that now.

>> +static inline bool arch_sync_dma_clean_before_fromdevice(void)
>> +{
>> +	return false;
>> +}
>>  
>> +static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
>> +{
>> +	return true;
>>  }
>
> Is there a way to cut down on this boilerplate code by just having
> sane default, and Kconfig options to override them if they are not
> runtime decisions?

I've changed arch_sync_dma_clean_before_fromdevice() to a
Kconfig symbol now, as this is never a runtime decision.

For arch_sync_dma_cpu_needs_post_dma_flush(), I have this
version now in common code, which lets mips and arm have
their own logic and has the same effect elsewhere:

+#ifndef arch_sync_dma_cpu_needs_post_dma_flush
+static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
+{
+       return IS_ENABLED(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU);
+}
+#endif

>> +#include <linux/dma-sync.h>
>
> I can't really say I like the #include version here despite your
> rationale in the commit log.  I can probably live with it if you
> think it is absolutely worth it, but I'm really not in favor of it.
>
>> +config ARCH_DMA_MARK_DCACHE_CLEAN
>> +	def_bool y
>
> What do we need this symbol for?  Unless I'm missing something it is
> always enable for arm32, and only used in arm32 code.

This was left over from an earlier draft and accidentally duplicates
the thing that I have in the Arm version for the existing
ARCH_HAS_DMA_MARK_CLEAN. I dropped this one and the
generic copy of the arch_dma_mark_dcache_clean() function
now, but still need to revisit the arm version, as it sounds
like it has slightly different semantics from the ia64 version.

     Arnd

WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Christoph Hellwig" <hch@lst.de>, "Arnd Bergmann" <arnd@kernel.org>
Cc: linux-kernel@vger.kernel.org, "Vineet Gupta" <vgupta@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, guoren <guoren@kernel.org>,
	"Brian Cain" <bcain@quicinc.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Michal Simek" <monstr@monstr.eu>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Dinh Nguyen" <dinguyen@kernel.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Rich Felker" <dalias@libc.org>,
	"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>,
	"David S . Miller" <davem@davemloft.net>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"Conor.Dooley" <conor.dooley@microchip.com>,
	linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"linux-oxnas@groups.io" <linux-oxnas@groups.io>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	"linux-openrisc@vger.kernel.org" <linux-openrisc@vger.kernel.org>,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Date: Fri, 31 Mar 2023 15:04:23 +0200	[thread overview]
Message-ID: <f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com> (raw)
In-Reply-To: <20230327222514.GA17904@lst.de>

On Tue, Mar 28, 2023, at 00:25, Christoph Hellwig wrote:
>> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback(paddr, size);
>> +}
>>  
>> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> +{
>> +	dma_cache_inv(paddr, size);
>>  }
>
>> +static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback_inv(paddr, size);
>> +}
>
> There are the only calls for the three functions for each of the
> involved functions.  So I'd rather rename the low-level symbols
> (and drop the pointless exports for two of them) rather than adding
> these wrapppers.
>
> The same is probably true for many other architectures.

Ok, done that now.

>> +static inline bool arch_sync_dma_clean_before_fromdevice(void)
>> +{
>> +	return false;
>> +}
>>  
>> +static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
>> +{
>> +	return true;
>>  }
>
> Is there a way to cut down on this boilerplate code by just having
> sane default, and Kconfig options to override them if they are not
> runtime decisions?

I've changed arch_sync_dma_clean_before_fromdevice() to a
Kconfig symbol now, as this is never a runtime decision.

For arch_sync_dma_cpu_needs_post_dma_flush(), I have this
version now in common code, which lets mips and arm have
their own logic and has the same effect elsewhere:

+#ifndef arch_sync_dma_cpu_needs_post_dma_flush
+static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
+{
+       return IS_ENABLED(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU);
+}
+#endif

>> +#include <linux/dma-sync.h>
>
> I can't really say I like the #include version here despite your
> rationale in the commit log.  I can probably live with it if you
> think it is absolutely worth it, but I'm really not in favor of it.
>
>> +config ARCH_DMA_MARK_DCACHE_CLEAN
>> +	def_bool y
>
> What do we need this symbol for?  Unless I'm missing something it is
> always enable for arm32, and only used in arm32 code.

This was left over from an earlier draft and accidentally duplicates
the thing that I have in the Arm version for the existing
ARCH_HAS_DMA_MARK_CLEAN. I dropped this one and the
generic copy of the arch_dma_mark_dcache_clean() function
now, but still need to revisit the arm version, as it sounds
like it has slightly different semantics from the ia64 version.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>, Arnd Bergmann <arnd@kernel.org>
Cc: linux-kernel@vger.kernel.org, Vineet Gupta <vgupta@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, guoren <guoren@kernel.org>,
	Brian Cain <bcain@quicinc.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Stafford Horne <shorne@gmail.com>, Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Rich Felker
Subject: Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Date: Fri, 31 Mar 2023 15:04:23 +0200	[thread overview]
Message-ID: <f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com> (raw)
In-Reply-To: <20230327222514.GA17904@lst.de>

On Tue, Mar 28, 2023, at 00:25, Christoph Hellwig wrote:
>> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback(paddr, size);
>> +}
>>  
>> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
>> +{
>> +	dma_cache_inv(paddr, size);
>>  }
>
>> +static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
>>  {
>> +	dma_cache_wback_inv(paddr, size);
>> +}
>
> There are the only calls for the three functions for each of the
> involved functions.  So I'd rather rename the low-level symbols
> (and drop the pointless exports for two of them) rather than adding
> these wrapppers.
>
> The same is probably true for many other architectures.

Ok, done that now.

>> +static inline bool arch_sync_dma_clean_before_fromdevice(void)
>> +{
>> +	return false;
>> +}
>>  
>> +static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
>> +{
>> +	return true;
>>  }
>
> Is there a way to cut down on this boilerplate code by just having
> sane default, and Kconfig options to override them if they are not
> runtime decisions?

I've changed arch_sync_dma_clean_before_fromdevice() to a
Kconfig symbol now, as this is never a runtime decision.

For arch_sync_dma_cpu_needs_post_dma_flush(), I have this
version now in common code, which lets mips and arm have
their own logic and has the same effect elsewhere:

+#ifndef arch_sync_dma_cpu_needs_post_dma_flush
+static inline bool arch_sync_dma_cpu_needs_post_dma_flush(void)
+{
+       return IS_ENABLED(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU);
+}
+#endif

>> +#include <linux/dma-sync.h>
>
> I can't really say I like the #include version here despite your
> rationale in the commit log.  I can probably live with it if you
> think it is absolutely worth it, but I'm really not in favor of it.
>
>> +config ARCH_DMA_MARK_DCACHE_CLEAN
>> +	def_bool y
>
> What do we need this symbol for?  Unless I'm missing something it is
> always enable for arm32, and only used in arm32 code.

This was left over from an earlier draft and accidentally duplicates
the thing that I have in the Arm version for the existing
ARCH_HAS_DMA_MARK_CLEAN. I dropped this one and the
generic copy of the arch_dma_mark_dcache_clean() function
now, but still need to revisit the arm version, as it sounds
like it has slightly different semantics from the ia64 version.

     Arnd

  reply	other threads:[~2023-03-31 13:04 UTC|newest]

Thread overview: 456+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 12:12 [PATCH 00/21] dma-mapping: unify support for cache flushes Arnd Bergmann
2023-03-27 12:12 ` Arnd Bergmann
2023-03-27 12:12 ` Arnd Bergmann
2023-03-27 12:12 ` Arnd Bergmann
2023-03-27 12:12 ` Arnd Bergmann
2023-03-27 12:12 ` Arnd Bergmann
2023-03-27 12:12 ` [PATCH 01/21] openrisc: dma-mapping: flush bidirectional mappings Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12 ` [PATCH 02/21] xtensa: dma-mapping: use normal cache invalidation rules Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 15:42   ` Max Filippov
2023-03-27 15:42     ` Max Filippov
2023-03-27 15:42     ` Max Filippov
2023-03-27 15:42     ` Max Filippov
2023-03-27 15:42     ` Max Filippov
2023-03-27 15:42     ` Max Filippov
2023-03-27 12:12 ` [PATCH 03/21] sparc32: flush caches in dma_sync_*for_device Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:12   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 04/21] microblaze: dma-mapping: skip extra DMA flushes Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 05/21] powerpc: dma-mapping: split out cache operation logic Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 06/21] powerpc: dma-mapping: minimize for_cpu flushing Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:56   ` Christophe Leroy
2023-03-27 12:56     ` Christophe Leroy
2023-03-27 12:56     ` Christophe Leroy
2023-03-27 12:56     ` Christophe Leroy
2023-03-27 12:56     ` Christophe Leroy
2023-03-27 12:56     ` Christophe Leroy
2023-03-27 13:02     ` Arnd Bergmann
2023-03-27 13:02       ` Arnd Bergmann
2023-03-27 13:02       ` Arnd Bergmann
2023-03-27 13:02       ` Arnd Bergmann
2023-03-27 13:02       ` Arnd Bergmann
2023-03-27 13:02       ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 07/21] powerpc: dma-mapping: always clean cache in _for_device() op Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-29 20:48   ` Conor Dooley
2023-03-29 20:48     ` Conor Dooley
2023-03-29 20:48     ` Conor Dooley
2023-03-29 20:48     ` Conor Dooley
2023-03-29 20:48     ` Conor Dooley
2023-03-29 20:48     ` Conor Dooley
2023-03-30  7:10     ` Arnd Bergmann
2023-03-30  7:10       ` Arnd Bergmann
2023-03-30  7:10       ` Arnd Bergmann
2023-03-30  7:10       ` Arnd Bergmann
2023-03-30  7:10       ` Arnd Bergmann
2023-03-30  7:10       ` Arnd Bergmann
2023-03-29 21:51   ` Jessica Clarke
2023-03-29 21:51     ` Jessica Clarke
2023-03-29 21:51     ` Jessica Clarke
2023-03-29 21:51     ` Jessica Clarke
2023-03-29 21:51     ` Jessica Clarke
2023-03-29 21:51     ` Jessica Clarke
2023-03-30 12:59   ` Lad, Prabhakar
2023-03-30 12:59     ` Lad, Prabhakar
2023-03-30 12:59     ` Lad, Prabhakar
2023-03-30 12:59     ` Lad, Prabhakar
2023-03-30 12:59     ` Lad, Prabhakar
2023-03-30 12:59     ` Lad, Prabhakar
2023-04-19 14:22   ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-03-27 12:13 ` [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-29 20:16   ` Conor Dooley
2023-03-29 20:16     ` Conor Dooley
2023-03-29 20:16     ` Conor Dooley
2023-03-29 20:16     ` Conor Dooley
2023-03-29 20:16     ` Conor Dooley
2023-03-29 20:16     ` Conor Dooley
2023-03-30 13:26   ` Lad, Prabhakar
2023-03-30 13:26     ` Lad, Prabhakar
2023-03-30 13:26     ` Lad, Prabhakar
2023-03-30 13:26     ` Lad, Prabhakar
2023-03-30 13:26     ` Lad, Prabhakar
2023-03-30 13:26     ` Lad, Prabhakar
2023-04-19 14:22   ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-04-19 14:22     ` Palmer Dabbelt
2023-05-05  5:47   ` Guo Ren
2023-05-05  5:47     ` Guo Ren
2023-05-05  5:47     ` Guo Ren
2023-05-05  5:47     ` Guo Ren
2023-05-05  5:47     ` Guo Ren
2023-05-05  5:47     ` Guo Ren
2023-05-05 13:18     ` Arnd Bergmann
2023-05-05 13:18       ` Arnd Bergmann
2023-05-05 13:18       ` Arnd Bergmann
2023-05-05 13:18       ` Arnd Bergmann
2023-05-05 13:18       ` Arnd Bergmann
2023-05-05 13:18       ` Arnd Bergmann
2023-05-06  7:25       ` Guo Ren
2023-05-06  7:25         ` Guo Ren
2023-05-06  7:25         ` Guo Ren
2023-05-06  7:25         ` Guo Ren
2023-05-06  7:25         ` Guo Ren
2023-05-06  7:25         ` Guo Ren
2023-05-06  7:53         ` Arnd Bergmann
2023-05-06  7:53           ` Arnd Bergmann
2023-05-06  7:53           ` Arnd Bergmann
2023-05-06  7:53           ` Arnd Bergmann
2023-05-06  7:53           ` Arnd Bergmann
2023-05-06  7:53           ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 10/21] csky: dma-mapping: skip invalidating before DMA from device Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 13:37   ` Guo Ren
2023-03-27 13:37     ` Guo Ren
2023-03-27 13:37     ` Guo Ren
2023-03-27 13:37     ` Guo Ren
2023-03-27 13:37     ` Guo Ren
2023-03-27 13:37     ` Guo Ren
2023-03-27 12:13 ` [PATCH 11/21] mips: dma-mapping: skip invalidating before bidirectional DMA Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 12/21] mips: dma-mapping: split out cache operation logic Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-04-02  6:52   ` Vineet Gupta
2023-04-02  6:52     ` Vineet Gupta
2023-04-02  6:52     ` Vineet Gupta
2023-04-02  6:52     ` Vineet Gupta
2023-04-02  6:52     ` Vineet Gupta
2023-04-02  6:52     ` Vineet Gupta
2023-04-04  8:27     ` Shahab Vahedi
2023-04-04  8:27       ` Shahab Vahedi
2023-04-04  8:27       ` Shahab Vahedi
2023-04-04  8:27       ` Shahab Vahedi
2023-04-04  8:27       ` Shahab Vahedi
2023-04-04  8:27       ` Shahab Vahedi
2023-04-06  9:01     ` Shahab Vahedi
2023-04-06  9:01       ` Shahab Vahedi
2023-04-06  9:01       ` Shahab Vahedi
2023-04-06  9:01       ` Shahab Vahedi
2023-04-06  9:01       ` Shahab Vahedi
2023-04-06  9:01       ` Shahab Vahedi
2023-03-27 12:13 ` [PATCH 14/21] parisc: dma-mapping: use regular flush/invalidate ops Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-31  9:01   ` Linus Walleij
2023-03-31  9:01     ` Linus Walleij
2023-03-31  9:01     ` Linus Walleij
2023-03-31  9:01     ` Linus Walleij
2023-03-31  9:01     ` Linus Walleij
2023-03-31  9:01     ` Linus Walleij
2023-03-31  9:07   ` Russell King (Oracle)
2023-03-31  9:07     ` Russell King (Oracle)
2023-03-31  9:07     ` Russell King (Oracle)
2023-03-31  9:07     ` Russell King (Oracle)
2023-03-31  9:07     ` Russell King (Oracle)
2023-03-31  9:07     ` Russell King (Oracle)
2023-03-31  9:35     ` Russell King (Oracle)
2023-03-31  9:35       ` Russell King (Oracle)
2023-03-31  9:35       ` Russell King (Oracle)
2023-03-31  9:35       ` Russell King (Oracle)
2023-03-31  9:35       ` Russell King (Oracle)
2023-03-31  9:35       ` Russell King (Oracle)
2023-03-31 10:38       ` Arnd Bergmann
2023-03-31 10:38         ` Arnd Bergmann
2023-03-31 10:38         ` Arnd Bergmann
2023-03-31 10:38         ` Arnd Bergmann
2023-03-31 10:38         ` Arnd Bergmann
2023-03-31 10:38         ` Arnd Bergmann
2023-03-31 11:01         ` David Laight
2023-03-31 11:01           ` David Laight
2023-03-31 11:01           ` David Laight
2023-03-31 11:01           ` David Laight
2023-03-31 11:01           ` David Laight
2023-03-31 11:08         ` Russell King (Oracle)
2023-03-31 11:08           ` Russell King (Oracle)
2023-03-31 11:08           ` Russell King (Oracle)
2023-03-31 11:08           ` Russell King (Oracle)
2023-03-31 11:08           ` Russell King (Oracle)
2023-03-31 11:08           ` Russell King (Oracle)
2023-03-31 12:32           ` Arnd Bergmann
2023-03-31 12:32             ` Arnd Bergmann
2023-03-31 12:32             ` Arnd Bergmann
2023-03-31 12:32             ` Arnd Bergmann
2023-03-31 12:32             ` Arnd Bergmann
2023-03-31 12:32             ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 16/21] ARM: dma-mapping: bring back dmac_{clean,inv}_range Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 13:10   ` Russell King (Oracle)
2023-03-27 13:10     ` Russell King (Oracle)
2023-03-27 13:10     ` Russell King (Oracle)
2023-03-27 13:10     ` Russell King (Oracle)
2023-03-27 13:10     ` Russell King (Oracle)
2023-03-27 13:10     ` Russell King (Oracle)
2023-03-27 12:13 ` [PATCH 17/21] ARM: dma-mapping: use arch_sync_dma_for_{device,cpu}() internally Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-31  9:10   ` Linus Walleij
2023-03-31  9:10     ` Linus Walleij
2023-03-31  9:10     ` Linus Walleij
2023-03-31  9:10     ` Linus Walleij
2023-03-31  9:10     ` Linus Walleij
2023-03-31  9:10     ` Linus Walleij
2023-03-31 12:48     ` Arnd Bergmann
2023-03-31 12:48       ` Arnd Bergmann
2023-03-31 12:48       ` Arnd Bergmann
2023-03-31 12:48       ` Arnd Bergmann
2023-03-31 12:48       ` Arnd Bergmann
2023-03-31 12:48       ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 18/21] ARM: drop SMP support for ARM11MPCore Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-30  7:48   ` Neil Armstrong
2023-03-30  7:48     ` Neil Armstrong
2023-03-30  7:48     ` Neil Armstrong
2023-03-30  7:48     ` Neil Armstrong
2023-03-30  7:48     ` Neil Armstrong
2023-03-30  7:48     ` Neil Armstrong
2023-03-30 10:03     ` Arnd Bergmann
2023-03-30 10:03       ` Arnd Bergmann
2023-03-30 10:03       ` Arnd Bergmann
2023-03-30 10:03       ` Arnd Bergmann
2023-03-30 10:03       ` Arnd Bergmann
2023-03-30 10:03       ` Arnd Bergmann
2023-03-30 16:40       ` Neil Armstrong
2023-03-30 16:40         ` Neil Armstrong
2023-03-30 16:40         ` Neil Armstrong
2023-03-30 16:40         ` Neil Armstrong
2023-03-30 16:40         ` Neil Armstrong
2023-03-30 16:40         ` Neil Armstrong
2023-03-30  8:12   ` Linus Walleij
2023-03-30  8:12     ` Linus Walleij
2023-03-30  8:12     ` Linus Walleij
2023-03-30  8:12     ` Linus Walleij
2023-03-30  8:12     ` Linus Walleij
2023-03-30  8:12     ` Linus Walleij
2023-03-30 11:28   ` Joel Stanley
2023-03-31 12:54     ` Arnd Bergmann
2023-04-05  1:49       ` Joel Stanley
2023-03-30 11:51   ` Ard Biesheuvel
2023-03-30 11:51     ` Ard Biesheuvel
2023-03-30 11:51     ` Ard Biesheuvel
2023-03-30 11:51     ` Ard Biesheuvel
2023-03-30 11:51     ` Ard Biesheuvel
2023-03-30 11:51     ` Ard Biesheuvel
2023-03-31 17:09   ` Catalin Marinas
2023-03-31 17:09     ` Catalin Marinas
2023-03-31 17:09     ` Catalin Marinas
2023-03-31 17:09     ` Catalin Marinas
2023-03-31 17:09     ` Catalin Marinas
2023-03-31 17:09     ` Catalin Marinas
2023-03-27 12:13 ` [PATCH 19/21] ARM: dma-mapping: use generic form of arch_sync_dma_* helpers Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13 ` [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:48   ` Robin Murphy
2023-03-27 12:48     ` Robin Murphy
2023-03-27 12:48     ` Robin Murphy
2023-03-27 12:48     ` Robin Murphy
2023-03-27 12:48     ` Robin Murphy
2023-03-27 12:48     ` Robin Murphy
2023-03-31 14:00     ` Arnd Bergmann
2023-03-31 14:00       ` Arnd Bergmann
2023-03-31 14:00       ` Arnd Bergmann
2023-03-31 14:00       ` Arnd Bergmann
2023-03-31 14:00       ` Arnd Bergmann
2023-03-31 14:00       ` Arnd Bergmann
2023-03-31 15:12       ` Robin Murphy
2023-03-31 15:12         ` Robin Murphy
2023-03-31 15:12         ` Robin Murphy
2023-03-31 15:12         ` Robin Murphy
2023-03-31 15:12         ` Robin Murphy
2023-03-31 15:12         ` Robin Murphy
2023-03-31 17:20         ` Arnd Bergmann
2023-03-31 17:20           ` Arnd Bergmann
2023-03-31 17:20           ` Arnd Bergmann
2023-03-31 17:20           ` Arnd Bergmann
2023-03-31 17:20           ` Arnd Bergmann
2023-03-31 17:20           ` Arnd Bergmann
2023-03-27 15:01   ` Russell King (Oracle)
2023-03-27 15:01     ` Russell King (Oracle)
2023-03-27 15:01     ` Russell King (Oracle)
2023-03-27 15:01     ` Russell King (Oracle)
2023-03-27 15:01     ` Russell King (Oracle)
2023-03-27 15:01     ` Russell King (Oracle)
2023-03-31 14:06     ` Arnd Bergmann
2023-03-31 14:06       ` Arnd Bergmann
2023-03-31 14:06       ` Arnd Bergmann
2023-03-31 14:06       ` Arnd Bergmann
2023-03-31 14:06       ` Arnd Bergmann
2023-03-31 14:06       ` Arnd Bergmann
2023-03-31 15:54       ` Russell King (Oracle)
2023-03-31 15:54         ` Russell King (Oracle)
2023-03-31 15:54         ` Russell King (Oracle)
2023-03-31 15:54         ` Russell King (Oracle)
2023-03-31 15:54         ` Russell King (Oracle)
2023-03-31 15:54         ` Russell King (Oracle)
2023-03-27 18:42   ` kernel test robot
2023-03-27 19:03   ` kernel test robot
2023-03-28 13:17   ` kernel test robot
2023-07-03  7:54   ` Geert Uytterhoeven
2023-07-03  7:54     ` Geert Uytterhoeven
2023-07-03  7:54     ` Geert Uytterhoeven
2023-07-03  7:54     ` Geert Uytterhoeven
2023-07-03  7:54     ` Geert Uytterhoeven
2023-07-03  7:54     ` Geert Uytterhoeven
2023-07-06 14:11     ` Christoph Hellwig
2023-07-06 14:11       ` Christoph Hellwig
2023-07-06 14:11       ` Christoph Hellwig
2023-07-06 14:11       ` Christoph Hellwig
2023-07-06 14:11       ` Christoph Hellwig
2023-07-06 14:11       ` Christoph Hellwig
2023-03-27 12:13 ` [PATCH 21/21] dma-mapping: replace custom code with generic implementation Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 12:13   ` Arnd Bergmann
2023-03-27 22:25   ` Christoph Hellwig
2023-03-27 22:25     ` Christoph Hellwig
2023-03-27 22:25     ` Christoph Hellwig
2023-03-27 22:25     ` Christoph Hellwig
2023-03-27 22:25     ` Christoph Hellwig
2023-03-27 22:25     ` Christoph Hellwig
2023-03-31 13:04     ` Arnd Bergmann [this message]
2023-03-31 13:04       ` Arnd Bergmann
2023-03-31 13:04       ` Arnd Bergmann
2023-03-31 13:04       ` Arnd Bergmann
2023-03-31 13:04       ` Arnd Bergmann
2023-03-31 13:04       ` Arnd Bergmann
2023-03-30 14:06   ` Lad, Prabhakar
2023-03-30 14:06     ` Lad, Prabhakar
2023-03-30 14:06     ` Lad, Prabhakar
2023-03-30 14:06     ` Lad, Prabhakar
2023-03-30 14:06     ` Lad, Prabhakar
2023-03-30 14:06     ` Lad, Prabhakar
2023-04-13 12:13   ` Biju Das
2023-04-13 12:13     ` Biju Das
2023-04-13 12:13     ` Biju Das
2023-04-13 12:13     ` Biju Das
2023-04-13 12:13     ` Biju Das
2023-04-13 12:13     ` Biju Das
2023-04-13 12:13     ` Biju Das
2023-04-13 12:51     ` Arnd Bergmann
2023-04-13 12:51       ` Arnd Bergmann
2023-04-13 12:51       ` Arnd Bergmann
2023-04-13 12:51       ` Arnd Bergmann
2023-04-13 12:51       ` Arnd Bergmann
2023-04-13 12:51       ` Arnd Bergmann
2023-06-27 16:52       ` Geert Uytterhoeven
2023-06-27 16:52         ` Geert Uytterhoeven
2023-06-27 16:52         ` Geert Uytterhoeven
2023-06-27 16:52         ` Geert Uytterhoeven
2023-06-27 16:52         ` Geert Uytterhoeven
2023-06-27 16:52         ` Geert Uytterhoeven
2023-03-31 16:53 ` [PATCH 00/21] dma-mapping: unify support for cache flushes Catalin Marinas
2023-03-31 16:53   ` Catalin Marinas
2023-03-31 16:53   ` Catalin Marinas
2023-03-31 16:53   ` Catalin Marinas
2023-03-31 16:53   ` Catalin Marinas
2023-03-31 16:53   ` Catalin Marinas
2023-03-31 20:27   ` Arnd Bergmann
2023-03-31 20:27     ` Arnd Bergmann
2023-03-31 20:27     ` Arnd Bergmann
2023-03-31 20:27     ` Arnd Bergmann
2023-03-31 20:27     ` Arnd Bergmann
2023-03-31 20:27     ` Arnd Bergmann
2023-05-25  7:46 ` Lad, Prabhakar
2023-05-25  7:46   ` Lad, Prabhakar
2023-05-25  7:46   ` Lad, Prabhakar
2023-05-25  7:46   ` Lad, Prabhakar
2023-05-25  7:46   ` Lad, Prabhakar
2023-05-25  7:46   ` Lad, Prabhakar

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=f25d74a0-9e61-44df-b4c7-f495462fa648@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=bcain@quicinc.com \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=conor.dooley@microchip.com \
    --cc=dalias@libc.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dinguyen@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=guoren@kernel.org \
    --cc=hch@lst.de \
    --cc=jcmvbkbc@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-openrisc@vger.kernel.org \
    --cc=linux-oxnas@groups.io \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=neil.armstrong@linaro.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robin.murphy@arm.com \
    --cc=shorne@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=vgupta@kernel.org \
    --cc=will@kernel.org \
    /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.