On 2025-01-23 11:10 am, Prakash Gupta wrote:
On Wed, Jan 22, 2025 at 03:00:58PM -0500, Connor Abbott wrote:
@@ -125,12 +125,25 @@ static void qcom_adreno_smmu_resume_translation(const
void *cookie, bool termina
struct arm_smmu_domain *smmu_domain = (void *)cookie;
struct arm_
many more bugs we
might uncover in MMU-500 and/or QCom firmware's emulation thereof :)
Reviewed-by Robin Murphy
Signed-off-by: Connor Abbott
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 15 ++-
drivers/iommu/arm/arm-smmu/arm-smmu.c | 30
On 2025-01-17 6:47 pm, Connor Abbott wrote:
On some SMMUv2 implementations, including MMU-500, SMMU_CBn_FSR.SS
asserts an interrupt. The only way to clear that bit is to resume the
transaction by writing SMMU_CBn_RESUME, but typically resuming the
transaction requires complex operations (copying
On 2025-01-15 7:46 pm, Florian Fainelli wrote:
From: Justin Chen
Network device driver's receive path typically do the following:
- dma_map_single(.., DMA_FROM_DEVICE)
- dma_sync_single_for_cpu() to allow the CPU to inspect packet
descriptors
- dma_unmap_single(.., DMA_FROM_DEVICE) when rel
On 2024-12-19 11:30 am, Will Deacon wrote:
On Mon, Dec 16, 2024 at 09:10:17AM -0800, Rob Clark wrote:
From: Rob Clark
On mmu-500, stall-on-fault seems to stall all context banks, causing the
GMU to misbehave. So limit this feature to smmu-v2 for now.
MMU-500 has public documentation so plea
On 2024-11-22 8:33 pm, Brian Johannesmeyer wrote:
On Fri, Nov 22, 2024 at 12:13 PM Brian Johannesmeyer
wrote:
We identified a security issue in the swiotlb unmapping operation, stemming
from the way some drivers save streaming DMA addresses. This issue can
potentially be exploited by a malicio
On 2024-11-04 5:41 pm, Jason Gunthorpe wrote:
A minority of page table implementations (arm_lpae, armv7) are unique in
how they handle partial unmap of large IOPTEs.
Other implementations will unmap the large IOPTE and return it's
length. For example if a 2M IOPTE is present and the first 4K is
87c7bf7 ("iommu: Remove struct iommu_ops *iommu from
arch_setup_dma_ops()")
Signed-off-by: Robin Murphy
---
drivers/media/platform/ti/omap3isp/isp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/ti/omap3isp/isp.c
b/drivers/media/platform/ti/omap3isp
preferred.
Thanks,
Robin.
[1]
https://lore.kernel.org/linux-iommu/c44545c6d07c65d89daa297298c27bb0f15c8b84.1728393458.git.robin.mur...@arm.com/
Robin Murphy (4):
remoteproc/omap: Handle ARM dma_iommu_mapping
media: omap3isp: Handle ARM dma_iommu_mapping
iommu/omap: Add minimal fwnode suppo
With the last external caller of bus_iommu_probe() now gone, make it
internal as it really should be.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 3 ++-
include/linux/iommu.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu
rnel.org/linux-iommu/0dbde87b-593f-4b14-8929-b78e18954...@ti.com/
Reported-by: H. Nikolaus Schaller
Link:
https://lore.kernel.org/linux-media/a7c284a9-33a5-4e21-9b57-9c4c213cc...@goldelico.com/
Fixes: 17de3f5fdd35 ("iommu: Retire bus ops")
Signed-off-by: Robin Murphy
---
d
87c7bf7 ("iommu: Remove struct iommu_ops *iommu from
arch_setup_dma_ops()")
Signed-off-by: Robin Murphy
---
drivers/remoteproc/omap_remoteproc.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remote
On 21/10/2024 1:17 pm, Jason Gunthorpe wrote:
On Mon, Oct 21, 2024 at 12:32:21PM +0100, Steven Price wrote:
that, we can always do it in two steps (unmap the 2M region and remap
the borders). At some point it'd be good to have some kind of atomic
page table updates, so we don't have this short
On 2024-10-17 7:13 pm, Sean Anderson wrote:
It can be surprising to the user if DMA functions are only traced on
success. On failure, it can be unclear what the source of the problem
is. Fix this by tracing all functions even when they fail. Cases where
we BUG/WARN are skipped, since those should
On 2024-09-20 9:20 am, Andy Yan wrote:
From: Andy Yan
The vop mmu support translate physical address upper 4 GB to iova
below 4 GB. So set dma mask to 64 bit to indicate we support address
4GB.
This can avoid warnging message like this on some boards with DDR
4 GB:
rockchip-drm display-su
On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
+/**
+ * enum drm_panthor_sync_op_flags - Synchronization operation
flags.
+ */
+enum drm_panthor_sync_op_flags {
+ /** @DRM_PANT
On 22/08/2024 6:09 pm, Abdellatif El Khlifi wrote:
Add devicetree binding schema for the External Systems remote processors
The External Systems remote processors are provided on the Corstone-1000
IoT Reference Design Platform via the SSE-710 subsystem.
For more details about the External Syste
On 06/09/2024 11:56 am, Will Deacon wrote:
On Thu, Sep 05, 2024 at 05:27:28PM +0100, Robin Murphy wrote:
On 05/09/2024 4:53 pm, Will Deacon wrote:
On Thu, Sep 05, 2024 at 05:49:56AM -0700, Rob Clark wrote:
From: Rob Clark
This reverts commit 85b715a334583488ad7fbd3001fe6fd617b7d4c0.
It was
On 2024-09-05 6:10 pm, Rob Clark wrote:
On Thu, Sep 5, 2024 at 10:00 AM Rob Clark wrote:
On Thu, Sep 5, 2024 at 9:27 AM Robin Murphy wrote:
On 05/09/2024 4:53 pm, Will Deacon wrote:
Hi Rob,
On Thu, Sep 05, 2024 at 05:49:56AM -0700, Rob Clark wrote:
From: Rob Clark
This reverts commit
On 05/09/2024 4:53 pm, Will Deacon wrote:
Hi Rob,
On Thu, Sep 05, 2024 at 05:49:56AM -0700, Rob Clark wrote:
From: Rob Clark
This reverts commit 85b715a334583488ad7fbd3001fe6fd617b7d4c0.
It was causing gpu smmu faults on x1e80100.
I _think_ what is causing this is the change in ordering of
On 05/09/2024 2:57 pm, Rob Clark wrote:
On Thu, Sep 5, 2024 at 6:24 AM Robin Murphy wrote:
On 05/09/2024 1:49 pm, Rob Clark wrote:
From: Rob Clark
This reverts commit 85b715a334583488ad7fbd3001fe6fd617b7d4c0.
It was causing gpu smmu faults on x1e80100.
I _think_ what is causing this is
On 05/09/2024 2:24 pm, Robin Murphy wrote:
On 05/09/2024 1:49 pm, Rob Clark wrote:
From: Rob Clark
This reverts commit 85b715a334583488ad7fbd3001fe6fd617b7d4c0.
It was causing gpu smmu faults on x1e80100.
I _think_ what is causing this is the change in ordering of
__arm_lpae_clear_pte
On 05/09/2024 1:49 pm, Rob Clark wrote:
From: Rob Clark
This reverts commit 85b715a334583488ad7fbd3001fe6fd617b7d4c0.
It was causing gpu smmu faults on x1e80100.
I _think_ what is causing this is the change in ordering of
__arm_lpae_clear_pte() (dma_sync_single_for_device() on the pgtable
mem
On 2024-08-29 2:42 pm, Neil Armstrong wrote:
Hi,
On 11/08/2024 09:09, Baruch Siach wrote:
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use plain a
On 2024-08-28 2:03 pm, Petr Tesařík wrote:
On Wed, 28 Aug 2024 13:02:31 +0100
Robin Murphy wrote:
On 2024-08-22 7:37 pm, mhkelle...@gmail.com wrote:
From: Michael Kelley
Background
==
Linux device drivers may make DMA map/unmap calls in contexts that
cannot block, such as in an
On 2024-08-22 7:37 pm, mhkelle...@gmail.com wrote:
From: Michael Kelley
Background
==
Linux device drivers may make DMA map/unmap calls in contexts that
cannot block, such as in an interrupt handler. Consequently, when a
DMA map call must use a bounce buffer, the allocation of swiotlb
m
nfusion from drivers/iommu is no
more, I too thoroughly approve of the overall idea.
Acked-by: Robin Murphy
nfusion from drivers/iommu is no
more, I too thoroughly approve of the overall idea.
Acked-by: Robin Murphy
nfusion from drivers/iommu is no
more, I too thoroughly approve of the overall idea.
Acked-by: Robin Murphy
t thinking ahead, might it be worth a logical "are SG segment limits
relevant?" wrapper around the dev->dma_parms reference? Not a big deal
for now if we think this site is the only user, so either way,
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
drive
On 2024-08-09 9:00 am, Tian, Kevin wrote:
From: Nicolin Chen
Sent: Friday, August 9, 2024 7:00 AM
On Thu, Aug 08, 2024 at 01:38:44PM +0100, Robin Murphy wrote:
On 06/08/2024 9:25 am, Tian, Kevin wrote:
From: Nicolin Chen
Sent: Saturday, August 3, 2024 8:32 AM
From: Robin Murphy
Currently
On 06/08/2024 9:25 am, Tian, Kevin wrote:
From: Nicolin Chen
Sent: Saturday, August 3, 2024 8:32 AM
From: Robin Murphy
Currently, iommu-dma is the only place outside of IOMMUFD and drivers
which might need to be aware of the stage 2 domain encapsulated within
a nested domain. This would be
On 2024-08-08 10:35 am, Petr Tesařík wrote:
On Wed, 7 Aug 2024 19:14:58 +0100
Catalin Marinas wrote:
On Wed, Aug 07, 2024 at 04:19:38PM +0200, Petr Tesařík wrote:
On Fri, 2 Aug 2024 10:37:38 +0100
Catalin Marinas wrote:
On Fri, Aug 02, 2024 at 09:03:47AM +0300, Baruch Siach wrote:
diff --g
On 2024-08-02 7:03 am, Baruch Siach wrote:
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Per the bot report this only works
On 2024-06-24 3:36 pm, Teddy Astie wrote:
Hello Robin,
Thanks for the thourough review.
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0af39bbbe3a3..242cefac77c9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -480,6 +480,15 @@ config VIRTIO_IOMMU
Sa
On 2024-06-24 6:36 pm, Easwar Hariharan wrote:
Hi Jason,
On 6/24/2024 9:32 AM, Jason Gunthorpe wrote:
On Mon, Jun 24, 2024 at 02:36:45PM +, Teddy Astie wrote:
+bool xen_iommu_capable(struct device *dev, enum iommu_cap cap)
+{
+ switch (cap) {
+ case IOMMU_CAP_CACHE_COHERENCY:
+
On 2024-06-23 4:21 am, Baolu Lu wrote:
On 6/21/24 11:09 PM, Teddy Astie wrote:
Le 19/06/2024 à 18:30, Jason Gunthorpe a écrit :
On Thu, Jun 13, 2024 at 01:50:22PM +, Teddy Astie wrote:
+struct iommu_domain *xen_iommu_domain_alloc(unsigned type)
+{
+ struct xen_iommu_domain *domain;
+
On 2024-06-21 5:08 pm, TSnake41 wrote:
From: Teddy Astie
In the context of Xen, Linux runs as Dom0 and doesn't have access to the
machine IOMMU. Although, a IOMMU is mandatory to use some kernel features
such as VFIO or DMA protection.
In Xen, we added a paravirtualized IOMMU with iommu_op hyp
On 23/05/2024 6:52 pm, Rob Clark wrote:
From: Rob Clark
Add an io-pgtable method to walk the pgtable returning the raw PTEs that
would be traversed for a given iova access.
Have to say I'm a little torn here - with my iommu-dma hat on I'm not
super enthusiastic about adding any more overhead
On 23/05/2024 6:52 pm, Rob Clark wrote:
From: Rob Clark
Add an io-pgtable method to walk the pgtable returning the raw PTEs that
would be traversed for a given iova access.
Have to say I'm a little torn here - with my iommu-dma hat on I'm not
super enthusiastic about adding any more overhead
On 2024-06-13 10:38 pm, Sebastian Reichel wrote:
Hi,
On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
wrote:
On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
IOMMUs
On 2024-06-12 1:50 pm, Philippe Mathieu-Daudé wrote:
On 12/6/24 14:48, Peter Maydell wrote:
On Wed, 12 Jun 2024 at 13:33, Philippe Mathieu-Daudé
wrote:
Hi Zhenyu,
On 12/6/24 04:05, Zhenyu Zhang wrote:
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 3c93c0c0a6..3cefac6d43 100644
--- a/hw/ar
ot.
*/
So this I think this is being triggered by a workaround for broken DT.
This was introduced by Robin Murphy +CC though you may need to ask on
kernel list because ARM / QEMU fun.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723288836628
On 29/05/2024 6:32 am, Lu Baolu wrote:
The IOMMU subsystem has undergone some changes, including the removal
of iommu_ops from the bus structure. Consequently, the existing domain
allocation interface, which relies on a bus type argument, is no longer
relevant:
struct iommu_domain *iommu_do
On 30/05/2024 6:11 pm, Yury Norov wrote:
On Wed, May 29, 2024 at 04:12:25PM +0100, Robin Murphy wrote:
Hi Alexander,
On 27/03/2024 3:23 pm, Alexander Lobakin wrote:
Now that we have generic bitmap_read() and bitmap_write(), which are
inline and try to take care of non-bound-crossing and
Hi Alexander,
On 27/03/2024 3:23 pm, Alexander Lobakin wrote:
Now that we have generic bitmap_read() and bitmap_write(), which are
inline and try to take care of non-bound-crossing and aligned cases
to keep them optimized, collapse bitmap_{get,set}_value8() into
simple wrappers around the former
On 11/04/2024 4:04 pm, Thorsten Blum wrote:
Use `find . -type f -exec sed -i 's/\/the/g' {} +` to find all
occurrences of "the the" and replace them with a single "the".
[...]
diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
index d60b09a5acfc..a75da9a01f91 100644
---
On 11/04/2024 4:04 pm, Thorsten Blum wrote:
Use `find . -type f -exec sed -i 's/\/the/g' {} +` to find all
occurrences of "the the" and replace them with a single "the".
[...]
diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
index d60b09a5acfc..a75da9a01f91 100644
---
On 18/03/2024 2:51 pm, Steven Price wrote:
virt_to_pfn() isn't available on x86 (except to xen) so breaks
COMPILE_TEST builds. Avoid its use completely by instead storing the
struct page pointer allocated in panthor_device_init() and using
page_to_pfn() instead.
Signed-off-by: Steven Price
---
On 18/03/2024 1:49 pm, Steven Price wrote:
On 18/03/2024 13:08, Boris Brezillon wrote:
On Mon, 18 Mar 2024 11:31:05 +
Steven Price wrote:
On 18/03/2024 08:58, Boris Brezillon wrote:
Putting a hard dependency on CONFIG_PM is not possible because of a
circular dependency issue, and it's ac
On 18/03/2024 8:58 am, Boris Brezillon wrote:
Putting a hard dependency on CONFIG_PM is not possible because of a
circular dependency issue, and it's actually not desirable either. In
order to support this use case, we forcibly resume at init time, and
suspend at unplug time.
Reported-by: kernel
On 2024-03-01 4:42 pm, abdellatif.elkhl...@arm.com wrote:
From: Abdellatif El Khlifi
introduce the bindings for Arm remoteproc support.
Signed-off-by: Abdellatif El Khlifi
---
.../bindings/remoteproc/arm,rproc.yaml| 69 +++
MAINTAINERS
On 2024-03-11 1:22 pm, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:11:28 +
Robin Murphy wrote:
On 2024-03-11 11:52 am, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:49:56 +0200
Jani Nikula wrote:
On Mon, 11 Mar 2024, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:05:01 +0200
On 2024-03-11 11:52 am, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:49:56 +0200
Jani Nikula wrote:
On Mon, 11 Mar 2024, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:05:01 +0200
Jani Nikula wrote:
This breaks the config for me:
SYNCinclude/config/auto.conf.cmd
GEN Makef
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 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:
On 2023-12-15 7:13 am, Kever Yang wrote:
Hi Jagan,
On 2023/12/15 14:36, Jagan Teki wrote:
Hi Heiko/Kerver/Anatoloj,
On Mon, Dec 11, 2023 at 2:30 PM Jagan Teki
wrote:
Unlike RK3399, Sunxi/Meson DW HDMI the new Rockchip SoC Rk3328 would
support external vendor PHY with DW HDMI chip.
Support
s, at least) in the SMMU
getting wedged and the GPU stuck without memory access.
Reviewed-by: Robin Murphy
Cc: sta...@vger.kernel.org
Signed-off-by: Rob Clark
---
I didn't add a fixes tag because really this issue has been there
all along, but either didn't matter with other firmwa
On 07/12/2023 9:24 pm, Rob Clark wrote:
From: Rob Clark
We also want the default domain for the GMU to be an identy domain,
so it does not get a context bank assigned. Without this, both
of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
allocating and configuring a context ba
On 07/12/2023 12:54 pm, Dmitry Baryshkov wrote:
In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
driver just to those machines. Allow it to be built for any 32-bit
Qualcomm platform (ARCH_QCOM).
Acked-by: Robin Murphy
Unless Joerg disagrees, I think it should be fine
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/ar
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/ar
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/ar
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the
On 28/11/2023 11:50 pm, Jason Gunthorpe wrote:
On Tue, Nov 28, 2023 at 06:00:13PM -0500, Pasha Tatashin wrote:
On Tue, Nov 28, 2023 at 5:53 PM Robin Murphy wrote:
On 2023-11-28 8:49 pm, Pasha Tatashin wrote:
Convert iommu/fsl_pamu.c to use the new page allocation functions
provided in iommu
On 2023-11-28 10:50 pm, Pasha Tatashin wrote:
On Tue, Nov 28, 2023 at 5:34 PM Robin Murphy wrote:
On 2023-11-28 8:49 pm, Pasha Tatashin wrote:
Convert iommu/dma-iommu.c to use the new page allocation functions
provided in iommu-pages.h.
These have nothing to do with IOMMU pagetables, they
decisively seems more useful than deferring forever.
Signed-off-by: Robin Murphy
---
I realised that last time I sent this I probably should have CCed a
wider audience of reviewers, so here's one with an updated commit
message as well to make the resend more worthwhile.
drivers/gpu/drm/med
On 2023-11-16 4:17 am, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 08:23:54PM +, Robin Murphy wrote:
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested
On 2023-11-16 4:17 am, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 08:23:54PM +, Robin Murphy wrote:
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obvi
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obvi
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously far, far too much for a stable
fix, but then it's also not the refactoring we want for the future
either, si
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously far, far too much for a stable
fix, but then it's also not the refactoring we want for the future
either, si
On 11/11/2023 6:45 pm, Chuck Zmudzinski wrote:
Enabling the new option, ARM_DMA_USE_IOMMU_XEN, fixes this error when
attaching the Exynos mixer in Linux dom0 on Xen on the Chromebook Snow
(and probably on other devices that use the Exynos mixer):
[drm] Exynos DRM: using 1440.fimd device for
On 13/11/2023 6:37 am, Yong Wu (吴勇) wrote:
[...]
+properties:
+ compatible:
+const: secure_cma_region
Still wrong compatible. Look at other bindings - there is nowhere
underscore. Look at other reserved memory bindings especially.
Also, CMA is a Linux thingy, so either not suitable for bi
On 2023-11-03 5:02 pm, Duje Mihanović wrote:
On Friday, November 3, 2023 4:34:54 PM CET Robin Murphy wrote:
On 2023-11-02 3:20 pm, Duje Mihanović wrote:
+config ARCH_MMP
+ bool "Marvell MMP SoC Family"
+ select ARM_GIC
+ select ARM_ARCH_TIMER
+ select ARM_
On 2023-11-02 3:20 pm, Duje Mihanović wrote:
Add ARCH_MMP configuration option for Marvell PXA1908 SoC.
Signed-off-by: Duje Mihanović
---
arch/arm64/Kconfig.platforms | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
On 2023-11-02 3:26 pm, Mark Brown wrote:
On Thu, Nov 02, 2023 at 04:20:29PM +0100, Duje Mihanović wrote:
The SSPA driver currently seems to generate ARM32 assembly, which causes
build errors when building a kernel for an ARM64 ARCH_MMP platform.
Fixes: fa375d42f0e5 ("ASoC: mmp: add sspa support
On 29/09/2023 4:45 pm, Will Deacon wrote:
On Mon, Sep 25, 2023 at 06:54:42PM +0100, Robin Murphy wrote:
On 2023-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
On 29/09/2023 4:45 pm, Will Deacon wrote:
On Mon, Sep 25, 2023 at 06:54:42PM +0100, Robin Murphy wrote:
On 2023-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
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 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-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
coherent SMMUs (like we have on sm8350 platform).
Hmm, but is it right that it should fail in the first place?
On 2023-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
coherent SMMUs (like we have on sm8350 platform).
Hmm, but is it right that it should fail in the first place?
On 2023-09-25 14:29, Jason Gunthorpe wrote:
On Mon, Sep 25, 2023 at 02:07:50PM +0100, Robin Murphy wrote:
On 2023-09-23 00:33, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote:
virtio isn't setting ops->pgsize_bitmap for the sake of direct mapping
On 2023-09-23 00:33, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote:
virtio isn't setting ops->pgsize_bitmap for the sake of direct mappings
either; it sets it once it's discovered any instance, since apparently it's
assuming that all inst
On 22/09/2023 5:27 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 02:13:18PM +0100, Robin Murphy wrote:
On 22/09/2023 1:41 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote:
They're not strictly equivalent: this check works around a temp
On 22/09/2023 1:41 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote:
They're not strictly equivalent: this check works around a temporary issue
with the IOMMU core, which calls map/unmap before the domain is
finalized.
Where? The above points to
On 2023-09-21 17:44, Jason Gunthorpe wrote:
On Thu, Sep 21, 2023 at 08:12:03PM +0800, Baolu Lu wrote:
On 2023/9/21 15:51, Yi Liu wrote:
diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index 4a7c5c8fdbb4..3c8660fe9bb1 100644
--- a/include/uapi/linux/iommufd.h
+++ b/inclu
On 20/09/2023 3:32 pm, Mark Rutland wrote:
Hi Naresh,
On Wed, Sep 20, 2023 at 11:29:12AM +0200, Naresh Kamboju wrote:
[ my two cents ]
While running LTP pty07 test cases on arm64 juno-r2 with Linux next-20230919
the following kernel crash was noticed.
I have been noticing this issue intermitte
On 2023-09-19 09:15, Jean-Philippe Brucker wrote:
On Mon, Sep 18, 2023 at 05:37:47PM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 17dcd826f5c2..3649586f0e5c 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
On 2023-09-18 12:51, Niklas Schnelle wrote:
Pull out the sync operation from viommu_map_pages() by implementing
ops->iotlb_sync_map. This allows the common IOMMU code to map multiple
elements of an sg with a single sync (see iommu_map_sg()). Furthermore,
it is also a requirement for IOMMU_CAP_DEF
On 12/09/2023 4:53 pm, Rob Herring wrote:
On Tue, Sep 12, 2023 at 11:13:50AM +0100, Robin Murphy wrote:
On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote:
On 12/09/2023 08:16, Yong Wu (吴勇) wrote:
Hi Rob,
Thanks for your review.
On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote
On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote:
On 12/09/2023 08:16, Yong Wu (吴勇) wrote:
Hi Rob,
Thanks for your review.
On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote:
External email : Please do not click links or open attachments until
you have verified the sender or the co
On 2023-09-06 19:10, Laurentiu Tudor wrote:
On 9/6/2023 8:21 PM, Robin Murphy wrote:
On 2023-09-06 17:01, Laurentiu Tudor wrote:
MC being a plain DMA master as any other device in the SoC and
being live at OS boot time, as soon as the SMMU is probed it
will immediately start triggering
On 2023-09-06 17:01, Laurentiu Tudor wrote:
MC being a plain DMA master as any other device in the SoC and
being live at OS boot time, as soon as the SMMU is probed it
will immediately start triggering faults because there is no
mapping in the SMMU for the MC. Pre-create such a mapping in
the SMM
On 2023-09-04 16:34, Jean-Philippe Brucker wrote:
On Fri, Aug 25, 2023 at 05:21:26PM +0200, Niklas Schnelle wrote:
Add ops->flush_iotlb_all operation to enable virtio-iommu for the
dma-iommu deferred flush scheme. This results inn a significant increase
in
in performance in exchange for a wi
On 2023-09-04 17:16, Boris Brezillon wrote:
On Mon, 4 Sep 2023 16:22:19 +0100
Steven Price wrote:
On 04/09/2023 10:26, Boris Brezillon wrote:
On Mon, 4 Sep 2023 08:42:08 +0100
Steven Price wrote:
On 01/09/2023 17:10, Boris Brezillon wrote:
On Wed, 9 Aug 2023 18:53:15 +0200
Boris Brezi
1 - 100 of 1087 matches
Mail list logo
