Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

[Geert Uytterhoeven]

Hi Niklas,

Thanks for your patch!

On Thu, Aug 30, 2018 at 11:39 PM Niklas Söderlund
 wrote:
> Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
> device_dma_parameters structure and filling in the max segment size. The
> size used is the result of a discussion with Renesas hardware engineers
> and unfortunately not found in the datasheet.
>
>   renesas_sdhi_internal_dmac ee14.sd: DMA-API: mapping sg segment
>   longer than device claims to support [len=126976] [max=65536A]

Bogus trailing "A".

> Signed-off-by: Niklas Söderlund 
> Reported-by: Geert Uytterhoeven 
>
> ---
>
> * Changes since v1
> - Use devm_kzalloc() instead of a custom remove function to clean up.
> ---
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index c9dab9ce1ed55174..715e0c5dc30e4ebf 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -308,12 +308,23 @@ static const struct soc_device_attribute 
> gen3_soc_whitelist[] = {
>  static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
>  {
> const struct soc_device_attribute *soc = 
> soc_device_match(gen3_soc_whitelist);
> +   struct device *dev = >dev;
>
> if (!soc)
> return -ENODEV;
>
> global_flags |= (unsigned long)soc->data;
>
> +   if (!dev->dma_parms) {

I guess dev->dma_parms is retained on unbind/rebind?

> +   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> + GFP_KERNEL);

But by using devm_kzalloc(), the memory will be freed, and lead to reuse after
free?

> +   if (!dev->dma_parms)
> +   return -ENOMEM;
> +   }
> +
> +   if (dma_set_max_seg_size(dev, 0x))
> +   dev_warn(dev, "Unable to set seg size\n");
> +
> return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
>  }

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] clk: renesas: r8a77990: Add missing I2C7 clock

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-08-30 08:28:13)
> When trying to use I2C7 on R-Car E3:
> 
> renesas-cpg-mssr e615.clock-controller: Cannot get module clock 1003: 
> -2
> i2c-rcar e669.i2c: failed to add to PM domain always-on: -2
> i2c-rcar: probe of e669.i2c failed with error -2
> 
> Unlike other R-Car Gen3 SoCs, R-Car E3 has more than 7 I2C bus
> interfaces.  Add the forgotten module clock for the 8th instance to fix
> this.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

Reviewed-by: Stephen Boyd 

[PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

[Niklas Söderlund]

Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
device_dma_parameters structure and filling in the max segment size. The
size used is the result of a discussion with Renesas hardware engineers
and unfortunately not found in the datasheet.

  renesas_sdhi_internal_dmac ee14.sd: DMA-API: mapping sg segment
  longer than device claims to support [len=126976] [max=65536A]

Signed-off-by: Niklas Söderlund 
Reported-by: Geert Uytterhoeven 

---

* Changes since v1
- Use devm_kzalloc() instead of a custom remove function to clean up.
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index c9dab9ce1ed55174..715e0c5dc30e4ebf 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -308,12 +308,23 @@ static const struct soc_device_attribute 
gen3_soc_whitelist[] = {
 static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
 {
const struct soc_device_attribute *soc = 
soc_device_match(gen3_soc_whitelist);
+   struct device *dev = >dev;
 
if (!soc)
return -ENODEV;
 
global_flags |= (unsigned long)soc->data;
 
+   if (!dev->dma_parms) {
+   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
+ GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+
+   if (dma_set_max_seg_size(dev, 0x))
+   dev_warn(dev, "Unable to set seg size\n");
+
return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
 }
 
-- 
2.18.0

Re: [PATCH 0/3] i2c: refactor releasing a DMA safe buffer

[Wolfram Sang]

On Fri, Aug 24, 2018 at 04:52:43PM +0200, Wolfram Sang wrote:
> Jun Gao correctly identified a problem when freeing a DMA safe buffer [1], 
> many
> thanks for that! However, I'd like to not introduce yet another function. So, 
> I
> thought about changing the existing API to support the case of freeing a 
> buffer
> in case no sync back to the message is needed. Here is what I came up with and
> I like the new way better.
> 
> Once this is set in place, the only existing user so far, has been fixed. It
> was leaking the bounce buffer on error cases before. Tested on a Renesas Lager
> board (R-Car H2).
> 
> Please let me know your thoughts. Jun Gao, does it work for you as well?
> 
> If all goes well, I would like to apply it for -rc2. But I am still open for
> comments, of course.
> 
> Thanks and happy hacking,
> 
>Wolfram

Applied all to for-current.



signature.asc
Description: PGP signature

[PATCH] clocksource: sh_cmt: fixup for 64-bit machines

[Sergei Shtylyov]

When trying to use CMT for clockevents on R-Car gen3 SoCs, I noticed that
the maximum delta (in ns) for the broadcast timer was diplayed as 1000 in
/proc/timer_list.  It turned out that when calculating it, the driver did
shift left 1 by 32 (causing what I think was undefined behaviour) getting
1 as a result. Using 1UL instead fixed the maximum delta and did even fix
switching an active clocksource to a CMT channel (which caused the system
to go non-interactive before).

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'tip.git' repo's 'timers/core' branch.

I am not sure whether the CMT driver was ever used on SH64; on R-Car gen3
(ARM64) I'm only enabling this driver now, so not sure how urgent is this...

 drivers/clocksource/sh_cmt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: tip/drivers/clocksource/sh_cmt.c
===
--- tip.orig/drivers/clocksource/sh_cmt.c
+++ tip/drivers/clocksource/sh_cmt.c
@@ -891,7 +891,7 @@ static int sh_cmt_setup_channel(struct s
if (cmt->info->width == (sizeof(ch->max_match_value) * 8))
ch->max_match_value = ~0;
else
-   ch->max_match_value = (1 << cmt->info->width) - 1;
+   ch->max_match_value = (1UL << cmt->info->width) - 1;
 
ch->match_value = ch->max_match_value;
raw_spin_lock_init(>lock);

[PATCH] clk: renesas: r8a77990: Add missing I2C7 clock

[Geert Uytterhoeven]

When trying to use I2C7 on R-Car E3:

renesas-cpg-mssr e615.clock-controller: Cannot get module clock 1003: -2
i2c-rcar e669.i2c: failed to add to PM domain always-on: -2
i2c-rcar: probe of e669.i2c failed with error -2

Unlike other R-Car Gen3 SoCs, R-Car E3 has more than 7 I2C bus
interfaces.  Add the forgotten module clock for the 8th instance to fix
this.

Signed-off-by: Geert Uytterhoeven 
---
To be queued in clk-renesas-for-v4.20.

 drivers/clk/renesas/r8a77990-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c 
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
index 9437219efdd98e34..7e000d0705891a3f 100644
--- a/drivers/clk/renesas/r8a77990-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
@@ -210,6 +210,7 @@ static const struct mssr_mod_clk r8a77990_mod_clks[] 
__initconst = {
DEF_MOD("i2c1",  930,   R8A77990_CLK_S3D2),
DEF_MOD("i2c0",  931,   R8A77990_CLK_S3D2),
 
+   DEF_MOD("i2c7", 1003,   R8A77990_CLK_S3D2),
DEF_MOD("ssi-all",  1005,   R8A77990_CLK_S3D4),
DEF_MOD("ssi9", 1006,   MOD_CLK_ID(1005)),
DEF_MOD("ssi8", 1007,   MOD_CLK_ID(1005)),
-- 
2.17.1

[PATCH] arm64: dts: renesas: r8a77990: Add BRG support to SCIF2

[Geert Uytterhoeven]

From: Takeshi Kihara 

Add the device node for the external SCIF_CLK, and describe the clock
inputs for the Baud Rate Generator for External Clock (BRG) for SCIF2,
which can increase serial clock accuracy.

The presence of the SCIF_CLK crystal and its clock frequency depend on
the actual board.

Signed-off-by: Takeshi Kihara 
[geert: Enhance patch description]
Signed-off-by: Geert Uytterhoeven 
---
Note: The Ebisu board does not provide SCIF_CLK.  However, using the BRG
  increases the serial console's clock accurary from 115200+541 bps
  to 115200-257 bps.
---
 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index e2c2d1480a68cf1b..6198768264bece81 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -63,6 +63,13 @@
method = "smc";
};
 
+   /* External SCIF clock - to be overridden by boards that provide it */
+   scif_clk: scif {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
soc: soc {
compatible = "simple-bus";
interrupt-parent = <>;
@@ -412,8 +419,11 @@
 "renesas,rcar-gen3-scif", "renesas,scif";
reg = <0 0xe6e88000 0 64>;
interrupts = ;
-   clocks = < CPG_MOD 310>;
-   clock-names = "fck";
+   clocks = < CPG_MOD 310>,
+< CPG_CORE R8A77990_CLK_S3D1C>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+
power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 310>;
status = "disabled";
-- 
2.17.1

[PATCH] arm64: dts: renesas: r8a77990: Use CPG/MSSR and SYSC binding definitions

[Geert Uytterhoeven]

Use the SoC-specific CPG/MSSR include file to allow future use of
R8A77990_CLK_* symbols.
Replace the hardcoded power domain indices by R8A77990_PD_* symbols.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 +++
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 2ee0edfb18d4b9d6..e2c2d1480a68cf1b 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -5,7 +5,7 @@
  * Copyright (C) 2018 Renesas Electronics Corp.
  */
 
-#include 
+#include 
 #include 
 #include 
 
@@ -22,7 +22,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0>;
device_type = "cpu";
-   power-domains = < 5>;
+   power-domains = < R8A77990_PD_CA53_CPU0>;
next-level-cache = <_CA53>;
enable-method = "psci";
};
@@ -31,14 +31,14 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <1>;
device_type = "cpu";
-   power-domains = < 6>;
+   power-domains = < R8A77990_PD_CA53_CPU1>;
next-level-cache = <_CA53>;
enable-method = "psci";
};
 
L2_CA53: cache-controller-0 {
compatible = "cache";
-   power-domains = < 21>;
+   power-domains = < R8A77990_PD_CA53_SCU>;
cache-unified;
cache-level = <2>;
};
@@ -75,7 +75,7 @@
 "renesas,rcar-gen3-wdt";
reg = <0 0xe602 0 0x0c>;
clocks = < CPG_MOD 402>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 402>;
status = "disabled";
};
@@ -91,7 +91,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 912>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 912>;
};
 
@@ -106,7 +106,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 911>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 911>;
};
 
@@ -121,7 +121,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 910>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 910>;
};
 
@@ -136,7 +136,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 909>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 909>;
};
 
@@ -151,7 +151,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 908>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 908>;
};
 
@@ -166,7 +166,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 907>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 907>;
};
 
@@ -181,7 +181,7 @@
#interrupt-cells = <2>;
interrupt-controller;
clocks = < CPG_MOD 906>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 906>;
};
 
@@ -329,7 +329,7 @@
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
-   power-domains = < 32>;
+   power-domains = < R8A77990_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
#address-cells = <1>;
@@ -414,7 

Re: [PATCH] arm64: dts: renesas: salvator-xs: Improve SATA switch settings comments

[Simon Horman]

On Thu, Aug 30, 2018 at 02:38:07PM +0200, Geert Uytterhoeven wrote:
> The comments describing the non-default switch settings to use SATA are
> confusing: 'Off' refers to the switch position, not to the MD12 logic
> value, while the parentheses suggest otherwise.  Rephrase to fix this.
> 
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Wolfram Sang 

Thanks Geert, thanks Wolfram, applied for v4.20.

Re: [PATCH 1/3] arm64: dts: renesas: r8a774a1: Add USB2.0 phy and host(EHCI/OHCI) device nodes

[Simon Horman]

On Thu, Aug 30, 2018 at 02:29:02PM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 24, 2018 at 12:50 PM Biju Das  wrote:
> > Add USB2.0 phy and host (EHCI/OHCI) device nodes on RZ/G2M SoC dtsi.
> >
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 73 
> > +++
> >  1 file changed, 73 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > index cd204f5..a794089 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> 
> > +   ehci0: usb@ee080100 {
> > +   compatible = "generic-ehci";
> > +   reg = <0 0xee080100 0 0x100>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 703>;
> > +   phys = <_phy0>;
> > +   phy-names = "usb";
> > +   companion= <>;
> 
> Please insert a space before the "=".

I fixed that by adding the update to your fixup patch for many similar
problems. Let me know if pain persists after I've pushed the devel branch.

> 
> > +   power-domains = < 32>;
> > +   resets = < 703>;
> > +   status = "disabled";
> > +   };
> > +
> > +   ehci1: usb@ee0a0100 {
> > +   compatible = "generic-ehci";
> > +   reg = <0 0xee0a0100 0 0x100>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 702>;
> > +   phys = <_phy1>;
> > +   phy-names = "usb";
> > +   companion= <>;
> 
> Likewise.
> 
> > +   power-domains = < 32>;
> > +   resets = < 702>;
> > +   status = "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
> 

Re: [PATCH v2] clk: renesas: cpg-mssr: Add R7S9210 support

[Geert Uytterhoeven]

Hi Rob,

On Thu, Aug 30, 2018 at 3:49 PM Rob Herring  wrote:
> On Thu, Aug 30, 2018 at 3:05 AM Geert Uytterhoeven  
> wrote:
> > On Wed, Aug 29, 2018 at 2:52 AM Rob Herring  wrote:
> > > On Mon, Aug 27, 2018 at 11:21:39AM -0500, Chris Brandt wrote:
> > > > Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> > > > Standby.
> > > >
> > > > The Module Standby HW in the RZ/A series is very close to R-Car HW, 
> > > > except
> > > > for how the registers are laid out.
> > > > The MSTP registers are only 8-bits wide, there is no status registers
> > > > (MSTPST), and the register offsets are a little different. Since the 
> > > > RZ/A
> > > > hardware manuals refer to these registers as the Standby Control 
> > > > Registers,
> > > > we'll use that name to distinguish the RZ/A type for the R-Car type.
> > > >
> > > > Signed-off-by: Chris Brandt 
> > > > ---
> > >
> > > > +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
> > > > @@ -0,0 +1,192 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > >
> > >
> > > > +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
> > > > @@ -0,0 +1,21 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0+
> > >
> > > The proper identifier is GPL-2.0-or-later
> >
> > Documentation/process/license-rules.rst disagrees.
>
> Indeed, but: https://spdx.org/licenses/GPL-2.0+.html
>
> I think this changed about the time the kernel adopted SPDX. I guess
> it is fine as-is until we change the documentation.

Unlikely to happen, cfr.
https://lore.kernel.org/lkml/20180822194613.gb3...@kroah.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: [PATCH] ARM: dts: r9a06g032: Use r9a06g032-sysctrl binding definitions

[Simon Horman]

On Thu, Aug 30, 2018 at 09:44:23AM +, Phil Edworthy wrote:
> Hi Geert,
> 
> On 28 August 2018 16:13, Geert Uytterhoeven wrote:
> > Replace the hardcoded clock indices by R9A06G032_CLK_* symbols.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> 
> Reviewed-by: Phil Edworthy 

Thanks Geert, thanks Phil, applied for v4.20.

Re: [PATCH] arm64: dts: renesas: r8a77965: Fix clock/reset for usb2_phy1

[Simon Horman]

On Thu, Aug 30, 2018 at 03:04:48AM +, Yoshihiro Shimoda wrote:
> Hi Geert-san,
> 
> > From: Geert Uytterhoeven, Sent: Tuesday, August 28, 2018 11:13 PM
> > 
> > usb2_phy1 accidentally uses the same clock/reset as usb2_phy0.
> > 
> > Fixes: b5857630a829a8d5 ("arm64: dts: renesas: r8a77965: add usb2_phy 
> > nodes")
> > Signed-off-by: Geert Uytterhoeven 
> 
> Thank you for the patch!
> 
> Reviewed-by: Yoshihiro Shimoda 

Thanks Geert, thanks Shimoda-san, applied for v4.20.

Re: [PATCH] arm64: dts: renesas: r8a77965: Fix HS-USB compatible

[Simon Horman]

On Thu, Aug 30, 2018 at 03:04:06AM +, Yoshihiro Shimoda wrote:
> Hi Geert-san,
> 
> > From: Geert Uytterhoeven, Sent: Tuesday, August 28, 2018 10:57 PM
> > 
> > Should be "renesas,usbhs-r8a77965", not "renesas,usbhs-r8a7796".
> > 
> > Fixes: a06e8af801760a98 ("arm64: dts: renesas: r8a77965: add HS-USB node")
> > Signed-off-by: Geert Uytterhoeven 
> 
> Thank you for the patch!
> 
> Reviewed-by: Yoshihiro Shimoda 

Thanks Geert, thanks Shimoda-san, applied for v4.20.

Re: [PATCH] arm64: dts: renesas: r8a77965: Move timer node

[Simon Horman]

On Wed, Aug 29, 2018 at 05:27:58PM +0200, Niklas Söderlund wrote:
> Hi Geert,
> 
> Thanks for your patch.
> 
> On 2018-08-28 16:14:44 +0200, Geert Uytterhoeven wrote:
> > To preserve alphabetical sort order.
> > 
> > Fixes: 4c529600eef0a6b7 ("arm64: dts: renesas: r8a77965: Add R-Car Gen3 
> > thermal support")
> > Signed-off-by: Geert Uytterhoeven 
> 
> Reviewed-by: Niklas Söderlund 

Thanks Geert, thanks Niklas, applied for v4.20.

Re: [PATCH] ARM: shmobile: defconfig: Refresh shmobile_defconfig for v4.19-rc1

[Simon Horman]

On Tue, Aug 28, 2018 at 04:56:46PM +0200, Geert Uytterhoeven wrote:
> Refresh the defconfig for Renesas ARM boards:
>   - Move options that have moved,
>   - Remove CONFIG_HAVE_ARM_ARCH_TIMER (auto-enabled),
>   - Remove ENABLE_WARN_DEPRECATED (removed).
> 
> Signed-off-by: Geert Uytterhoeven 

Thanks Geert, applied for v4.20.

Re: [PATCH] [LOCAL] arm64: renesas_defconfig: Enable CRYPTO_DEV_CCREE

[Simon Horman]

On Tue, Aug 28, 2018 at 04:47:52PM +0200, Geert Uytterhoeven wrote:
> Enable support for the CryptoCell core present in some R-Car Gen3 SoCs,
> which allows to offload crypto operations.
> 
> Signed-off-by: Geert Uytterhoeven 

Thanks,

I have applied this to the topic/renesas-defconfig branch which is included
in the devel branch and tags of the Renesas tree as a convenience to
developers.  The branch is not, however, included in the next branch or
tags nor is it targeted at upstream.

Re: [PATCH] [LOCAL] arm64: defconfig: Refresh renesas_defconfig for v4.19-rc1

[Simon Horman]

On Tue, Aug 28, 2018 at 04:46:15PM +0200, Geert Uytterhoeven wrote:
> Refresh the defconfig for Renesas R-Car Gen3 boards:
>   - Move options that have moved,
>   - Remove CONFIG_PCIE_DW_PLAT_HOST (auto-disabled),
>   - Remove CONFIG_DEBUG_FS (auto-enabled).
> 
> Signed-off-by: Geert Uytterhoeven 

Thanks,

I have applied this to the topic/renesas-defconfig branch which is included
in the devel branch and tags of the Renesas tree as a convenience to
developers.  The branch is not, however, included in the next branch or
tags nor is it targeted at upstream.

Re: [PATCH v2] clk: renesas: cpg-mssr: Add R7S9210 support

[Rob Herring]

On Thu, Aug 30, 2018 at 3:05 AM Geert Uytterhoeven  wrote:
>
> Hi Rob,
>
> On Wed, Aug 29, 2018 at 2:52 AM Rob Herring  wrote:
> > On Mon, Aug 27, 2018 at 11:21:39AM -0500, Chris Brandt wrote:
> > > Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> > > Standby.
> > >
> > > The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> > > for how the registers are laid out.
> > > The MSTP registers are only 8-bits wide, there is no status registers
> > > (MSTPST), and the register offsets are a little different. Since the RZ/A
> > > hardware manuals refer to these registers as the Standby Control 
> > > Registers,
> > > we'll use that name to distinguish the RZ/A type for the R-Car type.
> > >
> > > Signed-off-by: Chris Brandt 
> > > ---
> >
> > > +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
> > > @@ -0,0 +1,192 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> >
> >
> > > +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
> > > @@ -0,0 +1,21 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+
> >
> > The proper identifier is GPL-2.0-or-later
>
> Documentation/process/license-rules.rst disagrees.

Indeed, but: https://spdx.org/licenses/GPL-2.0+.html

I think this changed about the time the kernel adopted SPDX. I guess
it is fine as-is until we change the documentation.

Rob

Re: [PATCH] arm64: dts: r8a7796: Fix whitespace around assignments

[Geert Uytterhoeven]

Hi Simon,

On Thu, Aug 30, 2018 at 3:08 PM Simon Horman  wrote:
> On Tue, Aug 28, 2018 at 04:10:59PM +0200, Geert Uytterhoeven wrote:
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a774a1.dtsi|  4 +-
> >  arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 16 +++
> >  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 48 ++--
> >  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 48 ++--
> >  arch/arm64/boot/dts/renesas/r8a77965.dtsi| 36 +++
> >  arch/arm64/boot/dts/renesas/r8a77970.dtsi|  8 ++--
> >  arch/arm64/boot/dts/renesas/r8a77980.dtsi| 16 +++
> >  arch/arm64/boot/dts/renesas/ulcb-kf.dtsi |  2 +-
> >  8 files changed, 89 insertions(+), 89 deletions(-)
>
> Thanks Geert,
>
> I took the liberty of updating the subject with s/r8a7796/renesas/

Sorry, I thought I had fixed that. Probably on the wrong branch.

> and fixing a few more cases, likely ones that slipped in after you prepared
> this patch (and are currently only local to my tree).
>
> The incremental diff is:
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> index 2798c4c9cf94..010a9958693d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> @@ -1455,7 +1455,7 @@
> clocks = < CPG_MOD 703>;
> phys = <_phy0>;
> phy-names = "usb";
> -   companion= <>;
> +   companion = <>;
> power-domains = < 32>;
> resets = < 703>;
> status = "disabled";
> @@ -1468,7 +1468,7 @@
> clocks = < CPG_MOD 702>;
> phys = <_phy1>;
> phy-names = "usb";
> -   companion= <>;
> +   companion = <>;
> power-domains = < 32>;
> resets = < 702>;
> status = "disabled";
> diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi 
> b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> index 8bf3091a899c..1b316d79df88 100644
> --- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> @@ -127,7 +127,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x71>;
> -   reset-gpios= < 15 GPIO_ACTIVE_LOW>;
> +   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
> };
>  };

Thanks, looks good to me!

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] arm64: dts: renesas: v3hsk: Move lvds0 node

[Simon Horman]

On Tue, Aug 28, 2018 at 04:15:40PM +0200, Geert Uytterhoeven wrote:
> To preserve alphabetical sort order.
> 
> Fixes: 4edac426aff11a37 ("arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI 
> support")
> Signed-off-by: Geert Uytterhoeven 

Thanks Geert, applied for v4.20.

Re: [PATCH] arm64: dts: r8a7796: Fix whitespace around assignments

[Simon Horman]

On Tue, Aug 28, 2018 at 04:10:59PM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> ---
>  arch/arm64/boot/dts/renesas/r8a774a1.dtsi|  4 +-
>  arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 16 +++
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 48 ++--
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 48 ++--
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi| 36 +++
>  arch/arm64/boot/dts/renesas/r8a77970.dtsi|  8 ++--
>  arch/arm64/boot/dts/renesas/r8a77980.dtsi| 16 +++
>  arch/arm64/boot/dts/renesas/ulcb-kf.dtsi |  2 +-
>  8 files changed, 89 insertions(+), 89 deletions(-)

Thanks Geert,

I took the liberty of updating the subject with s/r8a7796/renesas/
and fixing a few more cases, likely ones that slipped in after you prepared
this patch (and are currently only local to my tree).

The incremental diff is:

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 2798c4c9cf94..010a9958693d 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1455,7 +1455,7 @@
clocks = < CPG_MOD 703>;
phys = <_phy0>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < 32>;
resets = < 703>;
status = "disabled";
@@ -1468,7 +1468,7 @@
clocks = < CPG_MOD 702>;
phys = <_phy1>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < 32>;
resets = < 702>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi 
b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 8bf3091a899c..1b316d79df88 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -127,7 +127,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x71>;
-   reset-gpios= < 15 GPIO_ACTIVE_LOW>;
+   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
};
 };
 

The resulting patch is as follows:


>From d44e5fc06910d21cc131d3b2a860fe0a669aefbe Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven 
Date: Tue, 28 Aug 2018 16:10:59 +0200
Subject: [PATCH] arm64: dts: renesas: Fix whitespace around assignments

Signed-off-by: Geert Uytterhoeven 
[simon: updated for a few new cases]
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi|  8 ++---
 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 16 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 48 ++--
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 48 ++--
 arch/arm64/boot/dts/renesas/r8a77965.dtsi| 36 ++---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi|  8 ++---
 arch/arm64/boot/dts/renesas/r8a77980.dtsi| 16 +-
 arch/arm64/boot/dts/renesas/ulcb-kf.dtsi |  2 +-
 8 files changed, 91 insertions(+), 91 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d9005cbce581..010a9958693d 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -66,7 +66,7 @@
power-domains = < 0>;
next-level-cache = <_CA57>;
enable-method = "psci";
-   clocks =< CPG_CORE 0>;
+   clocks = < CPG_CORE 0>;
};
 
a57_1: cpu@1 {
@@ -76,7 +76,7 @@
power-domains = < 1>;
next-level-cache = <_CA57>;
enable-method = "psci";
-   clocks =< CPG_CORE 0>;
+   clocks = < CPG_CORE 0>;
};
 
a53_0: cpu@100 {
@@ -1455,7 +1455,7 @@
clocks = < CPG_MOD 703>;
phys = <_phy0>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < 32>;
resets = < 703>;
status = "disabled";
@@ -1468,7 +1468,7 @@
clocks = < CPG_MOD 702>;
phys = <_phy1>;
phy-names = "usb";
-   companion= <>;
+   companion = <>;
power-domains = < 32>;
resets = < 702>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index 

Re: [PATCH v2 7/7] arm64: dts: renesas: r8a77965: m3nulcb-kf: Initial device tree

[Simon Horman]

On Wed, Aug 22, 2018 at 01:14:09PM +0200, Simon Horman wrote:
> On Sun, Aug 12, 2018 at 03:31:49PM +0200, Eugeniu Rosca wrote:
> > This is based on the existing KF device tree sources:
> > $ ls -1 arch/arm64/boot/dts/renesas/*-kf.dts
> > arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb-kf.dts
> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> > 
> > Signed-off-by: Eugeniu Rosca 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

I believe that this entire series has now been applied
or at least all of the portions to be merged via my
renesas tree. Please let me know if I am mistaken.

Re: [PATCH v2 5/7] arm64: dts: renesas: r8a77965: Add CAN{0,1} placeholder nodes

[Simon Horman]

On Mon, Aug 27, 2018 at 09:28:09PM +0200, Eugeniu Rosca wrote:
> Hi Simon, hi Geert,
> 
> On Mon, Aug 27, 2018 at 02:44:47PM +0200, Simon Horman wrote:
> > On Thu, Aug 23, 2018 at 10:52:09AM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Aug 17, 2018 at 3:53 PM Kieran Bingham
> > >  wrote:
> > > > On 12/08/18 14:31, Eugeniu Rosca wrote:
> > > > > According to R-Car Gen3 HW manual rev1.00, R-Car M3-N has two CAN
> > > > > interfaces, similar to H3, M3-W and other SoCs from the same family.
> > > > >
> > > > > Add CAN placeholder nodes to avoid below DTC errors:
> > > > > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path 
> > > > > can0 not found
> > > > > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path 
> > > > > can1 not found
> > > > >
> > > > > These errors occur *after* the addition of r8a77965-m3nulcb-kf.dts.
> > > > > Fix them beforehand.
> > > > >
> > > > > CAN support is inspired from below commits:
> > > > >  - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
> > > > >  - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
> > > > >  - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control 
> > > > > properties")
> > > > >
> > > > > Signed-off-by: Eugeniu Rosca 
> > > >
> > > > Reviewed-by: Kieran Bingham 
> > > >
> > > >
> > > > > ---
> > > > > Changes in v2:
> > > > >  - [Kieran Bingham] Improved commit description:
> > > > >- Referenced the newer HW manual rev1.00 instead of rev0.55E.
> > > > >- Kept the "true story" behind the patch. Just made it more clear.
> > > > >  - [Geert Uytterhoeven] Replaced CAN0 and CAN1 nodes with placeholders
> > > > >(no CAN testing was done to validate the DTS configuration).
> > > > > ---
> > > > >  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 16 
> > > > >  1 file changed, 16 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
> > > > > b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > > index 486aecacb22a..4da479d3c226 100644
> > > > > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > > @@ -656,6 +656,22 @@
> > > > >   status = "disabled";
> > > > >   };
> > > > >
> > > > > + can0: can@e6c3 {
> > > > > + compatible = "renesas,can-r8a77965",
> > > > > +  "renesas,rcar-gen3-can";
> > > > > + reg = <0 0xe6c3 0 0x1000>;
> > > > > + /* placeholder */
> > > > > + status = "disabled";
> > > > > + };
> > > >
> > > > This is probably more detail than is needed for a placeholder, but it
> > > > looks correct so I think this is fine.
> > > 
> > > Indeed. Adding the "compatible" properties means they're no longer
> > > placeholders, and will be probed by the driver, possibly leading to
> > > undefined behavior.
> > > 
> > > Hence please limit the placeholders to the absolute required minimum,
> > > and thus drop the "compatible" and "status" properties.
> > 
> > Agreed, I will update the patch accordingly.
> 
> My understanding is that Simon will drop the compatible strings and no
> action is needed from my end. Let me know otherwise.

Your understanding is correct.

Re: [PATCH v2] arm64: dts: renesas: salvator-xs: enable SATA

[Geert Uytterhoeven]

Hi Wolfram,

On Tue, Aug 21, 2018 at 3:41 PM Wolfram Sang  wrote:
> > > +/* MD12 (SW12-7) must be set 'Off' which is not the default! */
> >
> > Upon reading this again, I think this comment is confusing: the 'Off' refers
> > to the switch position, not to the MD12 logic value, while the parentheses
> > suggest otherwise.
> >
> > What about the following?
> >
> > SW12-7 must be set 'Off' (MD12 set to 1), which is not the default!
>
> I'd leave the ',' away but otherwise:
>
> Acked-by: Wolfram Sang 
>
> Shall I send an incremental patch or do you want to do it?

Sent, preacked ;-)

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] arm64: dts: renesas: salvator-xs: Improve SATA switch settings comments

[Geert Uytterhoeven]

The comments describing the non-default switch settings to use SATA are
confusing: 'Off' refers to the switch position, not to the MD12 logic
value, while the parentheses suggest otherwise.  Rephrase to fix this.

Fixes: bec000784d5bb571 ("arm64: dts: renesas: salvator-xs: enable SATA")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Wolfram Sang 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts  | 2 +-
 arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index ba3357636fdb0fea..cf08a119eec093cd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -184,7 +184,7 @@
};
 };
 
-/* MD12 (SW12-7) must be set 'Off' which is not the default! */
+/* SW12-7 must be set 'Off' (MD12 set to 1) which is not the default! */
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
index 45016a06fab1cd5d..f03a5e9e0c427e0d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -57,7 +57,7 @@
};
 };
 
-/* MD12 (SW12-7) must be set 'Off' which is not the default! */
+/* SW12-7 must be set 'Off' (MD12 set to 1) which is not the default! */
  {
status = "okay";
 };
-- 
2.17.1

[PATCH] arm64: dts: renesas: salvator-xs: Improve SATA switch settings comments

[Geert Uytterhoeven]

The comments describing the non-default switch settings to use SATA are
confusing: 'Off' refers to the switch position, not to the MD12 logic
value, while the parentheses suggest otherwise.  Rephrase to fix this.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Wolfram Sang 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts  | 2 +-
 arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index ba3357636fdb0fea..cf08a119eec093cd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -184,7 +184,7 @@
};
 };
 
-/* MD12 (SW12-7) must be set 'Off' which is not the default! */
+/* SW12-7 must be set 'Off' (MD12 set to 1) which is not the default! */
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
index 45016a06fab1cd5d..f03a5e9e0c427e0d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -57,7 +57,7 @@
};
 };
 
-/* MD12 (SW12-7) must be set 'Off' which is not the default! */
+/* SW12-7 must be set 'Off' (MD12 set to 1) which is not the default! */
  {
status = "okay";
 };
-- 
2.17.1

Re: [PATCH v3 2/2] arm64: dts: renesas: condor: add PCIe support

[Simon Horman]

On Mon, Aug 27, 2018 at 09:54:35PM +0300, Sergei Shtylyov wrote:
> Enable PCIe PHY and PCIEC and specify the PCIe bus clock for the Condor
> board.
> 
> Based on the original (and large) patch by Vladimir Barinov.
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 

Thanks Sergei, applied for v4.20.

Re: [PATCH v3 1/2] arm64: dts: renesas: r8a77980: add PCIe support

[Simon Horman]

On Mon, Aug 27, 2018 at 09:53:40PM +0300, Sergei Shtylyov wrote:
> Describe the PCIe PHY, PCIEC, and PCIe bus clock in the R8A77980 device
> tree.
> 
> Based on the original (and large) patch by Vladimir Barinov.
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Simon Horman 

Thanks Sergei, applied for v4.20.

Re: [PATCH] mmc: tmio: remove now unused variable

[Ulf Hansson]

On 30 August 2018 at 14:16, Wolfram Sang
 wrote:
> This variable is unused now after some refactoring.
>
> Signed-off-by: Wolfram Sang 

Applied for next, thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/host/tmio_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
> index 0ae100e62b57..29bda8224ae7 100644
> --- a/drivers/mmc/host/tmio_mmc.c
> +++ b/drivers/mmc/host/tmio_mmc.c
> @@ -45,7 +45,7 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
>  static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
>unsigned int new_clock)
>  {
> -   unsigned int clock, divisor;
> +   unsigned int divisor;
> u32 clk = 0;
> int clk_sel;
>
> --
> 2.11.0
>

Re: [PATCH v3 5/6] mmc: renesas_sdhi: merge clk_{start,stop} functions to set_clock

[Ulf Hansson]

On 23 August 2018 at 06:44, Masahiro Yamada
 wrote:
> renesas_sdhi_clk_start() and renesas_sdhi_clk_stop() are now only
> called from renesas_sdhi_set_clock().  Merge them.
>
> Signed-off-by: Masahiro Yamada 

Applied for next, thanks!

Kind regards
Uffe

> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/mmc/host/renesas_sdhi_core.c | 38 
> 
>  1 file changed, 12 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
> b/drivers/mmc/host/renesas_sdhi_core.c
> index cb6e889..0e88737 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -155,35 +155,17 @@ static unsigned int renesas_sdhi_clk_update(struct 
> tmio_mmc_host *host,
> return ret == 0 ? best_freq : clk_get_rate(priv->clk);
>  }
>
> -static void renesas_sdhi_clk_start(struct tmio_mmc_host *host)
> +static void renesas_sdhi_set_clock(struct tmio_mmc_host *host,
> +  unsigned int new_clock)
>  {
> -   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
> -   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
> -
> -   /* HW engineers overrode docs: no sleep needed on R-Car2+ */
> -   if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> -   usleep_range(1, 11000);
> -}
> +   u32 clk = 0, clock;
>
> -static void renesas_sdhi_clk_stop(struct tmio_mmc_host *host)
> -{
> sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
> sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
>
> -   /* HW engineers overrode docs: no sleep needed on R-Car2+ */
> -   if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> -   usleep_range(1, 11000);
> -}
> -
> -static void renesas_sdhi_set_clock(struct tmio_mmc_host *host,
> -  unsigned int new_clock)
> -{
> -   u32 clk = 0, clock;
> +   if (new_clock == 0)
> +   goto out;
>
> -   if (new_clock == 0) {
> -   renesas_sdhi_clk_stop(host);
> -   return;
> -   }
> /*
>  * Both HS400 and HS200/SD104 set 200MHz, but some devices need to
>  * set 400MHz to distinguish the CPG settings in HS400.
> @@ -206,13 +188,17 @@ static void renesas_sdhi_set_clock(struct tmio_mmc_host 
> *host,
> clk &= ~0xff;
> }
>
> -   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
> -   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
> sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk & CLK_CTL_DIV_MASK);
> if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> usleep_range(1, 11000);
>
> -   renesas_sdhi_clk_start(host);
> +   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
> +   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
> +
> +out:
> +   /* HW engineers overrode docs: no sleep needed on R-Car2+ */
> +   if (!(host->pdata->flags & TMIO_MMC_MIN_RCAR2))
> +   usleep_range(1, 11000);
>  }
>
>  static void renesas_sdhi_clk_disable(struct tmio_mmc_host *host)
> --
> 2.7.4
>

Re: [PATCH] mmc: tmio: more concise clk calculation

[Ulf Hansson]

On 30 August 2018 at 14:14, Wolfram Sang
 wrote:
> Concise, but still readable.
>
> Signed-off-by: Wolfram Sang 

Applied for next, thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/host/tmio_mmc.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
> index 0ae9ba1ee01b..0ae100e62b57 100644
> --- a/drivers/mmc/host/tmio_mmc.c
> +++ b/drivers/mmc/host/tmio_mmc.c
> @@ -56,14 +56,9 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
>
> divisor = host->pdata->hclk / new_clock;
>
> -   if (divisor <= 1) {
> -   clk_sel = 1;
> -   clk = 0;
> -   } else {
> -   clk_sel = 0;
> -   /* bit7 set: 1/512, ... bit0 set:1/4, all bits clear: 1/2 */
> -   clk = roundup_pow_of_two(divisor) >> 2;
> -   }
> +   /* bit7 set: 1/512, ... bit0 set: 1/4, all bits clear: 1/2 */
> +   clk_sel = (divisor <= 1);
> +   clk = clk_sel ? 0 : (roundup_pow_of_two(divisor) >> 2);
>
> host->pdata->set_clk_div(host->pdev, clk_sel);
>
> --
> 2.11.0
>

Re: [PATCH v4 0/3] mmc: {tmio,renesas_sdhi}: retune if SCC error detected

[Ulf Hansson]

On 30 August 2018 at 01:32, Niklas Söderlund
 wrote:
> Hi,
>
> These patches triggers a retune if a SCC error is detected. They where
> ported from the renesas BSP. Masaharu-san did all the real work I just
> ported them to upstream and did small fixups.
>
> These patches where broken out of my retuning series as more work where
> needed to adapt them to the recent HS400 series picked-up. It's tested
> on M3-N using both HS200 and HS400 and on H3 ES2.0 using HS200.
>
> Masaharu Hayakawa (2):
>   mmc: renesas_sdhi: skip SCC error check when retuning
>   mmc: tmio: Fix SCC error detection
>
> Niklas Söderlund (1):
>   mmc: core: add helper to see if a host is doing a retune
>
>  drivers/mmc/host/renesas_sdhi_core.c | 13 +
>  drivers/mmc/host/tmio_mmc_core.c |  4 ++--
>  include/linux/mmc/host.h |  5 +
>  3 files changed, 20 insertions(+), 2 deletions(-)
>
> --
> 2.18.0
>

Applied for next, thanks!

Kind regards
Uffe

Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add USB-DMAC and HSUSB device nodes

[Simon Horman]

On Tue, Aug 28, 2018 at 03:17:39PM +0200, Simon Horman wrote:
> On Fri, Aug 24, 2018 at 11:43:48AM +0100, Biju Das wrote:
> > Add usb dmac and hsusb device nodes on RZ/G2M SoC dtsi.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 1/3] arm64: dts: renesas: r8a774a1: Add USB2.0 phy and host(EHCI/OHCI) device nodes

[Geert Uytterhoeven]

On Fri, Aug 24, 2018 at 12:50 PM Biju Das  wrote:
> Add USB2.0 phy and host (EHCI/OHCI) device nodes on RZ/G2M SoC dtsi.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> ---
>  arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 73 
> +++
>  1 file changed, 73 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> index cd204f5..a794089 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi

> +   ehci0: usb@ee080100 {
> +   compatible = "generic-ehci";
> +   reg = <0 0xee080100 0 0x100>;
> +   interrupts = ;
> +   clocks = < CPG_MOD 703>;
> +   phys = <_phy0>;
> +   phy-names = "usb";
> +   companion= <>;

Please insert a space before the "=".

> +   power-domains = < 32>;
> +   resets = < 703>;
> +   status = "disabled";
> +   };
> +
> +   ehci1: usb@ee0a0100 {
> +   compatible = "generic-ehci";
> +   reg = <0 0xee0a0100 0 0x100>;
> +   interrupts = ;
> +   clocks = < CPG_MOD 702>;
> +   phys = <_phy1>;
> +   phy-names = "usb";
> +   companion= <>;

Likewise.

> +   power-domains = < 32>;
> +   resets = < 702>;
> +   status = "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

Re: [PATCH 3/3] arm64: dts: renesas: r8a774a1: Add USB3.0 device nodes

[Simon Horman]

On Tue, Aug 28, 2018 at 03:42:05PM +0200, Simon Horman wrote:
> On Fri, Aug 24, 2018 at 11:43:49AM +0100, Biju Das wrote:
> > Add usb3.0 phy, host and function device nodes on RZ/G2M SoC dtsi.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 1/3] arm64: dts: renesas: r8a774a1: Add USB2.0 phy and host(EHCI/OHCI) device nodes

[Simon Horman]

On Fri, Aug 24, 2018 at 11:43:47AM +0100, Biju Das wrote:
> Add USB2.0 phy and host (EHCI/OHCI) device nodes on RZ/G2M SoC dtsi.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Thanks, applied for v4.20.

Re: [PATCH] arm64: dts: renesas: r8a774a1: Add CAN nodes

[Simon Horman]

On Mon, Aug 27, 2018 at 11:53:35AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 03:22:46PM +0100, Fabrizio Castro wrote:
> > From: Chris Paterson 
> > 
> > Add the device nodes for both RZ/G2M CAN channels.
> > 
> > Signed-off-by: Chris Paterson 
> > Reviewed-by: Biju Das 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH v3 9/9] arm64: dts: renesas: r8a774a1: Add FCPF and FCPV instances

[Simon Horman]

On Mon, Aug 27, 2018 at 11:48:09AM +0200, Simon Horman wrote:
> On Fri, Aug 24, 2018 at 11:21:14AM +0100, Fabrizio Castro wrote:
> > Add FCPF and FCPV instances to the r8a774a1 dtsi, similarly
> > to what was done for the r8a7796 with commit 41dbbf0c5b4e
> > ("arm64: dts: r8a7796: Add FCPF and FCPV instances"),
> > commit 69490bc9665d ("arm64: dts: renesas: r8a7796: Point
> > FDP1 via FCPF to IPMMU-VI0"), and commit cef942d0bd89 ("arm64:
> > dts: renesas: r8a7796: Point VSPI via FCPVI to IPMMU-VC0").
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 8/9] arm64: dts: renesas: r8a774a1: Add audio support

[Simon Horman]

On Mon, Aug 27, 2018 at 11:32:52AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:07PM +0100, Fabrizio Castro wrote:
> > From: Biju Das 
> > 
> > Add sound support for the RZ/G2M SoC (a.k.a. R8A774A1).
> > 
> > This work is based on similar work done on the R8A7796 SoC
> > by Kuninori Morimoto .
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 7/9] arm64: dts: renesas: r8a774a1: Add PWM device nodes

[Simon Horman]

On Mon, Aug 27, 2018 at 11:12:39AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:06PM +0100, Fabrizio Castro wrote:
> > This patch adds PWM[0123456] device nodes to the RZ/G2M (a.k.a R8A774A1)
> > device tree.
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 6/9] arm64: dts: renesas: r8a774a1: Add Cortex-A53 CPU cores

[Simon Horman]

On Mon, Aug 27, 2018 at 11:08:33AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:05PM +0100, Fabrizio Castro wrote:
> > From: Biju Das 
> > 
> > This patch adds definitions for L2 cache for the Cortex-A53 CPU
> > cores (512 KiB in size, organized as 32 KiB x 16 ways), adds
> > Cortex-A53 CPU cores (setting a total of 6 cores, 2 x Cortex-A57
> > + 4 x Cortex-A53), and finally enables the performance monitor
> > unit for the Cortex-A53 cores on the R8A774A1 SoC.
> > 
> > Based on work done for r8a7796 SoC.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 5/9] arm64: dts: renesas: r8a774a1: Add all MSIOF nodes

[Simon Horman]

On Mon, Aug 27, 2018 at 11:05:52AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:04PM +0100, Fabrizio Castro wrote:
> > From: Biju Das 
> > 
> > Add the device nodes for all MSIOF SPI controllers on RZ/G2M SoC.
> > 
> > Based on several similar patches of the R8A7796 device tree
> > by Geert Uytterhoeven 
> > and Simon Horman .
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 4/9] arm64: dts: renesas: r8a774a1: Add IPMMU device nodes

[Simon Horman]

On Mon, Aug 27, 2018 at 11:02:36AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:03PM +0100, Fabrizio Castro wrote:
> > Add r8a774a1 IPMMU nodes.
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 3/9] arm64: dts: renesas: r8a774a1: Add RZ/G2M thermal support

[Simon Horman]

On Mon, Aug 27, 2018 at 10:54:08AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:02PM +0100, Fabrizio Castro wrote:
> > From: Biju Das 
> > 
> > Add thermal support for R8A774A1 (RZ/G2M) SoC.
> > 
> > Based on the work done for r8a7796 SoC.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add SDHI nodes

[Simon Horman]

On Thu, Aug 23, 2018 at 02:43:00PM +0100, Fabrizio Castro wrote:
> Add SDHI nodes to the DT of the r8a774a1 SoC.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Thanks again, applied for v4.20.

Re: [PATCH 2/9] arm64: dts: renesas: r8a774a1: Add I2C and IIC-DVFS support

[Simon Horman]

On Mon, Aug 27, 2018 at 10:51:35AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 02:43:01PM +0100, Fabrizio Castro wrote:
> > From: Biju Das 
> > 
> > Add the I2C[0-6] and IIC Bus Interface for DVFS (IIC for DVFS)
> > devices nodes to the r8a774a1 device tree.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH] arm64: dts: renesas: r8a774a1: Add GPIO device nodes

[Simon Horman]

On Mon, Aug 27, 2018 at 10:00:20AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 03:18:18PM +0100, Fabrizio Castro wrote:
> > Add GPIO device nodes to the DT of the r8a774a1 SoC.
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> > ---
> > 
> > This patch depends on:
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30549.html
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH v2] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function

[Geert Uytterhoeven]

On Tue, Aug 28, 2018 at 1:11 PM Laurent Pinchart
 wrote:
> This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
>
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
>
> - Add DU_CLKIN0

Thanks for the update!

Reviewed-by: Geert Uytterhoeven 
i.e. queued in sh-pfc-for-v4.20.

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] arm64: dts: renesas: r8a774a1: Add pinctrl device node

[Simon Horman]

On Mon, Aug 27, 2018 at 09:47:37AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 03:13:16PM +0100, Fabrizio Castro wrote:
> > This patch adds pinctrl device node for R8A774A1 SoC.
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> > ---
> > 
> > This patch depends on:
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30339.html
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30539.html
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 5/5] arm64: dts: renesas: r8a774a1: Add RWDT node

[Simon Horman]

On Fri, Aug 24, 2018 at 11:05:03AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 09:58:51AM +0100, Biju Das wrote:
> > Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
> > RZ/G2M (r8a774a1) SoC.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 10 ++
> >  1 file changed, 10 insertions(+)
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

[PATCH] mmc: tmio: remove now unused variable

[Wolfram Sang]

This variable is unused now after some refactoring.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/tmio_mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 0ae100e62b57..29bda8224ae7 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -45,7 +45,7 @@ static void tmio_mmc_clk_stop(struct tmio_mmc_host *host)
 static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
   unsigned int new_clock)
 {
-   unsigned int clock, divisor;
+   unsigned int divisor;
u32 clk = 0;
int clk_sel;
 
-- 
2.11.0

Re: [PATCH 4/5] arm64: dts: renesas: r8a774a1: Add Ethernet AVB node

[Simon Horman]

On Tue, Aug 28, 2018 at 02:20:44PM +0200, Simon Horman wrote:
> On Fri, Aug 24, 2018 at 09:06:49AM +, Fabrizio Castro wrote:
> > Hello Simon,
> > 
> > Thank you for your feedback!
> > 
> > > Subject: Re: [PATCH 4/5] arm64: dts: renesas: r8a774a1: Add Ethernet AVB 
> > > node
> > >
> > > On Thu, Aug 23, 2018 at 09:58:50AM +0100, Biju Das wrote:
> > > > From: Fabrizio Castro 
> > > >
> > > > This patch adds the SoC specific part of the Ethernet AVB
> > > > device tree node.
> > > >
> > > > Signed-off-by: Fabrizio Castro 
> > > > Reviewed-by: Biju Das 
> > > > ---
> > > >  arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 45 
> > > > +++
> > > >  1 file changed, 45 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
> > > > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > index 15d7785..b771211 100644
> > > > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > @@ -350,6 +350,51 @@
> > > >  dma-channels = <16>;
> > > >  };
> > > >
> > > > +avb: ethernet@e680 {
> > > > +compatible = "renesas,etheravb-r8a774a1",
> > > > + "renesas,etheravb-rcar-gen3";
> > > > +reg = <0 0xe680 0 0x800>;
> > >
> > > Should a region, <0 0xe6a0 0 0x1>, also be added
> > > here to describe the suggested space for descriptors?
> > 
> > There is no STBE (Stream Buffer for EthernetAVB-IF) on the r8a774a1, and 
> > that's why this node doesn't come with such a region.
> 
> Thanks for the follow-up. In that case I'm fine with this patch but
> I'd like to wait a little longer to allow review by others.

Thanks again, applied for v4.20.

Re: [PATCH 3/5] arm64: dts: renesas: r8a774a1: Add INTC-EX device node

[Simon Horman]

On Fri, Aug 24, 2018 at 10:55:13AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 09:58:49AM +0100, Biju Das wrote:
> > Add support for the Interrupt Controller for External Devices
> > (INTC-EX) on RZ/G2M.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH 2/5] arm64: dts: renesas: r8a774a1: Add SCIF and HSCIF nodes

[Simon Horman]

On Fri, Aug 24, 2018 at 10:52:57AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 09:58:48AM +0100, Biju Das wrote:
> > From: Fabrizio Castro 
> > 
> > Add the device nodes for all RZ/G2M SCIF and HSCIF serial ports,
> > incl. clocks, power domains and DMAs.
> > According to the HW user manual, SCIF[015] and HSCIF[012] are
> > connected to both SYS-DMAC1 and SYS-DMAC2, while SCIF[34] and
> > HSCIF[34] are connected to SYS-DMAC0.
> > 
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

[PATCH] mmc: tmio: more concise clk calculation

[Wolfram Sang]

Concise, but still readable.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/tmio_mmc.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 0ae9ba1ee01b..0ae100e62b57 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -56,14 +56,9 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
 
divisor = host->pdata->hclk / new_clock;
 
-   if (divisor <= 1) {
-   clk_sel = 1;
-   clk = 0;
-   } else {
-   clk_sel = 0;
-   /* bit7 set: 1/512, ... bit0 set:1/4, all bits clear: 1/2 */
-   clk = roundup_pow_of_two(divisor) >> 2;
-   }
+   /* bit7 set: 1/512, ... bit0 set: 1/4, all bits clear: 1/2 */
+   clk_sel = (divisor <= 1);
+   clk = clk_sel ? 0 : (roundup_pow_of_two(divisor) >> 2);
 
host->pdata->set_clk_div(host->pdev, clk_sel);
 
-- 
2.11.0

Re: [PATCH 1/5] arm64: dts: renesas: r8a774a1: Add SYS-DMAC controller nodes

[Simon Horman]

On Fri, Aug 24, 2018 at 10:38:59AM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 09:58:47AM +0100, Biju Das wrote:
> > Add sys-dmac[0-2] device nodes for RZ/G2M (r8a774a1) SoC.
> > 
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks again, applied for v4.20.

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

[Wolfram Sang]

> We could do that but then we can't reset the struct device dma_parms 
> member to NULL.

I think it is fine to skip this. From the device_add docs:

 * Do not call this routine or device_register() more than once for
 * any device structure.  The driver model core is not designed to work
 * with devices that get unregistered and then spring back to life.
 * (Among other things, it's very hard to guarantee that all references
 * to the previous incarnation of @dev have been dropped.)  Allocate
 * and register a fresh new struct device instead.

I also don't see any other dma_params user doing this (which is only an
indication, not a proof).



signature.asc
Description: PGP signature

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

[Niklas Söderlund]

Hi Wolfram,

Thanks for your feedback.

On 2018-08-30 11:49:12 +0200, Wolfram Sang wrote:
> Hi Niklas,
> 
> > +   if (!dev->dma_parms) {
> > +   dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
> 
> Can't we use devm_kzalloc and skip the custom remove function?

We could do that but then we can't reset the struct device dma_parms 
member to NULL.

kfree(dev->dma_parms);
dev->dma_parms = NULL;

This might not be a problem but I chose to opt for the more safer 
approach at first. If you or someone else thinks this is not an issue 
I'm more then happy to switch to devm_kcalloc().

-- 
Regards,
Niklas Söderlund

Re: [PATCH v4 3/3] mmc: tmio: Fix SCC error detection

[Wolfram Sang]

On Thu, Aug 30, 2018 at 01:32:07AM +0200, Niklas Söderlund wrote:
> From: Masaharu Hayakawa 
> 
> SDR104, HS200 and HS400 need to check for SCC error. If SCC error is
> detected, retuning is necessary.
> 
> Signed-off-by: Masaharu Hayakawa 
> [Niklas: update commit message]
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH v4 1/3] mmc: core: add helper to see if a host is doing a retune

[Wolfram Sang]

On Thu, Aug 30, 2018 at 01:32:05AM +0200, Niklas Söderlund wrote:
> Add a helper to allow host drivers checking if a retune is in progress.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH v4 2/3] mmc: renesas_sdhi: skip SCC error check when retuning

[Wolfram Sang]

On Thu, Aug 30, 2018 at 01:32:06AM +0200, Niklas Söderlund wrote:
> From: Masaharu Hayakawa 
> 
> Checking for SCC error during retuning is unnecessary.
> 
> Signed-off-by: Masaharu Hayakawa 
> [Niklas: fix small style issue]
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 



signature.asc
Description: PGP signature

[PATCH] ARM: dts: r9a06g032: Correct UART and add all other UARTs

[Phil Edworthy]

- UART0 was missing the bus clock ("apb_pclk").
- Now that the relevant rzn1 bindings have been added, replace the Synopsys
  compat string with the rzn1 strings.
- Add all the other UARTs.

Signed-off-by: Phil Edworthy 
---
 arch/arm/boot/dts/r9a06g032.dtsi | 83 ++--
 1 file changed, 80 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 3e45375..1bc1f36 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -78,13 +78,90 @@
};
 
uart0: serial@4006 {
-   compatible = "snps,dw-apb-uart";
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
reg = <0x4006 0x400>;
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = < R9A06G032_CLK_UART0>;
-   clock-names = "baudclk";
+   clocks = < R9A06G032_CLK_UART0>, < 
R9A06G032_HCLK_UART0>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart1: serial@40061000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x40061000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART1>, < 
R9A06G032_HCLK_UART1>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart2: serial@40062000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x40062000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART2>, < 
R9A06G032_HCLK_UART2>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart3: serial@5000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x5000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART3>, < 
R9A06G032_HCLK_UART3>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart4: serial@50001000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x50001000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART4>, < 
R9A06G032_HCLK_UART4>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart5: serial@50002000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x50002000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART5>, < 
R9A06G032_HCLK_UART5>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart6: serial@50003000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x50003000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART6>, < 
R9A06G032_HCLK_UART6>;
+   clock-names = "baudclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart7: serial@50004000 {
+   compatible = "renesas,r9a06g032-uart", 
"renesas,rzn1-uart";
+   reg = <0x50004000 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = < R9A06G032_CLK_UART7>, < 
R9A06G032_HCLK_UART7>;
+   clock-names = "baudclk", "apb_pclk";
status = "disabled";
};
 
-- 
2.7.4

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

[Wolfram Sang]

Hi Niklas,

> + if (!dev->dma_parms) {
> + dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);

Can't we use devm_kzalloc and skip the custom remove function?

Thanks,

   Wolfram


signature.asc
Description: PGP signature

RE: [PATCH] ARM: dts: r9a06g032: Use r9a06g032-sysctrl binding definitions

[Phil Edworthy]

Hi Geert,

On 28 August 2018 16:13, Geert Uytterhoeven wrote:
> Replace the hardcoded clock indices by R9A06G032_CLK_* symbols.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Phil Edworthy 

Thanks!
Phil

Re: [PATCH] thermal: rcar: reduce inaccuracy in calculate rounding

[Sergei Shtylyov]

Hello!

On 8/30/2018 5:39 AM, Nguyen An Hoan wrote:


From: Hoan Nguyen An 

About the formula for temperature calculation
[reg] = [temp] * a + b <=> [temp] = ([reg] - b) / a

Using "(mcelsius * tsc-> coef.aX) / 1000" instead of "DIV_ROUND_CLOSEST(mcelsius, 1000) 
* tsc-> coef.aX"
to avoid and reduce inaccuracy due to rounding the integer division.

Signed-off-by: Hoan Nguyen An 
---
  drivers/thermal/rcar_gen3_thermal.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
index 7aed533..dbb31b8 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -185,11 +185,10 @@ static int rcar_gen3_thermal_get_temp(void *devdata, int 
*temp)
  static int rcar_gen3_thermal_mcelsius_to_temp(struct rcar_gen3_thermal_tsc 
*tsc,
  int mcelsius)
  {
-   int celsius, val1, val2;
+   int val1, val2;
  
-	celsius = DIV_ROUND_CLOSEST(mcelsius, 1000);

-   val1 = celsius * tsc->coef.a1 + tsc->coef.b1;
-   val2 = celsius * tsc->coef.a2 + tsc->coef.b2;
+   val1 = (mcelsius * tsc->coef.a1)/1000 + tsc->coef.b1;
+   val2 = (mcelsius * tsc->coef.a2)/1000 + tsc->coef.b2;


   Please be consistent and enclose / in sopaces the same as you do for other 
operators.


[...]

MBR, Sergei

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Bartosz Golaszewski]

2018-08-30 11:16 GMT+02:00 Daniel Lezcano :
>
> [Added Arnd Bergmann, Bartosz Golaszewski and Mark Brown]
>
> On 30/08/2018 10:48, Geert Uytterhoeven wrote:
>> Hi Daniel,
>
> [ ... ]
>
>>> Yeah, I got this point. But it is the meaning of your sentence: "...
>>> which causes issues with complex dependencies.".
>>>
>>> It is ambiguous *what* causes the issues.
>>>
>>> Did you meant an attempt was done to support EPROBE_DEFER with
>>> *_OF_DECLARE but caused too much issues with the complex dependencies?
>>>
>>> Or the current situation is causing too much issues with the complex
>>> dependencies?
>>>
>>> (I know the latter is true, it is about the meaning of the sentence).
>>
>> I meant the latter.
>>
>> AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE.
>> IMHO it would be pointless, as it would be much easier to just switch to real
>> platform drivers.
>
> May be, may be not.
>
> From your point of view, the change is simple because it touches only a
> single driver.
>
> From my point of view, the change implies a split in the approach while
> I'm trying to unify the drivers little by little and there are hundred
> of them.
>
> It is not the first time we face this situation and Bartosz Golaszewski
> has a similar problem [1].
>

Hi,

thanks for Cc'in me on that.

This was my latest proposal for early platform drivers:

https://lkml.org/lkml/2018/5/11/488

I still intend on continuing this work, I just don't have the time right now.

Best regards,
Bartosz Golaszewski

> We have all the frameworks we need to solve this properly but I would
> like something we can propagate to all drivers (OF and !OF) so we end up
> with unified code.
>
> It is time we clearly state the dependency issues and we find a proper
> way to solve it.
>
>
>
>
> [1] https://lkml.org/lkml/2018/4/26/657
>
> --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Daniel Lezcano]

[Added Arnd Bergmann, Bartosz Golaszewski and Mark Brown]

On 30/08/2018 10:48, Geert Uytterhoeven wrote:
> Hi Daniel,

[ ... ]

>> Yeah, I got this point. But it is the meaning of your sentence: "...
>> which causes issues with complex dependencies.".
>>
>> It is ambiguous *what* causes the issues.
>>
>> Did you meant an attempt was done to support EPROBE_DEFER with
>> *_OF_DECLARE but caused too much issues with the complex dependencies?
>>
>> Or the current situation is causing too much issues with the complex
>> dependencies?
>>
>> (I know the latter is true, it is about the meaning of the sentence).
> 
> I meant the latter.
> 
> AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE.
> IMHO it would be pointless, as it would be much easier to just switch to real
> platform drivers.

May be, may be not.

>From your point of view, the change is simple because it touches only a
single driver.

>From my point of view, the change implies a split in the approach while
I'm trying to unify the drivers little by little and there are hundred
of them.

It is not the first time we face this situation and Bartosz Golaszewski
has a similar problem [1].

We have all the frameworks we need to solve this properly but I would
like something we can propagate to all drivers (OF and !OF) so we end up
with unified code.

It is time we clearly state the dependency issues and we find a proper
way to solve it.




[1] https://lkml.org/lkml/2018/4/26/657

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Aug 30, 2018 at 10:37 AM Daniel Lezcano
 wrote:
> On 30/08/2018 10:27, Geert Uytterhoeven wrote:
> > On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
> >  wrote:
> >> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> >>> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
> >>>  wrote:
>  On 29/08/2018 17:44, Chris Brandt wrote:
> > On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> >> Can the boot constraints [1] solve this issue instead of the changes 
> >> you
> >> are proposing ?
> >>
> >> [1] https://lwn.net/Articles/747250/
> >
> > Thanks for the suggestion, but...
> >
> > I grepped for "boot_constraint" and it shows up nowhere in the current
> > kernel.
> >
> > Also, this article was written Feb 16, 2018, and I can see that the
> > patch series was still being submitted (V7) as of Feb 23, 2018.
> 
>  Ah ok, fair enough, I thought it was merged. In any case, after thinking
>  about it, it wouldn't have helped.
> 
>  My concern is if we can avoid changing the TIMER_OF_DECLARE because of
>  the boot order, it would be better.
> 
>  Can returning EPROBE_DEFER fix this issue? Or use the 'complex
>  dependencies' [1]?
> >>>
> >>> *_OF_DECLARE() is not compatible with EPROBE_DEFER, which causes
> >>> issues with complex dependencies.
> >>
> >> What causes issues ? Add support for EPROBE_DEFER with OF_DECLARE or not
> >> having support of it ?
> >
> > Driver init functions declared using *_OF_DECLARE() are called exactly once.
> > Hence if they fail, they are never retried. Calling order among subsystems 
> > is
> > hardcoded, and the actual order was determined by historical reasons (legacy
> > PC systems with always-on clocks and power domains ;-).
> > This breaks as soon as e.g. timers or interrupt controllers start depending
> > on clocks and/or power domains.
> >
> > Drivers using the device driver framework are retried later when their init
> > function returns -EPROBE_DEFER. So (eventually) they all succeed
> > initialization.
>
> Yeah, I got this point. But it is the meaning of your sentence: "...
> which causes issues with complex dependencies.".
>
> It is ambiguous *what* causes the issues.
>
> Did you meant an attempt was done to support EPROBE_DEFER with
> *_OF_DECLARE but caused too much issues with the complex dependencies?
>
> Or the current situation is causing too much issues with the complex
> dependencies?
>
> (I know the latter is true, it is about the meaning of the sentence).

I meant the latter.

AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE.
IMHO it would be pointless, as it would be much easier to just switch to real
platform drivers.

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: [GIT PULL LTSI-4.14] LTSI-v4.14 Backport or I2C R-Car Fix

[Geert Uytterhoeven]

Hi Simon,

On Tue, Aug 28, 2018 at 1:49 PM Simon Horman  wrote:
> This is intended as a submission to LTSI-4.14. It is the backport
> of a fix for the R-Car I2C driver, and its dependency, both of which
> are present in linux-next 20180821.
>
> This pull-request is based on
> "[GIT PULL LTSI-4.14] Renesas SoCs and Drivers to v4.18-rc8",
> tagged as backport/v4.14.61/snapshot-to-v4.18-rc8+fixes-flattened,
> which I have already sent a pull-request for.
>
> There are 2 patches.
>
> I have performed build testing of this backports on a wide range of
> defconfigs and I am not aware of any regressions over v4.14.40 (the
> baseline chosen when this work began).
>
>
> The following changes since commit cc88cfdc0571385f098e82db47f5a16b6f44726e:
>
>   i2c: rcar: use the new get_bus_free callback (2018-08-09 17:22:00 +0200)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git 
> backport/v4.14.61/snapshot-to-v4.18+fixes-flattened
>
> for you to fetch changes up to 4d4605e5c137ed9a53582e573118cbc16b82cbf1:
>
>   i2c: rcar: implement STOP and REP_START according to docs (2018-08-28 
> 13:35:06 +0200)
>
> 
> LTSI-v4.14 Backport or I2C R-Car Fix
>
> Base:
> * v4.14.61
> * Backports of components for Renesas SoCs to v4.18
>
> Backport of post-v4.18 fix for i2c-rcar:
> * implement STOP and REP_START according to docs
>
> Dependency of above
> * Refactor private flags of i2c-rcar driver
>
> 
> Wolfram Sang (2):
>   i2c: rcar: refactor private flags
>   i2c: rcar: implement STOP and REP_START according to docs
>
>  drivers/i2c/busses/i2c-rcar.c | 39 +++
>  1 file changed, 23 insertions(+), 16 deletions(-)

Thank you, looks good to me.

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] clocksource/drivers/ostm: Delay driver registration

[Daniel Lezcano]

On 30/08/2018 10:27, Geert Uytterhoeven wrote:
> Hi Daniel,
> 
> On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
>  wrote:
>> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
>>> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
>>>  wrote:
 On 29/08/2018 17:44, Chris Brandt wrote:
> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
>> Can the boot constraints [1] solve this issue instead of the changes you
>> are proposing ?
>>
>> [1] https://lwn.net/Articles/747250/
>
> Thanks for the suggestion, but...
>
> I grepped for "boot_constraint" and it shows up nowhere in the current
> kernel.
>
> Also, this article was written Feb 16, 2018, and I can see that the
> patch series was still being submitted (V7) as of Feb 23, 2018.

 Ah ok, fair enough, I thought it was merged. In any case, after thinking
 about it, it wouldn't have helped.

 My concern is if we can avoid changing the TIMER_OF_DECLARE because of
 the boot order, it would be better.

 Can returning EPROBE_DEFER fix this issue? Or use the 'complex
 dependencies' [1]?
>>>
>>> *_OF_DECLARE() is not compatible with EPROBE_DEFER, which causes
>>> issues with complex dependencies.
>>
>> What causes issues ? Add support for EPROBE_DEFER with OF_DECLARE or not
>> having support of it ?
> 
> Driver init functions declared using *_OF_DECLARE() are called exactly once.
> Hence if they fail, they are never retried. Calling order among subsystems is
> hardcoded, and the actual order was determined by historical reasons (legacy
> PC systems with always-on clocks and power domains ;-).
> This breaks as soon as e.g. timers or interrupt controllers start depending
> on clocks and/or power domains.
> 
> Drivers using the device driver framework are retried later when their init
> function returns -EPROBE_DEFER. So (eventually) they all succeed
> initialization.

Yeah, I got this point. But it is the meaning of your sentence: "...
which causes issues with complex dependencies.".

It is ambiguous *what* causes the issues.

Did you meant an attempt was done to support EPROBE_DEFER with
*_OF_DECLARE but caused too much issues with the complex dependencies?

Or the current situation is causing too much issues with the complex
dependencies?

(I know the latter is true, it is about the meaning of the sentence).


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
 wrote:
> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> > On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
> >  wrote:
> >> On 29/08/2018 17:44, Chris Brandt wrote:
> >>> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
>  Can the boot constraints [1] solve this issue instead of the changes you
>  are proposing ?
> 
>  [1] https://lwn.net/Articles/747250/
> >>>
> >>> Thanks for the suggestion, but...
> >>>
> >>> I grepped for "boot_constraint" and it shows up nowhere in the current
> >>> kernel.
> >>>
> >>> Also, this article was written Feb 16, 2018, and I can see that the
> >>> patch series was still being submitted (V7) as of Feb 23, 2018.
> >>
> >> Ah ok, fair enough, I thought it was merged. In any case, after thinking
> >> about it, it wouldn't have helped.
> >>
> >> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
> >> the boot order, it would be better.
> >>
> >> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
> >> dependencies' [1]?
> >
> > *_OF_DECLARE() is not compatible with EPROBE_DEFER, which causes
> > issues with complex dependencies.
>
> What causes issues ? Add support for EPROBE_DEFER with OF_DECLARE or not
> having support of it ?

Driver init functions declared using *_OF_DECLARE() are called exactly once.
Hence if they fail, they are never retried. Calling order among subsystems is
hardcoded, and the actual order was determined by historical reasons (legacy
PC systems with always-on clocks and power domains ;-).
This breaks as soon as e.g. timers or interrupt controllers start depending
on clocks and/or power domains.

Drivers using the device driver framework are retried later when their init
function returns -EPROBE_DEFER. So (eventually) they all succeed
initialization.

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] clocksource/drivers/ostm: Delay driver registration

[Daniel Lezcano]

On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> Hi Daniel,
> 
> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
>  wrote:
>> On 29/08/2018 17:44, Chris Brandt wrote:
>>> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
 Can the boot constraints [1] solve this issue instead of the changes you
 are proposing ?

 [1] https://lwn.net/Articles/747250/
>>>
>>> Thanks for the suggestion, but...
>>>
>>> I grepped for "boot_constraint" and it shows up nowhere in the current
>>> kernel.
>>>
>>> Also, this article was written Feb 16, 2018, and I can see that the
>>> patch series was still being submitted (V7) as of Feb 23, 2018.
>>
>> Ah ok, fair enough, I thought it was merged. In any case, after thinking
>> about it, it wouldn't have helped.
>>
>> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
>> the boot order, it would be better.
>>
>> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
>> dependencies' [1]?
> 
> *_OF_DECLARE() is not compatible with EPROBE_DEFER, which causes
> issues with complex dependencies.

What causes issues ? Add support for EPROBE_DEFER with OF_DECLARE or not
having support of it ?

> That's exactly why many subsystems are moving away from it.
> E.g. IOMMU_OF_DECLARE was removed in v4.19-rc1.

Ok, thanks for information.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v2] clk: renesas: cpg-mssr: Add R7S9210 support

[Geert Uytterhoeven]

Hi Rob,

On Wed, Aug 29, 2018 at 2:52 AM Rob Herring  wrote:
> On Mon, Aug 27, 2018 at 11:21:39AM -0500, Chris Brandt wrote:
> > Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> > Standby.
> >
> > The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> > for how the registers are laid out.
> > The MSTP registers are only 8-bits wide, there is no status registers
> > (MSTPST), and the register offsets are a little different. Since the RZ/A
> > hardware manuals refer to these registers as the Standby Control Registers,
> > we'll use that name to distinguish the RZ/A type for the R-Car type.
> >
> > Signed-off-by: Chris Brandt 
> > ---
>
> > +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
> > @@ -0,0 +1,192 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
>
>
> > +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
> > @@ -0,0 +1,21 @@
> > +/* SPDX-License-Identifier: GPL-2.0+
>
> The proper identifier is GPL-2.0-or-later

Documentation/process/license-rules.rst disagrees.

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: vsps and channel indices (was: Re: [PATCH v3 1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support)

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Aug 29, 2018 at 11:12 AM Laurent Pinchart
 wrote:
> On Tuesday, 28 August 2018 15:10:52 EEST Geert Uytterhoeven wrote:
> > On Wed, Jun 13, 2018 at 10:11 PM Sergei Shtylyov wrote:
> > > Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
> > > R8A77980 device tree...
> > >
> > > Based on the original (and large) patch by Vladimir Barinov.
> > >
> > > Signed-off-by: Vladimir Barinov 
> > > Signed-off-by: Sergei Shtylyov 
> > > Reviewed-by: Laurent Pinchart 
> > >
> > > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > >
> > > +   du: display@feb0 {
> > > +   compatible = "renesas,du-r8a77980",
> > > +"renesas,du-r8a77970";
> > > +   reg = <0 0xfeb0 0 0x8>;
> > > +   interrupts = ;
> > > +   clocks = < CPG_MOD 724>;
> > > +   clock-names = "du.0";
> > > +   power-domains = < R8A77980_PD_ALWAYS_ON>;
> > > +   resets = < 724>;
> > > +   vsps = <>;
> >
> > According to the bindings, the vsps property should also contain a
> > channel index.
> >
> > Laurent added the indices to r8a7795.dtsi, but r8a7795-es.dtsi overrides
> > that with a version without the indices.
> > Kieran included the indices when adding DU support for r8a77965 and
> > r8a77995.
> >
> > r8a7796.dtsi, r8a77970.dtsi, and r8a77980.dtsi lack the indices.
> >
> > Commit fd57d77f9c649cf9 ("dt-bindings: display: rcar-du: Add a VSP channel
> > index to the vsps DT property") says a backwards-compatibility mode can be
> > implemented, but I fail to see how this can work, as rcar_du_vsps_init()
> > will just return an error, which is propagated.
> >
> > What am I missing?
>
> We're missing a DT validator :-/
>
> The vsps property shoould indeed contain indices. However, rcar_du_vsps_init()
> implements a backward-compatibility mode by checking the length of the
> property:
>
> cells = of_property_count_u32_elems(np, "vsps") / rcdu->num_crtcs - 1;
>
> and using that as an argument to of_parse_phandle_with_fixed_args().

Thanks for the explanation! I had seen that call, but failed to discover the
actual fallback mechanism in the code...

Perhaps updating the comment to describe the backward-compatibility mode
would help:

/*
 * First parse the DT vsps property to populate the list of VSPs. Each
 * entry contains a pointer to the VSP DT node and a bitmask of the
 * connected DU CRTCs.
 */

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

Re: [PATCH] arm64: dts: salvator-common: Add PWM-2 channel

[Geert Uytterhoeven]

Hi Hoan,

On Wed, Aug 29, 2018 at 11:33 AM Nguyen An Hoan  wrote:
> From: Hoan Nguyen An 
>
> Add PWM-2 channel(CN28 - pin30) support for Salvator-X

Thanks for your patch!

Please explain why this is useful. Usually we do not enable random functionality
on expansion connectors.

In this case, this even has an (undocumented) impact on on-board devices,
as the signal is also connected to the BD9571MWV PMIC.
(Perhaps that was the actual intention of this patch? ;-) If yes,
please explain)

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

Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Geert Uytterhoeven]

Hi Daniel,

On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
 wrote:
> On 29/08/2018 17:44, Chris Brandt wrote:
> > On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> >> Can the boot constraints [1] solve this issue instead of the changes you
> >> are proposing ?
> >>
> >> [1] https://lwn.net/Articles/747250/
> >
> > Thanks for the suggestion, but...
> >
> > I grepped for "boot_constraint" and it shows up nowhere in the current
> > kernel.
> >
> > Also, this article was written Feb 16, 2018, and I can see that the
> > patch series was still being submitted (V7) as of Feb 23, 2018.
>
> Ah ok, fair enough, I thought it was merged. In any case, after thinking
> about it, it wouldn't have helped.
>
> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
> the boot order, it would be better.
>
> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
> dependencies' [1]?

*_OF_DECLARE() is not compatible with EPROBE_DEFER, which causes
issues with complex dependencies.
That's exactly why many subsystems are moving away from it.
E.g. IOMMU_OF_DECLARE was removed in v4.19-rc1.

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] thermal: rcar: reduce inaccuracy in calculate rounding

[Geert Uytterhoeven]

Hi Hoan,

On Thu, Aug 30, 2018 at 4:39 AM Nguyen An Hoan  wrote:
> From: Hoan Nguyen An 
>
> About the formula for temperature calculation
> [reg] = [temp] * a + b <=> [temp] = ([reg] - b) / a
>
> Using "(mcelsius * tsc-> coef.aX) / 1000" instead of 
> "DIV_ROUND_CLOSEST(mcelsius, 1000) * tsc-> coef.aX"
> to avoid and reduce inaccuracy due to rounding the integer division.
>
> Signed-off-by: Hoan Nguyen An 

Thanks for your patch!

> --- a/drivers/thermal/rcar_gen3_thermal.c
> +++ b/drivers/thermal/rcar_gen3_thermal.c
> @@ -185,11 +185,10 @@ static int rcar_gen3_thermal_get_temp(void *devdata, 
> int *temp)
>  static int rcar_gen3_thermal_mcelsius_to_temp(struct rcar_gen3_thermal_tsc 
> *tsc,
>   int mcelsius)
>  {
> -   int celsius, val1, val2;
> +   int val1, val2;
>
> -   celsius = DIV_ROUND_CLOSEST(mcelsius, 1000);
> -   val1 = celsius * tsc->coef.a1 + tsc->coef.b1;
> -   val2 = celsius * tsc->coef.a2 + tsc->coef.b2;
> +   val1 = (mcelsius * tsc->coef.a1)/1000 + tsc->coef.b1;
> +   val2 = (mcelsius * tsc->coef.a2)/1000 + tsc->coef.b2;

No rounding anymoe?

val1 = DIV_ROUND_CLOSEST(mcelsius * tsc->coef.a1, 1000) + tsc->coef.b1;
val2 = DIV_ROUND_CLOSEST(mcelsius * tsc->coef.a2, 1000) + tsc->coef.b2;

Can the multiplication overflow?

I know mcelsius = -4..12/
What is the range of a1 and a2?

>
> return INT_FIXPT((val1 + val2) / 2);

BTW, do we want to introduce rounding here, too?
(for INT_FIXPT(), it doesn't matter much for /2)?

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