[PATCH v2] iommu/ipmmu-vmsa: Fix wrong error handle of ipmmu_add_device

Let's fix the error handle of ipmmu_add_device when failing to find utlbs, otherwise we take a risk of pontential memleak. Signed-off-by: Shawn Lin --- Changes in v2: - use error-out path drivers/iommu/ipmmu-vmsa.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v5 00/19] Generic DT bindings for PCI IOMMUs and ARM SMMU

On 23/08/16 20:05, Robin Murphy wrote: > Hi all, Oh bums, looks like I managed to miss LAKML off the CC list. If anyone there is interested, it's over here: https://lists.linuxfoundation.org/pipermail/iommu/2016-August/018230.html Robin. > > At long last I've finished the big SMMUv2 rework,

[PATCH v5 19/19] iommu/dma: Add support for mapping MSIs

When an MSI doorbell is located downstream of an IOMMU, attaching devices to a DMA ops domain and switching on translation leads to a rude shock when their attempt to write to the physical address returned by the irqchip driver faults (or worse, writes into some already-mapped buffer) and no

[PATCH v5 18/19] iommu/arm-smmu: Set domain geometry

For non-aperture-based IOMMUs, the domain geometry seems to have become the de-facto way of indicating the input address space size. That is quite a useful thing from the users' perspective, so let's do the same. Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu-v3.c

[PATCH v5 17/19] iommu/arm-smmu: Wire up generic configuration support

With everything else now in place, fill in an of_xlate callback and the appropriate registration to plumb into the generic configuration machinery, and watch everything just work. Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu.c | 168

[PATCH v5 13/19] iommu/arm-smmu: Add a stream map entry iterator

We iterate over the SMEs associated with a master config quite a lot in various places, and are about to do so even more. Let's wrap the idiom in a handy iterator macro before the repetition gets out of hand. Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu.c | 26

[PATCH v5 10/19] iommu/arm-smmu: Keep track of S2CR state

Making S2CRs first-class citizens within the driver with a high-level representation of their state offers a neat solution to a few problems: Firstly, the information about which context a device's stream IDs are associated with is already present by necessity in the S2CR. With that state easily

[PATCH v5 14/19] iommu/arm-smmu: Intelligent SMR allocation

Stream Match Registers are one of the more awkward parts of the SMMUv2 architecture; there are typically never enough to assign one to each stream ID in the system, and configuring them such that a single ID matches multiple entries is catastrophically bad - at best, every transaction raises a

[PATCH v5 16/19] Docs: dt: document ARM SMMU generic binding usage

Document how the generic "iommus" binding should be used to describe ARM SMMU stream IDs instead of the old "mmu-masters" binding. CC: Rob Herring CC: Mark Rutland Signed-off-by: Robin Murphy ---

[PATCH v5 15/19] iommu/arm-smmu: Convert to iommu_fwspec

In the final step of preparation for full generic configuration support, swap our fixed-size master_cfg for the generic iommu_fwspec. For the legacy DT bindings, the driver simply gets to act as its own 'firmware'. Farewell, arbitrary MAX_MASTER_STREAMIDS! Signed-off-by: Robin Murphy

[PATCH v5 08/19] iommu/arm-smmu: Handle stream IDs more dynamically

Rather than assuming fixed worst-case values for stream IDs and SMR masks, keep track of whatever implemented bits the hardware actually reports. This also obviates the slightly questionable validation of SMR fields in isolation - rather than aborting the whole SMMU probe for a hardware

[PATCH v5 07/19] iommu/arm-smmu: Set PRIVCFG in stage 1 STEs

Implement the SMMUv3 equivalent of d346180e70b9 ("iommu/arm-smmu: Treat all device transactions as unprivileged"), so that once again those pesky DMA controllers with their privileged instruction fetches don't unexpectedly fault in stage 1 domains due to VMSAv8 rules. Signed-off-by: Robin Murphy

[PATCH v5 12/19] iommu/arm-smmu: Streamline SMMU data lookups

Simplify things somewhat by stashing our arm_smmu_device instance in drvdata, so that it's readily available to our driver model callbacks. Then we can excise the private list entirely, since the driver core already has a perfectly good list of SMMU devices we can use in the one instance we

[PATCH v5 11/19] iommu/arm-smmu: Refactor mmu-masters handling

To be able to support the generic bindings and handle of_xlate() calls, we need to be able to associate SMMUs and stream IDs directly with devices *before* allocating IOMMU groups. Furthermore, to support real default domains with multi-device groups we also have to handle domain attach on a

[PATCH v5 05/19] iommu/arm-smmu: Implement of_xlate() for SMMUv3

Now that we can properly describe the mapping between PCI RIDs and stream IDs via "iommu-map", and have it fed it to the driver automatically via of_xlate(), rework the SMMUv3 driver to benefit from that, and get rid of the current misuse of the "iommus" binding. Since having of_xlate wired up

[PATCH v5 00/19] Generic DT bindings for PCI IOMMUs and ARM SMMU

Hi all, At long last I've finished the big SMMUv2 rework, so here's everything all together for a v5. As a quick breakdown: Patches 1-3 are the core PCI part, all acked and ready to go. No code changes from v4. Patch 4 is merely bugfixed from v4 for simplicity, as I've not yet managed to take

[PATCH v5 03/19] iommu/of: Handle iommu-map property for PCI

Now that we have a way to pick up the RID translation and target IOMMU, hook up of_iommu_configure() to bring PCI devices into the of_xlate mechanism and allow them IOMMU-backed DMA ops without the need for driver-specific handling. Signed-off-by: Robin Murphy ---

[PATCH v5 06/19] iommu/arm-smmu: Support non-PCI devices with SMMUv3

With the device <-> stream ID relationship suitably abstracted and of_xlate() hooked up, the PCI dependency now looks, and is, entirely arbitrary. Any bus using the of_dma_configure() mechanism will work, so extend support to the platform and AMBA buses which do just that. Signed-off-by: Robin

[PATCH v5 02/19] of/irq: Break out msi-map lookup (again)

The PCI msi-map code is already doing double-duty translating IDs and retrieving MSI parents, which unsurprisingly is the same functionality we need for the identically-formatted PCI iommu-map property. Drag the core parsing routine up yet another layer into the general OF-PCI code, and further

[PATCH v5 01/19] Docs: dt: add PCI IOMMU map bindings

From: Mark Rutland The existing IOMMU bindings are able to specify the relationship between masters and IOMMUs, but they are insufficient for describing the general case of hotpluggable busses such as PCI where the set of masters is not known until runtime, and the

[PATCH v5 04/19] iommu/of: Introduce iommu_fwspec

Introduce a common structure to hold the per-device firmware data that non-architectural IOMMU drivers generally need to keep track of. Initially this is DT-specific to complement the existing of_iommu support code, but will generalise further once other firmware methods (e.g. ACPI IORT) come

Re: [PATCHv9 4/6] arm: dma-mapping: add {map,unmap}_resource for iommu ops

Hi Russell, If you have the time can you please have a look at this patch? This series have been out for some time now and Vinod is willing to take it through the dmaengine tree but a ACK is needed on this patch from you first. On 2016-08-10 13:22:17 +0200, Niklas Söderlund wrote: > Add

Re: [PATCH v4 01/15] drivers: iommu: add FWNODE_IOMMU fwnode type

Hi Rafael, On Mon, Aug 15, 2016 at 04:23:26PM +0100, Lorenzo Pieralisi wrote: > On systems booting with a device tree, every struct device is > associated with a struct device_node, that represents its DT > representation. The device node can be used in generic kernel > contexts (eg IRQ