On Wed, Jul 06, 2022 at 12:50:31PM +0100, Will Deacon wrote:
> On Thu, Jun 30, 2022 at 05:29:24PM +0800, yf.w...@mediatek.com wrote:
> > This patchset adds MediaTek TTBR up to 35bit support for single normal zone.
> >
> > Changes in v12:
> > - Update [PATCH 1/2]: remove GENMASK(31, 7)
> > -
On Wed, Jul 06, 2022 at 05:07:50PM +0530, Vasant Hegde wrote:
>As discussed in other thread, I have updated "From:" tag and
>resending patchset. No changes in the actual patch content.
>This patchset is based on top on "iommu/x86/amd" branch.
>Base commit : 0d10fe75911787
On Fri, Jul 01, 2022 at 02:20:08AM -0400, Bo Liu wrote:
> As iommu_device_sysfs_add() can fail, we should check the return value.
>
> Signed-off-by: Bo Liu
> ---
> drivers/iommu/amd/init.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Applied, thanks.
On Sun, Jul 03, 2022 at 07:44:50PM +0800, Feng Tang wrote:
> kmalloc will round up the request size to power of 2, and current
> iova_magazine's size is 1032 (1024+8) bytes, so each instance
> allocated will get 2048 bytes from kmalloc, causing around 1KB
> waste.
>
> Change IOVA_MAG_SIZE from
On Sat, Jun 25, 2022 at 09:34:29PM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> One fix is queued for v5.19. It aims to fix:
>
> - RID2PASID setup/teardown failures for pci alias devices
>
> Please consider it for the iommu/fix branch.
>
> Best regards,
> Lu Baolu
>
> Lu Baolu (1):
> iommu/vt-d:
On Thu, Jun 23, 2022 at 11:36:29AM +0200, Marek Szyprowski wrote:
> drivers/iommu/exynos-iommu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Tue, Jun 21, 2022 at 04:14:24PM +0100, Robin Murphy wrote:
> Robin Murphy (3):
> iommu: Use dev_iommu_ops() for probe_finalize
> iommu: Make .release_device optional
> iommu: Clean up release_device checks
Applied to core branch, thanks.
___
On Fri, Jun 24, 2022 at 02:12:28PM +0800, Baolu Lu wrote:
> It makes sense as far as I am aware. By putting IOMMUs in pass-through
> mode, there will be no run-time costs and things could be simplified a
> lot.
>
> Besides the refactoring efforts, we still need this quick fix so that
> the fix
From: Joerg Roedel
The IOMMU mailing list has moved to io...@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Signed-off-by: Joerg Roedel
---
MAINTAINERS | 11 ---
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On Tue, Jun 28, 2022 at 02:35:51PM +0530, Vasant Hegde wrote:
> Sorry. I didn't get last statement ("device identity maps DMA requests
> without PASID").
> Can you please elaborate?
When using v1 page-tables, each device supporting ATS/PRI/PASID needs to
be direct-mapped, because the v1
On Tue, Jun 28, 2022 at 01:23:52PM +0530, Vasant Hegde wrote:
> I think it will complicate the parsing logic. We do have `amd_iommu=off`
> option.
> How are we going to handle `amd_iommu=off,[pgtable_v1/v2]` ?
In that case everything except 'off' will be ignored. The driver might
set its
.
Joerg Roedel (1):
MAINTAINERS: Add new IOMMU development mailing list
Yoshihiro Shimoda (1):
iommu/ipmmu-vmsa: Fix compatible for rcar-gen4
MAINTAINERS| 11 +++
drivers/iommu/ipmmu-vmsa.c | 2 +-
2
On Thu, Jun 23, 2022 at 12:41:00PM +0100, Robin Murphy wrote:
> On 2022-06-23 12:33, Joerg Roedel wrote:
> > On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
> > > Thanks for your bravery!
> >
> > It already starts, with that patch I am getting:
>
On Fri, Jun 24, 2022 at 05:59:39AM -0700, Christoph Hellwig wrote:
> Shouldn't this also remove the old list given it has only a few days
> to live?
No, the new list is not yet archived on lore. There will be a hard
switch of the archive on July 5th, and after that the old list can be
removed.
From: Joerg Roedel
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear
On Thu, Jun 23, 2022 at 11:30:06PM -0700, Christoph Hellwig wrote:
> iommu@lists.linux-foundation.org is also listed for various other
> MAINTAINERS entries. Can you please send a list to update all of them
> to Linus ASAP, including for 5.19 and -stable?
Right, will do, thanks for the heads-up.
Hi Baolu,
On Wed, May 25, 2022 at 09:40:26AM +0800, Baolu Lu wrote:
> How do you like it? If you agree, I can queue it in my next pull request
> for fixes.
Would it help to tie DMAR and IOMMU components together, so that
selecting DMAR for IRQ remapping also selects IOMMU? The IOMMU can be in
PT
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
> Thanks for your bravery!
It already starts, with that patch I am getting:
xhci_hcd :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x000f address=0xff00ffefe000 flags=0x]
In my kernel log. The device is an
On Thu, Jun 23, 2022 at 10:42:52AM +0100, Robin Murphy wrote:
> TBH it's probably time to retire iommu_ops->pgsize_bitmap anyway. At the
> very least it would be logical to move it to iommu_domain_ops now, but maybe
> we could skip ahead and just rely on drivers initialising
>
On Wed, Jun 22, 2022 at 12:11:31PM -0500, Suravee Suthikulpanit wrote:
> bool amd_iommu_v2_supported(void)
> {
> - return amd_iommu_v2_present;
> + /*
> + * Since DTE[Mode]=0 is prohibited on SNP-enabled system
> + * (i.e. EFR[SNPSup]=1), IOMMUv2 page table cannot be used
On Wed, Jun 22, 2022 at 12:11:25PM -0500, Suravee Suthikulpanit wrote:
> #ifdef CONFIG_IRQ_REMAP
> +/*
> + * Iterate through all the IOMMUs to verify if the specified
> + * EFR bitmask of IOMMU feature are set.
> + * Warn and return false if found inconsistency.
> + */
> static bool
On Fri, Jun 03, 2022 at 04:51:00PM +0530, Vasant Hegde wrote:
> - Part 1 (patch 1-4 and 6)
> Refactor the current IOMMU page table code to adopt the generic IO page
> table framework, and add AMD IOMMU Guest (v2) page table management code.
>
> - Part 2 (patch 5)
> Add support for the AMD
On Fri, Jun 03, 2022 at 04:51:07PM +0530, Vasant Hegde wrote:
> + amd_iommu_pgtable= [HW,X86-64]
> + Specifies one of the following AMD IOMMU page table to
> + be used for DMA remapping for DMA-API:
> + v1 - Use v1 page table
On Fri, Jun 03, 2022 at 04:51:04PM +0530, Vasant Hegde wrote:
> +/* Allocate page table */
> +static u64 *v2_alloc_pte(u64 *pgd, unsigned long iova,
> + unsigned long pg_size, bool *updated)
> +{
> + u64 *pte, *page;
> + int level, end_level;
> +
> +
On Fri, Jun 03, 2022 at 04:51:03PM +0530, Vasant Hegde wrote:
> Fix below sparse warning:
> CHECK drivers/iommu/amd/iommu.c
> drivers/iommu/amd/iommu.c:73:24: warning: symbol 'amd_iommu_ops' was not
> declared. Should it be static?
>
> Also we are going to introduce v2 page table which has
Hi Vasant,
On Wed, May 11, 2022 at 12:51:06PM +0530, Vasant Hegde wrote:
> .../admin-guide/kernel-parameters.txt | 34 +-
> drivers/iommu/amd/amd_iommu.h | 13 +-
> drivers/iommu/amd/amd_iommu_types.h | 133 +++-
> drivers/iommu/amd/init.c
t of cmpxchg). Also, remove racy explicit assignment to pteval
> when cmpxchg fails, this is what try_cmpxchg does implicitly from
> *pte in an atomic way.
>
> Signed-off-by: Uros Bizjak
> Cc: Joerg Roedel
> Cc: Suravee Suthikulpanit
> Cc: Will Deacon
> ---
> drivers
Hi Matthias,
On Wed, Jun 22, 2022 at 04:12:47PM +0200, Matthias Brugger wrote:
> I wanted to check if you took also 3 and 4, as these should go through my
> tree. Unfortunately you haven't pushed your tree (yet). In case you took the
> whole series, can you please drop the dts patches. I'll apply
On Fri, Jun 17, 2022 at 10:01:07AM +0900, Yoshihiro Shimoda wrote:
> Fix compatible string for R-Car Gen4.
>
> Fixes: ae684caf465b ("iommu/ipmmu-vmsa: Add support for R-Car Gen4")
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/iommu/ipmmu-vmsa.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote:
> AngeloGioacchino Del Regno (5):
> dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle
> iommu/mediatek: Lookup phandle to retrieve syscon to infracfg
> arm64: dts: mediatek: mt8173: Add mediatek,infracfg
On Thu, Jun 16, 2022 at 10:05:55PM -0400, Bo Liu wrote:
> Use ida_alloc_xxx()/ida_free() instead of
> ida_simple_get()/ida_simple_remove().
> The latter is deprecated and more verbose.
>
> Signed-off-by: Bo Liu
> ---
> drivers/iommu/iommu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3
On Wed, Jun 22, 2022 at 02:27:57PM +0100, Robin Murphy wrote:
> Apologies, I did spot this before, I've just been tied up with other things
> and dropping everything non-critical on the floor, so didn't get round to
> replying before it slipped my mind again.
>
> In summary, I hate it, but mostly
On Thu, Jun 09, 2022 at 04:12:10PM +0100, Robin Murphy wrote:
> firmware bindings by now. Let's be brave and default it to off in the
I don't have an overall good feeling about this, but as you said, let's
be brave. This is applied now to the core branch.
If it causes too much trouble we can
On Wed, Jun 08, 2022 at 02:16:55AM +, Ke Liu wrote:
> Use ida_alloc()/ida_free() instead of deprecated
> ida_simple_get()/ida_simple_remove().
>
> Signed-off-by: Ke Liu
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Michael S. Tsirkin
> ---
> v2 subject change to iommu
> ---
>
Please re-send with
Robin Murphy
in Cc.
On Mon, May 30, 2022 at 08:07:45PM +0800, yf.w...@mediatek.com wrote:
> From: Yunfei Wang
>
> When many devices share the same iova domain, iommu_dma_init_domain()
> may be called at the same time. The checking of iovad->start_pfn will
> all
From: Joerg Roedel
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches.
Signed-off-by: Joerg Roedel
On Fri, May 27, 2022 at 07:03:07AM +, keliu wrote:
> Use ida_alloc()/ida_free() instead of deprecated
> ida_simple_get()/ida_simple_remove() .
>
> Signed-off-by: keliu
Please change the subject to: "iommu: Directly use ida_alloc()/free()"
to match the IOMMU tree conventions. Also include
On Thu, May 26, 2022 at 10:29:09AM +0700, Suravee Suthikulpanit wrote:
> Actually, I am referring to when user uses the IOMMU v2 table for shared
> virtual address
> in current iommu_v2 driver (e.g. amd_iommu_init_device(),
> amd_iommu_bind_pasid).
>From what I can see this is not handled yet
vfio: Require that devices support DMA cache coherence
Jason Gunthorpe via iommu (1):
iommu: iommu_group_claim_dma_owner() must always assign a domain
Jean-Philippe Brucker (1):
iommu/arm-smmu-v3-sva: Fix mm use-after-free
Joerg Roedel (4):
Merge tag 'arm-smmu-updates
From: Joerg Roedel
On some systems it can take a long time for the hardware to enable the
GA log of the AMD IOMMU. The current wait time is only 0.1ms, but
testing showed that it can take up to 14ms for the GA log to enter
running state after it has been enabled.
Sometimes the long delay
Hi Vasant,
On Fri, May 20, 2022 at 03:25:38PM +0530, Vasant Hegde wrote:
> Ping. Did you get a chance to look into this series?
Sorry, too late for this round. The changes are pretty invasive and
merging them at -rc7 stage would not give them enough testing before
being merged. Please send me a
On Fri, May 20, 2022 at 09:54:51AM +0100, Robin Murphy wrote:
> The .def_domain type op already allows drivers to do exactly this sort of
> override. You could also conditionally reject IOMMU_DOMAIN_PASSTHROUGH in
> .domain_alloc for good measure, provided that (for now at least*) SNP is a
>
On Wed, May 18, 2022 at 03:13:53PM +0200, Christoph Hellwig wrote:
> On Tue, May 17, 2022 at 01:02:00PM +0100, Robin Murphy wrote:
> >> So how to inform the SCSI driver of this caching limit then so that it may
> >> limit the SGL length?
> >
> > Driver-specific mechanism; block-layer-specific
On Mon, May 16, 2022 at 09:57:56AM +0800, Lu Baolu wrote:
> const struct iommu_domain_ops *default_domain_ops;
> + const struct iommu_domain_ops *blocking_domain_ops;
I don't understand why extra domain-ops are needed for this. I think it
would be more straight-forward to implement
Hi Suravee,
On Mon, May 16, 2022 at 07:27:51PM +0700, Suravee Suthikulpanit wrote:
> Due to the new restriction (please see the IOMMU spec Rev 3.06-PUB - Apr 2021
> https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf) where the use of
> DTE[Mode]=0 is not supported on systems that are
On Thu, May 19, 2022 at 02:29:29PM -0400, Matthew Rosato wrote:
> Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
> always assign a domain") s390-iommu will get called to allocate multiple
> unmanaged iommu domains for a vfio-pci device -- however the current
> s390-iommu
On Tue, May 17, 2022 at 02:26:56PM -0600, Alex Williamson wrote:
> I'd be in favor of applying this, but it seems Robin and Eric are
> looking for a stay of execution and I'd also be looking for an ack from
> Joerg. Thanks,
This is mainly an ARM-SMMU thing, so I defer my ack to Will and Robin.
On Wed, May 18, 2022 at 04:14:46PM -0300, Jason Gunthorpe wrote:
> Fixes: 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must always assign
> a domain")
> Reported-by: Eric Farman
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/vfio/vfio.c | 15 ++-
> 1 file changed, 10
Hi Alex,
On Wed, May 04, 2022 at 10:29:56AM -0600, Alex Williamson wrote:
> Done, and thanks for the heads-up. Please try to cc me when the
> vfio-notifier-fix branch is merged back into your next branch. Thanks,
This has happened now, the vfio-notifier-fix branch got the fix and is
merged
On Tue, May 10, 2022 at 05:01:06PM +0100, Will Deacon wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> tags/arm-smmu-updates
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Tue, May 10, 2022 at 10:33:59AM +0800, Lu Baolu wrote:
> This includes patches queued for v5.19. It includes:
>
> - Domain force snooping improvement.
> - Cleanups, no intentional functional changes.
>
> Please consider them for v5.19.
>
> [This series cannot be directly applied to vt-d
On Mon, May 09, 2022 at 11:16:08AM +0100, Robin Murphy wrote:
> drivers/iommu/dma-iommu.c | 13 -
> drivers/pci/of.c | 8 +---
> 2 files changed, 13 insertions(+), 8 deletions(-)
Applied, thanks.
___
iommu mailing list
On Mon, May 09, 2022 at 02:48:15AM -0500, Suravee Suthikulpanit wrote:
> On AMD system with SNP enabled, IOMMU hardware checks the host translation
> valid (TV) and guest translation valid (GV) bits in the device
> table entry (DTE) before accessing the corresponded page tables.
>
> However,
On Sat, May 07, 2022 at 04:52:03PM +0800, yf.w...@mediatek.com wrote:
> drivers/iommu/dma-iommu.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, May 05, 2022 at 09:27:30PM +0800, Miles Chen wrote:
> drivers/iommu/mtk_iommu.c| 6 ++
> drivers/iommu/mtk_iommu_v1.c | 7 +++
> 2 files changed, 13 insertions(+)
Applied, thanks.
___
iommu mailing list
On Mon, May 09, 2022 at 01:19:19PM -0300, Jason Gunthorpe wrote:
> drivers/iommu/iommu.c | 127 ++
> 1 file changed, 91 insertions(+), 36 deletions(-)
Applied, thanks. Will back-merge the branch into next now.
Ashish Mhetre (1):
iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu
David Stevens (1):
iommu/vt-d: Calculate mask for non-aligned flushes
Hector Martin (1):
iommu/dart: Add missing module owner to ops structure
Joerg Roedel
On Wed, May 04, 2022 at 01:39:58PM +0100, Robin Murphy wrote:
> Groups created by VFIO backends outside the core IOMMU API should never
> be passed directly into the API itself, however they still expose their
> standard sysfs attributes, so we can still stumble across them that way.
> Take care
On Wed, May 04, 2022 at 08:51:35AM -0300, Jason Gunthorpe wrote:
> Nicolin and Eric have been testing with this series on ARM for a long
> time now, it is not like it is completely broken.
Yeah, I am also optimistic this can be fixed soon. But the rule is that
the next branch should only contain
Hi Robin,
On Wed, May 04, 2022 at 12:14:07PM +0100, Robin Murphy wrote:
> Oof, this can probably be hit with vfio-noiommu too, and by the look of
> things, `echo auto > /sys/kernel/iommu_groups/0/type` would likely blow
> up as well. Does the patch below work for you?
Thanks for the quick patch!
to point to the found one,
> and remove the unneeded check for 'iommu->dev->of_node != spec->np'
> outside the loop.
>
> Cc: sta...@vger.kernel.org
> Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings")
> Signed-off-by: Xiaomeng Tong
>
On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> Reverting this series fixed an user-after-free while doing SR-IOV.
>
> BUG: KASAN: use-after-free in __lock_acquire
Hrm, okay. I am going exclude this series from my next branch for now
until this has been sorted out.
Alex, I suggest
On Tue, May 03, 2022 at 03:13:51PM +0800, Yong Wu wrote:
> Yong Wu (36):
> dt-bindings: mediatek: mt8195: Add binding for MM IOMMU
> dt-bindings: mediatek: mt8195: Add binding for infra IOMMU
> dt-bindings: mediatek: mt8186: Add binding for MM iommu
> iommu/mediatek: Fix 2 HW sharing
ommu/renesas,ipmmu-vmsa.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Joerg Roedel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, May 02, 2022 at 06:22:38PM +0900, Hector Martin wrote:
> This is required to make loading this as a module work.
>
> Signed-off-by: Hector Martin
> ---
> drivers/iommu/apple-dart.c | 1 +
> 1 file changed, 1 insertion(+)
Applied for v5.18, thanks.
Hi Vasant,
On Fri, Apr 29, 2022 at 08:15:49PM +0530, Vasant Hegde wrote:
> We still need to parse IVHD to find max devices supported by each PCI segment
> (same as the way its doing it today). Hence we need all these variables.
>From what I have seen since a few years the IVRS tables enumerate
On Thu, Apr 07, 2022 at 04:32:28PM +0800, Yong Wu wrote:
> Yong Wu (2):
> dt-bindings: mediatek: mt8186: Add binding for MM iommu
> iommu/mediatek: Add mt8186 iommu support
>
> .../bindings/iommu/mediatek,iommu.yaml| 4 +
> drivers/iommu/mtk_iommu.c | 17 ++
>
On Thu, Apr 28, 2022 at 08:54:11AM -0300, Jason Gunthorpe wrote:
> Can we get this on a topic branch so Alex can pull it? There are
> conflicts with other VFIO patches
Right, we already discussed this. Moved the patches to a separate topic
branch. It will appear as 'vfio-notifier-fix' once I
On Thu, Apr 28, 2022 at 04:52:39PM +0800, xkernel.w...@foxmail.com wrote:
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Besides, to
Hi Vasant, Hi Suravee,
On Mon, Apr 25, 2022 at 05:03:38PM +0530, Vasant Hegde wrote:
> Newer AMD systems can support multiple PCI segments, where each segment
> contains one or more IOMMU instances. However, an IOMMU instance can only
> support a single PCI segment.
Thanks for doing this, making
On Mon, Apr 25, 2022 at 05:04:15PM +0530, Vasant Hegde wrote:
> + seg_id = (iommu_fault->sbdf >> 16) & 0x;
> + devid = iommu_fault->sbdf & 0x;
This deserves some macros for readability.
___
iommu mailing list
On Mon, Apr 25, 2022 at 05:04:05PM +0530, Vasant Hegde wrote:
> From: Suravee Suthikulpanit
>
> Replace global amd_iommu_dev_table with per PCI segment device table.
> Also remove "dev_table_size".
>
> Co-developed-by: Vasant Hegde
> Signed-off-by: Vasant Hegde
> Signed-off-by: Suravee
On Mon, Apr 25, 2022 at 05:03:49PM +0530, Vasant Hegde wrote:
> + /* Size of the device table */
> + u32 dev_table_size;
Same here and with all other size indicators. If they are always going
to have their maximum value anyways, we can drop them.
On Mon, Apr 25, 2022 at 05:03:48PM +0530, Vasant Hegde wrote:
> + /* Largest PCI device id we expect translation requests for */
> + u16 last_bdf;
How does the IVRS table look like on these systems? Do they still
enumerate the whole PCI Bus/Dev/Fn space? If so I am fine with getting
rid
On Mon, Apr 25, 2022 at 05:03:39PM +0530, Vasant Hegde wrote:
Subject: iommu/amd: Update struct iommu_dev_data defination
^^ Typo
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Vasant,
On Mon, Apr 25, 2022 at 05:03:40PM +0530, Vasant Hegde wrote:
> +/*
> + * This structure contains information about one PCI segment in the system.
> + */
> +struct amd_iommu_pci_seg {
> + struct list_head list;
The purpose of this list_head needs a comment.
> +
> + /* PCI
On Mon, Apr 25, 2022 at 05:08:26PM +0800, Yang Yingliang wrote:
> It will cause null-ptr-deref in resource_size(), if platform_get_resource()
> returns NULL, move calling resource_size() after devm_ioremap_resource() that
> will check 'res' to avoid null-ptr-deref.
> And use
On Fri, Apr 22, 2022 at 02:21:03PM -0500, Rob Herring wrote:
> There's no need to show consumer side in provider examples. The ones
> used here are undocumented or undocumented in schemas which results in
> warnings.
>
> Signed-off-by: Rob Herring
Applied, thanks Rob.
On Fri, Apr 22, 2022 at 12:22:34PM +0100, Will Deacon wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> tags/arm-smmu-fixes
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote:
> Lu Baolu (10):
> iommu: Add DMA ownership management interfaces
> driver core: Add dma_cleanup callback in bus_type
> amba: Stop sharing platform_dma_configure()
> bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
On Tue, Apr 12, 2022 at 06:12:11PM +0200, Sven Peter wrote:
> It's the same people anyway.
>
> Signed-off-by: Sven Peter
> ---
> MAINTAINERS | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
Applied, thanks.
___
iommu mailing list
On Sat, Apr 23, 2022 at 04:23:29PM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> One fix is queued for v5.18. It aims to fix:
>
> - Handle PCI stop marker messages in IOMMU driver to meet the
>requirement of I/O page fault handling framework.
>
> Please consider it for the iommu/fix branch.
>
>
On Sun, Apr 10, 2022 at 09:35:32AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> One fix is queued for v5.18. It aims to fix:
>
> - Calculate a feasible mask for non-aligned page-selective
>IOTLB invalidation.
>
> Please consider it for the iommu/fix branch.
>
> Best regards,
> Lu Baolu
>
>
On Mon, Apr 11, 2022 at 12:16:04PM -0300, Jason Gunthorpe wrote:
> Jason Gunthorpe (4):
> iommu: Introduce the domain op enforce_cache_coherency()
> vfio: Move the Intel no-snoop control off of IOMMU_CACHE
> iommu: Redefine IOMMU_CAP_CACHE_COHERENCY as the cap flag for
> IOMMU_CACHE
>
On Thu, Apr 07, 2022 at 08:26:04AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this removes a bit of dead code and methods from the iommu code and the
> cleans up the arm-smmu-v3 driver a little bit based on that.
>
> Diffstat:
> drivers/iommu/amd/iommu.c |1
>
On Mon, Apr 04, 2022 at 03:47:21PM -0500, Mario Limonciello wrote:
> Mario Limonciello (2):
> iommu/amd: Enable swiotlb in all cases
> dma-iommu: Check that swiotlb is active before trying to use it
>
> drivers/iommu/amd/iommu.c | 7 ---
> drivers/iommu/dma-iommu.c | 5 +
> 2 files
On Sat, Apr 02, 2022 at 12:08:38PM +0200, Christophe Leroy wrote:
> powerpc's asm/prom.h brings some headers that it doesn't
> need itself.
>
> In order to clean it up, first add missing headers in
> users of asm/prom.h
>
> Signed-off-by: Christophe Leroy
> ---
> drivers/iommu/fsl_pamu.c
On Tue, Mar 29, 2022 at 05:53:22AM +, cgel@gmail.com wrote:
> From: Lv Ruyi
>
> kmem_cache_zalloc is a memory allocation function which can return NULL
> when some internal memory errors happen. Add null pointer check to avoid
> dereferencing null pointer.
>
> Reported-by: Zeal Robot
>
st | 2 +-
> Documentation/x86/intel-iommu.rst | 115
> Documentation/x86/iommu.rst | 143 ++
> 3 files changed, 144 insertions(+), 116 deletions(-)
> delete mode 100644 Documentation/x86/intel-iommu.rst
> create mode
On Sun, Mar 27, 2022 at 01:35:58PM +0800, Xiaomeng Tong wrote:
> @@ -617,23 +617,17 @@ static int qcom_iommu_of_xlate(struct device *dev,
> {
> struct msm_iommu_dev *iommu;
> unsigned long flags;
> - int ret = 0;
>
> spin_lock_irqsave(_iommu_lock, flags);
>
On Fri, Mar 25, 2022 at 10:08:01AM +0800, xkernel.w...@foxmail.com wrote:
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Signed-off-by:
On Mon, Mar 14, 2022 at 12:32:26PM +0530, Vasant Hegde wrote:
> smatch static checker warning:
> drivers/iommu/amd/init.c:1989 amd_iommu_init_pci()
> warn: duplicate check 'ret' (previous on line 1978)
>
> Reported-by: Dan Carpenter
> Fixes: 06687a03805e ("iommu/amd: Improve error handling
On Sun, Mar 13, 2022 at 09:43:21PM -0500, Suravee Suthikulpanit wrote:
> Smatch static checker warns:
> drivers/iommu/amd/iommu_v2.c:133 free_device_state()
> warn: sleeping in atomic context
>
> Fixes by storing the list of struct device_state in a temporary
> list, and then free the
On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> You might consider using a linear tree instead of the topic branches,
> topics are tricky and I'm not sure it helps a small subsystem so much.
> Conflicts between topics are a PITA for everyone, and it makes
> handling conflicts
On Fri, Apr 08, 2022 at 09:23:52AM -0300, Jason Gunthorpe wrote:
> Why rc3? It has been 4 weeks now with no futher comments.
Because I start applying new code to branches based on -rc3. In the past
I used different -rc's for the topic branches (usually the latest -rc
available when I started
Hi Linus,
The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fix-v5.18-rc1
for you to fetch changes up to
On Thu, Apr 07, 2022 at 08:39:05AM +0300, Tony Lindgren wrote:
> Can you guys please get this fix into the -rc series? Or ack it so
> I can pick it up into my fixes branch?
Sorry for the delay, Covid catched me so I was away from email for
almost 2 week. This patch is picked-up now and I will
On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote:
> Joerg, are we good for the coming v5.18 merge window now? There are
> several things backed up behind this series.
I usually don't apply bigger changes like this after -rc7, so it didn't
make it. Please re-send after -rc3 is out
ion
iommu/arm-smmu-v3: Simplify memory allocation
David Heidelberg (1):
iommu/msm: Simplify with dev_err_probe()
Jiasheng Jiang (1):
iommu/ipmmu-vmsa: Check for error num after setting mask
Joerg Roedel (3):
Merge branch 'core' into x86/vt-d
Merge tag 'arm-smmu-updates' of
On Tue, Mar 08, 2022 at 10:18:10AM +, Will Deacon wrote:
> Hi Joerg,
>
> Please pull this handful of Arm SMMU updates for 5.18. Summary in the tag.
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
1 - 100 of 3391 matches
Mail list logo
