From: Moritz Fischer
[ Upstream commit a1df829ead5877d4a1061e976a50e2e665a16f24 ]
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.
iort_dma_setup() would query the root complex'/named component IORT
entry
Hi Catalin,
On Wed, Jan 27, 2021 at 01:09:36PM +, Catalin Marinas wrote:
> On Thu, 21 Jan 2021 17:24:19 -0800, Moritz Fischer wrote:
> > Address issue observed on real world system with suboptimal IORT table
> > where DMA masks of PCI devices would get set
On Thu, 21 Jan 2021 17:24:19 -0800, Moritz Fischer wrote:
> Address issue observed on real world system with suboptimal IORT table
> where DMA masks of PCI devices would get set to 0 as result.
>
> iort_dma_setup() would query the root complex'/named component IORT
> entry for
On Thu, Jan 21, 2021 at 05:24:19PM -0800, Moritz Fischer wrote:
> Address issue observed on real world system with suboptimal IORT table
> where DMA masks of PCI devices would get set to 0 as result.
>
> iort_dma_setup() would query the root complex'/named component IORT
>
s issue observed on real world system with suboptimal IORT table
> > > > where DMA masks of PCI devices would get set to 0 as result.
> > > >
> > > > iort_dma_setup() would query the root complex'/named component IORT
> > > > entr
On 2021-01-22 17:50, Moritz Fischer wrote:
Hi Robin,
On Fri, Jan 22, 2021 at 02:42:05PM +, Robin Murphy wrote:
On 2021-01-22 01:24, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result
Hi Robin,
On Fri, Jan 22, 2021 at 02:42:05PM +, Robin Murphy wrote:
> On 2021-01-22 01:24, Moritz Fischer wrote:
> > Address issue observed on real world system with suboptimal IORT table
> > where DMA masks of PCI devices would get set to 0 as result.
> >
> > i
On 2021-01-22 01:24, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.
iort_dma_setup() would query the root complex'/named component IORT
entry for a DMA mask, and use that over the on
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.
iort_dma_setup() would query the root complex'/named component IORT
entry for a DMA mask, and use that over the one the device has been
configured with ea
ddress issue observed on real world system with suboptimal IORT table
> > > > where DMA masks of PCI devices would get set to 0 as result.
> > > >
> > > > iort_dma_setup() would query the root complex' IORT entry for a DMA
> > > > mask, and use
On 2021-01-21 21:17, Moritz Fischer wrote:
Robin,
On Thu, Jan 21, 2021 at 08:08:42PM +, Robin Murphy wrote:
On 2021-01-21 19:16, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result
Robin,
On Thu, Jan 21, 2021 at 08:08:42PM +, Robin Murphy wrote:
> On 2021-01-21 19:16, Moritz Fischer wrote:
> > Address issue observed on real world system with suboptimal IORT table
> > where DMA masks of PCI devices would get set to 0 as result.
> >
> > iort_
On 2021-01-21 19:16, Moritz Fischer wrote:
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.
iort_dma_setup() would query the root complex' IORT entry for a DMA
mask, and use that over the one the device has
Address issue observed on real world system with suboptimal IORT table
where DMA masks of PCI devices would get set to 0 as result.
iort_dma_setup() would query the root complex' IORT entry for a DMA
mask, and use that over the one the device has been configured with
earlier.
Ideally we wa
On Tue, 2019-09-24 at 23:25 +0200, Christoph Hellwig wrote:
> On Mon, Sep 23, 2019 at 08:59:42PM -0400, James Bottomley wrote:
> > > if (mask > ~0U)
> > > » » return 0;
> > >
> > > Removing the if() makes the DMA mapping work. It's almost
> > > midnight here, so i won't look into that
On Mon, Sep 23, 2019 at 08:59:42PM -0400, James Bottomley wrote:
> > if (mask > ~0U)
> > » » return 0;
> >
> > Removing the if() makes the DMA mapping work. It's almost midnight
> > here, so i won't look into that any further today. Does anyone have
> > an opinion on this behaviour?
mask and dev-
> > >coherent_dma_mask) and system limitations (dev->bus_dma_mask). We
> > already accept larger than required masks in most dma_map_ops
> > implementation, in case of x86 and implementations based on it
> > since the dawn of time. Only one parisc and tw
We already accept larger than required
> masks in most dma_map_ops implementation, in case of x86 and
> implementations based on it since the dawn of time. Only one parisc
> and two sparc64 instances failed larger than required DMA masks, and
> this series fixes that up and updates the doc
On 7/24/19 1:11 PM, Kirill A. Shutemov wrote:
> On Wed, Jul 24, 2019 at 05:34:26PM +, Lendacky, Thomas wrote:
>> On 7/24/19 12:06 PM, Robin Murphy wrote:
>>> On 24/07/2019 17:42, Lendacky, Thomas wrote:
On 7/24/19 10:55 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 10, 2019 at 07:01:19PM
Argh. This was meant for the linuxppc list, will repost, please ignore this.
On 12/07/2019 19:29, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40 is usually available.
This is based on sha1
a2b6f26c264e Christophe Leroy "powerpc/module64: Use symbolic instructions
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmam
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmam
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_m
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_m
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_m
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmam
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmam
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmam
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_m
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmam
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_m
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_m
3.16.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initia
From: Arnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static
From: Arnd Bergmann
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overf
From: Arnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static
From: Arnd Bergmann
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overf
From: Arnd Bergmann
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overf
From: Arnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static
From: Arnd Bergmann
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overf
From: Arnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static
From: Arnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static
From: Arnd Bergmann
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overf
From: Arnd Bergmann
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static
From: Arnd Bergmann
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overf
On Mon, Mar 25, 2019 at 04:50:42PM +0100, Arnd Bergmann wrote:
> clang warns about statically defined DMA masks from the DMA_BIT_MASK
> macro with length 64:
>
> arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
> [-Werror,-Wsh
On Mon, Mar 25, 2019 at 04:50:43PM +0100, Arnd Bergmann wrote:
> clang warns about statically defined DMA masks from the DMA_BIT_MASK
> macro with length 64:
>
> arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
> [-Werror,-Wshift-count-overf
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
.coherent_dma_mask = DMA_BIT_MASK
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type
[-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmamask = DMA_BIT_MASK
h...@nvidia.com; Vu Pham ; Yuval Avnery
> ; jakub.kicin...@netronome.com;
> k...@vger.kernel.org
> Subject: Re: [RFC net-next v1 1/3] vfio/mdev: Inherit dma masks of parent
> device
>
> On Fri, 8 Mar 2019 16:07:54 -0600
> Parav Pandit wrote:
>
> > Inherit dm
On Fri, 8 Mar 2019 16:07:54 -0600
Parav Pandit wrote:
> Inherit dma mask of parent device in child mdev devices, so that
> protocol stack can use right dma mask while doing dma mappings.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c | 4
> 1 file changed, 4 insert
Inherit dma mask of parent device in child mdev devices, so that
protocol stack can use right dma mask while doing dma mappings.
Signed-off-by: Parav Pandit
---
drivers/vfio/mdev/mdev_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Jonas Gorski
commit 18836b48ebae20850631ee2916d0cdbb86df813d upstream.
The switch to the generic dma ops made dma masks mandatory, breaking
devices having them not set. In case of bcm63xx, it
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Jonas Gorski
commit 18836b48ebae20850631ee2916d0cdbb86df813d upstream.
The switch to the generic dma ops made dma masks mandatory, breaking
devices having them not set. In case of bcm63xx, it
Hello,
Jonas Gorski wrote:
> The switch to the generic dma ops made dma masks mandatory, breaking
> devices having them not set. In case of bcm63xx, it broke ethernet with
> the following warning when trying to up the device:
>
> [2.633123] ---
On 2/21/19 1:56 AM, Jonas Gorski wrote:
> The switch to the generic dma ops made dma masks mandatory, breaking
> devices having them not set. In case of bcm63xx, it broke ethernet with
> the following warning when trying to up the device:
>
> [2.633123] ---
On Thu, Feb 21, 2019 at 10:56:42AM +0100, Jonas Gorski wrote:
> The switch to the generic dma ops made dma masks mandatory, breaking
> devices having them not set. In case of bcm63xx, it broke ethernet with
> the following warning when trying to up the device:
Looks good:
Reviewed-by:
The switch to the generic dma ops made dma masks mandatory, breaking
devices having them not set. In case of bcm63xx, it broke ethernet with
the following warning when trying to up the device:
[2.633123] [ cut here ]
[2.637949] WARNING: CPU: 0 PID: 325 at ./include
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initia
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initial
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:58 +0100
> We've been moving to a model where the device just sets the DMA mask
> supported by it, instead of having to fallback to something it thinks
> the platform might support. Sparc64 is the remaining holdout forcing
> drivers to supply
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:57 +0100
> We've been moving to a model where the device just sets the DMA mask
> supported by it, instead of having to fallback to something it thinks
> the platform might support. Sparc64 is the remaining holdout forcing
> drivers to supply
We've been moving to a model where the device just sets the DMA mask
supported by it, instead of having to fallback to something it thinks
the platform might support. Sparc64 is the remaining holdout forcing
drivers to supply a matching mask. Change dma_4v_supported to just
check if the supplied
f x86 and
implementations based on it since the dawn of time. Only one parisc
and two sparc64 instances failed larger than required DMA masks, and
this series fixes that up and updates the documentation that devices
don't need to handle DMA mask fallbacks.
We've been moving to a model where the device just sets the DMA mask
supported by it, instead of having to fallback to something it thinks
the platform might support. Sparc64 is the remaining holdout forcing
drivers to supply a matching mask. Change dma_4u_supported to just
check if the supplied
There is no harm in setting a 64-bit mask even if we don't need it,
and the current ccio code is one of the few place in the kernel
still rejecting larger than required DMA masks.
Signed-off-by: Christoph Hellwig
---
drivers/parisc/ccio-dma.c | 4 ++--
1 file changed, 2 insertions(
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initia
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initia
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initia
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initial
If there is no ZONE_DMA32 we might need GFP_DMA to be able to
allocate memory that satisfies a 32-bit DMA mask.
Reported-by: Christian Zigotzky
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
kernel/dma/direct.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol sup
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol sup
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol sup
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol sup
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol sup
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol sup
or devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol supports a 34-bit (16GiB) DMA address
space, by interpreting the value presented in the address cycle across
the 32 `ad' lines as a 32-bit word rather than byte a
On 11/07/18 15:40, Rob Herring wrote:
On Tue, Jul 10, 2018 at 12:43 PM Robin Murphy wrote:
Whilst the common firmware code invoked by dma_configure() initialises
devices' DMA masks according to limitations described by the respective
properties ("dma-ranges" for OF and _DM
bit DMA masks are so common we expect every architecture
+* to be able to satisfy them - either by not supporting more physical
+* memory, or by providing a ZONE_DMA32. If neither is the case, the
+* architecture needs to use an IOMMU instead of the direct mapp
On 10/01/18 15:32, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote:
+#ifdef CONFIG_ZONE_DMA
+ if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ return 0;
+#else
+ /*
+* Because 32-bit DMA masks are so common we expect ev
On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote:
>> +#ifdef CONFIG_ZONE_DMA
>> +if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
>> +return 0;
>> +#else
>> + /*
>> + * Because 32-bit DMA masks are so common we expect ever
lse
+ /*
+* Because 32-bit DMA masks are so common we expect every architecture
+* to be able to satisfy them - either by not supporting more physical
+* memory, or by providing a ZONE_DMA32. If neither is the case, the
+* architecture needs to use an IOMMU instead of
(struct device *dev, struct
scatterlist *sgl,
return nents;
}
+int dma_direct_supported(struct device *dev, u64 mask)
+{
+#ifdef CONFIG_ZONE_DMA
+ if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ return 0;
+#else
+ /*
+* Because 32-bit DMA masks are so common
(struct device *dev, struct
scatterlist *sgl,
return nents;
}
+int dma_direct_supported(struct device *dev, u64 mask)
+{
+#ifdef CONFIG_ZONE_DMA
+ if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ return 0;
+#else
+ /*
+* Because 32-bit DMA masks are so common
Properly handle limiting of DMA masks based on device and bus
capabilities.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_driver.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging
Hi,
Thank you for the review.
On Wed, Nov 1, 2017 at 1:09 PM, Dan Carpenter wrote:
> On Tue, Oct 31, 2017 at 11:56:16AM +, Gilad Ben-Yossef wrote:
>>
>> - if (!dev->coherent_dma_mask)
>> - dev->coherent_dma_mask = DMA_BIT_MASK(DMA_BIT_MASK_LEN);
>> + if (rc) {
>> +
On Tue, Oct 31, 2017 at 11:56:16AM +, Gilad Ben-Yossef wrote:
>
> - if (!dev->coherent_dma_mask)
> - dev->coherent_dma_mask = DMA_BIT_MASK(DMA_BIT_MASK_LEN);
> + if (rc) {
> + dev_err(dev, "Error: failed in dma_set_mask, mask=%par\n",
> + &d
On Tue, Oct 31, 2017 at 11:56:16AM +, Gilad Ben-Yossef wrote:
> + dma_mask = (dma_addr_t)(DMA_BIT_MASK(DMA_BIT_MASK_LEN));
> + while (dma_mask > 0x7fffUL) {
> + if (dma_supported(&plat_dev->dev, dma_mask)) {
> + rc = dma_set_coherent_mask(&plat_dev->d
Properly handle limiting of DMA masks based on device and bus
capabilities.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_driver.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Robin Murphy
commit f7f6634d23830ff74335734fbdb28ea109c1f349 upstream.
Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
inadvertently relying on the default 32-bit DMA mas
Hi Nikita,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170112]
[cannot apply to arm64/for-next/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Nikita-
>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64
>> dma_base, u64 size,
>> if (!dev->archdata.dma_ops)
>> dev->archdata.dma_ops = &swiotlb_dma_ops;
>>
>> + /*
>> +* Whatever the parent bus can set. A device must not set
>> +* a
On Wednesday, January 11, 2017 9:31:52 PM CET Nikita Yushchenko wrote:
> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64
> dma_base, u64 size,
> if (!dev->archdata.dma_ops)
> dev->archdata.dma_ops = &swiotlb_dma_ops;
>
> + /*
> +* Whatev
hat.
---
Nikita Yushchenko (2):
dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
arm64: avoid increasing DMA masks above what hardware supports
arch/arm/include/asm/dma-mapping.h | 1 +
arch/arm/mm/dma-mapping.c | 3 +-
a
There are cases when device supports wide DMA addresses wider than
device's connection supports.
In this case driver sets DMA mask based on knowledge of device
capabilities. That must succeed to allow drivers to initialize.
However, swiotlb or iommu still need knowledge about actual device
capabi
looked Linux simply ignores all but the
last one in that case - which can't be combined into a simple bitmask,
so I'm not entirely sure where to go from there. Especially as so far it
seems to be a problem exclusive to one not-widely-available ageing
early-access development platform...
It
On Wednesday, January 11, 2017 3:37:22 PM CET Nikita Yushchenko wrote:
> > I actually have a third variation of this problem involving a PCI root
> > complex which *could* drive full-width (40-bit) addresses, but won't,
> > due to the way its PCI<->AXI interface is programmed. That would require
>
> I actually have a third variation of this problem involving a PCI root
> complex which *could* drive full-width (40-bit) addresses, but won't,
> due to the way its PCI<->AXI interface is programmed. That would require
> even more complicated dma-ranges handling to describe the windows of
> valid
1 - 100 of 155 matches
Mail list logo
