Re: [Patch V2 2/2] iommu: remove sysfs_link to device in iommu_group/devices when failed

On Wed, 23 Mar 2016 22:25:11 + Wei Yang wrote: > The original code forgets to remove the sysfs_link to a device in > iommu_group/devices directory, when the creation fails or conflicts on the > name. > > This patch tries to remove the sysfs_link on the failure. >

Re: [PATCH] iommu: remove the iommu_callback_data

Obsolete this one, V2 is sent. On Sun, Mar 20, 2016 at 01:57:52AM +, Wei Yang wrote: >According to the code path, iommu_callback_data is passed in >iommu_bus_init() and just used in {add/remove}_iommu_group, by when the >bus->iommu_ops is already set up properly. > >This patch removes the

[Patch V2 0/2] Cleanup on IOMMU

This two patches tries to do some cleanup in iommu. V2: * add patch 2 Wei Yang (2): iommu: remove the iommu_callback_data iommu: remove sysfs_link to device in iommu_group/devices when failed drivers/iommu/iommu.c | 22 +++--- 1 file changed, 7 insertions(+), 15

[Patch V2 2/2] iommu: remove sysfs_link to device in iommu_group/devices when failed

The original code forgets to remove the sysfs_link to a device in iommu_group/devices directory, when the creation fails or conflicts on the name. This patch tries to remove the sysfs_link on the failure. Signed-off-by: Wei Yang --- drivers/iommu/iommu.c |1 + 1

[Patch V2 1/2] iommu: remove the iommu_callback_data

According to the code path, iommu_callback_data is passed in iommu_bus_init() and just used in {add/remove}_iommu_group, by when the bus->iommu_ops is already set up properly. This patch removes the iommu_callback_data by retrieving iommu_ops from bus->iommu_ops directly. Signed-off-by: Wei

Re: [PATCH 0/6] of: Implement iterator for phandles

On Wed, Mar 23, 2016 at 6:54 AM, Joerg Roedel wrote: > Hi Rob, > > On Tue, Mar 22, 2016 at 01:45:41PM -0500, Rob Herring wrote: >> On Tue, Mar 22, 2016 at 12:58 PM, Joerg Roedel wrote: >> > Please review. Patches are based on v4.5. >> >> Other than my one

[PATCH] intel-iommu: fix up comment

dma_pte_free_pagetable no longer depends on last level ptes being clear, it clears them itself. Fix up the comment to match. Cc: Jiang Liu Suggested-by: Alex Williamson Signed-off-by: Michael S. Tsirkin ---

RE: [v2] powerpc: Fix incorrect PPC32 PAMU dependency

> -Original Message- > From: Linuxppc-dev [mailto:linuxppc-dev- > bounces+varun.sethi=freescale@lists.ozlabs.org] On Behalf Of Madalin- > Cristian Bucur > Sent: Wednesday, March 23, 2016 3:29 PM > To: j...@8bytes.org; Andy Fleming > Cc:

Re: [v2] powerpc: Fix incorrect PPC32 PAMU dependency

> -Original Message- > From: Andy Fleming > To: j...@8bytes.org > Cc: iommu@lists.linux-foundation.org, linuxppc-...@lists.ozlabs.org > Subject: [v2] powerpc: Fix incorrect PPC32 PAMU dependency > > The Freescale PAMU can be enabled on both 32 and 64-bit Power > chips.

Re: [PATCH v2] iommu/arm-smmu: Make use of phandle iterators in device-tree device-tree parsing

Hi Joerg, [auto build test ERROR on iommu/next] [also build test ERROR on v4.5 next-20160323] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Joerg-Roedel/iommu-arm-smmu-Make-use-of-phandle

[Patch V3 3/4] iommu/vt-d: check Register Base Address at the beginning of dmar_parse_one_drhd()

A NULL value of Register Base Address in a Hardware Unit Definition means it is an invalid dmar. Current implementation checks this value in alloc_iommu(), by when it has already allocated memory to store itself and device scope. This patch moves the check at the beginning of

[Patch V3 4/4] iommu/vt-d: refine dmar_acpi_dev_scope_init() with dmar_walk_dmar_table()

dmar_acpi_dev_scope_init() iterates on the remapping structure and just do proper job for ANDD structure. This is the what dmar_walk_dmar_table() does. This patch improves the code with dmar_walk_dmar_table(). Signed-off-by: Wei Yang --- drivers/iommu/dmar.c | 56

[Patch V3 0/4] Code refine for Intel IOMMU

These four patches try to refine the Intel IOMMU. Patch 1/2 tries to make it

[Patch V3 2/4] iommu/vt-d: use zero-sized array in DMAR related ACPI structures

1. DMAR table has variable number of remapping entries 2. DMAR hardware unit has variable number of device scope 3. DMAR device scope has variable number of pci path In current implementation, we use (head + 1) to access these variable number elements, which may not be obvious for audience.

[Patch V3 1/4] iommu/vt-d: replace *hdr with drhd[0] in struct dmar_drhd_unit

Before commit <6b1972493a84> ("iommu/vt-d: Implement DMAR unit hotplug framework"),dmaru->hdr just points to the memory region of DMA remapping hardware definition. In this case, it would have no difference to where we put hdr. After this commit, DMA remapping hardware definition is copied and

Re: [PATCH 0/6] of: Implement iterator for phandles

Hi Rob, On Tue, Mar 22, 2016 at 01:45:41PM -0500, Rob Herring wrote: > On Tue, Mar 22, 2016 at 12:58 PM, Joerg Roedel wrote: > > Please review. Patches are based on v4.5. > > Other than my one comment, this looks good to me. For the series: > > Acked-by: Rob Herring

Re: [PATCH 6/6] iommu/arm-smmu: Make use of phandle iterators in device-tree parsing

Hi Robin, On Tue, Mar 22, 2016 at 06:53:48PM +, Robin Murphy wrote: > In a stream-matching implementation, a device may quite legitimately > own anything up to _all_ of the stream IDs (32768, or 65536 if we > ever implement support for the SMMUv2 EXID extension), so this is > only a genuine

[PATCH v2] iommu/arm-smmu: Make use of phandle iterators in device-tree device-tree parsing

On Tue, Mar 22, 2016 at 01:38:06PM -0500, Rob Herring wrote: > > + struct of_phandle_iterator it; > > + struct arm_smmu_phandle_args masterspec; > > Isn't this a bit big to put on the stack being ~512 bytes? Yeah, you might be right. I havn't seen any problems booting with this being