Re: [PATCH 24/61] iommu: simplify getting .drvdata

2018-05-03 Thread Joerg Roedel
On Thu, Apr 19, 2018 at 04:05:54PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Build tested only. buildbot is happy. Please apply individually.
> 
>  drivers/iommu/qcom_iommu.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Applied, thanks.


Re: [PATCH 1/3] dt-bindings: iommu: ipmmu-vmsa: Add device tree support for r8a774[35]

2018-03-20 Thread Joerg Roedel
On Wed, Jan 24, 2018 at 03:42:00PM +, Biju Das wrote:
> Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
> (r8a774[35]) IPMMU are identical to the R-Car Gen2 family.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 
> ---
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

Patches 2 and 3 seems already to be applied to another tree.



Re: [PATCH 1/3] dt-bindings: iommu: ipmmu-vmsa: Add device tree support for r8a774[35]

2018-03-14 Thread Joerg Roedel
On Wed, Mar 07, 2018 at 09:09:21AM +0100, Simon Horman wrote:
> [CC Alex Williamson]
> 
> It looks like the last patch to this file was taken by Alex.
> Perhaps he would be willing to take this one too if it it was
> reposted with him CCed.

Alex was taking care of IOMMU patches while I was off at the end of last
year. I will take care of these.


Regards,

Joerg



Re: [PATCH v2 2/3] iommu/ipmmu-vmsa: Remove redundant of_iommu_init_fn hook

2018-01-17 Thread Joerg Roedel
On Tue, Jan 09, 2018 at 04:17:26PM +, Robin Murphy wrote:
> Having of_iommu_init() call ipmmu_init() via ipmmu_vmsa_iommu_of_setup()
> does nothing that the subsys_initcall wouldn't do slightly later anyway,
> since probe-deferral of masters means it is no longer critical to
> register the driver super-early. Clean it up.
> 
> Signed-off-by: Robin Murphy 
> ---

Applied this one, thanks.

The other two are already applied now from your first post.


Re: [PATCH 0/3] iommu/ipmmu-vmsa: R-Car Gen3 IPMMU DT binding update

2017-10-10 Thread Joerg Roedel
On Fri, Sep 22, 2017 at 06:44:54AM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: R-Car Gen3 IPMMU DT binding update
> 
> [PATCH 1/3] iommu/ipmmu-vmsa: Document R-Car M3-W IPMMU DT bindings
> [PATCH 2/3] iommu/ipmmu-vmsa: Document R-Car V3M IPMMU DT bindings
> [PATCH 3/3] iommu/ipmmu-vmsa: Document R-Car D3 IPMMU DT bindings

I guess this goes upstream through the devicetree repository?


Joerg



Re: [PATCH] iommu/ipmmu-vmsa: Use iommu_device_sysfs_add()/remove()

2017-08-22 Thread Joerg Roedel
On Mon, Aug 21, 2017 at 02:53:35PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Extend the driver to make use of iommu_device_sysfs_add()/remove()
> functions to hook up initial sysfs support.
> 
> Suggested-by: Joerg Roedel <jroe...@suse.de>
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>

Applied, thanks.



Re: [PATCH v2 01/05] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister()

2017-07-26 Thread Joerg Roedel
On Mon, Jul 17, 2017 at 10:05:10PM +0900, Magnus Damm wrote:
> --- 0001/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c   2017-07-17 21:01:47.140607110 +0900
> @@ -35,6 +35,7 @@
>  struct ipmmu_vmsa_device {
>   struct device *dev;
>   void __iomem *base;
> + struct iommu_device iommu;
>   struct list_head list;
>  
>   unsigned int num_utlbs;
> @@ -1054,6 +1055,13 @@ static int ipmmu_probe(struct platform_d
>  
>   ipmmu_device_reset(mmu);
>  
> + iommu_device_set_ops(>iommu, _ops);
> + iommu_device_set_fwnode(>iommu, >dev.of_node->fwnode);
> +
> + ret = iommu_device_register(>iommu);
> + if (ret)
> + return ret;
> +

Looks good so far, why don't you also add the iommu to sysfs with
iommu_device_sysfs_add()?


Joerg



Re: [PATCH v8 00/08] iommu/ipmmu-vmsa: IPMMU multi-arch update V8

2017-05-17 Thread Joerg Roedel
On Wed, May 17, 2017 at 07:06:16PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V8
> 
> [PATCH v8 01/08] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v8 02/08] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for 
> context
> [PATCH v8 03/08] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH v8 04/08] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH v8 05/08] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> [PATCH v8 06/08] iommu/ipmmu-vmsa: Use fwspec iommu_priv on ARM64
> [PATCH v8 07/08] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
> [PATCH v8 08/08] iommu/ipmmu-vmsa: Fix pgsize_bitmap semicolon typo

Applied, thanks.



Re: [PATCH 00/03] arm64: dts: r8a7795: IPMMU upstream USB integration

2017-04-03 Thread Joerg Roedel
On Tue, Mar 28, 2017 at 06:32:33PM +0900, Magnus Damm wrote:
> The recommended IPMMU driver patch stack consists of the following series:
>  [PATCH v7 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V7
>  [PATCH v3 00/09] iommu/ipmmu-vmsa: r8a7795 support V3

These two patch-sets have unaddressed comments. Please address these and
get a Reviewed-by from Robin on the re-posts.


Joerg


Re: [PATCH/RFC v2 0/4] iommu/ipmmu-vmsa: IPMMU slave device whitelist V2

2017-03-22 Thread Joerg Roedel
On Fri, Jan 27, 2017 at 03:14:07PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU slave device whitelist V2
> 
> [PATCH/RFC v2 1/4] iommu/of: Skip IOMMU devices disabled in DT
> [PATCH/RFC v2 2/4] iommu/ipmmu-vmsa: Get rid of disabled device check
> [PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Check devices in xlate()
> [PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Opt-in slave devices based on ES version
> 
> Here's an updated prototype that shows how DT integration of IPMMU details
> may be integrated and merged upstream based on SoC data sheet ahead of
> time followed by enablement in the IPMMU driver code once the appropriate
> SoC ES version has been released and the hardware has been tested.
> 
> Changes since V1:
>  - Broke out patch 1 from the IPMMU driver
>  - Moved slave device check from ->add_device() to ->xlate() (Thanks Robin!)
>  - Updated white list patch to hook into ->xlate()
> 
> Patch 1 may be suitable for upstream merge, however other patches should
> in the future if agreed on be rolled into the IPMMU driver series.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> ---
> 
>  Developed on top of renesas-drivers-2017-01-24-v4.10-rc5
> 
>  drivers/iommu/ipmmu-vmsa.c |   59 
> +++-
>  drivers/iommu/of_iommu.c   |2 -
>  2 files changed, 33 insertions(+), 28 deletions(-)

For the series:

Reviewed-by: Joerg Roedel <jroe...@suse.de>


Re: [PATCH v7 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

2017-03-22 Thread Joerg Roedel
On Tue, Mar 07, 2017 at 12:17:33PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+rene...@opensource.se>
> 
> Introduce an alternative set of iommu_ops suitable for 64-bit ARM
> as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the
> Kconfig to depend on ARM or IOMMU_DMA. Initialize the device
> from ->xlate() when CONFIG_IOMMU_DMA=y.
> 
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> ---
> 
>  Changes since V6:
>  - Rolled in the following patches from "r8a7795 support V2":
>[PATCH v2 04/11] iommu/ipmmu-vmsa: Reuse iommu groups
>[PATCH v2 06/11] iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
>  - Moved find_group() implementation to prevent warning on 32-bit ARM
>  - Rolled in the following patch from "IPMMU slave device whitelist V2":
>[PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Check devices in xlate()
> 
>  drivers/iommu/Kconfig  |1 
>  drivers/iommu/ipmmu-vmsa.c |  164 
> +++++++++---
>  2 files changed, 157 insertions(+), 8 deletions(-)

Reviewed-by: Joerg Roedel <jroe...@suse.de>


Re: [PATCH v3 0/3] iommu/ipmmu-vmsa: r8a7796 support V3

2017-03-22 Thread Joerg Roedel
Hey Magnus,

On Sun, Mar 12, 2017 at 02:38:20PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: r8a7796 support V3
> 
> [PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
> [PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> [PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

I just tried to apply a few of your patch-sets, but failed because they
don't apply cleanly and it is not clear what the dependencies are and in
which order they need to be applied.

So for now I skipped all ipmmu-vmsa patches that are currently in my
inbox. Please rebase your different series to v4.11-rc3 and resend them
in the right order, with all Reviewed-bys and other tags that people
gave you included. Then I am taking another look into applying them.


Thanks,

Joerg


Re: [PATCH v2] iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address space

2017-02-06 Thread Joerg Roedel
On Tue, Jan 31, 2017 at 12:17:07PM +0100, Geert Uytterhoeven wrote:
> Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses
> only, and thus sets io_pgtable_cfg.ias = 32.  However, it doesn't force
> a 32-bit IOVA space through the IOMMU Domain Geometry.
> 
> Hence if a device (e.g. SYS-DMAC) rightfully configures a 40-bit DMA
> mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA
> space, leading to out-of-bounds accesses of the PGD when mapping the
> IOVA.
> 
> Force a 32-bit IOMMU Domain Geometry to fix this.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Robin Murphy 

Applied, thanks.



Re: [PATCH v2 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

2017-01-27 Thread Joerg Roedel
On Mon, Jan 23, 2017 at 08:40:29PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Bump up the maximum numbers of micro-TLBS to 48.
> 
> Each IPMMU device instance get micro-TLB assignment via
> the "iommus" property in DT. Older SoCs tend to use a
> maximum number of 32 micro-TLBs per IPMMU instance however
> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
> 
> At this point no SoC specific handling is done to validate
> the maximum number of micro-TLBs, and because of that the
> DT information is assumed to be within correct range for
> each particular SoC.
> 
> If needed in the future SoC specific feature flags can be
> added to handle the maximum number of micro-TLBs without
> requiring DT changes, however at this point this does not
> seem necessary.
> 
> Signed-off-by: Magnus Damm 

I get a conflict when applying this to v4.10-rc5. What is this based on,
any patches I missed?


Joerg



Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

2016-11-11 Thread Joerg Roedel
On Fri, Nov 11, 2016 at 03:13:32AM +0200, Laurent Pinchart wrote:
> Joerg, as I've sent a few comments about the other patches (sorry for the 
> late 
> review, I got delayed by KS and LPC), the follow-up patch should probably be 
> squashed into this one when Magnus addresses my comments. Could you please 
> hold off pushing the arm/renesas branch until Magnus replies to this ?

Okay, I wait for a re-post and replace the patches in my tree then.



Joerg



Re: [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6

2016-11-10 Thread Joerg Roedel
On Thu, Oct 20, 2016 at 08:35:33AM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V6
> 
> [PATCH v6 01/07] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v6 02/07] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for 
> context
> [PATCH v6 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH v6 04/07] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> [PATCH v6 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access
> [PATCH v6 07/07] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency

Applied to arm/renesas, thanks.



Re: [PATCH v5 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V5

2016-09-22 Thread Joerg Roedel
On Tue, Sep 20, 2016 at 10:43:55PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V5
> 
> [PATCH v5 01/07] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v5 02/07] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for 
> context
> [PATCH v5 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH v5 04/07] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH v5 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> [PATCH v5 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access
> [PATCH v5 07/07] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency

So except for patch 5 this looks good to me. Please add

Reviewed-by: Joerg Roedel <jroe...@suse.de>

to all patches, except patch 5, when you resend.


Thanks,

Joerg



Re: [PATCH v5 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

2016-09-22 Thread Joerg Roedel
On Tue, Sep 20, 2016 at 10:44:46PM +0900, Magnus Damm wrote:
> +#ifdef CONFIG_IOMMU_DMA
> +
> +static struct iommu_domain *ipmmu_domain_alloc_dma(unsigned type)
> +{
> + struct iommu_domain *io_domain;
> +
> + if (type != IOMMU_DOMAIN_DMA)
> + return NULL;
> +
> + io_domain = __ipmmu_domain_alloc(type);
> + if (io_domain)
> + iommu_get_dma_cookie(io_domain);
> +
> + return io_domain;
> +}
> +
> +static void ipmmu_domain_free_dma(struct iommu_domain *io_domain)
> +{
> + iommu_put_dma_cookie(io_domain);
> + ipmmu_domain_free(io_domain);
> +}

> [...]

> +static const struct iommu_ops ipmmu_ops = {
> + .domain_alloc = ipmmu_domain_alloc_dma,
> + .domain_free = ipmmu_domain_free_dma,

Okay, so when CONFIG_IOMMU_DMA is enabled, you only support allocation
of DMA domains, not UNMANAGED domains anymore. Is there a reason for
that?

You can reduce the #ifdef'ed coded by supporting both types of domains
and call into allocation-subfunctions for DMA and UNMANAGED domains. The
#ifdef could then only let the dma-allocation function return NULL.

This would be much more compatible to what other IOMMU drivers do and
will allow VFIO usage in the future.



Joerg



Re: [PATCH v2 00/11] iommu/ipmmu-vmsa: r8a7795 support V2

2016-06-21 Thread Joerg Roedel
On Mon, Jun 06, 2016 at 12:57:23PM +0900, Magnus Damm wrote:
>  Developed on top of next-20160602 and:
>  [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3
> 
>  drivers/iommu/ipmmu-vmsa.c |  318 
> +---
>  1 file changed, 269 insertions(+), 49 deletions(-)

Okay, what is the plan on merging this? It is developed on linux-next
and doesn't apply on v4.7-rc4. From the areas it touches it should go
through the iommu-tree, unless there are good reasons not to.


Joerg

P.S.: Same question applies to your other two patch-sets.


Re: [PATCH 00/04] iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update

2016-04-05 Thread Joerg Roedel
On Wed, Mar 16, 2016 at 02:04:31AM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update
> 
> [PATCH 01/04] iommu/ipmmu-vmsa: 32-bit ARM may have CONFIG_IOMMU_DMA=y
> [PATCH 02/04] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH 03/04] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH 04/04] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

These patches do not apply to v4.6-rc2. Can you please rebase them,
address the comments and add the Reviewed-by's?


Joerg



Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding

2016-03-03 Thread Joerg Roedel
On Thu, Mar 03, 2016 at 09:05:39AM +0900, Simon Horman wrote:
> On Thu, Mar 03, 2016 at 12:46:30AM +0900, Magnus Damm wrote:
> > On Wed, Mar 2, 2016 at 11:55 PM, Joerg Roedel <j...@8bytes.org> wrote:
> > > On Mon, Feb 29, 2016 at 11:33:09PM +0900, Magnus Damm wrote:
> > >> From: Magnus Damm <damm+rene...@opensource.se>
> > >>
> > >> Update the IPMMU DT binding documentation to include the r8a7795 compat
> > >> string as well as the "renesas,ipmmu-main" property that on r8a7795 will
> > >> be used to describe the topology and the relationship between the various
> > >> cache IPMMU instances and the main IPMMU.
> > >>
> > >> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
> > >> ---
> > >>
> > >>  Written against linux-next tag next-20160229
> > >>
> > >>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |   15 
> > >> --
> > >>  1 file changed, 13 insertions(+), 2 deletions(-)
> > >
> > > Through which tree should this go?
> > 
> > Unless anyone objects may I suggest going through your tree please!
> 
> FWIW that would be my preferred option.

Okay, applied.


Re: [PATCH] iommu: ipmmu-vmsa: Use ARCH_RENESAS

2016-02-25 Thread Joerg Roedel
On Mon, Feb 22, 2016 at 10:41:35AM +0900, Simon Horman wrote:
> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> 
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> 
> Signed-off-by: Simon Horman 
> ---
>  drivers/iommu/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.



Re: [PATCH] iommu: fix second argument of trace_map() to report correct paddr

2016-02-25 Thread Joerg Roedel
On Wed, Feb 10, 2016 at 10:18:04AM +0900, Yoshihiro Shimoda wrote:
> Since iommu_map() code added pgsize value to the paddr, trace_map()
> used wrong paddr. So, this patch adds "orig_paddr" value in the
> iommu_map() to use for the trace_map().
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/iommu/iommu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.