On 17/03/16 22:02, Sinan Kaya wrote:
Prefixing dma_to_phys and phys_to_dma API with swiotlb so that
they are no longer part of the DMA API. These APIs do not exist
on all architectures and breaks compatibility.
In preparation for the clean up, also make the ARCH implementation
known by defining
On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Add a one-to-one iommu mapping for bman private data memory (FBPR).
This is required for BMAN to work without faults behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 11 +
On 12/04/2019 11:26, John Garry wrote:
On 09/04/2019 13:53, Zhen Lei wrote:
Currently the IOMMU dma contains 3 modes: passthrough, lazy, strict. The
passthrough mode bypass the IOMMU, the lazy mode defer the invalidation
of hardware TLBs, and the strict mode invalidate IOMMU hardware TLBs
synchr
t touching arm64
pagetable code, I'm wary of conflicts and cross-tree dependencies for
our actual ARCH_HAS_PTE_DEVMAP implementation. Thus it would be nice if
these could be picked up for 5.2 via mm or nvdimm as appropriate, such
that we can then handle the devmap patch itself via arm64 next cycle.
the commit message]
Acked-by: Michal Hocko
Reviewed-by: David Hildenbrand
Signed-off-by: Robin Murphy
Signed-off-by: Anshuman Khandual
---
include/linux/mmzone.h | 1 +
kernel/memremap.c | 10 --
mm/hmm.c | 2 --
3 files changed, 5 insertions(+), 8 deletions(
cleanup.
Suggested-by: Jerome Glisse
Signed-off-by: Robin Murphy
---
include/linux/mm.h | 43 +--
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 76769749b5a5..d76dfb7ac617 100644
--- a/include
ONE_DEVICE users have little chance of
functioning correctly without __HAVE_ARCH_PTE_DEVMAP, so let's clean
that up the same way as ARCH_HAS_PTE_SPECIAL and make it the proper
dependency so the real situation is clearer.
Signed-off-by: Robin Murphy
---
arch/powerpc/Kconfig
[since this is in my inbox...]
On 2020-03-19 10:28 am, Borislav Petkov wrote:
On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote:
I thought we agreed that decrypted is absolutely the wrong term.
I don't think we did. At least I don't know where we did that.
So NAK - if you wa
On 2020-03-20 2:16 pm, Christoph Hellwig wrote:
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Hmm, this is _almost_,
On 13/11/2019 1:37 pm, Christoph Hellwig wrote:
Hi all,
I've recently beeing chatting with Lu about using dma-iommu and
per-device DMA ops in the intel IOMMU driver, and one missing feature
in dma-iommu is a bypass mode where the direct mapping is used even
when an iommu is attached to improve p
On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is alre
On 2019-11-13 8:41 pm, Florian Fainelli wrote:
On 11/13/19 12:34 PM, Robin Murphy wrote:
On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA
On 14/11/2019 7:41 am, Christoph Hellwig wrote:
On Wed, Nov 13, 2019 at 02:45:15PM +, Robin Murphy wrote:
In all honesty, this seems silly. If we can set a per-device flag to say
"oh, bypass these ops and use some other ops instead", then we can just as
easily simply give the
On 19/11/2019 10:26 am, Marek Szyprowski wrote:
Hi Krzysztof,
On 19.11.2019 10:44, Krzysztof Kozlowski wrote:
On Tue, 19 Nov 2019 at 17:27, Marek Szyprowski wrote:
Hi Christoph,
On 13.11.2019 08:35, Christoph Hellwig wrote:
Currently each architectures that wants to override dma_to_phys and
On 19/11/2019 5:00 pm, Christoph Hellwig wrote:
On Tue, Nov 19, 2019 at 01:57:43PM +0100, Nicolas Saenz Julienne wrote:
Hi Rob & Christoph,
do you mind if I append v2 of this into my upcoming v3 RPi4 PCIe support
series, I didn't do it initially as I thought this was going to be a
contentious pa
On 16/11/2019 6:22 am, Christoph Hellwig wrote:
On Fri, Nov 15, 2019 at 06:12:48PM +, Robin Murphy wrote:
And is that any different from where you would choose to "just" set a
generic bypass flag?
Same spots, as intel-iommu moves from the identify to a dma domain when
settin
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing
On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only ho
On 21/11/2019 7:34 am, Christoph Hellwig wrote:
Robin, does this mean you ACK this series for the powerpc use case?
Yeah, I think we've nailed down sufficient justification now for having
a generalised flag, so at that point it makes every bit of sense to
convert PPC's private equivalent.
R
higher accesible DMA address.
^^ super-nit only because I can't not see my editor currently
highlighting the typo: "accessible"
Regardless of that though,
Reviewed-by: Robin Murphy
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- rework ACPI code to avoid d
On 25/11/2019 7:44 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
I think the dma_limit argument to iommu_dma_alloc_iova should be a u64
and/or we need to use min_t and open
On 2019-11-26 6:51 pm, Nicolas Saenz Julienne wrote:
On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote:
On 25/11/2019 7:44 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
Just as an FYI, this introduces a warning on arm32 allyesconfig for me
Since these are trivially handled by the .domain_{get,set}_attr
callbacks when relevant, we can streamline struct iommu_ops for
everyone.
Signed-off-by: Robin Murphy
---
drivers/iommu/fsl_pamu_domain.c | 125 +---
include/linux/iommu.h | 6 --
2 files
NDOWS handling directly into the PAMU driver.
Signed-off-by: Robin Murphy
---
Just a cleanup opportunity I spotted whilst poking around in the area.
drivers/iommu/fsl_pamu_domain.c | 20
drivers/iommu/iommu.c | 20
2 files changed, 20 insertions(+
On 25/09/18 21:16, Christoph Hellwig wrote:
Looking at the code I think this commit is simply broken for
architectures not using arch_setup_dma_ops, but instead setting up
the dma ops through arch specific magic.
I'll revert the patch.
Ugh, sorry about missing that too. Ack to a revert - think
max_dma > 0. Otherwise,
Reviewed-by: Robin Murphy
+}
+
static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
{
- dma_addr_t addr = force_dma_unencrypted() ?
- __phys_to_dma(dev, phys) : phys_to_dma(dev, phys);
- return addr +
goto again;
Ah right, in that situation we should probably end up here anyway, so
that's good enough - definitely not worth any more #ifdeffery above.
Nits aside,
Reviewed-by: Robin Murphy
}
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
-
On 20/09/18 19:52, Christoph Hellwig wrote:
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 ++-
kernel/dma/di
quot;theory" it's also ok to have a mask < ZONE_DMA_BITS as long as it's
big enough to fit all memory :-)
Yeah, we could do that.
FWIW I like it even if just for looking slightly more readable. With
that fixup,
Reviewed-by: Robin Murphy
On 27/09/18 16:28, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:12:25PM +0100, Robin Murphy wrote:
+u64 dma_direct_get_required_mask(struct device *dev)
+{
+ u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
+
+ return (1ULL << (fls64(max_dma) -
On 27/09/18 16:30, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
+static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
dma_mask,
+ u64 *phys_mask)
+{
+ if (force_dma_unencrypted())
+ *phys_mask
On 27/09/18 16:32, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:58:04PM +0100, Robin Murphy wrote:
}
#endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3c404e33d946..64466b7ef67b 100644
--- a/kernel/dma/direct.c
+++ b/kernel
On 27/09/18 17:27, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 05:14:56PM +0100, Robin Murphy wrote:
This just seemed more readable to me than min_not_zero, but if others
prefer min_not_zero I can switch.
Nah, just checking whether there were any intentionally different
assumptions
On 04/10/18 00:48, Alexander Duyck wrote:
It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
<= physiscal memory size") the logic of the test was changed from a "<" to
a ">=" however I don't see any reason for that change. I am assuming that
there was some additional chang
On 01/11/2018 19:32, Rob Herring wrote:
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon wrote:
Hi Rob,
On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote:
Convert ARM PMU binding to DT schema format using json-schema.
Cc: Will Deacon
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infrade
On 08/11/2018 15:59, Thomas Petazzoni wrote:
Hello,
I'm jumping into the discussion, but I clearly don't have all the
context of the discussion.
On Thu, 8 Nov 2018 15:54:31 +0000, Robin Murphy wrote:
This seems like a semantic different between the two representations, or am
On 19/11/2018 14:18, Ramon Fried wrote:
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
-* Because 32-bit DMA masks are so common we expect every architecture
-* to be able to satisfy them - either by not s
Hi Andrew,
On 26/11/2018 11:12, Andrew Murray wrote:
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute fl
On 10/12/2018 14:21, Rafael David Tinoco wrote:
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at addr
On 11/08/2019 09:05, Christoph Hellwig wrote:
We still treat devices without a DMA mask as defaulting to 32-bits for
both mask, but a few releases ago we've started warning about such
cases, as they require special cases to work around this sloppyness.
Add a dma_mask field to struct platform_obje
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation i
knows as actual system/device memory" to better explain the WARN...
Either way, though,
Reviewed-by: Robin Murphy
- BUG_ON(pfn_valid(PHYS_PFN(phys_addr)));
+ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
+ return DMA_MAPPING_ERROR;
if (dma_is_direct(ops))
On 20/05/18 14:49, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
ange done in the API.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
Acked-by: Bjorn Helgaas
---
drivers/iommu/of_iommu.c | 5 +--
drivers/of/base.c| 102 +++
drivers/of/irq.c | 5 +--
drivers/pc
for the moment, so:
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/iommu/of_iommu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
On 20/05/18 14:49, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 21 +
inclu
On 20/05/18 14:49, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Looks like this is the final arch_setup_dma_ops offender, yay!
Sign
On 20/05/18 14:49, Nipun Gupta wrote:
of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
1 file changed, 1 insertion(+)
diff
On 20/05/18 14:49, Nipun Gupta wrote:
fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
ff-by: Robin Murphy
---
Here's hoping the buildbot comes by to point out what I've inevitably
missed, although I did check a cursory cross-compile of ppc64_defconfig
to iron out the obvious howlers.
The motivation here is that I'm looking at adding set_mask overrides
for arm64, and hav
As for the other mask-related hooks, standardise the arch override into
a Kconfig option, and also pull the generic implementation into the DMA
mapping code rather than having it hide away in the platform bus code.
Signed-off-by: Robin Murphy
---
arch/ia64/Kconfig | 1 +
arch
On 05/07/18 20:37, Christoph Hellwig wrote:
On Wed, Jul 04, 2018 at 06:50:11PM +0100, Robin Murphy wrote:
Arch-specific implementions for dma_set_{coherent_,}mask() currently
rely on an inconsistent mix of arch-defined Kconfig symbols and macro
overrides. Now that we have a nice centralised
On 05/07/18 20:38, Christoph Hellwig wrote:
On Wed, Jul 04, 2018 at 06:50:12PM +0100, Robin Murphy wrote:
As for the other mask-related hooks, standardise the arch override into
a Kconfig option, and also pull the generic implementation into the DMA
mapping code rather than having it hide away
On 08/07/18 16:07, Christoph Hellwig wrote:
On Fri, Jul 06, 2018 at 03:20:34PM +0100, Robin Murphy wrote:
What are you trying to do? I really don't want to see more users of
the hooks as they are are a horribly bad idea.
I really need to fix the ongoing problem we have where, due to
On 10/07/18 12:39, Christoph Hellwig wrote:
On Wed, Jul 04, 2018 at 06:50:12PM +0100, Robin Murphy wrote:
As for the other mask-related hooks, standardise the arch override into
a Kconfig option, and also pull the generic implementation into the DMA
mapping code rather than having it hide away
On 09/07/18 12:18, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
I guess this is about as neat as it can get;
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm
On 09/07/18 12:18, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
R
On 09/07/18 12:18, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
No more nits from me :)
Acked-by: Robin Murphy
improvement in API terms.
For arm64,
Acked-by: Robin Murphy
Cheers,
Robin.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc
On 2019-10-08 9:38 am, Yunsheng Lin wrote:
On 2019/9/25 18:41, Peter Zijlstra wrote:
On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote:
From the discussion above, It seems making the node_to_cpumask_map()
NUMA_NO_NODE aware is the most feasible way to move forwad.
That's still wro
introduced.
cc: Benjamin Herrenschmidt
cc: David Gibson
cc: Michael Ellerman
cc: Paul Mackerras
cc: Michael Roth
cc: Alexey Kardashevskiy
cc: Paul Burton
cc: Robin Murphy
cc: Bartlomiej Zolnierkiewicz
cc: Marek Szyprowski
cc: Christoph Hellwig
Suggested-by: Michael S. Tsirkin
Signed-off-by: Ram
On 2023-09-26 20:34, Robin Murphy wrote:
On 2023-09-26 20:05, Janne Grunau wrote:
Hej,
On Fri, Sep 22, 2023 at 02:07:57PM -0300, Jason Gunthorpe wrote:
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason
On 2023-09-26 20:05, Janne Grunau wrote:
Hej,
On Fri, Sep 22, 2023 at 02:07:57PM -0300, Jason Gunthorpe wrote:
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c
On 31/03/2023 3:00 pm, Arnd Bergmann wrote:
On Mon, Mar 27, 2023, at 14:48, Robin Murphy wrote:
On 2023-03-27 13:13, Arnd Bergmann wrote:
[ HELP NEEDED: can anyone confirm that it is a correct assumption
on arm that a cache-coherent device writing to a page always results
in it being
On 2023-05-16 01:00, Jason Gunthorpe wrote:
The PLATFORM domain will be set as the default domain and attached as
normal during probe. The driver will ignore the initial attach from a NULL
domain to the PLATFORM domain.
After this, the PLATFORM domain's attach_dev will be called whenever we
deta
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the
same stuff, the way they relate to the IOMMU core is quiet different.
dma-iommu.c expects the core code to setup an UNMANAGED domain (of type
IOMMU_DOMAIN_DMA) and then configure
On 2023-05-16 01:00, Jason Gunthorpe wrote:
This callback requests the driver to create only a __IOMMU_DOMAIN_PAGING
domain, so it saves a few lines in a lot of drivers needlessly checking
the type.
More critically, this allows us to sweep out all the
IOMMU_DOMAIN_UNMANAGED and IOMMU_DOMAIN_DMA
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Robin was able to check the documentation and what fsl_pamu has
historically called detach_dev() is really putting the IOMMU into an
IDENTITY mode.
Unfortunately it was the other way around - it's the call to
fsl_setup_liodns() from fsl_pamu_probe()
On 2023-05-16 01:00, Jason Gunthorpe wrote:
These drivers don't support IOMMU_DOMAIN_DMA, so this commit effectively
allows them to support that mode.
The prior work to require default_domains makes this safe because every
one of these drivers is either compilation incompatible with dma-iommu.c,
On 2023-06-01 20:46, Jason Gunthorpe wrote:
On Thu, Jun 01, 2023 at 08:37:45PM +0100, Robin Murphy wrote:
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Robin was able to check the documentation and what fsl_pamu has
historically called detach_dev() is really putting the IOMMU into an
IDENTITY
On 2024-01-31 9:19 am, Tasmiya Nalatwad wrote:
Greetings,
[mainline] [linux-next] [6.8-rc1] [DLPAR] OOps kernel crash after
performing dlpar remove test
--- Traces ---
[58563.146236] BUG: Unable to handle kernel data access at
0x6b6b6b6b6b6b6b83
[58563.146242] Faulting instruction address:
Code: 38427bd0 7c0802a6 6000 7c0802a6 fba1ffe8
fbc1fff0 fbe1fff8 7cbf2b78 38a0 7cdd3378 f8010010 f821ffc1
4bff95d1 6000 7c7e1b79
[ 981.124374] ---[ end trace ]---
Thanks and Regards
On 1/31/24 16:18, Robin Murphy wrote:
On 2024-01-31 9:19 am, Tasmiya Nalatwad wr
On 2023-02-21 17:58, Christoph Hellwig wrote:
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
dma_default_coherent can be useful for determine default coherency
even on arches without noncoherent support.
How?
Indeed, "default" is conceptually meaningless when there is no possib
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So the main purpose of this patch is to fix MIPS’s broken per-device coherency.
To
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So the
On 2023-02-22 13:04, Jiaxun Yang wrote:
2023年2月22日 12:55，Robin Murphy 写道：
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv
On 2023-02-22 13:37, Jiaxun Yang wrote:
As for now all arches have dma_default_coherent matched with default
DMA coherency for of devices, so there is no need to have a standalone
config option.
This also fixes a case that for some MIPS platforms, coherency information
is not carried in devicetr
On 2023-03-27 13:13, Arnd Bergmann wrote:
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use th
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep
On 2021-02-04 07:29, Christoph Hellwig wrote:
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and io_tlb_end
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their pr
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
b
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the auth
On 2021-03-29 00:53, Bhaskar Chowdhury wrote:
s/Synopsys/Synopsis/ .two different places.
Erm, that is definitely not a typo... :/
..and for some unknown reason it introduce a empty line deleted and added
back.
Presumably your editor is configured to trim trailing whitespace on save.
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100
On 2021-03-31 16:32, Will Deacon wrote:
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin
On 2021-03-16 15:38, Christoph Hellwig wrote:
[...]
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f1e38526d5bd40..996dfdf9d375dd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3
On 2021-04-22 09:15, Claire Chang wrote:
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2
On 2021-04-22 09:15, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c |
On 2021-04-22 09:15, Claire Chang wrote:
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption,
On 2021-09-17 10:36, Roman Skakun wrote:
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
Well, something's gone badly wrong there - if you have to shadow the
entire thing in a bou
On 2021-10-15 07:36, meng...@windriver.com wrote:
From: Meng Li
When enable debug kernel configs,there will be calltrace as below:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is debug_smp_processor_id+0x20/0x30
CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.10
On 2021-01-07 17:57, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
Hi Greg and Konrad,
This change is intended to be non-arch specific. Any arch that lacks DMA access
control and has devices not behind an IOMMU can make use of it. Could you share
why
On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:
Hi All,
On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
On 1/5/21 7:41 PM, Claire Chang wrote:
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes in the device tree.
Signed-off-by: Cl
On 2021-01-13 17:43, Florian Fainelli wrote:
On 1/13/21 7:27 AM, Robin Murphy wrote:
On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:
Hi All,
On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
On 1/5/21 7:41 PM, Claire Chang wrote:
Add the initialization function to create
On 2021-01-13 12:48, Christoph Hellwig wrote:
+#ifdef CONFIG_SWIOTLB
+ if (unlikely(dev->dma_io_tlb_mem))
+ return swiotlb_alloc(dev, size, dma_handle, attrs);
+#endif
Another place where the dma_io_tlb_mem is useful to avoid the ifdef.
-phys_addr_t swiotlb_tbl_map_single(
1 - 100 of 187 matches
Mail list logo
