From: Jim Quinlan
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no regi
As the comment in usb_alloc_dev correctly states, drivers can't use
the DMA API on usb device, and at least calling dma_set_mask on them
is highly dangerous. Unlike what the comment states upper level drivers
also can't really use the presence of a dma mask to check for DMA
support, as the dma_mas
The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t. Currently the code compiles fine despite that, a pending
change to the DMA offset handling would create a compiler warning for
this case. Add an ifdef
Move the helpers to translate to and from direct mapping DMA addresses
to dma-direct.h. This not only is the most logical place, but the new
placement also avoids dependency loops with pending commits.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
arch/arm/common/dmabounce.c
dma_to_virt is entirely unused, remove it.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h| 18 +-
arch/arm/mach-omap1/include/mach/memory.h | 4
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.
On Tue, Sep 15, 2020 at 04:46:17PM -0400, Thomas Tai wrote:
> I tried out the suggested changes, and it successfully warned the null
> pointer without panic. I notice that there are some places outside the
> dma-direct, which calls dma_capable().
>
> https://elixir.bootlin.com/linux/v5.9-rc5/sour
The __arch_page_to_dma hook is long gone.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca3451..70d95677656044 100644
--- a/arch
Hi all,
this series adds range-based offsets to the dma-direct implementation. The
guts of the change are a patch from Jim with some modifications from me,
but to do it nicely we need to ARM patches to prepare for it as well.
Changes since v2:
- fix a mismerge
- return (phys_addr_t)-1 from tra
On Tue, Sep 15, 2020 at 01:55:01PM -0600, Mathieu Poirier wrote:
> That did the trick - the stm32 platform driver's probe() function completes
> and
> the remote processor is operatinal.
>
> That being said the value returned by function dma_to_pfn()
> is 0x137fff in the original code and 0x
On 2020/9/16 上午3:26, Raj, Ashok wrote:
IIUC, you are asking that part of the interface to move to a API interface
that potentially the new /dev/sva and VFIO could share? I think the API's
for PASID management themselves are generic (Jean's patchset + Jacob's
ioasid set management).
Yes, the in
On 2020/9/14 下午9:31, Jean-Philippe Brucker wrote:
If it's possible, I would suggest a generic uAPI instead of a VFIO specific
one.
A large part of this work is already generic uAPI, in
include/uapi/linux/iommu.h.
This is not what I read from this series, all the following uAPI is VFIO
speci
On 9/16/20 8:22 AM, Jacob Pan (Jun) wrote:
If user space wants to bind page tables, create the PASID with
/dev/sva, use ioctls there to setup the page table the way it wants,
then pass the now configured PASID to a driver that can use it.
Are we talking about bare metal SVA? If so, I don't see
> From: Jason Gunthorpe
> Sent: Tuesday, September 15, 2020 10:29 PM
>
> > Do they need a device at all? It's not clear to me why RID based
> > IOMMU management fits within vfio's scope, but PASID based does not.
>
> In RID mode vfio-pci completely owns the PCI function, so it is more
> natural
The "num_tlb_lines" might not be a power-of-2 value, being 48 on
Tegra210 for example. So the current way of calculating tlb_mask
using the num_tlb_lines is not correct: tlb_mask=0x5f in case of
num_tlb_lines=48, which will trim a setting of 0x30 (48) to 0x10.
Signed-off-by: Nicolin Chen
---
dri
Hi Jason,
On Tue, 15 Sep 2020 20:51:26 -0300, Jason Gunthorpe
wrote:
> On Tue, Sep 15, 2020 at 03:08:51PM -0700, Jacob Pan wrote:
> > > A PASID vIOMMU solution sharable with VDPA and VFIO, based on a
> > > PASID control char dev (eg /dev/sva, or maybe /dev/iommu) seems
> > > like a reasonable sta
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snoo
On Tue, Sep 15, 2020 at 03:08:51PM -0700, Jacob Pan wrote:
> > A PASID vIOMMU solution sharable with VDPA and VFIO, based on a PASID
> > control char dev (eg /dev/sva, or maybe /dev/iommu) seems like a
> > reasonable starting point for discussion.
>
> I am not sure what can really be consolidated
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareable domain, and so
even when snoop signals are wired up, they are only emitted for outer
shareable accesse
When the GPU's ACE-Lite interface is fully wired up and capable of
snooping CPU caches, it may be described as "dma-coherent" in
devicetree, which will already inform the DMA layer not to perform
unnecessary cache maintenance. However, we still need to ensure that
the GPU uses the appropriate cache
Hi all,
I polished up my original proof-of-concept a little while back, but now
that I've got my hands on my Juno again I've been able to actually test
it to my satisfaction, so here are proper patches!
It probably makes sense for patches #1 and #2 to stay together and both
go via drm-misc, provi
On Tue, Sep 15, 2020 at 12:26:32PM -0700, Raj, Ashok wrote:
> > Yes, there is. There is a limited pool of HW PASID's. If one user fork
> > bombs it can easially claim an unreasonable number from that pool as
> > each process will claim a PASID. That can DOS the rest of the system.
>
> Not sure ho
Hello Bjorn,
On Tue, Jul 14, 2020 at 1:19 PM Rajat Jain wrote:
>
> On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
> >
> > On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > > On Fri, Jul 10, 2020 at 03:29:22PM -0500,
Hi Jason,
On Tue, 15 Sep 2020 15:45:10 -0300, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > > PASID applies widely to many device and needs to be introduced with a
> > > wide community agreement so all scenarios will be supportable.
> >
> > True, rea
On 2020-09-15 11:09 a.m., Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 10:40:39AM -0400, Thomas Tai wrote:
+++ b/include/linux/dma-direct.h
@@ -62,9 +62,6 @@ static inline bool dma_capable(struct device *dev, dma_addr_t
addr, size_t size,
{
dma_addr_t end = addr + size - 1;
On Tue, Sep 15, 2020 at 07:41:22AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 14, 2020 at 05:01:47PM -0600, Mathieu Poirier wrote:
>
> [700 lines of the fullquote deleted..]
>
> > > + for (r = map; r->size; r++)
> > > + num_ranges++;
> > > +
> > > + new_map = kmemdup(map, array_size(nu
On Tue, Sep 15, 2020 at 03:45:10PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > > PASID applies widely to many device and needs to be introduced with a
> > > wide community agreement so all scenarios will be supportable.
> >
> > True, reading some
On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > PASID applies widely to many device and needs to be introduced with a
> > wide community agreement so all scenarios will be supportable.
>
> True, reading some of the earlier replies I was clearly confused as I
> thought you were talk
On Tue, Sep 15, 2020 at 08:33:41AM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 03:44:38PM -0700, Raj, Ashok wrote:
> > Hi Jason,
> >
> > I thought we discussed this at LPC, but still seems to be going in
> > circles :-(.
>
> We discused mdev at LPC, not PASID.
>
> PASID applies widel
ipmmu-vmsa driver is also used on Renesas RZ/G{1,2} Soc's, update the
description for the IPMMU_VMSA config symbol to reflect this.
Signed-off-by: Lad Prabhakar
Reviewed-by: Chris Paterson
Reviewed-by: Geert Uytterhoeven
---
v1->v2
* Updated commit description as suggested by Geert
* Included R
Use dma_alloc_pages to allocate DMAable pages instead of hoping that
the architecture either has GFP_DMA32 or not more than 4G of memory.
Signed-off-by: Christoph Hellwig
---
drivers/firewire/ohci.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/
Implement the alloc_noncoherent method to provide memory that is neither
coherent not contiguous.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 41 +++
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify process
address space and direct responses to the right address space.
Signed-off-by: Fenghua Y
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
Reviewed-by: Lu Baolu
---
v5:
- Reviewed by Lu Baolu
v2:
- Add this
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
Signed-o
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in E
Currently, the ENQCMD feature depends on CONFIG_IOMMU_SUPPORT.
Add X86_FEATURE_ENQCMD to the disabled features mask.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v8:
- Re-write commit message (Boris).
- Move "#ifdef CONFIG_IOMMU_SUPPORT" hunk from patch 9 (Boris).
v7:
- Split this patch
A PASID is allocated for an "mm" the first time any thread binds
to an SVM capable device and is freed from the "mm" when the SVM is
unbound by the last thread. It's possible for the "mm" to have different
PASID values in different binding/unbinding SVM cycles.
The mm's PASID (non-zero for valid P
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v4:
- Change PASID type to u32 (Christoph)
v3:
- Change
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".
No PASID type change
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Modify
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and a kernel-user transition to notify the
hardware of new work. What if both the translation and transition overhead
could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD
ena
This will allow IOMMU drivers to allocate non-contigous memory and
return a vmapped virtual address.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 5 +
kernel/dma/mapping.c| 33 +++--
2 files changed, 32 insertions(+), 6 deletions(-)
This API is the equivalent of alloc_pages, except that the returned memory
is guaranteed to be DMA addressable by the passed in device. The
implementation will also be used to provide a more sensible replacement
for DMA_ATTR_NON_CONSISTENT flag.
Additionally dma_alloc_noncoherent is switched over
All users are gone now, remove the API.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig | 1 -
arch/mips/jazz/jazzdma.c| 1 -
arch/mips/mm/dma-noncoherent.c | 6 --
arch/parisc/Kconfig | 1 -
arch/parisc/kernel/pci-dma.c| 6 --
include/l
Use the new non-coherent DMA API including proper ownership transfers.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/53c700.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index c59226d7e2f6b5..5117d90c
Use the new non-coherent DMA API including proper ownership transfers.
This includes adding additional calls to dma_sync_desc_dev as the
old syncing was rather ad-hoc.
Thanks to Thomas Bogendoerfer for debugging the ownership transfer
issues.
Signed-off-by: Christoph Hellwig
---
drivers/net/eth
Use the new non-coherent DMA API including proper ownership transfers.
This includes moving the DMA helpers to lib82596 based of an ifdef to
avoid include order problems.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/i825xx/lasi_82596.c | 25 ++---
drivers/net/ethernet/i825xx/lib825
Use the new non-coherent DMA API including proper ownership transfers.
This also means we can allocate the buffer memory with the proper
direction instead of bidirectional.
Signed-off-by: Christoph Hellwig
---
sound/mips/hal2.c | 58 ++-
1 file changed
Use the new non-coherent DMA API including proper ownership transfers.
This also means we can allocate the memory as DMA_TO_DEVICE instead
of bidirectional.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sgiwd93.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --gi
Add a new API to allocate and free memory that is guaranteed to be
addressable by a device, but which potentially is not cache coherent
for DMA.
To transfer ownership to and from the device, the existing streaming
DMA API calls dma_sync_single_for_device and dma_sync_single_for_cpu
must be used.
Switch the 53c700 driver to only use non-coherent descriptor memory if it
really has to because dma_alloc_coherent fails. This doesn't matter for
any of the platforms it runs on currently, but that will change soon.
To help with this two new helpers to transfer ownership to and from the
device ar
This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare
for untangling the coherent vs non-coherent DMA allocation API.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/i825xx/lasi_82596.c | 24 ++--
drivers/net/ethernet/i825xx/lib82596.c | 36 --
The au1000-eth driver contains none of the manual cache synchronization
required for using DMA_ATTR_NON_CONSISTENT. From what I can tell it
can be used on both dma coherent and non-coherent DMA platforms, but
I suspect it has been buggy on the non-coherent platforms all along.
Signed-off-by: Chri
DMA_ATTR_NON_CONSISTENT is a no-op except on PA-RISC and a few MIPS
configs, so don't set it in this ARM specific driver part.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gp
DMA_ATTR_NON_CONSISTENT is a no-op except on PA-RISC and a few MIPS
configs, so don't set it in this ARM specific driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/d
To prevent a compiler error when a method call alloc_pages is
added (which I plan to for the dma_map_ops).
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 67a0774e08
From: Sergey Senozhatsky
The patch partially reverts some of the UAPI bits of the buffer
cache management hints. Namely, the queue consistency (memory
coherency) user-space hint because, as it turned out, the kernel
implementation of this feature was misusing DMA_ATTR_NON_CONSISTENT.
The patch r
Hi all,
this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs
with a separate new dma_alloc_pages API, which is available on all
platforms. In addition to cleaning up the convoluted code path, this
ensures that other drivers that have asked for better support for
non-coherent D
On Mon 14 Sep 21:04 UTC 2020, John Stultz wrote:
> Allows qcom-pdc driver to be loaded as a permanent module.
>
> An earlier version of this patch was merged in a larger patchset
> but was reverted entirely when issues were found with other
> drivers, so now that Marc has provided a better soluti
On 2020-09-15 11:09 a.m., Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 10:40:39AM -0400, Thomas Tai wrote:
+++ b/include/linux/dma-direct.h
@@ -62,9 +62,6 @@ static inline bool dma_capable(struct device *dev, dma_addr_t
addr, size_t size,
{
dma_addr_t end = addr + size - 1;
On Tue, Sep 15, 2020 at 10:40:39AM -0400, Thomas Tai wrote:
>> +++ b/include/linux/dma-direct.h
>> @@ -62,9 +62,6 @@ static inline bool dma_capable(struct device *dev,
>> dma_addr_t addr, size_t size,
>> {
>> dma_addr_t end = addr + size - 1;
>> - if (!dev->dma_mask)
>> -retu
On 2020-09-15 10:26 a.m., Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 10:11:51AM -0400, Thomas Tai wrote:
On 2020-09-15 10:07 a.m., Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 08:03:14AM -0600, Thomas Tai wrote:
When booting the kernel v5.9-rc4 on a VM, the kernel would panic whe
On Mon, Sep 14, 2020 at 04:33:10PM -0600, Alex Williamson wrote:
> Can you explain that further, or spit-ball what you think this /dev/sva
> interface looks like and how a user might interact between vfio and
> this new interface?
When you open it you get some container, inside the container the
On Tue, Sep 15, 2020 at 10:11:51AM -0400, Thomas Tai wrote:
>
>
> On 2020-09-15 10:07 a.m., Christoph Hellwig wrote:
>> On Tue, Sep 15, 2020 at 08:03:14AM -0600, Thomas Tai wrote:
>>> When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
>>> printing a warning message in swiotlb_map
On 2020-09-15 10:07 a.m., Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 08:03:14AM -0600, Thomas Tai wrote:
When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
printing a warning message in swiotlb_map(). It is because dev->dma_mask
can potentially be a null pointer. Usin
On Tue, 2020-09-15 at 08:27 +0200, Christoph Hellwig wrote:
> On Mon, Sep 14, 2020 at 08:20:18AM -0700, James Bottomley wrote:
> > If you're going to change the macros from taking a device to taking
> > a hostdata structure then the descriptive argument name needs to
> > change ... it can't be dev
On Tue, Sep 15, 2020 at 04:07:19PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 15, 2020 at 08:03:14AM -0600, Thomas Tai wrote:
> > When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
> > printing a warning message in swiotlb_map(). It is because dev->dma_mask
> > can potentially
On Tue, Sep 15, 2020 at 08:03:14AM -0600, Thomas Tai wrote:
> When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
> printing a warning message in swiotlb_map(). It is because dev->dma_mask
> can potentially be a null pointer. Using the dma_get_mask() macro can
> avoid the NULL poi
When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
printing a warning message in swiotlb_map(). It is because dev->dma_mask
can potentially be a null pointer. Using the dma_get_mask() macro can
avoid the NULL pointer dereference.
Fixes: d323bb44e4d2 ("drm/virtio: Call the right
On 9/15/20 1:30 PM, Suravee Suthikulpanit wrote:
> On 9/15/20 6:25 PM, Maxim Levitsky wrote:
>> On Mon, 2020-09-14 at 21:48 +0700, Suravee Suthikulpanit wrote:
>>> Could you please try with the following patch instead?
>>>
>>> --- a/drivers/iommu/amd/iommu.c
>>> +++ b/drivers/iommu/amd/iommu.c
>>>
On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote:
> On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Reserved memory regions can be marked as "active" if hardware is
> > expected to access the regions during boot and before the operating
On 9/15/20 6:25 PM, Maxim Levitsky wrote:
On Mon, 2020-09-14 at 21:48 +0700, Suravee Suthikulpanit wrote:
Maxim,
On 9/13/2020 7:42 PM, Maxim Levitsky wrote:
Commit e52d58d54a32 ("iommu/amd: Use cmpxchg_double() when updating 128-bit
IRTE")
accidentally removed an assumption that modify_irt
On Mon, Sep 14, 2020 at 03:44:38PM -0700, Raj, Ashok wrote:
> Hi Jason,
>
> I thought we discussed this at LPC, but still seems to be going in
> circles :-(.
We discused mdev at LPC, not PASID.
PASID applies widely to many device and needs to be introduced with a
wide community agreement so all
On Mon, 2020-09-14 at 21:48 +0700, Suravee Suthikulpanit wrote:
> Maxim,
>
> On 9/13/2020 7:42 PM, Maxim Levitsky wrote:
> > Commit e52d58d54a32 ("iommu/amd: Use cmpxchg_double() when updating 128-bit
> > IRTE")
> > accidentally removed an assumption that modify_irte_ga always set the valid
> >
Hi Joe,
For MTD:
> drivers/mtd/nand/raw/nandsim.c| 2 +-
Reviewed-by: Miquel Raynal
Thanks,
Miquèl
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, 09 Sep 2020, Joe Perches wrote:
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 5ac0dbf0e03d..35ac539cc2b1 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@
On 15/09/2020 02:47, Lu Baolu wrote:
Hi Tvrtko,
On 9/14/20 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 12/09/2020 04:21, Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
77 matches
Mail list logo