From: "Arnd Bergmann" <arnd@arndb.de>
To: "Catalin Marinas" <catalin.marinas@arm.com>,
"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>,
"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>,
"Christoph Hellwig" <hch@lst.de>,
"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 00/21] dma-mapping: unify support for cache flushes
Date: Fri, 31 Mar 2023 22:27:29 +0200 [thread overview]
Message-ID: <578fda41-4a69-44f5-8a58-1eacd49e1347@app.fastmail.com> (raw)
In-Reply-To: <ZCcQGX/i8xBPiG7T@arm.com>
On Fri, Mar 31, 2023, at 18:53, Catalin Marinas wrote:
> On Mon, Mar 27, 2023 at 02:12:56PM +0200, Arnd Bergmann wrote:
>> Another difference that I do not address here is what cache invalidation
>> does for partical cache lines. On arm32, arm64 and powerpc, a partial
>> cache line always gets written back before invalidation in order to
>> ensure that data before or after the buffer is not discarded. On all
>> other architectures, the assumption is cache lines are never shared
>> between DMA buffer and data that is accessed by the CPU.
>
> I don't think sharing the DMA buffer with other data is safe even with
> this clean+invalidate on the unaligned cache. Mapping the DMA buffer as
> FROM_DEVICE or BIDIRECTIONAL can cause the shared cache line to be
> evicted and override the device written data. This sharing only works if
> the CPU guarantees not to dirty the corresponding cache line.
>
> I'm fine with removing this partial cache line hack from arm64 as it's
> not safe anyway. We'll see if any driver stops working. If there's some
> benign sharing (I wouldn't trust it), the cache cleaning prior to
> mapping and invalidate on unmap would not lose any data.
Ok, I'll add a patch to remove that bit from dcache_inval_poc
then. Do you know if any of the the other callers of this function
rely on on the writeback behavior, or is it safe to remove it for
all of them?
Note that before c50f11c6196f ("arm64: mm: Don't invalidate
FROM_DEVICE buffers at start of DMA transfer"), it made some
sense to write back partial cache lines before a DMA_FROM_DEVICE,
in order to allow sharing read-only data in them the same way as
on arm32 and powerpc. Doing the writeback in the sync_for_cpu
bit is of course always pointless.
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: "Catalin Marinas" <catalin.marinas@arm.com>,
"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>,
"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>,
"Christoph Hellwig" <hch@lst.de>,
"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 00/21] dma-mapping: unify support for cache flushes
Date: Fri, 31 Mar 2023 22:27:29 +0200 [thread overview]
Message-ID: <578fda41-4a69-44f5-8a58-1eacd49e1347@app.fastmail.com> (raw)
In-Reply-To: <ZCcQGX/i8xBPiG7T@arm.com>
On Fri, Mar 31, 2023, at 18:53, Catalin Marinas wrote:
> On Mon, Mar 27, 2023 at 02:12:56PM +0200, Arnd Bergmann wrote:
>> Another difference that I do not address here is what cache invalidation
>> does for partical cache lines. On arm32, arm64 and powerpc, a partial
>> cache line always gets written back before invalidation in order to
>> ensure that data before or after the buffer is not discarded. On all
>> other architectures, the assumption is cache lines are never shared
>> between DMA buffer and data that is accessed by the CPU.
>
> I don't think sharing the DMA buffer with other data is safe even with
> this clean+invalidate on the unaligned cache. Mapping the DMA buffer as
> FROM_DEVICE or BIDIRECTIONAL can cause the shared cache line to be
> evicted and override the device written data. This sharing only works if
> the CPU guarantees not to dirty the corresponding cache line.
>
> I'm fine with removing this partial cache line hack from arm64 as it's
> not safe anyway. We'll see if any driver stops working. If there's some
> benign sharing (I wouldn't trust it), the cache cleaning prior to
> mapping and invalidate on unmap would not lose any data.
Ok, I'll add a patch to remove that bit from dcache_inval_poc
then. Do you know if any of the the other callers of this function
rely on on the writeback behavior, or is it safe to remove it for
all of them?
Note that before c50f11c6196f ("arm64: mm: Don't invalidate
FROM_DEVICE buffers at start of DMA transfer"), it made some
sense to write back partial cache lines before a DMA_FROM_DEVICE,
in order to allow sharing read-only data in them the same way as
on arm32 and powerpc. Doing the writeback in the sync_for_cpu
bit is of course always pointless.
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: "Catalin Marinas" <catalin.marinas@arm.com>,
"Arnd Bergmann" <arnd@kernel.org>
Cc: Rich Felker <dalias@libc.org>,
linux-sh@vger.kernel.org,
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>, Christoph Hellwig <hch@lst.de>,
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 00/21] dma-mapping: unify support for cache flushes
Date: Fri, 31 Mar 2023 22:27:29 +0200 [thread overview]
Message-ID: <578fda41-4a69-44f5-8a58-1eacd49e1347@app.fastmail.com> (raw)
In-Reply-To: <ZCcQGX/i8xBPiG7T@arm.com>
On Fri, Mar 31, 2023, at 18:53, Catalin Marinas wrote:
> On Mon, Mar 27, 2023 at 02:12:56PM +0200, Arnd Bergmann wrote:
>> Another difference that I do not address here is what cache invalidation
>> does for partical cache lines. On arm32, arm64 and powerpc, a partial
>> cache line always gets written back before invalidation in order to
>> ensure that data before or after the buffer is not discarded. On all
>> other architectures, the assumption is cache lines are never shared
>> between DMA buffer and data that is accessed by the CPU.
>
> I don't think sharing the DMA buffer with other data is safe even with
> this clean+invalidate on the unaligned cache. Mapping the DMA buffer as
> FROM_DEVICE or BIDIRECTIONAL can cause the shared cache line to be
> evicted and override the device written data. This sharing only works if
> the CPU guarantees not to dirty the corresponding cache line.
>
> I'm fine with removing this partial cache line hack from arm64 as it's
> not safe anyway. We'll see if any driver stops working. If there's some
> benign sharing (I wouldn't trust it), the cache cleaning prior to
> mapping and invalidate on unmap would not lose any data.
Ok, I'll add a patch to remove that bit from dcache_inval_poc
then. Do you know if any of the the other callers of this function
rely on on the writeback behavior, or is it safe to remove it for
all of them?
Note that before c50f11c6196f ("arm64: mm: Don't invalidate
FROM_DEVICE buffers at start of DMA transfer"), it made some
sense to write back partial cache lines before a DMA_FROM_DEVICE,
in order to allow sharing read-only data in them the same way as
on arm32 and powerpc. Doing the writeback in the sync_for_cpu
bit is of course always pointless.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Catalin Marinas" <catalin.marinas@arm.com>,
"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>,
"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>,
"Christoph Hellwig" <hch@lst.de>,
"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 00/21] dma-mapping: unify support for cache flushes
Date: Fri, 31 Mar 2023 22:27:29 +0200 [thread overview]
Message-ID: <578fda41-4a69-44f5-8a58-1eacd49e1347@app.fastmail.com> (raw)
In-Reply-To: <ZCcQGX/i8xBPiG7T@arm.com>
On Fri, Mar 31, 2023, at 18:53, Catalin Marinas wrote:
> On Mon, Mar 27, 2023 at 02:12:56PM +0200, Arnd Bergmann wrote:
>> Another difference that I do not address here is what cache invalidation
>> does for partical cache lines. On arm32, arm64 and powerpc, a partial
>> cache line always gets written back before invalidation in order to
>> ensure that data before or after the buffer is not discarded. On all
>> other architectures, the assumption is cache lines are never shared
>> between DMA buffer and data that is accessed by the CPU.
>
> I don't think sharing the DMA buffer with other data is safe even with
> this clean+invalidate on the unaligned cache. Mapping the DMA buffer as
> FROM_DEVICE or BIDIRECTIONAL can cause the shared cache line to be
> evicted and override the device written data. This sharing only works if
> the CPU guarantees not to dirty the corresponding cache line.
>
> I'm fine with removing this partial cache line hack from arm64 as it's
> not safe anyway. We'll see if any driver stops working. If there's some
> benign sharing (I wouldn't trust it), the cache cleaning prior to
> mapping and invalidate on unmap would not lose any data.
Ok, I'll add a patch to remove that bit from dcache_inval_poc
then. Do you know if any of the the other callers of this function
rely on on the writeback behavior, or is it safe to remove it for
all of them?
Note that before c50f11c6196f ("arm64: mm: Don't invalidate
FROM_DEVICE buffers at start of DMA transfer"), it made some
sense to write back partial cache lines before a DMA_FROM_DEVICE,
in order to allow sharing read-only data in them the same way as
on arm32 and powerpc. Doing the writeback in the sync_for_cpu
bit is of course always pointless.
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: "Catalin Marinas" <catalin.marinas@arm.com>,
"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>,
"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>,
"Christoph Hellwig" <hch@lst.de>,
"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 00/21] dma-mapping: unify support for cache flushes
Date: Fri, 31 Mar 2023 22:27:29 +0200 [thread overview]
Message-ID: <578fda41-4a69-44f5-8a58-1eacd49e1347@app.fastmail.com> (raw)
In-Reply-To: <ZCcQGX/i8xBPiG7T@arm.com>
On Fri, Mar 31, 2023, at 18:53, Catalin Marinas wrote:
> On Mon, Mar 27, 2023 at 02:12:56PM +0200, Arnd Bergmann wrote:
>> Another difference that I do not address here is what cache invalidation
>> does for partical cache lines. On arm32, arm64 and powerpc, a partial
>> cache line always gets written back before invalidation in order to
>> ensure that data before or after the buffer is not discarded. On all
>> other architectures, the assumption is cache lines are never shared
>> between DMA buffer and data that is accessed by the CPU.
>
> I don't think sharing the DMA buffer with other data is safe even with
> this clean+invalidate on the unaligned cache. Mapping the DMA buffer as
> FROM_DEVICE or BIDIRECTIONAL can cause the shared cache line to be
> evicted and override the device written data. This sharing only works if
> the CPU guarantees not to dirty the corresponding cache line.
>
> I'm fine with removing this partial cache line hack from arm64 as it's
> not safe anyway. We'll see if any driver stops working. If there's some
> benign sharing (I wouldn't trust it), the cache cleaning prior to
> mapping and invalidate on unmap would not lose any data.
Ok, I'll add a patch to remove that bit from dcache_inval_poc
then. Do you know if any of the the other callers of this function
rely on on the writeback behavior, or is it safe to remove it for
all of them?
Note that before c50f11c6196f ("arm64: mm: Don't invalidate
FROM_DEVICE buffers at start of DMA transfer"), it made some
sense to write back partial cache lines before a DMA_FROM_DEVICE,
in order to allow sharing read-only data in them the same way as
on arm32 and powerpc. Doing the writeback in the sync_for_cpu
bit is of course always pointless.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de>
To: Catalin Marinas <catalin.marinas@arm.com>,
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>,
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>,
Chris
Subject: Re: [PATCH 00/21] dma-mapping: unify support for cache flushes
Date: Fri, 31 Mar 2023 22:27:29 +0200 [thread overview]
Message-ID: <578fda41-4a69-44f5-8a58-1eacd49e1347@app.fastmail.com> (raw)
In-Reply-To: <ZCcQGX/i8xBPiG7T@arm.com>
On Fri, Mar 31, 2023, at 18:53, Catalin Marinas wrote:
> On Mon, Mar 27, 2023 at 02:12:56PM +0200, Arnd Bergmann wrote:
>> Another difference that I do not address here is what cache invalidation
>> does for partical cache lines. On arm32, arm64 and powerpc, a partial
>> cache line always gets written back before invalidation in order to
>> ensure that data before or after the buffer is not discarded. On all
>> other architectures, the assumption is cache lines are never shared
>> between DMA buffer and data that is accessed by the CPU.
>
> I don't think sharing the DMA buffer with other data is safe even with
> this clean+invalidate on the unaligned cache. Mapping the DMA buffer as
> FROM_DEVICE or BIDIRECTIONAL can cause the shared cache line to be
> evicted and override the device written data. This sharing only works if
> the CPU guarantees not to dirty the corresponding cache line.
>
> I'm fine with removing this partial cache line hack from arm64 as it's
> not safe anyway. We'll see if any driver stops working. If there's some
> benign sharing (I wouldn't trust it), the cache cleaning prior to
> mapping and invalidate on unmap would not lose any data.
Ok, I'll add a patch to remove that bit from dcache_inval_poc
then. Do you know if any of the the other callers of this function
rely on on the writeback behavior, or is it safe to remove it for
all of them?
Note that before c50f11c6196f ("arm64: mm: Don't invalidate
FROM_DEVICE buffers at start of DMA transfer"), it made some
sense to write back partial cache lines before a DMA_FROM_DEVICE,
in order to allow sharing read-only data in them the same way as
on arm32 and powerpc. Doing the writeback in the sync_for_cpu
bit is of course always pointless.
Arnd
next prev parent reply other threads:[~2023-03-31 20:28 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
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 [this message]
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=578fda41-4a69-44f5-8a58-1eacd49e1347@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.