Re: [PATCH v6 07/11] ARM: sun9i: smp: Rename clusters's power-off

2018-04-17 Thread Mylène Josserand
Hello,

On Tue, 17 Apr 2018 11:21:02 +0300
Sergei Shtylyov  wrote:

> Hello!
> 
> On 4/17/2018 12:50 AM, Mylène Josserand wrote:
> 
> > To prepare the support for sun8i-a83t, rename the variable name  
> 
> s/variable/macro/ maybe? Also "rename the ... name" sounds tautological...

Thank you for the correction.

Best regards,

Mylène

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

> 
> > that handles the power-off of clusters because it is different from
> > sun9i-a80 to sun8i-a83t.
> > 
> > The power off register for clusters are different from a80 and a83t.
> > 
> > Signed-off-by: Mylène Josserand 
> > Acked-by: Maxime Ripard 
> > Reviewed-by: Chen-Yu Tsai 
> > ---
> >   arch/arm/mach-sunxi/mc_smp.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> > index 727968d6a3e5..03f021d0c73e 100644
> > --- a/arch/arm/mach-sunxi/mc_smp.c
> > +++ b/arch/arm/mach-sunxi/mc_smp.c
> > @@ -60,7 +60,7 @@
> >   #define PRCM_CPU_PO_RST_CTRL_CORE(n)  BIT(n)
> >   #define PRCM_CPU_PO_RST_CTRL_CORE_ALL 0xf
> >   #define PRCM_PWROFF_GATING_REG(c) (0x100 + 0x4 * (c))
> > -#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
> > +#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
> >   #define PRCM_PWROFF_GATING_REG_CORE(n)BIT(n)
> >   #define PRCM_PWR_SWITCH_REG(c, cpu)   (0x140 + 0x10 * (c) + 0x4 * 
> > (cpu))
> >   #define PRCM_CPU_SOFT_ENTRY_REG   0x164
> > @@ -255,7 +255,7 @@ static int sunxi_cluster_powerup(unsigned int cluster)
> >   
> > /* clear cluster power gate */
> > reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > -   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER;
> > +   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
> > writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > udelay(20);
> >   
> > @@ -452,7 +452,7 @@ static int sunxi_cluster_powerdown(unsigned int cluster)
> > /* gate cluster power */
> > pr_debug("%s: gate cluster power\n", __func__);
> > reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > -   reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
> > +   reg |= PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
> > writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
> > udelay(20);
> > 
> 
> MBR, Sergei



Re: [PATCH v6 00/11] Sunxi: Add SMP support on A83T

2018-04-17 Thread Mylène Josserand
Hello Ondrej,

On Tue, 17 Apr 2018 04:15:00 +0200
Ondřej Jirman  wrote:

> Hello Mylène,
> 
> Please also add this:
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index ce53ceaf4cc5..d9c8ecf88ec6 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -51,7 +51,7 @@ config MACH_SUN9I
>  config ARCH_SUNXI_MC_SMP
> bool
> depends on SMP
> -   default MACH_SUN9I
> + default MACH_SUN9I || MACH_SUN8I
> select ARM_CCI400_PORT_CTRL
> select ARM_CPU_SUSPEND
> 
> Because otherwise when I'm building kernel just for sun8i and I don't have 
> sun9i
> enabled, this new SMP code for A83T (which is sun8i) will not be built.
> 

True, I forgot to add this, thanks!

Best regards,

Mylène

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


> thank you,
>   Ondrej
> 
> On Mon, Apr 16, 2018 at 11:50:21PM +0200, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This is a V6 of my series that adds SMP support for Allwinner sun8i-a83t.
> > Based on sunxi's tree, sunxi/for-next branch.
> > Depends on a patch from Doug Berger that allows to include the "cpu-type"
> > header on assembly files:
> > 6c7dd080ba4b ("ARM: Allow this header to be included by assembly files")
> > 
> > This new series refactors the shmobile code to use the function introduced
> > in this series: "secure_cntvoff_init".
> > Geert Uytterhoeven and Simon Horman, could you review and test this series
> > on Renesas boards? Thank you very much!
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> > 
> > Changes since v5:
> > - Remove my patch 01 and use the patch of Doug Berger to be able to
> > include the cpu-type header on assembly files.
> > - Rename smp_init_cntvoff function into secure_cntvoff_init according
> > to Marc Zyngier's review.
> > - According to Chen-Yu and Maxime's reviews, remove the patch that was
> > moving structures. Instead of using an index to retrieve which
> > architecture we are having, use a global variable.
> > - Merge the 2 patches that move assembly code from C to assembly file.
> > - Use a sun8i field instead of sun9i to know on which architecture we
> > are using because many modifications/additions of the code are for
> > sun8i-a83t.
> > - Rework the patch "add is_sun8i field" to add only this field in this
> > patch. The part of the patch that was starting to handle the differences
> > between sun8i-a83t and sun9i-a80 is merged in the patch that adds the
> > support of sun8i-a83t.
> > - Add a new patch that refactor the shmobile code to use the new 
> > function
> > secure_cntvoff_init introduced in this series.
> > 
> > Changes since v4:
> > - Rebased my series according to new Chen-Yu series:
> >"ARM: sunxi: Clean and improvements for multi-cluster SMP"
> >https://lkml.org/lkml/2018/3/8/886
> > - Updated my series according to Marc Zyngier's reviews to add CNTVOFF
> > initialization's function into ARM's common part. Thanks to that, other
> > platforms such as Renesa can use this function.
> > - For boot CPU, create a new machine to handle the CNTVOFF 
> > initialization
> > using "init_early" callback.
> > Changes since v3:
> > - Take into account Maxime's reviews:
> > - split the first patch into 4 new patches: add sun9i device tree
> > parsing, rename some variables, add a83t support and finally,
> > add hotplug support.
> > - Move the code of previous patch 07 (to disable CPU0 disabling)
> > into hotplug support patch (see patch 04)
> > - Remove the patch that added PRCM register because it is already
> > available. Because of that, update the device tree parsing to use
> > "sun8i-a83t-r-ccu".
> > - Use a variable to know which SoC we currently have
> > - Take into account Chen-Yu's reviews: create two iounmap functions
> > to release the resources of the device tree parsing.
> > - Take into account Marc's review: Update the code to initialize CNTVOFF
> > register. As there is already assembly code in the driver, I decided
> > to create an assembly file not to mix assembly and C code.
> > For that, I create 3 new patches: move the current assembly code that
> > handles the cluster cache enabling into a file, move the cpu_resume 
> > entry
> > in this file and finally, add a new assembly entry to initialize the 
> > timer
> > offset for boot CPU and secondary CPUs.
> > 
> > Changes since v2:
> > - Rebased my modifications according to new Chen Yu's patch series
> > that adds SMP support for sun9i-a80 (without MCPM).
> > - Split the device-tree patches into 3 patches for CPUCFG, R_CPUCFG
> > and PRCM registers for more visibility.
> > - The hotplug of CPU0 is currently not working (even after 

Re: [PATCH v6 09/11] ARM: sun8i: smp: Add support for A83T

2018-04-17 Thread Mylène Josserand
Hello Maxime,

On Tue, 17 Apr 2018 13:20:38 +0200
Maxime Ripard  wrote:

> On Mon, Apr 16, 2018 at 11:50:30PM +0200, Mylène Josserand wrote:
> > @@ -535,8 +599,12 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu)
> > return !ret;
> >  }
> >  
> > -static bool sunxi_mc_smp_cpu_can_disable(unsigned int __unused)
> > +static bool sunxi_mc_smp_cpu_can_disable(unsigned int cpu)
> >  {
> > +   /* CPU0 hotplug not handled for sun8i-a83t */
> > +   if (is_sun8i)
> > +   if (cpu == 0)
> > +   return false;
> > return true;  
> 
> I think Chen-Yu told you how to implement the hotplug in the previous
> iteration, did you have time to test it?

Not yet, I will have a look this evening.

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


[PATCH] arm64: dts: r8a77965: Add R-Car Gen3 thermal support

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Based on previous work by Ryo Kataoka .

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 59 +++
 1 file changed, 59 insertions(+)

Hi Simon,

This patch depends on '[PATCH 0/2] thermal: rcar_gen3_thermal: add 
r8a77965 support'. So it's probably best you hold back applying it to 
such time it's dependency are accepted. I post it in any case to get 
review comments and keep it ready for future integration in 
renesas-drivers branches.

It also uses numerical values for the power-doamains propery as the 
defines where not yet available for me. This shall of course be updated 
before they are accepted.

// Niklas

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index a41f91653d93595b..8469453d8085ebee 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -199,6 +199,21 @@
#power-domain-cells = <1>;
};
 
+   tsc: thermal@e6198000 {
+   compatible = "renesas,r8a77965-thermal";
+   reg = <0 0xe6198000 0 0x100>,
+ <0 0xe61a 0 0x100>,
+ <0 0xe61a8000 0 0x100>;
+   interrupts = ,
+,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < 32>;
+   resets = < 522>;
+   #thermal-sensor-cells = <1>;
+   status = "okay";
+   };
+
gpio0: gpio@e605 {
compatible = "renesas,gpio-r8a77965",
 "renesas,rcar-gen3-gpio";
@@ -1073,4 +1088,48 @@
/* placeholder */
};
};
+
+   thermal-zones {
+   sensor_thermal1: sensor-thermal1 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+   thermal-sensors = < 0>;
+
+   trips {
+   sensor1_crit: sensor1-crit {
+   temperature = <12>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal2: sensor-thermal2 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+   thermal-sensors = < 1>;
+
+   trips {
+   sensor2_crit: sensor2-crit {
+   temperature = <12>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+   };
+
+   sensor_thermal3: sensor-thermal3 {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+   thermal-sensors = < 2>;
+
+   trips {
+   sensor3_crit: sensor3-crit {
+   temperature = <12>;
+   hysteresis = <1000>;
+   type = "critical";
+   };
+   };
+   };
+   };
 };
-- 
2.17.0



[PATCH 2/2] thermal: rcar_gen3_thermal: add r8a77965 support

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Signed-off-by: Niklas Söderlund 
---
 drivers/thermal/rcar_gen3_thermal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
index 561a0a332208504a..c04182e1518cd613 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -329,6 +329,7 @@ static void rcar_gen3_thermal_init(struct 
rcar_gen3_thermal_tsc *tsc)
 static const struct of_device_id rcar_gen3_thermal_dt_ids[] = {
{ .compatible = "renesas,r8a7795-thermal", },
{ .compatible = "renesas,r8a7796-thermal", },
+   { .compatible = "renesas,r8a77965-thermal", },
{},
 };
 MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);
-- 
2.17.0



[PATCH 0/2] thermal: rcar_gen3_thermal: add r8a77965 support

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Hi,

This series adds DT documentation and driver support to the 
rcar-gen3-thermal driver for r8a77965.

Niklas Söderlund (2):
  dt-bindings: thermal: rcar-gen3-thermal: add r8a77965
  thermal: rcar_gen3_thermal: add r8a77965 support

 .../devicetree/bindings/thermal/rcar-gen3-thermal.txt  | 3 ++-
 drivers/thermal/rcar_gen3_thermal.c| 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

-- 
2.17.0



[PATCH 1/2] dt-bindings: thermal: rcar-gen3-thermal: add r8a77965

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Based on previous work by Ryo Kataoka .

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/thermal/rcar-gen3-thermal.txt  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
index 39e7d4e61a63c038..de834c4442d5f213 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
@@ -9,6 +9,7 @@ Required properties:
  Examples with soctypes are:
- "renesas,r8a7795-thermal" (R-Car H3)
- "renesas,r8a7796-thermal" (R-Car M3-W)
+   - "renesas,r8a77965-thermal" (R-Car M3-N)
 - reg  : Address ranges of the thermal registers. Each sensor
  needs one address range. Sorting must be done in
  increasing order according to datasheet, i.e.
@@ -18,7 +19,7 @@ Required properties:
 
 Optional properties:
 
-- interrupts   : interrupts routed to the TSC (3 for H3 and M3-W)
+- interrupts   : interrupts routed to the TSC (3 for H3 and M3-W, M3-N)
 - power-domain : Must contain a reference to the power domain. This
  property is mandatory if the thermal sensor instance
  is part of a controllable power domain.
-- 
2.17.0



[PATCH 0/2] thermal: rcar_gen3_thermal: update constants for calculation of temperature

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Hi,

This series updates the constants used to convert the register values to 
degrease. It is based on feedback from the hardware team communicated 
through BSP patches and updated datasheets. :-)

Hien Dang (1):
  thermal: rcar_gen3_thermal: Update calculation formula due to HW
evaluation

Niklas Söderlund (1):
  thermal: rcar_gen3_thermal: update max temperature clamp

 drivers/thermal/rcar_gen3_thermal.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

-- 
2.17.0



[PATCH 2/2] thermal: rcar_gen3_thermal: update max temperature clamp

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Change the upper limit to clamp the high temperature value to 120C when
setting trip points.

Signed-off-by: Niklas Söderlund 
---
 drivers/thermal/rcar_gen3_thermal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
index 79c2cdb4105fc0b8..3905ec8b2689827c 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -207,8 +207,8 @@ static int rcar_gen3_thermal_set_trips(void *devdata, int 
low, int high)
 {
struct rcar_gen3_thermal_tsc *tsc = devdata;
 
-   low = clamp_val(low, -4, 125000);
-   high = clamp_val(high, -4, 125000);
+   low = clamp_val(low, -4, 12);
+   high = clamp_val(high, -4, 12);
 
rcar_gen3_thermal_write(tsc, REG_GEN3_IRQTEMP1,
rcar_gen3_thermal_mcelsius_to_temp(tsc, low));
-- 
2.17.0



[PATCH 1/2] thermal: rcar_gen3_thermal: Update calculation formula due to HW evaluation

2018-04-17 Thread Niklas Söderlund
From: Hien Dang 

Due to hardware evaluation result,
Max temperature is changed from 96 to 116 degree Celsius.
Also, calculation formula and pseudo FUSE values are changed accordingly.

Signed-off-by: Dien Pham 
Signed-off-by: Hien Dang 
Signed-off-by: Niklas Söderlund 
---
 drivers/thermal/rcar_gen3_thermal.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/rcar_gen3_thermal.c 
b/drivers/thermal/rcar_gen3_thermal.c
index 561a0a332208504a..79c2cdb4105fc0b8 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -132,7 +132,7 @@ static inline void rcar_gen3_thermal_write(struct 
rcar_gen3_thermal_tsc *tsc,
 #define RCAR3_THERMAL_GRAN 500 /* mili Celsius */
 
 /* no idea where these constants come from */
-#define TJ_1 96
+#define TJ_1 116
 #define TJ_3 -41
 
 static void rcar_gen3_thermal_calc_coefs(struct equation_coefs *coef,
@@ -146,7 +146,7 @@ static void rcar_gen3_thermal_calc_coefs(struct 
equation_coefs *coef,
 * Division is not scaled in BSP and if scaled it might overflow
 * the dividend (4095 * 4095 << 14 > INT_MAX) so keep it unscaled
 */
-   tj_2 = (FIXPT_INT((ptat[1] - ptat[2]) * 137)
+   tj_2 = (FIXPT_INT((ptat[1] - ptat[2]) * 157)
/ (ptat[0] - ptat[2])) - FIXPT_INT(41);
 
coef->a1 = FIXPT_DIV(FIXPT_INT(thcode[1] - thcode[2]),
@@ -354,11 +354,11 @@ static int rcar_gen3_thermal_probe(struct platform_device 
*pdev)
 
/* default values if FUSEs are missing */
/* TODO: Read values from hardware on supported platforms */
-   int ptat[3] = { 2351, 1509, 435 };
+   int ptat[3] = { 2631, 1509, 435 };
int thcode[TSC_MAX_NUM][3] = {
-   { 3248, 2800, 2221 },
-   { 3245, 2795, 2216 },
-   { 3250, 2805, 2237 },
+   { 3397, 2800, 2221 },
+   { 3393, 2795, 2216 },
+   { 3389, 2805, 2237 },
};
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-- 
2.17.0



[PATCH 0/2] arm64: dts: renesas: r8a779{5,6}: decrease temperature

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

Hi Simon,

This series decrease the hysteresis from 2C to 1C for the two boards we 
have described upstream. They have no dependencies and are ready to be 
accepted if the review is in favor of them.

Niklas Söderlund (2):
  arm64: dts: renesas: r8a7795: decrease temperature hysteresis
  arm64: dts: renesas: r8a7796: decrease temperature hysteresis

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12 ++--
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 12 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.17.0



[PATCH 2/2] arm64: dts: renesas: r8a7796: decrease temperature hysteresis

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

To incorporate more tests by the hardware team decrease the hysteresis
value to 1C.

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 599c74d6a6cb67ab..e3a28b9a5fbdd2a6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2438,12 +2438,12 @@
trips {
sensor1_passive: sensor1-passive {
temperature = <95000>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "passive";
};
sensor1_crit: sensor1-crit {
temperature = <12>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "critical";
};
};
@@ -2464,12 +2464,12 @@
trips {
sensor2_passive: sensor2-passive {
temperature = <95000>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "passive";
};
sensor2_crit: sensor2-crit {
temperature = <12>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "critical";
};
};
@@ -2490,12 +2490,12 @@
trips {
sensor3_passive: sensor3-passive {
temperature = <95000>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "passive";
};
sensor3_crit: sensor3-crit {
temperature = <12>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "critical";
};
};
-- 
2.17.0



[PATCH 1/2] arm64: dts: renesas: r8a7795: decrease temperature hysteresis

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

To incorporate more tests by the hardware team decrease the hysteresis
value to 1C.

Signed-off-by: Niklas Söderlund 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 5ae85d8a7685aec8..6eaa7c78d8402a7c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2826,12 +2826,12 @@
trips {
sensor1_passive: sensor1-passive {
temperature = <95000>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "passive";
};
sensor1_crit: sensor1-crit {
temperature = <12>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "critical";
};
};
@@ -2852,12 +2852,12 @@
trips {
sensor2_passive: sensor2-passive {
temperature = <95000>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "passive";
};
sensor2_crit: sensor2-crit {
temperature = <12>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "critical";
};
};
@@ -2878,12 +2878,12 @@
trips {
sensor3_passive: sensor3-passive {
temperature = <95000>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "passive";
};
sensor3_crit: sensor3-crit {
temperature = <12>;
-   hysteresis = <2000>;
+   hysteresis = <1000>;
type = "critical";
};
};
-- 
2.17.0



[PATCH] dt-bindings: thermal: rcar-gen3-thermal: update register size in example

2018-04-17 Thread Niklas Söderlund
From: Niklas Söderlund 

The datasheet have been expanded with more registers and the DT files
have been updated with the new size. This change updates the example so
writing new DT files can use the enchanted driver which uses the new
registers.

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/thermal/rcar-gen3-thermal.txt   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
index fdf5caa6229b4fff..39e7d4e61a63c038 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
@@ -27,9 +27,9 @@ Example:
 
tsc: thermal@e6198000 {
compatible = "renesas,r8a7795-thermal";
-   reg = <0 0xe6198000 0 0x68>,
- <0 0xe61a 0 0x5c>,
- <0 0xe61a8000 0 0x5c>;
+   reg = <0 0xe6198000 0 0x100>,
+ <0 0xe61a 0 0x100>,
+ <0 0xe61a8000 0 0x100>;
interrupts = ,
 ,
 ;
-- 
2.17.0



Re: [PATCH/RFC net-next 2/5] ravb: correct ptp does failure after suspend and resume

2018-04-17 Thread Sergei Shtylyov
On 04/17/2018 01:05 PM, Wolfram Sang wrote:

>> @@ -2302,6 +2305,7 @@ static int __maybe_unused ravb_resume(struct device 
>> *dev)
>>  {
>>  struct net_device *ndev = dev_get_drvdata(dev);
>>  struct ravb_private *priv = netdev_priv(ndev);
>> +struct platform_device *pdev = priv->pdev;

   Could infer 'pdev' from 'dev' (avoiding the dereference)...

> Minor nit: I'd save this line...
> 
>> +if (priv->chip_id != RCAR_GEN2)
>> +ravb_ptp_init(ndev, pdev);
> 
> ... and use ravb_ptp_init(ndev, priv->pdev); here.

   Agreed, no dire need for the new variable used only once.

MBR, Sergei


Re: [PATCH v5 3/6] dt-bindings: arm: Document the RZN1D-DB board

2018-04-17 Thread Geert Uytterhoeven
Hi Michel,

On Tue, Apr 17, 2018 at 1:04 PM, Michel Pollet
 wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
>
> Signed-off-by: Michel Pollet 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
> b/Documentation/devicetree/bindings/arm/shmobile.txt
> index 61b486f..6efb3f1 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -51,7 +51,8 @@ SoCs:
>  compatible = "renesas,r8a77990"
>- R-Car D3 (R8A77995)
>  compatible = "renesas,r8a77995"
> -
> +  - RZ/N1D (R9A06G032)
> +compatible = "renesas,r9a06g032", "renesas,rzn1"

Why do you need a family-specific compatible value ("renesas,rzn1",
which is a marketing name)?

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] sh: migor: Set DMA and DMA coherent mask

2018-04-17 Thread jacopo mondi
Hi Geert,

On Tue, Apr 17, 2018 at 04:30:03PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> CC Christoph
>
> On Tue, Apr 17, 2018 at 4:13 PM, Jacopo Mondi  
> wrote:
> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> > coherent_dma_mask") the Migo-R platform devices registered without a DMA
> > mask and coherent DMA mask issue the following warning
> >
> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
> >
> > Set dma mask and coherent DMA mask for Migo-R platforms devices to 32
> > bits as all other SH4a platforms do.
> >
> > Signed-off-by: Jacopo Mondi 
>
> Thanks for your patch!
>
> Reviewed-by: Geert Uytterhoeven 
>
> I guess usbf_device.dev.dma_mask should be fixed as well?

I don't get any warning for that. The only platform devices on which
platform_resource_setup_memory() is called on before registering them
are the ones this patch modifies, if I'm not wrong.

>
> BTW, there are plenty of other SH platforms that need similar fixes.

Oh, why am I not surprised? :/

Thanks
   j

>
> > ---
> >  arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c 
> > b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
> > index 6b3a26e..3fe1ea7 100644
> > --- a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
> > +++ b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
> > @@ -7,6 +7,7 @@
> >   * License.  See the file "COPYING" in the main directory of this archive
> >   * for more details.
> >   */
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -347,6 +348,8 @@ static struct platform_device vpu_device = {
> > .name   = "uio_pdrv_genirq",
> > .id = 0,
> > .dev = {
> > +   .dma_mask   = _device.dev.coherent_dma_mask,
> > +   .coherent_dma_mask  = DMA_BIT_MASK(32),
> > .platform_data  = _platform_data,
> > },
> > .resource   = vpu_resources,
> > @@ -375,6 +378,8 @@ static struct platform_device veu_device = {
> > .name   = "uio_pdrv_genirq",
> > .id = 1,
> > .dev = {
> > +   .dma_mask   = _device.dev.coherent_dma_mask,
> > +   .coherent_dma_mask  = DMA_BIT_MASK(32),
> > .platform_data  = _platform_data,
> > },
> > .resource   = veu_resources,
> > @@ -403,6 +408,8 @@ static struct platform_device jpu_device = {
> > .name   = "uio_pdrv_genirq",
> > .id = 2,
> > .dev = {
> > +   .dma_mask   = _device.dev.coherent_dma_mask,
> > +   .coherent_dma_mask  = DMA_BIT_MASK(32),
> > .platform_data  = _platform_data,
> > },
> > .resource   = jpu_resources,
>
> 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


signature.asc
Description: PGP signature


[PATCH v2] sh: mm: Fix unprotected access to struct device

2018-04-17 Thread Jacopo Mondi
With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
operations observe dev->dma_pfn_offset") the generic DMA allocation
function on which the SH 'dma_alloc_coherent()' function relies on,
accesses the 'dma_pfn_offset' field of struct device.

Unfortunately the 'dma_generic_alloc_coherent()' function is called from
several places with a NULL struct device argument, halting the CPU
during the boot process.

This patch fixes the issue by protecting access to dev->dma_pfn_offset,
with a trivial check for validity. It also passes a valid 'struct device'
in the 'platform_resource_setup_memory' function which is the main user
of 'dma_alloc_coherent()', and inserts a WARN_ON() check to remind to future
(and existing) bogus users of this function to provide a valid 'struct device'
whenever possible.

Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations 
observe dev->dma_pfn_offset")
Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Thomas Petazzoni 
---
 arch/sh/mm/consistent.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index 8ce9869..ec177c0 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -59,7 +59,9 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
size,

split_page(pfn_to_page(virt_to_phys(ret) >> PAGE_SHIFT), order);

-   *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
+   *dma_handle = virt_to_phys(ret);
+   if (!WARN_ON(!dev))
+   *dma_handle -= PFN_PHYS(dev->dma_pfn_offset);

return ret_nocache;
 }
@@ -69,9 +71,12 @@ void dma_generic_free_coherent(struct device *dev, size_t 
size,
   unsigned long attrs)
 {
int order = get_order(size);
-   unsigned long pfn = (dma_handle >> PAGE_SHIFT) + dev->dma_pfn_offset;
+   unsigned long pfn = (dma_handle >> PAGE_SHIFT);
int k;

+   if (!WARN_ON(!dev))
+   pfn += dev->dma_pfn_offset;
+
for (k = 0; k < (1 << order); k++)
__free_pages(pfn_to_page(pfn + k), 0);

@@ -143,7 +148,7 @@ int __init platform_resource_setup_memory(struct 
platform_device *pdev,
if (!memsize)
return 0;

-   buf = dma_alloc_coherent(NULL, memsize, _handle, GFP_KERNEL);
+   buf = dma_alloc_coherent(>dev, memsize, _handle, GFP_KERNEL);
if (!buf) {
pr_warning("%s: unable to allocate memory\n", name);
return -ENOMEM;
--
2.7.4



Re: [PATCH] sh: migor: Set DMA and DMA coherent mask

2018-04-17 Thread Geert Uytterhoeven
Hi Jacopo,

CC Christoph

On Tue, Apr 17, 2018 at 4:13 PM, Jacopo Mondi  wrote:
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the Migo-R platform devices registered without a DMA
> mask and coherent DMA mask issue the following warning
>
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>
> Set dma mask and coherent DMA mask for Migo-R platforms devices to 32
> bits as all other SH4a platforms do.
>
> Signed-off-by: Jacopo Mondi 

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven 

I guess usbf_device.dev.dma_mask should be fixed as well?

BTW, there are plenty of other SH platforms that need similar fixes.

> ---
>  arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c 
> b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
> index 6b3a26e..3fe1ea7 100644
> --- a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
> +++ b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
> @@ -7,6 +7,7 @@
>   * License.  See the file "COPYING" in the main directory of this archive
>   * for more details.
>   */
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -347,6 +348,8 @@ static struct platform_device vpu_device = {
> .name   = "uio_pdrv_genirq",
> .id = 0,
> .dev = {
> +   .dma_mask   = _device.dev.coherent_dma_mask,
> +   .coherent_dma_mask  = DMA_BIT_MASK(32),
> .platform_data  = _platform_data,
> },
> .resource   = vpu_resources,
> @@ -375,6 +378,8 @@ static struct platform_device veu_device = {
> .name   = "uio_pdrv_genirq",
> .id = 1,
> .dev = {
> +   .dma_mask   = _device.dev.coherent_dma_mask,
> +   .coherent_dma_mask  = DMA_BIT_MASK(32),
> .platform_data  = _platform_data,
> },
> .resource   = veu_resources,
> @@ -403,6 +408,8 @@ static struct platform_device jpu_device = {
> .name   = "uio_pdrv_genirq",
> .id = 2,
> .dev = {
> +   .dma_mask   = _device.dev.coherent_dma_mask,
> +   .coherent_dma_mask  = DMA_BIT_MASK(32),
> .platform_data  = _platform_data,
> },
> .resource   = jpu_resources,

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] sh: mm: Fix unprotected access to struct device

2018-04-17 Thread jacopo mondi
Hi Geert,

On Tue, Apr 17, 2018 at 04:04:27PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> Thanks for your patch!
>
> On Tue, Apr 17, 2018 at 3:35 PM, Jacopo Mondi  
> wrote:
> > With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> > operations observe dev->dma_pfn_offset") the generic DMA allocation
> > function on which the SH 'dma_alloc_coherent()' function relies on,
> > access the 'dma_pfn_offset' field of struct device.
>
> accesses
>
> > Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> > several places with a NULL struct device argument, halting the CPU
> > during the boot process.
> >
> > This patch fixes the issue protecting access to dev->dma_pfn_offset,
>
> by protecting access to the
>
> > with a trivial check for validity. It also passes a valid 'struct device'
> > in the 'platform_resource_setup_memory' function which is the main user
> > of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> > (and existing) bogus users of this function they're should provide a valid
>
> drop "they're should"?
>
> > 'struct device' whenever possible.
>
> > --- a/arch/sh/mm/consistent.c
> > +++ b/arch/sh/mm/consistent.c
> > @@ -39,6 +39,8 @@ void *dma_generic_alloc_coherent(struct device *dev, 
> > size_t size,
> > void *ret, *ret_nocache;
> > int order = get_order(size);
> >
> > +   WARN_ON(!dev);
> > +
> > gfp |= __GFP_ZERO;
> >
> > ret = (void *)__get_free_pages(gfp, order);
> > @@ -59,7 +61,9 @@ void *dma_generic_alloc_coherent(struct device *dev, 
> > size_t size,
> >
> > split_page(pfn_to_page(virt_to_phys(ret) >> PAGE_SHIFT), order);
> >
> > -   *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
> > +   *dma_handle = virt_to_phys(ret);
> > +   if (dev)
> > +   *dma_handle -= PFN_PHYS(dev->dma_pfn_offset);
>
> I would keep the WARN_ON() and the (ideally unneeded) dev check as close
> to each other as possible:
>
> if (!WARN_ON(!dev))
> *dma_handle -= PFN_PHYS(dev->dma_pfn_offset);

Looking at include/linux/dma-mapping.h I thought it was good to have
the WARN_ON() as early as possible in the function.

But your one looks nicer indeed!

>
> >
> > return ret_nocache;
> >  }
> > @@ -69,9 +73,14 @@ void dma_generic_free_coherent(struct device *dev, 
> > size_t size,
> >unsigned long attrs)
> >  {
> > int order = get_order(size);
> > -   unsigned long pfn = (dma_handle >> PAGE_SHIFT) + 
> > dev->dma_pfn_offset;
> > +   unsigned long pfn = (dma_handle >> PAGE_SHIFT);
> > int k;
> >
> > +   WARN_ON(!dev);
> > +
> > +   if (dev)
> > +   pfn += dev->dma_pfn_offset;
>
> if (!WARN_ON(!dev))
> pfn += dev->dma_pfn_offset;
>
> > +
> > for (k = 0; k < (1 << order); k++)
> > __free_pages(pfn_to_page(pfn + k), 0);
>
> Reviewed-by: Geert Uytterhoeven 

I'll resend and append your and Thomas' tags.

Thanks
  j
>
> 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


signature.asc
Description: PGP signature


Re: [PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits

2018-04-17 Thread David Miller
From: Simon Horman 
Date: Tue, 17 Apr 2018 10:50:28 +0200

> From: Kazuya Mizuguchi 
> 
> This patch corrects writing 1 to reserved bits.
> The write value should be 0.
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Simon Horman 

How are we ending up in situations where the driver is trying to write
non-zero values to those fields in the first place?

The places creating those values should be making sure that the
reserved bits are never set.

If you mask out the reserved bits in the register writing locations,
this just hides bugs.


Re: [PATCH/RFC net-next 4/5] ravb: remove undocumented processing

2018-04-17 Thread David Miller
From: Simon Horman 
Date: Tue, 17 Apr 2018 10:50:29 +0200

> From: Kazuya Mizuguchi 
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Simon Horman 

Why?  What was wrong with it?

Need more text and explanations in these commit messages please.


[PATCH] sh: migor: Set DMA and DMA coherent mask

2018-04-17 Thread Jacopo Mondi
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Migo-R platform devices registered without a DMA
mask and coherent DMA mask issue the following warning

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20

Set dma mask and coherent DMA mask for Migo-R platforms devices to 32
bits as all other SH4a platforms do.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c 
b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
index 6b3a26e..3fe1ea7 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
@@ -7,6 +7,7 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  */
+#include 
 #include 
 #include 
 #include 
@@ -347,6 +348,8 @@ static struct platform_device vpu_device = {
.name   = "uio_pdrv_genirq",
.id = 0,
.dev = {
+   .dma_mask   = _device.dev.coherent_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
.platform_data  = _platform_data,
},
.resource   = vpu_resources,
@@ -375,6 +378,8 @@ static struct platform_device veu_device = {
.name   = "uio_pdrv_genirq",
.id = 1,
.dev = {
+   .dma_mask   = _device.dev.coherent_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
.platform_data  = _platform_data,
},
.resource   = veu_resources,
@@ -403,6 +408,8 @@ static struct platform_device jpu_device = {
.name   = "uio_pdrv_genirq",
.id = 2,
.dev = {
+   .dma_mask   = _device.dev.coherent_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
.platform_data  = _platform_data,
},
.resource   = jpu_resources,
--
2.7.4



Re: [PATCH] sh: mm: Fix unprotected access to struct device

2018-04-17 Thread Geert Uytterhoeven
Hi Jacopo,

Thanks for your patch!

On Tue, Apr 17, 2018 at 3:35 PM, Jacopo Mondi  wrote:
> With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> operations observe dev->dma_pfn_offset") the generic DMA allocation
> function on which the SH 'dma_alloc_coherent()' function relies on,
> access the 'dma_pfn_offset' field of struct device.

accesses

> Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> several places with a NULL struct device argument, halting the CPU
> during the boot process.
>
> This patch fixes the issue protecting access to dev->dma_pfn_offset,

by protecting access to the

> with a trivial check for validity. It also passes a valid 'struct device'
> in the 'platform_resource_setup_memory' function which is the main user
> of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> (and existing) bogus users of this function they're should provide a valid

drop "they're should"?

> 'struct device' whenever possible.

> --- a/arch/sh/mm/consistent.c
> +++ b/arch/sh/mm/consistent.c
> @@ -39,6 +39,8 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
> size,
> void *ret, *ret_nocache;
> int order = get_order(size);
>
> +   WARN_ON(!dev);
> +
> gfp |= __GFP_ZERO;
>
> ret = (void *)__get_free_pages(gfp, order);
> @@ -59,7 +61,9 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
> size,
>
> split_page(pfn_to_page(virt_to_phys(ret) >> PAGE_SHIFT), order);
>
> -   *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
> +   *dma_handle = virt_to_phys(ret);
> +   if (dev)
> +   *dma_handle -= PFN_PHYS(dev->dma_pfn_offset);

I would keep the WARN_ON() and the (ideally unneeded) dev check as close
to each other as possible:

if (!WARN_ON(!dev))
*dma_handle -= PFN_PHYS(dev->dma_pfn_offset);

>
> return ret_nocache;
>  }
> @@ -69,9 +73,14 @@ void dma_generic_free_coherent(struct device *dev, size_t 
> size,
>unsigned long attrs)
>  {
> int order = get_order(size);
> -   unsigned long pfn = (dma_handle >> PAGE_SHIFT) + dev->dma_pfn_offset;
> +   unsigned long pfn = (dma_handle >> PAGE_SHIFT);
> int k;
>
> +   WARN_ON(!dev);
> +
> +   if (dev)
> +   pfn += dev->dma_pfn_offset;

if (!WARN_ON(!dev))
pfn += dev->dma_pfn_offset;

> +
> for (k = 0; k < (1 << order); k++)
> __free_pages(pfn_to_page(pfn + k), 0);

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] sh: mm: Fix unprotected access to struct device

2018-04-17 Thread jacopo mondi
Hi Thomas,

On Tue, Apr 17, 2018 at 03:54:07PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 17 Apr 2018 15:35:23 +0200, Jacopo Mondi wrote:
> > With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> > operations observe dev->dma_pfn_offset") the generic DMA allocation
> > function on which the SH 'dma_alloc_coherent()' function relies on,
> > access the 'dma_pfn_offset' field of struct device.
> >
> > Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> > several places with a NULL struct device argument, halting the CPU
> > during the boot process.
> >
> > This patch fixes the issue protecting access to dev->dma_pfn_offset,
> > with a trivial check for validity. It also passes a valid 'struct device'
> > in the 'platform_resource_setup_memory' function which is the main user
> > of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> > (and existing) bogus users of this function they're should provide a valid
> > 'struct device' whenever possible.
> >
> > Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations 
> > observe dev->dma_pfn_offset")
> > Signed-off-by: Jacopo Mondi 
>
> I would have done two commits here, one to fix:
>
>   dma_alloc_coherent(>dev, memsize, _handle, GFP_KERNEL);
>
> and one to switch to the WARN_ON + if(dev) model. But I don't really
> care either way, so:

I thought about doing the same, but as this commit is a fix to be
applied on top of v4.17-rc1, and it's likely being fast tracked as it
breaks SH architecture (at least SH7722) I thought it was good to keep
all of that in a single commit.

>
> Reviewed-by: Thomas Petazzoni 
>

Thank you

> Note that even with the if (dev) check, you don't avoid all possible
> regressions. For example, some parts of the sh_eth driver were passing
> a non-NULL struct device, but it was the wrong struct device (the one
> inside struct net_device, and not the one part of struct
> platform_device). I fixed that for sh_eth, but there could be other
> drivers doing bogus things.

Well, not that much we can do here for other bogus users, right?

Thanks
   j

>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH] sh: mm: Fix unprotected access to struct device

2018-04-17 Thread Thomas Petazzoni
Hello,

On Tue, 17 Apr 2018 15:35:23 +0200, Jacopo Mondi wrote:
> With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> operations observe dev->dma_pfn_offset") the generic DMA allocation
> function on which the SH 'dma_alloc_coherent()' function relies on,
> access the 'dma_pfn_offset' field of struct device.
> 
> Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> several places with a NULL struct device argument, halting the CPU
> during the boot process.
> 
> This patch fixes the issue protecting access to dev->dma_pfn_offset,
> with a trivial check for validity. It also passes a valid 'struct device'
> in the 'platform_resource_setup_memory' function which is the main user
> of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> (and existing) bogus users of this function they're should provide a valid
> 'struct device' whenever possible.
> 
> Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations 
> observe dev->dma_pfn_offset")
> Signed-off-by: Jacopo Mondi 

I would have done two commits here, one to fix:

  dma_alloc_coherent(>dev, memsize, _handle, GFP_KERNEL);

and one to switch to the WARN_ON + if(dev) model. But I don't really
care either way, so:

Reviewed-by: Thomas Petazzoni 

Note that even with the if (dev) check, you don't avoid all possible
regressions. For example, some parts of the sh_eth driver were passing
a non-NULL struct device, but it was the wrong struct device (the one
inside struct net_device, and not the one part of struct
platform_device). I fixed that for sh_eth, but there could be other
drivers doing bogus things.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


[PATCH] sh: mm: Fix unprotected access to struct device

2018-04-17 Thread Jacopo Mondi
With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
operations observe dev->dma_pfn_offset") the generic DMA allocation
function on which the SH 'dma_alloc_coherent()' function relies on,
access the 'dma_pfn_offset' field of struct device.

Unfortunately the 'dma_generic_alloc_coherent()' function is called from
several places with a NULL struct device argument, halting the CPU
during the boot process.

This patch fixes the issue protecting access to dev->dma_pfn_offset,
with a trivial check for validity. It also passes a valid 'struct device'
in the 'platform_resource_setup_memory' function which is the main user
of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
(and existing) bogus users of this function they're should provide a valid
'struct device' whenever possible.

Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations 
observe dev->dma_pfn_offset")
Signed-off-by: Jacopo Mondi 
---
 arch/sh/mm/consistent.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index 8ce9869..b257155 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -39,6 +39,8 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
size,
void *ret, *ret_nocache;
int order = get_order(size);

+   WARN_ON(!dev);
+
gfp |= __GFP_ZERO;

ret = (void *)__get_free_pages(gfp, order);
@@ -59,7 +61,9 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
size,

split_page(pfn_to_page(virt_to_phys(ret) >> PAGE_SHIFT), order);

-   *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
+   *dma_handle = virt_to_phys(ret);
+   if (dev)
+   *dma_handle -= PFN_PHYS(dev->dma_pfn_offset);

return ret_nocache;
 }
@@ -69,9 +73,14 @@ void dma_generic_free_coherent(struct device *dev, size_t 
size,
   unsigned long attrs)
 {
int order = get_order(size);
-   unsigned long pfn = (dma_handle >> PAGE_SHIFT) + dev->dma_pfn_offset;
+   unsigned long pfn = (dma_handle >> PAGE_SHIFT);
int k;

+   WARN_ON(!dev);
+
+   if (dev)
+   pfn += dev->dma_pfn_offset;
+
for (k = 0; k < (1 << order); k++)
__free_pages(pfn_to_page(pfn + k), 0);

@@ -143,7 +152,7 @@ int __init platform_resource_setup_memory(struct 
platform_device *pdev,
if (!memsize)
return 0;

-   buf = dma_alloc_coherent(NULL, memsize, _handle, GFP_KERNEL);
+   buf = dma_alloc_coherent(>dev, memsize, _handle, GFP_KERNEL);
if (!buf) {
pr_warning("%s: unable to allocate memory\n", name);
return -ENOMEM;
--
2.7.4



Re: [PATCH v5 3/6] dt-bindings: arm: Document the RZN1D-DB board

2018-04-17 Thread Rob Herring
On Tue, Apr 17, 2018 at 12:04:18PM +0100, Michel Pollet wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
> 
> Signed-off-by: Michel Pollet 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Please add acks/reviewed-bys when posting new versions.

Rob


Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support

2018-04-17 Thread Geert Uytterhoeven
Hi Biju,

+ Sergei

On Tue, Apr 17, 2018 at 11:07 AM, Biju Das  wrote:
>> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
>> On Wed, Apr 4, 2018 at 5:22 PM, Biju Das  wrote:
>> > Add PFC support for the R8A77470 SoC including pin groups for some
>> > on-chip devices such as SCIF, AVB and MMC.
>> >
>> > Signed-off-by: Biju Das 
>> > Reviewed-by: Fabrizio Castro 

>> > --- /dev/null
>> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c

>> > +/* - AVB
>> > + */ 
>> > static const
>> unsigned int avb_link_pins[] = {
>> > +   RCAR_GP_PIN(5, 14),
>> > +};
>> > +static const unsigned int avb_link_mux[] = {
>> > +   AVB_LINK_MARK,
>> > +};
>> > +static const unsigned int avb_magic_pins[] = {
>> > +   RCAR_GP_PIN(5, 15),
>> > +};
>> > +static const unsigned int avb_magic_mux[] = {
>> > +   AVB_MAGIC_MARK,
>> > +};
>> > +static const unsigned int avb_phy_int_pins[] = {
>> > +   RCAR_GP_PIN(5, 16),
>> > +};
>> > +static const unsigned int avb_phy_int_mux[] = {
>> > +   AVB_PHY_INT_MARK,
>> > +};
>> > +static const unsigned int avb_mdio_pins[] = {
>> > +   RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 13), }; static const
>> > +unsigned int avb_mdio_mux[] = {
>> > +   AVB_MDC_MARK, AVB_MDIO_MARK,
>> > +};
>> > +static const unsigned int avb_mii_pins[] = {
>> > +   RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15), RCAR_GP_PIN(3, 16),
>> > +   RCAR_GP_PIN(3, 27),
>> > +
>> > +   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 4),
>> > +   RCAR_GP_PIN(3, 5),
>> > +
>> > +   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
>> > +   RCAR_GP_PIN(5, 17), RCAR_GP_PIN(3, 13), RCAR_GP_PIN(5, 23),
>> > +   RCAR_GP_PIN(3, 12),
>> > +};
>> > +static const unsigned int avb_mii_mux[] = {
>> > +   AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
>> > +   AVB_TXD3_MARK,
>> > +
>> > +   AVB_RXD0_MARK, AVB_RXD1_MARK, AVB_RXD2_MARK,
>> > +   AVB_RXD3_MARK,
>> > +
>> > +   AVB_RX_ER_MARK, AVB_RX_CLK_MARK, AVB_RX_DV_MARK,
>> > +   AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_ER_MARK,
>> > +   AVB_TX_CLK_MARK,
>>
>> You forgot AVB_COL, which is GP5_18?
>
> GP5_18 is shred between the signals AVB_COL and VI0_CLK. As per the RZ/G1C 
> board schematic /hardware user guide
> Ethernet Phy collision pin(AVB_COL) pin  is not populated on this board by 
> default. It is populated only for
> Video Input Channel0 pixel clock.
>
> Since it is initial submission, I thought of adding only board specific pins 
> first and later
> add this collision pin alone as a separate pin entry  in the avb group. That 
> way we can support existing board
> as well as any future RZ/G1C board which populates this pin. Are you ok for 
> this approach?

Oops. That means our grouping is suboptimal. Perhaps we should revisit
(for all SoCs, while keeping backwards compatibility)?

After reading some wikipedia, I came up with:

mii_tx
mii_tx_er (optional)
mii_rx
mii_col_crs (optional, half duplex)

However, given your board uses AVB_CRS without AVB_COL, that would still
not be sufficient, so the last group should be split to cover your use case?

BTW, how does it work with AVB_COL not wired to anything by default, and thus
floating? Do you enable pull-up/down for that pin in the PFC, or is the pin
just ignored in full-duplex mode?

>> > +};
>> > +static const unsigned int avb_gmii_pins[] = {
>> > +   RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15), RCAR_GP_PIN(3, 16),
>> > +   RCAR_GP_PIN(3, 27), RCAR_GP_PIN(3, 28), RCAR_GP_PIN(3, 29),
>> > +   RCAR_GP_PIN(4, 0), RCAR_GP_PIN(5, 22),
>> > +
>> > +   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 4),
>> > +   RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
>> > +   RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 9),
>> > +
>> > +   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
>> > +   RCAR_GP_PIN(5, 17), RCAR_GP_PIN(4, 1), RCAR_GP_PIN(3, 11),
>> > +   RCAR_GP_PIN(3, 13), RCAR_GP_PIN(5, 23), RCAR_GP_PIN(3, 12), };
>> > +static const unsigned int avb_gmii_mux[] = {
>> > +   AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
>> > +   AVB_TXD3_MARK, AVB_TXD4_MARK, AVB_TXD5_MARK,
>> > +   AVB_TXD6_MARK, AVB_TXD7_MARK,
>> > +
>> > +   AVB_RXD0_MARK, AVB_RXD1_MARK, AVB_RXD2_MARK,
>> > +   AVB_RXD3_MARK, AVB_RXD4_MARK, AVB_RXD5_MARK,
>> > +   AVB_RXD6_MARK, AVB_RXD7_MARK,
>> > +
>> > +   AVB_RX_ER_MARK, AVB_RX_CLK_MARK, AVB_RX_DV_MARK,
>> > +   AVB_CRS_MARK, AVB_GTX_CLK_MARK, AVB_GTXREFCLK_MARK,
>> > +   AVB_TX_EN_MARK, AVB_TX_ER_MARK, AVB_TX_CLK_MARK,
>>
>> You forgot AVB_COL, which is GP5_18?
>
> The same comment as above.

Likewise:

gmii_tx
gmii_rx
gmii_col_crs (optional, half duplex; should this be split?)

>> > +};
>>
>> Any specific reason you haven't added the 

Re: [PATCH/RFC net-next 1/5] ravb: fix inconsistent lock state at enabling tx timestamp

2018-04-17 Thread Geert Uytterhoeven
Hi Simon,

On Tue, Apr 17, 2018 at 10:50 AM, Simon Horman
 wrote:
> From: Masaru Nagai 
>
> [   58.490829] =
> [   58.495205] [ INFO: inconsistent lock state ]
> [   58.499583] 4.9.0-yocto-standard-7-g2ef7caf #57 Not tainted

Can this be triggered on contemporary kernels, too?

> [   58.505529] -
> [   58.509904] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.

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 v4] gpio: dwapb: Add support for 1 interrupt per port A GPIO

2018-04-17 Thread Rob Herring
On Tue, Apr 17, 2018 at 7:42 AM, Phil Edworthy
 wrote:
> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
>
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
>
> Signed-off-by: Phil Edworthy 
> ---
> One point to mention is that I have made it possible for users to have
> unconncted interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
>
> v4:
>  - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
> v3:
>  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect 
> problems
> v2:
>  - Replaced interrupt-mask DT prop with support for the interrupts-extended
>prop. This means replacing the call to irq_of_parse_and_map() with calls
>to of_irq_parse_one() and irq_create_of_mapping().
>
> Note: There are a few *code* lines over 80 chars, but this is just guidance,
>right? Especially as there are already some lines over 80 chars.
>
> snps:gpio fix
>
> Signed-off-by: Phil Edworthy 
> ---
>  .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 +++--
>  drivers/gpio/gpio-dwapb.c  | 42 
> +-
>  drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
>  include/linux/platform_data/gpio-dwapb.h   |  3 +-
>  4 files changed, 44 insertions(+), 13 deletions(-)

Reviewed-by: Rob Herring 


renesas-drivers-2018-04-17-v4.17-rc1

2018-04-17 Thread Geert Uytterhoeven
I have pushed renesas-drivers-2018-04-17-v4.17-rc1 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20180416-v4.17-rc1.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/rcar-gen2-wdt-v6
  - topic/bd9571-ddr-backup-mode-driver-v2
  - topic/bd9571-ddr-backup-mode-dt-v2
  - topic/r8a77990-soc-v1
  - topic/r8a77990-clk-v1
  - topic/r8a77990-dts-v1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-driver-v6
  - git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
  - git://linuxtv.org/pinchartl/media.git#tags/vsp1-discom-v1-20171215
  - git://linuxtv.org/pinchartl/media.git#tags/drm-next-colorkey-v1-20171215
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/tlb-optimise/v7
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#d3/i2c-conflict/drm
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/du/interlaced/v2

Included fixes:
  - [LOCAL] arm64: defconfig: Update renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next

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 v2 3/3] ARM: dts: Renesas RZ/N1D SMP enable method

2018-04-17 Thread Michel Pollet
Add a special enable method for the second CA7 of the Renesas RZ/N1D
(R9A06G032), as well as the default value for the "cpu-release-addr"
property.

Signed-off-by: Michel Pollet 
---
 arch/arm/boot/dts/r9a06g032.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 23c56d7..170376d 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -33,6 +33,8 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <1>;
+   enable-method = "renesas,r9a06g032-smp";
+   cpu-release-addr = <0x4000c204>;
};
};
 
-- 
2.7.4



[PATCH v2 1/3] dt-bindings: cpu: Add Renesas RZ/N1D SMP enable method.

2018-04-17 Thread Michel Pollet
Add a special enable method for second CA8 of the Renesas RZ/N1D
(R9A06G032).

Signed-off-by: Michel Pollet 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/cpus.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 29e1dc5..b395d107 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -219,6 +219,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
+   "renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
-- 
2.7.4



[PATCH v2 2/3] arm: shmobile: Add the RZ/N1D SMP enabler driver

2018-04-17 Thread Michel Pollet
The Renesas RZ/N1D second CA7 is parked in a ROM pen at boot time, it
requires a special enable method to get it started.

Signed-off-by: Michel Pollet 
---
 arch/arm/mach-shmobile/Makefile|  1 +
 arch/arm/mach-shmobile/smp-r9a06g032.c | 85 ++
 2 files changed, 86 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 1939f52..d7fc98f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o 
platsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
 smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
+smp-$(CONFIG_ARCH_R9A06G032)   += smp-r9a06g032.o
 smp-$(CONFIG_ARCH_EMEV2)   += smp-emev2.o headsmp-scu.o platsmp-scu.o
 
 # PM objects
diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c 
b/arch/arm/mach-shmobile/smp-r9a06g032.c
new file mode 100644
index 000..a536e89
--- /dev/null
+++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/N1D Second CA7 enabler.
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet , 
+ * Derived from action,s500-smp
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The second CPU is parked in ROM at boot time. It requires waking it after
+ * writing an address into the BOOTADDR register of sysctrl.
+ *
+ * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
+ *
+ * *However* the BOOTADDR register is not available when the kernel
+ * starts in NONSEC mode.
+ *
+ * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
+ * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
+ * which is not restricted.
+ */
+
+static void __iomem *cpu_bootaddr;
+
+static DEFINE_SPINLOCK(cpu_lock);
+
+static int rzn1_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+   if (!cpu_bootaddr)
+   return -ENODEV;
+
+   spin_lock(_lock);
+
+   writel(__pa_symbol(secondary_startup), cpu_bootaddr);
+   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+   spin_unlock(_lock);
+
+   return 0;
+}
+
+static void __init rzn1_smp_prepare_cpus(unsigned int max_cpus)
+{
+   struct device_node *dn;
+   int ret;
+   u32 bootaddr;
+
+   dn = of_get_cpu_node(1, NULL);
+   if (!dn) {
+   pr_err("CPU#1: missing device tree node\n");
+   return;
+   }
+   /*
+* Determine the address from which the CPU is polling.
+* The bootloader *does* change this property
+*/
+   ret = of_property_read_u32(dn, "cpu-release-addr", );
+   of_node_put(dn);
+   if (ret) {
+   pr_err("CPU#1: invalid cpu-release-addr property\n");
+   return;
+   }
+   pr_info("CPU#1: cpu-release-addr %08x\n", (u32)bootaddr);
+
+   cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
+   if (!cpu_bootaddr)
+   pr_err("CPU#1: cpu-release-addr map failed\n");
+}
+
+static const struct smp_operations rzn1_smp_ops __initconst = {
+   .smp_prepare_cpus = rzn1_smp_prepare_cpus,
+   .smp_boot_secondary = rzn1_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(rzn1_smp, "renesas,r9a06g032-smp", _smp_ops);
-- 
2.7.4



[PATCH v2 0/3] Renesas RZ/N1D SMP enabler

2018-04-17 Thread Michel Pollet
*WARNING -- this requires the base RZ/N1 base patches (v5) already posted

This patch series is for enabling the second CA7 of the RZ/N1D.
It's based on a spin_table method, and it reuses the same binding
property as that driver.

v2:
  + Added suggestions from Florian Fainelli
  + Use __pa_symbol()
  + Simplified logic in prepare_cpu()
  + Reordered the patches
  + Rebased on RZN1 Base patch v5

*** BLURB HERE ***

Michel Pollet (3):
  dt-bindings: cpu: Add Renesas RZ/N1D SMP enable method.
  arm: shmobile: Add the RZ/N1D SMP enabler driver
  ARM: dts: Renesas RZ/N1D SMP enable method

 Documentation/devicetree/bindings/arm/cpus.txt |  1 +
 arch/arm/boot/dts/r9a06g032.dtsi   |  2 +
 arch/arm/mach-shmobile/Makefile|  1 +
 arch/arm/mach-shmobile/smp-r9a06g032.c | 85 ++
 4 files changed, 89 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c

-- 
2.7.4



[PATCH v4] gpio: dwapb: Add support for 1 interrupt per port A GPIO

2018-04-17 Thread Phil Edworthy
The DesignWare GPIO IP can be configured for either 1 interrupt or 1
per GPIO in port A, but the driver currently only supports 1 interrupt.
See the DesignWare DW_apb_gpio Databook description of the
'GPIO_INTR_IO' parameter.

This change allows the driver to work with up to 32 interrupts, it will
get as many interrupts as specified in the DT 'interrupts' property.
It doesn't do anything clever with the different interrupts, it just calls
the same handler used for single interrupt hardware.

Signed-off-by: Phil Edworthy 
---
One point to mention is that I have made it possible for users to have
unconncted interrupts by specifying holes in the list of interrupts. This is
done by supporting the interrupts-extended DT prop.
However, I have no use for this and had to hack some test case for this.
Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?

v4:
 - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
v3:
 - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect problems
v2:
 - Replaced interrupt-mask DT prop with support for the interrupts-extended
   prop. This means replacing the call to irq_of_parse_and_map() with calls
   to of_irq_parse_one() and irq_create_of_mapping().

Note: There are a few *code* lines over 80 chars, but this is just guidance,
   right? Especially as there are already some lines over 80 chars.

snps:gpio fix

Signed-off-by: Phil Edworthy 
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 +++--
 drivers/gpio/gpio-dwapb.c  | 42 +-
 drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
 include/linux/platform_data/gpio-dwapb.h   |  3 +-
 4 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
index 4a75da7..3c1118b 100644
--- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -26,8 +26,13 @@ controller.
   the second encodes the triger flags encoded as described in
   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - interrupt-parent : The parent interrupt controller.
-- interrupts : The interrupt to the parent controller raised when GPIOs
-  generate the interrupts.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+  generate the interrupts. If the controller provides one combined interrupt
+  for all GPIOs, specify a single interrupt. If the controller provides one
+  interrupt for each GPIO, provide a list of interrupts that correspond to each
+  of the GPIO pins. When specifying multiple interrupts, if any are 
unconnected,
+  use the interrupts-extended property to specify the interrupts and set the
+  interrupt controller handle for unused interrupts to 0.
 - snps,nr-gpios : The number of pins in the port, a single cell.
 - resets : Reset line for the controller.
 
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 226977f..7a1022f 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -441,14 +441,19 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
irq_gc->chip_types[1].handler = handle_edge_irq;
 
if (!pp->irq_shared) {
-   irq_set_chained_handler_and_data(pp->irq, dwapb_irq_handler,
-gpio);
+   int i;
+
+   for (i = 0; i < pp->ngpio; i++) {
+   if (pp->irq[i])
+   irq_set_chained_handler_and_data(pp->irq[i],
+   dwapb_irq_handler, gpio);
+   }
} else {
/*
 * Request a shared IRQ since where MFD would have devices
 * using the same irq pin
 */
-   err = devm_request_irq(gpio->dev, pp->irq,
+   err = devm_request_irq(gpio->dev, pp->irq[0],
   dwapb_irq_handler_mfd,
   IRQF_SHARED, "gpio-dwapb-mfd", gpio);
if (err) {
@@ -524,7 +529,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
if (pp->idx == 0)
port->gc.set_config = dwapb_gpio_set_config;
 
-   if (pp->irq)
+   if (pp->has_irq)
dwapb_configure_irqs(gpio, port, pp);
 
err = gpiochip_add_data(>gc, port);
@@ -535,7 +540,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
port->is_registered = true;
 
/* Add GPIO-signaled ACPI event support */
-   if (pp->irq)
+   if (pp->has_irq)
acpi_gpiochip_request_interrupts(>gc);
 
return err;
@@ -601,13 +606,32 @@ dwapb_gpio_get_pdata(struct device *dev)
if (dev->of_node && pp->idx 

RE: [PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO

2018-04-17 Thread Phil Edworthy
Hi Rob,

On 16 April 2018 21:03 Rob Herring wrote:
> On Fri, Apr 13, 2018 at 09:51:12AM +0100, Phil Edworthy wrote:
> > The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> > per GPIO in port A, but the driver currently only supports 1 interrupt.
> > See the DesignWare DW_apb_gpio Databook description of the
> > 'GPIO_INTR_IO' parameter.
> >
> > This change allows the driver to work with up to 32 interrupts, it
> > will get as many interrupts as specified in the DT 'interrupts' property.
> > It doesn't do anything clever with the different interrupts, it just
> > calls the same handler used for single interrupt hardware.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> > One point to mention is that I have made it possible for users to have
> > unconncted interrupts by specifying holes in the list of interrupts.
> > This is done by supporting the interrupts-extended DT prop.
> > However, I have no use for this and had to hack some test case for this.
> > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
> >
> > v3:
> >  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid
> > bisect problems
> > v2:
> >  - Replaced interrupt-mask DT prop with support for the interrupts-
> extended
> >prop. This means replacing the call to irq_of_parse_and_map() with calls
> >to of_irq_parse_one() and irq_create_of_mapping().
> >
> > Note: There are a few *code* lines over 80 chars, but this is just guidance,
> >right? Especially as there are already some lines over 80 chars.
> > ---
[snip]

> > +   for (j = 0; j < pp->ngpio; j++) {
> > +   if (of_irq_parse_one(np, j, ))
> > +   continue;
> > +
> > +   pp->irq[j] = irq_create_of_mapping();
> 
> I'm hoping to not have new users of of_irq_parse_one and
> irq_create_of_mapping. Can you use of_irq_get instead? It will base back
> error codes so you can distinguish different conditions.
Sure, I hadn't noticed that particular variant!

Thanks
Phil

> > +   if (pp->irq[j])
> > +   pp->has_irq = true;
> > +   }
> > +
> > +   if (!pp->has_irq)
> > dev_warn(dev, "no irq for port%d\n", pp-
> >idx);
> > }
> >
> > -   if (has_acpi_companion(dev) && pp->idx == 0)
> > -   pp->irq =
> platform_get_irq(to_platform_device(dev), 0);
> > +   if (has_acpi_companion(dev) && pp->idx == 0) {
> > +   pp->irq[0] =
> platform_get_irq(to_platform_device(dev), 0);
> > +   if (pp->irq[0])
> > +   pp->has_irq = true;
> > +   }
> >
> > pp->irq_shared  = false;
> > pp->gpio_base   = -1;


Re: [PATCH v6 01/11] ARM: sunxi: smp: Move assembly code into a file

2018-04-17 Thread Chen-Yu Tsai
On Tue, Apr 17, 2018 at 7:17 PM, Maxime Ripard
 wrote:
> On Tue, Apr 17, 2018 at 11:12:41AM +0800, Chen-Yu Tsai wrote:
>> On Tue, Apr 17, 2018 at 5:50 AM, Mylène Josserand
>>  wrote:
>> > Move the assembly code for cluster cache enabling and resuming
>> > into an assembly file instead of having it directly in C code.
>> >
>> > Remove the CFLAGS because we are using the ARM directive "arch"
>> > instead.
>> >
>> > Signed-off-by: Mylène Josserand 
>> > ---
>> >  arch/arm/mach-sunxi/Makefile  |  4 +--
>> >  arch/arm/mach-sunxi/headsmp.S | 80 
>> > +
>> >  arch/arm/mach-sunxi/mc_smp.c  | 82 
>> > +++
>> >  3 files changed, 85 insertions(+), 81 deletions(-)
>> >  create mode 100644 arch/arm/mach-sunxi/headsmp.S
>>
>> I'm still not convinced about this whole "move ASM to separate
>> file" thing, especially now that you aren't actually adding any
>> sunxi-specific ASM code beyond a simple function call.
>>
>> Could you drop this for now?
>
> I'd really like to have this merged actually. There's a significant
> readibility improvement, so even if there's no particular functional
> improvement, I'd still call it a win.

What parts do you consider hard to read? The extra quotes? Trailing
newline? Or perhaps the __stringify bits?

ChenYu


Re: [PATCH v6 09/11] ARM: sun8i: smp: Add support for A83T

2018-04-17 Thread Maxime Ripard
On Mon, Apr 16, 2018 at 11:50:30PM +0200, Mylène Josserand wrote:
> @@ -535,8 +599,12 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu)
>   return !ret;
>  }
>  
> -static bool sunxi_mc_smp_cpu_can_disable(unsigned int __unused)
> +static bool sunxi_mc_smp_cpu_can_disable(unsigned int cpu)
>  {
> + /* CPU0 hotplug not handled for sun8i-a83t */
> + if (is_sun8i)
> + if (cpu == 0)
> + return false;
>   return true;

I think Chen-Yu told you how to implement the hotplug in the previous
iteration, did you have time to test it?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v6 08/11] ARM: sun9i: smp: Add is_sun8i field

2018-04-17 Thread Maxime Ripard
On Tue, Apr 17, 2018 at 03:57:07PM +0800, Chen-Yu Tsai wrote:
> >> @@ -697,6 +700,8 @@ static int __init sunxi_mc_smp_init(void)
> >>   break;
> >>   }
> >>
> >> + is_sun8i = sunxi_mc_smp_data[i].is_sun8i;
> >> +
> >
> > Do we really need to cache it? Can't we just have a pointer to the SMP
> > data structure and use that instead?
> 
> I recommended that. We don't need any of the other fields in the SMP
> data structure once we're past the init phase. This saves a dereference
> or two.

Fair enough.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v6 01/11] ARM: sunxi: smp: Move assembly code into a file

2018-04-17 Thread Maxime Ripard
On Tue, Apr 17, 2018 at 11:12:41AM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 17, 2018 at 5:50 AM, Mylène Josserand
>  wrote:
> > Move the assembly code for cluster cache enabling and resuming
> > into an assembly file instead of having it directly in C code.
> >
> > Remove the CFLAGS because we are using the ARM directive "arch"
> > instead.
> >
> > Signed-off-by: Mylène Josserand 
> > ---
> >  arch/arm/mach-sunxi/Makefile  |  4 +--
> >  arch/arm/mach-sunxi/headsmp.S | 80 
> > +
> >  arch/arm/mach-sunxi/mc_smp.c  | 82 
> > +++
> >  3 files changed, 85 insertions(+), 81 deletions(-)
> >  create mode 100644 arch/arm/mach-sunxi/headsmp.S
> 
> I'm still not convinced about this whole "move ASM to separate
> file" thing, especially now that you aren't actually adding any
> sunxi-specific ASM code beyond a simple function call.
> 
> Could you drop this for now?

I'd really like to have this merged actually. There's a significant
readibility improvement, so even if there's no particular functional
improvement, I'd still call it a win.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


[PATCH v5 0/8] arm: Base support for Renesas RZN1D-DB Board

2018-04-17 Thread Michel Pollet
This series adds the plain basic support for booting a bare
kernel on the RZ/N1D-DB Board. It's been trimmed to the strict
minimum as a 'base', further patches that will add the
rest of the support, pinctrl, clock architecture and quite
a few others.

Thanks for the comments on the previous versions!

v5:
 + Given the problems I have with getting in some structure around the 
   sysctrl block, I've removed the MFD, I've now attached a simple reboot 
   driver on it's own pair of registers.
 + Rebased on next-20180417
v4:
 + Fixes for suggestions by Simon Horman
 + Fixes for suggestions by Jacopo Mondi
 + Fixes for suggestions by Geert Uytterhoeven
 + Renamed the r9a06g0xx.dtsi file, given up on trying to get a family
   common file in, so dropped potential RZ/N1S support and now only
   focus on RZ/N1D for this patchset.
 + Added 'always-on' to the architected timer node, because it is.
 + Added ARCH_R9A06G032, to match others patterns like RCAR
 + Sorted the .dts files, added empty lines as required.
 + Fixed patch prefixes to match git-log for bindings
 + Merged board .dts & Makefile changes together
 + Rebased on next-20180410
v3:
 + Fixes for suggestions by Geert Uytterhoeven
 + Removed SoC Specific renesas,r9a06g032-xxx, as it's not needed for now.
 + Kept renesas,rzn1 as a family/generic for this family.
 + Fixed a couple of the commit messages.
 + Added Geert's Reviewed-By where appropriate.
v2:
 + Fixes for suggestions by Simon Horman
 + Fixes for suggestions by Rob Herring
 + Fixes for suggestions by Geert Uytterhoeven
 + Removed the mach file
 + Added a MFD base for the sysctrl block
 + Added a regmap based sub driver for the reboot handler
 + Renamed the files to match shmobile conventions
 + Adapted the compatible= strings to reflect 'family' vs 'part'
   distinction.
 + Removed the sysctrl.h file entirelly.
 + Fixed every warnings from the DTC compiler on W=12 mode.
 + Split the device-tree patches from the code.

Michel Pollet (6):
  arm: shmobile: Add the RZ/N1D (R9A06G032) to the shmobile Kconfig
  dt-bindings: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver
  dt-bindings: arm: Document the RZN1D-DB board
  ARM: dts: Renesas RZ/N1 SoC base device tree file
  ARM: dts: Renesas RZN1D-DB Board base file
  reset: Renesas RZ/N1 reboot driver

 Documentation/devicetree/bindings/arm/shmobile.txt |  5 +-
 .../bindings/power/renesas,rzn1-reboot.txt | 17 
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts| 29 +++
 arch/arm/boot/dts/r9a06g032.dtsi   | 89 
 arch/arm/mach-shmobile/Kconfig |  4 +
 drivers/power/reset/Kconfig|  7 ++
 drivers/power/reset/Makefile   |  1 +
 drivers/power/reset/rzn1-reboot.c  | 96 ++
 9 files changed, 248 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
 create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
 create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi
 create mode 100644 drivers/power/reset/rzn1-reboot.c

-- 
2.7.4



[PATCH v5 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file

2018-04-17 Thread Michel Pollet
This adds the Renesas RZ/N1D (Part #R9A06G032) SoC bare
bone support.

This currently only handles generic parts (gic, architected timer)
and a UART.
For simplicity sake, this also relies on the bootloader to set the
pinctrl and clocks.

Signed-off-by: Michel Pollet 
---
 arch/arm/boot/dts/r9a06g032.dtsi | 89 
 1 file changed, 89 insertions(+)
 create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
new file mode 100644
index 000..23c56d7
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+#include 
+
+/ {
+   compatible = "renesas,r9a06g032", "renesas,rzn1";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   clkuarts: clkuarts {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <47619047>;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <1>;
+   };
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <>;
+   ranges;
+
+   reboot@4000c120 {
+   compatible = "renesas,r9a06g032-reboot",
+   "renesas,rzn1-reboot";
+   reg = <0x4000c120 4>,
+   <0x4000c198 4>;
+   };
+
+   uart0: serial@4006 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x4006 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = <>;
+   clock-names = "baudclk";
+   status = "disabled";
+   };
+
+   gic: gic@44101000 {
+   compatible = "arm,cortex-a7-gic", "arm,gic-400";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0x44101000 0x1000>, /* Distributer */
+ <0x44102000 0x2000>, /* CPU interface */
+ <0x44104000 0x2000>, /* Virt interface control */
+ <0x44106000 0x2000>; /* Virt CPU interface */
+   interrupts =
+   ;
+   };
+   };
+
+   timer {
+   compatible = "arm,cortex-a7-timer",
+"arm,armv7-timer";
+   interrupt-parent = <>;
+   arm,cpu-registers-not-fw-configured;
+   always-on;
+   interrupts =
+   ,
+   ,
+   ,
+   ;
+   };
+};
-- 
2.7.4



[PATCH v5 2/6] dt-bindings: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver

2018-04-17 Thread Michel Pollet
The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
as part of the sysctrl MFD to handle rebooting the CA7 cores.
This documents the driver bindings.

Signed-off-by: Michel Pollet 
---
 .../devicetree/bindings/power/renesas,rzn1-reboot.txt   | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt

diff --git a/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt 
b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
new file mode 100644
index 000..a553864
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
@@ -0,0 +1,17 @@
+DT bindings for the Renesas RZ/N1 Reboot Driver
+
+== Reboot Driver Node ==
+
+The reboot driver allows restarting the RZ/N1.
+
+Bindings:
++ Required:
+   compatible = "renesas,r9a06g032-reboot", "renesas,rzn1-reboot";
+
+Example:
+   reboot@4000c120 {
+   compatible = "renesas,r9a06g032-reboot",
+   "renesas,rzn1-reboot";
+   reg = <0x4000c120 4>,
+   <0x4000c198 4>;
+   };
-- 
2.7.4



[PATCH v5 5/6] ARM: dts: Renesas RZN1D-DB Board base file

2018-04-17 Thread Michel Pollet
This adds a base device tree file for the RZN1-DB board, with only the
basic support allowing the system to boot to a prompt. Only one UART is
used, with only a single CPU running.

Signed-off-by: Michel Pollet 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 29 +
 2 files changed, 30 insertions(+)
 create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 052aaf0..a53a677 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -809,6 +809,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
+   r9a06g032-rzn1d400-db.dtb \
sh73a0-kzm9g.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
diff --git a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts 
b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
new file mode 100644
index 000..5fc2c40
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the RZN1D-DB Board
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+/dts-v1/;
+
+#include "r9a06g032.dtsi"
+
+/ {
+   model = "RZN1D-DB Board";
+   compatible = "renesas,rzn1d400-db",
+   "renesas,r9a06g032", "renesas,rzn1";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = 
+   };
+};
+
+ {
+   status = "okay";
+};
-- 
2.7.4



[PATCH v5 1/6] arm: shmobile: Add the RZ/N1D (R9A06G032) to the shmobile Kconfig

2018-04-17 Thread Michel Pollet
Add the RZ/N1D SoC to the reset of the Renesas SoC Collection.

Signed-off-by: Michel Pollet 
---
 arch/arm/mach-shmobile/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 96672da..fcc273f 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -114,6 +114,10 @@ config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
 
+config ARCH_R9A06G032
+   bool "RZ/N1D (R9A06G032)"
+   select ARCH_RZN1
+
 config ARCH_RZN1
bool "RZ/N1 (R9A06G0xx) Family"
select ARM_AMBA
-- 
2.7.4



[PATCH v5 6/6] reset: Renesas RZ/N1 reboot driver

2018-04-17 Thread Michel Pollet
The Renesas RZ/N1 Family (Part #R9A06G0xx) needs a small driver
to reboot the Cortex-A7 cores. This driver is a sub driver of
the sysctrl MFD.

Signed-off-by: Michel Pollet 
---
 drivers/power/reset/Kconfig   |  7 +++
 drivers/power/reset/Makefile  |  1 +
 drivers/power/reset/rzn1-reboot.c | 96 +++
 3 files changed, 104 insertions(+)
 create mode 100644 drivers/power/reset/rzn1-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index df58fc8..1416d88 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -144,6 +144,13 @@ config POWER_RESET_RESTART
  Instead they restart, and u-boot holds the SoC until the
  user presses a key. u-boot then boots into Linux.
 
+config POWER_RESET_RZN1
+   bool "Renesas RZ/N1 reboot driver"
+   depends on ARCH_RZN1
+   help
+ This driver allows rebooting the CA7 cores of the
+ Renesas RZ/N1 Family of SoC (Part # R9A06G0xx).
+
 config POWER_RESET_ST
bool "ST restart driver"
depends on ARCH_STI
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 7778c74..bad9702 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
 obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
 obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
 obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
+obj-$(CONFIG_POWER_RESET_RZN1) += rzn1-reboot.o
 obj-$(CONFIG_POWER_RESET_ST) += st-poweroff.o
 obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
 obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
diff --git a/drivers/power/reset/rzn1-reboot.c 
b/drivers/power/reset/rzn1-reboot.c
new file mode 100644
index 000..43876d5
--- /dev/null
+++ b/drivers/power/reset/rzn1-reboot.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/N1 reboot driver
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet , 
+ * Derived from zx-reboot.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Definitions from the SDK rzn1-sysctrl.h autogenerated file */
+#define RZN1_SYSCTRL_REG_RSTEN_MRESET_EN   0
+#define RZN1_SYSCTRL_REG_RSTEN_WDA7RST_EN  1
+#define RZN1_SYSCTRL_REG_RSTEN_WDA7RST_EN_MASK 0x6
+#define RZN1_SYSCTRL_REG_RSTEN_WDM3RST_EN  3
+#define RZN1_SYSCTRL_REG_RSTEN_CM3LOCKUPRST_EN 4
+#define RZN1_SYSCTRL_REG_RSTEN_CM3SYSRESET_EN  5
+#define RZN1_SYSCTRL_REG_RSTEN_SWRST_EN6
+#define RZN1_SYSCTRL_REG_RSTCTRL_WDA7RST_REQ   1
+#define RZN1_SYSCTRL_REG_RSTCTRL_WDA7RST_REQ_MASK  0x6
+#define RZN1_SYSCTRL_REG_RSTCTRL_WDM3RST_REQ   3
+#define RZN1_SYSCTRL_REG_RSTCTRL_CM3LOCKUPRST_REQ  4
+#define RZN1_SYSCTRL_REG_RSTCTRL_CM3SYSRESET_REQ   5
+#define RZN1_SYSCTRL_REG_RSTCTRL_SWRST_REQ 6
+
+static void __iomem *reg_rsten, *reg_rstctrl;
+
+static int rzn1_reboot_handler(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   writel(readl(reg_rsten) |
+   BIT(RZN1_SYSCTRL_REG_RSTEN_SWRST_EN) |
+   BIT(RZN1_SYSCTRL_REG_RSTEN_MRESET_EN),
+   reg_rsten);
+   writel(readl(reg_rstctrl) |
+   BIT(RZN1_SYSCTRL_REG_RSTCTRL_SWRST_REQ),
+   reg_rstctrl);
+
+   mdelay(50);
+   pr_emerg("Unable to restart system\n");
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block rzn1_reboot_nb = {
+   .notifier_call = rzn1_reboot_handler,
+   .priority = 128,
+};
+
+static int rzn1_reboot_probe(struct platform_device *ofdev)
+{
+   int err;
+
+   reg_rsten = of_iomap(ofdev->dev.of_node, 0);
+   reg_rstctrl = of_iomap(ofdev->dev.of_node, 1);
+
+   if (!reg_rsten || !reg_rstctrl) {
+   dev_err(>dev, "invalid register mapping\n");
+   return -ENODEV;
+   }
+
+   err = register_restart_handler(_reboot_nb);
+   if (err) {
+   dev_err(>dev, "register restart handler 
failed(err=%d)\n",
+   err);
+   }
+
+   return err;
+}
+
+static const struct of_device_id rzn1_reboot_of_match[] = {
+   { .compatible = "renesas,rzn1-reboot" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, rzn1_reboot_of_match);
+
+static struct platform_driver rzn1_reboot_driver = {
+   .probe = rzn1_reboot_probe,
+   .driver = {
+   .name = "rzn1-reboot",
+   .of_match_table = rzn1_reboot_of_match,
+   },
+};
+module_platform_driver(rzn1_reboot_driver);
+
+MODULE_DESCRIPTION("RZ/N1 reboot driver");
+MODULE_AUTHOR("Michel Pollet , 
");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4


[PATCH v5 3/6] dt-bindings: arm: Document the RZN1D-DB board

2018-04-17 Thread Michel Pollet
This documents the RZ/N1 bindings for the RZN1D-DB board.

Signed-off-by: Michel Pollet 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 61b486f..6efb3f1 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -51,7 +51,8 @@ SoCs:
 compatible = "renesas,r8a77990"
   - R-Car D3 (R8A77995)
 compatible = "renesas,r8a77995"
-
+  - RZ/N1D (R9A06G032)
+compatible = "renesas,r9a06g032", "renesas,rzn1"
 
 Boards:
 
@@ -112,6 +113,8 @@ Boards:
 compatible = "renesas,porter", "renesas,r8a7791"
   - RSKRZA1 (YR0K77210C000BE)
 compatible = "renesas,rskrza1", "renesas,r7s72100"
+  - RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package)
+compatible = "renesas,rzn1d400-db", "renesas,r9a06g032", "renesas,rzn1"
   - Salvator-X (RTP0RC7795SIPB0010S)
 compatible = "renesas,salvator-x", "renesas,r8a7795"
   - Salvator-X (RTP0RC7796SIPB0011S)
-- 
2.7.4



Re: [PATCH v6 01/11] ARM: sunxi: smp: Move assembly code into a file

2018-04-17 Thread kbuild test robot
Hi Mylène,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on arm-soc/for-next]
[also build test ERROR on v4.17-rc1 next-20180417]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/Sunxi-Add-SMP-support-on-A83T/20180417-113911
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   In file included from arch/arm/include/asm/cputype.h:6:0,
from arch/arm/mach-sunxi/headsmp.S:15:
>> include/linux/kernel.h:57:0: warning: "ALIGN" redefined
#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))

   In file included from arch/arm/mach-sunxi/headsmp.S:13:0:
   include/linux/linkage.h:79:0: note: this is the location of the previous 
definition
#define ALIGN __ALIGN

   /usr/lib/gcc-cross/arm-linux-gnueabi/7/include/stdarg.h: Assembler messages:
>> /usr/lib/gcc-cross/arm-linux-gnueabi/7/include/stdarg.h:40: Error: bad 
>> instruction `typedef __builtin_va_list __gnuc_va_list'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/7/include/stdarg.h:99: Error: bad 
>> instruction `typedef __gnuc_va_list va_list'
>> include/linux/stddef.h:10: Error: bad instruction `enum {'
>> include/linux/stddef.h:11: Error: junk at end of line, first unrecognized 
>> character is `,'
   include/linux/stddef.h:13: Error: junk at end of line, first unrecognized 
character is `}'
>> include/linux/bitops.h:29: Error: bad instruction `extern unsigned int 
>> __sw_hweight8(unsigned int w)'
>> include/linux/bitops.h:30: Error: bad instruction `extern unsigned int 
>> __sw_hweight16(unsigned int w)'
>> include/linux/bitops.h:31: Error: bad instruction `extern unsigned int 
>> __sw_hweight32(unsigned int w)'
>> include/linux/bitops.h:32: Error: bad instruction `extern unsigned long 
>> __sw_hweight64(__u64 w)'
>> arch/arm/include/asm/irqflags.h:25: Error: bad instruction `static inline 
>> unsigned long arch_local_irq_save(void)'
>> arch/arm/include/asm/irqflags.h:26: Error: junk at end of line, first 
>> unrecognized character is `{'
>> arch/arm/include/asm/irqflags.h:27: Error: bad instruction `unsigned long 
>> flags'
>> arch/arm/include/asm/irqflags.h:29: Error: bad instruction `asm volatile('
   arch/arm/include/asm/irqflags.h:30: Error: bad instruction ` mrs %0, 
""cpsr""@ arch_local_irq_save\n"'
>> arch/arm/include/asm/irqflags.h:31: Error: bad instruction ` cpsid   i"'
>> arch/arm/include/asm/irqflags.h:32: Error: junk at end of line, first 
>> unrecognized character is `:'
>> arch/arm/include/asm/irqflags.h:33: Error: bad instruction `return flags'
   arch/arm/include/asm/irqflags.h:34: Error: junk at end of line, first 
unrecognized character is `}'
>> arch/arm/include/asm/irqflags.h:37: Error: bad instruction `static inline 
>> void arch_local_irq_enable(void)'
   arch/arm/include/asm/irqflags.h:38: Error: junk at end of line, first 
unrecognized character is `{'
   arch/arm/include/asm/irqflags.h:39: Error: bad instruction `asm volatile('
>> arch/arm/include/asm/irqflags.h:40: Error: bad instruction ` cpsie i 
>> @ arch_local_irq_enable"'
   arch/arm/include/asm/irqflags.h:41: Error: junk at end of line, first 
unrecognized character is `:'
   arch/arm/include/asm/irqflags.h:42: Error: junk at end of line, first 
unrecognized character is `:'
   arch/arm/include/asm/irqflags.h:43: Error: junk at end of line, first 
unrecognized character is `:'
   arch/arm/include/asm/irqflags.h:44: Error: junk at end of line, first 
unrecognized character is `}'
>> arch/arm/include/asm/irqflags.h:47: Error: bad instruction `static inline 
>> void arch_local_irq_disable(void)'
   arch/arm/include/asm/irqflags.h:48: Error: junk at end of line, first 
unrecognized character is `{'
   arch/arm/include/asm/irqflags.h:49: Error: bad instruction `asm volatile('
>> arch/arm/include/asm/irqflags.h:50: Error: bad instruction ` cpsid i 
>> @ arch_local_irq_disable"'
   arch/arm/include/asm/irqflags.h:51: Error: junk at end of line, first 
unrecognized character is `:'
   arch/arm/include/asm/irqflags.h:52: Error: junk at end of line, first 
unrecognized character is `:'
   arch/arm/include/asm/irqflags.h:53: Error: junk at end of line, first 
unrecognized character is `:'
   arch/arm

Re: [PATCH/RFC net-next 4/5] ravb: remove undocumented processing

2018-04-17 Thread Wolfram Sang
On Tue, Apr 17, 2018 at 10:50:29AM +0200, Simon Horman wrote:
> From: Kazuya Mizuguchi 
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Simon Horman 
> ---
>  drivers/net/ethernet/renesas/ravb.h  |  5 -
>  drivers/net/ethernet/renesas/ravb_main.c | 15 ---
>  2 files changed, 20 deletions(-)
> 
> diff --git a/drivers/net/ethernet/renesas/ravb.h 
> b/drivers/net/ethernet/renesas/ravb.h
> index 57eea4a77826..fcd04dbc7dde 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
> @@ -197,15 +197,11 @@ enum ravb_reg {
>   MAHR= 0x05c0,
>   MALR= 0x05c8,
>   TROCR   = 0x0700,   /* Undocumented? */

Why not this, too? Maybe some background info from HW team for the
commit message would be nice to have...



signature.asc
Description: PGP signature


Re: [PATCH/RFC net-next 1/5] ravb: fix inconsistent lock state at enabling tx timestamp

2018-04-17 Thread Wolfram Sang
On Tue, Apr 17, 2018 at 10:50:26AM +0200, Simon Horman wrote:
> From: Masaru Nagai 
> 
> [   58.490829] =
> [   58.495205] [ INFO: inconsistent lock state ]
> [   58.499583] 4.9.0-yocto-standard-7-g2ef7caf #57 Not tainted
> [   58.505529] -
> [   58.509904] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [   58.515939] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:
> [   58.521099]  (&(>lock)->rlock#2){?.-...}, at: [] 
> skb_queue_tail+0x2c/0x68
> {HARDIRQ-ON-W} state was registered at:

Maybe add a short text to the log to describe the approach of this fix?



signature.asc
Description: PGP signature


Re: [PATCH/RFC net-next 2/5] ravb: correct ptp does failure after suspend and resume

2018-04-17 Thread Wolfram Sang

> @@ -2302,6 +2305,7 @@ static int __maybe_unused ravb_resume(struct device 
> *dev)
>  {
>   struct net_device *ndev = dev_get_drvdata(dev);
>   struct ravb_private *priv = netdev_priv(ndev);
> + struct platform_device *pdev = priv->pdev;

Minor nit: I'd save this line...

> + if (priv->chip_id != RCAR_GEN2)
> + ravb_ptp_init(ndev, pdev);

... and use ravb_ptp_init(ndev, priv->pdev); here.

But well, maybe just bike-shedding...



signature.asc
Description: PGP signature


RE: [RFC 3/3] arm: shmobile: Add the RZ/N1D SMP enabler driver.

2018-04-17 Thread Michel Pollet
Hi Florian,

On 16 April 2018 22:46, Florian Fainelli:
> Hi Michel,
>
> On 04/16/2018 02:34 AM, Michel Pollet wrote:
> > The Renesas RZ/N1D second CA7 is parked in a ROM pen at boot time, it
> > requires a special enable method to get it started at boot time.
> >
> > Signed-off-by: Michel Pollet 
>
> Some few comments below. This patch should probably be re-ordered in
> your patch series, I would expect you to have this become patch 2 and have
> patch 2 be patch 3 (first you add infrastructure for using something, then you
> make use of it).

Thanks, took that onboard for v2

>
> > +static int rzn1_smp_boot_secondary(unsigned int cpu, struct
> > +task_struct *idle) {
> > +if (!cpu_bootaddr)
> > +return -ENODEV;
> > +
> > +spin_lock(_lock);
> > +
> > +writel(virt_to_phys(secondary_startup), cpu_bootaddr);
>
> Consider using __pa_symbol() instead of virt_to_phys() since
> secondary_startup is part of the kernel's linear memory map.

Agreed.

>
> > +arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> > +
> > +spin_unlock(_lock);
> > +
> > +return 0;
> > +}
> > +
> > +static void __init rzn1_smp_prepare_cpus(unsigned int max_cpus) {
> > +struct device_node *dn;
> > +int ret;
> > +u32 bootaddr;
> > +
> > +dn = of_get_cpu_node(1, NULL);
> > +if (!dn) {
> > +pr_err("CPU#1: missing device tree node\n");
> > +return;
> > +}
> > +/*
> > + * Determine the address from which the CPU is polling.
> > + */
> > +ret = of_property_read_u32(dn, "cpu-release-addr", );
> > +if (ret)
> > +pr_err("CPU#1: invalid cpu-release-addr property\n");
> > +
> > +of_node_put(dn);
> > +/* The bootloader *does* change this property */
>
> This comment should probably be moved above the function that fetches
> "cpu-release-addr"

Thanks, I've simplified that bit too..
>
> > +pr_info("CPU#1: cpu-release-addr %08x\n", (u32)bootaddr);
> > +
> > +if (!bootaddr)
> > +return;
>
> Would not you want to show a message here to help catch such conditions
>
> > +
> > +cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
>
> Relying on ioremap() to reject values that might be outside of the allowed
> range may be a little fragile, but I can't suggest any better alternative.

It's difficult, I'd have to add a memory map header I've been trying not to
use so far for KISS reason...

>
> > +if (!cpu_bootaddr)
> > +pr_err("CPU#1: cpu-release-addr map failed\n"); }
> > +
> > +static const struct smp_operations rzn1_smp_ops __initconst = {
> > +.smp_prepare_cpus = rzn1_smp_prepare_cpus,
> > +.smp_boot_secondary = rzn1_smp_boot_secondary, };
> > +CPU_METHOD_OF_DECLARE(rzn1_smp, "renesas,r9a06g032-smp",
> > +_smp_ops);
> >
>

Michel




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.


RE: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support

2018-04-17 Thread Biju Das
Hi Geert,

Thanks  for the comment.

> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
> Hi Biju,
>
> On Wed, Apr 4, 2018 at 5:22 PM, Biju Das  wrote:
> > Add PFC support for the R8A77470 SoC including pin groups for some
> > on-chip devices such as SCIF, AVB and MMC.
> >
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
> > @@ -0,0 +1,2156 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * R8A77470 processor support - PFC hardware block.
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Corp.
> > + */
> > +
> > +#include 
> > +
> > +#include "sh_pfc.h"
> > +
> > +#define CPU_ALL_PORT(fn, sfx)  \
> > +   PORT_GP_23(0, fn, sfx), \
> > +   PORT_GP_23(1, fn, sfx), \
> > +   PORT_GP_32(2, fn, sfx), \
> > +   PORT_GP_17(3, fn, sfx), \
> > +   PORT_GP_1(3, 27, fn, sfx),  \
> > +   PORT_GP_1(3, 28, fn, sfx),  \
> > +   PORT_GP_1(3, 29, fn, sfx),  \
>
> (Oh, they have a hole in the GPIO range...)
Yes it is correct. There is a hole between GP3-16 to GP3-27.
>
> > +   PORT_GP_26(4, fn, sfx), \
> > +   PORT_GP_32(5, fn, sfx)
>
> > +/* - AVB
> > + */ 
> > static const
> unsigned int avb_link_pins[] = {
> > +   RCAR_GP_PIN(5, 14),
> > +};
> > +static const unsigned int avb_link_mux[] = {
> > +   AVB_LINK_MARK,
> > +};
> > +static const unsigned int avb_magic_pins[] = {
> > +   RCAR_GP_PIN(5, 15),
> > +};
> > +static const unsigned int avb_magic_mux[] = {
> > +   AVB_MAGIC_MARK,
> > +};
> > +static const unsigned int avb_phy_int_pins[] = {
> > +   RCAR_GP_PIN(5, 16),
> > +};
> > +static const unsigned int avb_phy_int_mux[] = {
> > +   AVB_PHY_INT_MARK,
> > +};
> > +static const unsigned int avb_mdio_pins[] = {
> > +   RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 13), }; static const
> > +unsigned int avb_mdio_mux[] = {
> > +   AVB_MDC_MARK, AVB_MDIO_MARK,
> > +};
> > +static const unsigned int avb_mii_pins[] = {
> > +   RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15), RCAR_GP_PIN(3, 16),
> > +   RCAR_GP_PIN(3, 27),
> > +
> > +   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 4),
> > +   RCAR_GP_PIN(3, 5),
> > +
> > +   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
> > +   RCAR_GP_PIN(5, 17), RCAR_GP_PIN(3, 13), RCAR_GP_PIN(5, 23),
> > +   RCAR_GP_PIN(3, 12),
> > +};
> > +static const unsigned int avb_mii_mux[] = {
> > +   AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
> > +   AVB_TXD3_MARK,
> > +
> > +   AVB_RXD0_MARK, AVB_RXD1_MARK, AVB_RXD2_MARK,
> > +   AVB_RXD3_MARK,
> > +
> > +   AVB_RX_ER_MARK, AVB_RX_CLK_MARK, AVB_RX_DV_MARK,
> > +   AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_ER_MARK,
> > +   AVB_TX_CLK_MARK,
>
> You forgot AVB_COL, which is GP5_18?

GP5_18 is shred between the signals AVB_COL and VI0_CLK. As per the RZ/G1C 
board schematic /hardware user guide
Ethernet Phy collision pin(AVB_COL) pin  is not populated on this board by 
default. It is populated only for
Video Input Channel0 pixel clock.

Since it is initial submission, I thought of adding only board specific pins 
first and later
add this collision pin alone as a separate pin entry  in the avb group. That 
way we can support existing board
as well as any future RZ/G1C board which populates this pin. Are you ok for 
this approach?

> > +};
> > +static const unsigned int avb_gmii_pins[] = {
> > +   RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15), RCAR_GP_PIN(3, 16),
> > +   RCAR_GP_PIN(3, 27), RCAR_GP_PIN(3, 28), RCAR_GP_PIN(3, 29),
> > +   RCAR_GP_PIN(4, 0), RCAR_GP_PIN(5, 22),
> > +
> > +   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 4),
> > +   RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> > +   RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 9),
> > +
> > +   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
> > +   RCAR_GP_PIN(5, 17), RCAR_GP_PIN(4, 1), RCAR_GP_PIN(3, 11),
> > +   RCAR_GP_PIN(3, 13), RCAR_GP_PIN(5, 23), RCAR_GP_PIN(3, 12), };
> > +static const unsigned int avb_gmii_mux[] = {
> > +   AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
> > +   AVB_TXD3_MARK, AVB_TXD4_MARK, AVB_TXD5_MARK,
> > +   AVB_TXD6_MARK, AVB_TXD7_MARK,
> > +
> > +   AVB_RXD0_MARK, AVB_RXD1_MARK, AVB_RXD2_MARK,
> > +   AVB_RXD3_MARK, AVB_RXD4_MARK, AVB_RXD5_MARK,
> > +   AVB_RXD6_MARK, AVB_RXD7_MARK,
> > +
> > +   AVB_RX_ER_MARK, AVB_RX_CLK_MARK, 

[PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits

2018-04-17 Thread Simon Horman
From: Kazuya Mizuguchi 

This patch corrects writing 1 to reserved bits.
The write value should be 0.

Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Simon Horman 
---
 drivers/net/ethernet/renesas/ravb.h  | 12 
 drivers/net/ethernet/renesas/ravb_main.c |  9 +
 drivers/net/ethernet/renesas/ravb_ptp.c  |  2 +-
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index b81f4faf7b10..57eea4a77826 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -433,6 +433,8 @@ enum EIS_BIT {
EIS_QFS = 0x0001,
 };
 
+#define EIS_RESERVED_BITS  (u32)(GENMASK(31, 17) | GENMASK(15, 11))
+
 /* RIC0 */
 enum RIC0_BIT {
RIC0_FRE0   = 0x0001,
@@ -477,6 +479,8 @@ enum RIS0_BIT {
RIS0_FRF17  = 0x0002,
 };
 
+#define RIS0_RESERVED_BITS (u32)GENMASK(31, 18)
+
 /* RIC1 */
 enum RIC1_BIT {
RIC1_RFWE   = 0x8000,
@@ -533,6 +537,8 @@ enum RIS2_BIT {
RIS2_RFFF   = 0x8000,
 };
 
+#define RIS2_RESERVED_BITS (u32)GENMASK_ULL(30, 18)
+
 /* TIC */
 enum TIC_BIT {
TIC_FTE0= 0x0001,   /* Undocumented? */
@@ -549,6 +555,10 @@ enum TIS_BIT {
TIS_TFWF= 0x0200,
 };
 
+#define TIS_RESERVED_BITS  (u32)(GENMASK_ULL(31, 20) | \
+ GENMASK_ULL(15, 12) | \
+ GENMASK_ULL(7, 4))
+
 /* ISS */
 enum ISS_BIT {
ISS_FRS = 0x0001,   /* Undocumented? */
@@ -622,6 +632,8 @@ enum GIS_BIT {
GIS_PTMF= 0x0004,
 };
 
+#define GIS_RESERVED_BITS  (u32)GENMASK(15, 10)
+
 /* GIE (R-Car Gen3 only) */
 enum GIE_BIT {
GIE_PTCS= 0x0001,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index dbde3d11458b..736ca2f76a35 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -742,10 +742,11 @@ static void ravb_error_interrupt(struct net_device *ndev)
u32 eis, ris2;
 
eis = ravb_read(ndev, EIS);
-   ravb_write(ndev, ~EIS_QFS, EIS);
+   ravb_write(ndev, ~(EIS_QFS | EIS_RESERVED_BITS), EIS);
if (eis & EIS_QFS) {
ris2 = ravb_read(ndev, RIS2);
-   ravb_write(ndev, ~(RIS2_QFF0 | RIS2_RFFF), RIS2);
+   ravb_write(ndev, ~(RIS2_QFF0 | RIS2_RFFF | RIS2_RESERVED_BITS),
+  RIS2);
 
/* Receive Descriptor Empty int */
if (ris2 & RIS2_QFF0)
@@ -913,7 +914,7 @@ static int ravb_poll(struct napi_struct *napi, int budget)
/* Processing RX Descriptor Ring */
if (ris0 & mask) {
/* Clear RX interrupt */
-   ravb_write(ndev, ~mask, RIS0);
+   ravb_write(ndev, ~(mask | RIS0_RESERVED_BITS), RIS0);
if (ravb_rx(ndev, , q))
goto out;
}
@@ -925,7 +926,7 @@ static int ravb_poll(struct napi_struct *napi, int budget)
 
spin_lock_irqsave(>lock, flags);
/* Clear TX interrupt */
-   ravb_write(ndev, ~mask, TIS);
+   ravb_write(ndev, ~(mask | TIS_RESERVED_BITS), TIS);
ravb_tx_free(ndev, q, true);
netif_wake_subqueue(ndev, q);
mmiowb();
diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c 
b/drivers/net/ethernet/renesas/ravb_ptp.c
index eede70ec37f8..ba3017ca5577 100644
--- a/drivers/net/ethernet/renesas/ravb_ptp.c
+++ b/drivers/net/ethernet/renesas/ravb_ptp.c
@@ -319,7 +319,7 @@ void ravb_ptp_interrupt(struct net_device *ndev)
}
}
 
-   ravb_write(ndev, ~gis, GIS);
+   ravb_write(ndev, ~(gis | GIS_RESERVED_BITS), GIS);
 }
 
 void ravb_ptp_init(struct net_device *ndev, struct platform_device *pdev)
-- 
2.11.0



[PATCH/RFC net-next 5/5] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3

2018-04-17 Thread Simon Horman
From: Kazuya Mizuguchi 

This patch sets from two descriptor to one descriptor because R-Car Gen3
does not have the 4 bytes alignment restriction of the transmission buffer.

Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Simon Horman 
---
 drivers/net/ethernet/renesas/ravb.h  |   6 +-
 drivers/net/ethernet/renesas/ravb_main.c | 131 +++
 2 files changed, 85 insertions(+), 52 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index fcd04dbc7dde..3d0985305c26 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -964,7 +964,10 @@ enum RAVB_QUEUE {
 #define RX_QUEUE_OFFSET4
 #define NUM_RX_QUEUE   2
 #define NUM_TX_QUEUE   2
-#define NUM_TX_DESC2   /* TX descriptors per packet */
+
+/* TX descriptors per packet */
+#define NUM_TX_DESC_GEN2   2
+#define NUM_TX_DESC_GEN3   1
 
 struct ravb_tstamp_skb {
struct list_head list;
@@ -1043,6 +1046,7 @@ struct ravb_private {
unsigned no_avb_link:1;
unsigned avb_link_active_low:1;
unsigned wol_enabled:1;
+   int num_tx_desc;/* TX descriptors per packet */
 };
 
 static inline u32 ravb_read(struct net_device *ndev, enum ravb_reg reg)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 88056dd912ed..f137b62d5b52 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -189,12 +189,13 @@ static int ravb_tx_free(struct net_device *ndev, int q, 
bool free_txed_only)
int free_num = 0;
int entry;
u32 size;
+   int num_tx_desc = priv->num_tx_desc;
 
for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) {
bool txed;
 
entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
-NUM_TX_DESC);
+num_tx_desc);
desc = >tx_ring[q][entry];
txed = desc->die_dt == DT_FEMPTY;
if (free_txed_only && !txed)
@@ -203,12 +204,12 @@ static int ravb_tx_free(struct net_device *ndev, int q, 
bool free_txed_only)
dma_rmb();
size = le16_to_cpu(desc->ds_tagl) & TX_DS;
/* Free the original skb. */
-   if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+   if (priv->tx_skb[q][entry / num_tx_desc]) {
dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
 size, DMA_TO_DEVICE);
/* Last packet descriptor? */
-   if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
-   entry /= NUM_TX_DESC;
+   if (entry % num_tx_desc == num_tx_desc - 1) {
+   entry /= num_tx_desc;
dev_kfree_skb_any(priv->tx_skb[q][entry]);
priv->tx_skb[q][entry] = NULL;
if (txed)
@@ -229,6 +230,7 @@ static void ravb_ring_free(struct net_device *ndev, int q)
struct ravb_private *priv = netdev_priv(ndev);
int ring_size;
int i;
+   int num_tx_desc = priv->num_tx_desc;
 
if (priv->rx_ring[q]) {
for (i = 0; i < priv->num_rx_ring[q]; i++) {
@@ -252,7 +254,7 @@ static void ravb_ring_free(struct net_device *ndev, int q)
ravb_tx_free(ndev, q, false);
 
ring_size = sizeof(struct ravb_tx_desc) *
-   (priv->num_tx_ring[q] * NUM_TX_DESC + 1);
+   (priv->num_tx_ring[q] * num_tx_desc + 1);
dma_free_coherent(ndev->dev.parent, ring_size, priv->tx_ring[q],
  priv->tx_desc_dma[q]);
priv->tx_ring[q] = NULL;
@@ -284,9 +286,10 @@ static void ravb_ring_format(struct net_device *ndev, int 
q)
struct ravb_ex_rx_desc *rx_desc;
struct ravb_tx_desc *tx_desc;
struct ravb_desc *desc;
+   int num_tx_desc = priv->num_tx_desc;
int rx_ring_size = sizeof(*rx_desc) * priv->num_rx_ring[q];
int tx_ring_size = sizeof(*tx_desc) * priv->num_tx_ring[q] *
-  NUM_TX_DESC;
+  num_tx_desc;
dma_addr_t dma_addr;
int i;
 
@@ -321,8 +324,10 @@ static void ravb_ring_format(struct net_device *ndev, int 
q)
for (i = 0, tx_desc = priv->tx_ring[q]; i < priv->num_tx_ring[q];
 i++, tx_desc++) {
tx_desc->die_dt = DT_EEMPTY;
-   tx_desc++;
-   tx_desc->die_dt = DT_EEMPTY;
+   if (num_tx_desc >= 2) {
+   tx_desc++;
+   tx_desc->die_dt = DT_EEMPTY;
+   }
  

[PATCH/RFC net-next 4/5] ravb: remove undocumented processing

2018-04-17 Thread Simon Horman
From: Kazuya Mizuguchi 

Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Simon Horman 
---
 drivers/net/ethernet/renesas/ravb.h  |  5 -
 drivers/net/ethernet/renesas/ravb_main.c | 15 ---
 2 files changed, 20 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index 57eea4a77826..fcd04dbc7dde 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -197,15 +197,11 @@ enum ravb_reg {
MAHR= 0x05c0,
MALR= 0x05c8,
TROCR   = 0x0700,   /* Undocumented? */
-   CDCR= 0x0708,   /* Undocumented? */
-   LCCR= 0x0710,   /* Undocumented? */
CEFCR   = 0x0740,
FRECR   = 0x0748,
TSFRCR  = 0x0750,
TLFRCR  = 0x0758,
RFCR= 0x0760,
-   CERCR   = 0x0768,   /* Undocumented? */
-   CEECR   = 0x0770,   /* Undocumented? */
MAFCR   = 0x0778,
 };
 
@@ -223,7 +219,6 @@ enum CCC_BIT {
CCC_CSEL_HPB= 0x0001,
CCC_CSEL_ETH_TX = 0x0002,
CCC_CSEL_GMII_REF = 0x0003,
-   CCC_BOC = 0x0010,   /* Undocumented? */
CCC_LBME= 0x0100,
 };
 
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 736ca2f76a35..88056dd912ed 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -451,12 +451,6 @@ static int ravb_dmac_init(struct net_device *ndev)
ravb_ring_format(ndev, RAVB_BE);
ravb_ring_format(ndev, RAVB_NC);
 
-#if defined(__LITTLE_ENDIAN)
-   ravb_modify(ndev, CCC, CCC_BOC, 0);
-#else
-   ravb_modify(ndev, CCC, CCC_BOC, CCC_BOC);
-#endif
-
/* Set AVB RX */
ravb_write(ndev,
   RCR_EFFS | RCR_ENCF | RCR_ETS0 | RCR_ESF | 0x1800, RCR);
@@ -1660,15 +1654,6 @@ static struct net_device_stats *ravb_get_stats(struct 
net_device *ndev)
 
nstats->tx_dropped += ravb_read(ndev, TROCR);
ravb_write(ndev, 0, TROCR); /* (write clear) */
-   nstats->collisions += ravb_read(ndev, CDCR);
-   ravb_write(ndev, 0, CDCR);  /* (write clear) */
-   nstats->tx_carrier_errors += ravb_read(ndev, LCCR);
-   ravb_write(ndev, 0, LCCR);  /* (write clear) */
-
-   nstats->tx_carrier_errors += ravb_read(ndev, CERCR);
-   ravb_write(ndev, 0, CERCR); /* (write clear) */
-   nstats->tx_carrier_errors += ravb_read(ndev, CEECR);
-   ravb_write(ndev, 0, CEECR); /* (write clear) */
 
nstats->rx_packets = stats0->rx_packets + stats1->rx_packets;
nstats->tx_packets = stats0->tx_packets + stats1->tx_packets;
-- 
2.11.0



[PATCH/RFC net-next 2/5] ravb: correct ptp does failure after suspend and resume

2018-04-17 Thread Simon Horman
From: Kazuya Mizuguchi 

This patch fixes the problem that ptp4l command does not work after
suspend and resume.
Add the initial setting in ravb_suspend() and ravb_resume(),
because ptp does not work.

Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Simon Horman 
---
 drivers/net/ethernet/renesas/ravb_main.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index b311b1ac1286..dbde3d11458b 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2295,6 +2295,9 @@ static int __maybe_unused ravb_suspend(struct device *dev)
else
ret = ravb_close(ndev);
 
+   if (priv->chip_id != RCAR_GEN2)
+   ravb_ptp_stop(ndev);
+
return ret;
 }
 
@@ -2302,6 +2305,7 @@ static int __maybe_unused ravb_resume(struct device *dev)
 {
struct net_device *ndev = dev_get_drvdata(dev);
struct ravb_private *priv = netdev_priv(ndev);
+   struct platform_device *pdev = priv->pdev;
int ret = 0;
 
/* If WoL is enabled set reset mode to rearm the WoL logic */
@@ -2330,6 +2334,9 @@ static int __maybe_unused ravb_resume(struct device *dev)
/* Restore descriptor base address table */
ravb_write(ndev, priv->desc_bat_dma, DBAT);
 
+   if (priv->chip_id != RCAR_GEN2)
+   ravb_ptp_init(ndev, pdev);
+
if (netif_running(ndev)) {
if (priv->wol_enabled) {
ret = ravb_wol_restore(ndev);
-- 
2.11.0



[PATCH/RFC net-next 1/5] ravb: fix inconsistent lock state at enabling tx timestamp

2018-04-17 Thread Simon Horman
From: Masaru Nagai 

[   58.490829] =
[   58.495205] [ INFO: inconsistent lock state ]
[   58.499583] 4.9.0-yocto-standard-7-g2ef7caf #57 Not tainted
[   58.505529] -
[   58.509904] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[   58.515939] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:
[   58.521099]  (&(>lock)->rlock#2){?.-...}, at: [] 
skb_queue_tail+0x2c/0x68
{HARDIRQ-ON-W} state was registered at:
[   58.533654]   [   58.535155] [] mark_lock+0x1c4/0x718
[   58.540318]   [   58.541814] [] __lock_acquire+0x660/0x1890
[   58.547501]   [   58.548997] [] lock_acquire+0xd0/0x290
[   58.554334]   [   58.555834] [] _raw_spin_lock_bh+0x50/0x90
[   58.561520]   [   58.563018] [] 
first_packet_length+0x40/0x2b0
[   58.568965]   [   58.570461] [] udp_ioctl+0x58/0x120
[   58.575535]   [   58.577032] [] inet_ioctl+0x58/0x128
[   58.582194]   [   58.583691] [] sock_do_ioctl+0x40/0x88
[   58.589028]   [   58.590523] [] sock_ioctl+0x284/0x350
[   58.595773]   [   58.597271] [] do_vfs_ioctl+0xb0/0x7c0
[   58.602607]   [   58.604103] [] SyS_ioctl+0x94/0xa8
[   58.609090]   [   58.610588] [] __sys_trace_return+0x0/0x4
[   58.616187] irq event stamp: 335205
[   58.619690] hardirqs last  enabled at (335204): [] 
__do_softirq+0xdc/0x5c4
[   58.628168] hardirqs last disabled at (335205): [] 
el1_irq+0x70/0x12c
[   58.636211] softirqs last  enabled at (335202): [] 
_local_bh_enable+0x28/0x50
[   58.644950] softirqs last disabled at (335203): [] 
irq_exit+0xd4/0x100
[   58.653076]
[   58.653076] other info that might help us debug this:
[   58.659632]  Possible unsafe locking scenario:
[   58.659632]
[   58.665577]CPU0
[   58.668031]
[   58.670484]   lock(&(>lock)->rlock#2);
[   58.674799]   
[   58.677427] lock(&(>lock)->rlock#2);
[   58.681916]
[   58.681916]  *** DEADLOCK ***
[   58.681916]
[   58.687863] 1 lock held by swapper/0/0:
[   58.691713]  #0:  (&(>lock)->rlock){-.-...}, at: [] 
ravb_multi_interrupt+0x28/0x98
[   58.701456]
[   58.701456] stack backtrace:
[   58.705833] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.9.0-yocto-standard-7-g2ef7caf #57
[   58.714396] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   58.721214] Call trace:
[   58.723672] [] dump_backtrace+0x0/0x1d8
[   58.729095] [] show_stack+0x24/0x30
[   58.734170] [] dump_stack+0xb0/0xe8
[   58.740285] [] print_usage_bug.part.24+0x264/0x27c
[   58.747697] [] mark_lock+0x150/0x718
[   58.753892] [] __lock_acquire+0xc10/0x1890
[   58.760602] [] lock_acquire+0xd0/0x290
[   58.766956] [] _raw_spin_lock_irqsave+0x58/0x98
[   58.774089] [] skb_queue_tail+0x2c/0x68
[   58.780518] [] sock_queue_err_skb+0xc8/0x138
[   58.787364] [] __skb_complete_tx_timestamp+0x8c/0xb8
[   58.794888] [] __skb_tstamp_tx+0xd8/0x130
[   58.801437] [] skb_tstamp_tx+0x30/0x40
[   58.807723] [] ravb_timestamp_interrupt+0x164/0x1a8
[   58.815144] [] ravb_multi_interrupt+0x88/0x98
[   58.822043] [] __handle_irq_event_percpu+0x94/0x418
[   58.829464] [] handle_irq_event_percpu+0x28/0x60
[   58.836622] [] handle_irq_event+0x50/0x80
[   58.843166] [] handle_fasteoi_irq+0xdc/0x1e0
[   58.849968] [] generic_handle_irq+0x34/0x50
[   58.856681] [] __handle_domain_irq+0x8c/0x100
[   58.863568] [] gic_handle_irq+0x60/0xb8
[   58.869930] Exception stack(0x80063b0f9de0 to 0x80063b0f9f10)
[   58.877348] 9de0: 80063b0f9e10 0001 80063b0f9f40 
08081810
[   58.886159] 9e00: 6145 08082f70 09194b00 
00190f2c
[   58.894961] 9e20: 800632171000 000a  
0003a4d0
[   58.903767] 9e40: 0016 0023 091952f8 

[   58.912568] 9e60: 0040  34d5d91d 

[   58.921363] 9e80:    

[   58.930133] 9ea0:  0918 080d76e4 
0052
[   58.938897] 9ec0: 08d7 0008  
0001
[   58.947660] 9ee0: 80063a428000 09185000 0918 
80063b0f9f40
[   58.956430] 9f00: 0808180c 80063b0f9f40
[   58.962253] [] el1_irq+0xb4/0x12c
[   58.968096] [] irq_exit+0xd4/0x100
[   58.974025] [] __handle_domain_irq+0x90/0x100
[   58.980916] [] gic_handle_irq+0x60/0xb8
[   58.987281] Exception stack(0x09183d20 to 0x09183e50)
[   58.994708] 3d20: 09194b00 00190f2b 800632171000 
8c6318c6318c6320
[   59.003554] 3d40:  0003a4d0 0016 
002a
[   59.012416] 3d60: 091952f8  1000 

[   59.021279] 3d80: 34d5d91d   

[   59.030111] 3da0:    
000d9e3b53c4
[   59.038913] 3dc0: 

[PATCH/RFC net-next 0/5] ravb: updates

2018-04-17 Thread Simon Horman
Hi Sergei,

this series is composed of otherwise unrelated RAVB patches from the R-Car
BSP v3.6.2 which at a first pass seem worth considering for upstream.

I would value your feedback on these patches so they can either proceed
into net-next or remain local to the BSP.

Thanks!

Kazuya Mizuguchi (4):
  ravb: correct ptp does failure after suspend and resume
  ravb: do not write 1 to reserved bits
  ravb: remove undocumented processing
  ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car
Gen3

Masaru Nagai (1):
  ravb: fix inconsistent lock state at enabling tx timestamp

 drivers/net/ethernet/renesas/ravb.h  |  23 +++-
 drivers/net/ethernet/renesas/ravb_main.c | 192 ---
 drivers/net/ethernet/renesas/ravb_ptp.c  |   2 +-
 3 files changed, 117 insertions(+), 100 deletions(-)

-- 
2.11.0



Re: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node

2018-04-17 Thread Geert Uytterhoeven
Hi Michel,

On Tue, Apr 17, 2018 at 9:56 AM, Michel Pollet
 wrote:
> On 13 April 2018 19:06, Rob Herring:
>> On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function system
>> > controller. This documents the node used to encapsulate it's sub
>> > drivers.
>> >
>> > Signed-off-by: Michel Pollet 
>> > ---
>> >  .../bindings/mfd/renesas,rzn1-sysctrl.txt  | 23
>> ++
>> >  1 file changed, 23 insertions(+)
>> >  create mode 100644
>> > Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> >
>> > diff --git
>> > a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > new file mode 100644
>> > index 000..9897f8f
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > @@ -0,0 +1,23 @@
>> > +DT bindings for the Renesas RZ/N1 System Controller
>> > +
>> > +== System Controller Node ==
>> > +
>> > +The system controller node currently only hosts a single sub-node to
>> > +handle the rebooting of the CPU. Eventually it will host the clock
>> > +driver, SMP start handler, watchdog etc.
>>
>> Please submit a complete binding for the h/w block.
>>
>> Again, if the only reason you have sub nodes is to define compatible strings
>> and in turn enumerate drivers, then you don't need the nodes in DT. DT is
>> not the only way to instantiate drivers.
>
> I can't document it before I have the code. There is 0.000% chance of my clock
> driver for example to be upstreamed the way I would imagine making it -- in
> fact pretty much any other driver will have to be reworked to fit, so 
> documenting
> bindings first is impossible.
>
> So, if I understand correctly, you are telling me to make a 'sysctrl' driver 
> and use
> platform_device to instantiate my sub-drivers? Isn't that what machine files 
> used
> to do? And they are now banned?
>
> Geert, any guidance here?

It depends on how many and which subnodes you want to add to  the sysctrl
node. Without a complete binding for the block, we cannot know.
If the major part will be the clock driver, I would make that the main
driver for the sysctrl node. The clock driver can easily register
e.g. a simple reset handler.

Cfr. the renesas-cpg-mssr driver, which also handles (module) resets.
There are plenty of other examples of drivers providing multiple
functionalities (e.g. pinctrl drivers also registering GPIO controllers).

If a monolithic driver becomes too large, it can still be split using the
MFD framework.
E.g. the BD9571 PMIC driver is split in an MFD core driver, and 2 drivers
for different functionalities:

   drivers/gpio/gpio-bd9571mwv.c
   drivers/mfd/bd9571mwv.c
   drivers/regulator/bd9571mwv-regulator.c
   include/linux/mfd/bd9571mwv.h

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 v6 07/11] ARM: sun9i: smp: Rename clusters's power-off

2018-04-17 Thread Sergei Shtylyov

Hello!

On 4/17/2018 12:50 AM, Mylène Josserand wrote:


To prepare the support for sun8i-a83t, rename the variable name


   s/variable/macro/ maybe? Also "rename the ... name" sounds tautological...


that handles the power-off of clusters because it is different from
sun9i-a80 to sun8i-a83t.

The power off register for clusters are different from a80 and a83t.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
Reviewed-by: Chen-Yu Tsai 
---
  arch/arm/mach-sunxi/mc_smp.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index 727968d6a3e5..03f021d0c73e 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -60,7 +60,7 @@
  #define PRCM_CPU_PO_RST_CTRL_CORE(n)  BIT(n)
  #define PRCM_CPU_PO_RST_CTRL_CORE_ALL 0xf
  #define PRCM_PWROFF_GATING_REG(c) (0x100 + 0x4 * (c))
-#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
+#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
  #define PRCM_PWROFF_GATING_REG_CORE(n)BIT(n)
  #define PRCM_PWR_SWITCH_REG(c, cpu)   (0x140 + 0x10 * (c) + 0x4 * (cpu))
  #define PRCM_CPU_SOFT_ENTRY_REG   0x164
@@ -255,7 +255,7 @@ static int sunxi_cluster_powerup(unsigned int cluster)
  
  	/* clear cluster power gate */

reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
-   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER;
+   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
  
@@ -452,7 +452,7 @@ static int sunxi_cluster_powerdown(unsigned int cluster)

/* gate cluster power */
pr_debug("%s: gate cluster power\n", __func__);
reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
-   reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
+   reg |= PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
  


MBR, Sergei


Re: [PATCH v6 08/11] ARM: sun9i: smp: Add is_sun8i field

2018-04-17 Thread Chen-Yu Tsai
On Tue, Apr 17, 2018 at 3:52 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Apr 16, 2018 at 11:50:29PM +0200, Mylène Josserand wrote:
>> To prepare the support of sun8i-a83t, add a field in the smp_data
>> structure to know if we are on sun9i-a80 or sun8i-a83t.
>>
>> Add also a global variable to retrieve which architecture we are
>> having.
>>
>> Signed-off-by: Mylène Josserand 
>> ---
>>  arch/arm/mach-sunxi/mc_smp.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
>> index 03f021d0c73e..9d57ea27dacc 100644
>> --- a/arch/arm/mach-sunxi/mc_smp.c
>> +++ b/arch/arm/mach-sunxi/mc_smp.c
>> @@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
>>
>>  extern void sunxi_mc_smp_secondary_startup(void);
>>  extern void sunxi_mc_smp_resume(void);
>> +static int is_sun8i;
>>
>>  static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int 
>> cluster)
>>  {
>> @@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
>>  struct sunxi_mc_smp_data {
>>   const char *enable_method;
>>   int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
>> + int is_sun8i;
>>  };
>>
>>  static void __init sunxi_mc_smp_put_nodes(struct sunxi_mc_smp_nodes *nodes)
>> @@ -664,6 +666,7 @@ static const struct sunxi_mc_smp_data 
>> sunxi_mc_smp_data[] __initconst = {
>>   {
>>   .enable_method  = "allwinner,sun9i-a80-smp",
>>   .get_smp_nodes  = sun9i_a80_get_smp_nodes,
>> + .is_sun8i   = false,
>
> I'm still not convinced about the name of that flag. sun8i doesn't
> mean anything, really. What you want to discriminate against it what
> you're writing in your commit log: if it is an A80 or an A83t. The
> A33, H3, A23, you name it are also part of the sun8i family, yet they
> are completely irrelevant to this file.
>
> Also, false is the default value, you can leave it out.
>
>>   },
>>  };
>>
>> @@ -697,6 +700,8 @@ static int __init sunxi_mc_smp_init(void)
>>   break;
>>   }
>>
>> + is_sun8i = sunxi_mc_smp_data[i].is_sun8i;
>> +
>
> Do we really need to cache it? Can't we just have a pointer to the SMP
> data structure and use that instead?

I recommended that. We don't need any of the other fields in the SMP
data structure once we're past the init phase. This saves a dereference
or two.

ChenYu


RE: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node

2018-04-17 Thread Michel Pollet
Hi Rob,

On 13 April 2018 19:06, Rob Herring:
> On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote:
> > The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function system
> > controller. This documents the node used to encapsulate it's sub
> > drivers.
> >
> > Signed-off-by: Michel Pollet 
> > ---
> >  .../bindings/mfd/renesas,rzn1-sysctrl.txt  | 23
> ++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> > b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> > new file mode 100644
> > index 000..9897f8f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
> > @@ -0,0 +1,23 @@
> > +DT bindings for the Renesas RZ/N1 System Controller
> > +
> > +== System Controller Node ==
> > +
> > +The system controller node currently only hosts a single sub-node to
> > +handle the rebooting of the CPU. Eventually it will host the clock
> > +driver, SMP start handler, watchdog etc.
>
> Please submit a complete binding for the h/w block.
>
> Again, if the only reason you have sub nodes is to define compatible strings
> and in turn enumerate drivers, then you don't need the nodes in DT. DT is
> not the only way to instantiate drivers.

I can't document it before I have the code. There is 0.000% chance of my clock
driver for example to be upstreamed the way I would imagine making it -- in
fact pretty much any other driver will have to be reworked to fit, so 
documenting
bindings first is impossible.

So, if I understand correctly, you are telling me to make a 'sysctrl' driver 
and use
platform_device to instantiate my sub-drivers? Isn't that what machine files 
used
to do? And they are now banned?

Geert, any guidance here?

>
> Rob

Thanks!
Michel




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.


Re: [PATCH v6 08/11] ARM: sun9i: smp: Add is_sun8i field

2018-04-17 Thread Maxime Ripard
Hi,

On Mon, Apr 16, 2018 at 11:50:29PM +0200, Mylène Josserand wrote:
> To prepare the support of sun8i-a83t, add a field in the smp_data
> structure to know if we are on sun9i-a80 or sun8i-a83t.
> 
> Add also a global variable to retrieve which architecture we are
> having.
> 
> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/mach-sunxi/mc_smp.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> index 03f021d0c73e..9d57ea27dacc 100644
> --- a/arch/arm/mach-sunxi/mc_smp.c
> +++ b/arch/arm/mach-sunxi/mc_smp.c
> @@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
>  
>  extern void sunxi_mc_smp_secondary_startup(void);
>  extern void sunxi_mc_smp_resume(void);
> +static int is_sun8i;
>  
>  static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
>  {
> @@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
>  struct sunxi_mc_smp_data {
>   const char *enable_method;
>   int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
> + int is_sun8i;
>  };
>  
>  static void __init sunxi_mc_smp_put_nodes(struct sunxi_mc_smp_nodes *nodes)
> @@ -664,6 +666,7 @@ static const struct sunxi_mc_smp_data sunxi_mc_smp_data[] 
> __initconst = {
>   {
>   .enable_method  = "allwinner,sun9i-a80-smp",
>   .get_smp_nodes  = sun9i_a80_get_smp_nodes,
> + .is_sun8i   = false,

I'm still not convinced about the name of that flag. sun8i doesn't
mean anything, really. What you want to discriminate against it what
you're writing in your commit log: if it is an A80 or an A83t. The
A33, H3, A23, you name it are also part of the sun8i family, yet they
are completely irrelevant to this file.

Also, false is the default value, you can leave it out.

>   },
>  };
>  
> @@ -697,6 +700,8 @@ static int __init sunxi_mc_smp_init(void)
>   break;
>   }
>  
> + is_sun8i = sunxi_mc_smp_data[i].is_sun8i;
> +

Do we really need to cache it? Can't we just have a pointer to the SMP
data structure and use that instead?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH] pinctrl: sh-pfc: r8a77970: add pin I/O voltage control

2018-04-17 Thread Geert Uytterhoeven
Hi Sergei,

On Mon, Apr 16, 2018 at 5:06 PM, Sergei Shtylyov
 wrote:
> On 04/16/2018 04:02 PM, Geert Uytterhoeven wrote:
>>> Add the pin I/O voltage level control to the R8A77980 PFC driver.
>>
>> Subject says r8a77970?
>
>Typo, I guess. :-)
>
>>> Loosely based on the original (and large) patch by Vladimir Barinov.
>>>
>>> Signed-off-by: Vladimir Barinov 
>>> Signed-off-by: Sergei Shtylyov 
>>>
>>> ---
>>>  drivers/pinctrl/sh-pfc/pfc-r8a77980.c |   50 
>>> +++---
>>>  1 file changed, 47 insertions(+), 3 deletions(-)
>>>
>>> Index: renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77980.c
>>> ===
>>> --- renesas-drivers.orig/drivers/pinctrl/sh-pfc/pfc-r8a77980.c
>>> +++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77980.c
>>
>> Ah, pfc-r8a77980.c it is.
>>
>>> @@ -2779,8 +2779,51 @@ static const struct pinmux_cfg_reg pinmu
>>> { },
>>>  };
>>>
>>> +enum ioctrl_regs {
>>> +   IOCTRL30,
>>> +   IOCTRL31,
>>> +   IOCTRL32,
>>> +};
>>> +
>>> +static const struct pinmux_ioctrl_reg pinmux_ioctrl_regs[] = {
>>> +   [IOCTRL30] = { 0xe6060380, },
>>> +   [IOCTRL31] = { 0xe6060384, },
>>> +   [IOCTRL32] = { 0xe6060388, },
>>> +   { /* sentinel */ },
>>
>> However, r8a77980 has 4 IOCTRL3x registers (r8a77970 has three)?
>
>I thought that since we don't change it, no need to list it for 
> save/restore
> either. I was wrong?

Given the system resume path differs from the boot path (resume skips the
boot loader, and thus all PFC initialization it performs), I think it is
safest to list it anyway, so it is saved and restored.

>> Something is wrong: which SoC source file is this patch for?
>
>R8A77980.

Thanks for confirming, will resume reviewing (either this version, or v2 ;-)

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 v6 01/11] ARM: sunxi: smp: Move assembly code into a file

2018-04-17 Thread kbuild test robot
Hi Mylène,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on arm-soc/for-next]
[also build test ERROR on v4.17-rc1 next-20180416]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/Sunxi-Add-SMP-support-on-A83T/20180417-113911
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   include/asm-generic/bitops/sched.h:14: Error: junk at end of line, first 
unrecognized character is `{'
   include/asm-generic/bitops/sched.h:20: Error: bad instruction `if (b[0])'
   include/asm-generic/bitops/sched.h:21: Error: bad instruction `return 
__ffs(b[0])'
   include/asm-generic/bitops/sched.h:22: Error: bad instruction `if (b[1])'
   include/asm-generic/bitops/sched.h:23: Error: bad instruction `return 
__ffs(b[1])+32'
   include/asm-generic/bitops/sched.h:24: Error: bad instruction `if (b[2])'
   include/asm-generic/bitops/sched.h:25: Error: bad instruction `return 
__ffs(b[2])+64'
   include/asm-generic/bitops/sched.h:26: Error: bad instruction `return 
__ffs(b[3])+96'
   include/asm-generic/bitops/sched.h:30: Error: junk at end of line, first 
unrecognized character is `}'
   include/asm-generic/bitops/arch_hweight.h:7: Error: bad instruction `static 
inline unsigned int __arch_hweight32(unsigned int w)'
   include/asm-generic/bitops/arch_hweight.h:8: Error: junk at end of line, 
first unrecognized character is `{'
   include/asm-generic/bitops/arch_hweight.h:9: Error: bad instruction `return 
__sw_hweight32(w)'
   include/asm-generic/bitops/arch_hweight.h:10: Error: junk at end of line, 
first unrecognized character is `}'
   include/asm-generic/bitops/arch_hweight.h:12: Error: bad instruction `static 
inline unsigned int __arch_hweight16(unsigned int w)'
   include/asm-generic/bitops/arch_hweight.h:13: Error: junk at end of line, 
first unrecognized character is `{'
   include/asm-generic/bitops/arch_hweight.h:14: Error: bad instruction `return 
__sw_hweight16(w)'
   include/asm-generic/bitops/arch_hweight.h:15: Error: junk at end of line, 
first unrecognized character is `}'
   include/asm-generic/bitops/arch_hweight.h:17: Error: bad instruction `static 
inline unsigned int __arch_hweight8(unsigned int w)'
   include/asm-generic/bitops/arch_hweight.h:18: Error: junk at end of line, 
first unrecognized character is `{'
   include/asm-generic/bitops/arch_hweight.h:19: Error: bad instruction `return 
__sw_hweight8(w)'
   include/asm-generic/bitops/arch_hweight.h:20: Error: junk at end of line, 
first unrecognized character is `}'
   include/asm-generic/bitops/arch_hweight.h:22: Error: bad instruction `static 
inline unsigned long __arch_hweight64(__u64 w)'
   include/asm-generic/bitops/arch_hweight.h:23: Error: junk at end of line, 
first unrecognized character is `{'
   include/asm-generic/bitops/arch_hweight.h:24: Error: bad instruction `return 
__sw_hweight64(w)'
   include/asm-generic/bitops/arch_hweight.h:25: Error: junk at end of line, 
first unrecognized character is `}'
   include/asm-generic/bitops/find.h:30: Error: bad instruction `extern 
unsigned long find_next_and_bit(const unsigned long*addr1,'
   include/asm-generic/bitops/find.h:31: Error: bad instruction `const unsigned 
long*addr2,unsigned long size,'
   include/asm-generic/bitops/find.h:32: Error: bad instruction `unsigned long 
offset)'
   arch/arm/include/asm/swab.h:23: Error: bad instruction `static inline __u32 
__arch_swahb32(__u32 x)'
   arch/arm/include/asm/swab.h:24: Error: junk at end of line, first 
unrecognized character is `{'
   arch/arm/include/asm/swab.h:25: Error: bad instruction `__asm__ ("rev16 %0, 
%1":"=r"(x):"r"(x))'
   arch/arm/include/asm/swab.h:26: Error: bad instruction `return x'
   arch/arm/include/asm/swab.h:27: Error: junk at end of line, first 
unrecognized character is `}'
   arch/arm/include/asm/swab.h:31: Error: bad instruction `static inline __u32 
__arch_swab32(__u32 x)'
   arch/arm/include/asm/swab.h:32: Error: junk at end of line, first 
unrecognized character is `{'
   arch/arm/include/asm/swab.h:33: Error: bad instruction `__asm__ ("rev %0, 
%1":"=r"(x):"r"(x))'
   arch/arm/include/asm/swab.h:34: Error: bad instruction `return x'
   arch/arm/include/asm/swab.h:35: Error: junk at end of line, first 
unrecognized character is `}'
   include/uapi/linux/swab.h:47: Error: bad instruction `static inline __u16 
__fswab16(__u16 val)'
   include/uapi/linux/swab.h:48: Error: junk at end of line, fi