On 2022-03-23 19:16, Linus Torvalds wrote:
On Wed, Mar 23, 2022 at 12:06 PM Robin Murphy wrote:
On 2022-03-23 17:27, Linus Torvalds wrote:
I'm assuming that the ath9k issue is that it gives DMA mapping a big
enough area to handle any possible packet size, and just expects -
quite reasonably
On 2022-03-23 17:27, Linus Torvalds wrote:
On Wed, Mar 23, 2022 at 12:19 AM Oleksandr Natalenko
wrote:
The following upstream commits:
aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE
break ath9k-based Wi-Fi access
On 2022-03-23 12:54, Miguel Luis wrote:
Allows userspace to check for SMMUv3 features.
What will userspace do with that information?
It hardly matters what fancy new features might be present, if the
kernel and/or the abstracted interfaces available to userspace aren't
using them. Any
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to
On 2022-02-21 15:43, Shameer Kolothum via iommu wrote:
IORT rev E.d introduces more details into the RMR node Flags
field. Add temporary definitions to describe and access these
Flags field until ACPICA header is updated to support E.d.
This patch can be reverted once the include/acpi/actbl2.h
On 2022-02-21 15:43, Shameer Kolothum wrote:
Get ACPI IORT RMR regions associated with a dev reserved
so that there is a unity mapping for them in SMMU.
Signed-off-by: Shameer Kolothum
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 13 -
1 file changed, 12 insertions(+), 1
On 2022-02-21 15:43, Shameer Kolothum via iommu wrote:
Add helper functions (iort_iommu_get/put_rmrs()) that
retrieves/releases RMR memory descriptors associated
with a given IOMMU. This will be used by IOMMU drivers
to set up necessary mappings.
Invoke it from the generic iommu helper
On 2022-02-21 15:43, Shameer Kolothum wrote:
A union is introduced to struct iommu_resv_region to hold
any firmware specific data. This is in preparation to add
support for IORT RMR reserve regions and the union now holds
the RMR specific information.
Signed-off-by: Shameer Kolothum
---
seem entirely unreasonable, so that basic assumption no
longer holds. Make iommu-dma robust and get the sort order it needs by
explicitly sorting, which means we can also save the effort at creation
time and just build the list in whatever natural order the DT had.
Signed-off-by: Robin Murphy
On 2022-03-22 11:41, Mika Westerberg wrote:
Hi Robin,
I tried this now on two Intel systems. One with integrated Thunderbolt
and one with discrete. There was a small issue, see below but once fixed
it worked as expected :)
On Fri, Mar 18, 2022 at 05:42:58PM +, Robin Murphy wrote:
Between
On 2022-03-22 09:14, Christoph Hellwig wrote:
On Fri, Mar 18, 2022 at 05:42:57PM +, Robin Murphy wrote:
VT-d's dmar_platform_optin() actually represents a combination of
properties fairly well standardised by Microsoft as "Pre-boot DMA
Protection" and "Kernel DMA Protection&q
ACPI table check.
If it looks good can roll it into your series for v3, or if this series goes
as is for v2 it can come on its own.
CC: Mario Limonciello
Signed-off-by: Robin Murphy
---
v2: Give up trying to look for specific devices, just look for evidence
that firmware cares at all.
I stil
at implies that firmware is playing
the game overall, so we'll use that to assume that all Thunderbolt ports
should be correctly marked and thus will end up fully protected.
CC: Mario Limonciello
Signed-off-by: Robin Murphy
---
v2: Give up trying to look for specific devices, just look fo
toph Hellwig
Signed-off-by: Robin Murphy
---
v2: New patch
drivers/iommu/intel/iommu.c | 2 ++
include/linux/iommu.h | 7 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 0c7975848972..20d8e1f60068 100644
--- a/drivers
re:
https://lore.kernel.org/linux-iommu/f887686a-e7e4-f031-97e8-dbeb1c088...@arm.com/T/
Thanks,
Robin.
Robin Murphy (2):
iommu: Add capability for pre-boot DMA protection
thunderbolt: Make iommu_dma_protection more accurate
drivers/iommu/intel/iommu.c | 2 ++
drivers/thunderbolt/dom
On 2022-03-18 14:47, mika.westerb...@linux.intel.com wrote:
On Fri, Mar 18, 2022 at 02:08:16PM +, Robin Murphy wrote:
On 2022-03-18 13:25, mika.westerb...@linux.intel.com wrote:
Hi Robin,
On Fri, Mar 18, 2022 at 12:01:42PM +, Robin Murphy wrote:
This adds quite a lot code
On 2022-03-18 13:25, mika.westerb...@linux.intel.com wrote:
Hi Robin,
On Fri, Mar 18, 2022 at 12:01:42PM +, Robin Murphy wrote:
This adds quite a lot code and complexity, and honestly I would like to
keep it as simple as possible (and this is not enough because we need to
make sure
On 2022-03-18 11:38, mika.westerb...@linux.intel.com wrote:
Hi Mario,
On Thu, Mar 17, 2022 at 08:36:13PM +, Limonciello, Mario wrote:
Here is a proposal on top of what you did for this.
The idea being check the ports right when the links are made if they exist
(all the new USB4 stuff) and
On 2022-03-18 06:44, Mika Westerberg wrote:
Hi Robin,
Thanks for working on this!
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
Between me trying to get rid of iommu_present() and Mario wanting to
support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
On 2022-03-17 19:13, Michael Kelley (LINUX) wrote:
From: Robin Murphy Sent: Thursday, March 17, 2022 10:20
AM
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
Add a wrapper function to set dma_coherent, avoiding the need for
complex #ifdef's when setting it in architecture independent
On 2022-03-18 05:12, Michael Kelley (LINUX) wrote:
From: Robin Murphy Sent: Thursday, March 17, 2022 10:15
AM
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
Add a wrapper function to set dma_coherent, avoiding the need for
complex #ifdef's when setting it in architecture independent code.
No. It might happen to work out on the architectures you're looking at,
but if Hyper-V were ever to
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device is
set based on the VMbus node in ACPI, but the PCI device has no
ACPI node and defaults to not hardware coherent.
On 2022-03-17 16:25, Michael Kelley via iommu wrote:
VMbus synthetic devices are not represented in the ACPI DSDT -- only
the top level VMbus device is represented. As a result, on ARM64
coherence information in the _CCA method is not specified for
synthetic devices, so they default to not
On 2022-03-17 16:25, Michael Kelley wrote:
Export acpi_get_dma_attr() so that it can be used by the Hyper-V
VMbus driver, which may be built as a module. The related function
acpi_dma_configure_id() is already exported.
No. Use device_get_dma_attr() like everyone else, please.
Robin.
n't assume that IOMMU translation being enabled
for any reason is sufficient on its own; full (expensive) DMA protection
will still only be imposed on untrusted devices.
CC: Mario Limonciello
Signed-off-by: Robin Murphy
---
This supersedes my previous attempt just trying to replace
iommu_prese
On 2022-03-17 08:08, Mika Westerberg wrote:
Hi Robin,
On Wed, Mar 16, 2022 at 07:17:57PM +, Robin Murphy wrote:
The feeling I'm getting from all this is that if we've got as far as
iommu_dma_protection_show() then it's really too late to meaningfully
mitigate bad firmware.
Note
On 2022-03-17 12:26, Peter Geis wrote:
On Thu, Mar 17, 2022 at 6:37 AM Robin Murphy wrote:
On 2022-03-17 00:14, Peter Geis wrote:
Good Evening,
I apologize for raising this email chain from the dead, but there have
been some developments that have introduced even more questions.
I've looped
On 2022-03-17 00:14, Peter Geis wrote:
Good Evening,
I apologize for raising this email chain from the dead, but there have
been some developments that have introduced even more questions.
I've looped the Rockchip mailing list into this too, as this affects
rk356x, and likely the upcoming
On 2022-03-16 18:34, Limonciello, Mario wrote:
[Public]
Can the USB4 CM make the device links in the DVSEC case perhaps too? I
would
think we want that anyway to control device suspend ordering.
If I had something discrete to try I'd dust off the DVSEC patch I wrote
before to
try it, but
On 2022-03-16 17:53, Limonciello, Mario wrote:
[Public]
There is a way to figure out the "tunneled" PCIe ports by looking at
certain properties and we do that already actually. The BIOS has the
following under these ports:
On 2022-03-16 17:37, Mika Westerberg wrote:
Hi Mario,
On Wed, Mar 16, 2022 at 05:24:38PM +, Limonciello, Mario wrote:
[Public]
On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
What we want is to make sure the Tunneled PCIe ports get the full
IOMMU
protection. In case
On 2022-03-16 12:45, Mika Westerberg wrote:
Hi Robin,
On Wed, Mar 16, 2022 at 11:25:51AM +, Robin Murphy wrote:
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Furthermore
On 2022-03-16 13:01, Dmitry Osipenko wrote:
On 3/16/22 12:12, Sascha Hauer wrote:
On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote:
On 3/14/22 11:18, Sascha Hauer wrote:
On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote:
On 3/11/22 11:33, Sascha Hauer wrote:
The
On 2022-03-14 22:42, Dmitry Osipenko wrote:
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that
On 2022-03-14 22:42, Dmitry Osipenko wrote:
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that
that generically by simply looking at
whether we're currently attached to a translation domain or not.
Signed-off-by: Robin Murphy
---
I don't have the means to test this, but I'm at least 80% confident
in my unpicking of the structures to retrieve the correct device...
drivers/thunderbolt/domain.c | 7
On 2022-03-15 18:36, Limonciello, Mario wrote:
+ Christian Kellner (Bolt userspace maintainer)
On 3/15/2022 13:07, Robin Murphy wrote:
On 2022-03-15 16:54, Limonciello, Mario via iommu wrote:
[Public]
On Tue, Mar 15, 2022 at 11:24:55AM -0500, Mario Limonciello wrote:
- * handled
On 2022-03-15 16:54, Limonciello, Mario via iommu wrote:
[Public]
On Tue, Mar 15, 2022 at 11:24:55AM -0500, Mario Limonciello wrote:
-* handled natively using IOMMU. It is enabled when IOMMU is
-* enabled and ACPI DMAR table has DMAR_PLATFORM_OPT_IN set.
+* handled
On 2022-03-15 05:07, Jacob Pan wrote:
DMA mapping API is the de facto standard for in-kernel DMA. It operates
on a per device/RID basis which is not PASID-aware.
Some modern devices such as Intel Data Streaming Accelerator, PASID is
required for certain work submissions. To allow such devices
On 2022-03-14 19:44, Matthew Rosato wrote:
s390x will introduce an additional domain type that is used for
managing IOMMU owned by KVM. Define the type here and add an
interface for allocating a specified type vs the default type.
I'm also not a huge fan of adding a new domain_alloc interface
On 2022-03-14 11:31, Robin Murphy wrote:
On 2022-03-13 12:56, Peter Geis wrote:
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
Wiadomość napisana przez Peter Geis w dniu
26.01.2022, o godz. 21:24:
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after
On 2022-03-13 12:56, Peter Geis wrote:
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
Wiadomość napisana przez Peter Geis w dniu 26.01.2022, o
godz. 21:24:
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after enabling the clock we set it in order for
On 2022-03-11 08:19, Eric Auger wrote:
Hi guys,
On 2/21/22 4:43 PM, Shameer Kolothum wrote:
Hi,
Since we now have an updated verion[0] of IORT spec(E.d) which
addresses the memory attributes issues discussed here [1],
this series now make use of it.
The pull request for ACPICA E.d related
On 2022-02-25 07:51, Sascha Hauer wrote:
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Further to the clarification of the underlying
On 2022-03-09 08:37, elaine.zhang wrote:
hi,
在 2022/3/9 下午4:18, Sascha Hauer 写道:
Hi Elaine,
On Wed, Mar 09, 2022 at 09:41:39AM +0800, zhangq...@rock-chips.com wrote:
hi，all：
Let me explain the clock dependency：
From the clock tree, pclk_vo0 and hclk_vo0 are completely
On 2022-03-08 19:04, Alex Deucher via iommu wrote:
Add preliminary documenation for AMD IOMMU.
Signed-off-by: Alex Deucher
---
Documentation/x86/amd-iommu.rst | 85 +++
Documentation/x86/index.rst | 1 +
Documentation/x86/intel-iommu.rst | 2 +-
3
: Stuart Yoder
Cc: Laurentiu Tudor
Signed-off-by: Lu Baolu
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Jason Gunthorpe
Reviewed-by: Robin Murphy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo
iommu_group_dma_owner_claimed(struct iommu_group *group);
The device userspace assignment must be disallowed if the DMA owner
claiming interface returns failure.
Reviewed-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
Signed-off-by: Kevin Tian
Signed-off-by: Lu Baolu
On 2022-03-07 20:53, Geert Uytterhoeven wrote:
- sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but
does define __sparc__, hence replace the check for SPARC by a check
for __sparc__,
- powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__,
but
On 2022-03-07 13:03, Robin Murphy wrote:
On 2022-03-07 12:47, Gilad Ben-Yossef wrote:
On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy wrote:
On 2022-03-07 12:17, Gilad Ben-Yossef wrote:
On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy
wrote:
The "overlap" is in the sense of having mor
On 2022-03-07 12:47, Gilad Ben-Yossef wrote:
On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy wrote:
On 2022-03-07 12:17, Gilad Ben-Yossef wrote:
On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy wrote:
The "overlap" is in the sense of having more than one mapping within the
same
On 2022-03-07 12:17, Gilad Ben-Yossef wrote:
On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy wrote:
The "overlap" is in the sense of having more than one mapping within the
same cacheline:
[ 142.458120] DMA-API: add_dma_entry start P=ba79f200 N=ba79f
D=ba79f200 L=10 DMA_FROM_DEVI
On 2022-03-07 10:48, Corentin Labbe wrote:
Le Mon, Mar 07, 2022 at 09:59:29AM +0200, Gilad Ben-Yossef a �crit :
On Sun, Mar 6, 2022 at 11:49 PM Herbert Xu wrote:
On Fri, Mar 04, 2022 at 02:30:06PM +0100, Corentin Labbe wrote:
Hello
I got:
[ 17.563793] [ cut here
On 2022-03-04 13:55, Eric Auger wrote:
Hi Robin,
On 3/4/22 1:22 PM, Robin Murphy wrote:
On 2022-03-04 10:43, Lu Baolu wrote:
Hi Eric,
On 2022/3/4 18:34, Eric Auger wrote:
I hit a WARN_ON() when unbinding an e1000e driver just after boot:
sudo modprobe -v vfio-pci
echo vfio-pci | sudo tee
On 2022-03-04 04:46, yf.wang--- via iommu wrote:
From: Yunfei Wang
In alloc_iova_fast function, if an iova alloc request fail,
it will free the iova ranges present in the percpu iova
rcaches and free global iova rcache and then retry, but
flushing CPU iova rcaches only for each online CPU,
On 2022-03-04 10:43, Lu Baolu wrote:
Hi Eric,
On 2022/3/4 18:34, Eric Auger wrote:
I hit a WARN_ON() when unbinding an e1000e driver just after boot:
sudo modprobe -v vfio-pci
echo vfio-pci | sudo tee -a
/sys/bus/pci/devices/0004:01:00.0/driver_override
vfio-pci
echo 0004:01:00.0 | sudo tee
still want cached32_node to only move
upwards, but we should reset the allocation size if *any* 32-bit space
has become available.
Reported-by: Yunfei Wang
Signed-off-by: Robin Murphy
Would you mind adding:
Cc:
Applied without stable tag for now. If needed, please consider
re-sending it for s
:49 a.m., Robin Murphy wrote:
On 2022-02-25 19:27, Michael Cheng wrote:
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a
good thing to do from the start ]
* Thanks for adding the arm64 maintainer and sorry I didn't rope them
in sooner.
Why does i915 need
available.
Reported-by: Yunfei Wang
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index b28c9435b898..170e0f33040e 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
On 2022-03-03 03:43, yf.w...@mediatek.com wrote:
On Thu, 2022-03-03 at 07:52 +0800, Miles Chen wrote:
Thanks for your explanation.
YF showed me some numbers yesterday and maybe we can have a further
discussion in that test case. (It looks like that some iovas are
freed but
their pfn_lo(s) are
:49 a.m., Robin Murphy wrote:
On 2022-02-25 19:27, Michael Cheng wrote:
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a
good thing to do from the start ]
* Thanks for adding the arm64 maintainer and sorry I didn't rope them
in sooner.
Why does i915 need
to be valid.
Robin.
On 2022-02-25 10:24 a.m., Robin Murphy wrote:
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush
to be valid.
Robin.
On 2022-02-25 10:24 a.m., Robin Murphy wrote:
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush
On 2022-03-01 23:29, Miles Chen via iommu wrote:
Hi Yunfei,
Since __alloc_and_insert_iova_range fail will set the current alloc
iova size to max32_alloc_size (iovad->max32_alloc_size = size),
when the retry is executed into the __alloc_and_insert_iova_range
function, the retry action will be
est choice.
Reviewed-by: Robin Murphy
Cheers,
Robin.
+usable stream IDs.
+
required:
- reg-names
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
est choice.
Reviewed-by: Robin Murphy
Cheers,
Robin.
+usable stream IDs.
+
required:
- reg-names
On 2022-03-01 01:59, yf.wang--- via iommu wrote:
From: Yunfei Wang
In alloc_iova_fast function, if __alloc_and_insert_iova_range fail,
alloc_iova_fast will try flushing rcache and retry alloc iova, but
this has an issue:
Since __alloc_and_insert_iova_range fail will set the current alloc
iova
On 2022-02-28 14:19, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 02:11:54PM +0100, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300
Hi Matt,
On 2022-03-01 03:00, Matt Flax wrote:
Hi All,
It seems that the ZONE_DMA changes have broken the operation of Rochip rk3399
chipsets from v5.10.22 onwards.
It isn't clear what needs to be changed to get any of these boards up and
running again. Any pointers on how/what to change ?
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
nk should
go away now.
With that (or if there *is* some subtle wacky case where PageHighmem()
can actually return true for !MMU, a comment to remind us in future),
Reviewed-by: Robin Murphy
Cheers,
Robin.
___
iommu mailing list
iommu@lists.linux-fo
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
On 2022-02-25 09:32, Colin Ian King wrote:
The variable res is being assigned a value that isn't being read
later. The assignment is redundant and can be removed.
Cleans up clang scan warning:
drivers/iommu/arm/arm-smmu/arm-smmu.c:2109:10: warning: Although the
value stored to 'res' is used in
On 2022-02-25 13:11, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет:
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The
On 2022-02-24 05:29, Lu Baolu wrote:
On 2/24/22 1:16 PM, Lu Baolu wrote:
Hi Robin and Jason,
On 2/24/22 2:02 AM, Jason Gunthorpe wrote:
On Wed, Feb 23, 2022 at 06:00:06PM +, Robin Murphy wrote:
...and equivalently just set owner_cnt directly to 0 here. I don't
see a
realistic use-case
On 2022-02-23 18:02, Jason Gunthorpe via iommu wrote:
On Wed, Feb 23, 2022 at 06:00:06PM +, Robin Murphy wrote:
...and equivalently just set owner_cnt directly to 0 here. I don't see a
realistic use-case for any driver to claim the same group more than once,
and allowing it in the API just
On 2022-02-18 00:55, Lu Baolu wrote:
[...]
+/**
+ * iommu_group_claim_dma_owner() - Set DMA ownership of a group
+ * @group: The group.
+ * @owner: Caller specified pointer. Used for exclusive ownership.
+ *
+ * This is to support backward compatibility for vfio which manages
+ * the dma
Gunthorpe wrote:
On Wed, Feb 23, 2022 at 01:04:00PM +, Robin Murphy wrote:
1 - tmp->driver is non-NULL because tmp is already bound.
1.a - If tmp->driver->driver_managed_dma == 0, the group must currently be
DMA-API-owned as a whole. Regardless of what driver dev has unbound
On 2022-02-23 05:01, Lu Baolu wrote:
On 2/23/22 7:53 AM, Jason Gunthorpe wrote:
To spell it out, the scheme I'm proposing looks like this:
Well, I already got this, it is what is in driver_or_DMA_API_token()
that matters
I think you are suggesting to do something like:
if
On 2022-02-22 16:21, Christoph Hellwig wrote:
On Fri, Feb 18, 2022 at 01:39:45PM +0200, Mikko Perttunen wrote:
The context bus is a "dummy" bus that contains struct devices that
correspond to IOMMU contexts assigned through Host1x to processes.
Even when host1x itself is built as a module, the
On 2022-02-22 16:21, Christoph Hellwig wrote:
On Fri, Feb 18, 2022 at 01:39:45PM +0200, Mikko Perttunen wrote:
The context bus is a "dummy" bus that contains struct devices that
correspond to IOMMU contexts assigned through Host1x to processes.
Even when host1x itself is built as a module, the
On 2022-02-22 15:16, Jason Gunthorpe wrote:
On Tue, Feb 22, 2022 at 10:58:37AM +, Robin Murphy wrote:
On 2022-02-21 23:48, Jason Gunthorpe wrote:
On Mon, Feb 21, 2022 at 08:43:33PM +, Robin Murphy wrote:
On 2022-02-19 07:32, Christoph Hellwig wrote:
So we are back to the callback
On 2022-02-21 23:48, Jason Gunthorpe wrote:
On Mon, Feb 21, 2022 at 08:43:33PM +, Robin Murphy wrote:
On 2022-02-19 07:32, Christoph Hellwig wrote:
So we are back to the callback madness instead of the nice and simple
flag? Sigh.
TBH, I *think* this part could be a fair bit simpler
On 2022-02-19 07:32, Christoph Hellwig wrote:
So we are back to the callback madness instead of the nice and simple
flag? Sigh.
TBH, I *think* this part could be a fair bit simpler. It looks like this
whole callback mess is effectively just to decrement group->owner_cnt,
but since we should
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Implement the get_streamid_offset required for supporting context
isolation. Since old firmware cannot support context isolation
without hacks that we don't want to implement, check the firmware
binary to see if context isolation should be
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Implement the get_streamid_offset required for supporting context
isolation. Since old firmware cannot support context isolation
without hacks that we don't want to implement, check the firmware
binary to see if context isolation should be
On 2022-02-21 15:28, Mikko Perttunen wrote:
On 2/21/22 17:23, Robin Murphy wrote:
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node
On 2022-02-21 15:28, Mikko Perttunen wrote:
On 2/21/22 17:23, Robin Murphy wrote:
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node.
Couldn't you simply make "iommu-map" an allowed property on the host1x
node itself?
On 2022-02-18 11:39, Mikko Perttunen via iommu wrote:
Add schema information for the memory-contexts property used to
specify context stream IDs. This uses the standard iommu-map property
inside a child node.
Couldn't you simply make "iommu-map" an allowed property on the host1x
node itself?
On 2022-02-16 17:37, Florian Fainelli wrote:
On 2/16/22 3:13 AM, Robin Murphy wrote:
On 2022-02-15 22:43, Florian Fainelli wrote:
Some platforms might define the same memory region to be suitable for
used by a kernel supporting CONFIG_DMA_RESTRICTED_POOL while maintaining
compatibility
On 2022-02-15 22:43, Florian Fainelli wrote:
Some platforms might define the same memory region to be suitable for
used by a kernel supporting CONFIG_DMA_RESTRICTED_POOL while maintaining
compatibility with older kernels that do not support that. This is
achieved by declaring the node this way;
On 2022-02-15 13:42, Will Deacon wrote:
On Tue, Feb 15, 2022 at 01:30:26PM +, Robin Murphy wrote:
On 2022-02-15 13:00, Will Deacon wrote:
On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
On 2022/1/24 21:11, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work
501 - 600 of 7732 matches
Mail list logo
