Re: [PATCH v3 6/8] genirq: Add and use an irq_data_update_affinity helper

On Sun, 03 Jul 2022 16:22:03 +0100, Oleksandr wrote: > > > On 01.07.22 23:00, Samuel Holland wrote: > > > Hello Samuel > > > Some architectures and irqchip drivers modify the cpumask returned by > > irq_data_get_affinity_mask, usually by copying in to it. This is > > problematic for

Re: [PATCH v3 1/8] irqchip/mips-gic: Only register IPI domain when SMP is enabled

On Tue, 05 Jul 2022 14:52:43 +0100, Serge Semin wrote: > > Hi Samuel > > On Fri, Jul 01, 2022 at 03:00:49PM -0500, Samuel Holland wrote: > > The MIPS GIC irqchip driver may be selected in a uniprocessor > > configuration, but it unconditionally registers an IPI domain. > > > > Limit the part

Re: fully convert arm to use dma-direct

t he can test this on. Marc? > I have one too, just not much in my office because of parental leave. Finally found some time to hook the machine up and throw a new kernel at it. Booted at its usual glacial speed, so FWIW: Tested-by: Marc Zyngier

Re: fully convert arm to use dma-direct

On 2022-04-22 22:17, Linus Walleij wrote: On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote: arm is the last platform not using the dma-direct code for directly mapped DMA. With the dmaboune removal from Arnd we can easily switch arm to always use dma-direct now (it already does for

Re: [PATCH] iommu/dma: Explicitly sort PCI DMA windows

On Tue, 22 Mar 2022 17:27:36 +, Robin Murphy wrote: > > Originally, creating the dma_ranges resource list in pre-sorted fashion > was the simplest and most efficient way to enforce the order required by > iova_reserve_pci_windows(). However since then at least one PCI host > driver is now

Re: [patch 29/37] PCI/MSI: Use __msi_get_virq() in pci_get_vector()

On Sat, 27 Nov 2021 01:22:03 +, Thomas Gleixner wrote: > > Use __msi_get_vector() and handle the return values to be compatible. > > No functional change intended. You wish ;-). [ 15.779540] pcieport 0001:00:01.0: AER: request AER IRQ -22 failed Notice how amusing the IRQ number is? >

Re: [PATCH v3 4/6] iommu: Move IOMMU pagesize check to attach_device

On Fri, 22 Oct 2021 03:52:38 +0100, Lu Baolu wrote: > > On 10/21/21 4:10 PM, Marc Zyngier wrote: > > On Thu, 21 Oct 2021 03:22:30 +0100, > > Lu Baolu wrote: > >> > >> On 10/20/21 10:22 PM, Marc Zyngier wrote: > >>> On Wed, 2

Re: [PATCH v3 4/6] iommu: Move IOMMU pagesize check to attach_device

On Thu, 21 Oct 2021 03:22:30 +0100, Lu Baolu wrote: > > On 10/20/21 10:22 PM, Marc Zyngier wrote: > > On Wed, 20 Oct 2021 06:21:44 +0100, > > Lu Baolu wrote: > >> > >> On 2021/10/20 0:37, Sven Peter via iommu wrote: > >>> + /* > >>&

Re: [PATCH v3 4/6] iommu: Move IOMMU pagesize check to attach_device

On Wed, 20 Oct 2021 06:21:44 +0100, Lu Baolu wrote: > > On 2021/10/20 0:37, Sven Peter via iommu wrote: > > The iova allocator is capable of handling any granularity which is a power > > of two. Remove the much stronger condition that the granularity must be > > smaller or equal to the CPU page

Re: [PATCH] iommu/dart: Clear sid2group entry when a group is freed

64bit pref] > pci :03:00.0: BAR 6: assigned [mem 0x6c010-0x6c01007ff pref] > tg3 :03:00.0: Failed to add to iommu group 1: -2 > [...] > > Fixes: 46d1fb072e76b161 ("iommu/dart: Add DART iommu driver") > Reported-by: Marc Zyngier > Signed-off-by: Sven Peter

Re: [PATCH] iommu/dart: Remove iommu_flush_ops

roup_release+0x68/0xac >kobject_cleanup+0x4c/0x1fc >kobject_cleanup+0x14c/0x1fc >kobject_put+0x64/0x84 >iommu_group_remove_device+0x110/0x180 >iommu_release_device+0x50/0xa0 > [...] > > Fixes: 46d1fb072e76b161 ("iommu/dart: Add DART iommu driver")

Re: [PATCH -next v2] iommu/arm-smmu-v3: Add suspend and resume support

On Tue, 27 Jul 2021 13:14:08 +0100, Bixuan Cui wrote: > > Add suspend and resume support for arm-smmu-v3 by low-power mode. > > When the smmu is suspended, it is powered off and the registers are > cleared. So saves the msi_msg context during msi interrupt initialization > of smmu. When resume

Re: [bug report] iommu_dma_unmap_sg() is very slow then running IO from remote numa node

On 2021-07-22 12:12, John Garry wrote: Hi John, [...] Your kernel log should show: [0.00] GICv3: Pseudo-NMIs enabled using forced ICC_PMR_EL1 synchronisation Unrelated, but you seem to be running with ICC_CTLR_EL3.PMHE set, which makes the overhead of pseudo-NMIs much higher

Re: [PATCH -next] iommu/arm-smmu-v3: Add suspend and resume support

On Wed, 21 Jul 2021 14:59:47 +0100, Robin Murphy wrote: > > On 2021-07-21 14:12, Marc Zyngier wrote: > > On Wed, 21 Jul 2021 12:42:14 +0100, > > Robin Murphy wrote: > >> > >> [ +Marc for MSI bits ] > >> > >> On 2021-07-21 02:33, Bixuan C

Re: [PATCH -next] iommu/arm-smmu-v3: Add suspend and resume support

On Wed, 21 Jul 2021 12:42:14 +0100, Robin Murphy wrote: > > [ +Marc for MSI bits ] > > On 2021-07-21 02:33, Bixuan Cui wrote: > > Add suspend and resume support for arm-smmu-v3 by low-power mode. > > > > When the smmu is suspended, it is powered off and the registers are > > cleared. So saves

Re: [PATCH] iommu/arm-smmu-v3: Add default domain quirk for Arm Fast Models

On Tue, 29 Jun 2021 18:34:40 +0100, Will Deacon wrote: > > On Fri, Jun 18, 2021 at 05:24:49PM +0100, Robin Murphy wrote: > > Arm Fast Models are still implementing legacy virtio-pci devices behind > > the SMMU, which continue to be problematic as "real hardware" devices > > (from the point of

Re: [PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part)

On Fri, 23 Apr 2021 18:58:23 +0100, Krishna Reddy wrote: > > >> Did that patch cause any issue, or is it just not needed on your system? > >> It fixes an hypothetical problem with the way ATS is implemented. > >> Maybe I actually observed it on an old software model, I don't > >> remember.

Re: [Patch V2 13/13] genirq/msi: Provide helpers to return Linux IRQ/dev_msi hw IRQ number

On Fri, 26 Mar 2021 01:02:43 +, "Dey, Megha" wrote: > > Hi Marc, > > On 3/25/2021 10:53 AM, Marc Zyngier wrote: > > On Fri, 26 Feb 2021 20:11:17 +, > > Megha Dey wrote: > >> From: Dave Jiang > >> > >> Add new

Re: [Patch V2 08/13] genirq: Set auxiliary data for an interrupt

On Thu, 25 Mar 2021 18:59:48 +, Thomas Gleixner wrote: > > On Thu, Mar 25 2021 at 17:23, Marc Zyngier wrote: > >> +{ > >> + struct irq_desc *desc; > >> + struct irq_data *data; > >> + unsigned long flags; > >> + int res = -ENODEV;

Re: [Patch V2 07/13] irqdomain/msi: Provide msi_alloc/free_store() callbacks

On Thu, 25 Mar 2021 18:44:48 +, Thomas Gleixner wrote: > > On Thu, Mar 25 2021 at 17:08, Marc Zyngier wrote: > > Megha Dey wrote: > >> @@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain > >> *domain, struct device *dev, > >>

Re: [Patch V2 13/13] genirq/msi: Provide helpers to return Linux IRQ/dev_msi hw IRQ number

On Fri, 26 Feb 2021 20:11:17 +, Megha Dey wrote: > > From: Dave Jiang > > Add new helpers to get the Linux IRQ number and device specific index > for given device-relative vector so that the drivers don't need to > allocate their own arrays to keep track of the vectors and hwirq for > the

Re: [Patch V2 12/13] irqchip: Add IMS (Interrupt Message Store) driver

On Fri, 26 Feb 2021 20:11:16 +, Megha Dey wrote: > > Generic IMS(Interrupt Message Store) irq chips and irq domain > implementations for IMS based devices which store the interrupt messages > in an array in device memory. > > Allocation and freeing of interrupts happens via the generic >

Re: [Patch V2 08/13] genirq: Set auxiliary data for an interrupt

On Fri, 26 Feb 2021 20:11:12 +, Megha Dey wrote: > > Introduce a new function pointer in the irq_chip structure(irq_set_auxdata) > which is responsible for updating data which is stored in a shared register > or data storage. For example, the idxd driver uses the auxiliary data API > to

Re: [Patch V2 07/13] irqdomain/msi: Provide msi_alloc/free_store() callbacks

On Fri, 26 Feb 2021 20:11:11 +, Megha Dey wrote: > > From: Thomas Gleixner > > For devices which don't have a standard storage for MSI messages like the > upcoming IMS (Interrupt Message Store) it's required to allocate storage > space before allocating interrupts and after freeing them. >

Re: [RFC PATCH 3/5] KVM: ARM64: Add support for pinned VMIDs

Hi Shameer, [+Will] On Mon, 22 Feb 2021 15:53:36 +, Shameer Kolothum wrote: > > On an ARM64 system with a SMMUv3 implementation that fully supports > Broadcast TLB Maintenance(BTM) feature, the CPU TLB invalidate > instructions are received by SMMU. This is very useful when the > SMMU

Re: iommu/vt-d: Cure VF irqdomain hickup

On 2020-11-12 21:34, Thomas Gleixner wrote: On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote: The recent changes to store the MSI irqdomain pointer in struct device missed that Intel DMAR does not register virtual function devices. Due to that a VF device gets the plain PCI-MSI domain

Re: [PATCH v3 22/35] genirq/irqdomain: Implement get_name() method on irqchip fwnodes

t_name = irqchip_fwnode_get_name, > +}; > EXPORT_SYMBOL_GPL(irqchip_fwnode_ops); > > /** Acked-by: Marc Zyngier -- Without deviation from the norm, progress is not possible. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

On 2020-08-28 13:54, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote: > So the arch_setup_msi_irq/etc is not really an arch hook, but some > infrastructure to support those 4 PCI root port drivers. I happen to have a *really old* patch addressing Te

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

Hi Jason, On 2020-08-28 13:19, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote: On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote: [...] > And I can't figure out what's special about tegra, rcar, and xilinx > that makes them need it as

Re: [patch V2 43/46] genirq/msi: Provide and use msi_domain_set_default_info_flags()

On 2020-08-26 12:17, Thomas Gleixner wrote: MSI interrupts have some common flags which should be set not only for PCI/MSI interrupts. Move the PCI/MSI flag setting into a common function so it can be reused. Signed-off-by: Thomas Gleixner --- V2: New patch --- drivers/pci/msi.c |7

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

On Wed, 26 Aug 2020 20:47:38 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:57 +0100, > > Thomas Gleixner wrote: > >> /** > >> - * msi_domain_free_irqs - Free interrupts from a MSI interr

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

On Wed, 26 Aug 2020 22:19:56 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:32 +0100, > > Thomas Gleixner wrote: > >> --- > >> V2: New patch. Note, that this might break other stuff which reli

Re: [patch V2 41/46] platform-msi: Provide default irq_chip:: Ack

= irq_chip_mask_parent; > if (!chip->irq_unmask) > chip->irq_unmask = irq_chip_unmask_parent; > + if (!chip->irq_ack) > + chip->irq_ack = irq_chip_ack_parent; > if (!chip->irq_eoi) > chip->irq_eoi = irq_chip_

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

nel to support the Xilinx AXI PCIe @@ -105,7 +106,6 @@ config PCIE_XILINX_CPM bool "Xilinx Versal CPM host bridge support" depends on ARCH_ZYNQMP || COMPILE_TEST select PCI_HOST_COMMON - select PCI_MSI_ARCH_FALLBACKS help

Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI

MSI domain. > + */ > + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI); > + One day, we'll be able to set the token at domain creation time. In the meantime, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possibl

Re: [patch V2 23/46] irqdomain/msi: Provide DOMAIN_BUS_VMD_MSI

ch(domain->bus_token) { > + case DOMAIN_BUS_PCI_MSI: > + case DOMAIN_BUS_VMD_MSI: > + break; > + default: > return false; > + } > > if (!(info->flags & MSI_FLAG_MUST_REACTIVATE)) > return false; Acked-by: Mar

Re: [patch V2 17/46] PCI/MSI: Rework pci_msi_domain_calc_hwirq()

On Wed, 26 Aug 2020 12:16:45 +0100, Thomas Gleixner wrote: > > From: Thomas Gleixner > > Retrieve the PCI device from the msi descriptor instead of doing so at the > call sites. > > Signed-off-by: Thomas Gleixner > Acked-by: Bjorn Helgaas Acked-by: Marc Zyngier

Re: [patch V2 19/46] x86/msi: Use generic MSI domain ops

msi_prepare); > > -void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) > -{ > - arg->desc = desc; > - arg->hwirq = pci_msi_domain_calc_hwirq(desc); > -} > -EXPORT_SYMBOL_GPL(pci_msi_set_desc); I think that at this stage, pci_msi_domain_calc_hwirq() can

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

/irq/chip.c +++ b/kernel/irq/chip.c @@ -1544,7 +1544,7 @@ int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) struct irq_data *pos = NULL; #ifdef CONFIG_IRQ_DOMAIN_HIERARCHY - for (; data; data = data->parent_data) + for (; data && !pos; data = data->paren

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

truct irq_dom > } > > /** > + * __msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain > associated tp @dev Spurious __. > + * @domain: The domain to managing the interrupts > + * @dev: Pointer to device struct of the device for which the interrupts >

Re: [EXT] Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

On 2020-07-16 04:23, Makarand Pawagi wrote: -Original Message- From: Lorenzo Pieralisi [...] Anyway - you need to seek feedback from Marc on whether patches 11 and 12 are OK from an irqchip perspective, it is possible we can take the rest of the series independently if everyone

Re: [PATCH v2 11/12] bus/fsl-mc: Refactor the MSI domain creation in the DPRC driver

++-- drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 15 +- 5 files changed, 47 insertions(+), 40 deletions(-) For this patch and the following one: Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ iommu mailing

Re: [PATCH v2 3/5] irqchip: Allow QCOM_PDC to be loadable as a permanent module

On Sat, 11 Jul 2020 00:27:45 +0100, Stephen Boyd wrote: > > Quoting John Stultz (2020-07-10 15:44:18) > > On Thu, Jul 9, 2020 at 11:02 PM Stephen Boyd wrote: > > > > > > Does it work? I haven't looked in detail but I worry that the child > > > irqdomain (i.e. pinctrl-msm) would need to delay

Re: [PATCH v2 3/5] irqchip: Allow QCOM_PDC to be loadable as a permanent module

On Sat, 27 Jun 2020 02:34:25 +0100, John Stultz wrote: > > On Fri, Jun 26, 2020 at 12:42 AM Stephen Boyd wrote: > > > > Quoting John Stultz (2020-06-24 17:10:37) > > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c > > > index 6ae9e1f0819d..3fee8b655da1 100644 > > > ---

Re: [RFC][PATCH 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

Hi John, +Will for the SMMU part. On 2020-06-16 07:13, John Stultz wrote: Allow the qcom_scm driver to be loadable as a permenent module. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linus Walleij Cc: Lina Iyer Cc

Re: [PATCH v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance

On 2020-05-21 15:17, Will Deacon wrote: [+Marc] On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote: The SMMUv3 can handle invalidation targeted at TLB entries with shared ASIDs. If the implementation supports broadcast TLB maintenance, enable it and keep track of it in a

Re: arm-smmu-v3 high cpu usage for NVMe

On Tue, 24 Mar 2020 09:18:10 + John Garry wrote: > On 23/03/2020 09:16, Marc Zyngier wrote: > > + Julien, Mark > > Hi Marc, > > >>> Time to enable pseudo-NMIs in the PMUv3 driver... > >>> > >> > >> Do you know if there is any p

Re: arm-smmu-v3 high cpu usage for NVMe

On 2020-03-23 09:03, John Garry wrote: On 20/03/2020 16:33, Marc Zyngier wrote: JFYI, I've been playing for "perf annotate" today and it's giving strange results for my NVMe testing. So "report" looks somewhat sane, if not a worryingly high % for arm_smmu_cmdq_issue_cmdlist(

Re: arm-smmu-v3 high cpu usage for NVMe

Hi John, On 2020-03-20 16:20, John Garry wrote: I've run a bunch of netperf instances on multiple cores and collecting SMMU usage (on TaiShan 2280). I'm getting the following ratio pretty consistently. - 6.07% arm_smmu_iotlb_sync - 5.74% arm_smmu_tlb_inv_range 5.09%

Re: [PATCH] iommu/rockchip: Don't provoke WARN for harmless IRQs

return ret; if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks))) Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundat

Re: [PATCH] iommu/dma: Handle MSI mappings separately

n business with a bnx2x device passed to a guest. FWIW: Tested-by: Marc Zyngier Thanks, M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 6/7] irqchip/gic-v3-mbi: Don't map the MSI page in mbi_compose_m{b, s}i_msg()

On 01/05/2019 14:58, Julien Grall wrote: > The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible > context. However, on RT, iommu_dma_map_msi_msg() requires to be called > from a preemptible context. > > A recent patch split iommu_dma_map_msi_msg in two new functions: > one

Re: [PATCH v2 4/7] irqchip/gic-v3-its: Don't map the MSI page in its_irq_compose_msi_msg()

On 01/05/2019 12:14, Julien Grall wrote: > On 30/04/2019 13:34, Auger Eric wrote: >> Hi Julien, > > Hi Eric, > > Thank you for the review! > >> >> On 4/29/19 4:44 PM, Julien Grall wrote: >>> its_irq_compose_msi_msg() may be called from non-preemptible context. >>> However, on RT,

Re: [PATCH v2 0/7] iommu/dma-iommu: Split iommu_dma_map_msi_msg in two parts

Hi Julien, On 29/04/2019 15:44, Julien Grall wrote: > Hi all, > > On RT, the function iommu_dma_map_msi_msg expects to be called from > preemptible > context. However, this is not always the case resulting a splat with > !CONFIG_DEBUG_ATOMIC_SLEEP: > > [ 48.875777] BUG: sleeping function

Re: [PATCH v2 2/7] iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts

On 29/04/2019 15:44, Julien Grall wrote: > On RT, iommu_dma_map_msi_msg() may be called from non-preemptible > context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as > the function is using spin_lock (they can sleep on RT). > > iommu_dma_map_msi_msg() is used to map the MSI page in

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

On 23/04/2019 14:19, Robin Murphy wrote: > On 23/04/2019 12:46, Marc Zyngier wrote: >> On 23/04/2019 11:51, Julien Grall wrote: >>> On 4/23/19 11:23 AM, Marc Zyngier wrote: >>>> Hi Julien, >>> >>> Hi Marc, >>> >>>> On 18/04/

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

On 23/04/2019 11:51, Julien Grall wrote: > On 4/23/19 11:23 AM, Marc Zyngier wrote: >> Hi Julien, > > Hi Marc, > >> On 18/04/2019 18:26, Julien Grall wrote: >>> When an MSI doorbell is located downstream of an IOMMU, it is required >>> to swizzle the phy

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

Hi Julien, On 18/04/2019 18:26, Julien Grall wrote: > When an MSI doorbell is located downstream of an IOMMU, it is required > to swizzle the physical address with an appropriately-mapped IOVA for any > device attached to one of our DMA ops domain. > > At the moment, the allocation of the

Re: [PATCH v6 09/22] vfio: VFIO_IOMMU_BIND/UNBIND_MSI

Hi Vincent, On 10/04/2019 13:35, Vincent Stehlé wrote: > On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote: >> Hi Marc, Robin, Alex, > (..) >> Do you think this is a reasonable assumption to consider devices within >> the same host iommu group share the same MSI doorbell? > > Hi Eric, >

Re: [PATCH] iommu: rockchip: Drop verbose prints in the interrupt handler

On 26/09/18 18:31, Ezequiel Garcia wrote: On Tue, 2018-09-25 at 13:29 +0200, Joerg Roedel wrote: On Thu, Aug 30, 2018 at 07:28:32PM -0300, Ezequiel Garcia wrote: Printing verbosely via WARN macros and friends in interrupt handlers is strongly discouraged. Drop them and use proper ratelimited

Re: [PATCH] iommu/rockchip: Free irqs in shutdown handler

ta(pdev); > + int i = 0, irq; > + > + while ((irq = platform_get_irq(pdev, i++)) != -ENXIO) > + devm_free_irq(iommu->dev, irq, iommu); > + > pm_runtime_force_suspend(>dev); > } > > -- > 2.17.0 > Acked-by: Marc Zyngier

Re: [PATCH] iommu/rockchip: Free irqs in shutdown handler

mmu->dev, irq, iommu); + pm_runtime_force_suspend(>dev); } Looks OK to me. I don't think there is a point in using devm_irq* anymore in this driver, but that's a separate issue. Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___

[PATCH v2 4/4] iommu/rockchip: Move irq request past pm_runtime_enable

in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 24 +--- 1 file c

[PATCH v2 2/4] arm64: rockchip: Force CONFIG_PM on Rockchip systems

already does). Signed-off-by: Marc Zyngier --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index d5aeac351fc3..21a715ad8222 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms

[PATCH v2 0/4] iommu/rockchip: Runtime PM fixes

/arm-kernel/msg670229.html * From v1: - Collected RBs from Heiko - Added two patches forcing CONFIG_PM on all Rockchip platforms at Heiko's request, following the example set by Tegra platforms. Marc Zyngier (4): ARM: rockchip: Force CONFIG_PM on Rockchip systems arm64: rockchip: Force

[PATCH v2 3/4] iommu/rockchip: Handle errors returned from PM framework

let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-io

[PATCH v2 1/4] ARM: rockchip: Force CONFIG_PM on Rockchip systems

already does). Signed-off-by: Marc Zyngier --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index fafd3d7f9f8c..8ca926522026 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip

Re: [PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

On 07/08/18 14:15, Heiko Stuebner wrote: > Am Dienstag, 7. August 2018, 14:31:49 CEST schrieb Marc Zyngier: >> On 07/08/18 13:09, Heiko Stuebner wrote: >>> Hi Marc, >>> >>> Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier: >>>> pm_ru

Re: [PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

On 07/08/18 13:09, Heiko Stuebner wrote: > Hi Marc, > > Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier: >> pm_runtime_get_if_in_use can fail: either PM has been disabled >> altogether (-EINVAL), or the device hasn't been enabled yet (0). >> Sadly, the

[PATCH 2/2] iommu/rockchip: Move irq request past pm_runtime_enable

in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletion

[PATCH 0/2] iommu/rockchip: Runtime PM fixes

). [1] https://www.spinics.net/lists/arm-kernel/msg670229.html Marc Zyngier (2): iommu/rockchip: Handle errors returned from PM framework iommu/rockchip: Move irq request past pm_runtime_enable drivers/iommu/rockchip-iommu.c | 45 +- 1 file changed, 28

[PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 21 +++-- 1 file c

Re: [PATCH] iommu/rockchip: Handle errors returned from PM framework

Hi Heiko, On 06/08/18 13:09, Heiko Stuebner wrote: > Hi Marc, > > Am Sonntag, 5. August 2018, 14:46:16 CEST schrieb Marc Zyngier: >> pm_runtime_get_if_in_use can fail: either PM has been disabled >> altogether (-EINVAL), or the device hasn't been enabled yet (0). >>

[PATCH] iommu/rockchip: Handle errors returned from PM framework

investigation, let's output a single warning (instead of flodding the console). In both cases, bail with an IRQ_NONE. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 7 --- 1 file changed, 4 insertions(+), 3

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

On 13/06/18 10:20, Thomas Gleixner wrote: > On Wed, 13 Jun 2018, Julien Thierry wrote: >> On 13/06/18 09:34, Peter Zijlstra wrote: >>> On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote: diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index 5426627..dbc5e02

Re: [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed

[Thanks Robin for pointing me to that patch.] Hi Heiko, On 24/05/18 23:06, Heiko Stübner wrote: > From: Sandy Huang > > The vop irq is shared between vop and iommu and irq probing in the > iommu driver moved to the probe function recently. This can in some > cases lead to

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

On 12/04/18 11:17, Robin Murphy wrote: > On 11/04/18 17:54, Marc Zyngier wrote: >> Hi Sammer, >> >> On 11/04/18 16:58, Goel, Sameer wrote: >>> >>> >>> On 3/28/2018 9:00 AM, Marc Zyngier wrote: >>>> On 2018-03-28 15:39, Tim

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

Hi Sammer, On 11/04/18 16:58, Goel, Sameer wrote: > > > On 3/28/2018 9:00 AM, Marc Zyngier wrote: >> On 2018-03-28 15:39, Timur Tabi wrote: >>> From: Sameer Goel <sg...@codeaurora.org> >>> >>> Set SMMU_GBPA to abort all incoming trans

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

On 2018-03-28 15:39, Timur Tabi wrote: From: Sameer Goel Set SMMU_GBPA to abort all incoming translations during the SMMU reset when SMMUEN==0. This prevents a race condition where a stray DMA from the crashed primary kernel can try to access an IOVA address as an

[PATCH] iommu/rockchip: Perform a reset on shutdown

our back. Note that we need to be extra cautious when doing so, as the IOMMU may not be clocked if controlled by a another master, as typical on Rockchip system. Suggested-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/iommu/rock

Re: [PATCH v2] iommu/arm-smmu-v3: limit reporting of MSI allocation failures

i_msg); > if (ret) { > - dev_warn(dev, "failed to allocate MSIs\n"); > + dev_warn(dev, "failed to allocate MSIs - falling back to wired > irqs\n"); > return; > } > > Acked-by: Marc Zyngier &

Re: [PATCH] iommu/arm-smmu-v3: suppress MSI allocation failure message

On 17/01/18 18:54, Robin Murphy wrote: > [ +Marc just in case ] > > On 17/01/18 18:39, Nate Watterson wrote: >> From: Sinan Kaya >> >> Even though QDF2400 supports MSI interrupts with SMMUv3, it is not enabled >> in ACPI FW to preserve compatibility with older kernel

Re: [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

/irqchip/irq-gic-v3-its.c | 3 +- > include/linux/acpi_iort.h| 7 ++- > 3 files changed, 116 insertions(+), 5 deletions(-) For the ITS part: Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> M. ___ iommu mailing list

Re: [PATCH v8 2/5] ACPI/IORT: Add msi address regions reservation helper

On 27/09/17 14:32, Shameer Kolothum wrote: > On some platforms msi parent address regions have to be excluded from > normal IOVA allocation in that they are detected and decoded in a HW > specific way by system components and so they cannot be considered normal > IOVA address space. > > Add a

Re: [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper

On 27/09/17 14:32, Shameer Kolothum wrote: > From: John Garry > > On some platforms msi-controller address regions have to be excluded > from normal IOVA allocation in that they are detected and decoded in > a HW specific way by system components and so they cannot be

Re: [PATCH] iommu: Avoid NULL group dereference

ng rather familiar, but now it's backed by the reasoning of having > a robust API able to do the expected thing for all devices regardless. > > Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory") > Reported-by: Shawn Lin <shawn@rock-chips.c

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

On 17/08/17 10:01, Shawn Lin wrote: > Hi Marc > > On 2017/8/17 16:52, Marc Zyngier wrote: >> On 17/08/17 09:28, Shawn Lin wrote: >>> If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't >>> have iommu support, we don't need to do iommu_dma_map_msi_ms

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

On 17/08/17 09:28, Shawn Lin wrote: > If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't > have iommu support, we don't need to do iommu_dma_map_msi_msg to > get mapped iommu address as all we need is the physical address. > Otherwise we see the oops shown below as we can't get a

Re: PCIe oops for NULL pointer dereference during next-20170807 and next-20170815

On 17/08/17 08:58, Joerg Roedel wrote: > On Thu, Aug 17, 2017 at 03:02:31PM +0800, Shawn Lin wrote: >> So should we revert this commit or maybe we could add some checking >> into gic-v2m and gic-v3-its to see if the dev is iommu-capable? If not, >> we should create another routine to map MSI msg.

Re: [PATCH v8 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

On 21/06/17 10:08, Will Deacon wrote: > Hi Geetha, > > On Wed, Jun 21, 2017 at 12:09:45PM +0530, Geetha Akula wrote: >> On Tue, Jun 20, 2017 at 11:30 PM, Will Deacon wrote: >>> On Tue, Jun 20, 2017 at 07:47:39PM +0530, Geetha sowjanya wrote: From: Geetha Sowjanya

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 18:16, Ray Jui wrote: > Hi Marc, > > On 5/30/17 9:59 AM, Marc Zyngier wrote: >> On 30/05/17 17:49, Ray Jui wrote: >>> Hi Will, >>> >>> On 5/30/17 8:14 AM, Will Deacon wrote: >>>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 17:49, Ray Jui wrote: > Hi Will, > > On 5/30/17 8:14 AM, Will Deacon wrote: >> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: >>> I'm writing to check with you to see if the latest arm-smmu.c driver in >>> v4.12-rc Linux for smmu-500 can support mapping that is only specific

Re: [PATCH v7 16/19] irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP

info->data = its; > inner_domain->host_data = info; > For patches 13 to 16, and provided that you address the couple of nits I mentioned in reply to patches 13 and 15: Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> Thanks, M. -- Jazz is not dead. It just s

Re: [PATCH v7 15/19] irqdomain: irq_domain_check_msi_remap

On 09/01/17 13:46, Eric Auger wrote: > This new function checks whether all MSI irq domains > implement IRQ remapping. This is useful to understand > whether VFIO passthrough is safe with respect to interrupts. > > On ARM typically an MSI controller can sit downstream > to the IOMMU without

Re: [PATCH v7 13/19] irqdomain: Add irq domain MSI and MSI_REMAP flags

Hi Eric, On 09/01/17 13:46, Eric Auger wrote: > We introduce two new enum values for the irq domain flag: > - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to > an MSI domain > - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI > remapping capabilities. > > Those values

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 06/01/17 04:27, Bharat Bhushan wrote: > Hi Mark, > >> -Original Message- >> From: Auger Eric [mailto:eric.au...@redhat.com] >> Sent: Thursday, January 05, 2017 5:39 PM >> To: Marc Zyngier <marc.zyng...@arm.com>; eric.auger@gmail.com; >&

Re: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level

On 06/01/17 09:08, Auger Eric wrote: > Hi Bharat > > On 06/01/2017 09:50, Bharat Bhushan wrote: >> Hi Eric, >> >>> -Original Message- >>> From: Eric Auger [mailto:eric.au...@redhat.com] >>> Sent: Friday, January 06, 2017 12:35 AM >>> To: eric.au...@redhat.com; eric.auger@gmail.com;

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 05/01/17 11:29, Auger Eric wrote: > Hi Marc, > > On 05/01/2017 12:25, Marc Zyngier wrote: >> On 05/01/17 10:45, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 16:27, Marc Zyngier wrote: >>>> On 04/01/17 14:11, Auger Eric wrote: >&g

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 05/01/17 10:45, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 16:27, Marc Zyngier wrote: >> On 04/01/17 14:11, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 14:46, Marc Zyngier wrote: >>>> Hi Eric, >>>> >>>&g

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 04/01/17 14:11, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 14:46, Marc Zyngier wrote: >> Hi Eric, >> >> On 04/01/17 13:32, Eric Auger wrote: >>> This new function checks whether all platform and PCI >>> MSI domains implement IRQ remapping.

  1   2   >