date:20180510

On Thu, May 10, 2018 at 10:43 PM, Jagan Teki  wrote:
> Amarula A64 Relic is Allwinner A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - Mali-400MP2 GPU
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - AP6330 Wifi/BLE
> - MIPI-DSI
> - CSI: OV5640 sensor
> - USB OTG
> - 12V DC power supply
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v2:
> - Rename dts name to sun50i-a64-relic.dts which is simple to use

This is subjective. For other users this hardly qualifies to
identify the board. Please keep the vendor / brand name in
the file name.

ChenYu

Re: [PATCH] ARM: dts: imx51-zii-rdu1: fix touchscreen bindings

2018-05-10 Thread Shawn Guo

On Mon, May 07, 2018 at 04:53:09PM +0300, Nikita Yushchenko wrote:
> This fixes errors in RDU1 device tree that cause touch screens not
> working.
> 
> Signed-off-by: Nikita Yushchenko 

Applied, thanks.

Re: [PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

On Thu, May 10, 2018 at 10:43 PM, Jagan Teki  wrote:
> Amarula A64 Relic is Allwinner A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - Mali-400MP2 GPU
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - AP6330 Wifi/BLE
> - MIPI-DSI
> - CSI: OV5640 sensor
> - USB OTG
> - 12V DC power supply
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v2:
> - Rename dts name to sun50i-a64-relic.dts which is simple to use

This is subjective. For other users this hardly qualifies to
identify the board. Please keep the vendor / brand name in
the file name.

ChenYu

Re: [PATCH 2/3] sched/fair: util_est: update before schedutil

On 10-05-18, 16:05, Patrick Bellasi wrote:
> When a task is enqueue the estimated utilization of a CPU is updated
> to better support the selection of the required frequency.
> However, schedutil is (implicitly) updated by update_load_avg() which
> always happens before util_est_{en,de}queue(), thus potentially
> introducing a latency between estimated utilization updates and
> frequency selections.
> 
> Let's update util_est at the beginning of enqueue_task_fair(),
> which will ensure that all schedutil updates will see the most
> updated estimated utilization value for a CPU.
> 
> Reported-by: Vincent Guittot 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Vincent Guittot 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/fair.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Fixes and Stable ?

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 1f6a23a5b451..01dfc47541e6 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5356,6 +5356,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   struct cfs_rq *cfs_rq;
>   struct sched_entity *se = >se;
>  
> + /* Estimated utilization must be updated before schedutil */
> + util_est_enqueue(>cfs, p);
> +
>   /*
>* If in_iowait is set, the code below may not trigger any cpufreq
>* utilization updates, so do it here explicitly with the IOWAIT flag
> @@ -5397,7 +5400,6 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   if (!se)
>   add_nr_running(rq, 1);
>  
> - util_est_enqueue(>cfs, p);
>   hrtick_update(rq);
>  }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 2/3] sched/fair: util_est: update before schedutil

On 10-05-18, 16:05, Patrick Bellasi wrote:
> When a task is enqueue the estimated utilization of a CPU is updated
> to better support the selection of the required frequency.
> However, schedutil is (implicitly) updated by update_load_avg() which
> always happens before util_est_{en,de}queue(), thus potentially
> introducing a latency between estimated utilization updates and
> frequency selections.
> 
> Let's update util_est at the beginning of enqueue_task_fair(),
> which will ensure that all schedutil updates will see the most
> updated estimated utilization value for a CPU.
> 
> Reported-by: Vincent Guittot 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Vincent Guittot 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/fair.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Fixes and Stable ?

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 1f6a23a5b451..01dfc47541e6 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5356,6 +5356,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   struct cfs_rq *cfs_rq;
>   struct sched_entity *se = >se;
>  
> + /* Estimated utilization must be updated before schedutil */
> + util_est_enqueue(>cfs, p);
> +
>   /*
>* If in_iowait is set, the code below may not trigger any cpufreq
>* utilization updates, so do it here explicitly with the IOWAIT flag
> @@ -5397,7 +5400,6 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>   if (!se)
>   add_nr_running(rq, 1);
>  
> - util_est_enqueue(>cfs, p);
>   hrtick_update(rq);
>  }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/3] sched/cpufreq: always consider blocked FAIR utilization

On 10-05-18, 16:05, Patrick Bellasi wrote:
> Since the refactoring introduced by:
> 
>commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support")
> 
> we aggregate FAIR utilization only if this class has runnable tasks.
> This was mainly due to avoid the risk to stay on an high frequency just
> because of the blocked utilization of a CPU not being properly decayed
> while the CPU was idle.
> 
> However, since:
> 
>commit 31e77c93e432 ("sched/fair: Update blocked load when newly idle")
> 
> the FAIR blocked utilization is properly decayed also for IDLE CPUs.
> 
> This allows us to use the FAIR blocked utilization as a safe mechanism
> to gracefully reduce the frequency only if no FAIR tasks show up on a
> CPU for a reasonable period of time.
> 
> Moreover, we also reduce the frequency drops of CPUs running periodic
> tasks which, depending on the task periodicity and the time required
> for a frequency switch, was increasing the chances to introduce some
> undesirable performance variations.
> 
> Reported-by: Vincent Guittot 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Vincent Guittot 
> Cc: Viresh Kumar 
> Cc: Joel Fernandes 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/cpufreq_schedutil.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)

Do we need a Fixes tag and Cc stable ?

> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index d2c6083304b4..a74d05160e66 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -183,22 +183,21 @@ static void sugov_get_util(struct sugov_cpu *sg_cpu)
>  static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
>  {
>   struct rq *rq = cpu_rq(sg_cpu->cpu);
> - unsigned long util;
>  
> - if (rq->rt.rt_nr_running) {
> - util = sg_cpu->max;
> - } else {
> - util = sg_cpu->util_dl;
> - if (rq->cfs.h_nr_running)
> - util += sg_cpu->util_cfs;
> - }
> + if (rq->rt.rt_nr_running)
> + return sg_cpu->max;
>  
>   /*
> +  * Utilization required by DEADLINE must always be granted while, for
> +  * FAIR, we use blocked utilization of IDLE CPUs as a mechanism to
> +  * gracefully reduce the frequency when no tasks show up for longer
> +  * periods of time.
> +  *
>* Ideally we would like to set util_dl as min/guaranteed freq and
>* util_cfs + util_dl as requested freq. However, cpufreq is not yet
>* ready for such an interface. So, we only do the latter for now.
>*/
> - return min(util, sg_cpu->max);
> + return min(sg_cpu->max, (sg_cpu->util_dl + sg_cpu->util_cfs));
>  }
>  
>  static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, 
> unsigned int flags)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/3] sched/cpufreq: always consider blocked FAIR utilization

On 10-05-18, 16:05, Patrick Bellasi wrote:
> Since the refactoring introduced by:
> 
>commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support")
> 
> we aggregate FAIR utilization only if this class has runnable tasks.
> This was mainly due to avoid the risk to stay on an high frequency just
> because of the blocked utilization of a CPU not being properly decayed
> while the CPU was idle.
> 
> However, since:
> 
>commit 31e77c93e432 ("sched/fair: Update blocked load when newly idle")
> 
> the FAIR blocked utilization is properly decayed also for IDLE CPUs.
> 
> This allows us to use the FAIR blocked utilization as a safe mechanism
> to gracefully reduce the frequency only if no FAIR tasks show up on a
> CPU for a reasonable period of time.
> 
> Moreover, we also reduce the frequency drops of CPUs running periodic
> tasks which, depending on the task periodicity and the time required
> for a frequency switch, was increasing the chances to introduce some
> undesirable performance variations.
> 
> Reported-by: Vincent Guittot 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Vincent Guittot 
> Cc: Viresh Kumar 
> Cc: Joel Fernandes 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/cpufreq_schedutil.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)

Do we need a Fixes tag and Cc stable ?

> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index d2c6083304b4..a74d05160e66 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -183,22 +183,21 @@ static void sugov_get_util(struct sugov_cpu *sg_cpu)
>  static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
>  {
>   struct rq *rq = cpu_rq(sg_cpu->cpu);
> - unsigned long util;
>  
> - if (rq->rt.rt_nr_running) {
> - util = sg_cpu->max;
> - } else {
> - util = sg_cpu->util_dl;
> - if (rq->cfs.h_nr_running)
> - util += sg_cpu->util_cfs;
> - }
> + if (rq->rt.rt_nr_running)
> + return sg_cpu->max;
>  
>   /*
> +  * Utilization required by DEADLINE must always be granted while, for
> +  * FAIR, we use blocked utilization of IDLE CPUs as a mechanism to
> +  * gracefully reduce the frequency when no tasks show up for longer
> +  * periods of time.
> +  *
>* Ideally we would like to set util_dl as min/guaranteed freq and
>* util_cfs + util_dl as requested freq. However, cpufreq is not yet
>* ready for such an interface. So, we only do the latter for now.
>*/
> - return min(util, sg_cpu->max);
> + return min(sg_cpu->max, (sg_cpu->util_dl + sg_cpu->util_cfs));
>  }
>  
>  static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, 
> unsigned int flags)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 3/3] sched/fair: schedutil: explicit update only when required

On 10-05-18, 16:05, Patrick Bellasi wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> -static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> sched_entity *se, int flags)
> +static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> sched_entity *se)
>  {
>   u32 divider = LOAD_AVG_MAX - 1024 + cfs_rq->avg.period_contrib;
>  
> @@ -3762,7 +3736,6 @@ static void attach_entity_load_avg(struct cfs_rq 
> *cfs_rq, struct sched_entity *s
>  
>   add_tg_cfs_propagate(cfs_rq, se->avg.load_sum);
>  
> - cfs_rq_util_change(cfs_rq, flags);

Was leaving a blank line at the end of routine intentional ?

>  }
>  
>  /**
> @@ -3781,7 +3754,6 @@ static void detach_entity_load_avg(struct cfs_rq 
> *cfs_rq, struct sched_entity *s
>  
>   add_tg_cfs_propagate(cfs_rq, -se->avg.load_sum);
>  
> - cfs_rq_util_change(cfs_rq, 0);

Here too.

>  }
-- 
viresh

[PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

2018-05-10 Thread Jagan Teki

Amarula A64 Relic is Allwinner A64 based IoT device, which support
- Allwinner A64 Cortex-A53
- Mali-400MP2 GPU
- AXP803 PMIC
- 1GB DDR3 RAM
- 8GB eMMC
- AP6330 Wifi/BLE
- MIPI-DSI
- CSI: OV5640 sensor
- USB OTG
- 12V DC power supply

Signed-off-by: Jagan Teki 
---
Changes for v2:
- Rename dts name to sun50i-a64-relic.dts which is simple to use
- Update dldo4 min voltage as 1.8
- Use licence year as 2018

 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts | 182 +
 2 files changed, 183 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index c31f90a49481..9b4417f00b68 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-relic.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-libretech-all-h3-cc.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo-plus2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts
new file mode 100644
index ..7dd6f8b03503
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "Amarula A64 Relic";
+   compatible = "amarula,a64-relic", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcdc1>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
+   };
+};
+
+#include "axp803.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "avdd-csi";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "vcc-pl";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-3v3";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <104>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_dcdc6 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-sys";
+};
+
+_dldo1 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-hdmi-dsi-sensor";
+};
+
+_dldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-mipi";
+};
+
+_dldo3 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "vcc-gen";
+};
+
+_dldo4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi-io";
+};
+
+_drivevbus {
+   regulator-name = "usb0-vbus";
+   status = "okay";
+};
+
+_eldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "cpvdd";
+};
+
+_fldo1 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vcc-1v2-hsic";
+};
+
+/*
+ * The A64

Re: [PATCH 3/3] sched/fair: schedutil: explicit update only when required

On 10-05-18, 16:05, Patrick Bellasi wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> -static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> sched_entity *se, int flags)
> +static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> sched_entity *se)
>  {
>   u32 divider = LOAD_AVG_MAX - 1024 + cfs_rq->avg.period_contrib;
>  
> @@ -3762,7 +3736,6 @@ static void attach_entity_load_avg(struct cfs_rq 
> *cfs_rq, struct sched_entity *s
>  
>   add_tg_cfs_propagate(cfs_rq, se->avg.load_sum);
>  
> - cfs_rq_util_change(cfs_rq, flags);

Was leaving a blank line at the end of routine intentional ?

>  }
>  
>  /**
> @@ -3781,7 +3754,6 @@ static void detach_entity_load_avg(struct cfs_rq 
> *cfs_rq, struct sched_entity *s
>  
>   add_tg_cfs_propagate(cfs_rq, -se->avg.load_sum);
>  
> - cfs_rq_util_change(cfs_rq, 0);

Here too.

>  }
-- 
viresh

[PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support

2018-05-10 Thread Jagan Teki

Amarula A64 Relic is Allwinner A64 based IoT device, which support
- Allwinner A64 Cortex-A53
- Mali-400MP2 GPU
- AXP803 PMIC
- 1GB DDR3 RAM
- 8GB eMMC
- AP6330 Wifi/BLE
- MIPI-DSI
- CSI: OV5640 sensor
- USB OTG
- 12V DC power supply

Signed-off-by: Jagan Teki 
---
Changes for v2:
- Rename dts name to sun50i-a64-relic.dts which is simple to use
- Update dldo4 min voltage as 1.8
- Use licence year as 2018

 arch/arm64/boot/dts/allwinner/Makefile |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts | 182 +
 2 files changed, 183 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
b/arch/arm64/boot/dts/allwinner/Makefile
index c31f90a49481..9b4417f00b68 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-relic.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-libretech-all-h3-cc.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo2.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-nanopi-neo-plus2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts
new file mode 100644
index ..7dd6f8b03503
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-relic.dts
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "Amarula A64 Relic";
+   compatible = "amarula,a64-relic", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcdc1>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp803: pmic@3a3 {
+   compatible = "x-powers,axp803";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
+   };
+};
+
+#include "axp803.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "avdd-csi";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "vcc-pl";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-3v3";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <104>;
+   regulator-max-microvolt = <130>;
+   regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_dcdc6 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-sys";
+};
+
+_dldo1 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-hdmi-dsi-sensor";
+};
+
+_dldo2 {
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-mipi";
+};
+
+_dldo3 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "vcc-gen";
+};
+
+_dldo4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi-io";
+};
+
+_drivevbus {
+   regulator-name = "usb0-vbus";
+   status = "okay";
+};
+
+_eldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "cpvdd";
+};
+
+_fldo1 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vcc-1v2-hsic";
+};
+
+/*
+ * The A64 chip cannot work without this regulator off, although
+

Re: [PATCH] idr: fix invalid ptr dereference on item delete

2018-05-10 Thread Dmitry Vyukov

On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini  wrote:
> On 10/05/2018 21:16, Roman Kagan wrote:
>> If an IDR contains a single entry at index==0, the underlying radix tree
>> has a single item in its root node, in which case
>> __radix_tree_lookup(index!=0) doesn't set its *@nodep argument (in
>> addition to returning NULL).
>>
>> However, the tree itself is not empty, i.e. the tree root doesn't have
>> IDR_FREE tag.
>>
>> As a result, on an attempt to remove an index!=0 entry from such an IDR,
>> radix_tree_delete_item doesn't return early and calls
>> __radix_tree_delete with invalid parameters which are then dereferenced.
>>
>> Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
>> Signed-off-by: Roman Kagan 
>> ---
>>  lib/radix-tree.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/radix-tree.c b/lib/radix-tree.c
>> index da9e10c827df..10ff1bfae952 100644
>> --- a/lib/radix-tree.c
>> +++ b/lib/radix-tree.c
>> @@ -2040,8 +2040,9 @@ void *radix_tree_delete_item(struct radix_tree_root 
>> *root,
>>   void *entry;
>>
>>   entry = __radix_tree_lookup(root, index, , );
>> - if (!entry && (!is_idr(root) || node_tag_get(root, node, IDR_FREE,
>> - get_slot_offset(node, slot
>> + if (!entry && (!is_idr(root) || !node ||
>> +node_tag_get(root, node, IDR_FREE,
>> + get_slot_offset(node, slot
>>   return NULL;
>>
>>   if (item && entry != item)
>>
>
> I cannot really vouch for the patch, but if it is correct it's
> definitely stuff for stable.  The KVM testcase is only for 4.17-rc but
> this is a really nasty bug in a core data structure.
>
> Cc: sta...@vger.kernel.org
>
> Should radix-tree be compilable in userspace, so that we can add unit
> tests for it?...

Good point.

For my education, what/where are the tests that run as user-space code?

Re: [PATCH] idr: fix invalid ptr dereference on item delete

2018-05-10 Thread Dmitry Vyukov

On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini  wrote:
> On 10/05/2018 21:16, Roman Kagan wrote:
>> If an IDR contains a single entry at index==0, the underlying radix tree
>> has a single item in its root node, in which case
>> __radix_tree_lookup(index!=0) doesn't set its *@nodep argument (in
>> addition to returning NULL).
>>
>> However, the tree itself is not empty, i.e. the tree root doesn't have
>> IDR_FREE tag.
>>
>> As a result, on an attempt to remove an index!=0 entry from such an IDR,
>> radix_tree_delete_item doesn't return early and calls
>> __radix_tree_delete with invalid parameters which are then dereferenced.
>>
>> Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
>> Signed-off-by: Roman Kagan 
>> ---
>>  lib/radix-tree.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/radix-tree.c b/lib/radix-tree.c
>> index da9e10c827df..10ff1bfae952 100644
>> --- a/lib/radix-tree.c
>> +++ b/lib/radix-tree.c
>> @@ -2040,8 +2040,9 @@ void *radix_tree_delete_item(struct radix_tree_root 
>> *root,
>>   void *entry;
>>
>>   entry = __radix_tree_lookup(root, index, , );
>> - if (!entry && (!is_idr(root) || node_tag_get(root, node, IDR_FREE,
>> - get_slot_offset(node, slot
>> + if (!entry && (!is_idr(root) || !node ||
>> +node_tag_get(root, node, IDR_FREE,
>> + get_slot_offset(node, slot
>>   return NULL;
>>
>>   if (item && entry != item)
>>
>
> I cannot really vouch for the patch, but if it is correct it's
> definitely stuff for stable.  The KVM testcase is only for 4.17-rc but
> this is a really nasty bug in a core data structure.
>
> Cc: sta...@vger.kernel.org
>
> Should radix-tree be compilable in userspace, so that we can add unit
> tests for it?...

Good point.

For my education, what/where are the tests that run as user-space code?

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

2018-05-10 Thread Finn Thain

On Fri, 11 May 2018, Michael Schmitz wrote:

> 
> I'm afraid using platform_device_register() (which you already use for 
> the SCC devices) is the only option handling this on a per-device basis 
> without touching platform core code, while at the same time keeping the 
> DMA mask setup out of device drivers

I don't think that will fly. If you call platform_device_register() and 
follow that with a dma mask assignment, you could race with the bus 
matching and driver probe, and we are back to the same WARNING message.

If you want to use platform_device_register(), you'd have to implement 
arch_setup_pdev_archdata() and use that to set up the dma mask.

> (I can see Geert's point there - device driver code might be shared 
> across implementations of the device on platforms with different DMA 
> mask requirements,, something the driver can't be expected to know 
> about).

As I said, these drivers might be expected to be portable between Macs and 
early PowerMacs, but the same dma mask would apply AFAIK.

If a platform driver isn't expected to be portable, I think either method 
is reasonable: arch_setup_pdev_archdata() or the method in the patch.

Anyway, there is this in arch/powerpc/kernel/setup-common.c:

void arch_setup_pdev_archdata(struct platform_device *pdev)
{
pdev->archdata.dma_mask = DMA_BIT_MASK(32);
pdev->dev.dma_mask = >archdata.dma_mask;
...

I'm inclined to propose something similar for m68k. That should fix the 
problem, since arch_setup_pdev_archdata() is already in the call chain:

platform_device_register_simple()
platform_device_register_resndata()
platform_device_register_full()
platform_device_alloc()
arch_setup_pdev_archdata()

Thoughts? Will this have nasty side effects for m68k platforms that use 
smaller dma masks?

-- 

> 
> Cheers,
> 
>   Michael
>

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

2018-05-10 Thread Finn Thain

On Fri, 11 May 2018, Michael Schmitz wrote:

> 
> I'm afraid using platform_device_register() (which you already use for 
> the SCC devices) is the only option handling this on a per-device basis 
> without touching platform core code, while at the same time keeping the 
> DMA mask setup out of device drivers

I don't think that will fly. If you call platform_device_register() and 
follow that with a dma mask assignment, you could race with the bus 
matching and driver probe, and we are back to the same WARNING message.

If you want to use platform_device_register(), you'd have to implement 
arch_setup_pdev_archdata() and use that to set up the dma mask.

> (I can see Geert's point there - device driver code might be shared 
> across implementations of the device on platforms with different DMA 
> mask requirements,, something the driver can't be expected to know 
> about).

As I said, these drivers might be expected to be portable between Macs and 
early PowerMacs, but the same dma mask would apply AFAIK.

If a platform driver isn't expected to be portable, I think either method 
is reasonable: arch_setup_pdev_archdata() or the method in the patch.

Anyway, there is this in arch/powerpc/kernel/setup-common.c:

void arch_setup_pdev_archdata(struct platform_device *pdev)
{
pdev->archdata.dma_mask = DMA_BIT_MASK(32);
pdev->dev.dma_mask = >archdata.dma_mask;
...

I'm inclined to propose something similar for m68k. That should fix the 
problem, since arch_setup_pdev_archdata() is already in the call chain:

platform_device_register_simple()
platform_device_register_resndata()
platform_device_register_full()
platform_device_alloc()
arch_setup_pdev_archdata()

Thoughts? Will this have nasty side effects for m68k platforms that use 
smaller dma masks?

-- 

> 
> Cheers,
> 
>   Michael
>

Re: [PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function

On Thu, May 10, 2018 at 06:18:33PM -0500, mike.tra...@hpe.com wrote:
> Add a new function to "adjust" the current fixed UV memory block size of
> 2GB so it can be changed to a different physical boundary.  This is out
> of necessity so UV BIOS can accommodate Intel BIOS changes for NVDIMM's,
> which can align these new PMEM modules at other than 2GB boundaries.
> 
> A "set order" type of function was used to insure that the memory block
> size will be a power of two value without requiring a validity check on
> the size value passed in.  64GB was chosen as the upper limit for memory
> block size values to accommodate upcoming 4PB systems which have 6 more
> bits of physical address space (46 becoming 52).
> 
> Signed-off-by: Mike Travis 
> Reviewed-by: Andrew Banman 
> ---
>  arch/x86/mm/init_64.c  |   20 
>  include/linux/memory.h |1 +
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function

On Thu, May 10, 2018 at 06:18:33PM -0500, mike.tra...@hpe.com wrote:
> Add a new function to "adjust" the current fixed UV memory block size of
> 2GB so it can be changed to a different physical boundary.  This is out
> of necessity so UV BIOS can accommodate Intel BIOS changes for NVDIMM's,
> which can align these new PMEM modules at other than 2GB boundaries.
> 
> A "set order" type of function was used to insure that the memory block
> size will be a power of two value without requiring a validity check on
> the size value passed in.  64GB was chosen as the upper limit for memory
> block size values to accommodate upcoming 4PB systems which have 6 more
> bits of physical address space (46 becoming 52).
> 
> Signed-off-by: Mike Travis 
> Reviewed-by: Andrew Banman 
> ---
>  arch/x86/mm/init_64.c  |   20 
>  include/linux/memory.h |1 +
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH 2/3] x86/platform/UV: Use new set memory block size function

On Thu, May 10, 2018 at 06:18:34PM -0500, mike.tra...@hpe.com wrote:
> Add a call to the new function to "adjust" the current fixed UV memory
> block size of 2GB so it can be changed to a different physical boundary.
> This accommodates changes in the Intel BIOS, and therefore UV BIOS, which
> now can align boundaries different than the previous UV standard of 2GB.
> It also flags any UV Mem boundaries that cause a change in the mem block
> size boundary.
> 
> Signed-off-by: Mike Travis 
> Reviewed-by: Andrew Banman 
> ---
>  arch/x86/kernel/apic/x2apic_uv_x.c |   49 
> ++---
>  1 file changed, 46 insertions(+), 3 deletions(-)
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH 2/3] x86/platform/UV: Use new set memory block size function

On Thu, May 10, 2018 at 06:18:34PM -0500, mike.tra...@hpe.com wrote:
> Add a call to the new function to "adjust" the current fixed UV memory
> block size of 2GB so it can be changed to a different physical boundary.
> This accommodates changes in the Intel BIOS, and therefore UV BIOS, which
> now can align boundaries different than the previous UV standard of 2GB.
> It also flags any UV Mem boundaries that cause a change in the mem block
> size boundary.
> 
> Signed-off-by: Mike Travis 
> Reviewed-by: Andrew Banman 
> ---
>  arch/x86/kernel/apic/x2apic_uv_x.c |   49 
> ++---
>  1 file changed, 46 insertions(+), 3 deletions(-)
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size

On Thu, May 10, 2018 at 06:18:35PM -0500, mike.tra...@hpe.com wrote:
> Add a kernel parameter that allows setting UV memory block size.  This
> is to provide an adjustment for new forms of PMEM and other DIMM memory
> that might require alignment restrictions other than scanning the global
> address table for the required minimum alignment.  The value set will be
> further adjusted by both the GAM range table scan as well as restrictions
> imposed by set_memory_block_size_order().
> 
> Signed-off-by: Mike Travis 
> Reviewed-by: Andrew Banman 
> ---
>  arch/x86/kernel/apic/x2apic_uv_x.c |   11 +++
>  1 file changed, 11 insertions(+)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

KASAN: use-after-free Read in cma_cancel_operation

We report the crash: KASAN: use-after-free Read in cma_cancel_operation

Note that this bug is previously reported by syzkaller.
https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b
Nonetheless, this bug has not fixed yet, and we hope that this report and our
analysis, which gets help by the RaceFuzzer's feature, will helpful to fix the
crash.

This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, write$rdma_cm and write$rdma_cm.


Analysis:
We think the concurrent execution of rdma_destroy_id() causes the crash.
The first execution of rdma_destroy_id() calls kfree(id_priv), and the
second execution of rdma_destry_id() dereferences the id_priv in
cma_cancel_listens(). Therefore use-after-free read occurs.
We observed that rdma_destroy_id() is called during the write$rdma_cm
syscall. After returing from vfs_write(), fput() is called and
ucma_close() is called as a pending work before returing to the user
space.


Thread interleaving:
CPU0 (rdma_destory_id)  CPU1 (rdma_destroy_id)
=   =
kfree(id_priv->id.route.path_rec);
put_net(id_priv->id.route.addr.dev_addr.net);
kfree(id_priv);
id_priv = 
container_of(id, struct rdma_id_private, id);
state = 
cma_exch(id_priv, RDMA_CM_DESTROYING);

cma_cancel_operation(id_priv, state);

(in cma_cancel_listens)

list_del(_priv->list);

Call Sequence:
Both CPU0 and CPU1
=
ucma_close
rdma_destroy_id


==
BUG: KASAN: use-after-free in __list_del_entry_valid+0x5c/0xc0 
lib/list_debug.c:54
Read of size 8 at addr 8801e86deca0 by task syz-executor0/3524

CPU: 1 PID: 3524 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x166/0x21c lib/dump_stack.c:113
 print_address_description+0x73/0x250 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x23f/0x360 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 __asan_load8+0x54/0x90 mm/kasan/kasan.c:699
 __list_del_entry_valid+0x5c/0xc0 lib/list_debug.c:54
 __list_del_entry include/linux/list.h:117 [inline]
 list_del include/linux/list.h:125 [inline]
 cma_cancel_listens drivers/infiniband/core/cma.c:1527 [inline]
 cma_cancel_operation+0x2d2/0x750 drivers/infiniband/core/cma.c:1555
 rdma_destroy_id+0xe9/0x760 drivers/infiniband/core/cma.c:1619
 ucma_close+0x9f/0x1c0 drivers/infiniband/core/ucma.c:1743
 __fput+0x22c/0x450 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x152/0x1b0 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x1387/0x1860 kernel/exit.c:865
 do_group_exit+0xfb/0x220 kernel/exit.c:968
 get_signal+0x5b7/0xf70 kernel/signal.c:2469
 do_signal+0x94/0xde0 arch/x86/kernel/signal.c:810
 exit_to_usermode_loop+0x1eb/0x270 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
 do_syscall_64+0x473/0x4a0 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4563f9
RSP: 002b:7fdd885d9ba8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX: fe00 RBX: 0072bfc8 RCX: 004563f9
RDX:  RSI:  RDI: 0072bfc8
RBP: 7fdd885d9bd0 R08:  R09: 0072bfa0
R10:  R11: 0246 R12: 0001
R13: 7fdd885d9c50 R14:  R15: 7fdd885da700

Allocated by task 3521:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xae/0xe0 mm/kasan/kasan.c:553
 kmem_cache_alloc_trace+0x136/0x740 mm/slab.c:3620
 kmalloc include/linux/slab.h:512 [inline]
 kzalloc include/linux/slab.h:701 [inline]
 __rdma_create_id+0xc5/0x450 drivers/infiniband/core/cma.c:751
 ucma_create_id+0x219/0x510 drivers/infiniband/core/ucma.c:485
 ucma_write+0x1d6/0x260 drivers/infiniband/core/ucma.c:1664
 __vfs_write+0xdd/0x480 fs/read_write.c:485
 vfs_write+0x12d/0x2d0 fs/read_write.c:549
 ksys_write+0xca/0x190 fs/read_write.c:598
 __do_sys_write fs/read_write.c:610 [inline]
 __se_sys_write fs/read_write.c:607 [inline]
 __x64_sys_write+0x43/0x50 fs/read_write.c:607
 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287

Re: [PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size

On Thu, May 10, 2018 at 06:18:35PM -0500, mike.tra...@hpe.com wrote:
> Add a kernel parameter that allows setting UV memory block size.  This
> is to provide an adjustment for new forms of PMEM and other DIMM memory
> that might require alignment restrictions other than scanning the global
> address table for the required minimum alignment.  The value set will be
> further adjusted by both the GAM range table scan as well as restrictions
> imposed by set_memory_block_size_order().
> 
> Signed-off-by: Mike Travis 
> Reviewed-by: Andrew Banman 
> ---
>  arch/x86/kernel/apic/x2apic_uv_x.c |   11 +++
>  1 file changed, 11 insertions(+)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

KASAN: use-after-free Read in cma_cancel_operation

We report the crash: KASAN: use-after-free Read in cma_cancel_operation

Note that this bug is previously reported by syzkaller.
https://syzkaller.appspot.com/bug?id=95f89b8fb9fdc42e28ad586e657fea074e4e719b
Nonetheless, this bug has not fixed yet, and we hope that this report and our
analysis, which gets help by the RaceFuzzer's feature, will helpful to fix the
crash.

This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, write$rdma_cm and write$rdma_cm.


Analysis:
We think the concurrent execution of rdma_destroy_id() causes the crash.
The first execution of rdma_destroy_id() calls kfree(id_priv), and the
second execution of rdma_destry_id() dereferences the id_priv in
cma_cancel_listens(). Therefore use-after-free read occurs.
We observed that rdma_destroy_id() is called during the write$rdma_cm
syscall. After returing from vfs_write(), fput() is called and
ucma_close() is called as a pending work before returing to the user
space.


Thread interleaving:
CPU0 (rdma_destory_id)  CPU1 (rdma_destroy_id)
=   =
kfree(id_priv->id.route.path_rec);
put_net(id_priv->id.route.addr.dev_addr.net);
kfree(id_priv);
id_priv = 
container_of(id, struct rdma_id_private, id);
state = 
cma_exch(id_priv, RDMA_CM_DESTROYING);

cma_cancel_operation(id_priv, state);

(in cma_cancel_listens)

list_del(_priv->list);

Call Sequence:
Both CPU0 and CPU1
=
ucma_close
rdma_destroy_id


==
BUG: KASAN: use-after-free in __list_del_entry_valid+0x5c/0xc0 
lib/list_debug.c:54
Read of size 8 at addr 8801e86deca0 by task syz-executor0/3524

CPU: 1 PID: 3524 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x166/0x21c lib/dump_stack.c:113
 print_address_description+0x73/0x250 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x23f/0x360 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 __asan_load8+0x54/0x90 mm/kasan/kasan.c:699
 __list_del_entry_valid+0x5c/0xc0 lib/list_debug.c:54
 __list_del_entry include/linux/list.h:117 [inline]
 list_del include/linux/list.h:125 [inline]
 cma_cancel_listens drivers/infiniband/core/cma.c:1527 [inline]
 cma_cancel_operation+0x2d2/0x750 drivers/infiniband/core/cma.c:1555
 rdma_destroy_id+0xe9/0x760 drivers/infiniband/core/cma.c:1619
 ucma_close+0x9f/0x1c0 drivers/infiniband/core/ucma.c:1743
 __fput+0x22c/0x450 fs/file_table.c:209
 fput+0x15/0x20 fs/file_table.c:243
 task_work_run+0x152/0x1b0 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x1387/0x1860 kernel/exit.c:865
 do_group_exit+0xfb/0x220 kernel/exit.c:968
 get_signal+0x5b7/0xf70 kernel/signal.c:2469
 do_signal+0x94/0xde0 arch/x86/kernel/signal.c:810
 exit_to_usermode_loop+0x1eb/0x270 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
 do_syscall_64+0x473/0x4a0 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4563f9
RSP: 002b:7fdd885d9ba8 EFLAGS: 0246 ORIG_RAX: 00ca
RAX: fe00 RBX: 0072bfc8 RCX: 004563f9
RDX:  RSI:  RDI: 0072bfc8
RBP: 7fdd885d9bd0 R08:  R09: 0072bfa0
R10:  R11: 0246 R12: 0001
R13: 7fdd885d9c50 R14:  R15: 7fdd885da700

Allocated by task 3521:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xae/0xe0 mm/kasan/kasan.c:553
 kmem_cache_alloc_trace+0x136/0x740 mm/slab.c:3620
 kmalloc include/linux/slab.h:512 [inline]
 kzalloc include/linux/slab.h:701 [inline]
 __rdma_create_id+0xc5/0x450 drivers/infiniband/core/cma.c:751
 ucma_create_id+0x219/0x510 drivers/infiniband/core/ucma.c:485
 ucma_write+0x1d6/0x260 drivers/infiniband/core/ucma.c:1664
 __vfs_write+0xdd/0x480 fs/read_write.c:485
 vfs_write+0x12d/0x2d0 fs/read_write.c:549
 ksys_write+0xca/0x190 fs/read_write.c:598
 __do_sys_write fs/read_write.c:610 [inline]
 __se_sys_write fs/read_write.c:607 [inline]
 __x64_sys_write+0x43/0x50 fs/read_write.c:607
 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287

Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

On Thu, May 10, 2018 at 06:18:32PM -0500, mike.tra...@hpe.com wrote:
> 
> Update support for the UV kernel to accommodate Intel BIOS changes in
> NVDIMM alignment, which caused UV BIOS to align the memory boundaries
> on different blocks than the previous UV standard of 2GB.
> 
> -- 

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

On Thu, May 10, 2018 at 06:18:32PM -0500, mike.tra...@hpe.com wrote:
> 
> Update support for the UV kernel to accommodate Intel BIOS changes in
> NVDIMM alignment, which caused UV BIOS to align the memory boundaries
> on different blocks than the previous UV standard of 2GB.
> 
> -- 

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

KASAN: null-ptr-deref Read in rds_ib_get_mr

We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr

Note that this bug is previously reported by syzkaller.
https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91
Nonetheless, this bug has not fixed yet, and we hope that this report and our
analysis, which gets help by the RaceFuzzer's feature, will helpful to fix the
crash.

This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, bind$rds and setsockopt$RDS_GET_MR.


Analysis:
We think the concurrent execution of __rds_rdma_map() and rds_bind()
causes the problem. __rds_rdma_map() checks whether rs->rs_bound_addr is 0
or not. But the concurrent execution with rds_bind() can by-pass this
check. Therefore, __rds_rdmap_map() calls rs->rs_transport->get_mr() and
rds_ib_get_mr() causes the null deref at ib_rdma.c:544 in v4.17-rc1, when
dereferencing rs_conn.


Thread interleaving:
CPU0 (__rds_rdma_map)   CPU1 (rds_bind)
// rds_add_bound() sets 
rs->bound_addr as none 0
ret = rds_add_bound(rs, 
sin->sin_addr.s_addr, >sin_port);
if (rs->rs_bound_addr == 0 || !rs->rs_transport) {
ret = -ENOTCONN; /* XXX not a great errno */
goto out;
}
if (rs->rs_transport) { 
/* previously bound */
trans = 
rs->rs_transport;
if 
(trans->laddr_check(sock_net(sock->sk),

   sin->sin_addr.s_addr) != 0) {
ret = 
-ENOPROTOOPT;
// 
rds_remove_bound() sets rs->bound_addr as 0

rds_remove_bound(rs);
...
trans_private = rs->rs_transport->get_mr(sg, nents, rs,
 >r_key);
(in rds_ib_get_mr())
struct rds_ib_connection *ic = rs->rs_conn->c_transport_data;


Call sequence (v4.17-rc1):
CPU0
rds_setsockopt
rds_get_mr
__rds_rdma_map
rds_ib_get_mr


CPU1
rds_bind
rds_add_bound
...
rds_remove_bound


Crash log:
==
BUG: KASAN: null-ptr-deref in rds_ib_get_mr+0x3a/0x150 net/rds/ib_rdma.c:544
Read of size 8 at addr 0068 by task syz-executor0/32067

CPU: 0 PID: 32067 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x166/0x21c lib/dump_stack.c:113
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report+0x140/0x360 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 __asan_load8+0x54/0x90 mm/kasan/kasan.c:699
 rds_ib_get_mr+0x3a/0x150 net/rds/ib_rdma.c:544
 __rds_rdma_map+0x521/0x9d0 net/rds/rdma.c:271
 rds_get_mr+0xad/0xf0 net/rds/rdma.c:333
 rds_setsockopt+0x57f/0x720 net/rds/af_rds.c:347
 __sys_setsockopt+0x147/0x230 net/socket.c:1903
 __do_sys_setsockopt net/socket.c:1914 [inline]
 __se_sys_setsockopt net/socket.c:1911 [inline]
 __x64_sys_setsockopt+0x67/0x80 net/socket.c:1911
 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4563f9
RSP: 002b:7f6a2b3c2b28 EFLAGS: 0246 ORIG_RAX: 0036
RAX: ffda RBX: 0072bee0 RCX: 004563f9
RDX: 0002 RSI: 0114 RDI: 0015
RBP: 0575 R08: 0020 R09: 
R10: 2140 R11: 0246 R12: 7f6a2b3c36d4
R13:  R14: 006fd398 R15: 
==


= About RaceFuzzer

RaceFuzzer is a customized version of Syzkaller, specifically tailored
to find race condition bugs in the Linux kernel. While we leverage
many different technique, the notable feature of RaceFuzzer is in
leveraging a custom hypervisor (QEMU/KVM) to interleave the
scheduling. In particular, we modified the hypervisor to intentionally
stall a per-core execution, which is similar to supporting per-core
breakpoint functionality. This allows RaceFuzzer to force the kernel
to deterministically trigger racy condition (which may rarely happen
in practice due to randomness in scheduling).

RaceFuzzer's C repro always pinpoints two racy syscalls. Since C
repro's scheduling synchronization should be performed at the

KASAN: null-ptr-deref Read in rds_ib_get_mr

We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr

Note that this bug is previously reported by syzkaller.
https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91
Nonetheless, this bug has not fixed yet, and we hope that this report and our
analysis, which gets help by the RaceFuzzer's feature, will helpful to fix the
crash.

This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
version of Syzkaller), which we describe more at the end of this
report. Our analysis shows that the race occurs when invoking two
syscalls concurrently, bind$rds and setsockopt$RDS_GET_MR.


Analysis:
We think the concurrent execution of __rds_rdma_map() and rds_bind()
causes the problem. __rds_rdma_map() checks whether rs->rs_bound_addr is 0
or not. But the concurrent execution with rds_bind() can by-pass this
check. Therefore, __rds_rdmap_map() calls rs->rs_transport->get_mr() and
rds_ib_get_mr() causes the null deref at ib_rdma.c:544 in v4.17-rc1, when
dereferencing rs_conn.


Thread interleaving:
CPU0 (__rds_rdma_map)   CPU1 (rds_bind)
// rds_add_bound() sets 
rs->bound_addr as none 0
ret = rds_add_bound(rs, 
sin->sin_addr.s_addr, >sin_port);
if (rs->rs_bound_addr == 0 || !rs->rs_transport) {
ret = -ENOTCONN; /* XXX not a great errno */
goto out;
}
if (rs->rs_transport) { 
/* previously bound */
trans = 
rs->rs_transport;
if 
(trans->laddr_check(sock_net(sock->sk),

   sin->sin_addr.s_addr) != 0) {
ret = 
-ENOPROTOOPT;
// 
rds_remove_bound() sets rs->bound_addr as 0

rds_remove_bound(rs);
...
trans_private = rs->rs_transport->get_mr(sg, nents, rs,
 >r_key);
(in rds_ib_get_mr())
struct rds_ib_connection *ic = rs->rs_conn->c_transport_data;


Call sequence (v4.17-rc1):
CPU0
rds_setsockopt
rds_get_mr
__rds_rdma_map
rds_ib_get_mr


CPU1
rds_bind
rds_add_bound
...
rds_remove_bound


Crash log:
==
BUG: KASAN: null-ptr-deref in rds_ib_get_mr+0x3a/0x150 net/rds/ib_rdma.c:544
Read of size 8 at addr 0068 by task syz-executor0/32067

CPU: 0 PID: 32067 Comm: syz-executor0 Not tainted 4.17.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x166/0x21c lib/dump_stack.c:113
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report+0x140/0x360 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 __asan_load8+0x54/0x90 mm/kasan/kasan.c:699
 rds_ib_get_mr+0x3a/0x150 net/rds/ib_rdma.c:544
 __rds_rdma_map+0x521/0x9d0 net/rds/rdma.c:271
 rds_get_mr+0xad/0xf0 net/rds/rdma.c:333
 rds_setsockopt+0x57f/0x720 net/rds/af_rds.c:347
 __sys_setsockopt+0x147/0x230 net/socket.c:1903
 __do_sys_setsockopt net/socket.c:1914 [inline]
 __se_sys_setsockopt net/socket.c:1911 [inline]
 __x64_sys_setsockopt+0x67/0x80 net/socket.c:1911
 do_syscall_64+0x15f/0x4a0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4563f9
RSP: 002b:7f6a2b3c2b28 EFLAGS: 0246 ORIG_RAX: 0036
RAX: ffda RBX: 0072bee0 RCX: 004563f9
RDX: 0002 RSI: 0114 RDI: 0015
RBP: 0575 R08: 0020 R09: 
R10: 2140 R11: 0246 R12: 7f6a2b3c36d4
R13:  R14: 006fd398 R15: 
==


= About RaceFuzzer

RaceFuzzer is a customized version of Syzkaller, specifically tailored
to find race condition bugs in the Linux kernel. While we leverage
many different technique, the notable feature of RaceFuzzer is in
leveraging a custom hypervisor (QEMU/KVM) to interleave the
scheduling. In particular, we modified the hypervisor to intentionally
stall a per-core execution, which is similar to supporting per-core
breakpoint functionality. This allows RaceFuzzer to force the kernel
to deterministically trigger racy condition (which may rarely happen
in practice due to randomness in scheduling).

RaceFuzzer's C repro always pinpoints two racy syscalls. Since C
repro's scheduling synchronization should be performed at the

Re: [PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available

"Alastair D'Silva"  writes:

> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 8d2748e69c84..bb80f294b429 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
>  #define OCXL_IOCTL_IRQ_SET_FD_IOW(OCXL_MAGIC, 0x13, struct 
> ocxl_ioctl_irq_fd)
>  #define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct 
> ocxl_ioctl_metadata)
>  #define OCXL_IOCTL_ENABLE_P9_WAIT_IOR(OCXL_MAGIC, 0x15, struct 
> ocxl_ioctl_p9_wait)
> +#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
> ocxl_ioctl_platform)

I don't have ocxl_ioctl_platform ?

../include/uapi/misc/ocxl.h:78:56: error: invalid application of ‘sizeof’ to 
incomplete type ‘struct ocxl_ioctl_platform’
 #define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
ocxl_ioctl_platform)
^
../include/uapi/asm-generic/ioctl.h:73:5: note: in definition of macro ‘_IOC’
   ((size) << _IOC_SIZESHIFT))
 ^~~~
../include/uapi/asm-generic/ioctl.h:86:56: note: in expansion of macro 
‘_IOC_TYPECHECK’
 #define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
^~
../include/uapi/misc/ocxl.h:78:33: note: in expansion of macro ‘_IOR’
 #define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
ocxl_ioctl_platform)
 ^~~~
../drivers/misc/ocxl/file.c:262:7: note: in expansion of macro 
‘OCXL_IOCTL_GET_FEATURES’
  case OCXL_IOCTL_GET_FEATURES:
   ^~~

cheers

Re: [PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available

"Alastair D'Silva"  writes:

> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 8d2748e69c84..bb80f294b429 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
>  #define OCXL_IOCTL_IRQ_SET_FD_IOW(OCXL_MAGIC, 0x13, struct 
> ocxl_ioctl_irq_fd)
>  #define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct 
> ocxl_ioctl_metadata)
>  #define OCXL_IOCTL_ENABLE_P9_WAIT_IOR(OCXL_MAGIC, 0x15, struct 
> ocxl_ioctl_p9_wait)
> +#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
> ocxl_ioctl_platform)

I don't have ocxl_ioctl_platform ?

../include/uapi/misc/ocxl.h:78:56: error: invalid application of ‘sizeof’ to 
incomplete type ‘struct ocxl_ioctl_platform’
 #define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
ocxl_ioctl_platform)
^
../include/uapi/asm-generic/ioctl.h:73:5: note: in definition of macro ‘_IOC’
   ((size) << _IOC_SIZESHIFT))
 ^~~~
../include/uapi/asm-generic/ioctl.h:86:56: note: in expansion of macro 
‘_IOC_TYPECHECK’
 #define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
^~
../include/uapi/misc/ocxl.h:78:33: note: in expansion of macro ‘_IOR’
 #define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct 
ocxl_ioctl_platform)
 ^~~~
../drivers/misc/ocxl/file.c:262:7: note: in expansion of macro 
‘OCXL_IOCTL_GET_FEATURES’
  case OCXL_IOCTL_GET_FEATURES:
   ^~~

cheers

Re: nds32 build failures

2018-05-10 Thread Kito Cheng

Hi Arnd:

I am GCC guy from Andes, we've missed the release schedule for GCC 8,
we didn't upstream the Linux support on time.

Our plan is put our GCC 8 on github and continue commit rest patches
to upstream.
And we'll put our source on github after our internal testing done.

Thanks.

On Fri, May 11, 2018 at 10:40 AM, Arnd Bergmann  wrote:
> On Wed, Apr 18, 2018 at 3:19 AM, Greentime Hu  wrote:
>> 2018-04-17 20:47 GMT+08:00 Arnd Bergmann :
>>> On Mon, Apr 16, 2018 at 11:06 AM, Greentime Hu  wrote:
 2018-04-16 11:58 GMT+08:00 Guenter Roeck :

 This built failure is because the toolchain version you used is not
 supported the latest intrinsic function/macro.
 We are sending the latest patchset now and we expect the whole new
 features will be supported in gcc8.0.0 and binutil2.31+.

 If you'd like to get these new features of toolchain, you may use the
 github version.
 This is the built-script repo. 
 https://github.com/andestech/build_script.git
>>>
>>> I've taken the gcc-6.3 sources from there, and updated them to gcc-6.4.0
>>> in order to build a nds32le-linux toolchain based on the same version as
>>> the other ones.
>>>
>>> Unfortunately neither the usual binutils-2.29.1 nor your binutils worked
>>> for me, but I eventually managed to get a build using the binutils-2.30
>>> release.
>>>
>>> With this, I could build a mainline kernel with a couple of warnings,
>>> but an 'allmodconfig' build still failed.
>>>
>>> Guenter, can you try my binary from
>>> www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/x86_64-gcc-6.4.0-nolibc-nds32le-linux.tar.xz
>>> ?
>>>
>>> If that works for you, I'll update the front-page and remove the nds32-elf
>>> toolchains.
>>>
>>> Greentime, do you have a patch set for gcc-7.3 as well, or are 6.3 and 8.0 
>>> the
>>> only working compilers for nds32le-linux?
>>>
>>
>> Hi, all:
>>
>> I just discuss with our toolchain colleagues. We have only gcc6.3 and
>> gcc8.0 for nds32le-linux.
>> I have the ld segmentation fault issue too when building kernel with
>> 'allmodconfig'. We are dealing with it.
>
> I've tried building the mainline gcc-8.1 sources for nds32le-linux and
> still got a failure with those (building gcc), building a nds32le-elf 
> gcc-8.1.0
> worked fine, but that fails to build the vdso (no support for -fPIC), so
> it's again unusable for building kernels. Any other ideas?
>
>   Arnd

Re: nds32 build failures

2018-05-10 Thread Kito Cheng

Hi Arnd:

I am GCC guy from Andes, we've missed the release schedule for GCC 8,
we didn't upstream the Linux support on time.

Our plan is put our GCC 8 on github and continue commit rest patches
to upstream.
And we'll put our source on github after our internal testing done.

Thanks.

On Fri, May 11, 2018 at 10:40 AM, Arnd Bergmann  wrote:
> On Wed, Apr 18, 2018 at 3:19 AM, Greentime Hu  wrote:
>> 2018-04-17 20:47 GMT+08:00 Arnd Bergmann :
>>> On Mon, Apr 16, 2018 at 11:06 AM, Greentime Hu  wrote:
 2018-04-16 11:58 GMT+08:00 Guenter Roeck :

 This built failure is because the toolchain version you used is not
 supported the latest intrinsic function/macro.
 We are sending the latest patchset now and we expect the whole new
 features will be supported in gcc8.0.0 and binutil2.31+.

 If you'd like to get these new features of toolchain, you may use the
 github version.
 This is the built-script repo. 
 https://github.com/andestech/build_script.git
>>>
>>> I've taken the gcc-6.3 sources from there, and updated them to gcc-6.4.0
>>> in order to build a nds32le-linux toolchain based on the same version as
>>> the other ones.
>>>
>>> Unfortunately neither the usual binutils-2.29.1 nor your binutils worked
>>> for me, but I eventually managed to get a build using the binutils-2.30
>>> release.
>>>
>>> With this, I could build a mainline kernel with a couple of warnings,
>>> but an 'allmodconfig' build still failed.
>>>
>>> Guenter, can you try my binary from
>>> www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/x86_64-gcc-6.4.0-nolibc-nds32le-linux.tar.xz
>>> ?
>>>
>>> If that works for you, I'll update the front-page and remove the nds32-elf
>>> toolchains.
>>>
>>> Greentime, do you have a patch set for gcc-7.3 as well, or are 6.3 and 8.0 
>>> the
>>> only working compilers for nds32le-linux?
>>>
>>
>> Hi, all:
>>
>> I just discuss with our toolchain colleagues. We have only gcc6.3 and
>> gcc8.0 for nds32le-linux.
>> I have the ld segmentation fault issue too when building kernel with
>> 'allmodconfig'. We are dealing with it.
>
> I've tried building the mainline gcc-8.1 sources for nds32le-linux and
> still got a failure with those (building gcc), building a nds32le-elf 
> gcc-8.1.0
> worked fine, but that fails to build the vdso (no support for -fPIC), so
> it's again unusable for building kernels. Any other ideas?
>
>   Arnd

Re: [PATCH v3 02/14] drivers: soc: sunxi: Add dedicated compatibles for the A13, A20 and A33

On Mon, May 7, 2018 at 5:44 AM, Paul Kocialkowski
 wrote:
> This introduces platform-specific compatibles for the A13, A20 and A33
> SRAM driver. No particular adaptation for these platforms is required at
> this point, although this might become the case in the future.
>
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/soc/sunxi/sunxi_sram.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
> index 74cb81f37bd6..43ebc3bd33f2 100644
> --- a/drivers/soc/sunxi/sunxi_sram.c
> +++ b/drivers/soc/sunxi/sunxi_sram.c
> @@ -315,6 +315,9 @@ static int sunxi_sram_probe(struct platform_device *pdev)
>
>  static const struct of_device_id sunxi_sram_dt_match[] = {
> { .compatible = "allwinner,sun4i-a10-sram-controller" },
> +   { .compatible = "allwinner,sun5i-a13-sram-controller" },
> +   { .compatible = "allwinner,sun7i-a20-sram-controller" },
> +   { .compatible = "allwinner,sun8i-a33-sram-controller" },

We should probably name these "system-controller". Maxime?

ChenYu

> { .compatible = "allwinner,sun50i-a64-sram-controller" },
> { },
>  };
> --
> 2.16.3
>

Re: [PATCH v3 02/14] drivers: soc: sunxi: Add dedicated compatibles for the A13, A20 and A33

On Mon, May 7, 2018 at 5:44 AM, Paul Kocialkowski
 wrote:
> This introduces platform-specific compatibles for the A13, A20 and A33
> SRAM driver. No particular adaptation for these platforms is required at
> this point, although this might become the case in the future.
>
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/soc/sunxi/sunxi_sram.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
> index 74cb81f37bd6..43ebc3bd33f2 100644
> --- a/drivers/soc/sunxi/sunxi_sram.c
> +++ b/drivers/soc/sunxi/sunxi_sram.c
> @@ -315,6 +315,9 @@ static int sunxi_sram_probe(struct platform_device *pdev)
>
>  static const struct of_device_id sunxi_sram_dt_match[] = {
> { .compatible = "allwinner,sun4i-a10-sram-controller" },
> +   { .compatible = "allwinner,sun5i-a13-sram-controller" },
> +   { .compatible = "allwinner,sun7i-a20-sram-controller" },
> +   { .compatible = "allwinner,sun8i-a33-sram-controller" },

We should probably name these "system-controller". Maxime?

ChenYu

> { .compatible = "allwinner,sun50i-a64-sram-controller" },
> { },
>  };
> --
> 2.16.3
>

Re: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to

2018-05-10 Thread Chris Moore


Hi,

Le 04/05/2018 à 04:09, Wan, Jane (Nokia - US/Sunnyvale) a écrit

The following is the reposting of patch with v2 version indication based on comment on 
"[PATCH 1/2]" (also in the attachment).

Subject: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to
  recover the contents of ONFI parameter

Per ONFI specification (Rev. 4.0), if all parameter pages have invalid
CRC values, the bit-wise majority may be used to recover the contents of
the parameter pages from the parameter page copies present.

Signed-off-by: Jane Wan 
---
  drivers/mtd/nand/raw/nand_base.c |   36 ++--
  1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..464c4fb 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c


[snip]

  
+		pr_info("Recover ONFI params with bit-wise majority\n");

+   for (j = 0; j < pagesize; j++) {
+   v = 0;
+   for (k = 0; k < 8; k++) {
+   m = 0;
+   for (l = 0; l < 3; l++)
+   m += GET_BIT(k, buf[l*pagesize + j]);
+   if (m > 1)
+   v |= BIT(k);
+   }
+   ((u8 *)p)[j] = v;
+   }


I am not familiar with the context of this but the three way bit-wise 
majority can be implemented much more efficiently  using the identity:

majority3(a, b, c) = (a & b) | (a & c) | (b & c)
This can be factorized slightly to (a & (b | c)) | (b & c)
This enables the operation to be performed 8, 16, 32 or even 64 bits at 
a time depending on the hardware.


Cheers,
Chris

Re: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to

2018-05-10 Thread Chris Moore


Hi,

Le 04/05/2018 à 04:09, Wan, Jane (Nokia - US/Sunnyvale) a écrit

The following is the reposting of patch with v2 version indication based on comment on 
"[PATCH 1/2]" (also in the attachment).

Subject: [PATCH v2 2/2] mtd: rawnand: fsl_ifc: use bit-wise majority to
  recover the contents of ONFI parameter

Per ONFI specification (Rev. 4.0), if all parameter pages have invalid
CRC values, the bit-wise majority may be used to recover the contents of
the parameter pages from the parameter page copies present.

Signed-off-by: Jane Wan 
---
  drivers/mtd/nand/raw/nand_base.c |   36 ++--
  1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..464c4fb 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c


[snip]

  
+		pr_info("Recover ONFI params with bit-wise majority\n");

+   for (j = 0; j < pagesize; j++) {
+   v = 0;
+   for (k = 0; k < 8; k++) {
+   m = 0;
+   for (l = 0; l < 3; l++)
+   m += GET_BIT(k, buf[l*pagesize + j]);
+   if (m > 1)
+   v |= BIT(k);
+   }
+   ((u8 *)p)[j] = v;
+   }


I am not familiar with the context of this but the three way bit-wise 
majority can be implemented much more efficiently  using the identity:

majority3(a, b, c) = (a & b) | (a & c) | (b & c)
This can be factorized slightly to (a & (b | c)) | (b & c)
This enables the operation to be performed 8, 16, 32 or even 64 bits at 
a time depending on the hardware.


Cheers,
Chris

Re: [PATCH v3 5/7] ocxl: Expose the thread_id needed for wait on POWER9

"Alastair D'Silva"  writes:
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 0af83d80fb3e..8d2748e69c84 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
>   __u64 reserved[13]; // Total of 16*u64
>  };
>  
> +struct ocxl_ioctl_p9_wait {
> + __u16 thread_id; // The thread ID required to wake this thread
> + __u16 reserved1;
> + __u32 reserved2;
> + __u64 reserved3[3];
> +};
> +
> +};
> +

O_o

???

cheers

Re: [PATCH v3 5/7] ocxl: Expose the thread_id needed for wait on POWER9

"Alastair D'Silva"  writes:
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 0af83d80fb3e..8d2748e69c84 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -48,6 +48,15 @@ struct ocxl_ioctl_metadata {
>   __u64 reserved[13]; // Total of 16*u64
>  };
>  
> +struct ocxl_ioctl_p9_wait {
> + __u16 thread_id; // The thread ID required to wake this thread
> + __u16 reserved1;
> + __u32 reserved2;
> + __u64 reserved3[3];
> +};
> +
> +};
> +

O_o

???

cheers

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

2018-05-10 Thread Mimi Zohar

On Thu, 2018-05-10 at 23:26 +, Luis R. Rodriguez wrote:
> On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote:
> > On Wed, 2018-05-09 at 23:48 +, Luis R. Rodriguez wrote:
> > > On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote:
> > 
> > > > > > Yes, writing regdb as a micro/mini LSM sounds reasonable.  The LSM
> > > > > > would differentiate between other firmware and the regulatory.db 
> > > > > > based
> > > > > > on the firmware's pathname.
> > > > > 
> > > > > If that is the only way then it would be silly to do the mini LSM as 
> > > > > all
> > > > > calls would have to have the check. A special LSM hook for just the
> > > > > regulatory db also doesn't make much sense.
> > > > 
> > > > All calls to request_firmware() are already going through this LSM
> > > > hook.  I should have said, it would be based on both READING_FIRMWARE
> > > > and the firmware's pathname.
> > > 
> > > Yes, but it would still be a strcmp() computation added for all
> > > READING_FIRMWARE. In that sense, the current arrangement is only open 
> > > coding the
> > > signature verification for the regulatory.db file.  One way to avoid this 
> > > would
> > > be to add an LSM specific to the regulatory db
> > 
> > Casey already commented on this suggestion.
> 
> Sorry but I must have missed this, can you send me the email or URL where he 
> did that?
> I never got a copy of that email I think.

My mistake.  I've posted similar patches for kexec_load and for the
firmware sysfs fallback, both call security_kernel_read_file().
Casey's comment was in regards to kexec_load[1], not for the sysfs
fallback mode.  Here's the link to the most recent version of the
kexec_load patches.[2]

[1] 
http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006690.html
[2] 
http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006854.html

Mimi

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

2018-05-10 Thread Mimi Zohar

On Thu, 2018-05-10 at 23:26 +, Luis R. Rodriguez wrote:
> On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote:
> > On Wed, 2018-05-09 at 23:48 +, Luis R. Rodriguez wrote:
> > > On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote:
> > 
> > > > > > Yes, writing regdb as a micro/mini LSM sounds reasonable.  The LSM
> > > > > > would differentiate between other firmware and the regulatory.db 
> > > > > > based
> > > > > > on the firmware's pathname.
> > > > > 
> > > > > If that is the only way then it would be silly to do the mini LSM as 
> > > > > all
> > > > > calls would have to have the check. A special LSM hook for just the
> > > > > regulatory db also doesn't make much sense.
> > > > 
> > > > All calls to request_firmware() are already going through this LSM
> > > > hook.  I should have said, it would be based on both READING_FIRMWARE
> > > > and the firmware's pathname.
> > > 
> > > Yes, but it would still be a strcmp() computation added for all
> > > READING_FIRMWARE. In that sense, the current arrangement is only open 
> > > coding the
> > > signature verification for the regulatory.db file.  One way to avoid this 
> > > would
> > > be to add an LSM specific to the regulatory db
> > 
> > Casey already commented on this suggestion.
> 
> Sorry but I must have missed this, can you send me the email or URL where he 
> did that?
> I never got a copy of that email I think.

My mistake.  I've posted similar patches for kexec_load and for the
firmware sysfs fallback, both call security_kernel_read_file().
Casey's comment was in regards to kexec_load[1], not for the sysfs
fallback mode.  Here's the link to the most recent version of the
kexec_load patches.[2]

[1] 
http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006690.html
[2] 
http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006854.html

Mimi

RE: [PATCH v2] z3fold: fix reclaim lock-ups

2018-05-10 Thread Jongseok Kim

A headless page also need to be set UNDER_RECLAIM in previous
reply, but I missed it.

---
 mm/z3fold.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index 5f659ab..8536a47 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -849,10 +849,10 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, 
unsigned int retries)
kref_get(>refcount);
list_del_init(>buddy);
zhdr->cpu = -1;
-   set_bit(UNDER_RECLAIM, >private);
break;
}
 
+   set_bit(UNDER_RECLAIM, >private);
list_del_init(>lru);
spin_unlock(>lock);
 
@@ -899,6 +899,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, 
unsigned int retries)
}
 next:
if (test_bit(PAGE_HEADLESS, >private)) {
+   clear_bit(UNDER_RECLAIM, >private);
if (ret == 0) {
free_z3fold_page(page);
atomic64_dec(>pages_nr);
-- 
2.7.4

RE: [PATCH v2] z3fold: fix reclaim lock-ups

2018-05-10 Thread Jongseok Kim

A headless page also need to be set UNDER_RECLAIM in previous
reply, but I missed it.

---
 mm/z3fold.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index 5f659ab..8536a47 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -849,10 +849,10 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, 
unsigned int retries)
kref_get(>refcount);
list_del_init(>buddy);
zhdr->cpu = -1;
-   set_bit(UNDER_RECLAIM, >private);
break;
}
 
+   set_bit(UNDER_RECLAIM, >private);
list_del_init(>lru);
spin_unlock(>lock);
 
@@ -899,6 +899,7 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, 
unsigned int retries)
}
 next:
if (test_bit(PAGE_HEADLESS, >private)) {
+   clear_bit(UNDER_RECLAIM, >private);
if (ret == 0) {
free_z3fold_page(page);
atomic64_dec(>pages_nr);
-- 
2.7.4

[git pull] drm fixes for v4.17-rc5

2018-05-10 Thread Dave Airlie

Hi Linus,

As last week seemed a bit slow, we got a few more fixes this week.

The main stuff is 2 weeks of fixes for amdgpu, some missing bits of
vega12 atom firmware support were added, and some power management
fixes.

Nouveau got two regression fixes for an DP MST deadlock and a random oops fix.

i915 got an LVDS panel timeout fix 2 WARN fixes.

exynos fixed a pagefault issue in the mixer driver.

vc4 has an oops fix.

omap had a bunch of uninit var and error-checking fixes.
Two atomic modesetting state fixes.

One minor agp cleanup patch

Regards,
Dave.

The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:

  Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc5

for you to fetch changes up to 72777fe79768ec30ac2163d26de68a89edc9849f:

  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-05-11
10:37:17 +1000)


nouveau, amdgpu, i915, vc4, omap, exynos and atomic fixes


Andrey Grodzovsky (1):
  drm/amdgpu: Switch to interruptable wait to recover from ring hang.

Andrzej Hajda (2):
  drm/exynos/mixer: fix synchronization check in interlaced mode
  drm/bridge/sii8620: add Kconfig dependency on extcon

Ben Skeggs (1):
  drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive client

Boris Brezillon (1):
  drm/vc4: Fix scaling of uni-planar formats

Dan Carpenter (1):
  drm/omap: silence unititialized variable warning

Dave Airlie (6):
  Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge tag 'drm-intel-fixes-2018-05-09' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2018-05-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'linux-4.17' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Eric Anholt (1):
  drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

Florent Flament (1):
  drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

Harry Wentland (3):
  drm/amd/display: Add VG12 ASIC IDs
  drm/amd/display: Add get_firmware_info_v3_2 for VG12
  drm/amd/display: Don't return ddc result and read_bytes in same
return value

Jerry (Fangzhi) Zuo (1):
  drm/amd: Add BIOS smu_info v3_3 required struct def.

Lyude Paul (1):
  drm/nouveau: Fix deadlock in nv50_mstm_register_connector()

Mathieu Malaterre (1):
  agp: uninorth: make two functions static

Michel Dänzer (2):
  drm/amd/display: Use kvzalloc for potentially large allocations
  drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages

Peter Rosin (1):
  drm/exynos: hdmi: avoid duplicating drm_bridge_attach

Rex Zhu (2):
  drm/amd/pp: Refine the output of pp_power_profile_mode on VI
  drm/amd/pp: Fix performance drop on Fiji

Rodrigo Vivi (1):
  drm/i915: Adjust eDP's logical vco in a reliable place.

Tobias Jakobi (1):
  drm/exynos: mixer: avoid Oops in vp_video_buffer()

Tomi Valkeinen (6):
  drm/omap: fix uninitialized ret variable
  drm/omap: fix possible NULL ref issue in tiler_reserve_2d
  drm/omap: check return value from soc_device_match
  drm/omap: handle error if scale coefs are not found
  drm/omap: add missing linefeeds to prints
  drm/omap: handle alloc failures in omap_connector

Ville Syrjälä (3):
  drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()
  drm/atomic: Clean private obj old_state/new_state in
drm_atomic_state_default_clear()
  drm/i915: Correctly populate user mode h/vdisplay with pipe src
size during readout

 drivers/char/agp/uninorth-agp.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|   6 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  20 ++-
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c |  86 ++-
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  |  10 +-
 drivers/gpu/drm/amd/display/dc/core/dc_surface.c   |  14 +-
 drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h   |   5 +-
 drivers/gpu/drm/amd/display/include/dal_asic_id.h  |   9 +-
 .../drm/amd/display/modules/color/color_gamma.c|  72 -
 drivers/gpu/drm/amd/include/atomfirmware.h | 170 -
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  52 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h   |   1 -
 .../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c   |   4 +-
 drivers/gpu/drm/bridge/Kconfig |   1 +
 drivers/gpu/drm/drm_atomic.c

[git pull] drm fixes for v4.17-rc5

2018-05-10 Thread Dave Airlie

Hi Linus,

As last week seemed a bit slow, we got a few more fixes this week.

The main stuff is 2 weeks of fixes for amdgpu, some missing bits of
vega12 atom firmware support were added, and some power management
fixes.

Nouveau got two regression fixes for an DP MST deadlock and a random oops fix.

i915 got an LVDS panel timeout fix 2 WARN fixes.

exynos fixed a pagefault issue in the mixer driver.

vc4 has an oops fix.

omap had a bunch of uninit var and error-checking fixes.
Two atomic modesetting state fixes.

One minor agp cleanup patch

Regards,
Dave.

The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:

  Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc5

for you to fetch changes up to 72777fe79768ec30ac2163d26de68a89edc9849f:

  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-05-11
10:37:17 +1000)


nouveau, amdgpu, i915, vc4, omap, exynos and atomic fixes


Andrey Grodzovsky (1):
  drm/amdgpu: Switch to interruptable wait to recover from ring hang.

Andrzej Hajda (2):
  drm/exynos/mixer: fix synchronization check in interlaced mode
  drm/bridge/sii8620: add Kconfig dependency on extcon

Ben Skeggs (1):
  drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive client

Boris Brezillon (1):
  drm/vc4: Fix scaling of uni-planar formats

Dan Carpenter (1):
  drm/omap: silence unititialized variable warning

Dave Airlie (6):
  Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge tag 'drm-intel-fixes-2018-05-09' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2018-05-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'linux-4.17' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-fixes-4.17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Eric Anholt (1):
  drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

Florent Flament (1):
  drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

Harry Wentland (3):
  drm/amd/display: Add VG12 ASIC IDs
  drm/amd/display: Add get_firmware_info_v3_2 for VG12
  drm/amd/display: Don't return ddc result and read_bytes in same
return value

Jerry (Fangzhi) Zuo (1):
  drm/amd: Add BIOS smu_info v3_3 required struct def.

Lyude Paul (1):
  drm/nouveau: Fix deadlock in nv50_mstm_register_connector()

Mathieu Malaterre (1):
  agp: uninorth: make two functions static

Michel Dänzer (2):
  drm/amd/display: Use kvzalloc for potentially large allocations
  drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages

Peter Rosin (1):
  drm/exynos: hdmi: avoid duplicating drm_bridge_attach

Rex Zhu (2):
  drm/amd/pp: Refine the output of pp_power_profile_mode on VI
  drm/amd/pp: Fix performance drop on Fiji

Rodrigo Vivi (1):
  drm/i915: Adjust eDP's logical vco in a reliable place.

Tobias Jakobi (1):
  drm/exynos: mixer: avoid Oops in vp_video_buffer()

Tomi Valkeinen (6):
  drm/omap: fix uninitialized ret variable
  drm/omap: fix possible NULL ref issue in tiler_reserve_2d
  drm/omap: check return value from soc_device_match
  drm/omap: handle error if scale coefs are not found
  drm/omap: add missing linefeeds to prints
  drm/omap: handle alloc failures in omap_connector

Ville Syrjälä (3):
  drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()
  drm/atomic: Clean private obj old_state/new_state in
drm_atomic_state_default_clear()
  drm/i915: Correctly populate user mode h/vdisplay with pipe src
size during readout

 drivers/char/agp/uninorth-agp.c|   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|   6 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  20 ++-
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c |  86 ++-
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  |  10 +-
 drivers/gpu/drm/amd/display/dc/core/dc_surface.c   |  14 +-
 drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h   |   5 +-
 drivers/gpu/drm/amd/display/include/dal_asic_id.h  |   9 +-
 .../drm/amd/display/modules/color/color_gamma.c|  72 -
 drivers/gpu/drm/amd/include/atomfirmware.h | 170 -
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  52 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h   |   1 -
 .../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c   |   4 +-
 drivers/gpu/drm/bridge/Kconfig |   1 +
 drivers/gpu/drm/drm_atomic.c

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

2018-05-10 Thread Herbert Xu

On Fri, May 11, 2018 at 01:24:42AM +, Dey, Megha wrote:
> 
> Are you suggesting that the SIMD wrapper, will do what is currently being 
> done by the ' mcryptd_queue_worker ' function (assuming FPU is not disabled) 
> i.e dispatching the job to the inner algorithm?
> 
> I have got rid of the mcryptd layer( have an inner layer, outer SIMD layer, 
> handled the pointers and completions accordingly), but still facing some 
> issues after removing the per cpu mcryptd_cpu_queue.

Why don't you post what you've got and we can work it out together?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

2018-05-10 Thread Herbert Xu

On Fri, May 11, 2018 at 01:24:42AM +, Dey, Megha wrote:
> 
> Are you suggesting that the SIMD wrapper, will do what is currently being 
> done by the ' mcryptd_queue_worker ' function (assuming FPU is not disabled) 
> i.e dispatching the job to the inner algorithm?
> 
> I have got rid of the mcryptd layer( have an inner layer, outer SIMD layer, 
> handled the pointers and completions accordingly), but still facing some 
> issues after removing the per cpu mcryptd_cpu_queue.

Why don't you post what you've got and we can work it out together?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: nds32 build failures

2018-05-10 Thread Guenter Roeck

On 05/10/2018 07:40 PM, Arnd Bergmann wrote:

On Wed, Apr 18, 2018 at 3:19 AM, Greentime Hu wrote:

2018-04-17 20:47 GMT+08:00 Arnd Bergmann :

On Mon, Apr 16, 2018 at 11:06 AM, Greentime Hu wrote:

2018-04-16 11:58 GMT+08:00 Guenter Roeck :

This built failure is because the toolchain version you used is not
supported the latest intrinsic function/macro.
We are sending the latest patchset now and we expect the whole new
features will be supported in gcc8.0.0 and binutil2.31+.

If you'd like to get these new features of toolchain, you may use the
github version.
This is the built-script repo. https://github.com/andestech/build_script.git

I've taken the gcc-6.3 sources from there, and updated them to gcc-6.4.0
in order to build a nds32le-linux toolchain based on the same version as
the other ones.

Unfortunately neither the usual binutils-2.29.1 nor your binutils worked
for me, but I eventually managed to get a build using the binutils-2.30
release.

With this, I could build a mainline kernel with a couple of warnings,
but an 'allmodconfig' build still failed.

Guenter, can you try my binary from
www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/x86_64-gcc-6.4.0-nolibc-nds32le-linux.tar.xz
?

If that works for you, I'll update the front-page and remove the nds32-elf
toolchains.

Greentime, do you have a patch set for gcc-7.3 as well, or are 6.3 and 8.0 the
only working compilers for nds32le-linux?

Hi, all:

I just discuss with our toolchain colleagues. We have only gcc6.3 and
gcc8.0 for nds32le-linux.
I have the ld segmentation fault issue too when building kernel with
'allmodconfig'. We are dealing with it.

I've tried building the mainline gcc-8.1 sources for nds32le-linux and
still got a failure with those (building gcc), building a nds32le-elf gcc-8.1.0
worked fine, but that fails to build the vdso (no support for -fPIC), so
it's again unusable for building kernels. Any other ideas?

FWIW, nds32 in linux-next doesn't build for me at all, at least not with
nds32le-linux-gcc (GCC) 6.4.0 from kernel.org. I have not tried any
other versions.

Guenter

Re: nds32 build failures

2018-05-10 Thread Guenter Roeck

On 05/10/2018 07:40 PM, Arnd Bergmann wrote:

On Wed, Apr 18, 2018 at 3:19 AM, Greentime Hu wrote:

2018-04-17 20:47 GMT+08:00 Arnd Bergmann :

On Mon, Apr 16, 2018 at 11:06 AM, Greentime Hu wrote:

2018-04-16 11:58 GMT+08:00 Guenter Roeck :

If you'd like to get these new features of toolchain, you may use the
github version.
This is the built-script repo. https://github.com/andestech/build_script.git

I've taken the gcc-6.3 sources from there, and updated them to gcc-6.4.0
in order to build a nds32le-linux toolchain based on the same version as
the other ones.

Unfortunately neither the usual binutils-2.29.1 nor your binutils worked
for me, but I eventually managed to get a build using the binutils-2.30
release.

With this, I could build a mainline kernel with a couple of warnings,
but an 'allmodconfig' build still failed.

Guenter, can you try my binary from
www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/x86_64-gcc-6.4.0-nolibc-nds32le-linux.tar.xz
?

If that works for you, I'll update the front-page and remove the nds32-elf
toolchains.

Greentime, do you have a patch set for gcc-7.3 as well, or are 6.3 and 8.0 the
only working compilers for nds32le-linux?

Hi, all:

FWIW, nds32 in linux-next doesn't build for me at all, at least not with
nds32le-linux-gcc (GCC) 6.4.0 from kernel.org. I have not tried any
other versions.

Guenter

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

2018-05-10 Thread Michael Schmitz

Hi Finn,

Am 11.05.2018 um 15:28 schrieb Finn Thain:
> On Fri, 11 May 2018, Michael Schmitz wrote:
> 
 Which begs the question: why can' you set up all Nubus bus devices' 
 DMA masks in nubus_device_register(), or nubus_add_board()?
>>>
>>> I am expecting to see the same WARNING from the nubus sonic driver but 
>>> it hasn't happened yet, so I don't have a patch for it yet. In 
>>> anycase, the nubus fix would be a lot like the zorro bus fix, so I 
>>> don't see a problem.
>>
>> That's odd. But what I meant to say is that by setting up 
>> dma_coherent_mask in nubus_add_board(), and pointing dma_mask to that, 
>> ypu won't need any patches to Nubus device drivers.
> 
> Right. I think I've already acknowledged that. But it's off-topic, because 
> the patches under review are for platform drivers. Those patches fix an 
> actual bug that I've observed. Whereas, the nubus driver dma mask issue 
> that you raised is purely theoretical at this stage.

I had lost track of the fact that macsonic can be probed as either Nubus
or platform device. Sorry for the noise.

I'm afraid using platform_device_register() (which you already use for
the SCC devices) is the only option handling this on a per-device basis
without touching platform core code, while at the same time keeping the
DMA mask setup out of device drivers (I can see Geert's point there -
device driver code might be shared across implementations of the device
on platforms with different DMA mask requirements,, something the driver
can't be expected to know about).

Cheers,

Michael

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

2018-05-10 Thread Michael Schmitz

Hi Finn,

Am 11.05.2018 um 15:28 schrieb Finn Thain:
> On Fri, 11 May 2018, Michael Schmitz wrote:
> 
 Which begs the question: why can' you set up all Nubus bus devices' 
 DMA masks in nubus_device_register(), or nubus_add_board()?
>>>
>>> I am expecting to see the same WARNING from the nubus sonic driver but 
>>> it hasn't happened yet, so I don't have a patch for it yet. In 
>>> anycase, the nubus fix would be a lot like the zorro bus fix, so I 
>>> don't see a problem.
>>
>> That's odd. But what I meant to say is that by setting up 
>> dma_coherent_mask in nubus_add_board(), and pointing dma_mask to that, 
>> ypu won't need any patches to Nubus device drivers.
> 
> Right. I think I've already acknowledged that. But it's off-topic, because 
> the patches under review are for platform drivers. Those patches fix an 
> actual bug that I've observed. Whereas, the nubus driver dma mask issue 
> that you raised is purely theoretical at this stage.

I had lost track of the fact that macsonic can be probed as either Nubus
or platform device. Sorry for the noise.

I'm afraid using platform_device_register() (which you already use for
the SCC devices) is the only option handling this on a per-device basis
without touching platform core code, while at the same time keeping the
DMA mask setup out of device drivers (I can see Geert's point there -
device driver code might be shared across implementations of the device
on platforms with different DMA mask requirements,, something the driver
can't be expected to know about).

Cheers,

Michael

Re: [PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

2018-05-10 Thread Larry Chen


Hello Andrew,


On 05/11/2018 05:49 AM, Andrew Morton wrote:

On Thu, 10 May 2018 13:32:30 +0800 Larry Chen  wrote:


ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock,
is used to prevent deadlock due to recursive lock acquisition.

But this function does not distinguish
whether the requested level is EX or PR.

If a RP lock has been attained, this function
will immediately return success afterwards even
an EX lock is requested.

But actually the return value does not mean that
the process got a EX lock, because ocfs2_inode_lock
has not been called.

When taking lock levels into account, we face some different situations.
1. no lock is held
In this case, just lock the inode and return 0

2. We are holding a lock
For this situation, things diverges into several cases

wanted holding   what to do
ex  ex  see 2.1 below
ex  pr  see 2.2 below
pr  ex  see 2.1 below
pr  pr  see 2.1 below

2.1 lock level that is been held is compatible
with the wanted level, so no lock action will be tacken.

2.2 Otherwise, an upgrade is needed, but it is forbidden.

Reason why upgrade within a process is forbidden is that
lock upgrade may cause dead lock. The following illustrate
how it happens.

 process 1 process 2
ocfs2_inode_lock_tracker(ex=0)
<==   ocfs2_inode_lock_tracker(ex=1)

ocfs2_inode_lock_tracker(ex=1)


Nice changelog, but it gives no information about the severity of the
bug: how often does it hit and what is the end-user impact.

This info is needed so that I and others can decide which kernel
version(s) need the patch, so please always include it when fixing a
bug, thanks.


Thanks for your review and feel sorry for not providing enough information.

For the status quo of ocfs2, without this patch, neither a bug nor end-user
impact will be caused because the wrong logic is avoided.

But I'm afraid this generic interface, may be called by other
developers in future and used in this situation.

    a process
ocfs2_inode_lock_tracker(ex=0)
ocfs2_inode_lock_tracker(ex=1)

By the way, should I resend this patch with this info included?

Thanks
Larry

Re: [PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

2018-05-10 Thread Larry Chen


Hello Andrew,


On 05/11/2018 05:49 AM, Andrew Morton wrote:

On Thu, 10 May 2018 13:32:30 +0800 Larry Chen  wrote:


ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock,
is used to prevent deadlock due to recursive lock acquisition.

But this function does not distinguish
whether the requested level is EX or PR.

If a RP lock has been attained, this function
will immediately return success afterwards even
an EX lock is requested.

But actually the return value does not mean that
the process got a EX lock, because ocfs2_inode_lock
has not been called.

When taking lock levels into account, we face some different situations.
1. no lock is held
In this case, just lock the inode and return 0

2. We are holding a lock
For this situation, things diverges into several cases

wanted holding   what to do
ex  ex  see 2.1 below
ex  pr  see 2.2 below
pr  ex  see 2.1 below
pr  pr  see 2.1 below

2.1 lock level that is been held is compatible
with the wanted level, so no lock action will be tacken.

2.2 Otherwise, an upgrade is needed, but it is forbidden.

Reason why upgrade within a process is forbidden is that
lock upgrade may cause dead lock. The following illustrate
how it happens.

 process 1 process 2
ocfs2_inode_lock_tracker(ex=0)
<==   ocfs2_inode_lock_tracker(ex=1)

ocfs2_inode_lock_tracker(ex=1)


Nice changelog, but it gives no information about the severity of the
bug: how often does it hit and what is the end-user impact.

This info is needed so that I and others can decide which kernel
version(s) need the patch, so please always include it when fixing a
bug, thanks.


Thanks for your review and feel sorry for not providing enough information.

For the status quo of ocfs2, without this patch, neither a bug nor end-user
impact will be caused because the wrong logic is avoided.

But I'm afraid this generic interface, may be called by other
developers in future and used in this situation.

    a process
ocfs2_inode_lock_tracker(ex=0)
ocfs2_inode_lock_tracker(ex=1)

By the way, should I resend this patch with this info included?

Thanks
Larry

Re: [PATCH] tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}

2018-05-10 Thread Juergen Gross

On 09/05/18 20:46, Steven Rostedt wrote:
> 
> From: "Steven Rostedt (VMware)" 
> 
> Doing an audit of trace events, I discovered two trace events in the xen
> subsystem that use a hack to create zero data size trace events. This is not
> what trace events are for. Trace events add memory footprint overhead, and
> if all you need to do is see if a function is hit or not, simply make that
> function noinline and use function tracer filtering.
> 
> Worse yet, the hack used was:
> 
>  __array(char, x, 0)
> 
> Which creates a static string of zero in length. There's assumptions about
> such constructs in ftrace that this is a dynamic string that is nul
> terminated. This is not the case with these tracepoints and can cause
> problems in various parts of ftrace.
> 
> Nuke the trace events!
> 
> Cc: sta...@vger.kernel.org
> Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the 
> generic one.")
> Signed-off-by: Steven Rostedt (VMware) 

Any reason not sending this patch to the Xen maintainers?

I can take it through the Xen tree. :-)

Reviewed-by: Juergen Gross 


Juergen

Re: [PATCH] tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}

2018-05-10 Thread Juergen Gross

On 09/05/18 20:46, Steven Rostedt wrote:
> 
> From: "Steven Rostedt (VMware)" 
> 
> Doing an audit of trace events, I discovered two trace events in the xen
> subsystem that use a hack to create zero data size trace events. This is not
> what trace events are for. Trace events add memory footprint overhead, and
> if all you need to do is see if a function is hit or not, simply make that
> function noinline and use function tracer filtering.
> 
> Worse yet, the hack used was:
> 
>  __array(char, x, 0)
> 
> Which creates a static string of zero in length. There's assumptions about
> such constructs in ftrace that this is a dynamic string that is nul
> terminated. This is not the case with these tracepoints and can cause
> problems in various parts of ftrace.
> 
> Nuke the trace events!
> 
> Cc: sta...@vger.kernel.org
> Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the 
> generic one.")
> Signed-off-by: Steven Rostedt (VMware) 

Any reason not sending this patch to the Xen maintainers?

I can take it through the Xen tree. :-)

Reviewed-by: Juergen Gross 


Juergen

Re: [PATCH 0/5] fix radix tree multi-order iteration race

2018-05-10 Thread Ross Zwisler

On Thu, May 10, 2018 at 03:48:44PM -0700, Andrew Morton wrote:
> so I think I'll just ignore all that and send this series off to Linus next
> week.

Great.  Thank you, Andrew.

Re: [PATCH 0/5] fix radix tree multi-order iteration race

2018-05-10 Thread Ross Zwisler

On Thu, May 10, 2018 at 03:48:44PM -0700, Andrew Morton wrote:
> so I think I'll just ignore all that and send this series off to Linus next
> week.

Great.  Thank you, Andrew.

Re: [GIT PULL] arm64: updates for 4.17

2018-05-10 Thread Yang Li

On Wed, Apr 4, 2018 at 9:32 AM, Will Deacon  wrote:
> Hi Linus,
>
> Please pull these arm64 updates for 4.17. Note that I've pulled in a
> stable branch from Eric Biederman here to fulfil some siginfo dependencies,
> so the diffstat strays slightly out of arm64 due to his changes.
{snip}
>
> Catalin Marinas (1):
>   arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)
>

{snip}

>
> Will Deacon (20):
>   arm64: signal: Make force_signal_inject more robust
>   arm64: signal: Force SIGKILL for unknown signals in force_signal_inject
>   arm64: Introduce arm64_force_sig_info and hook up in arm64_notify_die
>   arm64: signal: Don't print anything directly in force_signal_inject
>   arm64: Pass user fault info to arm64_notify_die instead of printing it
>   arm64: mm: Rework unhandled user pagefaults to call arm64_force_sig_info
>   arm64: signal: Call arm64_notify_segfault when failing to deliver signal
>   arm64: Move show_unhandled_signals_ratelimited into traps.c
>   arm64: Use arm64_force_sig_info instead of force_sig_info
>   arm64: lse: Pass -fomit-frame-pointer to out-of-line ll/sc atomics
>   arm64: kaslr: Set TCR_EL1.NFD1 when CONFIG_RANDOMIZE_BASE=y
>   Merge tag 'acpi/iort-for-v4.17' of 
> git://git.kernel.org/.../lpieralisi/linux into aarch64/for-next/core
>   Merge branch 'siginfo-next' of 
> git://git.kernel.org/.../ebiederm/user-namespace into aarch64/for-next/core
>   arm64: cpufeature: Avoid warnings due to unused symbols
>   Revert "arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line 
> size)"

Hi Will,

I'm wondering if we are changing the L1_CACHE_SHIFT to 6 in 4.17?
This is causing big performance differences for us now.

Regards,
Leo

Re: [GIT PULL] arm64: updates for 4.17

2018-05-10 Thread Yang Li

On Wed, Apr 4, 2018 at 9:32 AM, Will Deacon  wrote:
> Hi Linus,
>
> Please pull these arm64 updates for 4.17. Note that I've pulled in a
> stable branch from Eric Biederman here to fulfil some siginfo dependencies,
> so the diffstat strays slightly out of arm64 due to his changes.
{snip}
>
> Catalin Marinas (1):
>   arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)
>

{snip}

>
> Will Deacon (20):
>   arm64: signal: Make force_signal_inject more robust
>   arm64: signal: Force SIGKILL for unknown signals in force_signal_inject
>   arm64: Introduce arm64_force_sig_info and hook up in arm64_notify_die
>   arm64: signal: Don't print anything directly in force_signal_inject
>   arm64: Pass user fault info to arm64_notify_die instead of printing it
>   arm64: mm: Rework unhandled user pagefaults to call arm64_force_sig_info
>   arm64: signal: Call arm64_notify_segfault when failing to deliver signal
>   arm64: Move show_unhandled_signals_ratelimited into traps.c
>   arm64: Use arm64_force_sig_info instead of force_sig_info
>   arm64: lse: Pass -fomit-frame-pointer to out-of-line ll/sc atomics
>   arm64: kaslr: Set TCR_EL1.NFD1 when CONFIG_RANDOMIZE_BASE=y
>   Merge tag 'acpi/iort-for-v4.17' of 
> git://git.kernel.org/.../lpieralisi/linux into aarch64/for-next/core
>   Merge branch 'siginfo-next' of 
> git://git.kernel.org/.../ebiederm/user-namespace into aarch64/for-next/core
>   arm64: cpufeature: Avoid warnings due to unused symbols
>   Revert "arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line 
> size)"

Hi Will,

I'm wondering if we are changing the L1_CACHE_SHIFT to 6 in 4.17?
This is causing big performance differences for us now.

Regards,
Leo

RE: cross-compiling a 64-bit kernel on a 32-bit host

2018-05-10 Thread Li, Philip


> Subject: Re: cross-compiling a 64-bit kernel on a 32-bit host
> 
> Hi Josh,
> 
> CC LKP team.
> 
> On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote:
> >Hi Fengguang,
> >
> >I occasionally get compilation bug reports from people who are
> >cross-compiling an x86-64 kernel target on an x86-32 host.
> >
> >Any chance the 0-day build bot could test that configuration?  I think
> >just building a defconfig would be sufficient.  It would help sort out
> >issues in objtool and other host-built scripts.
> 
> To do that we'll need to create a new build chroot. Julie/Philip
> should be able to evaluate the efforts and do the plan.
got it, we will consider this in future plan after some evaluation.

> 
> Thanks,
> Fengguang

RE: cross-compiling a 64-bit kernel on a 32-bit host

2018-05-10 Thread Li, Philip


> Subject: Re: cross-compiling a 64-bit kernel on a 32-bit host
> 
> Hi Josh,
> 
> CC LKP team.
> 
> On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote:
> >Hi Fengguang,
> >
> >I occasionally get compilation bug reports from people who are
> >cross-compiling an x86-64 kernel target on an x86-32 host.
> >
> >Any chance the 0-day build bot could test that configuration?  I think
> >just building a defconfig would be sufficient.  It would help sort out
> >issues in objtool and other host-built scripts.
> 
> To do that we'll need to create a new build chroot. Julie/Philip
> should be able to evaluate the efforts and do the plan.
got it, we will consider this in future plan after some evaluation.

> 
> Thanks,
> Fengguang

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

2018-05-10 Thread Theodore Y. Ts'o

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote:
> random uses __ratelimit() which calls ___ratelimit() with a function
> name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many
> messages were suppressed every ratelimit interval (1 second for random)
> and flushes ratelimit_state::missed:

So the thing about the ratelimit system is that if you have a burst of
1,000,000 within the one second burst window, and then nothing ever
again, you will never see a message accounting for those 1,000,000
"callbacks" (which is a terrible wording; it just confuses people).

If you have a burst of 1,000,000 calls to ratelimit, and then a month
goes by, and *then* a single call to __ratelimit is called by printk,
only *the* does the message about the suppressed "callback" get
printed.

So in the case of the random driver, once the random driver is fully
intialized, there will never be a call to __ratelimit() for the
urandom ratelimit structures, so we manually print out the final
number of suppressed message so there is proper accounting for them.

It is not a double-count.  If we didn't do that, those suppressed
warnings would never be mentioned by the kernel.

Cheers,

- Ted

Re: [PATCH 1/2] random: Omit double-printing ratelimit messages

2018-05-10 Thread Theodore Y. Ts'o

On Thu, May 10, 2018 at 08:50:07PM +0100, Dmitry Safonov wrote:
> random uses __ratelimit() which calls ___ratelimit() with a function
> name. Depending on !RATELIMIT_MSG_ON_RELEASE it prints how many
> messages were suppressed every ratelimit interval (1 second for random)
> and flushes ratelimit_state::missed:

So the thing about the ratelimit system is that if you have a burst of
1,000,000 within the one second burst window, and then nothing ever
again, you will never see a message accounting for those 1,000,000
"callbacks" (which is a terrible wording; it just confuses people).

If you have a burst of 1,000,000 calls to ratelimit, and then a month
goes by, and *then* a single call to __ratelimit is called by printk,
only *the* does the message about the suppressed "callback" get
printed.

So in the case of the random driver, once the random driver is fully
intialized, there will never be a call to __ratelimit() for the
urandom ratelimit structures, so we manually print out the final
number of suppressed message so there is proper accounting for them.

It is not a double-count.  If we didn't do that, those suppressed
warnings would never be mentioned by the kernel.

Cheers,

- Ted

[PATCH] um: remove unused vdso-syms.lds

This file contains symbol values, and was originally linked into
vmlinux, but I have no idea what it was actually used for.

Since commit 827880ec260b ("x86/um: thin archives build fix"), it is
not even linked.  Now it is completely orphan, and no problem has
been reported.  It is a proof that this file was not needed in the
first place.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/um/vdso/.gitignore |  1 -
 arch/x86/um/vdso/Makefile   | 16 
 2 files changed, 17 deletions(-)

diff --git a/arch/x86/um/vdso/.gitignore b/arch/x86/um/vdso/.gitignore
index 9cac6d0..f8b69d8 100644
--- a/arch/x86/um/vdso/.gitignore
+++ b/arch/x86/um/vdso/.gitignore
@@ -1,2 +1 @@
-vdso-syms.lds
 vdso.lds
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 1000335..426681e 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -53,22 +53,6 @@ $(vobjs): KBUILD_CFLAGS += $(CFL)
 CFLAGS_REMOVE_vdso-note.o = -pg -fprofile-arcs -ftest-coverage
 CFLAGS_REMOVE_um_vdso.o = -pg -fprofile-arcs -ftest-coverage
 
-targets += vdso-syms.lds
-extra-$(VDSO64-y)  += vdso-syms.lds
-
-#
-# Match symbols in the DSO that look like VDSO*; produce a file of constants.
-#
-sed-vdsosym := -e 's/^00*/0/' \
-   -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$$/\2 = 0x\1;/p'
-quiet_cmd_vdsosym = VDSOSYM $@
-define cmd_vdsosym
-   $(NM) $< | LC_ALL=C sed -n $(sed-vdsosym) | LC_ALL=C sort > $@
-endef
-
-$(obj)/%-syms.lds: $(obj)/%.so.dbg FORCE
-   $(call if_changed,vdsosym)
-
 #
 # The DSO images are built using a special linker script.
 #
-- 
2.7.4

[PATCH] um: remove unused vdso-syms.lds

This file contains symbol values, and was originally linked into
vmlinux, but I have no idea what it was actually used for.

Since commit 827880ec260b ("x86/um: thin archives build fix"), it is
not even linked.  Now it is completely orphan, and no problem has
been reported.  It is a proof that this file was not needed in the
first place.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/um/vdso/.gitignore |  1 -
 arch/x86/um/vdso/Makefile   | 16 
 2 files changed, 17 deletions(-)

diff --git a/arch/x86/um/vdso/.gitignore b/arch/x86/um/vdso/.gitignore
index 9cac6d0..f8b69d8 100644
--- a/arch/x86/um/vdso/.gitignore
+++ b/arch/x86/um/vdso/.gitignore
@@ -1,2 +1 @@
-vdso-syms.lds
 vdso.lds
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 1000335..426681e 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -53,22 +53,6 @@ $(vobjs): KBUILD_CFLAGS += $(CFL)
 CFLAGS_REMOVE_vdso-note.o = -pg -fprofile-arcs -ftest-coverage
 CFLAGS_REMOVE_um_vdso.o = -pg -fprofile-arcs -ftest-coverage
 
-targets += vdso-syms.lds
-extra-$(VDSO64-y)  += vdso-syms.lds
-
-#
-# Match symbols in the DSO that look like VDSO*; produce a file of constants.
-#
-sed-vdsosym := -e 's/^00*/0/' \
-   -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$$/\2 = 0x\1;/p'
-quiet_cmd_vdsosym = VDSOSYM $@
-define cmd_vdsosym
-   $(NM) $< | LC_ALL=C sed -n $(sed-vdsosym) | LC_ALL=C sort > $@
-endef
-
-$(obj)/%-syms.lds: $(obj)/%.so.dbg FORCE
-   $(call if_changed,vdsosym)
-
 #
 # The DSO images are built using a special linker script.
 #
-- 
2.7.4

Re: [UML] Question about arch/x86/um/vdso/vdso-syms.lds

Richard,


2018-05-09 15:36 GMT+09:00 Richard Weinberger :
> Masahiro,
>
> Am Mittwoch, 9. Mai 2018, 05:36:18 CEST schrieb Masahiro Yamada:
>> Hi Richard,
>>
>>
>> Please let me ask a question about vdso-syms.lds
>> under arch/x86/um/vdso/.
>>
>> This file exists since:
>>
>> commit f1c2bb8b9964ed31de988910f8b1cfb586d30091
>> Author: Richard Weinberger 
>> Date:   Mon Jul 25 17:12:54 2011 -0700
>>
>> um: implement a x86_64 vDSO
>>
>>
>> So, I think you are the right person
>> to reach out to.
>>
>>
>> Originally, vdso-syms.lds was linked to vmlinux,
>> but it is not since:
>>
>> commit 827880ec260ba048f95fe646b96a205c394fa0f0
>> Author: Nicholas Piggin 
>> Date:   Fri Jun 9 15:24:16 2017 +1000
>>
>> x86/um: thin archives build fix
>>
>>
>>
>> Something may be missing from my thought,
>> but I wonder what vdso-syms.lds is used for.
>
> Hmm, I think we can kill it. In 2011 I used the x86 vdso
> code as "template" this is how the file made it into UML.
> AFAICT it was forgotten after all the vdso related refactoring
> in um and x86.
>
> Thanks,
> //richard


OK, I have sent a patch to the UML ML.
Thanks.


-- 
Best Regards
Masahiro Yamada

Re: [UML] Question about arch/x86/um/vdso/vdso-syms.lds

Richard,


2018-05-09 15:36 GMT+09:00 Richard Weinberger :
> Masahiro,
>
> Am Mittwoch, 9. Mai 2018, 05:36:18 CEST schrieb Masahiro Yamada:
>> Hi Richard,
>>
>>
>> Please let me ask a question about vdso-syms.lds
>> under arch/x86/um/vdso/.
>>
>> This file exists since:
>>
>> commit f1c2bb8b9964ed31de988910f8b1cfb586d30091
>> Author: Richard Weinberger 
>> Date:   Mon Jul 25 17:12:54 2011 -0700
>>
>> um: implement a x86_64 vDSO
>>
>>
>> So, I think you are the right person
>> to reach out to.
>>
>>
>> Originally, vdso-syms.lds was linked to vmlinux,
>> but it is not since:
>>
>> commit 827880ec260ba048f95fe646b96a205c394fa0f0
>> Author: Nicholas Piggin 
>> Date:   Fri Jun 9 15:24:16 2017 +1000
>>
>> x86/um: thin archives build fix
>>
>>
>>
>> Something may be missing from my thought,
>> but I wonder what vdso-syms.lds is used for.
>
> Hmm, I think we can kill it. In 2011 I used the x86 vdso
> code as "template" this is how the file made it into UML.
> AFAICT it was forgotten after all the vdso related refactoring
> in um and x86.
>
> Thanks,
> //richard


OK, I have sent a patch to the UML ML.
Thanks.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328

2018-05-10 Thread Levin Du


On 2018-05-10 8:50 PM, Robin Murphy wrote:

On 10/05/18 10:16, d...@t-chip.com.cn wrote:

From: Levin Du 

Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
access to the pins defined in the syscon GRF_SOC_CON10.


This is the GPIO_MUTE pin, right? The public TRM is rather vague, but 
cross-referencing against the datasheet and schematics implies that 
it's the "gpiomut_*" part of the GRF bit names which is most significant.


It might be worth using a more descriptive name here, since "syscon10" 
is pretty much meaningless at the board level.


Robin.

Previously I though other bits might be able to reference from syscon10, 
other than GPIO_MUTE alone.
If it is renamed to gpio-mute, then the GPIO_MUTE pin is accessed as 
`< 1>`. Yet other
bits in syscon10 can also be referenced, say, `< 10>`, which 
is not good.


I'd like to add a `gpio,syscon-bit` property to gpio-syscon, which 
overrides the properties
of bit_count,  data_bit_offset and dir_bit_offset in the driver. For 
example:


    gpio_mute: gpio-mute {
    compatible = "rockchip,gpio-syscon";
    gpio-controller;
    #gpio-cells = <2>;
    gpio,syscon-dev = <0 0x0428 0>;
    gpio,syscon-bit = <1 1 0>;
    };

That way, the mute pin is strictly specified as <_mute 0>, and 
<_mute 1> will be invalid.

I think that is neat, and consistent with the gpio_mute name.

Thanks
Levin

Re: [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328

2018-05-10 Thread Levin Du


On 2018-05-10 8:50 PM, Robin Murphy wrote:

On 10/05/18 10:16, d...@t-chip.com.cn wrote:

From: Levin Du 

Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
access to the pins defined in the syscon GRF_SOC_CON10.


This is the GPIO_MUTE pin, right? The public TRM is rather vague, but 
cross-referencing against the datasheet and schematics implies that 
it's the "gpiomut_*" part of the GRF bit names which is most significant.


It might be worth using a more descriptive name here, since "syscon10" 
is pretty much meaningless at the board level.


Robin.

Previously I though other bits might be able to reference from syscon10, 
other than GPIO_MUTE alone.
If it is renamed to gpio-mute, then the GPIO_MUTE pin is accessed as 
`< 1>`. Yet other
bits in syscon10 can also be referenced, say, `< 10>`, which 
is not good.


I'd like to add a `gpio,syscon-bit` property to gpio-syscon, which 
overrides the properties
of bit_count,  data_bit_offset and dir_bit_offset in the driver. For 
example:


    gpio_mute: gpio-mute {
    compatible = "rockchip,gpio-syscon";
    gpio-controller;
    #gpio-cells = <2>;
    gpio,syscon-dev = <0 0x0428 0>;
    gpio,syscon-bit = <1 1 0>;
    };

That way, the mute pin is strictly specified as <_mute 0>, and 
<_mute 1> will be invalid.

I think that is neat, and consistent with the gpio_mute name.

Thanks
Levin

Re: [PATCH v4 0/1] Add livepatch kselftests

2018-05-10 Thread Joe Lawrence

On Fri, May 11, 2018 at 10:53:24AM +0800, Ye Xiaolong wrote:
> Hi, Joe
> 
> Sorry for the late response.

Hi Xiaolong, no worries...

> On 04/26, Joe Lawrence wrote:
> >>On 04/25/2018 02:28 PM, Joe Lawrence wrote:
> >
> >> [ ... snip ... ]
> >> 
> >> base-commit: 0adb32858b0bddf4ada5f364a84ed60b196dbcda
> >> prerequisite-patch-id: 5ed747c1a89a5dc4bba08186e21f927d7f3bf049
> >> prerequisite-patch-id: e9800288b71a9f339ea066e58d9ef70dece67083
> >> prerequisite-patch-id: 415f2e190b1b50142c78f2940c7b8dd39b5321a0
> >> prerequisite-patch-id: d229d9cf08af087e0a758d9df1da467103c2c200
> >> prerequisite-patch-id: b8c7ef99b13c6b321cba5e8919ed0b3e29f213e9
> >> prerequisite-patch-id: 4e10c0d08f151b18310fe0b1e5013d62db94cfeb
> >> prerequisite-patch-id: 33046b190c114d202f3a52e0e274dbb2b1907a4c
> >> prerequisite-patch-id: 6978944a725756317dd4e005d479b6101784aaf0
> >> prerequisite-patch-id: cce9d3c7e1ae8887f387ca9e072552dc63479749
> >> prerequisite-patch-id: c44ccc5dd7b1be6fe2b1f32ca6abde1da73fae79
> >> 
> >
> >Hi kbuild test robot folks,
> >
> >I attempted to use the --base option with git format-patch as suggested
> >by Philip, but the bot still sent me mail (addressed only to myself and
> >cc'd kbuild-...@01.org) about build test ERRORs against the wrong base:
> >
> >> [auto build test ERROR on v4.16]
> >> [also build test ERROR on next-20180424]
> >> [cannot apply to linus/master jikos-livepatching/for-next]
> 
> I noticed this error report was for [PATCH v3] selftests/livepatch: introduce 
> tests
> which doesn't include the base commit info.

That must have been it!  Looking back in my mail archives, I don't see
any complaints against v4.  The bot must have sent me v3 mail just after I
fired off v4.

> > [ ... snip workflow detail ... ]
> I think the work flow you described above is ok, you can just send them with
> git send-email after doing that, and base commit/prerequisite patch info in
> cover-letter is fine, the question here is I can't find the patch emails of
> your patchset except the cover letter in 0day's mail archive, do you send them
> as a whole series, could you tell the subjects of them so I can take a look in
> 0day's log.

My patchset v4 (this subject/thread):

  [PATCH v4 0/1] Add livepatch kselftests
  https://lkml.org/lkml/2018/4/25/1139

based on Petr's patchsets:

  [PATCH 0/8] livepatch: Atomic replace feature
  https://lkml.org/lkml/2018/3/23/665

  [PATCH v3 0/2] livepatch: Allocate and free shadow variables more safely
  https://lkml.org/lkml/2018/4/16/326

All of which should have been posted to linux-kernel as well as
linux-livepatching.  I can dig up Message-Ids or other headers if that
helps any.

Regards,

-- Joe

Re: [PATCH v4 0/1] Add livepatch kselftests

2018-05-10 Thread Joe Lawrence

On Fri, May 11, 2018 at 10:53:24AM +0800, Ye Xiaolong wrote:
> Hi, Joe
> 
> Sorry for the late response.

Hi Xiaolong, no worries...

> On 04/26, Joe Lawrence wrote:
> >>On 04/25/2018 02:28 PM, Joe Lawrence wrote:
> >
> >> [ ... snip ... ]
> >> 
> >> base-commit: 0adb32858b0bddf4ada5f364a84ed60b196dbcda
> >> prerequisite-patch-id: 5ed747c1a89a5dc4bba08186e21f927d7f3bf049
> >> prerequisite-patch-id: e9800288b71a9f339ea066e58d9ef70dece67083
> >> prerequisite-patch-id: 415f2e190b1b50142c78f2940c7b8dd39b5321a0
> >> prerequisite-patch-id: d229d9cf08af087e0a758d9df1da467103c2c200
> >> prerequisite-patch-id: b8c7ef99b13c6b321cba5e8919ed0b3e29f213e9
> >> prerequisite-patch-id: 4e10c0d08f151b18310fe0b1e5013d62db94cfeb
> >> prerequisite-patch-id: 33046b190c114d202f3a52e0e274dbb2b1907a4c
> >> prerequisite-patch-id: 6978944a725756317dd4e005d479b6101784aaf0
> >> prerequisite-patch-id: cce9d3c7e1ae8887f387ca9e072552dc63479749
> >> prerequisite-patch-id: c44ccc5dd7b1be6fe2b1f32ca6abde1da73fae79
> >> 
> >
> >Hi kbuild test robot folks,
> >
> >I attempted to use the --base option with git format-patch as suggested
> >by Philip, but the bot still sent me mail (addressed only to myself and
> >cc'd kbuild-...@01.org) about build test ERRORs against the wrong base:
> >
> >> [auto build test ERROR on v4.16]
> >> [also build test ERROR on next-20180424]
> >> [cannot apply to linus/master jikos-livepatching/for-next]
> 
> I noticed this error report was for [PATCH v3] selftests/livepatch: introduce 
> tests
> which doesn't include the base commit info.

That must have been it!  Looking back in my mail archives, I don't see
any complaints against v4.  The bot must have sent me v3 mail just after I
fired off v4.

> > [ ... snip workflow detail ... ]
> I think the work flow you described above is ok, you can just send them with
> git send-email after doing that, and base commit/prerequisite patch info in
> cover-letter is fine, the question here is I can't find the patch emails of
> your patchset except the cover letter in 0day's mail archive, do you send them
> as a whole series, could you tell the subjects of them so I can take a look in
> 0day's log.

My patchset v4 (this subject/thread):

  [PATCH v4 0/1] Add livepatch kselftests
  https://lkml.org/lkml/2018/4/25/1139

based on Petr's patchsets:

  [PATCH 0/8] livepatch: Atomic replace feature
  https://lkml.org/lkml/2018/3/23/665

  [PATCH v3 0/2] livepatch: Allocate and free shadow variables more safely
  https://lkml.org/lkml/2018/4/16/326

All of which should have been posted to linux-kernel as well as
linux-livepatching.  I can dig up Message-Ids or other headers if that
helps any.

Regards,

-- Joe

Re: cross-compiling a 64-bit kernel on a 32-bit host

2018-05-10 Thread Fengguang Wu


Hi Josh,

CC LKP team.

On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote:

Hi Fengguang,

I occasionally get compilation bug reports from people who are
cross-compiling an x86-64 kernel target on an x86-32 host.

Any chance the 0-day build bot could test that configuration?  I think
just building a defconfig would be sufficient.  It would help sort out
issues in objtool and other host-built scripts.


To do that we'll need to create a new build chroot. Julie/Philip
should be able to evaluate the efforts and do the plan.

Thanks,
Fengguang

Re: cross-compiling a 64-bit kernel on a 32-bit host

2018-05-10 Thread Fengguang Wu


Hi Josh,

CC LKP team.

On Thu, May 10, 2018 at 05:36:19PM -0500, Josh Poimboeuf wrote:

Hi Fengguang,

I occasionally get compilation bug reports from people who are
cross-compiling an x86-64 kernel target on an x86-32 host.

Any chance the 0-day build bot could test that configuration?  I think
just building a defconfig would be sufficient.  It would help sort out
issues in objtool and other host-built scripts.


To do that we'll need to create a new build chroot. Julie/Philip
should be able to evaluate the efforts and do the plan.

Thanks,
Fengguang

[PATCH 4/9] arm64: dts: ls208xa: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 

Add the identify of the platform to support set the rcpm with
big-endian or little-endian.

Signed-off-by: Zhang Ying-22455 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index fec61af..973e646 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -896,9 +896,11 @@
};
 
ftm0: ftm0@280 {
-   compatible = "fsl,ftm-alarm";
-   reg = <0x0 0x280 0x0 0x1>;
+   compatible = "fsl,ls208xa-ftm";
+   reg = <0x0 0x280 0x0 0x1>,
+ <0x0 0x1e34050 0x0 0x4>;
interrupts = <0 44 4>;
+   reg-names = "ftm", "FlexTimer1";
};
};
 
-- 
1.7.1

[PATCH 4/9] arm64: dts: ls208xa: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 

Add the identify of the platform to support set the rcpm with
big-endian or little-endian.

Signed-off-by: Zhang Ying-22455 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index fec61af..973e646 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -896,9 +896,11 @@
};
 
ftm0: ftm0@280 {
-   compatible = "fsl,ftm-alarm";
-   reg = <0x0 0x280 0x0 0x1>;
+   compatible = "fsl,ls208xa-ftm";
+   reg = <0x0 0x280 0x0 0x1>,
+ <0x0 0x1e34050 0x0 0x4>;
interrupts = <0 44 4>;
+   reg-names = "ftm", "FlexTimer1";
};
};
 
-- 
1.7.1

[PATCH 8/9] arm64: dts: ls1046a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 

Add the identify of the platform to support set the rcpm with
big-endian or little-endian.

Signed-off-by: Zhang Ying-22455 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 3e09bcb..1ce1153 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -575,7 +575,7 @@
};
 
ftm0: ftm0@29d {
-   compatible = "fsl,ftm-alarm";
+   compatible = "fsl,ls1046a-ftm";
reg = <0x0 0x29d 0x0 0x1>,
  <0x0 0x1ee2140 0x0 0x4>;
reg-names = "ftm", "FlexTimer1";
-- 
1.7.1

[PATCH 9/9] armv8: add psci 0.2 stardard support

From: Yuantian Tang 

In current kernel, only psci v1.0 is supported. But our psci firmware
only support psci v0.2. So update psci driver to support psci v0.2.

Signed-off-by: Tang Yuantian 
---
 drivers/firmware/psci.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 0bd795f..c9ed9fb 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -468,6 +468,8 @@ static void __init psci_init_system_suspend(void)
if (!IS_ENABLED(CONFIG_SUSPEND))
return;
 
+   suspend_set_ops(_suspend_ops);
+
ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND));
 
if (ret != PSCI_RET_NOT_SUPPORTED)
@@ -573,6 +575,8 @@ static void __init psci_0_2_set_functions(void)
 
pm_power_off = psci_sys_poweroff;
 
+   psci_init_system_suspend();
+
suspend_set_ops(_suspend_ops);
 }
 
-- 
1.7.1

[PATCH 8/9] arm64: dts: ls1046a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 

Add the identify of the platform to support set the rcpm with
big-endian or little-endian.

Signed-off-by: Zhang Ying-22455 
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 3e09bcb..1ce1153 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -575,7 +575,7 @@
};
 
ftm0: ftm0@29d {
-   compatible = "fsl,ftm-alarm";
+   compatible = "fsl,ls1046a-ftm";
reg = <0x0 0x29d 0x0 0x1>,
  <0x0 0x1ee2140 0x0 0x4>;
reg-names = "ftm", "FlexTimer1";
-- 
1.7.1

[PATCH 9/9] armv8: add psci 0.2 stardard support

From: Yuantian Tang 

In current kernel, only psci v1.0 is supported. But our psci firmware
only support psci v0.2. So update psci driver to support psci v0.2.

Signed-off-by: Tang Yuantian 
---
 drivers/firmware/psci.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 0bd795f..c9ed9fb 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -468,6 +468,8 @@ static void __init psci_init_system_suspend(void)
if (!IS_ENABLED(CONFIG_SUSPEND))
return;
 
+   suspend_set_ops(_suspend_ops);
+
ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND));
 
if (ret != PSCI_RET_NOT_SUPPORTED)
@@ -573,6 +575,8 @@ static void __init psci_0_2_set_functions(void)
 
pm_power_off = psci_sys_poweroff;
 
+   psci_init_system_suspend();
+
suspend_set_ops(_suspend_ops);
 }
 
-- 
1.7.1

[PATCH 6/9] soc: fsl: fix the compilation issue

From: Zhang Ying-22455 

Signed-off-by: Zhang Ying-22455 
---
 drivers/soc/fsl/layerscape/ftm_alarm.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c 
b/drivers/soc/fsl/layerscape/ftm_alarm.c
index 811dcfa..c22ef49 100644
--- a/drivers/soc/fsl/layerscape/ftm_alarm.c
+++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define FTM_SC 0x00
 #define FTM_SC_CLK_SHIFT   3
-- 
1.7.1

[PATCH 6/9] soc: fsl: fix the compilation issue

From: Zhang Ying-22455 

Signed-off-by: Zhang Ying-22455 
---
 drivers/soc/fsl/layerscape/ftm_alarm.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c 
b/drivers/soc/fsl/layerscape/ftm_alarm.c
index 811dcfa..c22ef49 100644
--- a/drivers/soc/fsl/layerscape/ftm_alarm.c
+++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define FTM_SC 0x00
 #define FTM_SC_CLK_SHIFT   3
-- 
1.7.1

[PATCH 7/9] arm64: dts: ls1043a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 

Add the identify of the platform to support set the rcpm with
big-endian or little-endian.

Signed-off-by: Zhang Ying-22455 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index ffea97a..754ce0d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -679,7 +679,7 @@
};
 
ftm0: ftm0@29d {
-   compatible = "fsl,ftm-alarm";
+   compatible = "fsl,ls1043a-ftm";
reg = <0x0 0x29d 0x0 0x1>,
  <0x0 0x1ee2140 0x0 0x4>;
reg-names = "ftm", "FlexTimer1";
-- 
1.7.1

[PATCH 7/9] arm64: dts: ls1043a: Add the identify of the platform to support to set rcpm bit

From: Zhang Ying-22455 

Add the identify of the platform to support set the rcpm with
big-endian or little-endian.

Signed-off-by: Zhang Ying-22455 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index ffea97a..754ce0d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -679,7 +679,7 @@
};
 
ftm0: ftm0@29d {
-   compatible = "fsl,ftm-alarm";
+   compatible = "fsl,ls1043a-ftm";
reg = <0x0 0x29d 0x0 0x1>,
  <0x0 0x1ee2140 0x0 0x4>;
reg-names = "ftm", "FlexTimer1";
-- 
1.7.1

[PATCH 5/9] drivers: firmware: psci: use psci v0.2 to implement sleep

From: Yuantian Tang 

Technically psci v0.2 can not support system sleep. Unfortunately
our PPA only supports psci v0.2. So workaround this by changing
psci v1.0 to v0.2 call to implement system sleep.

Signed-off-by: Tang Yuantian 
Signed-off-by: Yinbo Zhu 
---
 drivers/firmware/psci.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d..0bd795f 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -437,8 +437,18 @@ int psci_cpu_suspend_enter(unsigned long index)
 
 static int psci_system_suspend(unsigned long unused)
 {
-   return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
- __pa_symbol(cpu_resume), 0, 0);
+   u32 state;
+   u32 ver = psci_get_version();
+
+   if (PSCI_VERSION_MAJOR(ver) >= 1) {
+   return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
+   virt_to_phys(cpu_resume), 0, 0);
+   } else {
+   state = (2 << PSCI_0_2_POWER_STATE_AFFL_SHIFT) |
+   (1 << PSCI_0_2_POWER_STATE_TYPE_SHIFT);
+
+   return psci_cpu_suspend(state, virt_to_phys(cpu_resume));
+   }
 }
 
 static int psci_system_suspend_enter(suspend_state_t state)
@@ -562,6 +572,8 @@ static void __init psci_0_2_set_functions(void)
arm_pm_restart = psci_sys_reset;
 
pm_power_off = psci_sys_poweroff;
+
+   suspend_set_ops(_suspend_ops);
 }
 
 /*
-- 
1.7.1

[PATCH 5/9] drivers: firmware: psci: use psci v0.2 to implement sleep

From: Yuantian Tang 

Technically psci v0.2 can not support system sleep. Unfortunately
our PPA only supports psci v0.2. So workaround this by changing
psci v1.0 to v0.2 call to implement system sleep.

Signed-off-by: Tang Yuantian 
Signed-off-by: Yinbo Zhu 
---
 drivers/firmware/psci.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d..0bd795f 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -437,8 +437,18 @@ int psci_cpu_suspend_enter(unsigned long index)
 
 static int psci_system_suspend(unsigned long unused)
 {
-   return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
- __pa_symbol(cpu_resume), 0, 0);
+   u32 state;
+   u32 ver = psci_get_version();
+
+   if (PSCI_VERSION_MAJOR(ver) >= 1) {
+   return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
+   virt_to_phys(cpu_resume), 0, 0);
+   } else {
+   state = (2 << PSCI_0_2_POWER_STATE_AFFL_SHIFT) |
+   (1 << PSCI_0_2_POWER_STATE_TYPE_SHIFT);
+
+   return psci_cpu_suspend(state, virt_to_phys(cpu_resume));
+   }
 }
 
 static int psci_system_suspend_enter(suspend_state_t state)
@@ -562,6 +572,8 @@ static void __init psci_0_2_set_functions(void)
arm_pm_restart = psci_sys_reset;
 
pm_power_off = psci_sys_poweroff;
+
+   suspend_set_ops(_suspend_ops);
 }
 
 /*
-- 
1.7.1

[PATCH 2/9] armv8: pm: Fix issue of rcpm driver wrongly program other IP control bits

From: Ran Wang 

When rcpm driver get target register data from DTS property 'fsl,
rcpm-wakeup' (second value), it directly write that data to register
RCPM_IPPDEXPCRx rather than 'OR' the value read from it before. This
operation will over-write those non-related IP control bit which
might have been programmed, should be prevented.

Signed-off-by: Ran Wang 
Signed-off-by: Yinbo Zhu 
---
 drivers/soc/fsl/rcpm.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index ff0477b..39eabfb 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -75,6 +75,7 @@ static void rcpm_wakeup_fixup(struct device *dev, void *data)
 static int rcpm_suspend_prepare(void)
 {
int i;
+   u32 val;
 
WARN_ON(!rcpm);
 
@@ -84,9 +85,12 @@ static int rcpm_suspend_prepare(void)
dpm_for_each_dev(NULL, rcpm_wakeup_fixup);
 
for (i = 0; i < rcpm->ipp_num; i++) {
-   rcpm_reg_write(rcpm->ippdexpcr_offset + 4 * i,
-  rcpm->ippdexpcr[i]);
-   pr_debug("ippdexpcr%d = 0x%x\n", i, rcpm->ippdexpcr[i]);
+   if (rcpm->ippdexpcr[i]) {
+   val = rcpm_reg_read(rcpm->ippdexpcr_offset + 4 * i);
+   rcpm_reg_write(rcpm->ippdexpcr_offset + 4 * i,
+  val | rcpm->ippdexpcr[i]);
+   pr_debug("ippdexpcr%d = 0x%x\n", i, rcpm->ippdexpcr[i]);
+   }
}
 
return 0;
-- 
1.7.1

[PATCH 3/9] soc: fsl: set rcpm bit for FTM

From: Zhang Ying-22455 

Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
module of each platform has different big-end and little-end mode,
there need to set RCPM depending on the platform.

Signed-off-by: Zhang Ying-22455 
Signed-off-by: Yinbo Zhu 
---
 .../devicetree/bindings/timer/fsl,ftm-timer.txt|7 ++
 drivers/soc/fsl/layerscape/ftm_alarm.c |   92 ++-
 2 files changed, 94 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt 
b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
index aa8c402..15ead58 100644
--- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
@@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer
 Required properties:
 
 - compatible : should be "fsl,ftm-timer"
+ Possible compatibles for ARM:
+ "fsl,ls1012a-ftm"
+ "fsl,ls1021a-ftm"
+ "fsl,ls1043a-ftm"
+ "fsl,ls1046a-ftm"
+ "fsl,ls1088a-ftm"
+ "fsl,ls208xa-ftm"
 - reg : Specifies base physical address and size of the register sets for the
   clock event device and clock source device.
 - interrupts : Should be the clock event device interrupt.
diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c 
b/drivers/soc/fsl/layerscape/ftm_alarm.c
index 6f9882f..811dcfa 100644
--- a/drivers/soc/fsl/layerscape/ftm_alarm.c
+++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define FTM_SC 0x00
 #define FTM_SC_CLK_SHIFT   3
@@ -40,6 +43,59 @@
 static u32 alarm_freq;
 static bool big_endian;
 
+enum pmu_endian_type {
+   BIG_ENDIAN,
+   LITTLE_ENDIAN,
+};
+
+struct rcpm_cfg {
+   enum pmu_endian_type big_endian; /* Big/Little endian of PMU module */
+
+   /* FlexTimer1 is not powerdown during device LPM20 */
+   u32 flextimer_set_bit;
+};
+
+static struct rcpm_cfg ls1012a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1021a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1043a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1046a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1088a_rcpm_cfg = {
+   .big_endian = LITTLE_ENDIAN,
+   .flextimer_set_bit = 0x4000,
+};
+
+static struct rcpm_cfg ls208xa_rcpm_cfg = {
+   .big_endian = LITTLE_ENDIAN,
+   .flextimer_set_bit = 0x4000,
+};
+
+static const struct of_device_id ippdexpcr_of_match[] = {
+   { .compatible = "fsl,ls1012a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1021a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1043a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1046a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1088a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls208xa-ftm", .data = _rcpm_cfg},
+   {},
+};
+MODULE_DEVICE_TABLE(of, ippdexpcr_of_match);
+
 static inline u32 ftm_readl(void __iomem *addr)
 {
if (big_endian)
@@ -214,7 +270,10 @@ static int ftm_alarm_probe(struct platform_device *pdev)
struct resource *r;
int irq;
int ret;
-   u32 ippdexpcr;
+   struct rcpm_cfg *rcpm_cfg;
+   u32 ippdexpcr, flextimer;
+   const struct of_device_id *of_id;
+   enum pmu_endian_type endian;
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
@@ -224,14 +283,32 @@ static int ftm_alarm_probe(struct platform_device *pdev)
if (IS_ERR(ftm1_base))
return PTR_ERR(ftm1_base);
 
+   of_id = of_match_node(ippdexpcr_of_match, np);
+   if (!of_id)
+   return -ENODEV;
+
+   rcpm_cfg = devm_kzalloc(>dev, sizeof(*rcpm_cfg), GFP_KERNEL);
+   if (!rcpm_cfg)
+   return -ENOMEM;
+
+   rcpm_cfg = (struct rcpm_cfg *)of_id->data;
+   endian = rcpm_cfg->big_endian;
+   flextimer = rcpm_cfg->flextimer_set_bit;
+
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "FlexTimer1");
if (r) {
rcpm_ftm_addr = devm_ioremap_resource(>dev, r);
if (IS_ERR(rcpm_ftm_addr))
return PTR_ERR(rcpm_ftm_addr);
-   ippdexpcr = ioread32be(rcpm_ftm_addr);
-   ippdexpcr |= 0x2;
-   iowrite32be(ippdexpcr, rcpm_ftm_addr);
+   if (endian == BIG_ENDIAN)
+   ippdexpcr = ioread32be(rcpm_ftm_addr);
+   else
+   ippdexpcr = ioread32(rcpm_ftm_addr);
+   ippdexpcr |= flextimer;
+   if (endian == BIG_ENDIAN)
+   iowrite32be(ippdexpcr, rcpm_ftm_addr);

[PATCH 2/9] armv8: pm: Fix issue of rcpm driver wrongly program other IP control bits

From: Ran Wang 

When rcpm driver get target register data from DTS property 'fsl,
rcpm-wakeup' (second value), it directly write that data to register
RCPM_IPPDEXPCRx rather than 'OR' the value read from it before. This
operation will over-write those non-related IP control bit which
might have been programmed, should be prevented.

Signed-off-by: Ran Wang 
Signed-off-by: Yinbo Zhu 
---
 drivers/soc/fsl/rcpm.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index ff0477b..39eabfb 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -75,6 +75,7 @@ static void rcpm_wakeup_fixup(struct device *dev, void *data)
 static int rcpm_suspend_prepare(void)
 {
int i;
+   u32 val;
 
WARN_ON(!rcpm);
 
@@ -84,9 +85,12 @@ static int rcpm_suspend_prepare(void)
dpm_for_each_dev(NULL, rcpm_wakeup_fixup);
 
for (i = 0; i < rcpm->ipp_num; i++) {
-   rcpm_reg_write(rcpm->ippdexpcr_offset + 4 * i,
-  rcpm->ippdexpcr[i]);
-   pr_debug("ippdexpcr%d = 0x%x\n", i, rcpm->ippdexpcr[i]);
+   if (rcpm->ippdexpcr[i]) {
+   val = rcpm_reg_read(rcpm->ippdexpcr_offset + 4 * i);
+   rcpm_reg_write(rcpm->ippdexpcr_offset + 4 * i,
+  val | rcpm->ippdexpcr[i]);
+   pr_debug("ippdexpcr%d = 0x%x\n", i, rcpm->ippdexpcr[i]);
+   }
}
 
return 0;
-- 
1.7.1

[PATCH 3/9] soc: fsl: set rcpm bit for FTM

From: Zhang Ying-22455 

Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
module of each platform has different big-end and little-end mode,
there need to set RCPM depending on the platform.

Signed-off-by: Zhang Ying-22455 
Signed-off-by: Yinbo Zhu 
---
 .../devicetree/bindings/timer/fsl,ftm-timer.txt|7 ++
 drivers/soc/fsl/layerscape/ftm_alarm.c |   92 ++-
 2 files changed, 94 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt 
b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
index aa8c402..15ead58 100644
--- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
@@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer
 Required properties:
 
 - compatible : should be "fsl,ftm-timer"
+ Possible compatibles for ARM:
+ "fsl,ls1012a-ftm"
+ "fsl,ls1021a-ftm"
+ "fsl,ls1043a-ftm"
+ "fsl,ls1046a-ftm"
+ "fsl,ls1088a-ftm"
+ "fsl,ls208xa-ftm"
 - reg : Specifies base physical address and size of the register sets for the
   clock event device and clock source device.
 - interrupts : Should be the clock event device interrupt.
diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c 
b/drivers/soc/fsl/layerscape/ftm_alarm.c
index 6f9882f..811dcfa 100644
--- a/drivers/soc/fsl/layerscape/ftm_alarm.c
+++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define FTM_SC 0x00
 #define FTM_SC_CLK_SHIFT   3
@@ -40,6 +43,59 @@
 static u32 alarm_freq;
 static bool big_endian;
 
+enum pmu_endian_type {
+   BIG_ENDIAN,
+   LITTLE_ENDIAN,
+};
+
+struct rcpm_cfg {
+   enum pmu_endian_type big_endian; /* Big/Little endian of PMU module */
+
+   /* FlexTimer1 is not powerdown during device LPM20 */
+   u32 flextimer_set_bit;
+};
+
+static struct rcpm_cfg ls1012a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1021a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1043a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1046a_rcpm_cfg = {
+   .big_endian = BIG_ENDIAN,
+   .flextimer_set_bit = 0x2,
+};
+
+static struct rcpm_cfg ls1088a_rcpm_cfg = {
+   .big_endian = LITTLE_ENDIAN,
+   .flextimer_set_bit = 0x4000,
+};
+
+static struct rcpm_cfg ls208xa_rcpm_cfg = {
+   .big_endian = LITTLE_ENDIAN,
+   .flextimer_set_bit = 0x4000,
+};
+
+static const struct of_device_id ippdexpcr_of_match[] = {
+   { .compatible = "fsl,ls1012a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1021a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1043a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1046a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls1088a-ftm", .data = _rcpm_cfg},
+   { .compatible = "fsl,ls208xa-ftm", .data = _rcpm_cfg},
+   {},
+};
+MODULE_DEVICE_TABLE(of, ippdexpcr_of_match);
+
 static inline u32 ftm_readl(void __iomem *addr)
 {
if (big_endian)
@@ -214,7 +270,10 @@ static int ftm_alarm_probe(struct platform_device *pdev)
struct resource *r;
int irq;
int ret;
-   u32 ippdexpcr;
+   struct rcpm_cfg *rcpm_cfg;
+   u32 ippdexpcr, flextimer;
+   const struct of_device_id *of_id;
+   enum pmu_endian_type endian;
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
@@ -224,14 +283,32 @@ static int ftm_alarm_probe(struct platform_device *pdev)
if (IS_ERR(ftm1_base))
return PTR_ERR(ftm1_base);
 
+   of_id = of_match_node(ippdexpcr_of_match, np);
+   if (!of_id)
+   return -ENODEV;
+
+   rcpm_cfg = devm_kzalloc(>dev, sizeof(*rcpm_cfg), GFP_KERNEL);
+   if (!rcpm_cfg)
+   return -ENOMEM;
+
+   rcpm_cfg = (struct rcpm_cfg *)of_id->data;
+   endian = rcpm_cfg->big_endian;
+   flextimer = rcpm_cfg->flextimer_set_bit;
+
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "FlexTimer1");
if (r) {
rcpm_ftm_addr = devm_ioremap_resource(>dev, r);
if (IS_ERR(rcpm_ftm_addr))
return PTR_ERR(rcpm_ftm_addr);
-   ippdexpcr = ioread32be(rcpm_ftm_addr);
-   ippdexpcr |= 0x2;
-   iowrite32be(ippdexpcr, rcpm_ftm_addr);
+   if (endian == BIG_ENDIAN)
+   ippdexpcr = ioread32be(rcpm_ftm_addr);
+   else
+   ippdexpcr = ioread32(rcpm_ftm_addr);
+   ippdexpcr |= flextimer;
+   if (endian == BIG_ENDIAN)
+   iowrite32be(ippdexpcr, rcpm_ftm_addr);
+   else
+   iowrite32(ippdexpcr,

[PATCH 1/9] armv8: pm: add rcpm module support

From: Yuantian Tang 

The Run Control and Power Management (RCPM) module communicates
with embedded cores, coherency modules, and other device platform
module to provide run control and power management functionality

Signed-off-by: Tang Yuantian 
Signed-off-by: Yinbo Zhu 
---
 drivers/soc/fsl/Makefile |1 +
 drivers/soc/fsl/rcpm.c   |  153 ++
 2 files changed, 154 insertions(+), 0 deletions(-)
 create mode 100644 drivers/soc/fsl/rcpm.c

diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 629dab8..68fcd71 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_FSL_DPAA) += qbman/
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_SUSPEND)  += rcpm.o
 obj-$(CONFIG_FSL_GUTS) += guts.o
 obj-$(CONFIG_FSL_LS2_CONSOLE)  += ls2-console/
 obj-$(CONFIG_LS_SOC_DRIVERS)   += layerscape/
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..ff0477b
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2016 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#define pr_fmt(fmt) "RCPM: %s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* RCPM register offset */
+#define RCPM_IPPDEXPCR00x140
+
+#define RCPM_WAKEUP_CELL_SIZE  2
+
+struct rcpm_config {
+   int ipp_num;
+   int ippdexpcr_offset;
+   u32 ippdexpcr[2];
+   void *rcpm_reg_base;
+};
+
+static struct rcpm_config *rcpm;
+
+static inline void rcpm_reg_write(u32 offset, u32 value)
+{
+   iowrite32be(value, rcpm->rcpm_reg_base + offset);
+}
+
+static inline u32 rcpm_reg_read(u32 offset)
+{
+   return ioread32be(rcpm->rcpm_reg_base + offset);
+}
+
+static void rcpm_wakeup_fixup(struct device *dev, void *data)
+{
+   struct device_node *node = dev ? dev->of_node : NULL;
+   u32 value[RCPM_WAKEUP_CELL_SIZE];
+   int ret, i;
+
+   if (!dev || !node || !device_may_wakeup(dev))
+   return;
+
+   /*
+* Get the values in the "rcpm-wakeup" property.
+* Three values are:
+* The first is a pointer to the RCPM node.
+* The second is the value of the ippdexpcr0 register.
+* The third is the value of the ippdexpcr1 register.
+*/
+   ret = of_property_read_u32_array(node, "fsl,rcpm-wakeup",
+value, RCPM_WAKEUP_CELL_SIZE);
+   if (ret)
+   return;
+
+   pr_debug("wakeup source: the device %s\n", node->full_name);
+
+   for (i = 0; i < rcpm->ipp_num; i++)
+   rcpm->ippdexpcr[i] |= value[i + 1];
+}
+
+static int rcpm_suspend_prepare(void)
+{
+   int i;
+
+   WARN_ON(!rcpm);
+
+   for (i = 0; i < rcpm->ipp_num; i++)
+   rcpm->ippdexpcr[i] = 0;
+
+   dpm_for_each_dev(NULL, rcpm_wakeup_fixup);
+
+   for (i = 0; i < rcpm->ipp_num; i++) {
+   rcpm_reg_write(rcpm->ippdexpcr_offset + 4 * i,
+  rcpm->ippdexpcr[i]);
+   pr_debug("ippdexpcr%d = 0x%x\n", i, rcpm->ippdexpcr[i]);
+   }
+
+   return 0;
+}
+
+static int rcpm_suspend_notifier_call(struct notifier_block *bl,
+ unsigned long state,
+ void *unused)
+{
+   switch (state) {
+   case PM_SUSPEND_PREPARE:
+   rcpm_suspend_prepare();
+   break;
+   }
+
+   return NOTIFY_DONE;
+}
+
+static struct rcpm_config rcpm_default_config = {
+   .ipp_num = 1,
+   .ippdexpcr_offset = RCPM_IPPDEXPCR0,
+};
+
+static const struct of_device_id rcpm_matches[] = {
+   {
+   .compatible = "fsl,qoriq-rcpm-2.1",
+   .data = _default_config,
+   },
+   {}
+};
+
+static struct notifier_block rcpm_suspend_notifier = {
+   .notifier_call = rcpm_suspend_notifier_call,
+};
+
+static int __init layerscape_rcpm_init(void)
+{
+   const struct of_device_id *match;
+   struct device_node *np;
+
+   np = of_find_matching_node_and_match(NULL, rcpm_matches, );
+   if (!np) {
+   pr_err("Can't find the RCPM node.\n");
+   return -EINVAL;
+   }
+
+   if (match->data)
+   rcpm = (struct

[PATCH 1/9] armv8: pm: add rcpm module support

From: Yuantian Tang 

The Run Control and Power Management (RCPM) module communicates
with embedded cores, coherency modules, and other device platform
module to provide run control and power management functionality

Signed-off-by: Tang Yuantian 
Signed-off-by: Yinbo Zhu 
---
 drivers/soc/fsl/Makefile |1 +
 drivers/soc/fsl/rcpm.c   |  153 ++
 2 files changed, 154 insertions(+), 0 deletions(-)
 create mode 100644 drivers/soc/fsl/rcpm.c

diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 629dab8..68fcd71 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_FSL_DPAA) += qbman/
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_SUSPEND)  += rcpm.o
 obj-$(CONFIG_FSL_GUTS) += guts.o
 obj-$(CONFIG_FSL_LS2_CONSOLE)  += ls2-console/
 obj-$(CONFIG_LS_SOC_DRIVERS)   += layerscape/
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..ff0477b
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2016 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#define pr_fmt(fmt) "RCPM: %s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* RCPM register offset */
+#define RCPM_IPPDEXPCR00x140
+
+#define RCPM_WAKEUP_CELL_SIZE  2
+
+struct rcpm_config {
+   int ipp_num;
+   int ippdexpcr_offset;
+   u32 ippdexpcr[2];
+   void *rcpm_reg_base;
+};
+
+static struct rcpm_config *rcpm;
+
+static inline void rcpm_reg_write(u32 offset, u32 value)
+{
+   iowrite32be(value, rcpm->rcpm_reg_base + offset);
+}
+
+static inline u32 rcpm_reg_read(u32 offset)
+{
+   return ioread32be(rcpm->rcpm_reg_base + offset);
+}
+
+static void rcpm_wakeup_fixup(struct device *dev, void *data)
+{
+   struct device_node *node = dev ? dev->of_node : NULL;
+   u32 value[RCPM_WAKEUP_CELL_SIZE];
+   int ret, i;
+
+   if (!dev || !node || !device_may_wakeup(dev))
+   return;
+
+   /*
+* Get the values in the "rcpm-wakeup" property.
+* Three values are:
+* The first is a pointer to the RCPM node.
+* The second is the value of the ippdexpcr0 register.
+* The third is the value of the ippdexpcr1 register.
+*/
+   ret = of_property_read_u32_array(node, "fsl,rcpm-wakeup",
+value, RCPM_WAKEUP_CELL_SIZE);
+   if (ret)
+   return;
+
+   pr_debug("wakeup source: the device %s\n", node->full_name);
+
+   for (i = 0; i < rcpm->ipp_num; i++)
+   rcpm->ippdexpcr[i] |= value[i + 1];
+}
+
+static int rcpm_suspend_prepare(void)
+{
+   int i;
+
+   WARN_ON(!rcpm);
+
+   for (i = 0; i < rcpm->ipp_num; i++)
+   rcpm->ippdexpcr[i] = 0;
+
+   dpm_for_each_dev(NULL, rcpm_wakeup_fixup);
+
+   for (i = 0; i < rcpm->ipp_num; i++) {
+   rcpm_reg_write(rcpm->ippdexpcr_offset + 4 * i,
+  rcpm->ippdexpcr[i]);
+   pr_debug("ippdexpcr%d = 0x%x\n", i, rcpm->ippdexpcr[i]);
+   }
+
+   return 0;
+}
+
+static int rcpm_suspend_notifier_call(struct notifier_block *bl,
+ unsigned long state,
+ void *unused)
+{
+   switch (state) {
+   case PM_SUSPEND_PREPARE:
+   rcpm_suspend_prepare();
+   break;
+   }
+
+   return NOTIFY_DONE;
+}
+
+static struct rcpm_config rcpm_default_config = {
+   .ipp_num = 1,
+   .ippdexpcr_offset = RCPM_IPPDEXPCR0,
+};
+
+static const struct of_device_id rcpm_matches[] = {
+   {
+   .compatible = "fsl,qoriq-rcpm-2.1",
+   .data = _default_config,
+   },
+   {}
+};
+
+static struct notifier_block rcpm_suspend_notifier = {
+   .notifier_call = rcpm_suspend_notifier_call,
+};
+
+static int __init layerscape_rcpm_init(void)
+{
+   const struct of_device_id *match;
+   struct device_node *np;
+
+   np = of_find_matching_node_and_match(NULL, rcpm_matches, );
+   if (!np) {
+   pr_err("Can't find the RCPM node.\n");
+   return -EINVAL;
+   }
+
+   if (match->data)
+   rcpm = (struct rcpm_config *)match->data;
+   else
+

[PATCH v1 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain

According to a description from TRM, add all the power domains.

Signed-off-by: Elaine Zhang 
---
 include/dt-bindings/power/rk3228-power.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3228-power.h

diff --git a/include/dt-bindings/power/rk3228-power.h 
b/include/dt-bindings/power/rk3228-power.h
new file mode 100644
index ..fa1264d5a995
--- /dev/null
+++ b/include/dt-bindings/power/rk3228-power.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__
+#define __DT_BINDINGS_POWER_RK3228_POWER_H__
+
+/**
+ * RK3228 idle id Summary.
+ */
+
+#define RK3228_PD_CORE 0
+#define RK3228_PD_MSCH 1
+#define RK3228_PD_BUS  2
+#define RK3228_PD_SYS  3
+#define RK3228_PD_VIO  4
+#define RK3228_PD_VOP  5
+#define RK3228_PD_VPU  6
+#define RK3228_PD_RKVDEC   7
+#define RK3228_PD_GPU  8
+#define RK3228_PD_PERI 9
+#define RK3228_PD_GMAC 10
+
+#endif
-- 
1.9.1

[PATCH v1 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain

According to a description from TRM, add all the power domains.

Signed-off-by: Elaine Zhang 
---
 include/dt-bindings/power/rk3228-power.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3228-power.h

diff --git a/include/dt-bindings/power/rk3228-power.h 
b/include/dt-bindings/power/rk3228-power.h
new file mode 100644
index ..fa1264d5a995
--- /dev/null
+++ b/include/dt-bindings/power/rk3228-power.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__
+#define __DT_BINDINGS_POWER_RK3228_POWER_H__
+
+/**
+ * RK3228 idle id Summary.
+ */
+
+#define RK3228_PD_CORE 0
+#define RK3228_PD_MSCH 1
+#define RK3228_PD_BUS  2
+#define RK3228_PD_SYS  3
+#define RK3228_PD_VIO  4
+#define RK3228_PD_VOP  5
+#define RK3228_PD_VPU  6
+#define RK3228_PD_RKVDEC   7
+#define RK3228_PD_GPU  8
+#define RK3228_PD_PERI 9
+#define RK3228_PD_GMAC 10
+
+#endif
-- 
1.9.1

[PATCH v1 10/13] soc: rockchip: power-domain: add power domain support for rk3228

This driver is modified to support RK3228 SoC.

Signed-off-by: Elaine Zhang 
---
 drivers/soc/rockchip/pm_domains.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 99a2dd8a7801..90dcd5e21ae6 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -729,6 +730,20 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
[RK3128_PD_GPU] = DOMAIN_RK3288(1, 1, 3, false),
 };
 
+static const struct rockchip_domain_info rk3228_pm_domains[] = {
+   [RK3228_PD_CORE]= DOMAIN_RK3036(0, 0, 16, true),
+   [RK3228_PD_MSCH]= DOMAIN_RK3036(1, 1, 17, true),
+   [RK3228_PD_BUS] = DOMAIN_RK3036(2, 2, 18, true),
+   [RK3228_PD_SYS] = DOMAIN_RK3036(3, 3, 19, true),
+   [RK3228_PD_VIO] = DOMAIN_RK3036(4, 4, 20, false),
+   [RK3228_PD_VOP] = DOMAIN_RK3036(5, 5, 21, false),
+   [RK3228_PD_VPU] = DOMAIN_RK3036(6, 6, 22, false),
+   [RK3228_PD_RKVDEC]  = DOMAIN_RK3036(7, 7, 23, false),
+   [RK3228_PD_GPU] = DOMAIN_RK3036(8, 8, 24, false),
+   [RK3228_PD_PERI]= DOMAIN_RK3036(9, 9, 25, true),
+   [RK3228_PD_GMAC]= DOMAIN_RK3036(10, 10, 26, false),
+};
+
 static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC]= DOMAIN_RK3288(14, 10, 9, false),
@@ -816,6 +831,15 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
.domain_info = rk3128_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3228_pmu = {
+   .req_offset = 0x40c,
+   .idle_offset = 0x488,
+   .ack_offset = 0x488,
+
+   .num_domains = ARRAY_SIZE(rk3228_pm_domains),
+   .domain_info = rk3228_pm_domains,
+};
+
 static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -899,6 +923,10 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
.data = (void *)_pmu,
},
{
+   .compatible = "rockchip,rk3228-power-controller",
+   .data = (void *)_pmu,
+   },
+   {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)_pmu,
},
-- 
1.9.1

[PATCH v1 10/13] soc: rockchip: power-domain: add power domain support for rk3228

This driver is modified to support RK3228 SoC.

Signed-off-by: Elaine Zhang 
---
 drivers/soc/rockchip/pm_domains.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 99a2dd8a7801..90dcd5e21ae6 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -729,6 +730,20 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
[RK3128_PD_GPU] = DOMAIN_RK3288(1, 1, 3, false),
 };
 
+static const struct rockchip_domain_info rk3228_pm_domains[] = {
+   [RK3228_PD_CORE]= DOMAIN_RK3036(0, 0, 16, true),
+   [RK3228_PD_MSCH]= DOMAIN_RK3036(1, 1, 17, true),
+   [RK3228_PD_BUS] = DOMAIN_RK3036(2, 2, 18, true),
+   [RK3228_PD_SYS] = DOMAIN_RK3036(3, 3, 19, true),
+   [RK3228_PD_VIO] = DOMAIN_RK3036(4, 4, 20, false),
+   [RK3228_PD_VOP] = DOMAIN_RK3036(5, 5, 21, false),
+   [RK3228_PD_VPU] = DOMAIN_RK3036(6, 6, 22, false),
+   [RK3228_PD_RKVDEC]  = DOMAIN_RK3036(7, 7, 23, false),
+   [RK3228_PD_GPU] = DOMAIN_RK3036(8, 8, 24, false),
+   [RK3228_PD_PERI]= DOMAIN_RK3036(9, 9, 25, true),
+   [RK3228_PD_GMAC]= DOMAIN_RK3036(10, 10, 26, false),
+};
+
 static const struct rockchip_domain_info rk3288_pm_domains[] = {
[RK3288_PD_VIO] = DOMAIN_RK3288(7, 7, 4, false),
[RK3288_PD_HEVC]= DOMAIN_RK3288(14, 10, 9, false),
@@ -816,6 +831,15 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
.domain_info = rk3128_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3228_pmu = {
+   .req_offset = 0x40c,
+   .idle_offset = 0x488,
+   .ack_offset = 0x488,
+
+   .num_domains = ARRAY_SIZE(rk3228_pm_domains),
+   .domain_info = rk3228_pm_domains,
+};
+
 static const struct rockchip_pmu_info rk3288_pmu = {
.pwr_offset = 0x08,
.status_offset = 0x0c,
@@ -899,6 +923,10 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
.data = (void *)_pmu,
},
{
+   .compatible = "rockchip,rk3228-power-controller",
+   .data = (void *)_pmu,
+   },
+   {
.compatible = "rockchip,rk3288-power-controller",
.data = (void *)_pmu,
},
-- 
1.9.1

[PATCH v1 09/13] dt-bindings: add binding for rk3228 power domains

Add binding documentation for the power domains
found on Rockchip RK3228 SoCs.

Signed-off-by: Elaine Zhang 
---
 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt 
b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 9a3f5fd36a80..affe36dcfa17 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
 - compatible: Should be one of the following.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
+   "rockchip,rk3228-power-controller" - for RK3228 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -21,6 +22,7 @@ Required properties for power domain sub nodes:
 - reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power 
domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power 
domain.
+   "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power 
domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power 
domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power 
domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power 
domain.
@@ -99,6 +101,7 @@ power domain to use.
 The index should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power 
domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power 
domain.
+   "include/dt-bindings/power/rk3128-power.h" - for rk3228 type power 
domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power 
domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power 
domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power 
domain.
-- 
1.9.1

[PATCH v1 09/13] dt-bindings: add binding for rk3228 power domains

Add binding documentation for the power domains
found on Rockchip RK3228 SoCs.

Signed-off-by: Elaine Zhang 
---
 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt 
b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 9a3f5fd36a80..affe36dcfa17 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
 - compatible: Should be one of the following.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
+   "rockchip,rk3228-power-controller" - for RK3228 SoCs.
"rockchip,rk3288-power-controller" - for RK3288 SoCs.
"rockchip,rk3328-power-controller" - for RK3328 SoCs.
"rockchip,rk3366-power-controller" - for RK3366 SoCs.
@@ -21,6 +22,7 @@ Required properties for power domain sub nodes:
 - reg: index of the power domain, should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power 
domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power 
domain.
+   "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power 
domain.
"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power 
domain.
"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power 
domain.
"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power 
domain.
@@ -99,6 +101,7 @@ power domain to use.
 The index should use macros in:
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power 
domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power 
domain.
+   "include/dt-bindings/power/rk3128-power.h" - for rk3228 type power 
domain.
"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power 
domain.
"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power 
domain.
"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power 
domain.
-- 
1.9.1

[PATCH v1 13/13] soc: rockchip: power-domain: add power domain support for px30

This driver is modified to support PX30 SoC.

Signed-off-by: Elaine Zhang 
Signed-off-by: Finley Xiao 
---
 drivers/soc/rockchip/pm_domains.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 90dcd5e21ae6..d0c5615132e3 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +115,9 @@ struct rockchip_pmu {
.active_wakeup = wakeup,\
 }
 
+#define DOMAIN_PX30(pwr, status, req, wakeup)  \
+   DOMAIN_M(pwr, status, req, (req) + 16, req, wakeup)
+
 #define DOMAIN_RK3288(pwr, status, req, wakeup)\
DOMAIN(pwr, status, req, req, (req) + 16, wakeup)
 
@@ -712,6 +716,17 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
return error;
 }
 
+static const struct rockchip_domain_info px30_pm_domains[] = {
+   [PX30_PD_USB]   = DOMAIN_PX30(5, 5, 10, false),
+   [PX30_PD_SDCARD]= DOMAIN_PX30(8, 8, 9, false),
+   [PX30_PD_GMAC]  = DOMAIN_PX30(10, 10, 6, false),
+   [PX30_PD_MMC_NAND]  = DOMAIN_PX30(11, 11, 5, false),
+   [PX30_PD_VPU]   = DOMAIN_PX30(12, 12, 14, false),
+   [PX30_PD_VO]= DOMAIN_PX30(13, 13, 7, false),
+   [PX30_PD_VI]= DOMAIN_PX30(14, 14, 8, false),
+   [PX30_PD_GPU]   = DOMAIN_PX30(15, 15, 2, false),
+};
+
 static const struct rockchip_domain_info rk3036_pm_domains[] = {
[RK3036_PD_MSCH]= DOMAIN_RK3036(14, 23, 30, true),
[RK3036_PD_CORE]= DOMAIN_RK3036(13, 17, 24, false),
@@ -811,6 +826,17 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
[RK3399_PD_SDIOAUDIO]   = DOMAIN_RK3399(31, 31, 29, true),
 };
 
+static const struct rockchip_pmu_info px30_pmu = {
+   .pwr_offset = 0x18,
+   .status_offset = 0x20,
+   .req_offset = 0x64,
+   .idle_offset = 0x6c,
+   .ack_offset = 0x6c,
+
+   .num_domains = ARRAY_SIZE(px30_pm_domains),
+   .domain_info = px30_pm_domains,
+};
+
 static const struct rockchip_pmu_info rk3036_pmu = {
.req_offset = 0x148,
.idle_offset = 0x14c,
@@ -915,6 +941,10 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
 
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
{
+   .compatible = "rockchip,px30-power-controller",
+   .data = (void *)_pmu,
+   },
+   {
.compatible = "rockchip,rk3036-power-controller",
.data = (void *)_pmu,
},
-- 
1.9.1

[PATCH v1 12/13] dt-bindings: add binding for px30 power domains