[PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms

2016-05-30 Thread Arnd Bergmann
From: Yangbo Lu 

The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.

This patch adds GUTS driver to manage and access global utilities
block.

[arnd turned this into a platform_driver registering a soc_device
 rather than providing an ad-hoc interface for soc-id]

Signed-off-by: Yangbo Lu 
Signed-off-by: Arnd Bergmann 

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index ..33d331cac8d6
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,15 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+   bool "NXP Layerscale SoC identification"
+   depends on PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
+   default PPC_FSL || SOC_LS1021A || ARCH_LAYERSCAPE
+   select SOC_BUS
+   help
+ This registers a SoC device for NXP (formerly Freescale)
+ Layerscape devices, making information about the system
+ available in /sys/devices/soc/
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307fd92c1..02afb7f980f6 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index ..2f30698f5bcf
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,130 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GUTS_PVR   0x0a0
+#define GUTS_SVR   0x0a4
+
+struct guts {
+   void __iomem *regs;
+   bool little_endian;
+   struct soc_device_attribute soc;
+};
+
+static u32 fsl_guts_get_svr(struct guts *guts)
+{
+   if (guts->little_endian)
+   return ioread32(guts->regs + GUTS_SVR);
+   else
+   return ioread32be(guts->regs + GUTS_SVR);
+}
+
+static u32 fsl_guts_get_pvr(struct guts *guts)
+{
+   if (guts->little_endian)
+   return ioread32(guts->regs + GUTS_PVR);
+   else
+   return ioread32be(guts->regs + GUTS_PVR);
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+   /* For T4 & B4 Series SOCs */
+   { .compatible = "fsl,qoriq-device-config-1.0", .data = "T4/B4 series" },
+   /* For P Series SOCs */
+   { .compatible = "fsl,p1010-guts", .data = "P1010/P1014" },
+   { .compatible = "fsl,p1020-guts", .data = "P1020/P1011" },
+   { .compatible = "fsl,p1021-guts", .data = "P1021/P1012" },
+   { .compatible = "fsl,p1022-guts", .data = "P1022/P1013" },
+   { .compatible = "fsl,p1023-guts", .data = "P1013/P1017" },
+   { .compatible = "fsl,p2020-guts", .data = "P2010/P2020" },
+   { .compatible = "fsl,qoriq-device-config-2.0", .data = "P series" },
+   /* For BSC Series SOCs */
+   { .compatible = "fsl,bsc9131-guts", .data = "BSC9131 Qonverge" },
+   { .compatible = "fsl,bsc9132-guts", .data = "BSC9132 Qonverge" },
+   /* For MPC85xx Series SOCs */
+   { .compatible = "fsl,mpc8536-guts", .data = "PowerPC MPC8536" },
+   { .compatible = "fsl,mpc8544-guts", .data = "PowerPC MPC8544" },
+   { .compatible = "fsl,mpc8548-guts", .data = "PowerPC MPC8548" },
+   { .compatible = "fsl,mpc8568-guts", .data = "PowerPC MPC8568" },
+   { .compatible = "fsl,mpc8569-guts", .data = "PowerPC MPC8569" },
+   { .compatible = "fsl,mpc8572-guts", .data = "PowerPC MPC8572" },
+   /* For Layerscape Series SOCs */
+   { .compatible = "fsl,ls1021a-dcfg", .data = "Layerscape LS1021A" },
+   { .compatible = "fsl,ls1043a-dcfg", .data = "Layerscape LS1043A" },
+   { .compatible = "fsl,ls2080a-dcfg", .data = "Layerscape LS2080A" },
+   {}
+};
+
+static void fsl_guts_init(struct device *dev, struct guts *guts)
+{
+   const struct of_device_i

[PATCH 3/4] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

2016-05-30 Thread Arnd Bergmann
This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
for the NXP QorIQ T4240 in the detection of the host device version.

Unfortunately, this device cannot be detected using the compatible
string, as we have to support existing DTS files that use the generic
"fsl,t4240-esdhc" identifier but that have other host versions that
are correctly detected.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -73,14 +73,16 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
 static u16 esdhc_readw_fixup(struct sdhci_host *host,
 int spec_reg, u32 value)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
 
if (spec_reg == SDHCI_HOST_VERSION)
-   ret = value & 0x;
-   else
-   ret = (value >> shift) & 0x;
-   return ret;
+   return esdhc->vendor_ver << SDHCI_VENDOR_VER_SHIFT |
+  esdhc->spec_ver;
+
+   return (value >> shift) & 0x;
 }
 
 static u8 esdhc_readb_fixup(struct sdhci_host *host,
@@ -562,16 +564,32 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata 
= {
.ops = &sdhci_esdhc_le_ops,
 };
 
+#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | 
SDHCI_SPEC_200)
+static const struct soc_device_attribute esdhc_t4240_quirk = {
+   /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
+   { .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
+ .data = (void *)(uintptr_t)(T4240_HOST_VER) },
+   { },
+};
+
 static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
 {
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
-   u16 host_ver;
 
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
 
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+   if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
+   struct soc_device_attribute *match;
+
+   match = soc_device_match(&esdhc_t4240_quirk);
+   if (match)
+   host_ver = (uintptr_t)match->data;
+   }
+
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
 SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;



Re: [RFC PATCH 1/2] sched: encapsulate priority changes in a sched_set_prio static function

2016-05-30 Thread Mathieu Desnoyers
- On May 27, 2016, at 5:16 PM, Julien Desfossez jdesfos...@efficios.com 
wrote:

> Currently, the priority of tasks is modified directly in the scheduling
> functions. Encapsulate priority updates to enable instrumentation of
> priority changes. This will enable analysis of real-time scheduling
> delays per thread priority, which cannot be performed accurately if we
> only trace the priority of the currently scheduled processes.
> 
> The call sites that modify the priority of a task are mostly system
> calls: sched_setscheduler, sched_setattr, sched_process_fork and
> set_user_nice. Priority can also be dynamically boosted through
> priority inheritance of rt_mutex by rt_mutex_setprio.
> 
> Signed-off-by: Julien Desfossez 

Reviewed-by: Mathieu Desnoyers 

> ---
> include/linux/sched.h |  3 ++-
> kernel/sched/core.c   | 19 +--
> 2 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 52c4847..48b35c0 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1409,7 +1409,8 @@ struct task_struct {
> #endif
>   int on_rq;
> 
> - int prio, static_prio, normal_prio;
> + int prio; /* Updated through sched_set_prio() */
> + int static_prio, normal_prio;
>   unsigned int rt_priority;
>   const struct sched_class *sched_class;
>   struct sched_entity se;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d1f7149..6946b8f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2230,6 +2230,11 @@ int sysctl_schedstats(struct ctl_table *table, int 
> write,
> #endif
> #endif
> 
> +static void sched_set_prio(struct task_struct *p, int prio)
> +{
> + p->prio = prio;
> +}
> +
> /*
>  * fork()/clone()-time setup:
>  */
> @@ -2249,7 +2254,7 @@ int sched_fork(unsigned long clone_flags, struct
> task_struct *p)
>   /*
>* Make sure we do not leak PI boosting priority to the child.
>*/
> - p->prio = current->normal_prio;
> + sched_set_prio(p, current->normal_prio);
> 
>   /*
>* Revert to default priority/policy on fork if requested.
> @@ -2262,7 +2267,8 @@ int sched_fork(unsigned long clone_flags, struct
> task_struct *p)
>   } else if (PRIO_TO_NICE(p->static_prio) < 0)
>   p->static_prio = NICE_TO_PRIO(0);
> 
> - p->prio = p->normal_prio = __normal_prio(p);
> + p->normal_prio = __normal_prio(p);
> + sched_set_prio(p, p->normal_prio);
>   set_load_weight(p);
> 
>   /*
> @@ -3477,7 +3483,7 @@ void rt_mutex_setprio(struct task_struct *p, int prio)
>   p->sched_class = &fair_sched_class;
>   }
> 
> - p->prio = prio;
> + sched_set_prio(p, prio);
> 
>   if (running)
>   p->sched_class->set_curr_task(rq);
> @@ -3524,7 +3530,7 @@ void set_user_nice(struct task_struct *p, long nice)
>   p->static_prio = NICE_TO_PRIO(nice);
>   set_load_weight(p);
>   old_prio = p->prio;
> - p->prio = effective_prio(p);
> + sched_set_prio(p, effective_prio(p));
>   delta = p->prio - old_prio;
> 
>   if (queued) {
> @@ -3731,9 +3737,10 @@ static void __setscheduler(struct rq *rq, struct
> task_struct *p,
>* sched_setscheduler().
>*/
>   if (keep_boost)
> - p->prio = rt_mutex_get_effective_prio(p, normal_prio(p));
> + sched_set_prio(p, rt_mutex_get_effective_prio(p,
> + normal_prio(p)));
>   else
> - p->prio = normal_prio(p);
> + sched_set_prio(p, normal_prio(p));
> 
>   if (dl_prio(p->prio))
>   p->sched_class = &dl_sched_class;
> --
> 1.9.1

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


Re: [RFC PATCH 2/2] tracing: add sched_set_prio tracepoint

2016-05-30 Thread Mathieu Desnoyers
- On May 27, 2016, at 5:16 PM, Julien Desfossez jdesfos...@efficios.com 
wrote:

> This tracepoint allows to keep track of all priority changes made by all
> sites that can change this value. The impacted system calls are
> sched_setscheduler, sched_setattr, sched_process_fork and set_user_nice.
> The priority inheritance mechanism from rt_mutex gets also instrumented
> with this tracepoint even though there is a dedicated tracepoint for it
> (sched_pi_setprio).
> 
> This allows analysis of real-time scheduling delays per thread priority,
> which cannot be performed accurately if we only trace the priority of
> the currently scheduled processes.
> 
> Here is an example of what is output by ftrace when we change the
> priority of a running process:
> sys_sched_setscheduler(pid: 1c52, policy: 2, param: 7ffc22e20980)
> sched_set_prio: comm=burnP6 pid=7250 oldprio=120 newprio=39
> sys_sched_setscheduler -> 0x0
> sched_switch: prev_comm=chrt prev_pid=7268 prev_prio=120
>  prev_state=R ==> next_comm=burnP6 next_pid=7250
>  next_prio=39
> 
> Signed-off-by: Julien Desfossez 

Reviewed-by: Mathieu Desnoyers 

> ---
> include/trace/events/sched.h | 21 -
> kernel/sched/core.c  |  1 +
> 2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> index 9b90c57..3b83ddb 100644
> --- a/include/trace/events/sched.h
> +++ b/include/trace/events/sched.h
> @@ -407,11 +407,7 @@ DEFINE_EVENT(sched_stat_runtime, sched_stat_runtime,
>TP_PROTO(struct task_struct *tsk, u64 runtime, u64 vruntime),
>TP_ARGS(tsk, runtime, vruntime));
> 
> -/*
> - * Tracepoint for showing priority inheritance modifying a tasks
> - * priority.
> - */
> -TRACE_EVENT(sched_pi_setprio,
> +DECLARE_EVENT_CLASS(sched_prio_template,
> 
>   TP_PROTO(struct task_struct *tsk, int newprio),
> 
> @@ -436,6 +432,21 @@ TRACE_EVENT(sched_pi_setprio,
>   __entry->oldprio, __entry->newprio)
> );
> 
> +/*
> + * Tracepoint for showing priority inheritance modifying a tasks
> + * priority.
> + */
> +DEFINE_EVENT(sched_prio_template, sched_pi_setprio,
> + TP_PROTO(struct task_struct *tsk, int newprio),
> + TP_ARGS(tsk, newprio));
> +
> +/*
> + * Tracepoint for priority changes of a task.
> + */
> +DEFINE_EVENT(sched_prio_template, sched_set_prio,
> + TP_PROTO(struct task_struct *tsk, int newprio),
> + TP_ARGS(tsk, newprio));
> +
> #ifdef CONFIG_DETECT_HUNG_TASK
> TRACE_EVENT(sched_process_hang,
>   TP_PROTO(struct task_struct *tsk),
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 6946b8f..45fbaab 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2232,6 +2232,7 @@ int sysctl_schedstats(struct ctl_table *table, int 
> write,
> 
> static void sched_set_prio(struct task_struct *p, int prio)
> {
> + trace_sched_set_prio(p, prio);
>   p->prio = prio;
> }
> 
> --
> 1.9.1

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


[PATCH 4/4] Revert "powerpc/fsl: Move fsl_guts.h out of arch/powerpc"

2016-05-30 Thread Arnd Bergmann
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.

This reverts commit 948486544713492f00ac8a9572909101ea892cb0.

Signed-off-by: Arnd Bergmann 
---
This part of the series is not required for the eSDHC quirk,
but it restores the asm/fsl_guts.h header so it doesn't accidentally
get abused for this in the future. I found two drivers outside of
arch/powerpc that already accessed the registers directly, but the
functions look fairly contained, and can be easily hidden in an
#ifdef CONFIG_PPC

diff --git a/include/linux/fsl/guts.h b/arch/powerpc/include/asm/fsl_guts.h
similarity index 99%
rename from include/linux/fsl/guts.h
rename to arch/powerpc/include/asm/fsl_guts.h
index 649e9171a9b3..a67413c52701 100644
--- a/include/linux/fsl/guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -12,10 +12,9 @@
  * option) any later version.
  */
 
-#ifndef __FSL_GUTS_H__
-#define __FSL_GUTS_H__
-
-#include 
+#ifndef __ASM_POWERPC_FSL_GUTS_H__
+#define __ASM_POWERPC_FSL_GUTS_H__
+#ifdef __KERNEL__
 
 /**
  * Global Utility Registers.
@@ -295,3 +294,4 @@ struct ccsr_rcpm_v2 {
 };
 
 #endif
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index f61cbe235581..00f052e9f2a2 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -52,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "smp.h"
 
 #include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c 
b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
index f05325f0cc03..a812c0511252 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
@@ -14,8 +14,8 @@
 #include 
 #include 
 #include 
-#include 
 
+#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 3f4dad18..453ddda00fce 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -28,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c 
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 371df822e88e..6ac986d3f8a3 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -16,7 +16,6 @@
  * kind, whether express or implied.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -26,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "smp.h"
 
diff --git a/arch/powerpc/platforms/85xx/p1022_rdk.c 
b/arch/powerpc/platforms/85xx/p1022_rdk.c
index 5087becaa8bc..680232d6ba48 100644
--- a/arch/powerpc/platforms/85xx/p1022_rdk.c
+++ b/arch/powerpc/platforms/85xx/p1022_rdk.c
@@ -12,7 +12,6 @@
  * kind, whether express or implied.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -22,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "smp.h"
 
 #include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/smp.c 
b/arch/powerpc/platforms/85xx/smp.c
index fe9f19e5e935..6bd3a292e790 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -26,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c 
b/arch/powerpc/platforms/85xx/twr_p102x.c
index 71bc255b4324..2cac45f72d24 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -24,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c 
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 957473e5c8e5..761c81476957 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -39,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mpc86xx.h"
 
diff --git a/arch/powerpc/sysdev/fsl_rcpm.c b/arch/powerpc/sysdev/fsl_rcpm.c
index 9259a94f70e1..8af22187cb25 100644
--- a/arch/powerpc/sysdev/fsl_rcpm.c
+++ b/arch/powerpc/sysdev/fsl_rcpm.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 58566a17944a..f311bd399672 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -12,7 +12,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #inclu

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

2016-05-30 Thread Heikki Krogerus
Hi guys,

I'm attaching a diff instead of full v3. I'm not yet adding attributes
for the reset and cable_reset. I still don't understand what is the
case where the userspace would need to be able to tricker reset? Why
isn't it enough for the userspace to be able to enter/exit modes?
Oliver! Can you please comment?

Guenter, I removed the driver_data you proposed and changed the API
so that the struct typec_capability is passed to the function pointers
instead of struct typec_port. The driver_data pointer felt a bit
clumsy to me, as it was something extra that always had to be passed
to every function. Let me know if it's not OK for you.

I also made a change to the partner devices so that they always have
the port as their parent. That will have an effect on the location
where the partner device is exposed in sysfs (so now always under the
port). And because of that, I would like to get an OK from you guys.

I'm a bit concerned about the current API for adding the alternate
modes. Since we are passing the parent for an alternate mode as
struct device, it makes it possible for the caller to place it into
some wrong place. But I guess we can change the API even later.

We also need to decide how the alternate modes a port support are
exposed to the userspace. Do we just assume the port drivers will
create them as devices under the port device itself, just like
alternate modes of partners and cable plugs are exposed under the
partners and cable plugs? That works for me, but again, the class does
not have any effect on that, and it will be just a guideline. Maybe
we can add some kind of helpers and force the port drivers to use
them.

And finally, mostly as a reminder for myself. I didn't yet add
attributes for Try.SRC/SNK. So can we make it something like
"preferred_role" like I think you proposed Guenter? The
"current_data_role" I'm dropping.

So to summarize. There are still open questions regarding the required
attributes and attribute names and locations. Let's agree on those
quickly and then we can polish the patch.


Thanks,

-- 
heikki
diff --git a/drivers/usb/type-c/typec.c b/drivers/usb/type-c/typec.c
index 6836e97..41ad955 100644
--- a/drivers/usb/type-c/typec.c
+++ b/drivers/usb/type-c/typec.c
@@ -27,8 +27,6 @@ struct typec_port {
struct typec_partner*partner;
struct typec_cable  *cable;
 
-   void*driver_data;
-
unsigned intconnected:1;
 
int n_altmode;
@@ -101,29 +99,10 @@ static int
 typec_add_partner(struct typec_port *port, struct typec_partner *partner)
 {
struct device *dev = &partner->dev;
-   struct device *parent;
int ret;
 
-   /*
-* REVISIT: Maybe it would be better to make the port always as the
-* parent of the partner? Or not even that. Would it be enough to just
-* create the symlink to the partner like we do below in any case?
-*/
-   if (port->cable) {
-   if (port->cable->active) {
-   if (port->cable->sop_pp_controller)
-   parent = &port->cable->plug[1].dev;
-   else
-   parent = &port->cable->plug[0].dev;
-   } else {
-   parent = &port->cable->dev;
-   }
-   } else {
-   parent = &port->dev;
-   }
-
dev->class = &typec_class;
-   dev->parent = parent;
+   dev->parent = &port->dev;
dev->type = &typec_partner_dev_type;
dev_set_name(dev, "%s-partner", dev_name(&port->dev));
 
@@ -133,18 +112,6 @@ typec_add_partner(struct typec_port *port, struct 
typec_partner *partner)
return ret;
}
 
-   ret = typec_register_altmodes(dev, partner->alt_modes);
-   if (ret) {
-   device_unregister(dev);
-   return ret;
-   }
-
-   /* REVISIT: Creating symlink for the port device for now. */
-   ret = sysfs_create_link(&port->dev.kobj, &dev->kobj, "partner");
-   if (ret)
-   dev_WARN(&port->dev, "failed to create link to %s (%d)\n",
-dev_name(dev), ret);
-
port->partner = partner;
return 0;
 }
@@ -184,12 +151,6 @@ typec_add_plug(struct typec_port *port, struct typec_plug 
*plug)
return ret;
}
 
-   ret = typec_register_altmodes(dev, plug->alt_modes);
-   if (ret) {
-   device_unregister(dev);
-   return ret;
-   }
-
/* REVISIT: Is this useful? */
ret = sysfs_create_link(&port->dev.kobj, &dev->kobj, name);
if (ret)
@@ -278,7 +239,6 @@ static int typec_add_cable(struct typec_port *port, struct 
typec_cable *cable)
int ret;
 
dev->class = &typec_class;
-   /* REVISIT: We could have just the symlink also for the cable. */
dev->parent = &port->dev;
dev->type = &typec_cable_dev_type;
dev_set_name(dev,

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

2016-05-30 Thread Pramod Gurav
On 19 May 2016 at 15:42, Srinivas Kandagatla
 wrote:



> Fixes 4bb3cad7125b ("usb: host: ehci-msm: Register usb shutdown function")
> Signed-off-by: Srinivas Kandagatla 

Was seeing this crash while doing a reboot on db410c which is fixed
with this patch:

Tested-by: Pramod Gurav 


[PATCH v3 4/4] ARM: dts: amlogic: Enable Reset Controller on Meson8b platforms

2016-05-30 Thread Neil Armstrong
Update DTSI file to add the reset controller node.

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 2bfe401..fc4080d 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -46,6 +46,7 @@
 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -105,6 +106,12 @@
#interrupt-cells = <3>;
};
 
+   reset: reset-controller@c1104404 {
+   compatible = "amlogic,meson8b-reset";
+   reg = <0xc1104404 0x20>;
+   #reset-cells = <1>;
+   };
+
wdt: watchdog@c1109900 {
compatible = "amlogic,meson8b-wdt";
reg = <0xc1109900 0x8>;
-- 
2.7.0



[PATCH v3 1/4] reset: Add support for the Amlogic Meson SoC Reset Controller

2016-05-30 Thread Neil Armstrong
This patch adds the platform driver for the Amlogic Meson SoC Reset
Controller.

The Meson8b and GXBB SoCs are supported.

Signed-off-by: Neil Armstrong 
---
 drivers/reset/Makefile  |   1 +
 drivers/reset/reset-meson.c | 136 
 2 files changed, 137 insertions(+)
 create mode 100644 drivers/reset/reset-meson.c

diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index f173fc3..03dc1bb 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
+obj-$(CONFIG_ARCH_MESON) += reset-meson.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
new file mode 100644
index 000..c32f11a
--- /dev/null
+++ b/drivers/reset/reset-meson.c
@@ -0,0 +1,136 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_COUNT  8
+#define BITS_PER_REG   32
+
+struct meson_reset {
+   void __iomem *reg_base;
+   struct reset_controller_dev rcdev;
+};
+
+static int meson_reset_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   struct meson_reset *data =
+   container_of(rcdev, struct meson_reset, rcdev);
+   unsigned int bank = id / BITS_PER_REG;
+   unsigned int offset = id % BITS_PER_REG;
+   void __iomem *reg_addr = data->reg_base + (bank << 2);
+
+   if (bank >= REG_COUNT)
+   return -EINVAL;
+
+   writel(BIT(offset), reg_addr);
+
+   return 0;
+}
+
+static const struct reset_control_ops meson_reset_ops = {
+   .reset  = meson_reset_reset,
+};
+
+static const struct of_device_id meson_reset_dt_ids[] = {
+{ .compatible = "amlogic,meson8b-reset", },
+{ .compatible = "amlogic,meson-gxbb-reset", },
+{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, meson_reset_dt_ids);
+
+static int meson_reset_probe(struct platform_device *pdev)
+{
+   struct meson_reset *data;
+   struct resource *res;
+
+   data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOM

[PATCH v3 3/4] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-30 Thread Neil Armstrong
Update DTSI file to add the reset controller node.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 832815d..45e9c55 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "amlogic,meson-gxbb";
@@ -129,6 +130,12 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc110 0x0 0x10>;
 
+   reset: reset-controller@4404 {
+   compatible = "amlogic,meson-gxbb-reset";
+   reg = <0x0 0x04404 0x0 0x20>;
+   #reset-cells = <1>;
+   };
+
uart_A: serial@84c0 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x084c0 0x0 0x14>;
-- 
2.7.0



[PATCH v3 2/4] dt-bindings: reset: Add bindings for the Meson SoC Reset Controller

2016-05-30 Thread Neil Armstrong
Add DT bindings for the Meson SoC Reset Controller documentation and the
associated include file.

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 .../bindings/reset/amlogic,meson-reset.txt |  18 ++
 .../dt-bindings/reset/amlogic,meson-gxbb-reset.h   | 210 +
 include/dt-bindings/reset/amlogic,meson8b-reset.h  | 175 +
 3 files changed, 403 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
 create mode 100644 include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
 create mode 100644 include/dt-bindings/reset/amlogic,meson8b-reset.h

diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt 
b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
new file mode 100644
index 000..e746b63
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
@@ -0,0 +1,18 @@
+Amlogic Meson SoC Reset Controller
+===
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "amlogic,meson8b-reset" or "amlogic,meson-gxbb-reset"
+- reg: should contain the register address base
+- #reset-cells: 1, see below
+
+example:
+
+reset: reset-controller {
+   compatible = "amlogic,meson-gxbb-reset";
+   reg = <0x0 0x04404 0x0 0x20>;
+   #reset-cells = <1>;
+};
diff --git a/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h 
b/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
new file mode 100644
index 000..524d607
--- /dev/null
+++ b/include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
@@ -0,0 +1,210 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef _DT_BINDINGS_AMLOGIC_MESON_GXBB_RESET_H
+#define _DT_BINDINGS_AMLOGIC_MESON_GXBB_RESET_H
+
+/* RESET0  */
+#define RESET_HIU  0
+/* 1   */
+#define RESET_DOS_RESET2
+#define RESET_DDR_TOP  3
+#define RESET_DCU_RESET4
+#define RESET_VIU  5
+#define RESET_AIU  6
+#define RESET_VID_PLL_DIV  7
+/* 8   */
+#define RESET_PMUX 9
+#define RESET_VENC 10
+#define RESET_ASSIST   11
+#define RESET_AFI

[PATCH v3 0/4] Amlogic: Meson: Add reset controller

2016-05-30 Thread Neil Armstrong
Patchset to add and enable the reset controller driver on Meson SoCs platforms.

This reset controller has up to 256 reset lines with reset pulse generation 
only,
so the assert and deassert calls are not available.

Depends on the patch :
 - "reset: add devm_reset_controller_register API" [1]

Changes since v2 at 
http://lkml.kernel.org/r/1464169758-26975-1-git-send-email-narmstr...@baylibre.com
 :
- Get back __iomem in _reset() callback
- Get rid of MODULE_ALIAS

Changes since v1 at 
http://lkml.kernel.org/r/1463732875-23141-1-git-send-email-narmstr...@baylibre.com
 :
- Remove _gxbb_ in names
- Depends build on ARCH_MESON only
- Add meson8b compatible and bindings
- Re-indent dt-bindings headers
- Switch to devm_ reset controller register
- Remove platform "remove" callback
- Update Dual BSD/GPL file headers

Changes since the RFC at 
http://lkml.kernel.org/r/1463148012-25988-1-git-send-email-narmstr...@baylibre.com
 :
- Fix register mapping and bit defines in bindings header
- Remove assert and unassert calls
- Fix missing __iomem

[1] https://patchwork.kernel.org/patch/8988471/

Neil Armstrong (4):
  reset: Add support for the Amlogic Meson SoC Reset Controller
  dt-bindings: reset: Add bindings for the Meson SoC Reset Controller
  ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms
  ARM: dts: amlogic: Enable Reset Controller on Meson8b platforms

 .../bindings/reset/amlogic,meson-reset.txt |  18 ++
 arch/arm/boot/dts/meson8b.dtsi |   7 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   7 +
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-meson.c| 136 +
 .../dt-bindings/reset/amlogic,meson-gxbb-reset.h   | 210 +
 include/dt-bindings/reset/amlogic,meson8b-reset.h  | 175 +
 7 files changed, 554 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
 create mode 100644 drivers/reset/reset-meson.c
 create mode 100644 include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
 create mode 100644 include/dt-bindings/reset/amlogic,meson8b-reset.h

-- 
2.7.0



[PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

2016-05-30 Thread Neil Armstrong
Add watchdog specific driver for Amlogic Meson GXBB SoC.

Signed-off-by: Neil Armstrong 
---
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/meson_gxbb_wdt.c | 277 ++
 2 files changed, 278 insertions(+)
 create mode 100644 drivers/watchdog/meson_gxbb_wdt.c

diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 9bde095..7679d93 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
 obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
 obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
 obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
+obj-$(CONFIG_MESON_WATCHDOG) += meson_gxbb_wdt.o
 obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
 obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
 obj-$(CONFIG_LPC18XX_WATCHDOG) += lpc18xx_wdt.o
diff --git a/drivers/watchdog/meson_gxbb_wdt.c 
b/drivers/watchdog/meson_gxbb_wdt.c
new file mode 100644
index 000..9619c5e
--- /dev/null
+++ b/drivers/watchdog/meson_gxbb_wdt.c
@@ -0,0 +1,277 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_TIMEOUT10  /* seconds */
+
+#define GXBB_WDT_CTRL_REG  0x0
+#define GXBB_WDT_CTRL1_REG 0x4
+#define GXBB_WDT_TCNT_REG  0x8
+#define GXBB_WDT_RSET_REG  0xc
+
+#define GXBB_WDT_CTRL_EE_RESET_NOW BIT(26)
+
+#define GXBB_WDT_CTRL_CLKDIV_ENBIT(25)
+#define GXBB_WDT_CTRL_CLK_EN   BIT(24)
+#define GXBB_WDT_CTRL_IRQ_EN   BIT(23)
+#define GXBB_WDT_CTRL_EE_RESET BIT(21)
+#define GXBB_WDT_CTRL_XTAL_SEL (0)
+#define GXBB_WDT_CTRL_CLK81_SELBIT(19)
+#define GXBB_WDT_CTRL_EN   BIT(18)
+#define GXBB_WDT_CTRL_DIV_MASK (BIT(18) - 1)
+
+#define GXBB_WDT_CTRL1_GPIO_PULSE  BIT(17)
+#define GXBB_WDT_CTRL1_GPIO_POL_RESET_0BIT(16)
+#define GXBB_WDT_CTRL1_GPIO_POL_RESET_1(0)
+#define GXBB_WDT_CTRL1_GPIO_PULSE_CNT  (BIT(16) - 1)
+
+#define GXBB_WDT_TCNT_SETUP_MASK   (BIT(16) - 1)
+#define GXBB_WDT_TCNT_CNT_SHIFT16
+
+struct meson_gxbb_wdt {
+   void __iomem *reg_base;
+   struct watchdog_device wdt_

[PATCH 3/3] ARM64: dts: amlogic: meson-gxbb: Add watchdog node

2016-05-30 Thread Neil Armstrong
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 832815d..bcca82f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -136,6 +136,12 @@
clocks = <&xtal>;
status = "disabled";
};
+
+   watchdog@98d0 {
+   compatible = "amlogic,meson-gxbb-wdt";
+   reg = <0x0 0x098d0 0x0 0x10>;
+   clocks = <&xtal>;
+   };
};
 
gic: interrupt-controller@c4301000 {
-- 
2.7.0



[PATCH v3 0/4] Amlogic: Meson: Add reset controller

2016-05-30 Thread Neil Armstrong
Patchset to add and enable the reset controller driver on Meson SoCs platforms.

This reset controller has up to 256 reset lines with reset pulse generation 
only,
so the assert and deassert calls are not available.

Depends on the patch :
 - "reset: add devm_reset_controller_register API" [1]

Changes since v2 at 
http://lkml.kernel.org/r/1464169758-26975-1-git-send-email-narmstr...@baylibre.com
 :
- Get back __iomem in _reset() callback
- Get rid of MODULE_ALIAS

Changes since v1 at 
http://lkml.kernel.org/r/1463732875-23141-1-git-send-email-narmstr...@baylibre.com
 :
- Remove _gxbb_ in names
- Depends build on ARCH_MESON only
- Add meson8b compatible and bindings
- Re-indent dt-bindings headers
- Switch to devm_ reset controller register
- Remove platform "remove" callback
- Update Dual BSD/GPL file headers

Changes since the RFC at 
http://lkml.kernel.org/r/1463148012-25988-1-git-send-email-narmstr...@baylibre.com
 :
- Fix register mapping and bit defines in bindings header
- Remove assert and unassert calls
- Fix missing __iomem

[1] https://patchwork.kernel.org/patch/8988471/

Neil Armstrong (4):
  reset: Add support for the Amlogic Meson SoC Reset Controller
  dt-bindings: reset: Add bindings for the Meson SoC Reset Controller
  ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms
  ARM: dts: amlogic: Enable Reset Controller on Meson8b platforms

 .../bindings/reset/amlogic,meson-reset.txt |  18 ++
 arch/arm/boot/dts/meson8b.dtsi |   7 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   7 +
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-meson.c| 136 +
 .../dt-bindings/reset/amlogic,meson-gxbb-reset.h   | 210 +
 include/dt-bindings/reset/amlogic,meson8b-reset.h  | 175 +
 7 files changed, 554 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
 create mode 100644 drivers/reset/reset-meson.c
 create mode 100644 include/dt-bindings/reset/amlogic,meson-gxbb-reset.h
 create mode 100644 include/dt-bindings/reset/amlogic,meson8b-reset.h

-- 
2.7.0



[PATCH 0/3] watchdog: Add Amlogic Meson GXBB Watchdog Timer driver

2016-05-30 Thread Neil Armstrong
Adds support for the Amlogic Meson GXBB SoC Watchdog Timer.
It differs from the meson6/meson8b HW, so need for a separate driver.
The HW provides a divider capable of having a 1ms timebase thus simplifying
the counter update.
The restart call is not provided even if the HW is capable of triggering a
system reset immediately because of the PSCI firmare having such functionnality.
The watchdog is not expected to be running at boot time since there is a 
separate
system-level watchdog running from the SCPI co-processor, but this case would be
handle in a next driver update.

Changes since RFC version at 
http://lkml.kernel.org/r/1464249112-13658-1-git-send-email-narmstr...@baylibre.com
 :
- Remove status callback, will re-introduce it later to managed the 
already-running use case
- Fix registers defines indentation
- Fix space between operators
- Make all callbacks static functions
- Fix bindings with missing clocks attribute
- Do not stop/start watchdog on a timeout setup
- Fix probe device configuration

Neil Armstrong (3):
  watchdog: Add Meson GXBB Watchdog Driver
  dt-bindings: watchdog: Add Meson GXBB Watchdog bindings
  ARM64: dts: amlogic: meson-gxbb: Add watchdog node

 .../bindings/watchdog/meson-gxbb-wdt.txt   |  16 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   6 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/meson_gxbb_wdt.c  | 277 +
 4 files changed, 300 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
 create mode 100644 drivers/watchdog/meson_gxbb_wdt.c

-- 
2.7.0



[PATCH v2 2/2] crypto: omap: convert to the new cryptoengine API

2016-05-30 Thread LABBE Corentin
Since the crypto engine has been converted to use crypto_async_request
instead of ablkcipher_request, minor changes are needed to use it.

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/omap-aes.c | 10 ++
 drivers/crypto/omap-des.c | 10 ++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce174d3..7007f13 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -519,7 +519,7 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, 
int err)
 
pr_debug("err: %d\n", err);
 
-   crypto_finalize_request(dd->engine, req, err);
+   crypto_finalize_request(dd->engine, &req->base, err);
 }
 
 static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
@@ -592,14 +592,15 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
 struct ablkcipher_request *req)
 {
if (req)
-   return crypto_transfer_request_to_engine(dd->engine, req);
+   return crypto_transfer_request_to_engine(dd->engine, 
&req->base);
 
return 0;
 }
 
 static int omap_aes_prepare_req(struct crypto_engine *engine,
-   struct ablkcipher_request *req)
+   struct crypto_async_request *areq)
 {
+   struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
@@ -642,8 +643,9 @@ static int omap_aes_prepare_req(struct crypto_engine 
*engine,
 }
 
 static int omap_aes_crypt_req(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *areq)
 {
+   struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 3eedb03..0da5686 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -506,7 +506,7 @@ static void omap_des_finish_req(struct omap_des_dev *dd, 
int err)
pr_debug("err: %d\n", err);
 
pm_runtime_put(dd->dev);
-   crypto_finalize_request(dd->engine, req, err);
+   crypto_finalize_request(dd->engine, &req->base, err);
 }
 
 static int omap_des_crypt_dma_stop(struct omap_des_dev *dd)
@@ -572,14 +572,15 @@ static int omap_des_handle_queue(struct omap_des_dev *dd,
 struct ablkcipher_request *req)
 {
if (req)
-   return crypto_transfer_request_to_engine(dd->engine, req);
+   return crypto_transfer_request_to_engine(dd->engine, 
&req->base);
 
return 0;
 }
 
 static int omap_des_prepare_req(struct crypto_engine *engine,
-   struct ablkcipher_request *req)
+   struct crypto_async_request *areq)
 {
+   struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_des_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_des_dev *dd = omap_des_find_dev(ctx);
@@ -620,8 +621,9 @@ static int omap_des_prepare_req(struct crypto_engine 
*engine,
 }
 
 static int omap_des_crypt_req(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *areq)
 {
+   struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_des_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_des_dev *dd = omap_des_find_dev(ctx);
-- 
2.7.3



[PATCH v2 0/2] crypto: engine: permit to enqueue ashash_request

2016-05-30 Thread LABBE Corentin
Hello

I wanted to use the crypto engine for my Allwinner crypto driver but something
prevented me to use it: it cannot enqueue hash requests.
The first patch convert crypto engine to permit enqueuing of ahash_requests.
The second patch convert the only driver using crypto engine.

The second patch was only compile tested but the crypto engine with
hash support was tested on two different offtree driver (sun4i-ss and sun8i-ce)

Regards

Changes since v1:
- rebased on cryptodev for handling omap-des

LABBE Corentin (2):
  crypto: engine: permit to enqueue ashash_request
  crypto: omap: convert to the new cryptoengine API

 crypto/crypto_engine.c| 17 +++--
 drivers/crypto/omap-aes.c | 10 ++
 include/crypto/algapi.h   | 14 +++---
 3 files changed, 20 insertions(+), 21 deletions(-)

-- 
2.7.3



[PATCH v2 1/2] crypto: engine: permit to enqueue ashash_request

2016-05-30 Thread LABBE Corentin
The current crypto engine allow only ablkcipher_request to be enqueued.
Thus denying any use of it for hardware that also handle hash algo.

This patch convert all ablkcipher_request references to the
more general crypto_async_request.

Signed-off-by: LABBE Corentin 
---
 crypto/crypto_engine.c  | 17 +++--
 include/crypto/algapi.h | 14 +++---
 2 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index a55c82d..b658cb8 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -19,7 +19,7 @@
 #define CRYPTO_ENGINE_MAX_QLEN 10
 
 void crypto_finalize_request(struct crypto_engine *engine,
-struct ablkcipher_request *req, int err);
+struct crypto_async_request *req, int err);
 
 /**
  * crypto_pump_requests - dequeue one request from engine queue to process
@@ -34,7 +34,6 @@ static void crypto_pump_requests(struct crypto_engine *engine,
 bool in_kthread)
 {
struct crypto_async_request *async_req, *backlog;
-   struct ablkcipher_request *req;
unsigned long flags;
bool was_busy = false;
int ret;
@@ -82,9 +81,7 @@ static void crypto_pump_requests(struct crypto_engine *engine,
if (!async_req)
goto out;
 
-   req = ablkcipher_request_cast(async_req);
-
-   engine->cur_req = req;
+   engine->cur_req = async_req;
if (backlog)
backlog->complete(backlog, -EINPROGRESS);
 
@@ -142,7 +139,7 @@ static void crypto_pump_work(struct kthread_work *work)
  * @req: the request need to be listed into the engine queue
  */
 int crypto_transfer_request(struct crypto_engine *engine,
-   struct ablkcipher_request *req, bool need_pump)
+   struct crypto_async_request *req, bool need_pump)
 {
unsigned long flags;
int ret;
@@ -154,7 +151,7 @@ int crypto_transfer_request(struct crypto_engine *engine,
return -ESHUTDOWN;
}
 
-   ret = ablkcipher_enqueue_request(&engine->queue, req);
+   ret = crypto_enqueue_request(&engine->queue, req);
 
if (!engine->busy && need_pump)
queue_kthread_work(&engine->kworker, &engine->pump_requests);
@@ -171,7 +168,7 @@ EXPORT_SYMBOL_GPL(crypto_transfer_request);
  * @req: the request need to be listed into the engine queue
  */
 int crypto_transfer_request_to_engine(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *req)
 {
return crypto_transfer_request(engine, req, true);
 }
@@ -184,7 +181,7 @@ EXPORT_SYMBOL_GPL(crypto_transfer_request_to_engine);
  * @err: error number
  */
 void crypto_finalize_request(struct crypto_engine *engine,
-struct ablkcipher_request *req, int err)
+struct crypto_async_request *req, int err)
 {
unsigned long flags;
bool finalize_cur_req = false;
@@ -208,7 +205,7 @@ void crypto_finalize_request(struct crypto_engine *engine,
spin_unlock_irqrestore(&engine->queue_lock, flags);
}
 
-   req->base.complete(&req->base, err);
+   req->complete(req, err);
 
queue_kthread_work(&engine->kworker, &engine->pump_requests);
 }
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index eeafd21..d720a2a 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -173,26 +173,26 @@ struct crypto_engine {
int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
 
int (*prepare_request)(struct crypto_engine *engine,
-  struct ablkcipher_request *req);
+  struct crypto_async_request *req);
int (*unprepare_request)(struct crypto_engine *engine,
-struct ablkcipher_request *req);
+struct crypto_async_request *req);
int (*crypt_one_request)(struct crypto_engine *engine,
-struct ablkcipher_request *req);
+struct crypto_async_request *req);
 
struct kthread_worker   kworker;
struct task_struct  *kworker_task;
struct kthread_work pump_requests;
 
void*priv_data;
-   struct ablkcipher_request   *cur_req;
+   struct crypto_async_request *cur_req;
 };
 
 int crypto_transfer_request(struct crypto_engine *engine,
-   struct ablkcipher_request *req, bool need_pump);
+   struct crypto_async_request *req, bool need_pump);
 int crypto_transfer_request_to_engine(struct crypto_engine *engine,
- struct ablkcipher_request *req);
+ struct cryp

Re: [PATCH 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

2016-05-30 Thread Andrew Lunn
On Mon, May 30, 2016 at 12:40:49PM +0530, Pramod Kumar wrote:
> iProc based SoCs supports the integrated mdio multiplexer which
> has the bus selection as well as mdio transaction generation logic
> inside.

Hi Pramod

Great to see you using the existing MDIO framework. Thanks.

> +static int mdio_mux_iproc_switch_fn(int current_child, int desired_child,
> + void *data)
> +{
> + struct iproc_mdiomux_desc *md = data;
> + struct mdiomux_bus_param *bp = &md->bus_param[desired_child];
> + u32 param, bus_id;
> + bool bus_dir;
> +
> + /* select bus and its properties */
> + bus_dir = (desired_child < EXT_BUS_START_ADDR);
> + bus_id = bus_dir ? desired_child : (desired_child - EXT_BUS_START_ADDR);
> +
> + param = (bus_dir ? 1 : 0) << MDIO_PARAM_INTERNAL_SEL;
> + param |= (bp->is_c45 ? 1 : 0) << MDIO_PARAM_C45_SEL;
> + param |= (bus_id << MDIO_PARAM_BUS_ID);
> +
> + writel(param, md->base + MDIO_PARAM_OFFSET);
> + return 0;
> +}

What i don't yet see is why you went for the concept of an integrated
MDIO and MUX. This function above is the mux function, and it looks
like it could be used to implement a standard mdio-mux driver.

Thanks
 Andrew


[PATCH v6 3/8] block: mark 1st parameter of bvec_iter_advance as const

2016-05-30 Thread Ming Lei
bvec_iter_advance() only writes the parameter of iterator,
so the base address of bvec can be marked as const safely.

Without the change, we can see compiling warning in the
following patch for implementing iterate_bvec(): lib/iov_iter.c
with bvec iterator.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 include/linux/bvec.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/bvec.h b/include/linux/bvec.h
index 096efd2..701b64a 100644
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@ -66,7 +66,8 @@ struct bvec_iter {
.bv_offset  = bvec_iter_offset((bvec), (iter)), \
 })
 
-static inline void bvec_iter_advance(struct bio_vec *bv, struct bvec_iter 
*iter,
+static inline void bvec_iter_advance(const struct bio_vec *bv,
+struct bvec_iter *iter,
 unsigned bytes)
 {
WARN_ONCE(bytes > iter->bi_size,
-- 
1.9.1



[PATCH v6 0/8] block: prepare for multipage bvecs

2016-05-30 Thread Ming Lei

Hi,

Interests[1] have been shown in multipage bvecs, so this patchset
try to prepare for the support and do two things:

1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
then we can drop the non-standard way for iterating bvec, which
can be thought as a good cleanup for lib/iov_iter.c

2) remove BIO_MAX_SECTORS and makre BIO_MAX_SIZE as obsolete, and
now there is only one user for each. Once multipage bvecs is introduced,
one bio may hold lots of sectors, and we should always use sort of
BIO_MAX_VECS which should be introduced in future and is similiar
with current BIO_MAX_PAGES.

The only functional change is iterate_bvec():lib/iov_iter.c

xfstests(-a auto) over loop aio is run for ext4/xfs to verify 
the change and no regression found with this patchset.

V6:
- rebased on v4.7-rc1
- add reviewed-by tag
- mark BIO_MAX_SIZE as obsolete instead of removing because
dm-tree adds one usage now

V5:
- use bvec's iterator to figure new base vec address and
update 'skip' correctly
- run xfstests(-a auto) on loop aio/dio for verifying
the change in iterate_bvec(), and no regression reported
- use stree-ng to trigger heavy swap over swapfile to verify
change in iterate_bvec() too, looks everything is fine
V4:
- make xfstests cover xfs
- rebase on for-next of block tree
V3:
- include kenrel.h & bug.h in bvec.h for fix comiling failure on arm
as reported by 0day ktest
- build test on arm & arm64

V2:
- rename bvec_iter.h as bvec.h
- always include bvec.h into blk_types.h as suggested by Christoph

V1:
- don't move BIO_MAX_* to bvec_iter.h as pointed out by Christoph
- run xfstests against v4.6-rc1-next-20160329
- add Reviewed-by
- for 1,4 and 5, Reviewd-by not added, Christoph still expressed
'this looks fine to me.'


Ming Lei (8):
  block: move bvec iterator into include/linux/bvec.h
  block: move two bvec structure into bvec.h
  block: mark 1st parameter of bvec_iter_advance as const
  iov_iter: use bvec iterator to implement iterate_bvec()
  fs: xfs: replace BIO_MAX_SECTORS with BIO_MAX_PAGES
  block: bio: remove BIO_MAX_SECTORS
  block: drbd: avoid to use BIO_MAX_SIZE
  block: mark BIO_MAX_SIZE as obsolete

 drivers/block/drbd/drbd_int.h |  4 +-
 fs/xfs/xfs_buf.c  |  4 +-
 include/linux/bio.h   | 58 --
 include/linux/blk_types.h | 22 +-
 include/linux/bvec.h  | 96 +++
 lib/iov_iter.c| 45 +++-
 6 files changed, 122 insertions(+), 107 deletions(-)
 create mode 100644 include/linux/bvec.h

-- 
1.9.1



[PATCH v6 2/8] block: move two bvec structure into bvec.h

2016-05-30 Thread Ming Lei
This patch moves 'struct bio_vec' and 'struct bvec_iter'
into 'include/linux/bvec.h', then always include this header
into 'include/linux/blk_types.h'.

With this change, both 'struct bvec_iter' and bvec iterator
helpers don't depend on CONFIG_BLOCK any more, then we can
use bvec iterator to implement iterate_bvec(): lib/iov_iter.c.

Reviewed-by: Christoph Hellwig 
Suggested-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 include/linux/bio.h   |  1 -
 include/linux/blk_types.h | 22 +-
 include/linux/bvec.h  | 23 ++-
 3 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/include/linux/bio.h b/include/linux/bio.h
index ed4bfb9..8555b90 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -31,7 +31,6 @@
 
 /* struct bio, bio_vec and BIO_* flags are defined in blk_types.h */
 #include 
-#include 
 
 #define BIO_DEBUG
 
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 77e5d81..dadc240 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -6,6 +6,7 @@
 #define __LINUX_BLK_TYPES_H
 
 #include 
+#include 
 
 struct bio_set;
 struct bio;
@@ -17,28 +18,7 @@ struct cgroup_subsys_state;
 typedef void (bio_end_io_t) (struct bio *);
 typedef void (bio_destructor_t) (struct bio *);
 
-/*
- * was unsigned short, but we might as well be ready for > 64kB I/O pages
- */
-struct bio_vec {
-   struct page *bv_page;
-   unsigned intbv_len;
-   unsigned intbv_offset;
-};
-
 #ifdef CONFIG_BLOCK
-
-struct bvec_iter {
-   sector_tbi_sector;  /* device address in 512 byte
-  sectors */
-   unsigned intbi_size;/* residual I/O count */
-
-   unsigned intbi_idx; /* current index into bvl_vec */
-
-   unsigned intbi_bvec_done;   /* number of bytes completed in
-  current bvec */
-};
-
 /*
  * main unit of I/O for the block layer and lower layers (ie drivers and
  * stacking drivers)
diff --git a/include/linux/bvec.h b/include/linux/bvec.h
index 29c459d..096efd2 100644
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@ -20,7 +20,28 @@
 #ifndef __LINUX_BVEC_ITER_H
 #define __LINUX_BVEC_ITER_H
 
-#include 
+#include 
+#include 
+
+/*
+ * was unsigned short, but we might as well be ready for > 64kB I/O pages
+ */
+struct bio_vec {
+   struct page *bv_page;
+   unsigned intbv_len;
+   unsigned intbv_offset;
+};
+
+struct bvec_iter {
+   sector_tbi_sector;  /* device address in 512 byte
+  sectors */
+   unsigned intbi_size;/* residual I/O count */
+
+   unsigned intbi_idx; /* current index into bvl_vec */
+
+   unsigned intbi_bvec_done;   /* number of bytes completed in
+  current bvec */
+};
 
 /*
  * various member access, note that bio_data should of course not be used
-- 
1.9.1



[PATCH v6 5/8] fs: xfs: replace BIO_MAX_SECTORS with BIO_MAX_PAGES

2016-05-30 Thread Ming Lei
BIO_MAX_PAGES is used as maximum count of bvecs, so
replace BIO_MAX_SECTORS with BIO_MAX_PAGES since
BIO_MAX_SECTORS is to be removed.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 fs/xfs/xfs_buf.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index e71cfbd..e5d713b 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -1157,9 +1157,7 @@ xfs_buf_ioapply_map(
 
 next_chunk:
atomic_inc(&bp->b_io_remaining);
-   nr_pages = BIO_MAX_SECTORS >> (PAGE_SHIFT - BBSHIFT);
-   if (nr_pages > total_nr_pages)
-   nr_pages = total_nr_pages;
+   nr_pages = min(total_nr_pages, BIO_MAX_PAGES);
 
bio = bio_alloc(GFP_NOIO, nr_pages);
bio->bi_bdev = bp->b_target->bt_bdev;
-- 
1.9.1



[PATCH v6 4/8] iov_iter: use bvec iterator to implement iterate_bvec()

2016-05-30 Thread Ming Lei
bvec has one native/mature iterator for long time, so not
necessary to use the reinvented wheel for iterating bvecs
in lib/iov_iter.c.

Two ITER_BVEC test cases are run:
- xfstest(-g auto) on loop dio/aio, no regression found
- swap file works well under extreme stress(stress-ng --all 64 -t
  800 -v), and lots of OOMs are triggerd, and the whole
system still survives

Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 lib/iov_iter.c | 45 +++--
 1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 0cd5227..d67c828 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -56,37 +56,24 @@
n = wanted; \
 }
 
-#define iterate_bvec(i, n, __v, __p, skip, STEP) { \
-   size_t wanted = n;  \
-   __p = i->bvec;  \
-   __v.bv_len = min_t(size_t, n, __p->bv_len - skip);  \
-   if (likely(__v.bv_len)) {   \
-   __v.bv_page = __p->bv_page; \
-   __v.bv_offset = __p->bv_offset + skip;  \
-   (void)(STEP);   \
-   skip += __v.bv_len; \
-   n -= __v.bv_len;\
-   }   \
-   while (unlikely(n)) {   \
-   __p++;  \
-   __v.bv_len = min_t(size_t, n, __p->bv_len); \
-   if (unlikely(!__v.bv_len))  \
+#define iterate_bvec(i, n, __v, __bi, skip, STEP) {\
+   struct bvec_iter __start;   \
+   __start.bi_size = n;\
+   __start.bi_bvec_done = skip;\
+   __start.bi_idx = 0; \
+   for_each_bvec(__v, i->bvec, __bi, __start) {\
+   if (!__v.bv_len)\
continue;   \
-   __v.bv_page = __p->bv_page; \
-   __v.bv_offset = __p->bv_offset; \
(void)(STEP);   \
-   skip = __v.bv_len;  \
-   n -= __v.bv_len;\
}   \
-   n = wanted; \
 }
 
 #define iterate_all_kinds(i, n, v, I, B, K) {  \
size_t skip = i->iov_offset;\
if (unlikely(i->type & ITER_BVEC)) {\
-   const struct bio_vec *bvec; \
struct bio_vec v;   \
-   iterate_bvec(i, n, v, bvec, skip, (B))  \
+   struct bvec_iter __bi;  \
+   iterate_bvec(i, n, v, __bi, skip, (B))  \
} else if (unlikely(i->type & ITER_KVEC)) { \
const struct kvec *kvec;\
struct kvec v;  \
@@ -104,15 +91,13 @@
if (i->count) { \
size_t skip = i->iov_offset;\
if (unlikely(i->type & ITER_BVEC)) {\
-   const struct bio_vec *bvec; \
+   const struct bio_vec *bvec = i->bvec;   \
struct bio_vec v;   \
-   iterate_bvec(i, n, v, bvec, skip, (B))  \
-   if (skip == bvec->bv_len) { \
-   bvec++; \
-   skip = 0;   \
-   }   \
-   i->nr_segs -= bvec - i->bvec;   \
-   i->bvec = bvec; \
+   struct bvec_iter __bi;  \
+   iterate_bvec(i, n, v, __bi, skip, (B))  \
+   i->bvec = __bvec_iter_bvec(i->bvec, __bi);  \
+   i->nr_segs -= i->bvec - bvec;   \
+   skip = __bi.bi_bvec_done;   \
} else if (unlikely(i->type & ITER_KVEC)) { \
const struct kvec *kvec;\
struct kvec v;  \
-- 
1.9.1



[PATCH v6 1/8] block: move bvec iterator into include/linux/bvec.h

2016-05-30 Thread Ming Lei
bvec iterator helpers should be used to implement by
iterate_bvec():lib/iov_iter.c too, and move them into
one header, so that we can keep bvec iterator header
out of CONFIG_BLOCK. Then we can remove the reinventing
of wheel in iterate_bvec().

Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 include/linux/bio.h  | 51 +---
 include/linux/bvec.h | 74 
 2 files changed, 75 insertions(+), 50 deletions(-)
 create mode 100644 include/linux/bvec.h

diff --git a/include/linux/bio.h b/include/linux/bio.h
index 9faebf7..ed4bfb9 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -31,6 +31,7 @@
 
 /* struct bio, bio_vec and BIO_* flags are defined in blk_types.h */
 #include 
+#include 
 
 #define BIO_DEBUG
 
@@ -57,29 +58,6 @@
(bio)->bi_rw |= ((unsigned long) (prio) << BIO_PRIO_SHIFT); \
 } while (0)
 
-/*
- * various member access, note that bio_data should of course not be used
- * on highmem page vectors
- */
-#define __bvec_iter_bvec(bvec, iter)   (&(bvec)[(iter).bi_idx])
-
-#define bvec_iter_page(bvec, iter) \
-   (__bvec_iter_bvec((bvec), (iter))->bv_page)
-
-#define bvec_iter_len(bvec, iter)  \
-   min((iter).bi_size, \
-   __bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done)
-
-#define bvec_iter_offset(bvec, iter)   \
-   (__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_done)
-
-#define bvec_iter_bvec(bvec, iter) \
-((struct bio_vec) {\
-   .bv_page= bvec_iter_page((bvec), (iter)),   \
-   .bv_len = bvec_iter_len((bvec), (iter)),\
-   .bv_offset  = bvec_iter_offset((bvec), (iter)), \
-})
-
 #define bio_iter_iovec(bio, iter)  \
bvec_iter_bvec((bio)->bi_io_vec, (iter))
 
@@ -193,33 +171,6 @@ static inline void *bio_data(struct bio *bio)
 #define bio_for_each_segment_all(bvl, bio, i)  \
for (i = 0, bvl = (bio)->bi_io_vec; i < (bio)->bi_vcnt; i++, bvl++)
 
-static inline void bvec_iter_advance(struct bio_vec *bv, struct bvec_iter 
*iter,
-unsigned bytes)
-{
-   WARN_ONCE(bytes > iter->bi_size,
- "Attempted to advance past end of bvec iter\n");
-
-   while (bytes) {
-   unsigned len = min(bytes, bvec_iter_len(bv, *iter));
-
-   bytes -= len;
-   iter->bi_size -= len;
-   iter->bi_bvec_done += len;
-
-   if (iter->bi_bvec_done == __bvec_iter_bvec(bv, *iter)->bv_len) {
-   iter->bi_bvec_done = 0;
-   iter->bi_idx++;
-   }
-   }
-}
-
-#define for_each_bvec(bvl, bio_vec, iter, start)   \
-   for (iter = (start);\
-(iter).bi_size &&  \
-   ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
-bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
-
-
 static inline void bio_advance_iter(struct bio *bio, struct bvec_iter *iter,
unsigned bytes)
 {
diff --git a/include/linux/bvec.h b/include/linux/bvec.h
new file mode 100644
index 000..29c459d
--- /dev/null
+++ b/include/linux/bvec.h
@@ -0,0 +1,74 @@
+/*
+ * bvec iterator
+ *
+ * Copyright (C) 2001 Ming Lei 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public Licens
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-
+ */
+#ifndef __LINUX_BVEC_ITER_H
+#define __LINUX_BVEC_ITER_H
+
+#include 
+
+/*
+ * various member access, note that bio_data should of course not be used
+ * on highmem page vectors
+ */
+#define __bvec_iter_bvec(bvec, iter)   (&(bvec)[(iter).bi_idx])
+
+#define bvec_iter_page(bvec, iter) \
+   (__bvec_iter_bvec((bvec), (iter))->bv_page)
+
+#define bvec_iter_len(bvec, iter)  \
+   min((iter).bi_size, \
+   __bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done)
+
+#define bvec_iter_offset(bvec, iter)   \
+   (__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_d

[PATCH v2 1/6] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

2016-05-30 Thread Yongji Xie
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other words, the hardware
can protect system from invalid MSIs of the device by checking
the target address and data when there is something wrong
with MSI part in device or device driver.

There is a existing flag for this capability in the IOMMU space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

and Eric also posted a patchset [1] to abstract it on MSI
controller side for ARM. But it would make sense to have a
more common flag like PCI_BUS_FLAGS_MSI_REMAP so that we can
use a universal flag to test this capability on PCI side for
different archs.

With this flag enabled, we can easily know whether it's safe
to expose MSI-X tables of PCI BARs to userspace. Some usespace
drivers such as VFIO may benefit from this.

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Signed-off-by: Yongji Xie 
---
 include/linux/pci.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 932ec74..4ec37da 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -187,6 +187,7 @@ typedef unsigned short __bitwise pci_bus_flags_t;
 enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI   = (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 4,
 };
 
 /* These values come from the PCI Express Spec */
-- 
1.7.9.5



[PATCH v2 3/6] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping

2016-05-30 Thread Yongji Xie
The capability of IRQ remapping is abstracted on IOMMU side on
some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.

To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when IOMMU_CAP_INTR_REMAP is set.

Signed-off-by: Yongji Xie 
---
 drivers/pci/probe.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2b9e3ba..15a33e2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 #define CARDBUS_LATENCY_TIMER  176 /* secondary latency timer */
@@ -2160,6 +2161,9 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
pci_set_bus_of_node(b);
pci_set_bus_msi_domain(b);
 
+   if (iommu_capable(&pci_bus_type, IOMMU_CAP_INTR_REMAP))
+   b->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+
if (!parent)
set_dev_node(b->bridge, pcibus_to_node(b));
 
-- 
1.7.9.5



[PATCH v6 8/8] block: mark BIO_MAX_SIZE as obsolete

2016-05-30 Thread Ming Lei
Some in-tree drivers may use big bio which size is more
than BIO_MAX_SIZE, also the macro is seldom used in tree.

So mark it as obsolete now, and it doesn't make sense
after multipage bvec is introduced.

Signed-off-by: Ming Lei 
---
 include/linux/bio.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/bio.h b/include/linux/bio.h
index fb59a06..b284595 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -41,6 +41,13 @@
 #endif
 
 #define BIO_MAX_PAGES  256
+
+/*
+ * This is obsolete now and shouldn't be used, and the macro
+ * doesn't make any sense especially when multipage bvecs is
+ * supported. Even now some drivers may pass big bio which size
+ * is more than the value, such as bcache.
+ */
 #define BIO_MAX_SIZE   (BIO_MAX_PAGES << PAGE_SHIFT)
 
 /*
-- 
1.9.1



[PATCH v2 2/6] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller enables IRQ remapping

2016-05-30 Thread Yongji Xie
On ARM HW the capability of IRQ remapping is abstracted on
MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise
this [1].

To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when MSI_FLAG_IRQ_REMAPPING is set.

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Signed-off-by: Yongji Xie 
---
 drivers/pci/msi.c   |   15 +++
 drivers/pci/probe.c |3 +++
 include/linux/msi.h |5 -
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f44..dbdb5c3 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1134,6 +1134,21 @@ void *msi_desc_to_pci_sysdata(struct msi_desc *desc)
 }
 EXPORT_SYMBOL_GPL(msi_desc_to_pci_sysdata);
 
+int pci_bus_msi_isolated(struct pci_bus *bus, struct irq_domain *domain)
+{
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+   struct msi_domain_info *info;
+
+   if (!domain)
+   return 0;
+
+   info = msi_get_domain_info(domain);
+   if (info->flags & MSI_FLAG_IRQ_REMAPPING)
+   return 1;
+#endif
+   return 0;
+}
+
 #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
 /**
  * pci_msi_domain_write_msg - Helper to write MSI message to PCI config space
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8004f67..2b9e3ba 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -713,6 +713,9 @@ static void pci_set_bus_msi_domain(struct pci_bus *bus)
if (!d)
d = pci_host_bridge_msi_domain(b);
 
+   if (b == bus && pci_bus_msi_isolated(bus, d))
+   bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+
dev_set_msi_domain(&bus->dev, d);
 }
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 08441b1..04cc749 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -15,6 +15,8 @@ extern int pci_msi_ignore_mask;
 struct irq_data;
 struct msi_desc;
 struct pci_dev;
+struct pci_bus;
+struct irq_domain;
 struct platform_msi_priv_data;
 void __get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg);
@@ -164,6 +166,8 @@ void arch_restore_msi_irqs(struct pci_dev *dev);
 void default_teardown_msi_irqs(struct pci_dev *dev);
 void default_restore_msi_irqs(struct pci_dev *dev);
 
+int pci_bus_msi_isolated(struct pci_bus *bus, struct irq_domain *domain);
+
 struct msi_controller {
struct module *owner;
struct device *dev;
@@ -182,7 +186,6 @@ struct msi_controller {
 #include 
 #include 
 
-struct irq_domain;
 struct irq_domain_ops;
 struct irq_chip;
 struct device_node;
-- 
1.7.9.5



[PATCH v2 0/6] vfio-pci: Add support for mmapping MSI-X table

2016-05-30 Thread Yongji Xie
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write directly
to MSI-X table and generate an incorrect MSIs.

However, this will cause some performance issue when there
are some critical device registers in the same page as the 
MSI-X table. We have to handle the mmio access to these
registers in QEMU emulation rather than in guest.

To solve this issue, this series allows to expose MSI-X table
to userspace when hardware enables the capability of interrupt
remapping which can ensure that a given PCI device can only
shoot the MSIs assigned for it. And we introduce a new bus_flags
PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
for different archs.

The patch 3 are based on the proposed patchset[1].

Changelog v2: 
- Make the commit log more clear
- Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
  so that we could clearly know what the function does
- Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
  of iommu_bus_notifier()
- Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
  table so that we can know whether we allow to mmap MSI-X table
  in QEMU

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Yongji Xie (6):
  PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
  PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller enables IRQ remapping
  PCI: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping
  iommu: Set PCI_BUS_FLAGS_MSI_REMAP on iommu driver initialization
  pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
  vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is 
enabled

 arch/powerpc/platforms/powernv/pci-ioda.c |8 
 drivers/iommu/iommu.c |8 
 drivers/pci/msi.c |   15 +++
 drivers/pci/probe.c   |7 +++
 drivers/vfio/pci/vfio_pci.c   |   17 ++---
 drivers/vfio/pci/vfio_pci_rdwr.c  |3 ++-
 include/linux/msi.h   |5 -
 include/linux/pci.h   |1 +
 8 files changed, 59 insertions(+), 5 deletions(-)

-- 
1.7.9.5



Re: [patch V2 2/7] futex: Hash private futexes per process

2016-05-30 Thread Sebastian Andrzej Siewior
On 05/30/2016 02:06 PM, Peter Zijlstra wrote:
>> We
>> never rehash the hash. To rehash the hash on runtime we would need an
>> empty futex hash and some locking in the fast path.
> 
> Nah; you can do lockless rehashing. Little tricky, but entirely doable.
> At worst we'd need an rcu_read_lock(), but with a little extra work we
> can extend an existing preempt_disable section to cover the hash lookup
> if it isn't already covered.

you also need ensure that all new users use the new hash but all old
users go for the old one until you can switch them over. And it is
likely we miss a corner case because it is futex after all.

And still, we all that? You need an upper limit how often / until which
size you do resize. And if you want to avoid collisions at all costs
(because) go for the max value if you think you need it so there is no
need to resize. And if the task does not pre-allocate why care at all?

>> And rehash seems
>> not to be required since we tried to come up with a sane default value
>> and the user/RT task can set it to the current max value.
> 
> I'm not sure this statement is true; given that the hash function
> reduces the entire address space down to a few bits you're guaranteed to
> have collisions at some point. A good hash will not have more than given
> by the birthday paradox, but you cannot have less.
> 
> So while the sizing can certainly reduce the chance on collisions,
> nothing guarantees you will not have them, quite the opposite.

Yes, I did not try to discuss the hash collision away. From RT's point
of view the problems I am aware are of the following scenario:
Task #1 pinned to CPU1 task #2 pinned to CPU2 but share the same
bucket. Task #2 got a wakeup and should run but is blocked on the
bucket lock - otherwise it could run. Usually it would PI-boost task#1
but task#1 got preempted itself by task and since task#1 prio is lower
it can't boost its way free towards the lock and so so CPU #2 may
remain idle for some time.

The same thing can happen within a Task if you take my story from above
and replace task with thread. Completely understood.

>> So back to when does the collision happen. Since glibc visits the
>> kernel only on contention we might learn about the collision when it is
>> too late. We could have a lock operation by thread1 followed by lock
>> operation by thread2 on different uaddr resulting in the same bucket.
>> In this case we learn about this once the spin_lock() operation blocks.
> 
> Yep, so if this is two ondemand futexes hitting the same bucket, we
> don't care. But if this is an ondemand futex hitting a prealloc one, we
> do care.
> 
> And yes, this is late, but its the only possible time. And notification
> is better than silent weird behaviour.

We don't distinguish right now between "user asked to preallocate the
hash" and "we created this hash because we had a locking job in
kernel". The latter is the behaviour we used to have and the former is
something like "this new preallocate thingy does not always work".

>> Also marking a bucket as taken (on contention) might give false
>> positive results since we know nothing about lock's lifetime (i.e. the
>> lock might have been free()ed).
>>
>> But if I may bring some ideas from v1. In v1 we had "tickets / IDs" for
>> the futex per thread. In v2 we don't have them anymore. We still have
>> the "private" futex hash buckets but per process this time.
>> We could introduce the "tickets / IDs" back and make them process wide.
>> We could hide them in pthread_mutex_init() and pthread_mutex_destroy()
>> since their IDs are no longer thread unique. I think I had something in
>> glibc's pthread variable where we could store 16bit if I split another
>> 32bit variable.
> 
> Not sure you need a ticket (and I never got around to reading v1), a

so v1 in short. To lock you do:
  futex(uaddr, FUTEX_LOCK_PI | PRIVATE, …)

instead uaddr, we used tickets and called the mode attached:
  futex(ticket, FUTEX_LOCK_PI | PRIVATE | ATTACHED, …)

and the ticket was the index in our array where we kept the hash
buckets. That means each user space futex has its own hash bucket
without contention. But since we had the tickets unique in every thread
it was hard to handle. Keeping them the same process wide should make
things simple again.

> simple twin to PREALLOCATE_HASH to call on mutex_destroy would be
> sufficient I think. It could free the hash bucket.

You do PREALLOCATE_HASH _once_ on startup not for every mutex. But yes,
you would mark each mutex in mutex_destroy() as gone.

So this would "work", you would find a collision during a slot lookup.
You could increase the coverage if you add another marker in
pthread_mutex_init() (well, except for static initializes). That means
we need glibc changes for this to work.
And what do you suggest to report such a collision? A trace point, a
file in proc? WARN_ON_ONCE() would not result in CVE but is not that
pretty and informative. Not sure if glibc is all for a return code
which i

[PATCH v6 7/8] block: drbd: avoid to use BIO_MAX_SIZE

2016-05-30 Thread Ming Lei
Use BIO_MAX_PAGES instead and we will remove BIO_MAX_SIZE.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 drivers/block/drbd/drbd_int.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index 7a1cf7e..e6e4b08 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -1327,14 +1327,14 @@ struct bm_extent {
 #endif
 #endif
 
-/* BIO_MAX_SIZE is 256 * PAGE_SIZE,
+/* Estimate max bio size as 256 * PAGE_SIZE,
  * so for typical PAGE_SIZE of 4k, that is (1<<20) Byte.
  * Since we may live in a mixed-platform cluster,
  * we limit us to a platform agnostic constant here for now.
  * A followup commit may allow even bigger BIO sizes,
  * once we thought that through. */
 #define DRBD_MAX_BIO_SIZE (1U << 20)
-#if DRBD_MAX_BIO_SIZE > BIO_MAX_SIZE
+#if DRBD_MAX_BIO_SIZE > (BIO_MAX_PAGES << PAGE_SHIFT)
 #error Architecture not supported: DRBD_MAX_BIO_SIZE > BIO_MAX_SIZE
 #endif
 #define DRBD_MAX_BIO_SIZE_SAFE (1U << 12)   /* Works always = 4k */
-- 
1.9.1



[PATCH v2 4/6] iommu: Set PCI_BUS_FLAGS_MSI_REMAP on iommu driver initialization

2016-05-30 Thread Yongji Xie
Some iommu drivers would be initialized after PCI device
enumeration. So PCI_BUS_FLAGS_MSI_REMAP would not be set
when probing PCI devices although IOMMU enables capability
of IRQ remapping. This patch tests this capability and
set the flag when iommu driver is initialized.

Signed-off-by: Yongji Xie 
---
 drivers/iommu/iommu.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b9df141..e6159ab 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -872,6 +872,14 @@ static int add_iommu_group(struct device *dev, void *data)
const struct iommu_ops *ops = cb->ops;
int ret;
 
+   /*
+* Set PCI_BUS_FLAGS_MSI_REMAP for all PCI buses when IOMMU
+* have capability of IRQ remapping.
+*/
+   if (dev_is_pci(dev) && ops->capable &&
+   ops->capable(IOMMU_CAP_INTR_REMAP))
+   to_pci_dev(dev)->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+
if (!ops->add_device)
return 0;
 
-- 
1.7.9.5



Re: [PATCH 2/2] crypto: omap: convert to the new cryptoengine API

2016-05-30 Thread LABBE Corentin
On Mon, May 30, 2016 at 10:20:01AM +0800, Baolin Wang wrote:
> On 18 May 2016 at 17:21, LABBE Corentin  wrote:
> > Since the crypto engine has been converted to use crypto_async_request
> > instead of ablkcipher_request, minor changes are needed to use it.
> 
> I think you missed the conversion for omap des driver, please rebase
> your patch. Beyond that I think you did a good job for crypto engine
> if Herbert applied it.
> 

Thanks
I have just rebased it and added omap-des to the list of changes.

Regards



[PATCH v6 6/8] block: bio: remove BIO_MAX_SECTORS

2016-05-30 Thread Ming Lei
No one need this macro, so remove it. The motivation is
for supporting multipage bvecs, in which we only know
what the max count of bvecs is supported in the bio,
instead of max size or max sectors.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Ming Lei 
---
 include/linux/bio.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/bio.h b/include/linux/bio.h
index 8555b90..fb59a06 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -42,7 +42,6 @@
 
 #define BIO_MAX_PAGES  256
 #define BIO_MAX_SIZE   (BIO_MAX_PAGES << PAGE_SHIFT)
-#define BIO_MAX_SECTORS(BIO_MAX_SIZE >> 9)
 
 /*
  * upper 16 bits of bi_rw define the io priority of this bio
-- 
1.9.1



[PATCH v2 5/6] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

2016-05-30 Thread Yongji Xie
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.

Signed-off-by: Yongji Xie 
Reviewed-by: Alexey Kardashevskiy 
---
 arch/powerpc/platforms/powernv/pci-ioda.c |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index c5baaf3..9011268 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3094,6 +3094,12 @@ static void pnv_pci_ioda_fixup(void)
pnv_npu_ioda_fixup();
 }
 
+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+
 /*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3395,6 +3401,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
 
+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU)
hose->controller_ops = pnv_npu_ioda_controller_ops;
else
-- 
1.7.9.5



[PATCH v2 6/6] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

2016-05-30 Thread Yongji Xie
This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping. This capability can ensure that a
given PCI device can only shoot the MSIs assigned for it. That
means a userspace driver could never hurt other devices or system
by writing to the exposed MSI-X table directly.

Signed-off-by: Yongji Xie 
---
 drivers/vfio/pci/vfio_pci.c  |   17 ++---
 drivers/vfio/pci/vfio_pci_rdwr.c |3 ++-
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 188b1ff..6bae388 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -487,8 +487,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
end = pci_resource_len(vdev->pdev, vdev->msix_bar);
 
-   /* If MSI-X table is aligned to the start or end, only one area */
-   if (((vdev->msix_offset & PAGE_MASK) == 0) ||
+   /*
+* If MSI-X table is allowed to mmap because of the capability
+* of IRQ remapping or aligned to the start or end, only one area
+*/
+   if ((vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) ||
+   ((vdev->msix_offset & PAGE_MASK) == 0) ||
(PAGE_ALIGN(vdev->msix_offset + vdev->msix_size) >= end))
nr_areas = 1;
 
@@ -503,6 +507,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
  struct vfio_region_info_cap_sparse_mmap, header);
sparse->nr_areas = nr_areas;
 
+   if (vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) {
+   sparse->areas[i].offset = 0;
+   sparse->areas[i].size = end;
+   return 0;
+   }
+
if (vdev->msix_offset & PAGE_MASK) {
sparse->areas[i].offset = 0;
sparse->areas[i].size = vdev->msix_offset & PAGE_MASK;
@@ -1061,7 +1071,8 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (phys_len < PAGE_SIZE || req_start + req_len > phys_len)
return -EINVAL;
 
-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9..dbf9cd0 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];
 
-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
-- 
1.7.9.5



Re: [PATCH] cpufreq: stats: Make the stats code non-modular

2016-05-30 Thread Rafael J. Wysocki
On Mon, May 30, 2016 at 6:53 AM, Viresh Kumar  wrote:
> On 28-05-16, 15:15, Rafael J. Wysocki wrote:
>> It does, but there's a problem.
>>
>> If fast frequency switching is in use, the stats attributes just sit there
>> full of zeros (because the stats are not updated then) which is confusing.
>>
>> Of course, the ultimate solution here would be to make the stats actually
>> work with fast frequency switching, but that requires some major surgery of
>> the stats code, so for now I'd like to simply make those attributes return
>> nothing if fast frequency switching is enabled for the policy (returning
>> -EBUSY from there, which would have been cleaner, unfortunately breaks
>> powertop).
>
> What's stopping us from doing that? Sorry I don't remember that well :(
>
> I mean, why can't we call cpufreq_stats_record_transition() somehow via that
> code ?

Because it does things that aren't allowed to be done from the
scheduler paths (using the non-raw spinlock in the first place).

It also isn't efficient enough.  For example, the fast switch path in
schedutil for non-shared policies is lockless and it would be a shame
to add a lock to it just for the stats.


Re: [PATCH v2 6/7] iio: inv_mpu6050: Reformat sample for active scan mask

2016-05-30 Thread Crestez Dan Leonard
On 05/29/2016 06:47 PM, Jonathan Cameron wrote:
> On 18/05/16 16:00, Crestez Dan Leonard wrote:
>> Right now it is possible to only enable some of the x/y/z channels, for
>> example you can enable accel_z without x or y but if you actually do
>> that what you get is actually only the x channel.
>>
>> Fix this by reformatting the hardware sample to only include the
>> requested channels.
> As it stands here there is no benefit in doing this over using the core
> demux. In fact it's considerably less efficient (fair enough that you
> are keeping it simple in the first instance).
> The patch description should make that clear.

Why is it less efficient? All it really does is a bunch of memcpy.

> I'd definitely like to see simple extension of that option to handle
> a callback to get the nearest scanmask that is possible (as an alternative
> to the static scan_masks_available list.)
> 
> This only gets interesting if we are dealing with the unaligned case and for
> these parts that only kicks in I think if the slave devices have say 3 bytes 
> in
> their data type.  

But I want to deal with the unaligned case because it's better than
introducing odd validations on slave channels. If I added an extension
to get the nearest scanmask I would have to remove it in PATCH 7.

-- 
Regards,
Leonard


Re: [PATCH 0/3] watchdog: Add Amlogic Meson GXBB Watchdog Timer driver

2016-05-30 Thread Carlo Caione
On 30/05/16 15:29, Neil Armstrong wrote:
> Adds support for the Amlogic Meson GXBB SoC Watchdog Timer.
> It differs from the meson6/meson8b HW, so need for a separate driver.
> The HW provides a divider capable of having a 1ms timebase thus simplifying
> the counter update.
> The restart call is not provided even if the HW is capable of triggering a
> system reset immediately because of the PSCI firmare having such 
> functionnality.
> The watchdog is not expected to be running at boot time since there is a 
> separate
> system-level watchdog running from the SCPI co-processor, but this case would 
> be
> handle in a next driver update.
> 
> Changes since RFC version at 
> http://lkml.kernel.org/r/1464249112-13658-1-git-send-email-narmstr...@baylibre.com
>  :
> - Remove status callback, will re-introduce it later to managed the 
> already-running use case
> - Fix registers defines indentation
> - Fix space between operators
> - Make all callbacks static functions
> - Fix bindings with missing clocks attribute
> - Do not stop/start watchdog on a timeout setup
> - Fix probe device configuration
> 
> Neil Armstrong (3):
>   watchdog: Add Meson GXBB Watchdog Driver
>   dt-bindings: watchdog: Add Meson GXBB Watchdog bindings
>   ARM64: dts: amlogic: meson-gxbb: Add watchdog node

I'm missing [PATCH 2/3]

-- 
Carlo Caione


Re: [patch V2 2/7] futex: Hash private futexes per process

2016-05-30 Thread Peter Zijlstra
On Mon, May 30, 2016 at 03:37:48PM +0200, Sebastian Andrzej Siewior wrote:
> Yes, I did not try to discuss the hash collision away. From RT's point
> of view the problems I am aware are of the following scenario:
> Task #1 pinned to CPU1 task #2 pinned to CPU2 but share the same
> bucket. Task #2 got a wakeup and should run but is blocked on the
> bucket lock - otherwise it could run. Usually it would PI-boost task#1
> but task#1 got preempted itself by task and since task#1 prio is lower
> it can't boost its way free towards the lock and so so CPU #2 may
> remain idle for some time.
> 
> The same thing can happen within a Task if you take my story from above
> and replace task with thread. Completely understood.

Right; so I don't see the point of PREALLOCATE_HASH to cater for RT
workloads if it still doesn't guarantee anything, esp. if the failure
case is silent and obscure.


Re: [PATCH] Add virtio gpu driver.

2016-05-30 Thread Gerd Hoffmann
  Hi,

> - add a small core function to registerr HOT_X/HOT_Y for a (cursor) plane,
>   e.g. drm_plane_register_hotspot(). That should allocate the properties
>   (if they don't exist yet) and then attach those props to the cursor. We
>   don't want those props everywhere, but only on drivers that support/need
>   them, aka virtual hw.

Hmm, why is this special to virtual hw?

>   if (crtc->cursor) {
> - ret = drm_mode_cursor_universal(crtc, req, file_priv);
> + if (drm_core_check_feature(DRIVER_ATOMIC))
> + ret = drm_mode_cursor_atomic(crtc, req, file_priv);
> + else
> + ret = drm_mode_cursor_universal(crtc, req, file_priv);
>   goto out;

>   drm_mode_cursor_atomic would simply be a fusing of
>   drm_mode_cursor_universal + drm_atomic_helper_update_plane (dump all the
>   intermediate variables and store directly in the plane state), with the
>   addition of also storing hot_x/y into the plane state.

Hmm, that'll either make drm_mode_cursor_atomic a big cut+pasted
function, or need quite some refactoring to move common code into
functions callable from both drm_mode_cursor_atomic
+drm_mode_cursor_universal ...

Why attach the hotspot to the plane?  Wouldn't it make more sense to
make it a framebuffer property?

cheers,
  Gerd



Re: [PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

2016-05-30 Thread Carlo Caione
On 30/05/16 15:29, Neil Armstrong wrote:
> Add watchdog specific driver for Amlogic Meson GXBB SoC.
> 
> Signed-off-by: Neil Armstrong 
> +

> +#define GXBB_WDT_CTRL1_REG   0x4
...
> +#define GXBB_WDT_CTRL_EE_RESET_NOW   BIT(26)
...
> +#define GXBB_WDT_CTRL_IRQ_EN BIT(23)
...
> +#define GXBB_WDT_CTRL_XTAL_SEL   (0)
...
> +#define GXBB_WDT_CTRL_CLK81_SEL  BIT(19)
...
> +#define GXBB_WDT_CTRL1_GPIO_PULSEBIT(17)
...
> +#define GXBB_WDT_CTRL1_GPIO_POL_RESET_0  BIT(16)
> +#define GXBB_WDT_CTRL1_GPIO_POL_RESET_1  (0)
> +#define GXBB_WDT_CTRL1_GPIO_PULSE_CNT(BIT(16) - 1)

nit: all these defines are not used at all in the driver. You can remove them

Thanks!


-- 
Carlo Caione


[PATCH] staging: iio: fix ad7606_spi regression

2016-05-30 Thread Arnd Bergmann
As pointed out by Geert Uytterhoeven, the patch was incorrect
and breaks the driver, which was fortunately pointed out by
this gcc warning:

drivers/staging/iio/adc/ad7606_spi.c: In function ‘ad7606_spi_read_block’:
drivers/staging/iio/adc/ad7606_spi.c:34: warning: ‘data’ is used uninitialized 
in this function

The effect of the patch is that the data is copied into
a random memory location (from the uninitialized pointer)
instead of being byteswapped in place.

This adds the initialization for the 'data' variable back
to restore the original behavior.

Cc: Geert Uytterhoeven 
Cc: Ksenija Stanojevic 
Fixes: 87787e5ef727 ("Staging: iio: Fix sparse endian warning")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/iio/adc/ad7606_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/adc/ad7606_spi.c 
b/drivers/staging/iio/adc/ad7606_spi.c
index 825da0769936..9587fa86dc69 100644
--- a/drivers/staging/iio/adc/ad7606_spi.c
+++ b/drivers/staging/iio/adc/ad7606_spi.c
@@ -21,7 +21,7 @@ static int ad7606_spi_read_block(struct device *dev,
 {
struct spi_device *spi = to_spi_device(dev);
int i, ret;
-   unsigned short *data;
+   unsigned short *data = buf;
__be16 *bdata = buf;
 
ret = spi_read(spi, buf, count * 2);
-- 
2.7.0



Re: [PATCH] staging: iio: fix ad7606_spi regression

2016-05-30 Thread Geert Uytterhoeven
On Mon, May 30, 2016 at 3:50 PM, Arnd Bergmann  wrote:
> As pointed out by Geert Uytterhoeven, the patch was incorrect
> and breaks the driver, which was fortunately pointed out by
> this gcc warning:
>
> drivers/staging/iio/adc/ad7606_spi.c: In function ‘ad7606_spi_read_block’:
> drivers/staging/iio/adc/ad7606_spi.c:34: warning: ‘data’ is used 
> uninitialized in this function
>
> The effect of the patch is that the data is copied into
> a random memory location (from the uninitialized pointer)
> instead of being byteswapped in place.
>
> This adds the initialization for the 'data' variable back
> to restore the original behavior.
>
> Cc: Geert Uytterhoeven 
> Cc: Ksenija Stanojevic 
> Fixes: 87787e5ef727 ("Staging: iio: Fix sparse endian warning")
> Signed-off-by: Arnd Bergmann 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [patch V2 2/7] futex: Hash private futexes per process

2016-05-30 Thread Sebastian Andrzej Siewior
On 05/30/2016 03:49 PM, Peter Zijlstra wrote:
>> The same thing can happen within a Task if you take my story from above
>> and replace task with thread. Completely understood.
> 
> Right; so I don't see the point of PREALLOCATE_HASH to cater for RT
> workloads if it still doesn't guarantee anything, esp. if the failure
> case is silent and obscure.

So what do you suggest? Adding trace points in order to learn about
possible collisions or using tickets (on top of this) to guarantee
being collision free?
Note: this as it, is already a win on NUMA boxes since the memory is
not referenced cross node.

Sebastian


Re: [PATCH v2 1/4] staging : comedi : fix type issues in s626.c

2016-05-30 Thread Luis de Bethencourt
On 28/05/16 06:26, Ravishankar Karkala Mallikarjunayya wrote:
> This is a patch to the s626.c file that fixes up a type issues like
> i.e Prefer kernel type 'u8' over 'uint8_t'
> Prefer kernel type 'u16' over 'uint16_t'
> Prefer kernel type 'u32' over 'uint32_t'
> Prefer kernel type 's16' over 'int16_t'
> Prefer kernel type 's32' over 'int32_t'
> found by the checkpatch.pl tool.
> 
> Signed-off-by: Ravishankar Karkala Mallikarjunayya 

>From the CodingStyle [0]:

"Although it would only take a short amount of time for the eyes and
brain to become accustomed to the standard types like 'uint32_t',
some people object to their use anyway.

Therefore, the Linux-specific 'u8/u16/u32/u64' types and their
signed equivalents which are identical to standard types are
permitted -- although they are not mandatory in new code of your
own.

When editing existing code which already uses one or the other set
of types, you should conform to the existing choices in that code."

Not sure why checkpatch complains about this when the CodingStyle suggests
to conform to the choice in the existing code.

Anybody can shed some light on this?

Thanks,
Luis



[0] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle#n318



Re: [patch V2 2/7] futex: Hash private futexes per process

2016-05-30 Thread Peter Zijlstra
On Mon, May 30, 2016 at 03:59:51PM +0200, Sebastian Andrzej Siewior wrote:
> On 05/30/2016 03:49 PM, Peter Zijlstra wrote:
> >> The same thing can happen within a Task if you take my story from above
> >> and replace task with thread. Completely understood.
> > 
> > Right; so I don't see the point of PREALLOCATE_HASH to cater for RT
> > workloads if it still doesn't guarantee anything, esp. if the failure
> > case is silent and obscure.
> 
> So what do you suggest? Adding trace points in order to learn about
> possible collisions or using tickets (on top of this) to guarantee
> being collision free?

I have no idea about the ticket stuff, i've not seen it. But yes, you
need to somehow guarantee no collisions.


Re: [RFC PATCHv2] usb: USB Type-C Connector Class

2016-05-30 Thread Oliver Neukum
On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> Hi guys,
> 
> I'm attaching a diff instead of full v3. I'm not yet adding attributes
> for the reset and cable_reset. I still don't understand what is the
> case where the userspace would need to be able to tricker reset? Why
> isn't it enough for the userspace to be able to enter/exit modes?
> Oliver! Can you please comment?

1. Because we need error handling.
   Devices crash. Cables will crash. We will get out of sync.
   You never put yourself in a place where you cannot handle an
   IO error.
2. Because it is in the spec. We do not second guess the spec.
   We implement it.

> I also made a change to the partner devices so that they always have
> the port as their parent. That will have an effect on the location
> where the partner device is exposed in sysfs (so now always under the
> port). And because of that, I would like to get an OK from you guys.

It is not very important. i am fine with it.

> I'm a bit concerned about the current API for adding the alternate
> modes. Since we are passing the parent for an alternate mode as
> struct device, it makes it possible for the caller to place it into
> some wrong place. But I guess we can change the API even later.
> 
> We also need to decide how the alternate modes a port support are
> exposed to the userspace. Do we just assume the port drivers will
> create them as devices under the port device itself, just like
> alternate modes of partners and cable plugs are exposed under the
> partners and cable plugs? That works for me, but again, the class does
> not have any effect on that, and it will be just a guideline. Maybe
> we can add some kind of helpers and force the port drivers to use
> them.

What are the alternatives?

> And finally, mostly as a reminder for myself. I didn't yet add
> attributes for Try.SRC/SNK. So can we make it something like
> "preferred_role" like I think you proposed Guenter? The
> "current_data_role" I'm dropping.

That sounds good.

Regards
Oliver




Re: [PATCH v8 00/14] USB OTG/dual-role framework

2016-05-30 Thread Roger Quadros
On 30/05/16 12:29, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:14PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> This series centralizes OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm and am437x-gp-evm.
>> NOTE: my am437x-gp-evm broke so I couldn't test v8 on it.
>> But the changes since v7 are trivial and shouldn't impact am437x-gp-evm.
>>
>> DWC3 controller and platform related patches will be sent separately.
>>
>> Series is based on v4.6-rc1 and depends on first 2 patches of [1]
>> [1] - OTG fsm cleanup - https://lkml.org/lkml/2016/3/30/186
>>
>> Why?:
>> 
>>
>> Currently there is no central location where OTG/dual-role functionality is
>> implemented in the Linux USB stack and every USB controller driver is
>> doing their own thing for OTG/dual-role. We can benefit from code-reuse
>> and simplicity by adding the OTG/dual-role core driver.
>>
>> Newer OTG cores support standard host interface (e.g. xHCI) so
>> host and gadget functionality are no longer closely knit like older
>> cores. There needs to be a way to co-ordinate the operation of the
>> host and gadget controllers in dual-role mode. i.e. to stop and start them
>> from a central location. This central location should be the
>> USB OTG/dual-role core.
>>
>> Host and gadget controllers might be sharing resources and can't
>> be always running. One has to be stopped for the other to run.
>> This couldn't be done till now but can be done from the OTG core.
>>
>> What?:
>> -
>>
>> The OTG/dual-role core consists of a set of APIs that allow
>> registration of OTG controller device and OTG capable host and gadget
>> controllers.
>>
>> - The OTG controller driver can provide the OTG capabilities and the
>> Finite State Machine work function via 'struct usb_otg_config'
>> at the time of registration i.e. usb_otg_register();
>>
>>  struct usb_otg *usb_otg_register(struct device *dev,
>>   struct usb_otg_config *config);
>>  int usb_otg_unregister(struct device *dev);
>>  /**
>>   * struct usb_otg_config - otg controller configuration
>>   * @caps: otg capabilities of the controller
>>   * @ops: otg fsm operations
>>   * @otg_work: optional custom otg state machine work function
>>   */
>>  struct usb_otg_config {
>>  struct usb_otg_caps *otg_caps;
>>  struct otg_fsm_ops *fsm_ops;
>>  void (*otg_work)(struct work_struct *work);
>>  };
>>
>> The dual-role state machine is built-into the OTG core so nothing
>> special needs to be provided if only dual-role functionality is desired.
>> The low level OTG controller driver ops are povided via
>> 'struct otg_fsm_ops *fsm_ops' in the 'struct usb_otg_config'.
>>
>> After registration, the OTG core waits for host, gadget controller
>> and the gadget function driver to be registered. Once all resources are
>> available it instantiates the Finite State Machine (FSM).
>> The host/gadget controllers are started/stopped according to the FSM.
>>
>> - Host and gadget controllers that are a part of OTG/dual-role port must
>> use the OTG core provided APIs to add/remove the host/gadget.
>> i.e. hosts must use usb_otg_add_hcd() usb_otg_remove_hcd(),,
>> gadgets must use usb_otg_add_gadget_udc() usb_del_gadget_udc().
>> This ensures that the host and gadget controllers are not started till
>> the state machine is ready and the right bus conditions are met.
>> It also allows the host and gadget controllers to provide the OTG
>> controller device to link them together. For Device tree boots
>> the related OTG controller is automatically picked up via the
>> 'otg-controller' property in the Host/Gadget controller nodes.
>>
>>  int usb_otg_add_hcd(struct usb_hcd *hcd,
>>  unsigned int irqnum, unsigned long irqflags,
>>  struct device *otg_dev);
>>  void usb_otg_remove_hcd(struct usb_hcd *hcd);
>>
>>  int usb_otg_add_gadget_udc(struct device *parent,
>> struct usb_gadget *gadget,
>> struct device *otg_dev);
>>  usb_del_gadget_udc() must be used for removal.
>>
>>
>> - During the lifetime of the FSM, the OTG controller driver can provide
>> inputs event changes using usb_otg_sync_inputs(). The OTG core will
>> then schedule the FSM work function (or internal dual-role state machine)
>> to update the FSM state. The FSM then calls the OTG controller
>> operations (fsm_ops) as necessary.
>>  void usb_otg_sync_inputs(struct usb_otg *otg);
>>
>> - The following 2 functions are provided as helpers for use by the
>> OTG controller driver to start/stop the host/gadget controllers.
>>  int usb_otg_start_host(struct usb_otg *otg, int on);
>>  int usb_otg_start_gadget(struct usb_otg *otg, int on);
>>
>> - The following function is provided for use by the USB host stack
>> to sync OTG related events to 

Re: [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr.

2016-05-30 Thread Miklos Szeredi
On Fri, May 20, 2016 at 11:53:18PM +0300, Krisztian Litkey wrote:
> On Fri, May 20, 2016 at 8:00 PM, Mimi Zohar  wrote:

> > We deferred __fput() back in 2012 in order for IMA to safely take the
> > i_mutex and write security.ima.   Writing the security.ima xattr now
> > triggers overlayfs to write the xattr, but overlayfs doesn't
> > differentiate between callers - as a result of userspace or as described
> > here in __fput().   All calls to ovl_setxattr() should call vfs_sexattr,
> > except the one triggered by __fput().   Refer to the original lockdep
> > report -
> > http://thread.gmane.org/gmane.linux.file-systems.union/640

Looks like more fallout from 4bacc9c9234c ("overlayfs: Make f_path always point
to the overlay and f_inode to the underlay").

Not sure what we want here.  Doing everything on the underlying dentry/inode
would be trivial (see attached patch).

Question is, can we get setxattr() on file opened for O_RDONLY?  If so, then
that could fail on overlayfs (lower layer is read-only).

Thanks,
Miklos

---
From: Miklos Szeredi 
Subject: ima: use file_path()

Ima tries to call ->setxattr() on overlayfs dentry after having locked
underlying inode, which results in a deadlock.

Reported-by: Krisztian Litkey 
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and 
f_inode to the underlay")
Signed-off-by: Miklos Szeredi 
Cc:  # v4.2
---
 security/integrity/ima/ima_appraise.c |4 ++--
 security/integrity/ima/ima_main.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -222,7 +222,7 @@ static int process_measurement(struct fi
if ((action & IMA_APPRAISE_SUBMASK) ||
strcmp(template_desc->name, IMA_TEMPLATE_IMA_NAME) != 0)
/* read 'security.ima' */
-   xattr_len = ima_read_xattr(file->f_path.dentry, &xattr_value);
+   xattr_len = ima_read_xattr(file_dentry(file), &xattr_value);
 
hash_algo = ima_get_hash_algo(xattr_value, xattr_len);
 
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -190,7 +190,7 @@ int ima_appraise_measurement(enum ima_ho
 {
static const char op[] = "appraise_data";
char *cause = "unknown";
-   struct dentry *dentry = file->f_path.dentry;
+   struct dentry *dentry = file_dentry(file);
struct inode *inode = d_backing_inode(dentry);
enum integrity_status status = INTEGRITY_UNKNOWN;
int rc = xattr_len, hash_start = 0;
@@ -295,7 +295,7 @@ int ima_appraise_measurement(enum ima_ho
  */
 void ima_update_xattr(struct integrity_iint_cache *iint, struct file *file)
 {
-   struct dentry *dentry = file->f_path.dentry;
+   struct dentry *dentry = file_dentry(file);
int rc = 0;
 
/* do not collect and update hash for digital signatures */


Re: [PATCH v2 2/4] Staging: comedi: Fix WARNING issue in s626.c

2016-05-30 Thread Luis de Bethencourt
On 28/05/16 06:26, Ravishankar Karkala Mallikarjunayya wrote:
> This is a patch to the s626.c file that fixes up a Block comments
> issues found by the checkpatch.pl tool.
> 
> i.e. Block comments use a trailing */ on a separate line
> 
> Signed-off-by: Ravishankar Karkala Mallikarjunayya 

We can see in the diff this is making changes in s626.c :) no need to mention
that in the commit message.

Not sure moving the opening and closing of comments (/* and */) to a new line
makes things more readable. checkpatch is a great tool but it gives suggestions,
not hard rules.
Just a comment since I've seen multiple people follow checkpatch blindly, and
it is best to use your discretion.

Maintainer of this code will probably have a preference.

Thank you for your patches Ravishankar.

Luis



[PATCH 2/3] dt-bindings: watchdog: Add Meson GXBB Watchdog bindings

2016-05-30 Thread Neil Armstrong
Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/watchdog/meson-gxbb-wdt.txt  | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
new file mode 100644
index 000..c7fe36f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
@@ -0,0 +1,16 @@
+Meson GXBB SoCs Watchdog timer
+
+Required properties:
+
+- compatible : should be "amlogic,meson-gxbb-wdt"
+- reg : Specifies base physical address and size of the registers.
+- clocks : Should be a phandle to the Watchdog clock source, for GXBB the xtal
+  is the default clock source.
+
+Example:
+
+wdt: watchdog@98d0 {
+   compatible = "amlogic,meson-gxbb-wdt";
+   reg = <0 0x98d0 0x0 0x10>;
+   clocks = <&xtal>;
+};
-- 
2.7.0



Re: [PATCH 0/3] watchdog: Add Amlogic Meson GXBB Watchdog Timer driver

2016-05-30 Thread Neil Armstrong
On 05/30/2016 03:45 PM, Carlo Caione wrote:
> On 30/05/16 15:29, Neil Armstrong wrote:
>> Adds support for the Amlogic Meson GXBB SoC Watchdog Timer.
>> It differs from the meson6/meson8b HW, so need for a separate driver.
>> The HW provides a divider capable of having a 1ms timebase thus simplifying
>> the counter update.
>> The restart call is not provided even if the HW is capable of triggering a
>> system reset immediately because of the PSCI firmare having such 
>> functionnality.
>> The watchdog is not expected to be running at boot time since there is a 
>> separate
>> system-level watchdog running from the SCPI co-processor, but this case 
>> would be
>> handle in a next driver update.
>>
>> Changes since RFC version at 
>> http://lkml.kernel.org/r/1464249112-13658-1-git-send-email-narmstr...@baylibre.com
>>  :
>> - Remove status callback, will re-introduce it later to managed the 
>> already-running use case
>> - Fix registers defines indentation
>> - Fix space between operators
>> - Make all callbacks static functions
>> - Fix bindings with missing clocks attribute
>> - Do not stop/start watchdog on a timeout setup
>> - Fix probe device configuration
>>
>> Neil Armstrong (3):
>>   watchdog: Add Meson GXBB Watchdog Driver
>>   dt-bindings: watchdog: Add Meson GXBB Watchdog bindings
>>   ARM64: dts: amlogic: meson-gxbb: Add watchdog node
> 
> I'm missing [PATCH 2/3]
> 
Sorry, fixed here :


"systemd[1]: Failed to apply local time delta" with v4.7-rc1

2016-05-30 Thread Mika Westerberg
Hi,

I noticed that when I boot my Lenovo Yoga 900 with v4.7-rc1 I get
following error from systemd:

  systemd[1]: Failed to apply local time delta, ignoring: Invalid argument

and my system time is left being 180 minutes off.

With following commits reverted it works fine:

  86d3473224b0 time: Introduce do_sys_settimeofday64()
  457db29bfcfd security: Introduce security_settime64()

and systemd prints:

  systemd[1]: RTC configured in localtime, applying delta of 180 minutes to 
system time.

>From systemd source code it seems to use Linux specific feature to "warp" the
system clock according the timezone passed in:

  clock_set_timezone() {
const struct timeval *tv_null = NULL;

...

/*
 * If the RTC does not run in UTC but in local time, the very first
 * call to settimeofday() will set the kernel's timezone and will warp 
the
 * system clock, so that it runs in UTC instead of the local time we
 * have read from the RTC.
 */
if (settimeofday(tv_null, &tz) < 0)
return -errno;
if (min)
*min = minutesdelta;

With commit 86d3473224b0 it seems that do_sys_settimeofday() started returning
-EINVAL when tv is NULL which seems to break the above.

Is this intentional or am I missing something?


Re: [PATCH v2 3/4] Staging: comedi:Fix unsigned int to bare use of unsigned issue in s626.c

2016-05-30 Thread Luis de Bethencourt
On 28/05/16 06:26, Ravishankar Karkala Mallikarjunayya wrote:
> This is a patch to the s626.c file that fixes up a
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> found by the checkpatch.pl tool
> 
> Signed-off-by: Ravishankar Karkala Mallikarjunayya 

The patch looks good :) adding the int makes it more verbose.

Just the same comment as the previous patch, we can see in the diff which file
is affected by this. You can just say:
"This fixes a WARNING: Prefer 'unsigned int' ..."

Thanks,
Luis



[PATCH 2/2] PCI: hv: handle all pending messages in hv_pci_onchannelcallback()

2016-05-30 Thread Vitaly Kuznetsov
When we have an interrupt from host we have a bit set in event page
indicating there are messages for the particular channel. We need to read
them all as we won't get signaled for what was on the queue before we
cleared the bit in vmbus_on_event(). This applies to all Hyper-V drivers
and the pass-through driver should do the same.
I did non meet any bugs, the issue was found by code inspection. We don't
have many events going through hv_pci_onchannelcallback(), this explains
why nobody reported the issue before.

While on it, fix handling non-zero vmbus_recvpacket_raw() return values by
dropping out. If the return value is not zero it is wrong to inspect
buffer or bytes_recvd as these may contain invalid data.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/pci/host/pci-hyperv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index a68ec49..7de341d 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1657,12 +1657,16 @@ static void hv_pci_onchannelcallback(void *context)
continue;
}
 
+   /* Zero length indicates there are no more packets. */
+   if (ret || !bytes_recvd)
+   break;
+
/*
 * All incoming packets must be at least as large as a
 * response.
 */
if (bytes_recvd <= sizeof(struct pci_response))
-   break;
+   continue;
desc = (struct vmpacket_descriptor *)buffer;
 
switch (desc->type) {
@@ -1724,7 +1728,6 @@ static void hv_pci_onchannelcallback(void *context)
desc->type, req_id, bytes_recvd);
break;
}
-   break;
}
 
kfree(buffer);
-- 
2.5.5



[PATCH 1/2] PCI: hv: don't leak buffer in hv_pci_onchannelcallback()

2016-05-30 Thread Vitaly Kuznetsov
We don't free buffer on several code paths in hv_pci_onchannelcallback(),
put kfree() to the end of the function to fix the issue. Direct { kfree();
return; } can now be replaced with a simple 'break';

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/pci/host/pci-hyperv.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 7e9b2de..a68ec49 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1661,10 +1661,8 @@ static void hv_pci_onchannelcallback(void *context)
 * All incoming packets must be at least as large as a
 * response.
 */
-   if (bytes_recvd <= sizeof(struct pci_response)) {
-   kfree(buffer);
-   return;
-   }
+   if (bytes_recvd <= sizeof(struct pci_response))
+   break;
desc = (struct vmpacket_descriptor *)buffer;
 
switch (desc->type) {
@@ -1679,8 +1677,7 @@ static void hv_pci_onchannelcallback(void *context)
comp_packet->completion_func(comp_packet->compl_ctxt,
 response,
 bytes_recvd);
-   kfree(buffer);
-   return;
+   break;
 
case VM_PKT_DATA_INBAND:
 
@@ -1729,6 +1726,8 @@ static void hv_pci_onchannelcallback(void *context)
}
break;
}
+
+   kfree(buffer);
 }
 
 /**
-- 
2.5.5



[PATCH 0/2] PCI: hv: fix a couple of issues in hv_pci_onchannelcallback()

2016-05-30 Thread Vitaly Kuznetsov
kmemleak helped me to identify a memory leak in hv_pci_onchannelcallback()
and while fixing it I stumbled upon an unrelated issue(s) there.

Vitaly Kuznetsov (2):
  PCI: hv: don't leak buffer in hv_pci_onchannelcallback()
  PCI: hv: handle all pending messages in hv_pci_onchannelcallback()

 drivers/pci/host/pci-hyperv.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

-- 
2.5.5



[PATCH stable] serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios()

2016-05-30 Thread Krzysztof Kozlowski
From: Chanwoo Choi 

commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream.

This patch fixes the broken serial log when changing the clock source
of uart device. Before disabling the original clock source, this patch
enables the new clock source to protect the clock off state for a split second.

[k.kozlowski]:
On SMP systems this opens a short time window when both clocks (old and
new) are disabled and a second thread uses TTY/UART. This leads to
broken log or imprecise external abort (on one of ARM64 boards):

Unhandled fault: synchronous external abort (0x96000210) at 0xff8008080008
Internal error: : 96000210 [#1] PREEMPT SMP
[] s3c24xx_serial_console_putchar+0x8/0x64
[] s3c24xx_serial_console_write+0x30/0x38
[] call_console_drivers.constprop.22+0x100/0x108
[] console_unlock+0x504/0x58c
[] vprintk_emit+0x2cc/0x478
[] vprintk_default+0x38/0x40
[] printk+0xac/0xb8
[] audit_printk_skb+0x68/0x6c
[] audit_log_end+0x13c/0x188
[] common_lsm_audit+0xb4/0x618
[] smack_log+0xe8/0x10c
[] smk_tskacc+0x8c/0xa4
[] smk_curacc+0x2c/0x34
[] smack_inode_permission+0x60/0x70
[] security_inode_permission+0x58/0x80
[] __inode_permission+0x40/0xa0
[] inode_permission+0x14/0x4c
[] may_open+0x5c/0x10c
[] path_openat+0x13c/0xec8
[] do_filp_open+0x64/0xc0
[] do_sys_open+0x144/0x208
[] SyS_openat+0x10/0x18
[] __sys_trace_return+0x0/0x4

Signed-off-by: Chanwoo Choi 
Reviewed-by: Marek Szyprowski 
Signed-off-by: Greg Kroah-Hartman 
Cc: 
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
[k.kozlowski: Backport to stable, update commit msg]
Signed-off-by: Krzysztof Kozlowski 

---

The original Samsung serial driver was broken so this should be
backported as far as possible including the 2.6.12. :)
---
 drivers/tty/serial/samsung.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index ac7f8df54406..99bb23161dd6 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1271,6 +1271,8 @@ static void s3c24xx_serial_set_termios(struct uart_port 
*port,
/* check to see if we need  to change clock source */
 
if (ourport->baudclk != clk) {
+   clk_prepare_enable(clk);
+
s3c24xx_serial_setsource(port, clk_sel);
 
if (!IS_ERR(ourport->baudclk)) {
@@ -1278,8 +1280,6 @@ static void s3c24xx_serial_set_termios(struct uart_port 
*port,
ourport->baudclk = ERR_PTR(-EINVAL);
}
 
-   clk_prepare_enable(clk);
-
ourport->baudclk = clk;
ourport->baudclk_rate = clk ? clk_get_rate(clk) : 0;
}
-- 
1.9.1



Re: [PATCH trivial] include/linux/memblock.h: Clean up code for several trivial details

2016-05-30 Thread Chen Gang
On 5/29/16 23:08, Joe Perches wrote:
> On Sun, 2016-05-29 at 22:36 +0800, cheng...@emindsoft.com.cn wrote:
>>
>> Use "!!" to let the boolean function return boolean value directly.
> []
>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> []
>> @@ -191,12 +190,12 @@ static inline bool movable_node_is_enabled(void)
>>  
>>  static inline bool memblock_is_mirror(struct memblock_region *m)
>>  {
>> -return m->flags & MEMBLOCK_MIRROR;
>> +return !!(m->flags & MEMBLOCK_MIRROR);
> 
> These !! uses are't necessary.
> The compiler makes the bool return 0 or 1.
> 

No, they are not necessary. But for me, it will be more clearer, since
in our kernel (at least in include/linux/), almost all Boolean functions
use Boolean value or expression for return (and "!!" are often used).

Please help check, and welcome any additional ideas, suggestions, and
completions.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.


Re: [PATCH 1/6] proc, oom: drop bogus task_lock and mm check

2016-05-30 Thread Vladimir Davydov
On Mon, May 30, 2016 at 03:05:51PM +0200, Michal Hocko wrote:
> From: Michal Hocko 
> 
> both oom_adj_write and oom_score_adj_write are using task_lock,
> check for task->mm and fail if it is NULL. This is not needed because
> the oom_score_adj is per signal struct so we do not need mm at all.
> The code has been introduced by 3d5992d2ac7d ("oom: add per-mm oom
> disable count") but we do not do per-mm oom disable since c9f01245b6a7
> ("oom: remove oom_disable_count").
> 
> The task->mm check is even not correct because the current thread might
> have exited but the thread group might be still alive - e.g. thread
> group leader would lead that echo $VAL > /proc/pid/oom_score_adj would
> always fail with EINVAL while /proc/pid/task/$other_tid/oom_score_adj
> would succeed. This is unexpected at best.
> 
> Remove the lock along with the check to fix the unexpected behavior
> and also because there is not real need for the lock in the first place.
> 
> Signed-off-by: Michal Hocko 

Reviewed-by: Vladimir Davydov 


Re: [PATCH v2 4/4] Staging: comedi: fix line over 80 characters issue in s626.c

2016-05-30 Thread Luis de Bethencourt
On 28/05/16 06:26, Ravishankar Karkala Mallikarjunayya wrote:
> This is a patch to the s626.c file that fixes up a  line over 80
> characters issues found by the checkpatch.pl tool.
> 
> Signed-off-by: Ravishankar Karkala Mallikarjunayya 

Looks good :)

This is the only instance of the line over 80 characters Warning in that file.

Like previous patches, no need to mention the file being fixed in the commit
message. It isn't a big deal though.

+1

Luis



Re: [PATCH v6 10/11] perf callchain: Support x86 target platform

2016-05-30 Thread Jiri Olsa
On Mon, May 30, 2016 at 06:58:40PM +0800, Hekuang wrote:

SNIP

> > I think it's ok to include arch/arm/c
> > from arch/x86/util/unwind-libunwind-arm64.c
> > 
> > jirka
> 
> By following your advise, if ARCH=x86, the file tree will
> be like this:
> 
> arch/x86
> -arch/x86/util/unwind-libunwind-arm64.c
> -arch/x86/util/unwind-libunwind-x86_32.c
> -arch/x86/util/unwind-libunwind-x86_64.c
> -arch/x86/util/unwind-libunwind-arm.c
> 
> And for ARCH=arm (host machine is arm, it should be considered)
> arch/arm
> -arch/arm/util/unwind-libunwind-arm64.c
> -arch/arm/util/unwind-libunwind-x86_32.c
> -arch/arm/util/unwind-libunwind-x86_64.c
> -arch/arm/util/unwind-libunwind-arm.c
> 
> For arm64:
> arch/arm64
> -arch/arm64/util/unwind-libunwind-arm64.c
> -arch/arm64/util/unwind-libunwind-x86_32.c
> -arch/arm64/util/unwind-libunwind-x86_64.c
> -arch/arm64/util/unwind-libunwind-arm.c
> 
> But in my patch, the file tree is like this:
> 
> arch
> -arch/arm64/util/unwind-libunwind-arm64.c
> -arch/x86/util/unwind-libunwind-x86_64.c
> -arch/x86/util/unwind-libunwind-x86_32.c
> -arch/arm/util/unwind-libunwind-arm.c
> 
> I admit that
> 
> +libperf-$(CONFIG_LIBUNWIND_X86)  += x86/util/unwind-libunwind_x86_32.o
> 
> is not so good, but do you think the above file tree is
> too redunctant?

i see.. we could leave it like that, I just wish
it'd be more clear.. one last thought:

how about moving libunwind arch files into special folder:

  util/libunwind/arm64.c
  util/libunwind/x86_32.c
  util/libunwind/x86_64.c
  util/libunwind/arm.c

thanks,
jirka


Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

2016-05-30 Thread Rafael J. Wysocki
On Mon, May 30, 2016 at 12:18 PM, Viresh Kumar  wrote:
> On 29-05-16, 02:40, Rafael J. Wysocki wrote:
>> I can't really parse the above question, so I'm not going to try to
>> answer it. :-)
>
> Sorry about that :(
>
> IOW, I think that we should make this change into the sched-governor (I will
> send a patch separately if you agree to this):

I don't.

> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 14c4aa25cc45..5934b14aa21c 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -66,11 +66,6 @@ static bool sugov_should_update_freq(struct sugov_policy 
> *sg_policy, u64 time)
>
> if (unlikely(sg_policy->need_freq_update)) {
> sg_policy->need_freq_update = false;
> -   /*
> -* This happens when limits change, so forget the previous
> -* next_freq value and force an update.
> -*/
> -   sg_policy->next_freq = UINT_MAX;
> return true;
> }
>
> And here is my reasoning behind this.
>
> Can you show me any case, where the above code (as present in mainline
> today) leads to a freq-change? I couldn't find any.
>
> Let me demonstrate.
>
> Following only talks about the fast-switch path, the other path is
> same as well.
>
> Suppose this is the current range of frequencies supported by a
> driver: 200, 400, 600, 800, 1000 (in MHz).
>
> And policy->cur = next_freq = 400 MHz.
>
> A.) Suppose that we change policy->min to 400 MHz from userspace.
> -> sugov_limits()
>This will find everything in order and simply set
>need_freq_update, without updating the frequency.
>
> On next util-callback, we will forcefully return true from
> sugov_should_update_freq() and reach sugov_update_commit().
>
> We calculate next_freq and that comes to 400 MHz again (that's the
> case we are trying to target with the above code).
>
> With the current code, we will forcefully end up calling
> cpufreq_driver_fast_switch().
>
> Because the new and current frequencies are same,
> cpufreq_driver->fast_switch() will simply return.
>
> NOTE: I also think that cpufreq_driver_fast_switch() should have a
> check like (policy->cur == target_freq). I will add that too, in
> case you agree.
>
> So, forcefully updating next_freq to UINT_MAX will end up wasting
> some cycles, but wouldn't do any useful stuff.

It will, but there's no way to distinguish this case from B in the
governor with the current min/max synchronization mechanism.  That is,
it only knows that something has changed, but checking what exactly
has changed would be racy.

> B.) Suppose that we change policy->min to 600 MHz from userspace.
> -> sugov_limits()
>This will find that policy->cur is less than 600 and will set
>that to 600 MHz by calling __cpufreq_driver_target(). We will
>also set need_freq_update.
>
>Note that next_freq and policy->cur are not in sync anymore and
>perhaps this is the most important case for the above code.

It is.

Moreover, please note that __cpufreq_driver_target() is only called in
sugov_limits() when policy->fast_switch_enabled is unset.

> On next util-callback, we will forcefully return true from
> sugov_should_update_freq() and reach sugov_update_commit().
>
> We calculate next_freq and lets say that comes to 400 MHz again
> (as that's the case we are trying to target with the above code).
>
> With the current code, we will forcefully end up calling
> cpufreq_driver_fast_switch().
>
> Because next_freq() is not part of the new range, we will clamp it
> and set it to 600 MHz eventually. Again, next and current
> frequencies are same, cpufreq_driver->fast_switch() will simply
> return.

Not really (as per the above).

And even in the !fast_switch_enabled case, if next_freq stays at 400
MHz (which is different from policy->cur), it may lead to suboptimal
decisions going forward (eg. if it goes to 600 MHz next time and the
governor will think that the frequency has changed, although in fact
it hasn't).

I guess the !fast_switch_enabled case might be optimized by comparing
next_freq with policy->cur at one point, but next_freq should be
updated regardless IMO.


Re: [PATCH 00/26] fb/drm: omapdss: Clean up the headers and separate the two stack

2016-05-30 Thread Tomi Valkeinen
Hi Peter, Tony,

On 30/05/16 14:42, Peter Ujfalusi wrote:
> Hi,
> 
> omapfb is deprecated. It will not receive new features, only bug fixes. On 
> the.
> other hand omapdrm is in active development and the fact that both
> implementation (omapfb and omapdrm) is using the same header file
> (video/omapdss.h) makes implementing new features or doing bigger clean ups in
> omapdrm harder and hared as the change should not break omapfb.
> 
> To overcome this issue we need to separate the two implementation. This is the
> aim of this series:
> Create platform_data header for omapdss,
> clean up the header usage and dependencies,
> new header file for omapfb stack (video/omapfb_dss.h)
> local omapdss.h header file for omapdrm.
> 
> To generate the set I have used:
> git format-patch -C20 --find-copies-harder

Yeah, you need to drop -C20 to get a bit saner "renames" in the patches =).

But otherwise, looks good.

One thing which is not strictly required, but I think should be added,
is cleaning up the omap-panel-data.h from the drm side. There are many
panels including the file, but not using it.

I don't think there's any sane way to split this series into different
subsystems. So I think we should merge this via drm tree.

Tony, can we get acks from you for the mach-omap2 patches? Do you think
there's anything there that could cause bigger conflicts?

 Tomi



signature.asc
Description: OpenPGP digital signature


Re: [PATCH v4 09/10] cpuidle/powernv: Add support for POWER ISA v3 idle states

2016-05-30 Thread Daniel Lezcano

On 05/24/2016 03:15 PM, Shreyas B. Prabhu wrote:

POWER ISA v3 defines a new idle processor core mechanism. In summary,
  a) new instruction named stop is added.
  b) new per thread SPR named PSSCR is added which controls the behavior
of stop instruction.

Supported idle states and value to be written to PSSCR register to enter
any idle state is exposed via ibm,cpu-idle-state-names and
ibm,cpu-idle-state-psscr respectively. To enter an idle state,
platform provided power_stop() needs to be invoked with the appropriate
PSSCR value.

This patch adds support for this new mechanism in cpuidle powernv driver.

Cc: Rafael J. Wysocki 
Cc: Daniel Lezcano 
Cc: linux...@vger.kernel.org
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: linuxppc-...@lists.ozlabs.org
Reviewed-by: Gautham R. Shenoy 
Signed-off-by: Shreyas B. Prabhu 
---
  - No changes since v1

  drivers/cpuidle/cpuidle-powernv.c | 57 ++-
  1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index e12dc30..efe5221 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -21,6 +21,7 @@
  #include 

  #define MAX_POWERNV_IDLE_STATES   8
+#define MAX_IDLE_STATE_NAME_LEN10


Why not reuse cpuidle constants even if they are slightly different ?

#define CPUIDLE_STATE_MAX   10
#define CPUIDLE_NAME_LEN16


  struct cpuidle_driver powernv_idle_driver = {
.name = "powernv_idle",
@@ -29,9 +30,11 @@ struct cpuidle_driver powernv_idle_driver = {

  static int max_idle_state;
  static struct cpuidle_state *cpuidle_state_table;
+
+static u64 stop_psscr_table[MAX_POWERNV_IDLE_STATES];
+
  static u64 snooze_timeout;
  static bool snooze_timeout_en;
-
  static int snooze_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -139,6 +142,15 @@ static struct notifier_block setup_hotplug_notifier = {
.notifier_call = powernv_cpuidle_add_cpu_notifier,
  };

+static int stop_loop(struct cpuidle_device *dev,
+   struct cpuidle_driver *drv,
+   int index)
+{
+   ppc64_runlatch_off();
+   power_stop(stop_psscr_table[index]);
+   ppc64_runlatch_on();
+   return index;
+}
  /*
   * powernv_cpuidle_driver_init()
   */
@@ -169,6 +181,8 @@ static int powernv_add_idle_states(void)
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
u32 *latency_ns, *residency_ns, *flags;
+   u64 *psscr_val = NULL;
+   const char *names[MAX_POWERNV_IDLE_STATES];
int i, rc;

/* Currently we have snooze statically defined */
@@ -201,6 +215,23 @@ static int powernv_add_idle_states(void)
goto out_free_latency;
}

+   rc = of_property_read_string_array(power_mgt,
+   "ibm,cpu-idle-state-names", names, dt_idle_states);
+   if (rc < -1) {


Why < -1 ?


+   pr_warn("cpuidle-powernv: missing ibm,cpu-idle-states-names in 
DT\n");
+   goto out_free_latency;
+   }
+
+   if (cpu_has_feature(CPU_FTR_ARCH_300)) {


Isn't weird to mix cpu feature and DT bindings check ?


+   psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
+   GFP_KERNEL);
+   rc = of_property_read_u64_array(power_mgt,
+   "ibm,cpu-idle-state-psscr", psscr_val, dt_idle_states);


[cc'ed Lorenzo and Rob ]

I don't see the documentation for the binding. Wouldn't make sense to 
add the value per idle state instead of an index based array ?



+   if (rc < -1) {
+   pr_warn("cpuidle-powernv: missing ibm,cpu-idle-states-psscr 
in DT\n");
+   goto out_free_psscr;
+   }
+   }
residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states, 
GFP_KERNEL);
rc = of_property_read_u32_array(power_mgt,
"ibm,cpu-idle-state-residency-ns", residency_ns, 
dt_idle_states);
@@ -218,6 +249,16 @@ static int powernv_add_idle_states(void)
powernv_states[nr_idle_states].flags = 0;
powernv_states[nr_idle_states].target_residency = 100;
powernv_states[nr_idle_states].enter = &nap_loop;
+   } else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
+   !(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
+   strncpy(powernv_states[nr_idle_states].name,
+   (char *)names[i], MAX_IDLE_STATE_NAME_LEN);


Why cast names[] to (char *) while strncpy is waiting for const char *, 
the initial type of names[] ?



+   strncpy(powernv_states[nr_idle_states].desc,
+   (char *)names[i], MAX_IDLE_STATE_NAME_LEN);
+   powernv_states[nr_idle_states].flags =

Re: [PATCH 2/2] staging: slicoss: fix camel case check

2016-05-30 Thread Luis de Bethencourt
On 29/05/16 14:31, Jaime Arrocha wrote:
> From: Jaime Arrocha 
> 
> Fixed several checks about camel case use provided by checkpatch.pl.
> CHECK: Avoid CamelCase
> Changes verified to work by compiling module.
> 
> Signed-off-by: Jaime Arrocha 

Purpose of the patch is good but it fails to apply in my clone of the 
staging-testing
branch. Not sure why.

Can you check it applies cleanly in your side?

Thanks,
Luis




Re: [PATCH perf/core v9 00/16] perf-probe --cache and SDT support

2016-05-30 Thread Masami Hiramatsu
On Mon, 30 May 2016 12:54:58 +0900
Namhyung Kim  wrote:

> Hi Masami,
> 
> On Sun, May 29, 2016 at 12:15:01AM +0900, Masami Hiramatsu wrote:
> > Hi,
> > 
> > Here is the 9th version of the patchset for probe-cache and 
> > initial SDT support.
> > 
> > The previous version is here; https://lkml.org/lkml/2016/5/14/107
> > 
> > This version just fixes 2 points according to Hemant's comment,
> > and split out the filename__readable() patch.
> > 
> > Changes in v9:
> >   - [1/16,2/16] split out the filename__readable()
> >   - [7/16] Fix to show which event is deleted.
> >   - [12/16] Update list_usage to show sdt option.
> > 
> > Thank you,
> 
> Thanks for doing this, I hope this gets merged soon.  The patch 4 and
> 14 look a bit larger and would be better to be splitted IMHO.  Other
> than that, all look good to me.

Yeah, it seems 14/16 can be splitted, but 4/16 might not be.
When I need to update to v10, I'll try.

> 
> Acked-by: Namhyung Kim 

Thanks!


> 
> Thanks,
> Namhyung
> 
> 
> > 
> > ---
> > 
> > Hemant Kumar (1):
> >   perf/sdt: ELF support for SDT
> > 
> > Masami Hiramatsu (15):
> >   perf-symbol: Introduce filename__readable to check readability
> >   perf symbol: Cleanup the code flow of dso__find_kallsyms
> >   perf-buildid-cache: Use path/to/bin/buildid/elf instead of 
> > path/to/bin/buildid
> >   perf probe: Add --cache option to cache the probe definitions
> >   perf probe: Use cache entry if possible
> >   perf probe: Show all cached probes
> >   perf probe: Remove caches when --cache is given
> >   perf probe: Add group name support
> >   perf buildid-cache: Scan and import user SDT events to probe cache
> >   perf probe: Accept %sdt and %cached event name
> >   perf-list: Show SDT and pre-cached events
> >   perf-list: Skip SDTs placed in invalid binaries
> >   perf probe: Allow wildcard for cached events
> >   perf probe: Support @BUILDID or @FILE suffix for SDT events
> >   perf probe: Support a special SDT probe format
> > 
> > 
> >  tools/perf/Documentation/perf-probe.txt |   26 +-
> >  tools/perf/builtin-list.c   |6 
> >  tools/perf/builtin-probe.c  |   30 ++
> >  tools/perf/util/build-id.c  |  295 --
> >  tools/perf/util/build-id.h  |8 
> >  tools/perf/util/dso.h   |5 
> >  tools/perf/util/parse-events.c  |   83 +
> >  tools/perf/util/parse-events.h  |2 
> >  tools/perf/util/probe-event.c   |  492 
> > +++---
> >  tools/perf/util/probe-event.h   |7 
> >  tools/perf/util/probe-file.c|  504 
> > +++
> >  tools/perf/util/probe-file.h|   41 +++
> >  tools/perf/util/symbol-elf.c|  252 
> >  tools/perf/util/symbol.c|   71 ++--
> >  tools/perf/util/symbol.h|   22 +
> >  15 files changed, 1712 insertions(+), 132 deletions(-)
> > 
> > --
> > Masami Hiramatsu


-- 
Masami Hiramatsu 


[PATCH 0/5] Patches for QCOM IPQ4019 clock driver

2016-05-30 Thread Abhishek Sahu
These patches are related to Qualcomm IPQ4019 GCC (Global Clock
Controller) driver code mainly adding support for multiple CPU
frequencies and corrected fixed clock values.

Abhishek Sahu (5):
  clk: qcom: ipq4019: Modified the fixed clock rate to proper values
  clk: qcom: ipq4019: Added the apss cpu pll divider clock node
  clk: qcom: ipq4019: Added the cpu pll divider and changed regmap limit
  clk: qcom: ipq4019: Added the cpu clock frequency change notifier
  clk: qcom: ipq4019: Added the turbo frequency for apps cpu

 drivers/clk/qcom/gcc-ipq4019.c   | 195 +--
 include/dt-bindings/clock/qcom,gcc-ipq4019.h |   1 +
 2 files changed, 183 insertions(+), 13 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 1/5] clk: qcom: ipq4019: Modified the fixed clock rate to proper values

2016-05-30 Thread Abhishek Sahu
Modified the fixed clock rate initialization in the IPQ4019 clock
probe function with correct values.

Also some of the fixed clocks entries were not added in the current
driver file so added the same.

Signed-off-by: Abhishek Sahu 
---
 drivers/clk/qcom/gcc-ipq4019.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 3cd1af0..db24cb8 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -80,7 +80,7 @@ static struct parent_map gcc_xo_sdcc1_500_map[] = {
 
 static const char * const gcc_xo_sdcc1_500[] = {
"xo",
-   "ddrpll",
+   "ddrpllsdcc",
"fepll500",
 };
 
@@ -1317,13 +1317,15 @@ static int gcc_ipq4019_probe(struct platform_device 
*pdev)
 {
struct device *dev = &pdev->dev;
 
-   clk_register_fixed_rate(dev, "fepll125", "xo", 0, 2);
-   clk_register_fixed_rate(dev, "fepll125dly", "xo", 0, 2);
-   clk_register_fixed_rate(dev, "fepllwcss2g", "xo", 0, 2);
-   clk_register_fixed_rate(dev, "fepllwcss5g", "xo", 0, 2);
+   clk_register_fixed_rate(dev, "fepll125", "xo", 0, 12500);
+   clk_register_fixed_rate(dev, "fepll125dly", "xo", 0, 12500);
+   clk_register_fixed_rate(dev, "fepllwcss2g", "xo", 0, 25000);
+   clk_register_fixed_rate(dev, "fepllwcss5g", "xo", 0, 25000);
clk_register_fixed_rate(dev, "fepll200", "xo", 0, 2);
-   clk_register_fixed_rate(dev, "fepll500", "xo", 0, 2);
+   clk_register_fixed_rate(dev, "fepll500", "xo", 0, 5);
clk_register_fixed_rate(dev, "ddrpllapss", "xo", 0, 66600);
+   clk_register_fixed_rate(dev, "ddrpllsdcc", "xo", 0, 19300);
+   clk_register_fixed_rate(dev, "pcnoc_clk_src", "xo", 0, 1);
 
return qcom_cc_probe(pdev, &gcc_ipq4019_desc);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 5/5] clk: qcom: ipq4019: Added the turbo frequency for apps cpu

2016-05-30 Thread Abhishek Sahu
Added the CPU turbo frequency (710 Mhz) to frequency table of
APPS CPU clock.

Signed-off-by: Abhishek Sahu 
---
 drivers/clk/qcom/gcc-ipq4019.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 69a8250..c325618 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -665,11 +665,12 @@ static struct clk_apps_cpu_div gcc_apps_cpu_div_clk = {
 };
 
 static const struct freq_tbl ftbl_gcc_apps_clk[] = {
-   F(4800, P_XO,  1, 0, 0),
-   F(2, P_FEPLL200,   1, 0, 0),
-   F(5, P_FEPLL500,   1, 0, 0),
+   F(4800, P_XO, 1, 0, 0),
+   F(2, P_FEPLL200, 1, 0, 0),
+   F(5, P_FEPLL500, 1, 0, 0),
F(62600, P_DDRPLLAPSS, 1, 0, 0),
-   { }
+   F(71000, P_DDRPLLAPSS, 1, 0, 0),
+   {}
 };
 
 static struct clk_rcg2 apps_clk_src = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 3/5] clk: qcom: ipq4019: Added the cpu pll divider and changed regmap limit

2016-05-30 Thread Abhishek Sahu
This patch adds the APSS CPU PLL divider in clock framework and
its binding in IPQ4019 device tree binding.

Also, it changed the max_register value to 0x2 in regmap config
to support the APSS CPU PLL divider operations.

Signed-off-by: Abhishek Sahu 
---
 drivers/clk/qcom/gcc-ipq4019.c   | 6 --
 include/dt-bindings/clock/qcom,gcc-ipq4019.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 45f4749..263577c 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -143,7 +143,7 @@ static const char * const gcc_xo_ddr_500_200[] = {
"xo",
"fepll200",
"fepll500",
-   "ddrpllapss",
+   "gcc_apps_cpu_div_clk",
 };
 
 #define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
@@ -682,6 +682,7 @@ static struct clk_rcg2 apps_clk_src = {
.parent_names = gcc_xo_ddr_500_200,
.num_parents = 4,
.ops = &clk_rcg2_ops,
+   .flags = CLK_SET_RATE_PARENT,
},
 };
 
@@ -1355,6 +1356,7 @@ static struct clk_regmap *gcc_ipq4019_clocks[] = {
[GCC_WCSS5G_CLK] = &gcc_wcss5g_clk.clkr,
[GCC_WCSS5G_REF_CLK] = &gcc_wcss5g_ref_clk.clkr,
[GCC_WCSS5G_RTC_CLK] = &gcc_wcss5g_rtc_clk.clkr,
+   [GCC_APPS_CLK_CPU_DIV] = &gcc_apps_cpu_div_clk.cdiv.clkr,
 };
 
 static const struct qcom_reset_map gcc_ipq4019_resets[] = {
@@ -1435,7 +1437,7 @@ static const struct regmap_config 
gcc_ipq4019_regmap_config = {
.reg_bits   = 32,
.reg_stride = 4,
.val_bits   = 32,
-   .max_register   = 0x2dfff,
+   .max_register   = 0x2,
.fast_io= true,
 };
 
diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h 
b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
index 6240e5b..417a722 100644
--- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h
+++ b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
@@ -154,5 +154,6 @@
 #define GCC_QDSS_BCR   69
 #define GCC_MPM_BCR70
 #define GCC_SPDM_BCR   71
+#define GCC_APPS_CLK_CPU_DIV   72
 
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH 2/5] clk: qcom: ipq4019: Added the apss cpu pll divider clock node

2016-05-30 Thread Abhishek Sahu
The existing code does not have support for all the frequency
supported by APPS CPU. APPS CPU frequency is provided with APSS
CPU PLL divider which divides down the VCO frequency. This divider
is nonlinear and specific to IPQ4019 so the standard divider code
cannot be used for this.

This patch adds new node and its clock operations for APPS CPU clock
divider. Since, this divider is nonlinear, so frequency table is also
added for this, which contains the frequency and its corresponding
hardware divider values.

Signed-off-by: Abhishek Sahu 
---
 drivers/clk/qcom/gcc-ipq4019.c | 140 +
 1 file changed, 140 insertions(+)

diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index db24cb8..45f4749 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -20,6 +20,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -28,6 +33,7 @@
 #include "clk-rcg.h"
 #include "clk-branch.h"
 #include "reset.h"
+#include "clk-regmap-divider.h"
 
 enum {
P_XO,
@@ -40,6 +46,18 @@ enum {
P_DDRPLLAPSS,
 };
 
+#define to_clk_regmap_div(_hw) container_of(to_clk_regmap(_hw),\
+   struct clk_regmap_div, clkr)
+
+#define to_clk_cdiv_rcg(_hw) container_of((to_clk_regmap_div(_hw)),\
+   struct clk_apps_cpu_div, cdiv)
+
+struct clk_apps_cpu_div {
+   struct clk_regmap_div cdiv;
+   const u8*parent_map;
+   const struct freq_tbl   *freq_tbl;
+};
+
 static struct parent_map gcc_xo_200_500_map[] = {
{ P_XO, 0 },
{ P_FEPLL200, 1 },
@@ -524,6 +542,128 @@ static struct clk_rcg2  sdcc1_apps_clk_src = {
},
 };
 
+/*
+* Round rate function for APPS CPU PLL Clock divider.
+* It Returns the input rate without changing it. The hardware supported rate
+* will be calculated in set function by getting the same from frequency table.
+*/
+static long clk_cpu_div_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *p_rate)
+{
+   return rate;
+};
+
+/*
+* Clock set rate function for APPS CPU PLL Clock divider.
+* It looks up the frequency table and updates the PLL divider to corresponding
+* divider value.
+*/
+static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   struct clk_apps_cpu_div *rcg = to_clk_cdiv_rcg(hw);
+   const struct freq_tbl *f;
+   u32 mask;
+   int ret;
+
+   f = qcom_find_freq(rcg->freq_tbl, rate);
+   if (!f)
+   return -EINVAL;
+
+   mask = (BIT(rcg->cdiv.width) - 1) << rcg->cdiv.shift;
+   ret = regmap_update_bits(rcg->cdiv.clkr.regmap,
+   rcg->cdiv.reg, mask,
+   (f->pre_div << rcg->cdiv.shift) & mask);
+   udelay(1);
+
+   return 0;
+};
+
+/*
+* Clock frequency calculation function for APPS CPU PLL Clock divider.
+* It first calculates the VCO frequency with the parent rate. This clock 
divider
+* is nonlinear so this function calculates the actual divider and returns the
+* output frequency by dividing VCO Frequency with this actual divider value.
+*/
+static unsigned long clk_cpu_div_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct clk_apps_cpu_div *rcg = to_clk_cdiv_rcg(hw);
+   u32 fdbkdiv, cdiv, rate, pre_div;
+   u32 fdbkdiv_shift = 16, fdbkdiv_mask =  0xff;
+   u64 vco;
+
+   regmap_read(rcg->cdiv.clkr.regmap, rcg->cdiv.reg, &cdiv);
+   fdbkdiv = cdiv & (fdbkdiv_mask << fdbkdiv_shift);
+   fdbkdiv = fdbkdiv >> fdbkdiv_shift;
+
+   cdiv &= (BIT(rcg->cdiv.width) - 1) << rcg->cdiv.shift;
+   cdiv = cdiv >> rcg->cdiv.shift;
+
+   /*
+   * Some dividers have value in 0.5 fraction so multiply both VCO
+   * frequency and pre_div with 2 to make integer calculation.
+   */
+   vco = parent_rate;
+   vco *= fdbkdiv;
+   vco *= 2;
+
+   if (cdiv > 10)
+   pre_div = (cdiv + 1) * 2;
+   else
+   pre_div = cdiv + 12;
+
+   do_div(vco, pre_div);
+   do_div(vco, 100);
+   rate = (u32)vco * 100;
+
+   return rate;
+};
+
+const struct clk_ops clk_regmap_cpu_div_ops = {
+   .round_rate = clk_cpu_div_round_rate,
+   .set_rate = clk_cpu_div_set_rate,
+   .recalc_rate = clk_cpu_div_recalc_rate,
+};
+
+static const struct freq_tbl ftbl_apps_ddr_pll[] = {
+   {38000, P_XO, 0xD, 0},
+   {40900, P_XO, 0xC, 0, 0},
+   {44400, P_XO, 0xB, 0, 0},
+   {48400, P_XO, 0xA, 0, 0},
+   {50700, P_XO, 0x9, 0, 0},
+   {53200, P_XO, 0x8, 0, 0},
+   {56000, P_XO, 0x7, 0, 0},
+   {59200, P_XO, 0x6, 0, 0},
+   {62600, P_XO, 0x5, 0, 0},
+   {66600, P_XO, 0x4, 0, 0},
+   {7

Re: [PATCH trivial] include/linux/memblock.h: Clean up code for several trivial details

2016-05-30 Thread Joe Perches
On Mon, 2016-05-30 at 22:21 +0800, Chen Gang wrote:
> On 5/29/16 23:08, Joe Perches wrote:
> > On Sun, 2016-05-29 at 22:36 +0800, cheng...@emindsoft.com.cn wrote:
> > > Use "!!" to let the boolean function return boolean value directly.
> > []
> > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > []
> > > @@ -191,12 +190,12 @@ static inline bool movable_node_is_enabled(void)
> > >  static inline bool memblock_is_mirror(struct memblock_region *m)
> > >  {
> > > - return m->flags & MEMBLOCK_MIRROR;
> > > + return !!(m->flags & MEMBLOCK_MIRROR);
> > These !! uses are't necessary.
> > The compiler makes the bool return 0 or 1.
> No, they are not necessary. But for me, it will be more clearer, since
> in our kernel (at least in include/linux/), almost all Boolean functions
> use Boolean value or expression for return (and "!!" are often used).

Opinions vary.

There seem to be fewer than 20 !! uses in bool return
functions in include/linux/

Finding the quantity of bool conversions in include/linux
from something other than 0, 1, true, or false to 0 or 1
is not trivial, but it is non-zero and seems rather more
than 20.



[PATCH 4/5] clk: qcom: ipq4019: Added the cpu clock frequency change notifier

2016-05-30 Thread Abhishek Sahu
The current IPQ4019 clock driver code gives the crash or gets hang
while switching the CPU frequency some time. The APSS CPU Clock
divider is not glitch free so the APPS clock need to be switched for
stable clock duringthe change.

This patch adds the frequency change notifier for APSS CPU clock.
It changes the parent of this clock to stable PLL FEPLL500 when it
gets for PRE_RATE_CHANGE event. This event will be generated before
actual clock set operations. The clock set operation will again change
its corresponding parent by getting the same from frequency table.

Signed-off-by: Abhishek Sahu 
---
 drivers/clk/qcom/gcc-ipq4019.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 263577c..69a8250 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -1455,9 +1455,27 @@ static const struct of_device_id 
gcc_ipq4019_match_table[] = {
 };
 MODULE_DEVICE_TABLE(of, gcc_ipq4019_match_table);
 
+int cpu_clk_notifier_fn(struct notifier_block *nb,
+   unsigned long action, void *data)
+{
+   int err = 0;
+
+   if (action == PRE_RATE_CHANGE) {
+   err = clk_rcg2_ops.set_parent(&apps_clk_src.clkr.hw,
+   P_FEPLL500);
+   }
+
+   return notifier_from_errno(err);
+}
+
+struct notifier_block cpu_clk_notifier = {
+   .notifier_call = cpu_clk_notifier_fn,
+};
+
 static int gcc_ipq4019_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
+   int err;
 
clk_register_fixed_rate(dev, "fepll125", "xo", 0, 12500);
clk_register_fixed_rate(dev, "fepll125dly", "xo", 0, 12500);
@@ -1469,7 +1487,13 @@ static int gcc_ipq4019_probe(struct platform_device 
*pdev)
clk_register_fixed_rate(dev, "ddrpllsdcc", "xo", 0, 19300);
clk_register_fixed_rate(dev, "pcnoc_clk_src", "xo", 0, 1);
 
-   return qcom_cc_probe(pdev, &gcc_ipq4019_desc);
+   err = qcom_cc_probe(pdev, &gcc_ipq4019_desc);
+
+   if (!err)
+   clk_notifier_register(apps_clk_src.clkr.hw.clk,
+   &cpu_clk_notifier);
+
+   return err;
 }
 
 static struct platform_driver gcc_ipq4019_driver = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: ARC stable backport request

2016-05-30 Thread Jiri Slaby
On 05/25/2016, 01:43 PM, Vineet Gupta wrote:
> Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler mnemonic".
> Newer binutils don't like ASL instruction and fail to build kernels prior to 
> v4.4
> which added this fix.

Added to 3.12. Thanks.


-- 
js
suse labs


RE: [PATCH 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

2016-05-30 Thread Pramod Kumar
Hi Andrew,

Thanks for reviewing. Please see my comment inline.

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: 30 May 2016 19:05
> To: Pramod Kumar
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala;
Catalin
> Marinas; Will Deacon; Kishon Vijay Abraham I; David S. Miller;
> devicet...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; bcm-kernel-feedback-l...@broadcom.com;
linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 5/7] net:mdio-mux: Add MDIO mux driver for iProc
SoCs
>
> On Mon, May 30, 2016 at 12:40:49PM +0530, Pramod Kumar wrote:
> > iProc based SoCs supports the integrated mdio multiplexer which has
> > the bus selection as well as mdio transaction generation logic inside.
>
> Hi Pramod
>
> Great to see you using the existing MDIO framework. Thanks.
>
> > +static int mdio_mux_iproc_switch_fn(int current_child, int
desired_child,
> > +   void *data)
> > +{
> > +   struct iproc_mdiomux_desc *md = data;
> > +   struct mdiomux_bus_param *bp = &md->bus_param[desired_child];
> > +   u32 param, bus_id;
> > +   bool bus_dir;
> > +
> > +   /* select bus and its properties */
> > +   bus_dir = (desired_child < EXT_BUS_START_ADDR);
> > +   bus_id = bus_dir ? desired_child : (desired_child -
> > +EXT_BUS_START_ADDR);
> > +
> > +   param = (bus_dir ? 1 : 0) << MDIO_PARAM_INTERNAL_SEL;
> > +   param |= (bp->is_c45 ? 1 : 0) << MDIO_PARAM_C45_SEL;
> > +   param |= (bus_id << MDIO_PARAM_BUS_ID);
> > +
> > +   writel(param, md->base + MDIO_PARAM_OFFSET);
> > +   return 0;
> > +}
>
> What i don't yet see is why you went for the concept of an integrated
MDIO and
> MUX. This function above is the mux function, and it looks like it could
be used
> to implement a standard mdio-mux driver.
>

iProc based SoCs Integrated MDIO Multiplexer has both logic in a hardware.
MDIO transaction and Child bus selection logic share the same address
space.
For ex-

In above mux function- Register-MDIO_PARAM_OFFSET is used for bus,
direction and transaction type. Same register
Is used for programming the PHY Ids and write data values in MDIO parent
bus transaction.

Writing MDIO bus driver and mux driver separately gives a notion of being
two separate device/address space, obviously it is not our use case.
Even if we used syscon for accessing the shared register, this does not
appears good for writing separate drivers for a single device.


> Thanks
>  Andrew

Regards,
Pramod


Re: [lkp] [rcu] ac3c30e891: kmsg.shift_exponent#is_too_large_for#-bit_type'long_unsigned_int'

2016-05-30 Thread Paul E. McKenney
On Mon, May 30, 2016 at 10:21:07AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> dev.2016.05.17a
> commit ac3c30e8911d244986e3bb2c56f7d3ca84405d98 ("rcu: Correctly handle 
> sparse possible CPUs")

FYI, this commit is obsolete.  It has been superseded by ac345c38ebc1 with
the same subject line.  I believe that the problem called out below has been
fixed in the new commit.

Thanx, Paul

> on test machine: vm-kbuild-yocto-ia32: 1 threads qemu-system-x86_64 
> -enable-kvm -cpu Westmere with 320M memory
> 
> caused below changes:
> 
> 
> 
> [   18.665139] 
> 
> [   18.665163] UBSAN: Undefined behaviour in kernel/rcu/tree_exp.h:379:3
> [   18.665185] shift exponent 64 is too large for 64-bit type 'long unsigned 
> int'
> [   18.665211] CPU: 0 PID: 61 Comm: rcu_torture_fak Not tainted 
> 4.6.0-rc2-00099-gac3c30e #1
> [   18.665251]  813e0831 0096  
> 0001
> [   18.665288]    88000fb7bbb8 
> 820d7b86
> [   18.665326]  81478309 7a61dc58 7a61dc30 
> 0020
> [   18.665333] Call Trace:
> [   18.665369]  [] ? trace_hardirqs_off+0xcb/0xd6
> [   18.665402]  [] dump_stack+0x286/0x3f0
> [   18.665434]  [] ? printk+0x5d/0x65
> [   18.665469]  [] ubsan_epilogue+0x12/0x3f
> [   18.665510]  [] 
> __ubsan_handle_shift_out_of_bounds+0x19c/0x1d1
> [   18.665543]  [] ? find_next_bit+0x2c/0x2e
> [   18.665575]  [] sync_rcu_exp_select_cpus+0xc87/0xd7f
> [   18.665605]  [] ? sync_rcu_exp_select_cpus+0xc87/0xd7f
> [   18.665633]  [] ? exp_funnel_lock+0x6a0/0x6b1
> [   18.665665]  [] ? rcu_report_exp_rdp+0x3f/0x3f
> [   18.665706]  [] synchronize_rcu_expedited+0x18b/0x1a9
> [   18.665740]  [] ? stub_timer+0x28/0x28
> [   18.665773]  [] ? torture_random+0xf3/0x112
> [   18.665801]  [] rcu_torture_fakewriter+0x50c/0x542
> [   18.665827]  [] ? rcu_torture_fqs+0x1c5/0x1c5
> [   18.665854]  [] kthread+0x2b0/0x2c0
> [   18.665881]  [] ret_from_fork+0x22/0x50
> [   18.665909]  [] ? __kthread_unpark+0x1ed/0x1ed
> [   18.665922] 
> 
> 
> 
> 
> FYI, raw QEMU command line is:
> 
>   qemu-system-x86_64 -enable-kvm -cpu Westmere -kernel 
> /pkg/linux/x86_64-randconfig-s4-05262217/gcc-6/ac3c30e8911d244986e3bb2c56f7d3ca84405d98/vmlinuz-4.6.0-rc2-00099-gac3c30e
>  -append 'root=/dev/ram0 user=lkp 
> job=/lkp/scheduled/vm-kbuild-yocto-ia32-15/bisect_boot-1-yocto-minimal-i386.cgz-x86_64-randconfig-s4-05262217-ac3c30e8911d244986e3bb2c56f7d3ca84405d98-20160528-4983-ppi8s9-1.yaml
>  ARCH=x86_64 kconfig=x86_64-randconfig-s4-05262217 
> branch=linux-devel/devel-hourly-2016052620 
> commit=ac3c30e8911d244986e3bb2c56f7d3ca84405d98 
> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s4-05262217/gcc-6/ac3c30e8911d244986e3bb2c56f7d3ca84405d98/vmlinuz-4.6.0-rc2-00099-gac3c30e
>  max_uptime=600 
> RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-ia32/yocto-minimal-i386.cgz/x86_64-randconfig-s4-05262217/gcc-6/ac3c30e8911d244986e3bb2c56f7d3ca84405d98/0
>  LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug 
> apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
> softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
> prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
> ip=vm-kbuild-yocto-ia32-15::dhcp drbd.minor_count=8'  -initrd 
> /fs/sdh1/initrd-vm-kbuild-yocto-ia32-15 -m 320 -smp 1 -device 
> e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
> i6300esb -rtc base=localtime -drive 
> file=/fs/sdh1/disk0-vm-kbuild-yocto-ia32-15,media=disk,if=virtio -pidfile 
> /dev/shm/kboot/pid-vm-kbuild-yocto-ia32-15 -serial 
> file:/dev/shm/kboot/serial-vm-kbuild-yocto-ia32-15 -daemonize -display none 
> -monitor null 
> 
> 
> 
> 
> 
> Thanks,
> Xiaolong

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.6.0-rc2 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONF

Re: WMI driver no longer load after switching to generic UUID library

2016-05-30 Thread Andy Shevchenko
On Mon, 2016-05-30 at 12:52 +0200, Bjørn Mork wrote:
> How about the untested attached patch?
> 

Facepalm.jpg!

Good catch!

The question is how it passed in our internal tree without being
notified (it even included a lot of ACPI code updated)!?

My explanation since I have no access to archive of internal mailing
list is that I submitted 'cleaned up' version which brought that and
wasn't tested. 

Anyway I just wrote a test module and is about to submit it with your
fix in a series.

Thanks!

> 
> Bjørn
> 

-- 
Andy Shevchenko 
Intel Finland Oy


[PATCH v1 1/2] lib/uuid: add a test module

2016-05-30 Thread Andy Shevchenko
It appears that somehow I missed a test of the latest UUID rework which landed
in the kernel. Present a small test module to avoid such cases in the future.

Signed-off-by: Andy Shevchenko 
---
 lib/Kconfig.debug |   3 ++
 lib/Makefile  |   1 +
 lib/test_uuid.c   | 133 ++
 3 files changed, 137 insertions(+)
 create mode 100644 lib/test_uuid.c

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b8ab3c3..574ae55 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1856,6 +1856,9 @@ config TEST_BITMAP
 
  If unsure, say N.
 
+config TEST_UUID
+   tristate "Test functions located in the uuid module at runtime"
+
 config TEST_RHASHTABLE
tristate "Perform selftest on resizable hash table"
default n
diff --git a/lib/Makefile b/lib/Makefile
index 1128e33..d374a53 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
 obj-$(CONFIG_TEST_PRINTF) += test_printf.o
 obj-$(CONFIG_TEST_BITMAP) += test_bitmap.o
+obj-$(CONFIG_TEST_UUID) += test_uuid.o
 
 ifeq ($(CONFIG_DEBUG_KOBJECT),y)
 CFLAGS_kobject.o += -DDEBUG
diff --git a/lib/test_uuid.c b/lib/test_uuid.c
new file mode 100644
index 000..547d312
--- /dev/null
+++ b/lib/test_uuid.c
@@ -0,0 +1,133 @@
+/*
+ * Test cases for lib/uuid.c module.
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct test_uuid_data {
+   const char *uuid;
+   uuid_le le;
+   uuid_be be;
+};
+
+static const struct test_uuid_data test_uuid_test_data[] = {
+   {
+   .uuid = "c33f4995-3701-450e-9fbf-206a2e98e576",
+   .le = UUID_LE(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 
0x6a, 0x2e, 0x98, 0xe5, 0x76),
+   .be = UUID_BE(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 
0x6a, 0x2e, 0x98, 0xe5, 0x76),
+   },
+   {
+   .uuid = "64b4371c-77c1-48f9-8221-29f054fc023b",
+   .le = UUID_LE(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 
0xf0, 0x54, 0xfc, 0x02, 0x3b),
+   .be = UUID_BE(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 
0xf0, 0x54, 0xfc, 0x02, 0x3b),
+   },
+   {
+   .uuid = "0cb4ddff-a545-4401-9d06-688af53e7f84",
+   .le = UUID_LE(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 
0x8a, 0xf5, 0x3e, 0x7f, 0x84),
+   .be = UUID_BE(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 
0x8a, 0xf5, 0x3e, 0x7f, 0x84),
+   },
+};
+
+static const char * const test_uuid_wrong_data[] = {
+   "c33f4995-3701-450e-9fbf206a2e98e576 ", /* no hyphen(s) */
+   "64b4371c-77c1-48f9-8221-29f054XX023b", /* invalid character(s) */
+   "0cb4ddff-a545-4401-9d06-688af53e", /* not enough data */
+};
+
+static unsigned total_tests __initdata;
+static unsigned failed_tests __initdata;
+
+static void __init test_uuid_failed(const char *prefix, bool wrong, bool be,
+   const char *data, const char *actual)
+{
+   pr_err("%s test #%u %s %s data: '%s'\n",
+  prefix,
+  total_tests,
+  wrong ? "passed on wrong" : "failed on",
+  be ? "BE" : "LE",
+  data);
+   if (actual && *actual)
+   pr_err("%s test #%u actual data: '%s'\n",
+  prefix,
+  total_tests,
+  actual);
+   failed_tests++;
+}
+
+static void __init test_uuid_test(const struct test_uuid_data *data)
+{
+   uuid_le le;
+   uuid_be be;
+   char buf[48];
+
+   /* LE */
+   total_tests++;
+   if (uuid_le_to_bin(data->uuid, &le))
+   test_uuid_failed("conversion", false, false, data->uuid, NULL);
+
+   total_tests++;
+   if (uuid_le_cmp(data->le, le)) {
+   sprintf(buf, "%pUl", &le);
+   test_uuid_failed("cmp", false, false, data->uuid, buf);
+   }
+
+   /* BE */
+   total_tests++;
+   if (uuid_be_to_bin(data->uuid, &be))
+   test_uuid_failed("conversion", false, true, data->uuid, NULL);
+
+   total_tests++;
+   if (uuid_be_cmp(data->be, be)) {
+   sprintf(buf, "%pUb", &be);
+   test_uuid_failed("cmp", false, true, data->uuid, buf);
+   }
+}
+
+static void __init test_uuid_wrong(const char *data)
+{
+   uuid_le le;
+   uuid_be be;
+
+   /* LE */
+   total_tests++;
+   if (!uuid_le_to_bin(data, &le))
+   test_uuid_failed("negative", true, false, data, NULL);
+
+   /* BE */
+   total_tests++;
+   if (!uuid_be_to_bin(data, &be))
+   test_uuid_failed("negative", true, true, data, NULL);
+}
+
+static int __init test_uuid_init(void)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(test_uuid_test_data); i++)
+   test_uuid_test(&test_uuid_test_data[i]);
+
+   for (i 

[PATCH v1 2/2] lib/uuid.c: use correct offset in uuid parser

2016-05-30 Thread Andy Shevchenko
From: Bjørn Mork 

Use '+ 0' and '+ 1' as offsets, like they were intended, instead
of adding to the result.

Fixes: 2b1b0d66704a ("lib/uuid.c: introduce a few more generic helpers")
Signed-off-by: Bjørn Mork 
Signed-off-by: Andy Shevchenko 
---
 lib/uuid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/uuid.c b/lib/uuid.c
index e116ae5..37687af 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -106,8 +106,8 @@ static int __uuid_to_bin(const char *uuid, __u8 b[16], 
const u8 ei[16])
return -EINVAL;
 
for (i = 0; i < 16; i++) {
-   int hi = hex_to_bin(uuid[si[i]] + 0);
-   int lo = hex_to_bin(uuid[si[i]] + 1);
+   int hi = hex_to_bin(uuid[si[i] + 0]);
+   int lo = hex_to_bin(uuid[si[i] + 1]);
 
b[ei[i]] = (hi << 4) | lo;
}
-- 
2.8.1



Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

2016-05-30 Thread Daniel Vetter
On Mon, May 30, 2016 at 02:06:50PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > But I'll take you up on the implied offer to help out and test ;-)
> > 
> > git://people.freedesktop.org/~danvet/drm stuff
> 
> Tried that branch.
> 
> > Would be really awesome if you could test this on virtio. Note that the
> > new nonblocking helpers require that your atomic backend gets the drm
> > event handling right. So if there's a bug in that logic then you'll see
> > lots of dmesg noise about waits timing out (after 10s of waiting). From a
> > quick inspection it should work though.
> 
> No timeouts.  Yay!
> 
> But it seems crtcs can be (temporarely) disabled now, so we might have
> to pick up the crtc from old_state in virtio_gpu_plane_atomic_update to
> figure which virtual output needs to be turned off.  Ran into this last
> week already.  Happened with multihead setups only, but the same patch
> fixes this one too ;)
> 
> https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html

Hm, smells more like virtio isn't too happy with the default ordering of
the commit operation. The default is:

- Disable any crtc/encoders that need to be disabled/change.
- Bash new plane setup into hw.
- Enable all crtcs/encoders that need to be enabled/have changed.

There's two problems:
- some hw gets real grumpy if you bash in plane state without the crtc
  state yet matching.
- if you do runtime pm nothing is enabled and the writes get lost at best,
  or hang your interconnect at worst.

That's why you can overwrite atomic_commit_tail, and use something more
sensible. See for example what it looks like for rockchip. I have a gut
feeling that should also take care of your troubles. Using the old crtc is
definitely not what you want.

Another option is that virtio isn't happy about bashing in plane state for
disabled crtc. Again helpers have you covered, look at the active_only
parameter for drm_atomic_helper_commit_planes().

Aside, if you wonder why these defaults: They match what the crtc helpers
are doing, but they are a bit surprising indeed.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

2016-05-30 Thread Guenter Roeck

On 05/30/2016 06:29 AM, Neil Armstrong wrote:

Add watchdog specific driver for Amlogic Meson GXBB SoC.

Signed-off-by: Neil Armstrong 
---
  drivers/watchdog/Makefile |   1 +
  drivers/watchdog/meson_gxbb_wdt.c | 277 ++
  2 files changed, 278 insertions(+)
  create mode 100644 drivers/watchdog/meson_gxbb_wdt.c

diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 9bde095..7679d93 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
  obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
  obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
  obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
+obj-$(CONFIG_MESON_WATCHDOG) += meson_gxbb_wdt.o


No extra Kconfig entry ? Why ?



Re: [PATCH 00/10] Documentation/Sphinx

2016-05-30 Thread Jani Nikula
On Mon, 30 May 2016, Markus Heiser  wrote:
> Here my 5cents about Jani's patch series:
>
> 1. Migration implementations should not be a part of the kernel tree

If you're referring to the conversion scripts, I don't care either
way. It's probably helpful to have them until everything is converted,
and we can dispose of them afterwards.

> 2. sed/pandoc migration fits not for all the XML documentation and has 
> disadvantages.
>Jonathan asked it before: 
> http://article.gmane.org/gmane.linux.documentation/37533
>
>I repeat myself: Summarize, why should one prefer this tools over pandoc + 
> sed?
>
>* Pandoc coverage is less on reading and writing, this is where 
>  dbxml comes into play
>
>  - reading DocBook: 
> https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Readers/DocBook.hs#L23
>   
>  - writing reST has many bugs and leaks (you fixed some of them with sed)
>
>* Pandoc does not support external entities (linux-tv), covered by dbxml
>
>* dbxml brings the ability to chunk one large XML book into small 
>  reST chunks e.g. kernel-hacking book: 
> https://github.com/return42/sphkerneldoc/tree/master/doc/books/kernel-hacking
>
>* dbxml lets you manipulate the XML source before you convert it to reST
>
>  this might helpfull e.g. if you have to convert single-column 
> informal-tables 
>  to lists or other things ... in short; dbxml and it's hooks are the key 
> to hack
>  everything you need in a full automated DocBook-->reST migration 
> workflow.

I am not proposing to merge the documents that I've converted mostly as
samples in the branch. I needed something to demonstrate the build is
sane.

The authors of the DocBook documents should make the conversions as they
see fit, when they see fit, with the tools they see fit, probably with
some manual work on top.

> 3. we also discussed before, that ASCII art tables are ugly, because the 
> produce
>confusing diffs, for this I wrote the flat-table directive (dbxml migrates 
> tables
>to flat-tables / pandoc can't). 
>
> https://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table

See the above. Any authors that think the Sphinx support I've added is
good enough can go ahead and switch.

I think it's safe for me to say the GPU documents won't wait for further
extension directives or conversion tools. Some others will definitely
want to have the flat table extension before switching.

>> With this, we can put any .rst files (including ones that have
>> kernel-doc directives) anywhere under Documentation, add a link to them
>> in Documentation/index.rst table of contents, and it will just work. It
>> can't get much simpler than that.
>
> 4. We discussed it / I already mentioned that each document shipped in it's 
> own
>sphinx project. Bundling all documents into one sphinx-project will work 
> for
>4 or 5  small documents, but not for the whole documentation. BTW all XML 
>documents are currently separated DocBook projects .. so why should we 
> merge
>them into one big project? Making one index-file for the different and 
> small 
>".txt" files seems OK, but not for the XML docs.

FWIW I locally converted all the DocBook documents (except media) and it
works just fine, and to me it looks like exactly what we should
have. One of the goals was to have nice cross-referencing between the
documents (e.g. from GPU to kernel or device driver API). And it works.

This does not exclude having *additional* indexes or Sphinx config files
for subsystems or subprojects to build a subset of the documentation for
specific needs. It's up to the authors of the documents to decide.

For PDF documents, adding the documents separately in pdf_documents
seems to be the right thing to do.

> 5. In general, the markup of the linux kernel's source code comments remains
>unchanged and the reST markup within the comments is passed through the
>output. A closer lookup to the *kernel-doc* and *reST* markup revals, that
>there are some conflicts between reST (inline) markup and kernel-doc
>markup. Determined by the historical development of the kernel-doc 
> comments, the
>*classic* kernel-doc comments contain characters like ``*`` or strings with
>e.g. leading/trailing underscore (``_``), which are inline markups in
>reST. Here a schort example from a *classic* comment::
>
>  -
> * In contrast to the other drm_get_*_name functions this one here 
> returns a
> * const pointer and hence is threadsafe.
>  -
>
>In reST markup, the wildcard in the string ``drm_get_*_name`` has to be
>masked: ``drm_get_\\*_name``. Some more examples from reST markup:
>
>* Emphasis "*":  like ``*emphasis*`` or ``**emphasis strong**``
>* Leading "_" :  is a *anchor* in reST markup (``_foo``).
>* Trailing "_:  is a reference in reST markup (``foo_``).
>* interpreted text: "`"
>* inline literals: "``"
>*

[PATCH 1/1 v4] hwmon: add support for Sensirion SHT3x sensors

2016-05-30 Thread Pascal Sachs
From: David Frey 

This driver implements support for the Sensirion SHT3x-DIS chip,
a humidity and temperature sensor. Temperature is measured
in degrees celsius, relative humidity is expressed as a percentage.
In the sysfs interface, all values are scaled by 1000,
i.e. the value for 31.5 degrees celsius is 31500.

Signed-off-by: Pascal Sachs 
---
Patch was generated against kernel v4.7-rc1

 Documentation/hwmon/sht3x   |  72 
 drivers/hwmon/Kconfig   |  11 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/sht3x.c   | 724 
 include/linux/platform_data/sht3x.h |  25 ++
 5 files changed, 833 insertions(+)
 create mode 100644 Documentation/hwmon/sht3x
 create mode 100644 drivers/hwmon/sht3x.c
 create mode 100644 include/linux/platform_data/sht3x.h

diff --git a/Documentation/hwmon/sht3x b/Documentation/hwmon/sht3x
new file mode 100644
index 000..f5aa633
--- /dev/null
+++ b/Documentation/hwmon/sht3x
@@ -0,0 +1,72 @@
+Kernel driver sht3x
+===
+
+Supported chips:
+  * Sensirion SHT3x-DIS
+Prefix: 'sht3x'
+Addresses scanned: none
+Datasheet: 
http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Humidity/Sensirion_Humidity_Datasheet_SHT3x_DIS.pdf
+
+Author:
+  David Frey 
+  Pascal Sachs 
+
+Description
+---
+
+This driver implements support for the Sensirion SHT3x-DIS chip, a humidity
+and temperature sensor. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. In the sysfs interface, all values are
+scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+
+The device communicates with the I2C protocol. Sensors can have the I2C
+addresses 0x44 or 0x45, depending on the wiring. See
+Documentation/i2c/instantiating-devices for methods to instantiate the device.
+
+There are two options configurable by means of sht3x_platform_data:
+1. blocking (pull the I2C clock line down while performing the measurement) or
+   non-blocking mode. Blocking mode will guarantee the fastest result but
+   the I2C bus will be busy during that time. By default, non-blocking mode
+   is used. Make sure clock-stretching works properly on your device if you
+   want to use blocking mode.
+2. high or low accuracy. High accuracy is used by default and using it is
+   strongly recommended.
+
+The sht3x sensor supports a single shot mode as well as 5 periodic measure
+modes, which can be controlled with the update_interval sysfs interface.
+The allowed update_interval in milliseconds are as follows:
+  * 0   single shot mode
+  *  2000   0.5 Hz periodic measurement
+  *  1000   1   Hz periodic measurement
+  *   500   2   Hz periodic measurement
+  *   250   4   Hz periodic measurement
+  *   100  10   Hz periodic measurement
+
+In the periodic measure mode, the sensor automatically triggers a measurement
+with the configured update interval on the chip. When a temperature or humidity
+reading exceeds the configured limits, the alert attribute is set to 1 and
+the alert pin on the sensor is set to high.
+When the temperature and humidity readings move back between the hysteresis
+values, the alert bit is set to 0 and the alert pin on the sensor is set to
+low.
+
+sysfs-Interface
+---
+
+temp1_input:temperature input
+humidity1_input:humidity input
+temp1_max:  temperature max value
+temp1_max_hyst: temperature hysteresis value for max limit
+humidity1_max:  humidity max value
+humidity1_max_hyst: humidity hysteresis value for max limit
+temp1_min:  temperature min value
+temp1_min_hyst: temperature hysteresis value for min limit
+humidity1_min:  humidity min value
+humidity1_min_hyst: humidity hysteresis value for min limit
+temp1_alarm:alarm flag is set to 1 if the temperature is outside the
+configured limits. Alarm only works in periodic measure 
mode
+humidity1_alarm:alarm flag is set to 1 if the humidity is outside the
+configured limits. Alarm only works in periodic measure 
mode
+update_interval:update interval, 0 for single shot, interval in msec
+for periodic measurement. If the interval is not supported
+by the sensor, the next faster interval is chosen
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ff94007..e0be99a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1265,6 +1265,17 @@ config SENSORS_SHT21
  This driver can also be built as a module.  If so, the module
  will be called sht21.
 
+config SENSORS_SHT3x
+   tristate "Sensiron humidity and temperature sensors. SHT3x and compat."
+   depends on I2C
+   select CRC8
+   help
+ If you say yes here you get support for the Sensiron SHT30 and SHT31
+ humidity and temperature sensors.
+
+ This driver can also be built as a module.  If so, the 

Re: [PATCH] Add virtio gpu driver.

2016-05-30 Thread Daniel Vetter
On Mon, May 30, 2016 at 03:50:36PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > - add a small core function to registerr HOT_X/HOT_Y for a (cursor) plane,
> >   e.g. drm_plane_register_hotspot(). That should allocate the properties
> >   (if they don't exist yet) and then attach those props to the cursor. We
> >   don't want those props everywhere, but only on drivers that support/need
> >   them, aka virtual hw.
> 
> Hmm, why is this special to virtual hw?
> 
> > if (crtc->cursor) {
> > -   ret = drm_mode_cursor_universal(crtc, req, file_priv);
> > +   if (drm_core_check_feature(DRIVER_ATOMIC))
> > +   ret = drm_mode_cursor_atomic(crtc, req, file_priv);
> > +   else
> > +   ret = drm_mode_cursor_universal(crtc, req, file_priv);
> > goto out;
> 
> >   drm_mode_cursor_atomic would simply be a fusing of
> >   drm_mode_cursor_universal + drm_atomic_helper_update_plane (dump all the
> >   intermediate variables and store directly in the plane state), with the
> >   addition of also storing hot_x/y into the plane state.
> 
> Hmm, that'll either make drm_mode_cursor_atomic a big cut+pasted
> function, or need quite some refactoring to move common code into
> functions callable from both drm_mode_cursor_atomic
> +drm_mode_cursor_universal ...
> 
> Why attach the hotspot to the plane?  Wouldn't it make more sense to
> make it a framebuffer property?

We don't have properties on the framebuffer. I guess you /could/ just add
it internally to struct drm_framebuffer, and not bother exposing to
userspace. I guess that would be a lot simpler, but it also means that
atomic userspace can't use hotspots before we add properties to fbs. And
doing that is a bit tricky since drm_framebuffer objects are meant to be
invariant - this assumption is deeply in-grained into the code all over
the place, everything just compares pointers when semantically it means to
compare the entire fb (including backing storage pointer/offsets and
everything).

So would be a bit more work to wire up for atomic userspace, but indeed a
lot less work to implement. I'm totally happy if you go with that tradeoff
;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH] iio: as3935: improve error reporting in as3935_event_work

2016-05-30 Thread Arnd Bergmann
gcc warns about a potentially uninitialized variable use
in as3935_event_work:

drivers/iio/proximity/as3935.c: In function ‘as3935_event_work’:
drivers/iio/proximity/as3935.c:231:6: error: ‘val’ may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

This case specifically happens when spi_w8r8() fails with a
negative return code. We check all other users of this function
except this one.

As the error is rather unlikely to happen after the device
has already been initialized, this just adds a dev_warn().
Another warning already existst in the same function, but is
missing a trailing '\n' character, so I'm fixing that too.

Signed-off-by: Arnd Bergmann 
---
 drivers/iio/proximity/as3935.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
index f4d29d5dbd5f..b49e3ab5730a 100644
--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -224,10 +224,16 @@ static void as3935_event_work(struct work_struct *work)
 {
struct as3935_state *st;
int val;
+   int ret;
 
st = container_of(work, struct as3935_state, work.work);
 
-   as3935_read(st, AS3935_INT, &val);
+   ret = as3935_read(st, AS3935_INT, &val);
+   if (ret) {
+   dev_warn(&st->spi->dev, "read error\n");
+   return;
+   }
+
val &= AS3935_INT_MASK;
 
switch (val) {
@@ -235,7 +241,7 @@ static void as3935_event_work(struct work_struct *work)
iio_trigger_poll(st->trig);
break;
case AS3935_NOISE_INT:
-   dev_warn(&st->spi->dev, "noise level is too high");
+   dev_warn(&st->spi->dev, "noise level is too high\n");
break;
}
 }
-- 
2.7.0



Re: [PATCH block/for-4.7-fixes] writeback: use higher precision calculation in domain_dirty_limits()

2016-05-30 Thread Jens Axboe

On 05/27/2016 12:34 PM, Tejun Heo wrote:

As vm.dirty_[background_]bytes can't be applied verbatim to multiple
cgroup writeback domains, they get converted to percentages in
domain_dirty_limits() and applied the same way as
vm.dirty_[background]ratio.  However, if the specified bytes is lower
than 1% of available memory, the calculated ratios become zero and the
writeback domain gets throttled constantly.

Fix it by using per-PAGE_SIZE instead of percentage for ratio
calculations.  Also, the updated DIV_ROUND_UP() usages now should
yield 1/4096 (0.0244%) as the minimum ratio as long as the specified
bytes are above zero.

Signed-off-by: Tejun Heo 
Reported-by: Miao Xie 
Link: http://lkml.kernel.org/g/57333e75.3080...@huawei.com
Cc: sta...@vger.kernel.org # v4.2+
Fixes: 9fc3a43e1757 ("writeback: separate out domain_dirty_limits()")


Queued up for this series, with the minor comment tweak that Jan suggested.

--
Jens Axboe



Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

2016-05-30 Thread Linus Walleij
On Thu, May 26, 2016 at 9:00 PM, Uwe Kleine-König
 wrote:
> On Thu, May 26, 2016 at 11:00:55AM +0200, Linus Walleij wrote:
>> On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König
>>  wrote:
>>
>> > [added Linus Walleij to Cc, there is a question for you/him below]
>> (...)
>> >> +void mdio_device_reset(struct mdio_device *mdiodev, int value)
>> >> +{
>> >> + if (mdiodev->reset)
>> >> + gpiod_set_value(mdiodev->reset, value);
>> >
>> > Before v4.6-rc1~108^2~91 it was not necessary to check for the first
>> > parameter being non-NULL before calling gpiod_set_value. Linus, did you
>> > change this on purpose?
>>
>> Not really. And AFAICT it is still not necessary: what changed is that
>> an error message will be printed by VALIDATE_DESC() if you do that.
>> And that is proper I guess? I think it's sloppy code to randomly pass in
>> NULL to a call and just expect it to bail out, it seems more like
>> exercising the error path than something you'd normally rely on.
>>
>> Or am I getting things wrong?
>
> is the following sloppy?:
>
> somegpio = gpiod_get_optional(dev, "some", GPIOD_OUT_LOW);
> if (IS_ERR(somegpio))
> return PTR_ERR(somegpio);
> gpiod_set_value(somegpio, 1);

Grrr OK I see, it's explicit from the _optional() call that it may be NULL
and then it should be ignored. So subsequent functions should ignore
that and bail out. My bad, sorry.

> If not (as I assume) you really changed something as this might trigger
> the warning.

Making a patch.

Yours,
Linus Walleij


Re: [PATCH 1/4] base: soc: introduce soc_device_match() interface

2016-05-30 Thread Arnd Bergmann
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by a driver, or by directly accessing some kind of version register
> that is not part of the device itself but that belongs to a global
> register area of the chip.
> 
> Common reasons for doing this include:
> 
> - A machine is not using devicetree or similar for passing data
>   about on-chip devices, but just announces their presence using
>   boot-time platform devices, and the machine code itself does
>   not care about the revision.
> 
> - There is existing firmware or boot loaders with existing DT
>   binaries with generic compatible strings that do not identify
>   the particular revision of each device, but the driver knows
>   which SoC revisions include which part
> 
> - A prerelease version of a chip has some quirks and we are
>   using the same version of the bootloader and the DT blob
>   on both the prerelease and the final version. An update of
>   the DT binding seems inappropriate because that would involve
>   maintaining multiple copies of the dts and/or bootloader.
> 
> This introduces the soc_device_match() interface that is meant
> to work like of_match_node() but instead of identifying the
> version of a device, it identifies the SoC itself using a
> vendor-agnostic interface.
> 
> Unlike soc_device_match(), we do not do an exact string compare
> but instead use glob_match() to allow wildcards in strings.

I'm sorry the series introduced build failures (I had done some changes
after testing), here is a quick fixup. I'll resend the whole thing
after someone has looked at it as none of the changes below should
have any influence on the review.

Arnd

diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index e9623c6674a5..c38573249777 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -173,7 +173,7 @@ module_exit(soc_bus_unregister);
 static int soc_device_match_one(struct device *dev, void *arg)
 {
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
-   struct soc_device_attribute *match = arg;
+   const struct soc_device_attribute *match = arg;
 
if (match->machine && !glob_match(match->machine, 
soc_dev->attr->machine))
return 0;
@@ -208,7 +208,7 @@ static int soc_device_match_one(struct device *dev, void 
*arg)
  * soc_device_attribute to pass a structure or function pointer for
  * each entry.
  */
-struct soc_device_attribute *soc_device_match(struct soc_device_attribute 
*matches)
+const struct soc_device_attribute *soc_device_match(const struct 
soc_device_attribute *matches)
 {
struct device *dev;
int ret;
@@ -219,7 +219,7 @@ struct soc_device_attribute *soc_device_match(struct 
soc_device_attribute *match
return NULL;
 
dev = NULL;
-   ret = bus_for_each_dev(&soc_bus_type, dev, matches,
+   ret = bus_for_each_dev(&soc_bus_type, dev, (void *)matches,
 soc_device_match_one);
}
 
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index 1d4814fe4cb2..a7b8b05a13e8 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
 
@@ -75,7 +77,6 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
-   u16 ret;
int shift = (spec_reg & 0x2) * 8;
 
if (spec_reg == SDHCI_HOST_VERSION)
@@ -565,7 +566,7 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = 
{
 };
 
 #define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | 
SDHCI_SPEC_200)
-static const struct soc_device_attribute esdhc_t4240_quirk = {
+static const struct soc_device_attribute esdhc_t4240_quirk[] = {
/* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200 */
{ .soc_id = "T4*(0x824000)", .revision = "0x[01]?",
  .data = (void *)(uintptr_t)(T4240_HOST_VER) },
@@ -576,6 +577,7 @@ static void esdhc_init(struct platform_device *pdev, struct 
sdhci_host *host)
 {
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
+   u32 host_ver;
 
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
@@ -583,9 +585,9 @@ static void esdhc_init(struct platform_device *pdev, struct 
sdhci_host *host)
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
 
if (of_device_is_compatible(pdev->dev.of_node, "fsl,t4240-esdhc")) {
-   struct soc_device_attribute *match;
+   const struct soc_device_attri

[PATCH v7 02/10] kthread: Allow to call __kthread_create_on_node() with va_list args

2016-05-30 Thread Petr Mladek
kthread_create_on_node() implements a bunch of logic to create
the kthread. It is already called by kthread_create_on_cpu().

We are going to extend the kthread worker API and will
need to call kthread_create_on_node() with va_list args there.

This patch does only a refactoring and does not modify the existing
behavior.

Signed-off-by: Petr Mladek 
---
 kernel/kthread.c | 72 +---
 1 file changed, 42 insertions(+), 30 deletions(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 1ffc11ec5546..bfe8742c4217 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -244,33 +244,10 @@ static void create_kthread(struct kthread_create_info 
*create)
}
 }
 
-/**
- * kthread_create_on_node - create a kthread.
- * @threadfn: the function to run until signal_pending(current).
- * @data: data ptr for @threadfn.
- * @node: task and thread structures for the thread are allocated on this node
- * @namefmt: printf-style name for the thread.
- *
- * Description: This helper function creates and names a kernel
- * thread.  The thread will be stopped: use wake_up_process() to start
- * it.  See also kthread_run().  The new thread has SCHED_NORMAL policy and
- * is affine to all CPUs.
- *
- * If thread is going to be bound on a particular cpu, give its node
- * in @node, to get NUMA affinity for kthread stack, or else give NUMA_NO_NODE.
- * When woken, the thread will run @threadfn() with @data as its
- * argument. @threadfn() can either call do_exit() directly if it is a
- * standalone thread for which no one will call kthread_stop(), or
- * return when 'kthread_should_stop()' is true (which means
- * kthread_stop() has been called).  The return value should be zero
- * or a negative error number; it will be passed to kthread_stop().
- *
- * Returns a task_struct or ERR_PTR(-ENOMEM) or ERR_PTR(-EINTR).
- */
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
-  void *data, int node,
-  const char namefmt[],
-  ...)
+static struct task_struct *__kthread_create_on_node(int (*threadfn)(void 
*data),
+   void *data, int node,
+   const char namefmt[],
+   va_list args)
 {
DECLARE_COMPLETION_ONSTACK(done);
struct task_struct *task;
@@ -311,11 +288,8 @@ struct task_struct *kthread_create_on_node(int 
(*threadfn)(void *data),
task = create->result;
if (!IS_ERR(task)) {
static const struct sched_param param = { .sched_priority = 0 };
-   va_list args;
 
-   va_start(args, namefmt);
vsnprintf(task->comm, sizeof(task->comm), namefmt, args);
-   va_end(args);
/*
 * root may have changed our (kthreadd's) priority or CPU mask.
 * The kernel thread should not inherit these properties.
@@ -326,6 +300,44 @@ struct task_struct *kthread_create_on_node(int 
(*threadfn)(void *data),
kfree(create);
return task;
 }
+
+/**
+ * kthread_create_on_node - create a kthread.
+ * @threadfn: the function to run until signal_pending(current).
+ * @data: data ptr for @threadfn.
+ * @node: task and thread structures for the thread are allocated on this node
+ * @namefmt: printf-style name for the thread.
+ *
+ * Description: This helper function creates and names a kernel
+ * thread.  The thread will be stopped: use wake_up_process() to start
+ * it.  See also kthread_run().  The new thread has SCHED_NORMAL policy and
+ * is affine to all CPUs.
+ *
+ * If thread is going to be bound on a particular cpu, give its node
+ * in @node, to get NUMA affinity for kthread stack, or else give NUMA_NO_NODE.
+ * When woken, the thread will run @threadfn() with @data as its
+ * argument. @threadfn() can either call do_exit() directly if it is a
+ * standalone thread for which no one will call kthread_stop(), or
+ * return when 'kthread_should_stop()' is true (which means
+ * kthread_stop() has been called).  The return value should be zero
+ * or a negative error number; it will be passed to kthread_stop().
+ *
+ * Returns a task_struct or ERR_PTR(-ENOMEM) or ERR_PTR(-EINTR).
+ */
+struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+  void *data, int node,
+  const char namefmt[],
+  ...)
+{
+   struct task_struct *task;
+   va_list args;
+
+   va_start(args, namefmt);
+   task = __kthread_create_on_node(threadfn, data, node, namefmt, args);
+   va_end(args);
+
+   return task;
+}
 EXPORT_SYMBOL(kthread_create_on_node);
 
 static void __kthread_bind_mask(struct task_struct *p, const struct cpumask 
*mask

[PATCH v7 00/10] kthread: Kthread worker API improvements

2016-05-30 Thread Petr Mladek
I send the kthread worker API improvements separately as discussed
in v6, see
https://lkml.kernel.org/g/<20160511105224.ge2...@pathway.suse.cz>
They seem to be ready for inclusion in 4.8.

I will send the conversion of the particular kthreads once
the API changes are in some maintainers three (-mm?) and
visible in linux-next. If nobody suggests some other approach.

Also I plan to continue with conversion of more kthreads.

Just to remember. The intention of this patchset is to make
it easier to manipulate and maintain kthreads. Especially, I want
to replace all the custom main cycles with a generic one.
Also I want to make the kthreads sleep in a consistent
state in a common place when there is no work.


Changes against v6:

  + no changes.


Changes against v5:

  + removed spin_trylock() from delayed_kthread_work_timer_fn();
instead temporary released worked->lock() when calling
del_timer_sync(); made sure that any queueing was blocked
by work->canceling in the meatime

  + used 0th byte for KTW_FREEZABLE to reduce confusion

  + fixed warnings in comments reported by make htmldocs

  + sigh, there was no easy way to create an empty va_list
that would work on all architectures; decided to make
@namefmt generic in create_kthread_worker_on_cpu()

  + converted khungtaskd a better way; it was inspired by
the recent changes that appeared in 4.6-rc1


Changes against v4:

  + added worker->delayed_work_list; it simplified the check
for pending work; we do not longer need the new timer_active()
function; also we do not need the link work->timer. On the
other hand we need to distinguish between the normal and
the delayed work by a boolean parameter passed to
the common functions, e.g. __cancel_kthread_work_sync()

  + replaced most try_lock repeat cycles with a WARN_ON();
the API does not allow to use the work with more workers;
so such a situation would be a bug; it removed the
complex try_lock_kthread_work() function that supported
more modes;

  + renamed kthread_work_pending() to queuing_blocked();
added this function later when really needed

  + renamed try_to_cancel_kthread_work() to __cancel_kthread_work();
in fact, this a common implementation for the async cancel()
function

  + removed a dull check for invalid cpu number in
create_kthread_worker_on_cpu(); removed some other unnecessary
code structures as suggested by Tejun

  + consistently used bool return value in all new __cancel functions

  + fixed ordering of cpu and flags parameters in
create_kthread_worker_on_cpu() vs. create_kthread_worker()

  + used memset in the init_kthread_worker()

  + updated many comments as suggested by Tejun and as
required the above changes

  + removed obsolete patch adding timer_active()

  + removed obsolete patch for using try_lock in flush_kthread_worker()

  + double checked all existing users of kthread worker API
that they reinitialized the work when the worker was started
and would not print false warnings; all looked fine

  + added taken acks for the Intel Powerclamp conversion


Changes against v3:

  + allow to free struct kthread_work from its callback; do not touch
the struct from the worker post-mortem; as a side effect, the structure
must be reinitialized when the worker gets restarted; updated
khugepaged, and kmemleak accordingly

  + call del_timer_sync() with worker->lock; instead, detect canceling
in the timer callback and give up an attempt to get the lock there;
do busy loop with spin_is_locked() to reduce cache bouncing

  + renamed ipmi+func() -> ipmi_kthread_worker_func() as suggested
by Corey

  + added some collected Reviewed-by

  
Changes against v2:

  + used worker->lock to synchronize the operations with the work
instead of the PENDING bit as suggested by Tejun Heo; it simplified
the implementation in several ways

  + added timer_active(); used it together with del_timer_sync()
to cancel the work a less tricky way

  + removed the controversial conversion of the RCU kthreads

  + added several other examples: hung_task, kmemleak, ipmi,
IB/fmr_pool, memstick/r592, intel_powerclamp

  + the helper fixes for the ring buffer benchmark has been improved
as suggested by Steven; they already are in the Linus tree now

  + fixed a possible race between the check for existing khugepaged
worker and queuing the work
 

Changes against v1:

  + remove wrappers to manipulate the scheduling policy and priority

  + remove questionable wakeup_and_destroy_kthread_worker() variant

  + do not check for chained work when draining the queue

  + allocate struct kthread worker in create_kthread_work() and
use more simple checks for running worker

  + add support for delayed kthread works and use them instead
of waiting inside the works

  + rework the "unrelated" fixes for the ring buffer benchmark
as discussed in the 1st RFC; also sent

[PATCH v7 01/10] kthread/smpboot: Do not park in kthread_create_on_cpu()

2016-05-30 Thread Petr Mladek
kthread_create_on_cpu() was added by the commit 2a1d446019f9a5983e
("kthread: Implement park/unpark facility"). It is currently used
only when enabling new CPU. For this purpose, the newly created
kthread has to be parked.

The CPU binding is a bit tricky. The kthread is parked when the CPU
has not been allowed yet. And the CPU is bound when the kthread
is unparked.

The function would be useful for more per-CPU kthreads, e.g.
bnx2fc_thread, fcoethread. For this purpose, the newly created
kthread should stay in the uninterruptible state.

This patch moves the parking into smpboot. It binds the thread
already when created. Then the function might be used universally.
Also the behavior is consistent with kthread_create() and
kthread_create_on_node().

Signed-off-by: Petr Mladek 
Reviewed-by: Thomas Gleixner 
---
 kernel/kthread.c | 8 ++--
 kernel/smpboot.c | 5 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 9ff173dca1ae..1ffc11ec5546 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -390,10 +390,10 @@ struct task_struct *kthread_create_on_cpu(int 
(*threadfn)(void *data),
   cpu);
if (IS_ERR(p))
return p;
+   kthread_bind(p, cpu);
+   /* CPU hotplug need to bind once again when unparking the thread. */
set_bit(KTHREAD_IS_PER_CPU, &to_kthread(p)->flags);
to_kthread(p)->cpu = cpu;
-   /* Park the thread to get it out of TASK_UNINTERRUPTIBLE state */
-   kthread_park(p);
return p;
 }
 
@@ -407,6 +407,10 @@ static void __kthread_unpark(struct task_struct *k, struct 
kthread *kthread)
 * which might be about to be cleared.
 */
if (test_and_clear_bit(KTHREAD_IS_PARKED, &kthread->flags)) {
+   /*
+* Newly created kthread was parked when the CPU was offline.
+* The binding was lost and we need to set it again.
+*/
if (test_bit(KTHREAD_IS_PER_CPU, &kthread->flags))
__kthread_bind(k, kthread->cpu, TASK_PARKED);
wake_up_state(k, TASK_PARKED);
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 13bc43d1fb22..4a5c6e73ecd4 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -186,6 +186,11 @@ __smpboot_create_thread(struct smp_hotplug_thread *ht, 
unsigned int cpu)
kfree(td);
return PTR_ERR(tsk);
}
+   /*
+* Park the thread so that it could start right on the CPU
+* when it is available.
+*/
+   kthread_park(tsk);
get_task_struct(tsk);
*per_cpu_ptr(ht->store, cpu) = tsk;
if (ht->create) {
-- 
1.8.5.6



Re: [PATCH 1/3] gpio: max77620: Configure interrupt trigger level

2016-05-30 Thread Linus Walleij
On Tue, May 24, 2016 at 3:13 PM, Laxman Dewangan  wrote:

> The GPIO sub modules of MAX77620 offers to configure the GPIO
> interrupt trigger level as RISING and FALLING edge.
>
> Pass this information to regmap-irg when registering for GPIO
> interrupts.
>
> Signed-off-by: Laxman Dewangan 

Patch applied.

Yours,
Linus Walleij


[PATCH v7 03/10] kthread: Add create_kthread_worker*()

2016-05-30 Thread Petr Mladek
Kthread workers are currently created using the classic kthread API,
namely kthread_run(). kthread_worker_fn() is passed as the @threadfn
parameter.

This patch defines create_kthread_worker() and
create_kthread_worker_on_cpu() functions that hide implementation details.

They enforce using kthread_worker_fn() for the main thread. But I doubt
that there are any plans to create any alternative. In fact, I think
that we do not want any alternative main thread because it would be
hard to support consistency with the rest of the kthread worker API.

The naming and function of create_kthread_worker() is inspired by
the workqueues API like the rest of the kthread worker API.

The create_kthread_worker_on_cpu() variant is motivated by the original
kthread_create_on_cpu(). Note that we need to bind per-CPU kthread
workers already when they are created. It makes the life easier.
kthread_bind() could not be used later for an already running worker.

This patch does _not_ convert existing kthread workers. The kthread worker
API need more improvements first, e.g. a function to destroy the worker.

IMPORTANT:

create_kthread_worker_on_cpu() allows to use any format of the
worker name, in compare with kthread_create_on_cpu(). The good thing
is that it is more generic. The bad thing is that most users will
need to pass the cpu number in two parameters, e.g.
create_kthread_worker_on_cpu(cpu, "helper/%d", cpu).

To be honest, the main motivation was to avoid the need for an
empty va_list. The only legal way was to create a helper function that
would be called with an empty list. Other attempts caused compilation
warnings or even errors on different architectures.

There were also other alternatives, for example, using #define or
splitting __create_kthread_worker(). The used solution looked
like the least ugly.

Signed-off-by: Petr Mladek 
---
 include/linux/kthread.h |   7 +++
 kernel/kthread.c| 113 +++-
 2 files changed, 110 insertions(+), 10 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index e691b6a23f72..468011efa68d 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -124,6 +124,13 @@ extern void __init_kthread_worker(struct kthread_worker 
*worker,
 
 int kthread_worker_fn(void *worker_ptr);
 
+__printf(1, 2)
+struct kthread_worker *
+create_kthread_worker(const char namefmt[], ...);
+
+struct kthread_worker *
+create_kthread_worker_on_cpu(int cpu, const char namefmt[], ...);
+
 bool queue_kthread_work(struct kthread_worker *worker,
struct kthread_work *work);
 void flush_kthread_work(struct kthread_work *work);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index bfe8742c4217..76364374ff98 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -567,23 +567,24 @@ EXPORT_SYMBOL_GPL(__init_kthread_worker);
  * kthread_worker_fn - kthread function to process kthread_worker
  * @worker_ptr: pointer to initialized kthread_worker
  *
- * This function can be used as @threadfn to kthread_create() or
- * kthread_run() with @worker_ptr argument pointing to an initialized
- * kthread_worker.  The started kthread will process work_list until
- * the it is stopped with kthread_stop().  A kthread can also call
- * this function directly after extra initialization.
+ * This function implements the main cycle of kthread worker. It processes
+ * work_list until it is stopped with kthread_stop(). It sleeps when the queue
+ * is empty.
  *
- * Different kthreads can be used for the same kthread_worker as long
- * as there's only one kthread attached to it at any given time.  A
- * kthread_worker without an attached kthread simply collects queued
- * kthread_works.
+ * The works are not allowed to keep any locks, disable preemption or 
interrupts
+ * when they finish. There is defined a safe point for freezing when one work
+ * finishes and before a new one is started.
  */
 int kthread_worker_fn(void *worker_ptr)
 {
struct kthread_worker *worker = worker_ptr;
struct kthread_work *work;
 
-   WARN_ON(worker->task);
+   /*
+* FIXME: Update the check and remove the assignment when all kthread
+* worker users are created using create_kthread_worker*() functions.
+*/
+   WARN_ON(worker->task && worker->task != current);
worker->task = current;
 repeat:
set_current_state(TASK_INTERRUPTIBLE);  /* mb paired w/ kthread_stop */
@@ -617,6 +618,98 @@ repeat:
 }
 EXPORT_SYMBOL_GPL(kthread_worker_fn);
 
+static struct kthread_worker *
+__create_kthread_worker(int cpu, const char namefmt[], va_list args)
+{
+   struct kthread_worker *worker;
+   struct task_struct *task;
+
+   worker = kzalloc(sizeof(*worker), GFP_KERNEL);
+   if (!worker)
+   return ERR_PTR(-ENOMEM);
+
+   init_kthread_worker(worker);
+
+   if (cpu >= 0) {
+   char name[TASK_COMM_LEN];
+
+   /*
+* creare_kthread_wo

[PATCH v7 06/10] kthread: Detect when a kthread work is used by more workers

2016-05-30 Thread Petr Mladek
Nothing currently prevents a work from queuing for a kthread worker
when it is already running on another one. This means that the work
might run in parallel on more workers. Also some operations, e.g.
flush or drain are not reliable.

This problem will be even more visible after we add cancel_kthread_work()
function. It will only have "work" as the parameter and will use
worker->lock to synchronize with others.

Well, normally this is not a problem because the API users are sane.
But bugs might happen and users also might be crazy.

This patch adds a warning when we try to insert the work for another
worker. It does not fully prevent the misuse because it would make the
code much more complicated without a big benefit.

It adds the same warning also into flush_kthread_work() instead of
the repeated attempts to get the right lock.

A side effect is that one needs to explicitly reinitialize the work
if it must be queued into another worker. This is needed, for example,
when the worker is stopped and started again. It is a bit inconvenient.
But it looks like a good compromise between the stability and complexity.

I have double checked all existing users of the kthread worker API
and they all seems to initialize the work after the worker gets
started.

Just for completeness, the patch adds a check that the work is not
already in a queue.

The patch also puts all the checks into a separate function. It will
be reused when implementing delayed works.

Signed-off-by: Petr Mladek 
---
 kernel/kthread.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 441651765f08..385a7d6b4872 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -574,6 +574,9 @@ EXPORT_SYMBOL_GPL(__init_kthread_worker);
  * The works are not allowed to keep any locks, disable preemption or 
interrupts
  * when they finish. There is defined a safe point for freezing when one work
  * finishes and before a new one is started.
+ *
+ * Also the works must not be handled by more workers at the same time, see 
also
+ * queue_kthread_work().
  */
 int kthread_worker_fn(void *worker_ptr)
 {
@@ -710,12 +713,21 @@ create_kthread_worker_on_cpu(int cpu, const char 
namefmt[], ...)
 }
 EXPORT_SYMBOL(create_kthread_worker_on_cpu);
 
+static void insert_kthread_work_sanity_check(struct kthread_worker *worker,
+  struct kthread_work *work)
+{
+   lockdep_assert_held(&worker->lock);
+   WARN_ON_ONCE(!list_empty(&work->node));
+   /* Do not use a work with more workers, see queue_kthread_work() */
+   WARN_ON_ONCE(work->worker && work->worker != worker);
+}
+
 /* insert @work before @pos in @worker */
 static void insert_kthread_work(struct kthread_worker *worker,
-  struct kthread_work *work,
-  struct list_head *pos)
+   struct kthread_work *work,
+   struct list_head *pos)
 {
-   lockdep_assert_held(&worker->lock);
+   insert_kthread_work_sanity_check(worker, work);
 
list_add_tail(&work->node, pos);
work->worker = worker;
@@ -731,6 +743,9 @@ static void insert_kthread_work(struct kthread_worker 
*worker,
  * Queue @work to work processor @task for async execution.  @task
  * must have been created with kthread_worker_create().  Returns %true
  * if @work was successfully queued, %false if it was already pending.
+ *
+ * Reinitialize the work if it needs to be used by another worker.
+ * For example, when the worker was stopped and started again.
  */
 bool queue_kthread_work(struct kthread_worker *worker,
struct kthread_work *work)
@@ -775,16 +790,13 @@ void flush_kthread_work(struct kthread_work *work)
struct kthread_worker *worker;
bool noop = false;
 
-retry:
worker = work->worker;
if (!worker)
return;
 
spin_lock_irq(&worker->lock);
-   if (work->worker != worker) {
-   spin_unlock_irq(&worker->lock);
-   goto retry;
-   }
+   /* Work must not be used with more workers, see queue_kthread_work(). */
+   WARN_ON_ONCE(work->worker != worker);
 
if (!list_empty(&work->node))
insert_kthread_work(worker, &fwork.work, work->node.next);
-- 
1.8.5.6



[PATCH v7 10/10] kthread: Better support freezable kthread workers

2016-05-30 Thread Petr Mladek
This patch allows to make kthread worker freezable via a new @flags
parameter. It will allow to avoid an init work in some kthreads.

It currently does not affect the function of kthread_worker_fn()
but it might help to do some optimization or fixes eventually.

I currently do not know about any other use for the @flags
parameter but I believe that we will want more flags
in the future.

Finally, I hope that it will not cause confusion with @flags member
in struct kthread. Well, I guess that we will want to rework the
basic kthreads implementation once all kthreads are converted into
kthread workers or workqueues. It is possible that we will merge
the two structures.

Signed-off-by: Petr Mladek 
---
 include/linux/kthread.h | 12 +---
 kernel/kthread.c| 21 +++--
 2 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 1d5ca191562f..edad163b26d0 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -65,7 +65,12 @@ struct kthread_work;
 typedef void (*kthread_work_func_t)(struct kthread_work *work);
 void delayed_kthread_work_timer_fn(unsigned long __data);
 
+enum {
+   KTW_FREEZABLE   = 1 << 0,   /* freeze during suspend */
+};
+
 struct kthread_worker {
+   unsigned intflags;
spinlock_t  lock;
struct list_headwork_list;
struct list_headdelayed_work_list;
@@ -154,12 +159,13 @@ extern void __init_kthread_worker(struct kthread_worker 
*worker,
 
 int kthread_worker_fn(void *worker_ptr);
 
-__printf(1, 2)
+__printf(2, 3)
 struct kthread_worker *
-create_kthread_worker(const char namefmt[], ...);
+create_kthread_worker(unsigned int flags, const char namefmt[], ...);
 
 struct kthread_worker *
-create_kthread_worker_on_cpu(int cpu, const char namefmt[], ...);
+create_kthread_worker_on_cpu(int cpu, unsigned int flags,
+const char namefmt[], ...);
 
 bool queue_kthread_work(struct kthread_worker *worker,
struct kthread_work *work);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 2cc32cad66ef..4ee4c05f8bf7 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -556,11 +556,11 @@ void __init_kthread_worker(struct kthread_worker *worker,
const char *name,
struct lock_class_key *key)
 {
+   memset(worker, 0, sizeof(struct kthread_worker));
spin_lock_init(&worker->lock);
lockdep_set_class_and_name(&worker->lock, key, name);
INIT_LIST_HEAD(&worker->work_list);
INIT_LIST_HEAD(&worker->delayed_work_list);
-   worker->task = NULL;
 }
 EXPORT_SYMBOL_GPL(__init_kthread_worker);
 
@@ -590,6 +590,10 @@ int kthread_worker_fn(void *worker_ptr)
 */
WARN_ON(worker->task && worker->task != current);
worker->task = current;
+
+   if (worker->flags & KTW_FREEZABLE)
+   set_freezable();
+
 repeat:
set_current_state(TASK_INTERRUPTIBLE);  /* mb paired w/ kthread_stop */
 
@@ -623,7 +627,8 @@ repeat:
 EXPORT_SYMBOL_GPL(kthread_worker_fn);
 
 static struct kthread_worker *
-__create_kthread_worker(int cpu, const char namefmt[], va_list args)
+__create_kthread_worker(int cpu, unsigned int flags,
+   const char namefmt[], va_list args)
 {
struct kthread_worker *worker;
struct task_struct *task;
@@ -653,6 +658,7 @@ __create_kthread_worker(int cpu, const char namefmt[], 
va_list args)
if (IS_ERR(task))
goto fail_task;
 
+   worker->flags = flags;
worker->task = task;
wake_up_process(task);
return worker;
@@ -664,6 +670,7 @@ fail_task:
 
 /**
  * create_kthread_worker - create a kthread worker
+ * @flags: flags modifying the default behavior of the worker
  * @namefmt: printf-style name for the kthread worker (task).
  *
  * Returns a pointer to the allocated worker on success, ERR_PTR(-ENOMEM)
@@ -671,13 +678,13 @@ fail_task:
  * when the worker was SIGKILLed.
  */
 struct kthread_worker *
-create_kthread_worker(const char namefmt[], ...)
+create_kthread_worker(unsigned int flags, const char namefmt[], ...)
 {
struct kthread_worker *worker;
va_list args;
 
va_start(args, namefmt);
-   worker = __create_kthread_worker(-1, namefmt, args);
+   worker = __create_kthread_worker(-1, flags, namefmt, args);
va_end(args);
 
return worker;
@@ -688,6 +695,7 @@ EXPORT_SYMBOL(create_kthread_worker);
  * create_kthread_worker_on_cpu - create a kthread worker and bind it
  * it to a given CPU and the associated NUMA node.
  * @cpu: CPU number
+ * @flags: flags modifying the default behavior of the worker
  * @namefmt: printf-style name for the kthread worker (task).
  *
  * Use a valid CPU number if you want to bind the kthread worker
@@ -701,13 +709,14 @@ EXPORT_SYMBOL(create_kthread_worker);
  * when the worker was SI

[PATCH v7 07/10] kthread: Initial support for delayed kthread work

2016-05-30 Thread Petr Mladek
We are going to use kthread_worker more widely and delayed works
will be pretty useful.

The implementation is inspired by workqueues. It uses a timer to
queue the work after the requested delay. If the delay is zero,
the work is queued immediately.

In compare with workqueues, each work is associated with a single
worker (kthread). Therefore the implementation could be much easier.
In particular, we use the worker->lock to synchronize all the
operations with the work. We do not need any atomic operation
with a flags variable.

In fact, we do not need any state variable at all. Instead, we
add a list of delayed works into the worker. Then the pending
work is listed either in the list of queued or delayed works.
And the existing check of pending works is the same even for
the delayed ones.

A work must not be assigned to another worker unless reinitialized.
Therefore the timer handler might expect that dwork->work->worker
is valid and it could simply take the lock. We just add some
sanity checks to help with debugging a potential misuse.

Signed-off-by: Petr Mladek 
---
 include/linux/kthread.h |  33 
 kernel/kthread.c| 102 
 2 files changed, 135 insertions(+)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index a36604fa8aa2..b27be55cffa3 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -63,10 +63,12 @@ extern int tsk_fork_get_node(struct task_struct *tsk);
  */
 struct kthread_work;
 typedef void (*kthread_work_func_t)(struct kthread_work *work);
+void delayed_kthread_work_timer_fn(unsigned long __data);
 
 struct kthread_worker {
spinlock_t  lock;
struct list_headwork_list;
+   struct list_headdelayed_work_list;
struct task_struct  *task;
struct kthread_work *current_work;
 };
@@ -77,9 +79,15 @@ struct kthread_work {
struct kthread_worker   *worker;
 };
 
+struct delayed_kthread_work {
+   struct kthread_work work;
+   struct timer_list timer;
+};
+
 #define KTHREAD_WORKER_INIT(worker){   \
.lock = __SPIN_LOCK_UNLOCKED((worker).lock),\
.work_list = LIST_HEAD_INIT((worker).work_list),\
+   .delayed_work_list = LIST_HEAD_INIT((worker).delayed_work_list),\
}
 
 #define KTHREAD_WORK_INIT(work, fn){   \
@@ -87,12 +95,23 @@ struct kthread_work {
.func = (fn),   \
}
 
+#define DELAYED_KTHREAD_WORK_INIT(dwork, fn) { \
+   .work = KTHREAD_WORK_INIT((dwork).work, (fn)),  \
+   .timer = __TIMER_INITIALIZER(delayed_kthread_work_timer_fn, \
+0, (unsigned long)&(dwork),\
+TIMER_IRQSAFE),\
+   }
+
 #define DEFINE_KTHREAD_WORKER(worker)  \
struct kthread_worker worker = KTHREAD_WORKER_INIT(worker)
 
 #define DEFINE_KTHREAD_WORK(work, fn)  \
struct kthread_work work = KTHREAD_WORK_INIT(work, fn)
 
+#define DEFINE_DELAYED_KTHREAD_WORK(dwork, fn) \
+   struct delayed_kthread_work dwork = \
+   DELAYED_KTHREAD_WORK_INIT(dwork, fn)
+
 /*
  * kthread_worker.lock needs its own lockdep class key when defined on
  * stack with lockdep enabled.  Use the following macros in such cases.
@@ -122,6 +141,15 @@ extern void __init_kthread_worker(struct kthread_worker 
*worker,
(work)->func = (fn);\
} while (0)
 
+#define init_delayed_kthread_work(dwork, fn)   \
+   do {\
+   init_kthread_work(&(dwork)->work, (fn));\
+   __setup_timer(&(dwork)->timer,  \
+ delayed_kthread_work_timer_fn,\
+ (unsigned long)(dwork),   \
+ TIMER_IRQSAFE);   \
+   } while (0)
+
 int kthread_worker_fn(void *worker_ptr);
 
 __printf(1, 2)
@@ -133,6 +161,11 @@ create_kthread_worker_on_cpu(int cpu, const char 
namefmt[], ...);
 
 bool queue_kthread_work(struct kthread_worker *worker,
struct kthread_work *work);
+
+bool queue_delayed_kthread_work(struct kthread_worker *worker,
+   struct delayed_kthread_work *dwork,
+   unsigned long delay);
+
 void flush_kthread_work(struct kthread_work *work);
 void flush_kthread_worker(struct kthread_worker *worker);
 
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 385a7d6b4872..7655357065e1 100644
--- a/kernel/kthre

<    1   2   3   4   5   6   7   8   9   10   >