[PATCH] dt-bindings: iommu: renesas, ipmmu-vmsa: Reformat renesas, ipmmu-main description

2022-01-26 Thread Geert Uytterhoeven
Remove trailing whitespace and break overly long lines.

Signed-off-by: Geert Uytterhoeven 
---
 .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml 
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 507853fcc746eea1..67da53e8d4d10aa0 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -69,9 +69,9 @@ properties:
 items:
   - items:
   - description: phandle to main IPMMU
-  - description: the interrupt bit number associated with the 
particular 
-  cache IPMMU device. The interrupt bit number needs to match the 
main 
-  IPMMU IMSSTR register. Only used by cache IPMMU instances.
+  - description: the interrupt bit number associated with the 
particular
+  cache IPMMU device. The interrupt bit number needs to match the
+  main IPMMU IMSSTR register. Only used by cache IPMMU instances.
 description:
   Reference to the main IPMMU phandle plus 1 cell. The cell is
   the interrupt bit number associated with the particular cache IPMMU
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: Improve phandle-array schemas

2022-01-19 Thread Geert Uytterhoeven
Hi Rob,

On Wed, Jan 19, 2022 at 2:50 AM Rob Herring  wrote:

> The 'phandle-array' type is a bit ambiguous. It can be either just an
> array of phandles or an array of phandles plus args. Many schemas for
> phandle-array properties aren't clear in the schema which case applies
> though the description usually describes it.
>
> The array of phandles case boils down to needing:
>
> items:
>   maxItems: 1
>
> The phandle plus args cases should typically take this form:
>
> items:
>   - items:
>   - description: A phandle
>   - description: 1st arg cell
>   - description: 2nd arg cell
>
> With this change, some examples need updating so that the bracketing of
> property values matches the schema.

> Signed-off-by: Rob Herring 

The Renesas parts look good to me.
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/2] iommu/ipmmu-vmsa: Add support for r8a779a0

2021-09-30 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
 wrote:
> This patch series adds support for r8a779a0 (R-Car V3U).
>
> Yoshihiro Shimoda (2):
>   dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779a0 support
>   iommu/ipmmu-vmsa: Add support for r8a779a0

Thanks to rcar-4.1.0.rc16 of the R-Car BSP, I was pointed to the fact
that the IPMMU modules on R-Car V3U have module clocks and resets,
unlike on other R-Car SoCs.
Probably they should be handled, too?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

2021-09-07 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Tue, Sep 7, 2021 at 9:29 AM Yoshihiro Shimoda
 wrote:
> > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 3:34 PM
> > On Tue, Sep 7, 2021 at 2:02 AM Yoshihiro Shimoda
> >  wrote:
> > > > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 12:34 AM
> > > > On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
> > > >  wrote:
> > > > > Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> > > > > of this SoC differs than others. So, add a new ipmmu_features for it.
> > > > >
> > > > > Signed-off-by: Yoshihiro Shimoda 
> > > >
> > > > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > >
> > > > > @@ -922,6 +922,20 @@ static const struct ipmmu_features 
> > > > > ipmmu_features_rcar_gen3 = {
> > > > > .utlb_offset_base = 0,
> > > > >  };
> > > > >
> > > > > +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> > > > > +   .use_ns_alias_offset = false,
> > > > > +   .has_cache_leaf_nodes = true,
> > > > > +   .number_of_contexts = 8,
> > > >
> > > > Shouldn't this be 16?
> > > > Or do you plan to add support for more than 8 contexts later, as that
> > > > would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
> > > > to handle the second bank of 8 contexts?
> > >
> > > I would like to add support for more than 8 contexts later because
> > > I realized that ctx_offset_{base,stride} are not suitable for the second 
> > > bank
> > > of 8 contexts...
> >
> > Wouldn't something like below be sufficient?
>
> Thank you for your suggestion!
>
> >  static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
> >   unsigned int context_id, unsigned int reg)
> >  {
> > -   return mmu->features->ctx_offset_base +
> > -  context_id * mmu->features->ctx_offset_stride + reg;
> > +   unsigned int base = mmu->features->ctx_offset_base;
> > +
> > +   if (context_id > 7)
> > +   base += 0x800 - 8 * 0x1040;
>
> This should be "base += 0x800 - 8 * 0x40;" because the 8th context address is
> 0x18800, not 0x10800.

Doh, I should have written my first thought ("base += FIXME" ;-)

> I'll send v2 patch to support 16 contexts.
> (I'll change IPMMU_CTX_MAX to 16 too.)

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

2021-09-07 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Tue, Sep 7, 2021 at 2:02 AM Yoshihiro Shimoda
 wrote:
> > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 12:34 AM
> > On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
> >  wrote:
> > > Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> > > of this SoC differs than others. So, add a new ipmmu_features for it.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> >
> > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > +++ b/drivers/iommu/ipmmu-vmsa.c
> >
> > > @@ -922,6 +922,20 @@ static const struct ipmmu_features 
> > > ipmmu_features_rcar_gen3 = {
> > > .utlb_offset_base = 0,
> > >  };
> > >
> > > +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> > > +   .use_ns_alias_offset = false,
> > > +   .has_cache_leaf_nodes = true,
> > > +   .number_of_contexts = 8,
> >
> > Shouldn't this be 16?
> > Or do you plan to add support for more than 8 contexts later, as that
> > would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
> > to handle the second bank of 8 contexts?
>
> I would like to add support for more than 8 contexts later because
> I realized that ctx_offset_{base,stride} are not suitable for the second bank
> of 8 contexts...

Wouldn't something like below be sufficient?

 static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
  unsigned int context_id, unsigned int reg)
 {
-   return mmu->features->ctx_offset_base +
-  context_id * mmu->features->ctx_offset_stride + reg;
+   unsigned int base = mmu->features->ctx_offset_base;
+
+   if (context_id > 7)
+   base += 0x800 - 8 * 0x1040;
+
+   return base + context_id * mmu->features->ctx_offset_stride + reg;
 }

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0

2021-09-06 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
 wrote:
> Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> of this SoC differs than others. So, add a new ipmmu_features for it.
>
> Signed-off-by: Yoshihiro Shimoda 

> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c

> @@ -922,6 +922,20 @@ static const struct ipmmu_features 
> ipmmu_features_rcar_gen3 = {
> .utlb_offset_base = 0,
>  };
>
> +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> +   .use_ns_alias_offset = false,
> +   .has_cache_leaf_nodes = true,
> +   .number_of_contexts = 8,

Shouldn't this be 16?
Or do you plan to add support for more than 8 contexts later, as that
would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
to handle the second bank of 8 contexts?

Regardless, I assume this will still work when when limiting to 8
contexts, so
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779a0 support

2021-09-06 Thread Geert Uytterhoeven
On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
 wrote:
> Add support for r8a779a0 (R-Car V3U).
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu/io-pgtable: Abstract iommu_iotlb_gather access

2021-08-24 Thread Geert Uytterhoeven
Hi Robin,

On Fri, Aug 20, 2021 at 3:22 PM Robin Murphy  wrote:
> Previously io-pgtable merely passed the iommu_iotlb_gather pointer
> through to helpers, but now it has grown its own direct dereference.
> This turns out to break the build for !IOMMU_API configs where the
> structure only has a dummy definition. It will probably also crash
> drivers who don't use the gather mechanism and simply pass in NULL.
>
> Wrap this dereference in a suitable helper which can both be stubbed
> out for !IOMMU_API and encapsulate a NULL check otherwise.
>
> Fixes: 7a7c5badf858 ("iommu: Indicate queued flushes via gather data")

Is this the right Fixes tag?

The build issue was introduced by:
Fixes: a8e5f04458c4e496 ("iommu/io-pgtable: Remove non-strict quirk")

> Reported-by: kernel test robot 
> Signed-off-by: Robin Murphy 

Thanks, this fixes the build issues I was seeing.

Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 15/24] iommu/io-pgtable: Remove non-strict quirk

2021-08-24 Thread Geert Uytterhoeven
Hi Robin,

On Wed, Aug 11, 2021 at 2:24 PM Robin Murphy  wrote:
> IO_PGTABLE_QUIRK_NON_STRICT was never a very comfortable fit, since it's
> not a quirk of the pagetable format itself. Now that we have a more
> appropriate way to convey non-strict unmaps, though, this last of the
> non-quirk quirks can also go, and with the flush queue code also now
> enforcing its own ordering we can have a lovely cleanup all round.
>
> Signed-off-by: Robin Murphy 

Thanks for your patch, which is now commit a8e5f04458c4e496
("iommu/io-pgtable: Remove non-strict quirk") in iommu/next.

> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -700,14 +700,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable 
> *data,
> ARM_V7S_BLOCK_SIZE(lvl + 1));
> ptep = iopte_deref(pte[i], lvl, data);
> __arm_v7s_free_table(ptep, lvl + 1, data);
> -   } else if (iop->cfg.quirks & 
> IO_PGTABLE_QUIRK_NON_STRICT) {
> -   /*
> -* Order the PTE update against queueing the 
> IOVA, to
> -* guarantee that a flush callback from a 
> different CPU
> -* has observed it before the TLBIALL can be 
> issued.
> -*/
> -   smp_wmb();
> -   } else {
> +   } else if (!gather->queued) {

If CONFIG_IOMMU_API=n:

error: ‘struct iommu_iotlb_gather’ has no member named ‘queued’

This can be reproduced using e.g. shmobile_defconfig with
CONFIG_IOMMU_SUPPORT=y
CONFIG_IOMMU_IO_PGTABLE_ARMV7S=y


> io_pgtable_tlb_add_page(iop, gather, iova, 
> blk_size);
> }
> iova += blk_size;

> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -638,14 +638,7 @@ static size_t __arm_lpae_unmap(struct 
> arm_lpae_io_pgtable *data,
> io_pgtable_tlb_flush_walk(iop, iova + i * 
> size, size,
>   
> ARM_LPAE_GRANULE(data));
> __arm_lpae_free_pgtable(data, lvl + 1, 
> iopte_deref(pte, data));
> -   } else if (iop->cfg.quirks & 
> IO_PGTABLE_QUIRK_NON_STRICT) {
> -   /*
> -* Order the PTE update against queueing the 
> IOVA, to
> -* guarantee that a flush callback from a 
> different CPU
> -* has observed it before the TLBIALL can be 
> issued.
> -*/
> -   smp_wmb();
> -   } else {
> +   } else if (!gather->queued) {

If CONFIG_IOMMU_API=n:

error: ‘struct iommu_iotlb_gather’ has no member named ‘queued’

This can be reproduced using e.g. shmobile_defconfig with
CONFIG_IOMMU_SUPPORT=y
CONFIG_IOMMU_IO_PGTABLE_LPAE=y

> io_pgtable_tlb_add_page(iop, gather, iova + i 
> * size, size);
> }
>

Perhaps "select IOMMU_API" should be added (moved from individual
drivers) to both IOMMU_IO_PGTABLE_ARMV7S and IOMMU_IO_PGTABLE_LPAE?
Or iommu_iotlb_gather.queued should not be accessed here, or the
access wrapped into a static inline helper function with a dummy for
the CONFIG_IOMMU_API=n case?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] iommu: APPLE_DART should depend on ARCH_APPLE

2021-08-10 Thread Geert Uytterhoeven
The Apple DART (Device Address Resolution Table) IOMMU is only present
on Apple ARM SoCs like the M1.  Hence add a dependency on ARCH_APPLE, to
prevent asking the user about this driver when configuring a kernel
without support for the Apple Silicon SoC family.

Fixes: 05ce9d20d699b093 ("iommu/dart: Add DART iommu driver")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dfe81da483e9e073..e908b8222e4ed679 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -292,7 +292,7 @@ config SPAPR_TCE_IOMMU
 
 config APPLE_DART
tristate "Apple DART IOMMU Support"
-   depends on ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
+   depends on ARCH_APPLE || (COMPILE_TEST && !GENERIC_ATOMIC64)
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
default ARCH_APPLE
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

2021-06-22 Thread Geert Uytterhoeven
Hi Rob,

On Tue, Jun 15, 2021 at 9:16 PM Rob Herring  wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.
>
> This condition is partially checked with the meta-schema already, but
> only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.

> Signed-off-by: Rob Herring 

> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> @@ -46,7 +46,6 @@ properties:
>
>clocks:
>  minItems: 3
> -maxItems: 5
>  items:
>- description: GMAC main clock
>- description: MAC TX clock

While resolving the conflict with commit fea99822914039c6
("dt-bindings: net: document ptp_ref clk in dwmac") in soc/for-next,
I noticed the following construct for clock-names:

  clock-names:
minItems: 3
maxItems: 6
contains:
  enum:
- stmmaceth
- mac-clk-tx
- mac-clk-rx
- ethstp
- eth-ck
- ptp_ref

Should this use items instead of enum, and drop maxItems, or is this
a valid construct to support specifying the clocks in random order?
If the latter, it does mean that the order of clock-names may not
match the order of the clock descriptions.

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages

2021-05-17 Thread Geert Uytterhoeven
On Wed, Mar 31, 2021 at 11:59 AM Geert Uytterhoeven
 wrote:
> While long fancy messages have a higher probability of being seen than
> small messages, they may scroll of the screen fast, if visible at all,
> and may still be missed.  In addition, they increase boot time and
> kernel size.
>
> The correct mechanism to increase importance of a kernel message is not
> to draw fancy boxes with more text, but to shout louder, i.e. increase
> the message's reporting level.  Making sure the administrator of the
> system is aware of such a message is a system policy, and is the
> responsability of a user-space log daemon.
>
> Fix this by increasing the reporting level from KERN_WARNING to
> KERN_CRIT, and removing irrelevant text and graphics.
>
> This reduces kernel size by ca. 0.5 KiB.
>
> Fixes: 5ead723a20e0447b ("lib/vsprintf: no_hash_pointers prints all addresses 
> as unhashed")
> Signed-off-by: Geert Uytterhoeven 

No comments?
Unlike the cases handled by the other two patches in this series,
this one cannot be configured out.

Thanks!

> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2193,20 +2193,9 @@ static int __init no_hash_pointers_enable(char *str)
>
> no_hash_pointers = true;
>
> -   
> pr_warn("**\n");
> -   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   
> **\n");
> -   pr_warn("**  
> **\n");
> -   pr_warn("** This system shows unhashed kernel memory addresses   
> **\n");
> -   pr_warn("** via the console, logs, and other interfaces. This
> **\n");
> -   pr_warn("** might reduce the security of your system.
> **\n");
> -   pr_warn("**  
> **\n");
> -   pr_warn("** If you see this message and you are not debugging
> **\n");
> -   pr_warn("** the kernel, report this immediately to your system   
> **\n");
> -   pr_warn("** administrator!   
> **\n");
> -   pr_warn("**  
> **\n");
> -   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   
> **\n");
> -   
> pr_warn("**\n");
> -
> +   pr_crit("This system shows unhashed kernel memory addresses\n");
> +   pr_crit("via the console, logs, and other interfaces. This\n");
> +   pr_crit("might reduce the security of your system.\n");
> return 0;
>  }
>  early_param("no_hash_pointers", no_hash_pointers_enable);

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-19 Thread Geert Uytterhoeven
Hi Dominique,

CC Arnd (soc_device_match() author)

On Mon, Apr 19, 2021 at 7:03 AM Dominique MARTINET
 wrote:
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo 
> > Update all the code that use soc_device_match
>
> A single patch might be difficult to accept for all components, a each
> maintainer will probably want to have a say on their subsystem?
>
> I would suggest to split these for a non-RFC version; a this will really
> need to be case-by-case handling.
>
> > because add support for soc_device_match returning -EPROBE_DEFER.
>
> (English does not parse here for me)
>
> I've only commented a couple of places in the code itself, but this
> doesn't seem to add much support for errors, just sweep the problem
> under the rug.
>
> > Signed-off-by: Alice Guo 
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> > index 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >   }
> >
> >   match = soc_device_match(sysc_soc_feat_match);
> > - if (!match)
> > + if (!match || IS_ERR(match))
> >   return 0;
>
> This function handles errors, I would recommend returning the error as
> is if soc_device_match returned one so the probe can be retried later.

Depends...

> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[] 
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)
> >  {
> > + const struct soc_device_attribute *match;
> >   const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >   u32 cpg_mode;
> >   int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device 
> > *dev)
> >   return -EINVAL;
> >   }
> >
> > - if (soc_device_match(r8a7795es1)) {
> > + match = soc_device_match(r8a7795es1);
> > + if (!IS_ERR(match) && match) {
>
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug
> problems because the driver potentially assumed the wrong device when
> it's just not ready yet.

When running on R-Car H3, there will always be a match device, as
the SoC device is registered early.

>
> >   cpg_core_nullify_range(r8a7795_core_clks,
> >  ARRAY_SIZE(r8a7795_core_clks),
> >  R8A7795_CLK_S0D2, R8A7795_CLK_S0D12);
> > [...]
> > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > index eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] = {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)
> >  {
> > + const struct soc_device_attribute *match1, *match2;
> >   unsigned int i;
> >
> >   /*
> >* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >* For Other SoCs, this returns true anyway.
> >*/
> > - if (!soc_device_match(soc_needs_opt_in))
> > + match1 = soc_device_match(soc_needs_opt_in);
> > + if (!IS_ERR(match1) && !match1)
>
> I'm not sure what you intended to do, but !match1 already means there is
> no error so the original code is identical.
>
> In this case ipmmu_device_is_allowed does not allow errors so this is
> one of the "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly,
> so in this case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
>
> ...
> This is going to need quite some more work to be acceptable, in my
> opinion, but I think it should be possible.

In general, this is very hard to do, IMHO. Some drivers may be used on
multiple platforms, some of them registering an SoC device, some of
them not registering an SoC device.  So there is no way to know the
difference between "SoC device not registered, intentionally", and
"SoC device not yet registered".

soc_device_match() should only be used as a last resort, to identify
systems that cannot be identified otherwise.  Typically this is used for
quirks, which should only be enabled on a very specific subset of
systems.  IMHO such systems 

Re: [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER

2021-04-19 Thread Geert Uytterhoeven
Hi Alice,

CC Arnd (soc_device_match() author)

On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS)  wrote:
> From: Alice Guo 
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC device is registered and no
> early_soc_dev_attr.

I'm wondering if this is really a good idea: soc_device_match() is a
last-resort low-level check, and IMHO should be made available early on,
so there is no need for -EPROBE_DEFER.

>
> Signed-off-by: Alice Guo 

Thanks for your patch!

> --- a/drivers/base/soc.c
> +++ b/drivers/base/soc.c
> @@ -110,6 +110,7 @@ static void soc_release(struct device *dev)
>  }
>
>  static struct soc_device_attribute *early_soc_dev_attr;
> +static bool soc_dev_attr_init_done = false;

Do you need this variable?

>
>  struct soc_device *soc_device_register(struct soc_device_attribute 
> *soc_dev_attr)
>  {
> @@ -157,6 +158,7 @@ struct soc_device *soc_device_register(struct 
> soc_device_attribute *soc_dev_attr
> return ERR_PTR(ret);
> }
>
> +   soc_dev_attr_init_done = true;
> return soc_dev;
>
>  out3:
> @@ -246,6 +248,9 @@ const struct soc_device_attribute *soc_device_match(
> if (!matches)
> return NULL;
>
> +   if (!soc_dev_attr_init_done && !early_soc_dev_attr)

if (!soc_bus_type.p && !early_soc_dev_attr)

> +   return ERR_PTR(-EPROBE_DEFER);
> +
> while (!ret) {
> if (!(matches->machine || matches->family ||
>   matches->revision || matches->soc_id))

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

2021-04-01 Thread Geert Uytterhoeven
Hi Steven,

On Wed, Mar 31, 2021 at 3:40 PM Steven Rostedt  wrote:
> On Wed, 31 Mar 2021 11:31:03 +0200
> Geert Uytterhoeven  wrote:
>
> > This reduces kernel size by ca. 0.5 KiB.
>
> If you are worried about size, disable tracing and it will go away
> entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in
> size overhead.

Fair enough for this particular case, as tracing can be disabled.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 1/3] iommu: Use pr_crit() instead of long fancy messages

2021-03-31 Thread Geert Uytterhoeven
While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.

This reduces kernel size by ca. 0.5 KiB.

Fixes: bad614b24293ae46 ("iommu: Enable debugfs exposure of IOMMU driver 
internals")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/iommu-debugfs.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/iommu/iommu-debugfs.c b/drivers/iommu/iommu-debugfs.c
index f0354894209648fd..c3306998de0687bd 100644
--- a/drivers/iommu/iommu-debugfs.c
+++ b/drivers/iommu/iommu-debugfs.c
@@ -32,20 +32,9 @@ void iommu_debugfs_setup(void)
 {
if (!iommu_debugfs_dir) {
iommu_debugfs_dir = debugfs_create_dir("iommu", NULL);
-   pr_warn("\n");
-   
pr_warn("*\n");
-   pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE 
NOTICE**\n");
-   pr_warn("** 
**\n");
-   pr_warn("**  IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS 
KERNEL  **\n");
-   pr_warn("** 
**\n");
-   pr_warn("** This means that this kernel is built to expose 
internal **\n");
-   pr_warn("** IOMMU data structures, which may compromise 
security on **\n");
-   pr_warn("** your system.
**\n");
-   pr_warn("** 
**\n");
-   pr_warn("** If you see this message and you are not debugging 
the   **\n");
-   pr_warn("** kernel, report this immediately to your vendor! 
**\n");
-   pr_warn("** 
**\n");
-   pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE 
NOTICE**\n");
-   
pr_warn("*\n");
+   pr_crit("IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS 
KERNEL\n");
+   pr_crit("This means that this kernel is built to expose 
internal\n");
+   pr_crit("IOMMU data structures, which may compromise security 
on\n");
+   pr_crit("your system.\n");
}
 }
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

2021-03-31 Thread Geert Uytterhoeven
While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.

This reduces kernel size by ca. 0.5 KiB.

Fixes: 2184db46e425c2b8 ("tracing: Print nasty banner when trace_printk() is in 
use")
Signed-off-by: Geert Uytterhoeven 
---
 kernel/trace/trace.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index eccb4e1187cc788e..b3a93aff01045923 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3175,20 +3175,9 @@ void trace_printk_init_buffers(void)
 
/* trace_printk() is for debug use only. Don't use it in production. */
 
-   pr_warn("\n");
-   pr_warn("**\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**  **\n");
-   pr_warn("** trace_printk() being used. Allocating extra memory.  **\n");
-   pr_warn("**  **\n");
-   pr_warn("** This means that this is a DEBUG kernel and it is **\n");
-   pr_warn("** unsafe for production use.   **\n");
-   pr_warn("**  **\n");
-   pr_warn("** If you see this message and you are not debugging**\n");
-   pr_warn("** the kernel, report this immediately to your vendor!  **\n");
-   pr_warn("**  **\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**\n");
+   pr_crit("trace_printk() being used. Allocating extra memory.\n");
+   pr_crit("This means that this is a DEBUG kernel and it is\n");
+   pr_crit("unsafe for production use.\n");
 
/* Expand the buffers to set size */
tracing_update_buffers();
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages

2021-03-31 Thread Geert Uytterhoeven
While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.

This reduces kernel size by ca. 0.5 KiB.

Fixes: 5ead723a20e0447b ("lib/vsprintf: no_hash_pointers prints all addresses 
as unhashed")
Signed-off-by: Geert Uytterhoeven 
---
 lib/vsprintf.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 9b423359bb6433d3..0293f1b89064b287 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2193,20 +2193,9 @@ static int __init no_hash_pointers_enable(char *str)
 
no_hash_pointers = true;
 
-   pr_warn("**\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**  **\n");
-   pr_warn("** This system shows unhashed kernel memory addresses   **\n");
-   pr_warn("** via the console, logs, and other interfaces. This**\n");
-   pr_warn("** might reduce the security of your system.**\n");
-   pr_warn("**  **\n");
-   pr_warn("** If you see this message and you are not debugging**\n");
-   pr_warn("** the kernel, report this immediately to your system   **\n");
-   pr_warn("** administrator!   **\n");
-   pr_warn("**  **\n");
-   pr_warn("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **\n");
-   pr_warn("**\n");
-
+   pr_crit("This system shows unhashed kernel memory addresses\n");
+   pr_crit("via the console, logs, and other interfaces. This\n");
+   pr_crit("might reduce the security of your system.\n");
return 0;
 }
 early_param("no_hash_pointers", no_hash_pointers_enable);
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 0/3] Use pr_crit() instead of long fancy messages

2021-03-31 Thread Geert Uytterhoeven
Hi all,

While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed.  In addition, they increase boot time and
kernel size.

The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level.  Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.

This series increases the reporting level of such messages from
KERN_WARNING to KERN_CRIT, and removes irrelevant text and graphics.
It was made against linux-next, but applies to v5.12-rc5 with an offset
for the last patch.

Each of these patches reduces kernel size by ca. 0.5 KiB.

Thanks for your comments!

Geert Uytterhoeven (3):
  iommu: Use pr_crit() instead of long fancy messages
  tracing: Use pr_crit() instead of long fancy messages
  lib/vsprintf: Use pr_crit() instead of long fancy messages

 drivers/iommu/iommu-debugfs.c | 19 ---
 kernel/trace/trace.c  | 17 +++--
 lib/vsprintf.c| 17 +++--
 3 files changed, 10 insertions(+), 43 deletions(-)

-- 
2.25.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] clk: Align provider-specific CLK_* bit definitions

2021-03-31 Thread Geert Uytterhoeven
The definition of CLK_MULTIPLIER_ROUND_CLOSEST is not aligned to the two
bit definitions next to it.  A deeper inspection reveals that the
alignment of CLK_MULTIPLIER_ROUND_CLOSEST does match the most common
alignment.

Align the bit definitions for the various provider types throughout the
file at 40 columns, to increase uniformity.

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/clk-provider.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 58f6fe866ae9b797..8f37829565f9640e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -342,7 +342,7 @@ struct clk_fixed_rate {
unsigned long   flags;
 };
 
-#define CLK_FIXED_RATE_PARENT_ACCURACY BIT(0)
+#define CLK_FIXED_RATE_PARENT_ACCURACY BIT(0)
 
 extern const struct clk_ops clk_fixed_rate_ops;
 struct clk_hw *__clk_hw_register_fixed_rate(struct device *dev,
@@ -984,8 +984,8 @@ struct clk_fractional_divider {
 
 #define to_clk_fd(_hw) container_of(_hw, struct clk_fractional_divider, hw)
 
-#define CLK_FRAC_DIVIDER_ZERO_BASEDBIT(0)
-#define CLK_FRAC_DIVIDER_BIG_ENDIANBIT(1)
+#define CLK_FRAC_DIVIDER_ZERO_BASEDBIT(0)
+#define CLK_FRAC_DIVIDER_BIG_ENDIANBIT(1)
 
 extern const struct clk_ops clk_fractional_divider_ops;
 struct clk *clk_register_fractional_divider(struct device *dev,
@@ -1033,9 +1033,9 @@ struct clk_multiplier {
 
 #define to_clk_multiplier(_hw) container_of(_hw, struct clk_multiplier, hw)
 
-#define CLK_MULTIPLIER_ZERO_BYPASS BIT(0)
+#define CLK_MULTIPLIER_ZERO_BYPASS BIT(0)
 #define CLK_MULTIPLIER_ROUND_CLOSEST   BIT(1)
-#define CLK_MULTIPLIER_BIG_ENDIAN  BIT(2)
+#define CLK_MULTIPLIER_BIG_ENDIAN  BIT(2)
 
 extern const struct clk_ops clk_multiplier_ops;
 
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 4/8] of: property: Add fw_devlink support for optional properties

2021-02-10 Thread Geert Uytterhoeven
Hi Saravana,

CC iommu

On Tue, Feb 9, 2021 at 10:55 PM Saravana Kannan  wrote:
> On Tue, Feb 9, 2021 at 1:33 PM Rob Herring  wrote:
> > On Fri, Feb 05, 2021 at 02:26:40PM -0800, Saravana Kannan wrote:
> > > Not all DT bindings are mandatory bindings. Add support for optional DT
> > > bindings and mark iommus, iommu-map, dmas as optional DT bindings.
> >
> > I don't think we can say these are optional or not. It's got to be a
> > driver decision somehow.
>
> Right, so maybe the word "optional" isn't a good name for it. I can
> change that if you want.
>
> The point being, fw_devlink can't block the probe of this driver based
> on iommu property. We let the driver decide if it wants to
> -EPROBE_DEFER or not or however it wants to handle this.

The driver cannot make that decision, cfr. below.

> > For example, if IOMMU is optional, what happens with this sequence:
> >
> > driver probes without IOMMU
> > driver calls dma_map_?()
> > IOMMU driver probes
> > h/w accesses DMA buffer --> BOOM!

Does it really behave that way? Or does it continue without IOMMU?

> Right. But how is this really related to fw_devlink? AFAICT, this is
> an issue even today. If the driver needs the IOMMU, then it needs to
> make sure the IOMMU has probed? What am I missing?

Individual I/O (IOMMU slave) drivers are completely unaware of the
presence or absence of an IOMMU; they just use the DMA API, which is the
same regardless of an IOMMU being used or not.
While for GPIO/IRQ/CLK/DMA/... have request/get_{gpio,irq,clk,dma,...}
APIs for a driver to get a reference, which can return -EPROBE_DEFER, no
such thing exists for IOMMUs.  This is handled by the IOMMU core
instead.

Using the IOMMU or not is more like a system policy decision.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas

2021-02-03 Thread Geert Uytterhoeven
Hi Rob,

On Wed, Feb 3, 2021 at 4:55 PM Rob Herring  wrote:
> On Wed, Feb 03, 2021 at 09:01:23AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Feb 2, 2021 at 9:55 PM Rob Herring  wrote:
> > > Properties in if/then schemas weren't getting checked by the meta-schemas.
> > > Enabling meta-schema checks finds several errors.
> > >
> > > The use of an 'items' schema (as opposed to the list form) is wrong in
> > > some cases as it applies to all entries. 'contains' is the correct schema
> > > to use in the case of multiple entries.
> >
> > > Signed-off-by: Rob Herring 
> >
> > Thanks for your patch!
> >
> > > --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> > > @@ -81,9 +81,8 @@ properties:
> > >  if:
> > >properties:
> > >  compatible:
> > > -  items:
> > > -enum:
> > > -  - renesas,usb2-phy-r7s9210
> > > +  contains:
> > > +const: renesas,usb2-phy-r7s9210
> >
> > Single entry, so "contains" not needed?
>
> No, you are misunderstanding how these work. 'contains' means at least
> one entry in an array passes with the subschema. In this case,
> 'renesas,usb2-phy-r7s9210' must appear somewhere in the 'compatible'
> values. (Before, it said *every* entry must be
> 'renesas,usb2-phy-r7s9210'.) As there is a fallback compatible, we need
> 'contains'.
>
> > > --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> > > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> > > @@ -76,11 +76,10 @@ required:
> > >  if:
> > >properties:
> > >  compatible:
> > > -  items:
> > > -enum:
> > > -  - renesas,pfc-r8a73a4
> > > -  - renesas,pfc-r8a7740
> > > -  - renesas,pfc-sh73a0
> > > +  enum:
> > > +- renesas,pfc-r8a73a4
> > > +- renesas,pfc-r8a7740
> > > +- renesas,pfc-sh73a0
> >
> > Missing "contains"?
>
> No. In this case, 'compatible' is always a single entry, so no
> 'contains' needed (but would work). If compatible is one of these 3
> strings, then the 'if' is true.
>
> The original way would actually work in this case (i.e. is valid
> json-schema), but we require 'items' to have a size (maxItems/minItems)
> in our meta-schema.

Thanks for the explanation!
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas

2021-02-03 Thread Geert Uytterhoeven
Hi Rob,

On Tue, Feb 2, 2021 at 9:55 PM Rob Herring  wrote:
> Properties in if/then schemas weren't getting checked by the meta-schemas.
> Enabling meta-schema checks finds several errors.
>
> The use of an 'items' schema (as opposed to the list form) is wrong in
> some cases as it applies to all entries. 'contains' is the correct schema
> to use in the case of multiple entries.

> Signed-off-by: Rob Herring 

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> @@ -81,9 +81,8 @@ properties:
>  if:
>properties:
>  compatible:
> -  items:
> -enum:
> -  - renesas,usb2-phy-r7s9210
> +  contains:
> +const: renesas,usb2-phy-r7s9210

Single entry, so "contains" not needed?

> --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> @@ -76,11 +76,10 @@ required:
>  if:
>properties:
>  compatible:
> -  items:
> -enum:
> -  - renesas,pfc-r8a73a4
> -  - renesas,pfc-r8a7740
> -  - renesas,pfc-sh73a0
> +  enum:
> +- renesas,pfc-r8a73a4
> +- renesas,pfc-r8a7740
> +    - renesas,pfc-sh73a0

Missing "contains"?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


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

2020-11-16 Thread Geert Uytterhoeven
Hi Thomas,

On Thu, Nov 12, 2020 at 8:16 PM 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 assigned and then issues
> compat MSI messages which get caught by the interrupt remapping unit.
>
> Cure that by inheriting the irq domain from the physical function
> device.
>
> That's a temporary workaround. The correct fix is to inherit the irq domain
> from the bus, but that's a larger effort which needs quite some other
> changes to the way how x86 manages PCI and MSI domains.
>
> Fixes: 85a8dfc57a0b ("iommm/vt-d: Store irq domain in struct device")
> Reported-by: Jason Gunthorpe 
> Signed-off-by: Thomas Gleixner 
> ---
>  drivers/iommu/intel/dmar.c |   19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -333,6 +333,11 @@ static void  dmar_pci_bus_del_dev(struct
> dmar_iommu_notify_scope_dev(info);
>  }
>
> +static inline void vf_inherit_msi_domain(struct pci_dev *pdev)
> +{
> +   dev_set_msi_domain(>dev, 
> dev_get_msi_domain(>physfn->dev));

If CONFIG_PCI_ATS is not set:

error: 'struct pci_dev' has no member named 'physfn'

http://kisskb.ellerman.id.au/kisskb/buildresult/14400927/

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [GIT PULL] dma-mapping fix for 5.10

2020-11-02 Thread Geert Uytterhoeven
Hi Linus,

On Sat, Oct 31, 2020 at 8:51 PM Linus Torvalds
 wrote:
> On Sat, Oct 31, 2020 at 2:40 AM Christoph Hellwig  wrote:
> > dma-mapping fix for 5.10:
> >
> >  - fix an integer overflow on 32-bit platforms in the new DMA range code
> >(Geert Uytterhoeven)
>
> So this is just a stylistic nit, and has no impact on this pull (which
> I've done). But looking at the patch, it triggers one of my "this is
> wrong" patterns.
>
> In particular, this:
>
> u64 dma_start = 0;
> ...
> for (dma_start = ~0ULL; r->size; r++) {
>
> is actually completely bogus in theory, and it's a horribly horribly
> bad pattern to have.
>
> The thing that I hate about that parttern is "~0ULL", which is simply wrong.
>
> The correct pattern for "all bits set" is ~0. NOTHING ELSE. No extra
> letters at the end.
>
> Why? Because using an unsigned type is wrong, and will not extend the
> bits up to a potentially bigger size.
>
> So adding that "ULL" is not just three extra characters to type, it
> actually _detracts_ from the code and makes it more fragile and
> potentially wrong.
>
> It so happens, that yes, in the kernel, "ull" us 64-bit, and you get
> the right results. So the code _works_. But it's wrong, and it now
> requires that the types match exactly (ie it would not be broken if
> somebody ever were to say "I want to use use 128-bit dma addresses and
> u128").

Thanks, you're right, the "ULL" suffix is not needed, and could cause
future issues.

> Another example is using "~0ul", which would give different results on
> a 32-bit kernel and a 64-bit kernel. Again: DON'T DO THAT.

Definitely.

> I repeat: the right thing to do for "all bits set" is just a plain ~0
> or -1. Either of those are fine (technically assumes a 2's complement
> machine, but let's just be honest: that's a perfectly fine assumption,
> and -1 might be preferred by some because it makes that sign extension
> behavior of the integer constant more obvious).

"-1" definitely causes warnings, depending on your compiler (not with
the gcc 9.3.0 I'm currently using, though).

> Don't try to do anything clever or anything else, because it's going
> to be strictly worse.
>
> The old code that that patch removed was "technically correct", but
> just pointless, and actually shows the problem:
>
> for (dma_start = ~(dma_addr_t)0; r->size; r++) {
>
> the above is indeed a correct way to say "I want all bits set in a
> dma_addr_t", but while correct, it is - once again - strictly inferior
> to just using "~0".

Obviously I was misled by the old code, and instead of changing
the cast, I replaced the cast ("casts are evil") by a suffix. Doh.

Any, I've just sent a patch. Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu: Kconfig: Update help description for IPMMU_VMSA config

2020-09-14 Thread Geert Uytterhoeven
On Fri, Sep 11, 2020 at 12:19 PM Lad Prabhakar
 wrote:
> ipmmu-vmsa driver is also used on Renesas RZ/G{1,2} Soc's, update the
> same to reflect the help description for IPMMU_VMSA config.

... update the help description for the IPMMU_VMSA config symbol to reflect
this?

>
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Chris Paterson 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/2] ARM: dts: r8a7742: Add IPMMU DT nodes

2020-09-03 Thread Geert Uytterhoeven
On Tue, Aug 25, 2020 at 4:19 PM Lad Prabhakar
 wrote:
> Add the five IPMMU instances found in the r8a7742 to DT with a disabled
> status.
>
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Chris Paterson 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.10.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: Add r8a7742 support

2020-09-03 Thread Geert Uytterhoeven
On Tue, Aug 25, 2020 at 4:19 PM Lad Prabhakar
 wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> No driver change is needed due to the fallback compatible value
> "renesas,ipmmu-vmsa".
>
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Chris Paterson 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: iommu: renesas,ipmmu-vmsa: Sort compatible string in increasing number of the SoC

2020-08-10 Thread Geert Uytterhoeven
On Sun, Aug 9, 2020 at 9:35 PM Lad Prabhakar
 wrote:
> Sort the items in the compatible string list in increasing number of SoC.
>
> Signed-off-by: Lad Prabhakar 

As my previous tag was conditional on fixing the sort order:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 9/9] arm64: dts: renesas: r8a774e1: Add Ethernet AVB node

2020-07-15 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:36 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> This patch adds the SoC specific part of the Ethernet AVB
> device tree node.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.9.

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 7/9] arm64: dts: renesas: r8a774e1: Add GPIO device nodes

2020-07-15 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> Add GPIO device nodes to the DT of the r8a774e1 SoC.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.9.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 5/9] arm64: dts: renesas: r8a774e1: Add SYS-DMAC device nodes

2020-07-15 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> Add sys-dmac[0-2] device nodes for RZ/G2H (R8A774E1) SoC.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.9.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/9] arm64: dts: renesas: r8a774e1: Add IPMMU device nodes

2020-07-15 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> Add RZ/G2H (R8A774E1) IPMMU nodes.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in renesas-devel for v5.9.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/2] iommu/ipmmu-vmsa: Add an entry for r8a77961 in soc_rcar_gen3[]

2020-07-15 Thread Geert Uytterhoeven
On Tue, Jul 14, 2020 at 12:21 PM Lad Prabhakar
 wrote:
> Add an entry for r8a77961 in soc_rcar_gen3[] list so that we dont
> enable iommu unconditionally.
>
> Fixes: 17fe161816398 ("iommu/renesas: Add support for r8a77961")
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/2] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code

2020-07-15 Thread Geert Uytterhoeven
On Tue, Jul 14, 2020 at 12:21 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/9] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code

2020-07-14 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Tue, Jul 14, 2020 at 1:42 PM Yoshihiro Shimoda
 wrote:
> > From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM
> > On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
> >  wrote:
> > > On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven  
> > > wrote:
> > > > On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> > > Also the recent patch to add
> > > "r8a77961" just adds to soc_rcar_gen3_whitelist.
> >
> > Oops, commit 17fe16181639801b ("iommu/renesas: Add support for r8a77961")
> > did it wrong, too.
>
> Thank you for the point it out. We should add r8a77961 to the soc_rcar_gen3[].
> However, I don't know why I could not realize this issue...
> So, I investigated this a little and then, IIUC, glob_match() which
> soc_device_match() uses seems to return true, if *pat = "r8a7796" and *str = 
> "r8a77961".

Are you sure about this?
I enabled CONFIG_GLOB_SELFTEST, and globtest succeeded.
It does test glob_match("a", "aa"), which is a similar test.

To be 100% sure, I added:

--- a/lib/globtest.c
+++ b/lib/globtest.c
@@ -59,6 +59,7 @@ static char const glob_tests[] __initconst =
"1" "a\0" "a\0"
"0" "a\0" "b\0"
    "0" "a\0" "aa\0"
+   "0" "r8a7796\0" "r8a77961\0"
"0" "a\0" "\0"
"1" "\0" "\0"
"0" "\0" "a\0"

and it still succeeded.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/9] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code

2020-07-14 Thread Geert Uytterhoeven
Hi Prabhakar,

On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar
 wrote:
> On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven  
> wrote:
> > On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
> >  wrote:
> > > From: Marian-Cristian Rotariu 
> > >
> > > Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
> > >
> > > Signed-off-by: Marian-Cristian Rotariu 
> > > 
> > > Signed-off-by: Lad Prabhakar 
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > @@ -751,6 +751,7 @@ static const struct soc_device_attribute 
> > > soc_rcar_gen3[] = {
> > >  static const struct soc_device_attribute soc_rcar_gen3_whitelist[] = {
> > > { .soc_id = "r8a774b1", },
> > > { .soc_id = "r8a774c0", },
> > > +   { .soc_id = "r8a774e1", },
> >
> > Adding an entry to soc_rcar_gen3_whitelist[] doesn't do anything, unless
> > you also add the same entry to soc_rcar_gen3[].
> >
> I think the comment "For R-Car Gen3 use a white list to opt-in slave
> devices." is misleading.  Booting through the kernel I do see iommu
> groups (attached is the logs).

Indeed. Without an entry in soc_rcar_gen3[], the IPMMU is enabled
unconditionally, and soc_rcar_gen3_whitelist[] is ignored.
That's why you want an entry in both, unless you have an R-Car Gen3
SoC where the IPMMU works correctly with all slave devices present.
Perhaps soc_rcar_gen3[] should be renamed to soc_rcar_gen3_greylist[]
(or soc_rcar_gen3_maybelist[]) to make this clear?

> Also the recent patch to add
> "r8a77961" just adds to soc_rcar_gen3_whitelist.

Oops, commit 17fe16181639801b ("iommu/renesas: Add support for r8a77961")
did it wrong, too.

> > > { .soc_id = "r8a7795", .revision = "ES3.*" },
> > > { .soc_id = "r8a77961", },
> > > { .soc_id = "r8a77965", },

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/9] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code

2020-07-14 Thread Geert Uytterhoeven
Hi Prabhakar,

On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> Add support for RZ/G2H (R8A774E1) SoC IPMMUs.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Thanks for your patch!

> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -751,6 +751,7 @@ static const struct soc_device_attribute soc_rcar_gen3[] 
> = {
>  static const struct soc_device_attribute soc_rcar_gen3_whitelist[] = {
> { .soc_id = "r8a774b1", },
> { .soc_id = "r8a774c0", },
> +   { .soc_id = "r8a774e1", },

Adding an entry to soc_rcar_gen3_whitelist[] doesn't do anything, unless
you also add the same entry to soc_rcar_gen3[].

> { .soc_id = "r8a7795", .revision = "ES3.*" },
> { .soc_id = "r8a77961", },
> { .soc_id = "r8a77965", },
> @@ -963,6 +964,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> }, {
> .compatible = "renesas,ipmmu-r8a774c0",
> .data = _features_rcar_gen3,
> +   }, {
> +   .compatible = "renesas,ipmmu-r8a774e1",
> +   .data = _features_rcar_gen3,
>     }, {
>     .compatible = "renesas,ipmmu-r8a7795",
> .data = _features_rcar_gen3,

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 8/9] dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC

2020-07-14 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:36 PM Lad Prabhakar
 wrote:
> From: Marian-Cristian Rotariu 
>
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Marian-Cristian Rotariu 
> 
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 6/9] dt-bindings: gpio: renesas, rcar-gpio: Add r8a774e1 support

2020-07-14 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
> relevant dt-bindings.
>
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 4/9] dt-bindings: dma: renesas,rcar-dmac: Document R8A774E1 bindings

2020-07-14 Thread Geert Uytterhoeven
On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> Renesas RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible
> DMA controllers, therefore document RZ/G2H specific bindings.
>
> Signed-off-by: Lad Prabhakar 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/9] dt-bindings: iommu: renesas, ipmmu-vmsa: Add r8a774e1 support

2020-07-14 Thread Geert Uytterhoeven
Hi Prabhakar,

On Mon, Jul 13, 2020 at 11:35 PM Lad Prabhakar
 wrote:
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Lad Prabhakar 

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> @@ -32,6 +32,7 @@ properties:
>- enum:
>- renesas,ipmmu-r8a774a1 # RZ/G2M
>- renesas,ipmmu-r8a774b1 # RZ/G2N
> +  - renesas,ipmmu-r8a774e1 # RZ/G2H
>- renesas,ipmmu-r8a774c0 # RZ/G2E

Please preserve alphabetical sort order.

>- renesas,ipmmu-r8a7795  # R-Car H3
>- renesas,ipmmu-r8a7796  # R-Car M3-W

With the above fixed:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: SUN50I_IOMMU should depend on HAS_DMA

2020-06-29 Thread Geert Uytterhoeven
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):

drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
dma-iommu.c:(.text+0x92e): undefined reference to `dma_pgprot'

IOMMU_DMA must not be selected, unless HAS_DMA=y.

Hence fix this by making SUN50I_IOMMU depend on HAS_DMA.

Fixes: 4100b8c229b32835 ("iommu: Add Allwinner H6 IOMMU driver")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 6dc49ed8377a5c12..b0f308cb7f7c2fc2 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -305,6 +305,7 @@ config ROCKCHIP_IOMMU
 
 config SUN50I_IOMMU
bool "Allwinner H6 IOMMU Support"
+   depends on HAS_DMA
depends on ARCH_SUNXI || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems

2020-06-21 Thread Geert Uytterhoeven
Hi Günter,

On Sat, Jun 20, 2020 at 10:09 PM Guenter Roeck  wrote:
> On Mon, Jun 08, 2020 at 03:22:17PM +0200, Geert Uytterhoeven wrote:
> > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> > memory pools are much larger than intended (e.g. 2 MiB instead of 128
> > KiB on a 256 MiB system).
> >
> > Fix this by correcting the calculation of the number of GiBs of RAM in
> > the system.  Invert the order of the min/max operations, to keep on
> > calculating in pages until the last step, which aids readability.
> >
> > Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool 
> > size with memory capacity")
> > Signed-off-by: Geert Uytterhoeven 
> > Acked-by: David Rientjes 
>
> This patch results in a boot failure in some of my powerpc boot tests,
> specifically those testing boots from mptsas1068 devices. Error message:
>
> mptsas :00:02.0: enabling device ( -> 0002)
> mptbase: ioc0: Initiating bringup
> ioc0: LSISAS1068 A0: Capabilities={Initiator}
> mptbase: ioc0: ERROR - Unable to allocate Reply, Request, Chain Buffers!
> mptbase: ioc0: ERROR - didn't initialize properly! (-3)
> mptsas: probe of :00:02.0 failed with error -3
>
> Configuration is bamboo:44x/bamboo_defconfig plus various added drivers.
> Qemu command line is
>
> qemu-system-ppc -kernel vmlinux -M bamboo \
>  -m 256 -no-reboot -snapshot -device mptsas1068,id=scsi \
>  -device scsi-hd,bus=scsi.0,drive=d0,wwn=0x5000c50015ea71ac -drive \
>  file=rootfs.ext2,format=raw,if=none,id=d0 \
>  --append "panic=-1 slub_debug=FZPUA root=/dev/sda  mem=256M 
> console=ttyS0" \
>  -monitor none -nographic
>
> canyonlands_defconfig with sam460ex machine and otherwise similar command line
> fails as well.
>
> Reverting this patch fixes the problem.

This looks like the minimum value of 128 KiB is not sufficient, and the
bug is in the intention of 1d659236fb43c4d2 ("dma-pool: scale the
default DMA coherent pool size with memory capacity")?
Before, there was a single pool of (fixed) 256 KiB size, now there are
up to three coherent pools (DMA, DMA32, and kernel), albeit of smaller
size (128 KiB each).

Can you print the requested size in drivers/message/fusion/mptbase.c:
PrimeIocFifos()?
Does replacing all SZ_128K by SZ_256K in my patch help?
That would waste^H^H^H^H^Hallocate 256 KiB or 512 KiB more, though.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a77961 support

2020-06-18 Thread Geert Uytterhoeven
On Thu, Jun 11, 2020 at 1:11 PM Yoshihiro Shimoda
 wrote:
> Add support for r8a77961 (R-Car M3-W+).
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v2] dma-pool: Fix too large DMA pools on medium systems

2020-06-08 Thread Geert Uytterhoeven
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 128
KiB on a 256 MiB system).

Fix this by correcting the calculation of the number of GiBs of RAM in
the system.  Invert the order of the min/max operations, to keep on
calculating in pages until the last step, which aids readability.

Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size 
with memory capacity")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Improve readability:
  - Divide by (SZ_1G / SZ_128K) instead of using a shift,
  - Invert min/max order to keep calculating in pages until the last
step.
---
 kernel/dma/pool.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 35bb51c31fff370f..8cfa01243ed27b6f 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -175,10 +175,9 @@ static int __init dma_atomic_pool_init(void)
 * sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1.
 */
if (!atomic_pool_size) {
-   atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) *
-   SZ_128K;
-   atomic_pool_size = min_t(size_t, atomic_pool_size,
-1 << (PAGE_SHIFT + MAX_ORDER-1));
+   unsigned long pages = totalram_pages() / (SZ_1G / SZ_128K);
+   pages = min_t(unsigned long, pages, MAX_ORDER_NR_PAGES);
+   atomic_pool_size = max_t(size_t, pages << PAGE_SHIFT, SZ_128K);
}
INIT_WORK(_pool_work, atomic_pool_work_fn);
 
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dma-pool: Fix too large DMA pools on medium systems

2020-06-08 Thread Geert Uytterhoeven
Hi Robin,

On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy  wrote:
> On 2020-06-08 09:52, Geert Uytterhoeven wrote:
> > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> > memory pools are much larger than intended (e.g. 2 MiB instead of 128
> > KiB on a 256 MiB system).
> >
> > Fix this by correcting the calculation of the number of GiBs of RAM in
> > the system.
> >
> > Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool 
> > size with memory capacity")
> > Signed-off-by: Geert Uytterhoeven 

> > --- a/kernel/dma/pool.c
> > +++ b/kernel/dma/pool.c
> > @@ -175,8 +175,8 @@ static int __init dma_atomic_pool_init(void)
> >* sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1.
> >*/
> >   if (!atomic_pool_size) {
> > - atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) *
> > - SZ_128K;
> > + unsigned long gigs = totalram_pages() >> (30 - PAGE_SHIFT);
> > + atomic_pool_size = max(gigs, 1UL) * SZ_128K;
> >   atomic_pool_size = min_t(size_t, atomic_pool_size,
> >1 << (PAGE_SHIFT + MAX_ORDER-1));
> >   }
>
> Nit: although this probably is right, it seems even less readable than

">> (x - PAGE_SHIFT)" is a commonly used construct in the kernel.

> the broken version (where at least some at-a-glance 'dimensional
> analysis' flags up "(number of pages) >> PAGE_SHIFT" as rather
> suspicious). How about a something a little more self-explanatory, e.g.:
>
> unsigned long pages = totalram_pages() * SZ_128K / SZ_1GB;

That multiplication will overflow on 32-bit systems (perhaps even on
large 64-bit systems; any 47-bit addressing?).

unsigned long pages = totalram_pages() / (SZ_1GB / SZ_128K);

> atomic_pool_size = min(pages, MAX_ORDER_NR_PAGES) << PAGE_SHIFT;
> atomic_pool_size = max_t(size_t, atomic_pool_size, SZ_128K);

I agree this part is an improvement.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] dma-pool: Fix too large DMA pools on medium systems

2020-06-08 Thread Geert Uytterhoeven
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 128
KiB on a 256 MiB system).

Fix this by correcting the calculation of the number of GiBs of RAM in
the system.

Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size 
with memory capacity")
Signed-off-by: Geert Uytterhoeven 
---
 kernel/dma/pool.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 35bb51c31fff370f..1c7eab2cc0498003 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -175,8 +175,8 @@ static int __init dma_atomic_pool_init(void)
 * sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1.
 */
if (!atomic_pool_size) {
-   atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) *
-   SZ_128K;
+   unsigned long gigs = totalram_pages() >> (30 - PAGE_SHIFT);
+   atomic_pool_size = max(gigs, 1UL) * SZ_128K;
atomic_pool_size = min_t(size_t, atomic_pool_size,
 1 << (PAGE_SHIFT + MAX_ORDER-1));
}
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 18/25] drm: rcar-du: fix common struct sg_table related issues

2020-05-05 Thread Geert Uytterhoeven
Hi Marek,

On Tue, May 5, 2020 at 10:48 AM Marek Szyprowski
 wrote:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with the original number of the entries passed to dma_map_sg. The
> sg_table->nents in turn holds the result of the dma_map_sg call as stated
> in include/linux/scatterlist.h. A common mistake was to ignore a result
> of the dma_map_sg function and don't use the sg_table->orig_nents at all.
>
> To avoid such issues, lets use common dma-mapping wrappers operating
> directly on the struct sg_table objects and adjust references to the
> nents and orig_nents respectively.
>
> Signed-off-by: Marek Szyprowski 
> ---
> For more information, see '[PATCH v3 00/25] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread: https://lkml.org/lkml/2020/5/5/187

For the modern lore-users:
https://lore.kernel.org/r/20200505083926.28503-1-m.szyprow...@samsung.com/

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

2020-04-21 Thread Geert Uytterhoeven
On Tue, Apr 21, 2020 at 7:16 AM Yoshihiro Shimoda
 wrote:
> Convert Renesas VMSA-Compatible IOMMU bindings documentation
> to json-schema.
>
> Note that original documentation doesn't mention renesas,ipmmu-vmsa
> for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
> Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
> section.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 24/29] mm: remove __vmalloc_node_flags_caller

2020-04-20 Thread Geert Uytterhoeven
Hi Christoph,

On Tue, Apr 14, 2020 at 3:21 PM Christoph Hellwig  wrote:
> Just use __vmalloc_node instead which gets and extra argument.  To be
> able to to use __vmalloc_node in all caller make it available outside
> of vmalloc and implement it in nommu.c.
>
> Signed-off-by: Christoph Hellwig 
> Acked-by: Peter Zijlstra (Intel) 

One more nommu failure below...

> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -150,8 +150,8 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask)
>  }
>  EXPORT_SYMBOL(__vmalloc);
>
> -void *__vmalloc_node_flags_caller(unsigned long size, int node, gfp_t flags,
> -   void *caller)
> +void *__vmalloc_node(unsigned long size, unsigned long align, gfp_t gfp_mask,
> +   int node, const void *caller)
>  {
> return __vmalloc(size, flags);

On Mon, Apr 20, 2020 at 10:39 AM  wrote:
> FAILED linux-next/m5272c3_defconfig/m68k-gcc8 Mon Apr 20, 18:38
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14213623/
>
> mm/nommu.c:164:25: error: 'flags' undeclared (first use in this function); 
> did you mean 'class'?

"return __vmalloc(size, gfp_mask);"

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 26/29] mm: remove vmalloc_user_node_flags

2020-04-20 Thread Geert Uytterhoeven
Hi Christoph,

On Tue, Apr 14, 2020 at 3:22 PM Christoph Hellwig  wrote:
> Open code it in __bpf_map_area_alloc, which is the only caller.  Also
> clean up __bpf_map_area_alloc to have a single vmalloc call with
> slightly different flags instead of the current two different calls.
>
> For this to compile for the nommu case add a __vmalloc_node_range stub
> to nommu.c.

Apparently your nommu-cross-compilers are in quarantaine? ;-)

> Signed-off-by: Christoph Hellwig 
> Acked-by: Peter Zijlstra (Intel) 
> Acked-by: Johannes Weiner 

> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -150,6 +150,14 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask)
>  }
>  EXPORT_SYMBOL(__vmalloc);
>
> +void *__vmalloc_node_range(unsigned long size, unsigned long align,
> +   unsigned long start, unsigned long end, gfp_t gfp_mask,
> +   pgprot_t prot, unsigned long vm_flags, int node,
> +   const void *caller)
> +{
> +   return __vmalloc(size, flags);

On Mon, Apr 20, 2020 at 10:39 AM  wrote:
> FAILED linux-next/m5272c3_defconfig/m68k-gcc8 Mon Apr 20, 18:38
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14213623/
>
> mm/nommu.c:158:25: error: 'flags' undeclared (first use in this function); 
> did you mean 'class'?

"return __vmalloc(size, gfp_mask);", I assume?

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

2020-04-17 Thread Geert Uytterhoeven
Hi Shimoda-san,

(not related to the json-schema conversion)

On Fri, Apr 17, 2020 at 9:03 AM Yoshihiro Shimoda
 wrote:
> +  renesas,ipmmu-main:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> +  Reference to the main IPMMU instance in two cells. The first cell is
> +  a phandle to the main IPMMU and the second cell is the interrupt bit
> +  number associated with the particular cache IPMMU device. The interrupt
> +  bit number needs to match the main IPMMU IMSSTR register. Only used by
> +  cache IPMMU instances.

Note: Apparently the master IPMMU instance has an interrupt bit number
in the MMU Interrupt Status Register, too.  This is currently not
described in DT, as no renesas,ipmmu-main property is present for the
master instance.  Currently this doesn't matter, as the driver doesn't
use the interrupt bits at all.

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema

2020-04-17 Thread Geert Uytterhoeven
On Fri, Apr 17, 2020 at 9:03 AM Yoshihiro Shimoda
 wrote:
> Convert Renesas VMSA-Compatible IOMMU bindings documentation
> to json-schema.
>
> Note that original documentation doesn't mention renesas,ipmmu-vmsa
> for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
> Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
> section.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bndings: iommu: renesas, ipmmu-vmsa: convert to json-schema

2020-04-16 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Thu, Apr 16, 2020 at 11:56 AM Yoshihiro Shimoda
 wrote:
> > From: Geert Uytterhoeven, Sent: Wednesday, April 15, 2020 11:21 PM
> > On Tue, Apr 14, 2020 at 2:26 AM Yoshihiro Shimoda
> >  wrote:
> > > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > > to json-schema.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> >
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml

> > > +  renesas,ipmmu-main:
> > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > > +description:
> > > +  Reference to the main IPMMU instance in two cells. The first cell 
> > > is
> > > +  a phandle to the main IPMMU and the second cell is the interrupt 
> > > bit
> > > +  number associated with the particular cache IPMMU device. The 
> > > interrupt
> > > +  bit number needs to match the main IPMMU IMSSTR register. Only 
> > > used by
> > > +  cache IPMMU instances.
> >
> > This property is not valid only on R-Car Gen2 and R-Mobile APE6.
>
> That sounds good. But, since ipmmu_mm on R-Car Gen3 also is not valid,
> we cannot use compatible property for detecting it.

What do you mean by "ipmmu_mm is not valid"?

> However, I realized renesas,ipmmu-main is only used by "cache IPMMU"
> and "cache IPMMU" doesn't have interrupts property. So,
> I described the following schema and then it seems success.
> --
> if:
>   properties:
> interrupts: false
> then:
>   required:
> - renesas,ipmmu-main

But all other nodes should have interrupts properties, right?
So they are mutually exclusive:

  oneOf:
 - required:
 - interrupts
- required:
- renesas,ipmmu-main

> Especially, I could find missing renesas,ipmmu-main property on r8a77980.dtsi
> like below :)  So, I'll make and submit a fixing r8a77980.dtsi patch later 
> (maybe tomorrow).

Good! ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bndings: iommu: renesas, ipmmu-vmsa: convert to json-schema

2020-04-15 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Tue, Apr 14, 2020 at 2:26 AM Yoshihiro Shimoda
 wrote:
> Convert Renesas VMSA-Compatible IOMMU bindings documentation
> to json-schema.
>
> Signed-off-by: Yoshihiro Shimoda 

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas VMSA-Compatible IOMMU
> +
> +maintainers:
> +  - Yoshihiro Shimoda 
> +
> +description:
> +  The IPMMU is an IOMMU implementation compatible with the ARM VMSA page 
> tables.
> +  It provides address translation for bus masters outside of the CPU, each
> +  connected to the IPMMU through a port called micro-TLB.
> +
> +properties:
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - renesas,ipmmu-r8a7743  # RZ/G1M
> +  - renesas,ipmmu-r8a7744  # RZ/G1N
> +  - renesas,ipmmu-r8a7745  # RZ/G1E
> +  - renesas,ipmmu-r8a7790  # R-Car H2
> +  - renesas,ipmmu-r8a7791  # R-Car M2-W
> +  - renesas,ipmmu-r8a7793  # R-Car M2-N
> +  - renesas,ipmmu-r8a7794  # R-Car E2
> +  - renesas,ipmmu-r8a7795  # R-Car H3
> +  - const: renesas,ipmmu-vmsa  # R-Car Gen2 or RZ/G1
> +  - items:
> +  - enum:
> +  - renesas,ipmmu-r8a73a4  # R-Mobile APE6

I believe the R-Mobile APE6 IPMMU is similar to the R-Car Gen2 IPMMU,
and thus belongs in the section above instead.

> +  - renesas,ipmmu-r8a774a1 # RZ/G2M
> +  - renesas,ipmmu-r8a774b1 # RZ/G2N
> +  - renesas,ipmmu-r8a774c0 # RZ/G2E
> +  - renesas,ipmmu-r8a7796  # R-Car M3-W
> +  - renesas,ipmmu-r8a77965 # R-Car M3-N
> +  - renesas,ipmmu-r8a77970 # R-Car V3M
> +  - renesas,ipmmu-r8a77980 # R-Car V3H
> +  - renesas,ipmmu-r8a77990 # R-Car E3
> +  - renesas,ipmmu-r8a77995 # R-Car D3
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +minItems: 1
> +maxItems: 2
> +description:
> +  Specifiers for the MMU fault interrupts. For instances that support
> +  secure mode two interrupts must be specified, for non-secure and secure
> +  mode, in that order. For instances that don't support secure mode a
> +  single interrupt must be specified. Not required for cache IPMMUs.

items:
  - description: 
  - description: 

> +
> +  '#iommu-cells':
> +const: 1
> +
> +  power-domains:
> +maxItems: 1
> +
> +  renesas,ipmmu-main:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> +  Reference to the main IPMMU instance in two cells. The first cell is
> +  a phandle to the main IPMMU and the second cell is the interrupt bit
> +  number associated with the particular cache IPMMU device. The interrupt
> +  bit number needs to match the main IPMMU IMSSTR register. Only used by
> +  cache IPMMU instances.

This property is not valid only on R-Car Gen2 and R-Mobile APE6.

(untested)

oneOf:
  - properties:
  contains:
    const: renesas,ipmmu-vmsa
  - properties:
  renesas,ipmmu-main:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
  [...]

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] netfilter: nft_fwd_netdev: Fix CONFIG_NET_CLS_ACT=n build

2020-04-10 Thread Geert Uytterhoeven
On Fri, Apr 10, 2020 at 4:26 PM Geert Uytterhoeven  wrote:
> If CONFIG_NET_CLS_ACT=n:
>
> net/netfilter/nft_fwd_netdev.c: In function ‘nft_fwd_netdev_eval’:
> net/netfilter/nft_fwd_netdev.c:32:10: error: ‘struct sk_buff’ has no 
> member named ‘tc_redirected’
>   pkt->skb->tc_redirected = 1;
>   ^~
> net/netfilter/nft_fwd_netdev.c:33:10: error: ‘struct sk_buff’ has no 
> member named ‘tc_from_ingress’
>   pkt->skb->tc_from_ingress = 1;
>   ^~
>
> Fix this by protecting this code hunk with the appropriate #ifdef.
>
> Reported-by: nore...@ellerman.id.au
> Fixes: bcfabee1afd99484 ("netfilter: nft_fwd_netdev: allow to redirect to ifb 
> via ingress")
> Signed-off-by: Geert Uytterhoeven 

Please ignore, wrong patch.
Sorry for the mess.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] iommu: Fix MTK_IOMMU dependencies

2020-04-10 Thread Geert Uytterhoeven
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):

drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
dma-iommu.c:(.text+0x836): undefined reference to `dma_pgprot'

IOMMU_DMA must not be selected, unless HAS_DMA=y.

Hence fix this by making MTK_IOMMU depend on HAS_DMA.
While at it, remove the dependency on ARM || ARM64, as that is already
implied by the dependency on ARCH_MEDIATEK.

Fixes: e93a1695d7fb5513 ("iommu: Enable compile testing for some of drivers")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 58b4a4dbfc78b9a5..bead9aaea8429447 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -457,7 +457,7 @@ config S390_AP_IOMMU
 
 config MTK_IOMMU
bool "MTK IOMMU Support"
-   depends on ARM || ARM64 || COMPILE_TEST
+   depends on HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] netfilter: nft_fwd_netdev: Fix CONFIG_NET_CLS_ACT=n build

2020-04-10 Thread Geert Uytterhoeven
If CONFIG_NET_CLS_ACT=n:

net/netfilter/nft_fwd_netdev.c: In function ‘nft_fwd_netdev_eval’:
net/netfilter/nft_fwd_netdev.c:32:10: error: ‘struct sk_buff’ has no member 
named ‘tc_redirected’
  pkt->skb->tc_redirected = 1;
  ^~
net/netfilter/nft_fwd_netdev.c:33:10: error: ‘struct sk_buff’ has no member 
named ‘tc_from_ingress’
  pkt->skb->tc_from_ingress = 1;
  ^~

Fix this by protecting this code hunk with the appropriate #ifdef.

Reported-by: nore...@ellerman.id.au
Fixes: bcfabee1afd99484 ("netfilter: nft_fwd_netdev: allow to redirect to ifb 
via ingress")
Signed-off-by: Geert Uytterhoeven 
---
 net/netfilter/nft_fwd_netdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
index 74f050ba6badc9dc..ebcaf5c325712f30 100644
--- a/net/netfilter/nft_fwd_netdev.c
+++ b/net/netfilter/nft_fwd_netdev.c
@@ -28,9 +28,11 @@ static void nft_fwd_netdev_eval(const struct nft_expr *expr,
struct nft_fwd_netdev *priv = nft_expr_priv(expr);
int oif = regs->data[priv->sreg_dev];
 
+#ifdef CONFIG_NET_CLS_ACT
/* These are used by ifb only. */
pkt->skb->tc_redirected = 1;
pkt->skb->tc_from_ingress = 1;
+#endif
 
nf_fwd_netdev_egress(pkt, oif);
regs->verdict.code = NF_STOLEN;
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

2020-04-03 Thread Geert Uytterhoeven
Hi John,

On Fri, Apr 3, 2020 at 1:47 PM Geert Uytterhoeven  wrote:
> On Thu, Apr 2, 2020 at 7:27 PM John Stultz  wrote:
> > On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda
> >  wrote:
> > >
> > > I found an issue after applied the following patches:
> > > ---
> > > 64c775f driver core: Rename deferred_probe_timeout and make it global
> > > 0e9f8d0 driver core: Remove driver_deferred_probe_check_state_continue()
> > > bec6c0e pinctrl: Remove use of 
> > > driver_deferred_probe_check_state_continue()
> > > e2cec7d driver core: Set deferred_probe_timeout to a longer default if 
> > > CONFIG_MODULES is set
>
> Note that just setting deferred_probe_timeout = -1 like for the
> CONFIG_MODULES=n case doesn't help.
>
> > > c8c43ce driver core: Fix driver_deferred_probe_check_state() logic
> > > ---
> > >
> > > Before these patches, on my environment [1], some device drivers
> > > which has iommus property output the following message when probing:
> > >
> > > [3.05] ravb e680.ethernet: ignoring dependency for device, 
> > > assuming no driver
> > > [3.257174] ravb e680.ethernet eth0: Base address at 0xe680, 
> > > 2e:09:0a:02:eb:2d, IRQ 117.
> > >
> > > So, since ravb driver is probed within 4 seconds, we can use NFS rootfs 
> > > correctly.
> > >
> > > However, after these patches are applied, since the patches are always 
> > > waiting for 30 seconds
> > > for of_iommu_configure() when IOMMU hardware is disabled, 
> > > drivers/base/dd.c output WARN.
> > > Also, since ravb cannot be probed for 30 seconds, we cannot use NFS 
> > > rootfs anymore.
> > > JFYI, I copied the kernel log to the end of this email.
> >
> > Hey,
> >   Terribly sorry for the trouble. So as Robin mentioned I have a patch
> > to remove the WARN messages, but I'm a bit more concerned about why
> > after the 30 second delay, the ethernet driver loads:
> >   [   36.218666] ravb e680.ethernet eth0: Base address at
> > 0xe680, 2e:09:0a:02:eb:2d, IRQ 117.
> > but NFS fails.
> >
> > Is it just that the 30 second delay is too long and NFS gives up?
>
> I added some debug code to mount_nfs_root(), which shows that the first
> 3 tries happen before ravb is instantiated, and the last 3 tries happen
> after.  So NFS root should work, if the network works.
>
> However, it seems the Ethernet PHY is never initialized, hence the link
> never becomes ready.

So the issue is not nfsroot in-se, but the ip-config that needs to
happen before that.

The call to wait_for_devices() in ip_auto_config() (which is a
late_initcall()) returns -ENODEV, as the network device hasn't probed
successfully yet, so ip-config is aborted.

The (whitespace-damaged) patch below fixes that, but may have unintended
side-effects.

--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1469,7 +1469,11 @@ static int __init ip_auto_config(void)
/* Wait for devices to appear */
err = wait_for_devices();
if (err)
+#ifdef IPCONFIG_DYNAMIC
+   goto try_try_again;
+#else
return err;
+#endif

/* Setup all network devices */
err = ic_open_devs();

Probably we want at least some CONFIG_ROOT_NFS || CONFIG_CIFS_ROOT,
and ROOT_DEV == Root_NFS || ROOT_DEV == Root_CIFS checks.

Thanks for your comments!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: How to fix WARN from drivers/base/dd.c in next-20200401 if CONFIG_MODULES=y?

2020-04-03 Thread Geert Uytterhoeven
Hi John,

On Thu, Apr 2, 2020 at 7:27 PM John Stultz  wrote:
> On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda
>  wrote:
> >
> > I found an issue after applied the following patches:
> > ---
> > 64c775f driver core: Rename deferred_probe_timeout and make it global
> > 0e9f8d0 driver core: Remove driver_deferred_probe_check_state_continue()
> > bec6c0e pinctrl: Remove use of driver_deferred_probe_check_state_continue()
> > e2cec7d driver core: Set deferred_probe_timeout to a longer default if 
> > CONFIG_MODULES is set

Note that just setting deferred_probe_timeout = -1 like for the
CONFIG_MODULES=n case doesn't help.

> > c8c43ce driver core: Fix driver_deferred_probe_check_state() logic
> > ---
> >
> > Before these patches, on my environment [1], some device drivers
> > which has iommus property output the following message when probing:
> >
> > [3.05] ravb e680.ethernet: ignoring dependency for device, 
> > assuming no driver
> > [3.257174] ravb e680.ethernet eth0: Base address at 0xe680, 
> > 2e:09:0a:02:eb:2d, IRQ 117.
> >
> > So, since ravb driver is probed within 4 seconds, we can use NFS rootfs 
> > correctly.
> >
> > However, after these patches are applied, since the patches are always 
> > waiting for 30 seconds
> > for of_iommu_configure() when IOMMU hardware is disabled, drivers/base/dd.c 
> > output WARN.
> > Also, since ravb cannot be probed for 30 seconds, we cannot use NFS rootfs 
> > anymore.
> > JFYI, I copied the kernel log to the end of this email.
>
> Hey,
>   Terribly sorry for the trouble. So as Robin mentioned I have a patch
> to remove the WARN messages, but I'm a bit more concerned about why
> after the 30 second delay, the ethernet driver loads:
>   [   36.218666] ravb e680.ethernet eth0: Base address at
> 0xe680, 2e:09:0a:02:eb:2d, IRQ 117.
> but NFS fails.
>
> Is it just that the 30 second delay is too long and NFS gives up?

I added some debug code to mount_nfs_root(), which shows that the first
3 tries happen before ravb is instantiated, and the last 3 tries happen
after.  So NFS root should work, if the network works.

However, it seems the Ethernet PHY is never initialized, hence the link
never becomes ready.  Dmesg before/after:

 ravb e680.ethernet eth0: Base address at 0xe680,
2e:09:0a:02:ea:ff, IRQ 108.

Good.

 ...
-gpio_rcar e6052000.gpio: sense irq = 11, type = 8

This is the GPIO the PHY IRQ is connected to.
Note that that GPIO controller has been instantiated before.

 ...
-Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
attached PHY driver [Micrel KSZ9031 Gigabit PHY]
(mii_bus:phy_addr=e680.ethernet-:00, irq=197)
 ...
-ravb e680.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

Oops.

-Sending DHCP requests .., OK
-IP-Config: Got DHCP answer from ...
 ...
+VFS: Unable to mount root fs via NFS, trying floppy.
+VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6

> Does booting with deferred_probe_timeout=0 work?

It does, as now everything using optional links (DMA and IOMMU) is now
instantiated on first try.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dma-debug: dynamic allocation of hash table

2020-01-31 Thread Geert Uytterhoeven
Hi Robin,

On Fri, Jan 31, 2020 at 12:46 AM Robin Murphy  wrote:
> On 2020-01-30 7:10 pm, Eric Dumazet via iommu wrote:
> > Increasing the size of dma_entry_hash size by 327680 bytes
> > has reached some bootloaders limitations.
>
> [ That might warrant some further explanation - I don't quite follow how
> this would relate to a bootloader specifically :/ ]

Increasing the size of a static array increases kernel size.
Some (all? ;-) bootloaders have limitations on the maximum size of a
kernel image they can boot (usually something critical gets overwritten
when handling a too large image).  While boot loaders can be fixed and
upgraded, this is usually much more cumbersome than updating the
kernel.

Besides, a static array always consumes valuable unswapable memory,
even when the feature would not be used (e.g. disabled by a command
line option).

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH -next] iommu/ipmmu-vmsa: Remove dev_err() on platform_get_irq() failure

2019-10-23 Thread Geert Uytterhoeven
On Wed, Oct 23, 2019 at 4:01 PM YueHaibing  wrote:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 5/6] iommu/ipmmu-vmsa: Add helper functions for "uTLB" registers

2019-10-16 Thread Geert Uytterhoeven
On Tue, Oct 15, 2019 at 2:10 PM Yoshihiro Shimoda
 wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> This patch adds helper functions ipmmu_utlb_reg() and
> ipmmu_imu{asid,ctr}_write() for "uTLB" registers. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 4/6] iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro

2019-10-16 Thread Geert Uytterhoeven
On Tue, Oct 15, 2019 at 2:10 PM Yoshihiro Shimoda
 wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch uses ipmmu_features values instead of a macro to
> calculate context registers offset. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/6] iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers

2019-10-16 Thread Geert Uytterhoeven
On Tue, Oct 15, 2019 at 2:10 PM Yoshihiro Shimoda
 wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> This patch adds helper functions ipmmu_ctx_{reg,read,write}()
> for MMU "context" registers. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] iommu/ipmmu-vmsa: Add utlb_offset_base

2019-10-11 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
 wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch adds a utlb_offset_base into struct ipmmu_features
> for IMUCTR and IMUASID registers.
> No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks for your patch!

> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -52,6 +52,7 @@ struct ipmmu_features {
> bool cache_snoop;
> u32 ctx_offset_base;
> u32 ctx_offset_stride;
> +   u32 utlb_offset_base;
>  };
>
>  struct ipmmu_vmsa_device {
> @@ -285,6 +286,11 @@ static void ipmmu_ctx_write_all(struct ipmmu_vmsa_domain 
> *domain,
> ipmmu_ctx_write_root(domain, reg, data);
>  }
>
> +static u32 ipmmu_utlb_reg(struct ipmmu_vmsa_device *mmu, unsigned int reg)
> +{
> +   return mmu->features->utlb_offset_base + reg;
> +}
> +
>  /* 
> -
>   * TLB and microTLB Management
>   */
> @@ -330,9 +336,9 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain 
> *domain,
>  */
>
> /* TODO: What should we set the ASID to ? */
> -   ipmmu_write(mmu, IMUASID(utlb), 0);
> +   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)), 0);
> /* TODO: Do we need to flush the microTLB ? */
> -   ipmmu_write(mmu, IMUCTR(utlb),
> +   ipmmu_write(mmu, ipmmu_utlb_reg(mmu, IMUCTR(utlb)),
> IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_FLUSH |
> IMUCTR_MMUEN);

Like in [PATCH 2/3], I think providing two helpers would make this more
readable:

    ipmmu_imuasid_write(mmu, utlb, 0);
ipmmu_imuctr_write(mmu, utlb, data);

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 2/3] iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro

2019-10-11 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
 wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch uses ipmmu_features values instead of a macro to
> calculate context registers offset. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks for your patch!

> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -50,6 +50,8 @@ struct ipmmu_features {
> bool twobit_imttbcr_sl0;
> bool reserved_context;
> bool cache_snoop;
> +   u32 ctx_offset_base;
> +   u32 ctx_offset_stride;
>  };
>
>  struct ipmmu_vmsa_device {
> @@ -99,8 +101,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
> *dev)
>
>  #define IM_NS_ALIAS_OFFSET 0x800
>
> -#define IM_CTX_SIZE0x40
> -
>  #define IMCTR  0x
>  #define IMCTR_TRE  (1 << 17)
>  #define IMCTR_AFE  (1 << 16)
> @@ -253,18 +253,25 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu, 
> unsigned int offset,
> iowrite32(data, mmu->base + offset);
>  }
>
> +static u32 ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu, unsigned int 
> context_id,
> +unsigned int reg)
> +{
> +   return mmu->features->ctx_offset_base +
> +  context_id * mmu->features->ctx_offset_stride + reg;
> +}
> +
>  static u32 ipmmu_ctx_read_root(struct ipmmu_vmsa_domain *domain,
>unsigned int reg)
>  {
> return ipmmu_read(domain->mmu->root,
> - domain->context_id * IM_CTX_SIZE + reg);
> + ipmmu_ctx_reg(domain->mmu, domain->context_id, 
> reg));

For consistency:

ipmmu_ctx_reg(domain->mmu->root, ...)

but in practice the features for domain->mmu and domain->mmu->root are
identical anyway.

>  }
>
>  static void ipmmu_ctx_write_root(struct ipmmu_vmsa_domain *domain,
>  unsigned int reg, u32 data)
>  {
> ipmmu_write(domain->mmu->root,
> -   domain->context_id * IM_CTX_SIZE + reg, data);
> +   ipmmu_ctx_reg(domain->mmu, domain->context_id, reg), 
> data);

Likewise:

ipmmu_ctx_reg(domain->mmu->root, ...)?

I find these ipmmu_{read,write}() a bit hard too read, with passing the
mmu to both ipmmu_{read,write}() and ipmmu_ctx_reg().

What do you think about providing two helpers ipmmu_ctx_{read,write}(),
so all users can just use e.g.

ipmmu_ctx_write(mmu, context_id, reg, data);

instead of

ipmmu_write(mmu, ipmmu_ctx_reg(mmu, context_id, reg), data);

?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 1/3] iommu/ipmmu-vmsa: Remove some unused register declarations

2019-10-11 Thread Geert Uytterhoeven
Hi Shimoda-san,

Thanks for your patch!

On Wed, Oct 9, 2019 at 10:27 AM Yoshihiro Shimoda
 wrote:
> To support different registers memory mapping hardware easily
> in the future, this patch removes some unused register
> declarations.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

While I can confirm the removed definitions are unused, they were
still valid (but see comments below).
Perhaps it would be better to add comments, to state clearly to which
SoCs or SoC families they apply?  Or do you think this would be futile,
and would add too much clutter to the source file in the near future?

> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -104,8 +104,6 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
> *dev)
>  #define IMCTR  0x
>  #define IMCTR_TRE  (1 << 17)
>  #define IMCTR_AFE  (1 << 16)
> -#define IMCTR_RTSEL_MASK   (3 << 4)

FWIW, this is valid for R-Car Gen2 only.  On R-Car Gen3, the field
contains 3 bits.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [RESEND TRIVIAL 3/3] treewide: arch: Fix Kconfig indentation

2019-10-07 Thread Geert Uytterhoeven
On Fri, Oct 4, 2019 at 4:57 PM Krzysztof Kozlowski  wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski 

>  arch/m68k/Kconfig.bus  |  2 +-
>  arch/m68k/Kconfig.debug| 16 
>  arch/m68k/Kconfig.machine  |  8 ----

For m68k:
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dma-mapping: fix false positivse warnings in dma_common_free_remap()

2019-10-07 Thread Geert Uytterhoeven
gt; (platform_drv_shutdown+0x2c/0x30)
> [<804a2944>] (platform_drv_shutdown) from [<8049e4fc>] 
> (device_shutdown+0x158/0x1f0)
> [<8049e3a4>] (device_shutdown) from [<8013ac80>] 
> (kernel_restart_prepare+0x44/0x48)
>  r10:0058 r9:9f4d8000 r8:fee1dead r7:379ce700 r6:81c0b280 r5:81c03048
>  r4:
> [<8013ac3c>] (kernel_restart_prepare) from [<8013ad14>] 
> (kernel_restart+0x1c/0x60)
> [<8013acf8>] (kernel_restart) from [<8013af84>] (__do_sys_reboot+0xe0/0x1d8)
>  r5:81c03048 r4:
> [<8013aea4>] (__do_sys_reboot) from [<8013b0ec>] (sys_reboot+0x18/0x1c)
>  r8:80101204 r7:0058 r6: r5: r4:
> [<8013b0d4>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54)
> Exception stack(0x9f4d9fa8 to 0x9f4d9ff0)
> 9fa0:     fee1dead 28121969 01234567 379ce700
> 9fc0:    0058    00016d04
> 9fe0: 00028e0c 7ec87c64 000135ec 76c1f410
>
> Restore original invalid input check in dma_common_free_remap() to
> avoid this problem.
>
> Fixes: 5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages helper")
> Signed-off-by: Andrey Smirnov 
> [hch: just revert the offending hunk instead of creating a new helper]
> Signed-off-by: Christoph Hellwig 

Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/4] dma-mapping: introduce a dma_common_find_pages helper

2019-10-07 Thread Geert Uytterhoeven
Hi Christoph,

On Sun, Oct 6, 2019 at 8:45 PM Christoph Hellwig  wrote:
> please try Linus' current tree.  It has a fix from Andrey Smirnov
> for what looks the same problem that you reported.

Thanks, confirmed fixed by commit 2cf2aa6a69db0b17 ("dma-mapping: fix
false positivse warnings in dma_common_free_remap()").

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 3/4] dma-mapping: introduce a dma_common_find_pages helper

2019-10-02 Thread Geert Uytterhoeven
 = __iommu_dma_get_pages(cpu_addr);
> +   struct page **pages = dma_common_find_pages(cpu_addr);
>
> if (pages)
> return __iommu_dma_mmap(pages, size, vma);
> @@ -1067,7 +1058,7 @@ static int iommu_dma_get_sgtable(struct device *dev, 
> struct sg_table *sgt,
> int ret;
>
> if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) {
> -   struct page **pages = __iommu_dma_get_pages(cpu_addr);
> +   struct page **pages = dma_common_find_pages(cpu_addr);
>
> if (pages) {
> return sg_alloc_table_from_pages(sgt, pages,

> --- a/kernel/dma/remap.c
> +++ b/kernel/dma/remap.c
> @@ -11,6 +11,15 @@
>  #include 
>  #include 
>
> +struct page **dma_common_find_pages(void *cpu_addr)
> +{
> +   struct vm_struct *area = find_vm_area(cpu_addr);
> +
> +   if (!area || area->flags != VM_DMA_COHERENT)

... while this one checks area->flags?

> +   return NULL;
> +   return area->pages;
> +}
> +
>  static struct vm_struct *__dma_common_pages_remap(struct page **pages,
> size_t size, pgprot_t prot, const void *caller)
>  {

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH] iommu/ipmmu-vmsa: Only call platform_get_irq() when interrupt is mandatory

2019-10-01 Thread Geert Uytterhoeven
As platform_get_irq() now prints an error when the interrupt does not
exist, calling it gratuitously causes scary messages like:

ipmmu-vmsa e674.mmu: IRQ index 0 not found

Fix this by moving the call to platform_get_irq() down, where the
existence of the interrupt is mandatory.

Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to 
platform_get_irq*()")
Signed-off-by: Geert Uytterhoeven 
---
This is a fix for v5.4-rc1.
---
 drivers/iommu/ipmmu-vmsa.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9da8309f71708f21..237103465b824c51 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -1086,8 +1086,6 @@ static int ipmmu_probe(struct platform_device *pdev)
 
mmu->num_ctx = min(IPMMU_CTX_MAX, mmu->features->number_of_contexts);
 
-   irq = platform_get_irq(pdev, 0);
-
/*
 * Determine if this IPMMU instance is a root device by checking for
 * the lack of has_cache_leaf_nodes flag or renesas,ipmmu-main property.
@@ -1106,6 +1104,7 @@ static int ipmmu_probe(struct platform_device *pdev)
 
/* Root devices have mandatory IRQs */
if (ipmmu_is_root(mmu)) {
+   irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(>dev, "no IRQ found\n");
return irq;
-- 
2.17.1



Re: [PATCH] iommu/ipmmu-vmsa: Hook up r8a774b1 DT matching code

2019-09-26 Thread Geert Uytterhoeven
Hi Biju,

On Tue, Sep 24, 2019 at 9:43 AM Biju Das  wrote:
> Support RZ/G2N (R8A774B1) IPMMU.
>
> Signed-off-by: Biju Das 

Thanks for your patch!

> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c

>  static const struct soc_device_attribute soc_rcar_gen3_whitelist[] = {
> { .soc_id = "r8a774c0", },
> +   { .soc_id = "r8a774b1", },

Please preserve alphabetical sort order.

> { .soc_id = "r8a7795", .revision = "ES3.*" },
> { .soc_id = "r8a77965", },
>     { .soc_id = "r8a77990", },

With the above fixed:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH] dt-bindings: iommu: ipmmu-vmsa: Add r8a774b1 support

2019-09-26 Thread Geert Uytterhoeven
On Tue, Sep 24, 2019 at 9:41 AM Biju Das  wrote:
> Document RZ/G2N (R8A774B1) SoC bindings.
>
> Signed-off-by: Biju Das 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v1 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count

2019-09-17 Thread Geert Uytterhoeven
Hi Uwe,

On Tue, Sep 17, 2019 at 2:25 PM Uwe Kleine-König
 wrote:
> On Tue, Sep 17, 2019 at 11:25:46AM +, Peter Rosin wrote:
> > On 2019-09-17 12:13, Uwe Kleine-König wrote:
> > > On Tue, Sep 17, 2019 at 11:40:25AM +0200, Geert Uytterhoeven wrote:
> > >> On Fri, Sep 13, 2019 at 11:58 PM Rob Herring  wrote:
> > >>> On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= 
> > >>>  wrote:
> > >>>> Referencing device tree nodes from a property allows to pass arguments.
> > >>>> This is for example used for referencing gpios. This looks as follows:
> > >>>>
> > >>>>   gpio_ctrl: gpio-controller {
> > >>>>   #gpio-cells = <2>
> > >>>>   ...
> > >>>>   }
> > >>>>
> > >>>>   someothernode {
> > >>>>   gpios = <_ctrl 5 0 _ctrl 3 0>;
> > >>>>   ...
> > >>>>   }
> > >>>>
> > >>>> To know the number of arguments this must be either fixed, or the
> > >>>> referenced node is checked for a $cells_name (here: "#gpio-cells")
> > >>>> property and with this information the start of the second reference 
> > >>>> can
> > >>>> be determined.
> > >>>>
> > >>>> Currently regulators are referenced with no additional arguments. To
> > >>>> allow some optional arguments without having to change all referenced
> > >>>> nodes this change introduces a way to specify a default cell_count. So
> > >>>> when a phandle is parsed we check for the $cells_name property and use
> > >>>> it as before if present. If it is not present we fall back to
> > >>>> cells_count if non-negative and only fail if cells_count is smaller 
> > >>>> than
> > >>>> zero.
> > >>>>
> > >>>> Signed-off-by: Uwe Kleine-König 
> > >>
> > >> This is now commit e42ee61017f58cd9 ("of: Let of_for_each_phandle 
> > >> fallback
> > >> to non-negative cell_count") in robh/for-next, which causes a lock-up 
> > >> when
> > >> booting a shmobile_defconfig kernel on r8a7791/koelsch:
> > >>
> > >> rcu: INFO: rcu_sched self-detected stall on CPU

> Oh yeah, you're right. I'm a bit disappointed that I didn't spot this
> myself :-|
>
> Untested patch to fix this problem:
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 2f25d2dfecfa..26f7a21d7187 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1284,6 +1284,13 @@ int of_phandle_iterator_init(struct 
> of_phandle_iterator *it,
> const __be32 *list;
> int size;
>
> +   /*
> +* one of cell_count or cells_name must be provided to determine the
> +* argument length.
> +*/
> +   if (cell_count < 0 && !cells_name)
> +   return -EINVAL;
> +
> memset(it, 0, sizeof(*it));
>
>     list = of_get_property(np, list_name, );
> @@ -1765,6 +1772,18 @@ int of_count_phandle_with_args(const struct 
> device_node *np, const char *list_na
> struct of_phandle_iterator it;
> int rc, cur_index = 0;
>
> +   /* If cells_name is NULL we assume an cell_count of 0 */

a cell count

> +   if (cells_name == NULL) {
> +   const __be32 *list;
> +   int size;
> +
> +   list = of_get_property(np, list_name, );
> +   if (!list)
> +   return -ENOENT;
> +
> +   return size / sizeof(*list);
> +   }
> +
> rc = of_phandle_iterator_init(, np, list_name, cells_name, -1);
> if (rc)
> return rc;

Thanks, that fixes the boot for me!

Tested-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v1 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count

2019-09-17 Thread Geert Uytterhoeven
Hi Rob, Uwe,

On Fri, Sep 13, 2019 at 11:58 PM Rob Herring  wrote:
> On Sat, 24 Aug 2019 15:28:46 +0200, =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=   
>wrote:
> > Referencing device tree nodes from a property allows to pass arguments.
> > This is for example used for referencing gpios. This looks as follows:
> >
> >   gpio_ctrl: gpio-controller {
> >   #gpio-cells = <2>
> >   ...
> >   }
> >
> >   someothernode {
> >   gpios = <_ctrl 5 0 _ctrl 3 0>;
> >   ...
> >   }
> >
> > To know the number of arguments this must be either fixed, or the
> > referenced node is checked for a $cells_name (here: "#gpio-cells")
> > property and with this information the start of the second reference can
> > be determined.
> >
> > Currently regulators are referenced with no additional arguments. To
> > allow some optional arguments without having to change all referenced
> > nodes this change introduces a way to specify a default cell_count. So
> > when a phandle is parsed we check for the $cells_name property and use
> > it as before if present. If it is not present we fall back to
> > cells_count if non-negative and only fail if cells_count is smaller than
> > zero.
> >
> > Signed-off-by: Uwe Kleine-König 

This is now commit e42ee61017f58cd9 ("of: Let of_for_each_phandle fallback
to non-negative cell_count") in robh/for-next, which causes a lock-up when
booting a shmobile_defconfig kernel on r8a7791/koelsch:

rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 0-: (2099 ticks this GP) idle=6fe/1/0x4002
softirq=29/29 fqs=1050
 (t=2100 jiffies g=-1131 q=0)
NMI backtrace for cpu 0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.0-rc2-shmobile-00050-ge42ee61017f58cd9 #376
Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x7c/0x9c)
[] (dump_stack) from [] (nmi_cpu_backtrace+0xa0/0xb8)
[] (nmi_cpu_backtrace) from []
(nmi_trigger_cpumask_backtrace+0x84/0x114)
[] (nmi_trigger_cpumask_backtrace) from []
(rcu_dump_cpu_stacks+0xac/0xc8)
[] (rcu_dump_cpu_stacks) from []
(rcu_sched_clock_irq+0x2ac/0x6b4)
[] (rcu_sched_clock_irq) from []
(update_process_times+0x30/0x5c)
[] (update_process_times) from []
(tick_nohz_handler+0xcc/0x120)
[] (tick_nohz_handler) from []
(arch_timer_handler_virt+0x28/0x30)
[] (arch_timer_handler_virt) from []
(handle_percpu_devid_irq+0xe8/0x21c)
[] (handle_percpu_devid_irq) from []
(generic_handle_irq+0x18/0x28)
[] (generic_handle_irq) from []
(__handle_domain_irq+0xa0/0xb4)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x90)
[] (gic_handle_irq) from [] (__irq_svc+0x6c/0x90)
Exception stack(0xeb08dd30 to 0xeb08dd78)
dd20: c0cc7514 2013 0005 3b27
dd40: eb7c4020 c0cc750c 0051 0051 2013 c0c66b08 eb1cdc00 0018
dd60:  eb08dd80 c05c1a38 c0756c00 2013 
[] (__irq_svc) from []
(_raw_spin_unlock_irqrestore+0x1c/0x20)
[] (_raw_spin_unlock_irqrestore) from []
(of_find_node_by_phandle+0xcc/0xf0)
[] (of_find_node_by_phandle) from []
(of_phandle_iterator_next+0x68/0x178)
[] (of_phandle_iterator_next) from []
(of_count_phandle_with_args+0x5c/0x7c)
[] (of_count_phandle_with_args) from []
(i2c_demux_pinctrl_probe+0x24/0x1fc)
[] (i2c_demux_pinctrl_probe) from []
(platform_drv_probe+0x48/0x94)
[] (platform_drv_probe) from [] (really_probe+0x1f0/0x2b8)
[] (really_probe) from [] (driver_probe_device+0x140/0x158)
[] (driver_probe_device) from []
(device_driver_attach+0x44/0x5c)
[] (device_driver_attach) from []
(__driver_attach+0xac/0xb4)
[] (__driver_attach) from [] (bus_for_each_dev+0x64/0xa0)
[] (bus_for_each_dev) from [] (bus_add_driver+0x148/0x1a8)
[] (bus_add_driver) from [] (driver_register+0xac/0xf0)
[] (driver_register) from [] (do_one_initcall+0xa8/0x1d4)
[] (do_one_initcall) from []
(kernel_init_freeable+0x26c/0x2c8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0x10c)
[] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xeb08dfb0 to 0xeb08dff8)
dfa0:    
dfc0:        
dfe0: 0000    0013 

Presumably it loops forever, due to a conversion of -1 to unsigned
somewhere?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH 2/2] iommu/ipmmu-vmsa: Disable cache snoop transactions on R-Car Gen3

2019-09-04 Thread Geert Uytterhoeven
From: Hai Nguyen Pham 

According to the Hardware Manual Errata for Rev. 1.50 of April 10, 2019,
cache snoop transactions for page table walk requests are not supported
on R-Car Gen3.

Hence, this patch removes setting these fields in the IMTTBCR register,
since it will have no effect, and adds comments to the register bit
definitions, to make it clear they apply to R-Car Gen2 only.

Signed-off-by: Hai Nguyen Pham 
[geert: Reword, add comments]
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 71 --
 1 file changed, 38 insertions(+), 33 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 1baabeaddc9cba1b..9da8309f71708f21 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -49,6 +49,7 @@ struct ipmmu_features {
bool setup_imbuscr;
bool twobit_imttbcr_sl0;
bool reserved_context;
+   bool cache_snoop;
 };
 
 struct ipmmu_vmsa_device {
@@ -115,36 +116,36 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IMTTBCR0x0008
 #define IMTTBCR_EAE(1 << 31)
 #define IMTTBCR_PMB(1 << 30)
-#define IMTTBCR_SH1_NON_SHAREABLE  (0 << 28)
-#define IMTTBCR_SH1_OUTER_SHAREABLE(2 << 28)
-#define IMTTBCR_SH1_INNER_SHAREABLE(3 << 28)
-#define IMTTBCR_SH1_MASK   (3 << 28)
-#define IMTTBCR_ORGN1_NC   (0 << 26)
-#define IMTTBCR_ORGN1_WB_WA(1 << 26)
-#define IMTTBCR_ORGN1_WT   (2 << 26)
-#define IMTTBCR_ORGN1_WB   (3 << 26)
-#define IMTTBCR_ORGN1_MASK (3 << 26)
-#define IMTTBCR_IRGN1_NC   (0 << 24)
-#define IMTTBCR_IRGN1_WB_WA(1 << 24)
-#define IMTTBCR_IRGN1_WT   (2 << 24)
-#define IMTTBCR_IRGN1_WB   (3 << 24)
-#define IMTTBCR_IRGN1_MASK (3 << 24)
+#define IMTTBCR_SH1_NON_SHAREABLE  (0 << 28)   /* R-Car Gen2 only */
+#define IMTTBCR_SH1_OUTER_SHAREABLE(2 << 28)   /* R-Car Gen2 only */
+#define IMTTBCR_SH1_INNER_SHAREABLE(3 << 28)   /* R-Car Gen2 only */
+#define IMTTBCR_SH1_MASK   (3 << 28)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN1_NC   (0 << 26)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN1_WB_WA(1 << 26)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN1_WT   (2 << 26)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN1_WB   (3 << 26)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN1_MASK (3 << 26)   /* R-Car Gen2 only */
+#define IMTTBCR_IRGN1_NC   (0 << 24)   /* R-Car Gen2 only */
+#define IMTTBCR_IRGN1_WB_WA(1 << 24)   /* R-Car Gen2 only */
+#define IMTTBCR_IRGN1_WT   (2 << 24)   /* R-Car Gen2 only */
+#define IMTTBCR_IRGN1_WB   (3 << 24)   /* R-Car Gen2 only */
+#define IMTTBCR_IRGN1_MASK (3 << 24)   /* R-Car Gen2 only */
 #define IMTTBCR_TSZ1_MASK  (7 << 16)
 #define IMTTBCR_TSZ1_SHIFT 16
-#define IMTTBCR_SH0_NON_SHAREABLE  (0 << 12)
-#define IMTTBCR_SH0_OUTER_SHAREABLE(2 << 12)
-#define IMTTBCR_SH0_INNER_SHAREABLE(3 << 12)
-#define IMTTBCR_SH0_MASK   (3 << 12)
-#define IMTTBCR_ORGN0_NC   (0 << 10)
-#define IMTTBCR_ORGN0_WB_WA(1 << 10)
-#define IMTTBCR_ORGN0_WT   (2 << 10)
-#define IMTTBCR_ORGN0_WB   (3 << 10)
-#define IMTTBCR_ORGN0_MASK (3 << 10)
-#define IMTTBCR_IRGN0_NC   (0 << 8)
-#define IMTTBCR_IRGN0_WB_WA(1 << 8)
-#define IMTTBCR_IRGN0_WT   (2 << 8)
-#define IMTTBCR_IRGN0_WB   (3 << 8)
-#define IMTTBCR_IRGN0_MASK (3 << 8)
+#define IMTTBCR_SH0_NON_SHAREABLE  (0 << 12)   /* R-Car Gen2 only */
+#define IMTTBCR_SH0_OUTER_SHAREABLE(2 << 12)   /* R-Car Gen2 only */
+#define IMTTBCR_SH0_INNER_SHAREABLE(3 << 12)   /* R-Car Gen2 only */
+#define IMTTBCR_SH0_MASK   (3 << 12)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN0_NC   (0 << 10)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN0_WB_WA(1 << 10)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN0_WT   (2 << 10)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN0_WB   (3 << 10)   /* R-Car Gen2 only */
+#define IMTTBCR_ORGN0_MASK (3 << 10)   /* R-Car Gen2 only */
+#define IMTTBCR_IRGN0_NC   (0 << 8)/* R-Car Gen2 only */
+#define IMTTBCR_IRGN0_WB_WA(1 << 8)/* R-C

[PATCH 0/2] iommu/ipmmu-vmsa: Disable cache snoop transactions on R-Car Gen3

2019-09-04 Thread Geert Uytterhoeven
Hi Jörg,

According to recent errata, the IOMMU in R-Car Gen3 SoCs does not
support cache snoop transactions for page table walk requests.

Hence this patch series skips the related setup when running on R-Car
Gen3, after doing a customary cleanup of related definitions.

Tested on R-Car H3 ES2.0 with QEMU+KVM and VFIO for EtherAVB.

Thanks!

Geert Uytterhoeven (1):
  iommu/ipmmu-vmsa: Move IMTTBCR_SL0_TWOBIT_* to restore sort order

Hai Nguyen Pham (1):
  iommu/ipmmu-vmsa: Disable cache snoop transactions on R-Car Gen3

 drivers/iommu/ipmmu-vmsa.c | 78 --
 1 file changed, 41 insertions(+), 37 deletions(-)

-- 
2.17.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH 1/2] iommu/ipmmu-vmsa: Move IMTTBCR_SL0_TWOBIT_* to restore sort order

2019-09-04 Thread Geert Uytterhoeven
Move the recently added IMTTBCR_SL0_TWOBIT_* definitions up, to make
sure all IMTTBCR register bit definitions are sorted by decreasing bit
index.  Add comments to make it clear that they exist on R-Car Gen3
only.

Fixes: c295f504fb5a38ab ("iommu/ipmmu-vmsa: Allow two bit SL0")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/ipmmu-vmsa.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 76a8ec343d53252e..1baabeaddc9cba1b 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -145,15 +145,14 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IMTTBCR_IRGN0_WT   (2 << 8)
 #define IMTTBCR_IRGN0_WB   (3 << 8)
 #define IMTTBCR_IRGN0_MASK (3 << 8)
+#define IMTTBCR_SL0_TWOBIT_LVL_3   (0 << 6)/* R-Car Gen3 only */
+#define IMTTBCR_SL0_TWOBIT_LVL_2   (1 << 6)/* R-Car Gen3 only */
+#define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)/* R-Car Gen3 only */
 #define IMTTBCR_SL0_LVL_2  (0 << 4)
 #define IMTTBCR_SL0_LVL_1  (1 << 4)
 #define IMTTBCR_TSZ0_MASK  (7 << 0)
 #define IMTTBCR_TSZ0_SHIFT O
 
-#define IMTTBCR_SL0_TWOBIT_LVL_3   (0 << 6)
-#define IMTTBCR_SL0_TWOBIT_LVL_2   (1 << 6)
-#define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)
-
 #define IMBUSCR0x000c
 #define IMBUSCR_DVM(1 << 2)
 #define IMBUSCR_BUSSEL_SYS (0 << 0)
-- 
2.17.1



Re: [PATCH 4/6] dma-mapping: remove arch_dma_mmap_pgprot

2019-08-16 Thread Geert Uytterhoeven
On Fri, Aug 16, 2019 at 9:19 AM Christoph Hellwig  wrote:
> arch_dma_mmap_pgprot is used for two things:
>
>  1) to override the "normal" uncached page attributes for mapping
> memory coherent to devices that can't snoop the CPU caches
>  2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
> arm systems
>
> Replace one with the pgprot_dmacoherent macro that is already provided
> by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
> handling to common code with an explicit arch opt-in.
>
> Signed-off-by: Christoph Hellwig 

>  arch/m68k/Kconfig  |  1 -
>  arch/m68k/include/asm/pgtable_mm.h |  3 +++
>  arch/m68k/kernel/dma.c |  3 +--

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device

2019-08-16 Thread Geert Uytterhoeven
Hi Christoph,

On Fri, Aug 16, 2019 at 8:30 AM Christoph Hellwig  wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_device so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default, replacing similar functionality in m68k and
> powerpc.  The arch_setup_pdev_archdata hooks is now unused and removed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/m68k/kernel/dma.c   |  9 ---

Acked-by: Geert Uytterhoeven 

>  arch/sh/boards/mach-ecovec24/setup.c |  2 --
>  arch/sh/boards/mach-migor/setup.c|  1 -

Acked-by: Geert Uytterhoeven 
given "[PATCH 0/2] Remove calls to empty arch_setup_pdev_archdata()"
https://lore.kernel.org/linux-renesas-soc/1526641611-2769-1-git-send-email-geert+rene...@glider.be/

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 8/8] dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP

2019-08-09 Thread Geert Uytterhoeven
Hi Christoph,

On Thu, Aug 8, 2019 at 6:01 PM Christoph Hellwig  wrote:
> CONFIG_ARCH_NO_COHERENT_DMA_MMAP is now functionally identical to
> !CONFIG_MMU, so remove the separate symbol.  The only difference is that
> arm did not set it for !CONFIG_MMU, but arm uses a separate dma mapping
> implementation including its own mmap method, which is handled by moving
> the CONFIG_MMU check in dma_can_mmap so that is only applies to the
> dma-direct case, just as the other ifdefs for it.
>
> Signed-off-by: Christoph Hellwig 

>  arch/m68k/Kconfig   |  1 -

For m68k:
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 4/5] dma-mapping: provide a better default ->get_required_mask

2019-07-29 Thread Geert Uytterhoeven
Hi Christoph,

On Thu, Jul 25, 2019 at 8:35 AM Christoph Hellwig  wrote:
> Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
> of IOVA space, and the generic direct mapping code already provides its
> own routines that is intelligent based on the amount of memory actually
> present.  Wire up the dma-direct routine for the ARM direct mapping code
> as well, and otherwise default to the constant 32-bit mask.  This way
> we only need to override it for the occasional odd IOMMU that requires
> 64-bit IOVA support, or IOMMU drivers that are more efficient if they
> can fall back to the direct mapping.

As I know you like diving into cans of worms ;-)

Does 64-bit IOVA support actually work in general? Or only on 64-bit
platforms, due to dma_addr_t to unsigned long truncation on 32-bit?

https://lore.kernel.org/linux-renesas-soc/camuhmdwkq918y61tmjbheu29agleynwbvzbsbb-rrh7yyun...@mail.gmail.com/

Gr{oetje,eeting}s,

        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: switch m68k to use the generic remapping DMA allocator v2

2019-07-08 Thread Geert Uytterhoeven
Hi Christoph,

On Tue, Jun 25, 2019 at 11:01 AM Christoph Hellwig  wrote:
> can you take a look at the (untested) patches below?  They convert m68k
> to use the generic remapping DMA allocator, which is also used by
> arm64 and csky.
>
> Changes since v2:
>  - fix kconfig dependencies to properly build on sun3
>  - updated a patch description to better explain why we are doing this

Thanks, both applied and queued for v5.3.

Gr{oetje,eeting}s,

    Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 1/2] m68k: use the generic dma coherent remap allocator

2019-07-01 Thread Geert Uytterhoeven
Hi Christoph,

On Tue, Jun 25, 2019 at 11:01 AM Christoph Hellwig  wrote:
> This switche to using common code for the DMA allocations, including

switches m68k

> potential use of the CMA allocator if configure.  Also add a

configured

> comment where the existing behavior seems to be lacking.
>
> Switching to the generic code enables DMA allocations from atomic
> context, which is required by the DMA API documentation, and also
> adds various other minor features drivers start relying upon.  It
> also makes sure we have on tested code base for all architectures

a tested code base

> that require uncached pte bits for coherent DMA allocations.
>
> Signed-off-by: Christoph Hellwig 

Thanks, applying and queueing for v5.3.

> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -18,57 +18,20 @@
>  #include 
>
>  #if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
> -
> -void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> -   gfp_t flag, unsigned long attrs)
> +pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> +   unsigned long attrs)
>  {
> -   struct page *page, **map;
> -   pgprot_t pgprot;
> -   void *addr;
> -   int i, order;
> -
> -   pr_debug("dma_alloc_coherent: %d,%x\n", size, flag);
> -
> -   size = PAGE_ALIGN(size);
> -   order = get_order(size);
> -
> -   page = alloc_pages(flag | __GFP_ZERO, order);
> -   if (!page)
> -   return NULL;
> -
> -   *handle = page_to_phys(page);
> -   map = kmalloc(sizeof(struct page *) << order, flag & ~__GFP_DMA);
> -   if (!map) {
> -   __free_pages(page, order);
> -   return NULL;
> +   /*
> +* XXX: this doesn't seem to handle the sun3 MMU at all.

Correct.  This file is not compiled on Sun-3, which selects NO_DMA, so
I'll drop the comment while applying.

> +*/
> +   if (CPU_IS_040_OR_060) {
> +   pgprot_val(prot) &= ~_PAGE_CACHE040;
> +   pgprot_val(prot) |= _PAGE_GLOBAL040 | _PAGE_NOCACHE_S;
> +   } else {
> +   pgprot_val(prot) |= _PAGE_NOCACHE030;
> }
> -   split_page(page, order);
> -
> -   order = 1 << order;
> -   size >>= PAGE_SHIFT;
> -   map[0] = page;
> -   for (i = 1; i < size; i++)
> -   map[i] = page + i;
> -   for (; i < order; i++)
> -   __free_page(page + i);
> -   pgprot = __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_DIRTY);
> -   if (CPU_IS_040_OR_060)
> -   pgprot_val(pgprot) |= _PAGE_GLOBAL040 | _PAGE_NOCACHE_S;
> -   else
> -   pgprot_val(pgprot) |= _PAGE_NOCACHE030;
> -   addr = vmap(map, size, VM_MAP, pgprot);
> -   kfree(map);
> -
> -   return addr;
> +   return prot;
>  }

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [RFC] switch m68k to use the generic remapping DMA allocator

2019-06-25 Thread Geert Uytterhoeven
Hi Christoph,

On Tue, Jun 25, 2019 at 9:35 AM Christoph Hellwig  wrote:
> On Tue, Jun 25, 2019 at 09:26:48AM +0200, Geert Uytterhoeven wrote:
> > > > bloat-o-meter says:
> > > >
> > > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040)
> > >
> > > What do these values stand for?  The code should grow a little as
> > > we now need to include the the pool allocator for the above API
> > > fix.
> >
> > Last 3 values are "bytes added/removed (net increase)".
> > So this increases the static kernel size by ca. 4 KiB.
>
> That seems a lot for the little bit of pool code.  Did m68k not

Exactly, hence my original question...

> build lib/genalloc.c by default before?

Indeed, CONFIG_GENERIC_ALLOCATOR wasn't enabled before.

--- .config.orig 2019-06-25 09:53:35.098691378 +0200
+++ .config 2019-06-25 09:59:23.914874446 +0200
@@ -2401,6 +2401,7 @@
 CONFIG_DECOMPRESS_XZ=y
 CONFIG_DECOMPRESS_LZO=y
 CONFIG_DECOMPRESS_LZ4=y
+CONFIG_GENERIC_ALLOCATOR=y
 CONFIG_TEXTSEARCH=y
 CONFIG_TEXTSEARCH_KMP=m
 CONFIG_TEXTSEARCH_BM=m
@@ -2409,6 +2410,10 @@
 CONFIG_HAS_IOMEM=y
 CONFIG_HAS_DMA=y
 CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
+CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
+CONFIG_ARCH_HAS_DMA_MMAP_PGPROT=y
+CONFIG_DMA_REMAP=y
+CONFIG_DMA_DIRECT_REMAP=y
 # CONFIG_DMA_API_DEBUG is not set
 CONFIG_SGL_ALLOC=y
 CONFIG_DQL=y

> Also I'd be curious what the first 4 values are.

Reading scripts/bloat-o-meter in the kernel source tree tells me number of
added/removed symbols (functions or variables), and number of
grown/shrunk symbols.

I run it regularly, to catch silly mistakes (cfr. my favorite one, fixed
by commit 23c323af0375a7f6 ("SUNRPC: No, I did not intend to create a
256KiB hashtable")).

Full output before/after for an atari_defconfig kernel
(numbers are different, baseline has changed, too):

$ bloat-o-meter vmlinux.orig vmlinux
add/remove: 75/0 grow/shrink: 1/2 up/down: 4098/-28 (4070)
Function old new   delta
gen_pool_alloc_algo_owner  - 392+392
dma_atomic_pool_init   - 360+360
gen_pool_best_fit  - 248+248
dma_common_contiguous_remap- 238+238
gen_pool_destroy   - 190+190
gen_pool_free_owner- 184+184
devm_gen_pool_create   - 174+174
dma_alloc_from_pool- 152+152
bitmap_clear_ll- 138+138
arch_dma_free 12 136+124
dma_common_free_remap  - 110+110
gen_pool_add_owner - 108+108
gen_pool_fixed_alloc   - 100+100
dma_common_pages_remap -  92 +92
gen_pool_dma_alloc -  78 +78
arch_dma_prep_coherent -  76 +76
clear_bits_ll  -  66 +66
dma_free_from_pool -  62 +62
set_bits_ll-  60 +60
devm_gen_pool_match-  56 +56
addr_in_gen_pool   -  56 +56
gen_pool_create-  54 +54
gen_pool_virt_to_phys  -  52 +52
gen_pool_first_fit_align   -  52 +52
gen_pool_for_each_chunk-  42 +42
gen_pool_get   -  40 +40
gen_pool_first_fit_order_align -  36 +36
gen_pool_set_algo  -  34 +34
early_coherent_pool-  32 +32
__kstrtab_gen_pool_first_fit_order_align   -  31 +31
gen_pool_size  -  30 +30
arch_dma_mmap_pgprot   -  28 +28
dma_in_atomic_pool -  26 +26
__kstrtab_gen_pool_alloc_algo_owner-  26 +26
__kstrtab_gen_pool_first_fit_align -  25 +25
gen_pool_avail -  24 +24
__kstrtab_gen_pool_for_each_chunk  -  24 +24
__kstrtab_gen_pool_virt_to_phys-  22 +22
__kstrtab_gen_pool_fixed_alloc -  21 +21
__kstrtab_devm_gen_pool_create -  21 +21
arch_dma_coherent_to_pfn   -  20 +20
__kstrtab_gen_pool_free_owner  -  20 +20
__kstrtab_gen_pool_first_fit   -  19 +19
__kstrtab_gen_pool_dma_alloc   -  19 +19
__kstrtab_gen_pool_add_owner

Re: [RFC] switch m68k to use the generic remapping DMA allocator

2019-06-25 Thread Geert Uytterhoeven
Hi Christoph,

On Tue, Jun 25, 2019 at 8:33 AM Christoph Hellwig  wrote:
> On Mon, Jun 17, 2019 at 08:53:55PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig  wrote:
> > > can you take a look at the (untested) patches below?  They convert m68k
> > > to use the generic remapping DMA allocator, which is also used by
> > > arm64 and csky.
> >
> > Thanks. But what does this buy us?
>
> A common dma mapping code base with everyone, including supporting
> DMA allocations from atomic context, which the documentation and
> API assume are there, but which don't work on m68k.

OK, thanks!

> > bloat-o-meter says:
> >
> > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040)
>
> What do these values stand for?  The code should grow a little as
> we now need to include the the pool allocator for the above API
> fix.

Last 3 values are "bytes added/removed (net increase)".
So this increases the static kernel size by ca. 4 KiB.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [RFC] switch m68k to use the generic remapping DMA allocator

2019-06-24 Thread Geert Uytterhoeven
Hi Christoph,

On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig  wrote:
> can you take a look at the (untested) patches below?  They convert m68k
> to use the generic remapping DMA allocator, which is also used by
> arm64 and csky.

When building for Sun-3:

kernel/dma/remap.o: In function `arch_dma_alloc':
remap.c:(.text+0x316): undefined reference to `__dma_direct_alloc_pages'
remap.c:(.text+0x32a): undefined reference to `arch_dma_prep_coherent'
remap.c:(.text+0x34e): undefined reference to `arch_dma_mmap_pgprot'
remap.c:(.text+0x378): undefined reference to `__dma_direct_free_pages'
remap.c:(.text+0x3f4): undefined reference to `arch_dma_prep_coherent'
remap.c:(.text+0x40a): undefined reference to `__dma_direct_alloc_pages'
kernel/dma/remap.o: In function `arch_dma_free':
remap.c:(.text+0x446): undefined reference to `__dma_direct_free_pages'
remap.c:(.text+0x4a8): undefined reference to `__dma_direct_free_pages'
kernel/dma/remap.o: In function `dma_atomic_pool_init':
remap.c:(.init.text+0x66): undefined reference to `arch_dma_prep_coherent'

Doing

-   select DMA_DIRECT_REMAP if MMU && !COLDFIRE
+   select DMA_DIRECT_REMAP if MMU && !COLDFIRE && !SUN3

in arch/m68k/Kconfig fixes the build.

Alternatively, you could use:

-   select DMA_DIRECT_REMAP if MMU && !COLDFIRE
+   select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [RFC] switch m68k to use the generic remapping DMA allocator

2019-06-17 Thread Geert Uytterhoeven
Hi Christoph,

On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig  wrote:
> can you take a look at the (untested) patches below?  They convert m68k
> to use the generic remapping DMA allocator, which is also used by
> arm64 and csky.

Thanks. But what does this buy us?

bloat-o-meter says:

add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [RFC PATCH v6 4/5] mmc: tmio: Use dma_max_mapping_size() instead of a workaround

2019-06-17 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Mon, Jun 17, 2019 at 6:54 AM Yoshihiro Shimoda
 wrote:
> > From: Geert Uytterhoeven, Sent: Friday, June 14, 2019 4:27 PM
> > On Fri, Jun 14, 2019 at 9:18 AM Christoph Hellwig wrote:
> > > On Thu, Jun 13, 2019 at 10:35:44PM +0200, Geert Uytterhoeven wrote:
> > > > I'm always triggered by the use of min_t() and other casts:
> > > > mmc->max_blk_size and mmc->max_blk_count are both unsigned int.
> > > > dma_max_mapping_size() returns size_t, which can be 64-bit.
> > > >
> > > >  1) Can the multiplication overflow?
> > > > Probably not, as per commit 2a55c1eac7882232 ("mmc: renesas_sdhi:
> > > > prevent overflow for max_req_size"), but I thought I'd better ask.
>
> Geert-san:
>
> I agree.
>
> > > >  2) In theory, dma_max_mapping_size() can return a number that doesn't
> > > > fit in 32-bit, and will be truncated (to e.g. 0), leading to 
> > > > max_req_size
> > > > is zero?
>
> Geert-san:
>
> I agree. If dma_max_mapping_size() return 0x1__, it will be truncated 
> to 0
> and then max_req_size is set to zero. It is a problem. Also, the second 
> argument
> "mmc->max_blk_size * mmc->max_blk_count" will not be overflow and then the 
> value is
> 0x_ or less. So, I also think this should use size_t instead of 
> unsigned int.
>
> > > This really should use a min_t on size_t.  Otherwise the patch looks
> > > fine:
> >
> > Followed by another min() to make it fit in mmc->max_req_size, which is
> > unsigned int.
>
> Geert-san:
>
> I'm afraid, but I cannot understand this means.
> Is this patch is possible to be upstream? Or, do you have any concern?

Please disregard my last comment: as the value of "mmc->max_blk_size *
mmc->max_blk_count" is always 0x_ or less, "min_t(size_t,
mmc->max_blk_size * mmc->max_blk_count, dma_max_mapping_size(>dev))"
will always be 0x_ or less, too, so there is no extra step needed
to make it fit in mmc->max_req_size.


Sorry for the confusion.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH v6 4/5] mmc: tmio: Use dma_max_mapping_size() instead of a workaround

2019-06-14 Thread Geert Uytterhoeven
Hi Christoph,

On Fri, Jun 14, 2019 at 9:18 AM Christoph Hellwig  wrote:
> On Thu, Jun 13, 2019 at 10:35:44PM +0200, Geert Uytterhoeven wrote:
> > I'm always triggered by the use of min_t() and other casts:
> > mmc->max_blk_size and mmc->max_blk_count are both unsigned int.
> > dma_max_mapping_size() returns size_t, which can be 64-bit.
> >
> >  1) Can the multiplication overflow?
> > Probably not, as per commit 2a55c1eac7882232 ("mmc: renesas_sdhi:
> > prevent overflow for max_req_size"), but I thought I'd better ask.
> >  2) In theory, dma_max_mapping_size() can return a number that doesn't
> > fit in 32-bit, and will be truncated (to e.g. 0), leading to 
> > max_req_size
> > is zero?
>
> This really should use a min_t on size_t.  Otherwise the patch looks
> fine:

Followed by another min() to make it fit in mmc->max_req_size, which is
unsigned int.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH v6 4/5] mmc: tmio: Use dma_max_mapping_size() instead of a workaround

2019-06-13 Thread Geert Uytterhoeven
Hi Shimoda-san,

On Thu, Jun 13, 2019 at 5:37 PM Yoshihiro Shimoda
 wrote:
> Since the commit 133d624b1cee ("dma: Introduce dma_max_mapping_size()")
> provides a helper function to get the max mapping size, we can use
> the function instead of the workaround code for swiotlb.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks for your patch!

> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c

> @@ -1189,19 +1190,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
> mmc->max_blk_size = TMIO_MAX_BLK_SIZE;
> mmc->max_blk_count = pdata->max_blk_count ? :
> (PAGE_SIZE / mmc->max_blk_size) * mmc->max_segs;
> -   mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
> -   /*
> -* Since swiotlb has memory size limitation, this will calculate
> -* the maximum size locally (because we don't have any APIs for it 
> now)
> -* and check the current max_req_size. And then, this will update
> -* the max_req_size if needed as a workaround.
> -*/
> -   if (swiotlb_max_segment()) {
> -   unsigned int max_size = (1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
> -
> -   if (mmc->max_req_size > max_size)
> -   mmc->max_req_size = max_size;
> -   }
> +   mmc->max_req_size = min_t(unsigned int,
> + mmc->max_blk_size * mmc->max_blk_count,
> + dma_max_mapping_size(>dev));
> mmc->max_seg_size = mmc->max_req_size;

I'm always triggered by the use of min_t() and other casts:
mmc->max_blk_size and mmc->max_blk_count are both unsigned int.
dma_max_mapping_size() returns size_t, which can be 64-bit.

 1) Can the multiplication overflow?
Probably not, as per commit 2a55c1eac7882232 ("mmc: renesas_sdhi:
prevent overflow for max_req_size"), but I thought I'd better ask.
 2) In theory, dma_max_mapping_size() can return a number that doesn't
fit in 32-bit, and will be truncated (to e.g. 0), leading to max_req_size
is zero?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v4 2/6] iommu/ipmmu-vmsa: Prepare to handle 40-bit error addresses

2019-05-27 Thread Geert Uytterhoeven
On R-Car Gen3, the faulting virtual address is a 40-bit address, and
comprised of two registers.  Read the upper address part, and combine
both parts, when running on a 64-bit system.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Yoshihiro Shimoda 
---
Apart from this, the driver doesn't support 40-bit IOVA addresses yet.

v4:
  - Add Reviewed-by, Tested-by,

v3:
  - Add Reviewed-by,

v2:
  - Merge IMEAR/IMELAR.
---
 drivers/iommu/ipmmu-vmsa.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9f2b781e20a0eba6..f2061bd1dc7b8852 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -186,7 +186,8 @@ static struct ipmmu_vmsa_device *to_ipmmu(struct device 
*dev)
 #define IMMAIR_ATTR_IDX_WBRWA  1
 #define IMMAIR_ATTR_IDX_DEV2
 
-#define IMEAR  0x0030
+#define IMELAR 0x0030  /* IMEAR on R-Car Gen2 */
+#define IMEUAR 0x0034  /* R-Car Gen3 only */
 
 #define IMPCTR 0x0200
 #define IMPSTR 0x0208
@@ -522,14 +523,16 @@ static irqreturn_t ipmmu_domain_irq(struct 
ipmmu_vmsa_domain *domain)
 {
const u32 err_mask = IMSTR_MHIT | IMSTR_ABORT | IMSTR_PF | IMSTR_TF;
struct ipmmu_vmsa_device *mmu = domain->mmu;
+   unsigned long iova;
u32 status;
-   u32 iova;
 
status = ipmmu_ctx_read_root(domain, IMSTR);
if (!(status & err_mask))
return IRQ_NONE;
 
-   iova = ipmmu_ctx_read_root(domain, IMEAR);
+   iova = ipmmu_ctx_read_root(domain, IMELAR);
+   if (IS_ENABLED(CONFIG_64BIT))
+   iova |= (u64)ipmmu_ctx_read_root(domain, IMEUAR) << 32;
 
/*
 * Clear the error status flags. Unlike traditional interrupt flag
@@ -541,10 +544,10 @@ static irqreturn_t ipmmu_domain_irq(struct 
ipmmu_vmsa_domain *domain)
 
/* Log fatal errors. */
if (status & IMSTR_MHIT)
-   dev_err_ratelimited(mmu->dev, "Multiple TLB hits @0x%08x\n",
+   dev_err_ratelimited(mmu->dev, "Multiple TLB hits @0x%lx\n",
iova);
if (status & IMSTR_ABORT)
-   dev_err_ratelimited(mmu->dev, "Page Table Walk Abort @0x%08x\n",
+   dev_err_ratelimited(mmu->dev, "Page Table Walk Abort @0x%lx\n",
iova);
 
if (!(status & (IMSTR_PF | IMSTR_TF)))
@@ -560,7 +563,7 @@ static irqreturn_t ipmmu_domain_irq(struct 
ipmmu_vmsa_domain *domain)
return IRQ_HANDLED;
 
dev_err_ratelimited(mmu->dev,
-   "Unhandled fault: status 0x%08x iova 0x%08x\n",
+   "Unhandled fault: status 0x%08x iova 0x%lx\n",
status, iova);
 
return IRQ_HANDLED;
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v4 5/6] iommu/ipmmu-vmsa: Extract hardware context initialization

2019-05-27 Thread Geert Uytterhoeven
ipmmu_domain_init_context() takes care of (1) initializing the software
domain, and (2) initializing the hardware context for the domain.

Extract the code to initialize the hardware context into a new subroutine
ipmmu_domain_setup_context(), to prepare for later reuse.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Yoshihiro Shimoda 
---
v4:
  - Add Reviewed-by, Tested-by,

v3:
  - Add Reviewed-by,

v2:
  - s/ipmmu_context_init/ipmmu_domain_setup_context/.
---
 drivers/iommu/ipmmu-vmsa.c | 91 --
 1 file changed, 48 insertions(+), 43 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 3fa57627b1e35562..56e84bcc9532e1ce 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -404,52 +404,10 @@ static void ipmmu_domain_free_context(struct 
ipmmu_vmsa_device *mmu,
spin_unlock_irqrestore(>lock, flags);
 }
 
-static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain)
+static void ipmmu_domain_setup_context(struct ipmmu_vmsa_domain *domain)
 {
u64 ttbr;
u32 tmp;
-   int ret;
-
-   /*
-* Allocate the page table operations.
-*
-* VMSA states in section B3.6.3 "Control of Secure or Non-secure memory
-* access, Long-descriptor format" that the NStable bit being set in a
-* table descriptor will result in the NStable and NS bits of all child
-* entries being ignored and considered as being set. The IPMMU seems
-* not to comply with this, as it generates a secure access page fault
-* if any of the NStable and NS bits isn't set when running in
-* non-secure mode.
-*/
-   domain->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS;
-   domain->cfg.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K;
-   domain->cfg.ias = 32;
-   domain->cfg.oas = 40;
-   domain->cfg.tlb = _gather_ops;
-   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(32);
-   domain->io_domain.geometry.force_aperture = true;
-   /*
-* TODO: Add support for coherent walk through CCI with DVM and remove
-* cache handling. For now, delegate it to the io-pgtable code.
-*/
-   domain->cfg.iommu_dev = domain->mmu->root->dev;
-
-   /*
-* Find an unused context.
-*/
-   ret = ipmmu_domain_allocate_context(domain->mmu->root, domain);
-   if (ret < 0)
-   return ret;
-
-   domain->context_id = ret;
-
-   domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
-  domain);
-   if (!domain->iop) {
-   ipmmu_domain_free_context(domain->mmu->root,
- domain->context_id);
-   return -EINVAL;
-   }
 
/* TTBR0 */
ttbr = domain->cfg.arm_lpae_s1_cfg.ttbr[0];
@@ -495,7 +453,54 @@ static int ipmmu_domain_init_context(struct 
ipmmu_vmsa_domain *domain)
 */
ipmmu_ctx_write_all(domain, IMCTR,
IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
+}
+
+static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain)
+{
+   int ret;
+
+   /*
+* Allocate the page table operations.
+*
+* VMSA states in section B3.6.3 "Control of Secure or Non-secure memory
+* access, Long-descriptor format" that the NStable bit being set in a
+* table descriptor will result in the NStable and NS bits of all child
+* entries being ignored and considered as being set. The IPMMU seems
+* not to comply with this, as it generates a secure access page fault
+* if any of the NStable and NS bits isn't set when running in
+* non-secure mode.
+*/
+   domain->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS;
+   domain->cfg.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K;
+   domain->cfg.ias = 32;
+   domain->cfg.oas = 40;
+   domain->cfg.tlb = _gather_ops;
+   domain->io_domain.geometry.aperture_end = DMA_BIT_MASK(32);
+   domain->io_domain.geometry.force_aperture = true;
+   /*
+* TODO: Add support for coherent walk through CCI with DVM and remove
+* cache handling. For now, delegate it to the io-pgtable code.
+*/
+   domain->cfg.iommu_dev = domain->mmu->root->dev;
+
+   /*
+* Find an unused context.
+*/
+   ret = ipmmu_domain_allocate_context(domain->mmu->root, domain);
+   if (ret < 0)
+   return ret;
+
+   domain->context_id = ret;
+
+   domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
+  domain);
+   if (!domain->iop) {
+   ipmmu_domain_free_context(domain->mmu->root,
+ domain->context_id);
+   return -EINVAL;
+   }
 
+   ipmmu_domain_setup_context(domain);
return 0;
 }
 
-- 
2.17.1



[PATCH v4 6/6] iommu/ipmmu-vmsa: Add suspend/resume support

2019-05-27 Thread Geert Uytterhoeven
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and all
IPMMU state is lost.  Hence after s2ram, devices wired behind an IPMMU,
and configured to use it, will see their DMA operations hang.

To fix this, restore all IPMMU contexts, and re-enable all active
micro-TLBs during system resume.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Yoshihiro Shimoda 
---
This patch takes a different approach than the BSP, which implements a
bulk save/restore of all registers during system suspend/resume.

v4:
  - Add Reviewed-by, Tested-by,

v3:
  - No changes,

v2:
  - Drop PSCI checks.
---
 drivers/iommu/ipmmu-vmsa.c | 47 +-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 56e84bcc9532e1ce..408ad0b2591925e0 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -36,7 +36,10 @@
 #define arm_iommu_detach_device(...)   do {} while (0)
 #endif
 
-#define IPMMU_CTX_MAX 8U
+#define IPMMU_CTX_MAX  8U
+#define IPMMU_CTX_INVALID  -1
+
+#define IPMMU_UTLB_MAX 48U
 
 struct ipmmu_features {
bool use_ns_alias_offset;
@@ -58,6 +61,7 @@ struct ipmmu_vmsa_device {
spinlock_t lock;/* Protects ctx and domains[] */
DECLARE_BITMAP(ctx, IPMMU_CTX_MAX);
struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX];
+   s8 utlb_ctx[IPMMU_UTLB_MAX];
 
struct iommu_group *group;
struct dma_iommu_mapping *mapping;
@@ -335,6 +339,7 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain 
*domain,
ipmmu_write(mmu, IMUCTR(utlb),
IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_FLUSH |
IMUCTR_MMUEN);
+   mmu->utlb_ctx[utlb] = domain->context_id;
 }
 
 /*
@@ -346,6 +351,7 @@ static void ipmmu_utlb_disable(struct ipmmu_vmsa_domain 
*domain,
struct ipmmu_vmsa_device *mmu = domain->mmu;
 
ipmmu_write(mmu, IMUCTR(utlb), 0);
+   mmu->utlb_ctx[utlb] = IPMMU_CTX_INVALID;
 }
 
 static void ipmmu_tlb_flush_all(void *cookie)
@@ -1043,6 +1049,7 @@ static int ipmmu_probe(struct platform_device *pdev)
spin_lock_init(>lock);
bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
mmu->features = of_device_get_match_data(>dev);
+   memset(mmu->utlb_ctx, IPMMU_CTX_INVALID, mmu->features->num_utlbs);
dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(40));
 
/* Map I/O memory and request IRQ. */
@@ -1158,10 +1165,48 @@ static int ipmmu_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int ipmmu_resume_noirq(struct device *dev)
+{
+   struct ipmmu_vmsa_device *mmu = dev_get_drvdata(dev);
+   unsigned int i;
+
+   /* Reset root MMU and restore contexts */
+   if (ipmmu_is_root(mmu)) {
+   ipmmu_device_reset(mmu);
+
+   for (i = 0; i < mmu->num_ctx; i++) {
+   if (!mmu->domains[i])
+   continue;
+
+   ipmmu_domain_setup_context(mmu->domains[i]);
+   }
+   }
+
+   /* Re-enable active micro-TLBs */
+   for (i = 0; i < mmu->features->num_utlbs; i++) {
+   if (mmu->utlb_ctx[i] == IPMMU_CTX_INVALID)
+   continue;
+
+   ipmmu_utlb_enable(mmu->root->domains[mmu->utlb_ctx[i]], i);
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops ipmmu_pm  = {
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(NULL, ipmmu_resume_noirq)
+};
+#define DEV_PM_OPS _pm
+#else
+#define DEV_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
 static struct platform_driver ipmmu_driver = {
.driver = {
.name = "ipmmu-vmsa",
.of_match_table = of_match_ptr(ipmmu_of_ids),
+   .pm = DEV_PM_OPS,
},
.probe = ipmmu_probe,
.remove = ipmmu_remove,
-- 
2.17.1



[PATCH v4 1/6] iommu/ipmmu-vmsa: Link IOMMUs and devices in sysfs

2019-05-27 Thread Geert Uytterhoeven
As of commit 7af9a5fdb9e0ca33 ("iommu/ipmmu-vmsa: Use
iommu_device_sysfs_add()/remove()"), IOMMU devices show up under
/sys/class/iommu/, but their "devices" subdirectories are empty.
Likewise, devices tied to an IOMMU do not have an "iommu" backlink.

Make sure all links are created, on both arm32 and arm64.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Yoshihiro Shimoda 
---
v4:
  - Add Reviewed-by, Tested-by,

v3:
  - Fix sysfs path typo in patch description,

v2:
  - Add Reviewed-by.
---
 drivers/iommu/ipmmu-vmsa.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9a380c10655e182d..9f2b781e20a0eba6 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -885,27 +885,37 @@ static int ipmmu_init_arm_mapping(struct device *dev)
 
 static int ipmmu_add_device(struct device *dev)
 {
+   struct ipmmu_vmsa_device *mmu = to_ipmmu(dev);
struct iommu_group *group;
+   int ret;
 
/*
 * Only let through devices that have been verified in xlate()
 */
-   if (!to_ipmmu(dev))
+   if (!mmu)
return -ENODEV;
 
-   if (IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_IOMMU_DMA))
-   return ipmmu_init_arm_mapping(dev);
+   if (IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_IOMMU_DMA)) {
+   ret = ipmmu_init_arm_mapping(dev);
+   if (ret)
+   return ret;
+   } else {
+   group = iommu_group_get_for_dev(dev);
+   if (IS_ERR(group))
+   return PTR_ERR(group);
 
-   group = iommu_group_get_for_dev(dev);
-   if (IS_ERR(group))
-   return PTR_ERR(group);
+   iommu_group_put(group);
+   }
 
-   iommu_group_put(group);
+   iommu_device_link(>iommu, dev);
return 0;
 }
 
 static void ipmmu_remove_device(struct device *dev)
 {
+   struct ipmmu_vmsa_device *mmu = to_ipmmu(dev);
+
+   iommu_device_unlink(>iommu, dev);
arm_iommu_detach_device(dev);
iommu_group_remove_device(dev);
 }
-- 
2.17.1



[PATCH v4 0/6] iommu/ipmmu-vmsa: Suspend/resume support and assorted cleanups

2019-05-27 Thread Geert Uytterhoeven
Hi Jörg, Magnus,

On R-Car Gen3 systems with PSCI, PSCI may power down the SoC during
system suspend, thus losing all IOMMU state.  Hence after s2ram, devices
behind an IPMMU (e.g. SATA), and configured to use it, will fail to
complete their I/O operations.

This patch series adds suspend/resume support to the Renesas IPMMU-VMSA
IOMMU driver, and performs some smaller cleanups and fixes during the
process.  Most patches are fairly independent, except for patch 6/6,
which depends on patches 4/6 and 5/6.

Changes compared to v3:
  - Add Reviewed-by, Tested-by.

Changes compared to v2:
  - Fix sysfs path typo in patch description,
  - Add Reviewed-by.

Changes compared to v1:
  - Dropped "iommu/ipmmu-vmsa: Call ipmmu_ctx_write_root() instead of
open coding",
  - Add Reviewed-by,
  - Merge IMEAR/IMELAR,
  - s/ipmmu_context_init/ipmmu_domain_setup_context/,
  - Drop PSCI checks.

This has been tested on Salvator-XS with R-Car H3 ES2.0, with IPMMU
suport for SATA enabled.  To play safe, the resume operation has also
been tested on R-Car M2-W.

Is there anything still blocking the integration of this patch series?
If not, please apply.

Thanks!

Geert Uytterhoeven (6):
  iommu/ipmmu-vmsa: Link IOMMUs and devices in sysfs
  iommu/ipmmu-vmsa: Prepare to handle 40-bit error addresses
  iommu/ipmmu-vmsa: Make IPMMU_CTX_MAX unsigned
  iommu/ipmmu-vmsa: Move num_utlbs to SoC-specific features
  iommu/ipmmu-vmsa: Extract hardware context initialization
  iommu/ipmmu-vmsa: Add suspend/resume support

 drivers/iommu/ipmmu-vmsa.c | 185 +
 1 file changed, 124 insertions(+), 61 deletions(-)

-- 
2.17.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH v4 3/6] iommu/ipmmu-vmsa: Make IPMMU_CTX_MAX unsigned

2019-05-27 Thread Geert Uytterhoeven
Make the IPMMU_CTX_MAX constant unsigned, to match the type of
ipmmu_features.number_of_contexts.

This allows to use plain min() instead of type-casting min_t().

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Simon Horman 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Yoshihiro Shimoda 
---
v4:
  - Add Reviewed-by, Tested-by,

v3:
  - Add Reviewed-by,

v2:
  - Add Reviewed-by.
---
 drivers/iommu/ipmmu-vmsa.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index f2061bd1dc7b8852..87acf86f295fac0d 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -36,7 +36,7 @@
 #define arm_iommu_detach_device(...)   do {} while (0)
 #endif
 
-#define IPMMU_CTX_MAX 8
+#define IPMMU_CTX_MAX 8U
 
 struct ipmmu_features {
bool use_ns_alias_offset;
@@ -1060,8 +1060,7 @@ static int ipmmu_probe(struct platform_device *pdev)
if (mmu->features->use_ns_alias_offset)
mmu->base += IM_NS_ALIAS_OFFSET;
 
-   mmu->num_ctx = min_t(unsigned int, IPMMU_CTX_MAX,
-mmu->features->number_of_contexts);
+   mmu->num_ctx = min(IPMMU_CTX_MAX, mmu->features->number_of_contexts);
 
irq = platform_get_irq(pdev, 0);
 
-- 
2.17.1



  1   2   3   4   >