[RFC PATCH 4/4] perf-probe: Support probing on offline cross-arch binary

[Masami Hiramatsu]

Support probing on offline cross-architecture binary by
adding getting the target machine arch from ELF and
choose correct register string for the machine.

Here is an example:
  -
  $ mkdir tracing
  $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
do_sys_open '$vars'
  Added new event:
  probe:do_sys_open(on do_sys_open with $vars)

  You can now use it in all perf tools, such as:

perf record -e probe:do_sys_open -aR sleep 1

  $ cat tracing/kprobe_events
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
   flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  -
Here, we can get probe/do_sys_open event by "copy & paste" from
./tracing/kprobe_events to target-machine's debugfs/tracing/kprobe_events

To make sure it is correct:
  -
  $ nm vmlinux-arm | grep "T _text"
  80008000 T _text
  $ nm vmlinux-arm | grep "T do_sys_open"
  801410f4 T do_sys_open
  $ expr `printf "%d + %d" 0x80008000 1282292`
  2148798708
  $ printf "%x\n" 2148798708
  801410f4
  -
So "_text+12882292" indicates do_sys_open on the target binary correctly.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
 tools/perf/arch/arm64/include/dwarf-regs-table.h   |   13 +
 tools/perf/arch/powerpc/include/dwarf-regs-table.h |   27 ++
 tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
 tools/perf/arch/sh/include/dwarf-regs-table.h  |   25 +
 tools/perf/arch/sparc/include/dwarf-regs-table.h   |   18 +++
 tools/perf/arch/x86/include/dwarf-regs-table.h |   14 +
 tools/perf/arch/xtensa/include/dwarf-regs-table.h  |8 +++
 tools/perf/util/Build  |1 
 tools/perf/util/dwarf-regs.c   |   55 
 tools/perf/util/include/dwarf-regs.h   |6 ++
 tools/perf/util/probe-finder.c |   27 ++
 tools/perf/util/probe-finder.h |1 
 13 files changed, 201 insertions(+), 11 deletions(-)
 create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
 create mode 100644 tools/perf/util/dwarf-regs.c

diff --git a/tools/perf/arch/arm/include/dwarf-regs-table.h 
b/tools/perf/arch/arm/include/dwarf-regs-table.h
new file mode 100644
index 000..f298d03
--- /dev/null
+++ b/tools/perf/arch/arm/include/dwarf-regs-table.h
@@ -0,0 +1,9 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+static const char * const arm_regstr_tbl[] = {
+   "%r0", "%r1", "%r2", "%r3", "%r4",
+   "%r5", "%r6", "%r7", "%r8", "%r9", "%r10",
+   "%fp", "%ip", "%sp", "%lr", "%pc",
+};
+#endif
diff --git a/tools/perf/arch/arm64/include/dwarf-regs-table.h 
b/tools/perf/arch/arm64/include/dwarf-regs-table.h
new file mode 100644
index 000..2675936
--- /dev/null
+++ b/tools/perf/arch/arm64/include/dwarf-regs-table.h
@@ -0,0 +1,13 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+static const char * const aarch64_regstr_tbl[] = {
+   "%r0", "%r1", "%r2", "%r3", "%r4",
+   "%r5", "%r6", "%r7", "%r8", "%r9",
+   "%r10", "%r11", "%r12", "%r13", "%r14",
+   "%r15", "%r16", "%r17", "%r18", "%r19",
+   "%r20", "%r21", "%r22", "%r23", "%r24",
+   "%r25", "%r26", "%r27", "%r28", "%r29",
+   "%lr", "%sp",
+};
+#endif
diff --git a/tools/perf/arch/powerpc/include/dwarf-regs-table.h 
b/tools/perf/arch/powerpc/include/dwarf-regs-table.h
new file mode 100644
index 000..db4730f
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/dwarf-regs-table.h
@@ -0,0 +1,27 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+/*
+ * Reference:
+ * http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html
+ * http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
+ */
+#define REG_DWARFNUM_NAME(reg, idx)[idx] = "%" #reg
+
+static const char * const powerpc_regstr_tbl[] = {
+   "%gpr0", "%gpr1", "%gpr2", "%gpr3", "%gpr4",
+   "%gpr5", "%gpr6", "%gpr7", "%gpr8", "%gpr9",
+   "%gpr10", "%gpr11", "%gpr12", "%gpr13", "%gpr14",
+   "%gpr15", "%gpr16", "%gpr17", "%gpr18", "%gpr19",
+   "%gpr20", "%gpr21", "%gpr22", "%gpr23", "%gpr24",
+   "%gpr25", "%gpr26", "%gpr27", "%gpr28", "%gpr29",
+   "%gpr30", "%gpr31",
+   REG_DWARFNUM_NAME(msr,   66),
+   REG_DWARFNUM_NAME(ctr,   109),
+   REG_DWARFNUM_NAME(link,  108),
+   

Re: [PATCH v2 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property

[Andrzej Hajda]

On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'phy' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 6a636f2..bb2d6d4 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct 
> device *dev)
>   return np;
>  }
>  
> -static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> +static struct device_node *hdmi_phy_dt_binding(struct device *dev)
>  {
>   const char *compatible_str = "samsung,exynos4212-hdmiphy";
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, compatible_str);
> + if (np)
> + return np;
> +
> + np = of_parse_phandle(dev->of_node, "phy", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);

Identical issue as in previous patch.

Regards
Andrzej

>  
> - return of_find_compatible_node(NULL, NULL, compatible_str);
> + return np;
>  }
>  
>  static int hdmi_probe(struct platform_device *pdev)
> @@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
>   return -EPROBE_DEFER;
>   }
>  
> - phy_node = hdmi_legacy_phy_dt_binding(dev);
> - if (phy_node)
> - goto out_get_phy_port;
> -
> - phy_node = of_parse_phandle(dev->of_node, "phy", 0);
> + phy_node = hdmi_phy_dt_binding(dev);
>   if (!phy_node) {
>   DRM_ERROR("Failed to find hdmiphy node in device tree\n");
>   ret = -ENODEV;
>   goto err_ddc;
>   }
> - of_node_put(dev->of_node);
>  
> -out_get_phy_port:
>   if (hdata->drv_data->is_apb_phy) {
>   hdata->regs_hdmiphy = of_iomap(phy_node, 0);
>   if (!hdata->regs_hdmiphy) {

[RFC PATCH 4/4] perf-probe: Support probing on offline cross-arch binary

[Masami Hiramatsu]

Support probing on offline cross-architecture binary by
adding getting the target machine arch from ELF and
choose correct register string for the machine.

Here is an example:
  -
  $ mkdir tracing
  $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
do_sys_open '$vars'
  Added new event:
  probe:do_sys_open(on do_sys_open with $vars)

  You can now use it in all perf tools, such as:

perf record -e probe:do_sys_open -aR sleep 1

  $ cat tracing/kprobe_events
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
   flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  -
Here, we can get probe/do_sys_open event by "copy & paste" from
./tracing/kprobe_events to target-machine's debugfs/tracing/kprobe_events

To make sure it is correct:
  -
  $ nm vmlinux-arm | grep "T _text"
  80008000 T _text
  $ nm vmlinux-arm | grep "T do_sys_open"
  801410f4 T do_sys_open
  $ expr `printf "%d + %d" 0x80008000 1282292`
  2148798708
  $ printf "%x\n" 2148798708
  801410f4
  -
So "_text+12882292" indicates do_sys_open on the target binary correctly.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
 tools/perf/arch/arm64/include/dwarf-regs-table.h   |   13 +
 tools/perf/arch/powerpc/include/dwarf-regs-table.h |   27 ++
 tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
 tools/perf/arch/sh/include/dwarf-regs-table.h  |   25 +
 tools/perf/arch/sparc/include/dwarf-regs-table.h   |   18 +++
 tools/perf/arch/x86/include/dwarf-regs-table.h |   14 +
 tools/perf/arch/xtensa/include/dwarf-regs-table.h  |8 +++
 tools/perf/util/Build  |1 
 tools/perf/util/dwarf-regs.c   |   55 
 tools/perf/util/include/dwarf-regs.h   |6 ++
 tools/perf/util/probe-finder.c |   27 ++
 tools/perf/util/probe-finder.h |1 
 13 files changed, 201 insertions(+), 11 deletions(-)
 create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
 create mode 100644 tools/perf/util/dwarf-regs.c

diff --git a/tools/perf/arch/arm/include/dwarf-regs-table.h 
b/tools/perf/arch/arm/include/dwarf-regs-table.h
new file mode 100644
index 000..f298d03
--- /dev/null
+++ b/tools/perf/arch/arm/include/dwarf-regs-table.h
@@ -0,0 +1,9 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+static const char * const arm_regstr_tbl[] = {
+   "%r0", "%r1", "%r2", "%r3", "%r4",
+   "%r5", "%r6", "%r7", "%r8", "%r9", "%r10",
+   "%fp", "%ip", "%sp", "%lr", "%pc",
+};
+#endif
diff --git a/tools/perf/arch/arm64/include/dwarf-regs-table.h 
b/tools/perf/arch/arm64/include/dwarf-regs-table.h
new file mode 100644
index 000..2675936
--- /dev/null
+++ b/tools/perf/arch/arm64/include/dwarf-regs-table.h
@@ -0,0 +1,13 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+static const char * const aarch64_regstr_tbl[] = {
+   "%r0", "%r1", "%r2", "%r3", "%r4",
+   "%r5", "%r6", "%r7", "%r8", "%r9",
+   "%r10", "%r11", "%r12", "%r13", "%r14",
+   "%r15", "%r16", "%r17", "%r18", "%r19",
+   "%r20", "%r21", "%r22", "%r23", "%r24",
+   "%r25", "%r26", "%r27", "%r28", "%r29",
+   "%lr", "%sp",
+};
+#endif
diff --git a/tools/perf/arch/powerpc/include/dwarf-regs-table.h 
b/tools/perf/arch/powerpc/include/dwarf-regs-table.h
new file mode 100644
index 000..db4730f
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/dwarf-regs-table.h
@@ -0,0 +1,27 @@
+#ifdef DEFINE_DWARF_REGSTR_TABLE
+/* This is included in perf/util/dwarf-regs.c */
+
+/*
+ * Reference:
+ * http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html
+ * http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
+ */
+#define REG_DWARFNUM_NAME(reg, idx)[idx] = "%" #reg
+
+static const char * const powerpc_regstr_tbl[] = {
+   "%gpr0", "%gpr1", "%gpr2", "%gpr3", "%gpr4",
+   "%gpr5", "%gpr6", "%gpr7", "%gpr8", "%gpr9",
+   "%gpr10", "%gpr11", "%gpr12", "%gpr13", "%gpr14",
+   "%gpr15", "%gpr16", "%gpr17", "%gpr18", "%gpr19",
+   "%gpr20", "%gpr21", "%gpr22", "%gpr23", "%gpr24",
+   "%gpr25", "%gpr26", "%gpr27", "%gpr28", "%gpr29",
+   "%gpr30", "%gpr31",
+   REG_DWARFNUM_NAME(msr,   66),
+   REG_DWARFNUM_NAME(ctr,   109),
+   REG_DWARFNUM_NAME(link,  108),
+   REG_DWARFNUM_NAME(xer,   101),

Re: [PATCH v2 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property

[Andrzej Hajda]

On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'phy' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 6a636f2..bb2d6d4 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct 
> device *dev)
>   return np;
>  }
>  
> -static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> +static struct device_node *hdmi_phy_dt_binding(struct device *dev)
>  {
>   const char *compatible_str = "samsung,exynos4212-hdmiphy";
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, compatible_str);
> + if (np)
> + return np;
> +
> + np = of_parse_phandle(dev->of_node, "phy", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);

Identical issue as in previous patch.

Regards
Andrzej

>  
> - return of_find_compatible_node(NULL, NULL, compatible_str);
> + return np;
>  }
>  
>  static int hdmi_probe(struct platform_device *pdev)
> @@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
>   return -EPROBE_DEFER;
>   }
>  
> - phy_node = hdmi_legacy_phy_dt_binding(dev);
> - if (phy_node)
> - goto out_get_phy_port;
> -
> - phy_node = of_parse_phandle(dev->of_node, "phy", 0);
> + phy_node = hdmi_phy_dt_binding(dev);
>   if (!phy_node) {
>   DRM_ERROR("Failed to find hdmiphy node in device tree\n");
>   ret = -ENODEV;
>   goto err_ddc;
>   }
> - of_node_put(dev->of_node);
>  
> -out_get_phy_port:
>   if (hdata->drv_data->is_apb_phy) {
>   hdata->regs_hdmiphy = of_iomap(phy_node, 0);
>   if (!hdata->regs_hdmiphy) {

[RFC PATCH 2/4] perf-probe: Add offline output directory option

[Masami Hiramatsu]

Add offline output direcrtory option. This allows user to
store probe event definition in offline output directory.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/builtin-probe.c|2 ++
 tools/perf/util/probe-event.h |1 +
 tools/perf/util/probe-file.c  |   19 ---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index ee5b421..5b45ec8 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -517,6 +517,8 @@ __cmd_probe(int argc, const char **argv, const char *prefix 
__maybe_unused)
"Show variables location range in scope (with --vars only)"),
OPT_STRING('k', "vmlinux", _conf.vmlinux_name,
   "file", "vmlinux pathname"),
+   OPT_STRING(0, "outdir", _conf.output_dir,
+   "directory", "path to offline output directory"),
OPT_STRING('s', "source", _conf.source_prefix,
   "directory", "path to kernel source"),
OPT_BOOLEAN('\0', "no-inlines", _conf.no_inlines,
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index f4f45db..75b572a 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -14,6 +14,7 @@ struct probe_conf {
boolno_inlines;
boolcache;
int max_probes;
+   const char  *output_dir;
 };
 extern struct probe_conf probe_conf;
 extern bool probe_event_dry_run;
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 6f931e4..41db430 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -73,16 +73,25 @@ static void print_both_open_warning(int kerr, int uerr)
 static int open_probe_events(const char *trace_file, bool readwrite)
 {
char buf[PATH_MAX];
+   const char *tracing_dir = tracing_path;
+   int oflag = 0;
+   mode_t mode = 0;
int ret;
 
+   if (probe_conf.output_dir) {
+   tracing_dir = probe_conf.output_dir;
+   oflag = O_CREAT;
+   mode = 0644;
+   }
+
ret = e_snprintf(buf, PATH_MAX, "%s/%s",
-tracing_path, trace_file);
+tracing_dir, trace_file);
if (ret >= 0) {
pr_debug("Opening %s write=%d\n", buf, readwrite);
if (readwrite && !probe_event_dry_run)
-   ret = open(buf, O_RDWR | O_APPEND, 0);
+   ret = open(buf, O_RDWR | O_APPEND | oflag, mode);
else
-   ret = open(buf, O_RDONLY, 0);
+   ret = open(buf, O_RDONLY | oflag, mode);
 
if (ret < 0)
ret = -errno;
@@ -242,6 +251,8 @@ int probe_file__add_event(int fd, struct probe_trace_event 
*tev)
pr_warning("Failed to write event: %s\n",
   str_error_r(errno, sbuf, sizeof(sbuf)));
}
+   if (probe_conf.output_dir)
+   ret = write(fd, "\n", 1) == 1 ? 0 : -errno;
}
free(buf);
 
@@ -274,6 +285,8 @@ static int __del_trace_probe_event(int fd, struct str_node 
*ent)
ret = -errno;
goto error;
}
+   if (probe_conf.output_dir)
+   ret = write(fd, "\n", 1) == 1 ? 0 : -errno;
 
return 0;
 error:

[RFC PATCH 3/4] perf-probe: Ignore vmlinux buildid if offline kernel is given

[Masami Hiramatsu]

Ignore the buildid of running kernel when both --outdir and
--vmlinux is given and --outdir is not tracing_path,
because that kernel should be off-line.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/builtin-probe.c   |6 ++
 tools/perf/util/symbol-elf.c |2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 5b45ec8..773cea0 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -602,6 +602,12 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
 */
symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
 
+   /* If user gives output directory and offline vmlinux, ignore buildid */
+   if (probe_conf.output_dir && symbol_conf.vmlinux_name &&
+   strcmp(probe_conf.output_dir, tracing_path) != 0) {
+   symbol_conf.ignore_vmlinux_buildid = true;
+   }
+
switch (params.command) {
case 'l':
if (params.uprobes) {
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a811c13..013cebf 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -685,7 +685,7 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, const 
char *name,
}
 
/* Always reject images with a mismatched build-id: */
-   if (dso->has_build_id) {
+   if (dso->has_build_id && !symbol_conf.ignore_vmlinux_buildid) {
u8 build_id[BUILD_ID_SIZE];
 
if (elf_read_build_id(elf, build_id, BUILD_ID_SIZE) < 0) {

[RFC PATCH 2/4] perf-probe: Add offline output directory option

[Masami Hiramatsu]

Add offline output direcrtory option. This allows user to
store probe event definition in offline output directory.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/builtin-probe.c|2 ++
 tools/perf/util/probe-event.h |1 +
 tools/perf/util/probe-file.c  |   19 ---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index ee5b421..5b45ec8 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -517,6 +517,8 @@ __cmd_probe(int argc, const char **argv, const char *prefix 
__maybe_unused)
"Show variables location range in scope (with --vars only)"),
OPT_STRING('k', "vmlinux", _conf.vmlinux_name,
   "file", "vmlinux pathname"),
+   OPT_STRING(0, "outdir", _conf.output_dir,
+   "directory", "path to offline output directory"),
OPT_STRING('s', "source", _conf.source_prefix,
   "directory", "path to kernel source"),
OPT_BOOLEAN('\0', "no-inlines", _conf.no_inlines,
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index f4f45db..75b572a 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -14,6 +14,7 @@ struct probe_conf {
boolno_inlines;
boolcache;
int max_probes;
+   const char  *output_dir;
 };
 extern struct probe_conf probe_conf;
 extern bool probe_event_dry_run;
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 6f931e4..41db430 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -73,16 +73,25 @@ static void print_both_open_warning(int kerr, int uerr)
 static int open_probe_events(const char *trace_file, bool readwrite)
 {
char buf[PATH_MAX];
+   const char *tracing_dir = tracing_path;
+   int oflag = 0;
+   mode_t mode = 0;
int ret;
 
+   if (probe_conf.output_dir) {
+   tracing_dir = probe_conf.output_dir;
+   oflag = O_CREAT;
+   mode = 0644;
+   }
+
ret = e_snprintf(buf, PATH_MAX, "%s/%s",
-tracing_path, trace_file);
+tracing_dir, trace_file);
if (ret >= 0) {
pr_debug("Opening %s write=%d\n", buf, readwrite);
if (readwrite && !probe_event_dry_run)
-   ret = open(buf, O_RDWR | O_APPEND, 0);
+   ret = open(buf, O_RDWR | O_APPEND | oflag, mode);
else
-   ret = open(buf, O_RDONLY, 0);
+   ret = open(buf, O_RDONLY | oflag, mode);
 
if (ret < 0)
ret = -errno;
@@ -242,6 +251,8 @@ int probe_file__add_event(int fd, struct probe_trace_event 
*tev)
pr_warning("Failed to write event: %s\n",
   str_error_r(errno, sbuf, sizeof(sbuf)));
}
+   if (probe_conf.output_dir)
+   ret = write(fd, "\n", 1) == 1 ? 0 : -errno;
}
free(buf);
 
@@ -274,6 +285,8 @@ static int __del_trace_probe_event(int fd, struct str_node 
*ent)
ret = -errno;
goto error;
}
+   if (probe_conf.output_dir)
+   ret = write(fd, "\n", 1) == 1 ? 0 : -errno;
 
return 0;
 error:

[RFC PATCH 3/4] perf-probe: Ignore vmlinux buildid if offline kernel is given

[Masami Hiramatsu]

Ignore the buildid of running kernel when both --outdir and
--vmlinux is given and --outdir is not tracing_path,
because that kernel should be off-line.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/builtin-probe.c   |6 ++
 tools/perf/util/symbol-elf.c |2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 5b45ec8..773cea0 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -602,6 +602,12 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
 */
symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
 
+   /* If user gives output directory and offline vmlinux, ignore buildid */
+   if (probe_conf.output_dir && symbol_conf.vmlinux_name &&
+   strcmp(probe_conf.output_dir, tracing_path) != 0) {
+   symbol_conf.ignore_vmlinux_buildid = true;
+   }
+
switch (params.command) {
case 'l':
if (params.uprobes) {
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a811c13..013cebf 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -685,7 +685,7 @@ int symsrc__init(struct symsrc *ss, struct dso *dso, const 
char *name,
}
 
/* Always reject images with a mismatched build-id: */
-   if (dso->has_build_id) {
+   if (dso->has_build_id && !symbol_conf.ignore_vmlinux_buildid) {
u8 build_id[BUILD_ID_SIZE];
 
if (elf_read_build_id(elf, build_id, BUILD_ID_SIZE) < 0) {

[RFC PATCH 1/4] perf-probe: Remove unused tracing_dir variable

[Masami Hiramatsu]

Remove unused tracing_dir variable from open_probe_events().

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-file.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 697ef66..6f931e4 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -73,11 +73,10 @@ static void print_both_open_warning(int kerr, int uerr)
 static int open_probe_events(const char *trace_file, bool readwrite)
 {
char buf[PATH_MAX];
-   const char *tracing_dir = "";
int ret;
 
-   ret = e_snprintf(buf, PATH_MAX, "%s/%s%s",
-tracing_path, tracing_dir, trace_file);
+   ret = e_snprintf(buf, PATH_MAX, "%s/%s",
+tracing_path, trace_file);
if (ret >= 0) {
pr_debug("Opening %s write=%d\n", buf, readwrite);
if (readwrite && !probe_event_dry_run)

[RFC PATCH 1/4] perf-probe: Remove unused tracing_dir variable

[Masami Hiramatsu]

Remove unused tracing_dir variable from open_probe_events().

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-file.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 697ef66..6f931e4 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -73,11 +73,10 @@ static void print_both_open_warning(int kerr, int uerr)
 static int open_probe_events(const char *trace_file, bool readwrite)
 {
char buf[PATH_MAX];
-   const char *tracing_dir = "";
int ret;
 
-   ret = e_snprintf(buf, PATH_MAX, "%s/%s%s",
-tracing_path, tracing_dir, trace_file);
+   ret = e_snprintf(buf, PATH_MAX, "%s/%s",
+tracing_path, trace_file);
if (ret >= 0) {
pr_debug("Opening %s write=%d\n", buf, readwrite);
if (readwrite && !probe_event_dry_run)

[RFC PATCH 0/4] perf probe: Introduce remote cross-arch probes

[Masami Hiramatsu]

Hi,

Here is an RFC series for remote cross-arch probe support on perf-probe.

I've made a perf-probe for remote arch (currently arm on x86-64) for
helping debugging and performance analysis.

Currently perf-probe doesn't supoort cross/remote target. This means
we have to cross-build the perf-tools including libraries (elfutils,
libelf etc.), and to prepare vmlinux with debuginfo which can be 
accessed from the target machine.
This requires too much resource for a small embededd device.

If we can analyze the debuginfo by perf-probe on host machine,
we do not need to cross-build perf-tools, nor copy vmlinux on the
device. :)

This series introduces such features on perf-probe.

To use this, on host machine (with cross build kernel image),
below command outputs the target-machine's kprobe-events definition
in /kprobe_events.

  perf probe -k  --outdir= \
 

Perf analyzes the given vmlinux and get the architecture and
switch the dwarf-register mappings.

Here is an example:
  -
  $ mkdir tracing
  $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
do_sys_open '$vars'
  Added new event:
  probe:do_sys_open(on do_sys_open with $vars)

  You can now use it in all perf tools, such as:

perf record -e probe:do_sys_open -aR sleep 1

  $ cat tracing/kprobe_events
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
   flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  -
Here, we can get probe/do_sys_open event by "copy & paste" the
definition to target-machine's debugfs/tracing/kprobe_events.

To make sure it is correct:
  -
  $ nm vmlinux-arm | grep "T _text"
  80008000 T _text
  $ nm vmlinux-arm | grep "T do_sys_open"
  801410f4 T do_sys_open
  $ expr `printf "%d + %d" 0x80008000 1282292`
  2148798708
  $ printf "%x\n" 2148798708
  801410f4
  -
So "_text+12882292" indicates do_sys_open on the target binary correctly.

Thanks,
---

Masami Hiramatsu (4):
  perf-probe: Remove unused tracing_dir variable
  perf-probe: Add offline output directory option
  perf-probe: Ignore vmlinux buildid if offline kernel is given
  perf-probe: Support probing on offline cross-arch binary


 tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
 tools/perf/arch/arm64/include/dwarf-regs-table.h   |   13 +
 tools/perf/arch/powerpc/include/dwarf-regs-table.h |   27 ++
 tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
 tools/perf/arch/sh/include/dwarf-regs-table.h  |   25 +
 tools/perf/arch/sparc/include/dwarf-regs-table.h   |   18 +++
 tools/perf/arch/x86/include/dwarf-regs-table.h |   14 +
 tools/perf/arch/xtensa/include/dwarf-regs-table.h  |8 +++
 tools/perf/builtin-probe.c |8 +++
 tools/perf/util/Build  |1 
 tools/perf/util/dwarf-regs.c   |   55 
 tools/perf/util/include/dwarf-regs.h   |6 ++
 tools/perf/util/probe-event.h  |1 
 tools/perf/util/probe-file.c   |   22 ++--
 tools/perf/util/probe-finder.c |   27 ++
 tools/perf/util/probe-finder.h |1 
 tools/perf/util/symbol-elf.c   |2 -
 17 files changed, 228 insertions(+), 17 deletions(-)
 create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
 create mode 100644 tools/perf/util/dwarf-regs.c

--
Masami Hiramatsu (Linaro Ltd.) 

[RFC PATCH 0/4] perf probe: Introduce remote cross-arch probes

[Masami Hiramatsu]

Hi,

Here is an RFC series for remote cross-arch probe support on perf-probe.

I've made a perf-probe for remote arch (currently arm on x86-64) for
helping debugging and performance analysis.

Currently perf-probe doesn't supoort cross/remote target. This means
we have to cross-build the perf-tools including libraries (elfutils,
libelf etc.), and to prepare vmlinux with debuginfo which can be 
accessed from the target machine.
This requires too much resource for a small embededd device.

If we can analyze the debuginfo by perf-probe on host machine,
we do not need to cross-build perf-tools, nor copy vmlinux on the
device. :)

This series introduces such features on perf-probe.

To use this, on host machine (with cross build kernel image),
below command outputs the target-machine's kprobe-events definition
in /kprobe_events.

  perf probe -k  --outdir= \
 

Perf analyzes the given vmlinux and get the architecture and
switch the dwarf-register mappings.

Here is an example:
  -
  $ mkdir tracing
  $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
do_sys_open '$vars'
  Added new event:
  probe:do_sys_open(on do_sys_open with $vars)

  You can now use it in all perf tools, such as:

perf record -e probe:do_sys_open -aR sleep 1

  $ cat tracing/kprobe_events
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
   flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  -
Here, we can get probe/do_sys_open event by "copy & paste" the
definition to target-machine's debugfs/tracing/kprobe_events.

To make sure it is correct:
  -
  $ nm vmlinux-arm | grep "T _text"
  80008000 T _text
  $ nm vmlinux-arm | grep "T do_sys_open"
  801410f4 T do_sys_open
  $ expr `printf "%d + %d" 0x80008000 1282292`
  2148798708
  $ printf "%x\n" 2148798708
  801410f4
  -
So "_text+12882292" indicates do_sys_open on the target binary correctly.

Thanks,
---

Masami Hiramatsu (4):
  perf-probe: Remove unused tracing_dir variable
  perf-probe: Add offline output directory option
  perf-probe: Ignore vmlinux buildid if offline kernel is given
  perf-probe: Support probing on offline cross-arch binary


 tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
 tools/perf/arch/arm64/include/dwarf-regs-table.h   |   13 +
 tools/perf/arch/powerpc/include/dwarf-regs-table.h |   27 ++
 tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
 tools/perf/arch/sh/include/dwarf-regs-table.h  |   25 +
 tools/perf/arch/sparc/include/dwarf-regs-table.h   |   18 +++
 tools/perf/arch/x86/include/dwarf-regs-table.h |   14 +
 tools/perf/arch/xtensa/include/dwarf-regs-table.h  |8 +++
 tools/perf/builtin-probe.c |8 +++
 tools/perf/util/Build  |1 
 tools/perf/util/dwarf-regs.c   |   55 
 tools/perf/util/include/dwarf-regs.h   |6 ++
 tools/perf/util/probe-event.h  |1 
 tools/perf/util/probe-file.c   |   22 ++--
 tools/perf/util/probe-finder.c |   27 ++
 tools/perf/util/probe-finder.h |1 
 tools/perf/util/symbol-elf.c   |2 -
 17 files changed, 228 insertions(+), 17 deletions(-)
 create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
 create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
 create mode 100644 tools/perf/util/dwarf-regs.c

--
Masami Hiramatsu (Linaro Ltd.) 

Re: [PATCH v6 2/4] Add support for SCT Write Same

[Tom Yan]

Never mind. I was a bit lightheaded.

Anyway I don't think you should use ata_scsi_rbuf. It is a buffer
created and used for ata_scsi_simulate, which interacts with the SCSI
layer but not the ATA device (v.s. ata_scsi_translate). You should
probably create buffer inside ata_format_dsm_trim_descr() and
ata_format_sct_write_same() of size(s) you need.

On 23 August 2016 at 18:56, Shaun Tancheff  wrote:
> On Tue, Aug 23, 2016 at 5:37 AM, Tom Yan  wrote:
>> On 22 August 2016 at 04:23, Shaun Tancheff  wrote:
>>> +/**
>>> + * ata_format_dsm_trim_descr() - SATL Write Same to ATA SCT Write Same
>>> + * @cmd: SCSI command being translated
>>> + * @lba: Starting sector
>>> + * @num: Number of logical sectors to be zero'd.
>>> + *
>>> + * Rewrite the WRITE SAME descriptor to be an SCT Write Same formatted
>>> + * descriptor.
>>> + * NOTE: Writes a pattern (0's) in the foreground.
>>> + *   Large write-same requents can timeout.
>>> + */
>>> +static void ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64 
>>> num)
>>> +{
>>> +   u16 *sctpg;
>>> +   unsigned long flags;
>>> +
>>> +   spin_lock_irqsave(_scsi_rbuf_lock, flags);
>>> +   sctpg = ((void *)ata_scsi_rbuf);
>>
>> Because ata_scsi_rbuf is of a fixed size of ATA_SCSI_RBUF_SIZE.
>>
>> #define ATA_SCSI_RBUF_SIZE  4096
>> ...
>> static u8 ata_scsi_rbuf[ATA_SCSI_RBUF_SIZE];
>>
>>> +
>>> +   put_unaligned_le16(0x0002,  [0]); /* SCT_ACT_WRITE_SAME */
>>> +   put_unaligned_le16(0x0101,  [1]); /* WRITE PTRN FG */
>>> +   put_unaligned_le64(lba, [2]);
>>> +   put_unaligned_le64(num, [6]);
>>> +   put_unaligned_le32(0u,  [10]);
>>> +
>>> +   sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), sctpg, 
>>> 512);
>>
>> You have no reason to use 512 here instead of ATA_SCSI_RBUF_SIZE this time.
>
> Ah .. because SCT Write Same is a fixed 512 byte transfer?
> Ah .. because I only have 512 bytes to copy?
>
>>> +   spin_unlock_irqrestore(_scsi_rbuf_lock, flags);
>>> +}

Re: [PATCH v6 2/4] Add support for SCT Write Same

[Tom Yan]

Never mind. I was a bit lightheaded.

Anyway I don't think you should use ata_scsi_rbuf. It is a buffer
created and used for ata_scsi_simulate, which interacts with the SCSI
layer but not the ATA device (v.s. ata_scsi_translate). You should
probably create buffer inside ata_format_dsm_trim_descr() and
ata_format_sct_write_same() of size(s) you need.

On 23 August 2016 at 18:56, Shaun Tancheff  wrote:
> On Tue, Aug 23, 2016 at 5:37 AM, Tom Yan  wrote:
>> On 22 August 2016 at 04:23, Shaun Tancheff  wrote:
>>> +/**
>>> + * ata_format_dsm_trim_descr() - SATL Write Same to ATA SCT Write Same
>>> + * @cmd: SCSI command being translated
>>> + * @lba: Starting sector
>>> + * @num: Number of logical sectors to be zero'd.
>>> + *
>>> + * Rewrite the WRITE SAME descriptor to be an SCT Write Same formatted
>>> + * descriptor.
>>> + * NOTE: Writes a pattern (0's) in the foreground.
>>> + *   Large write-same requents can timeout.
>>> + */
>>> +static void ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64 
>>> num)
>>> +{
>>> +   u16 *sctpg;
>>> +   unsigned long flags;
>>> +
>>> +   spin_lock_irqsave(_scsi_rbuf_lock, flags);
>>> +   sctpg = ((void *)ata_scsi_rbuf);
>>
>> Because ata_scsi_rbuf is of a fixed size of ATA_SCSI_RBUF_SIZE.
>>
>> #define ATA_SCSI_RBUF_SIZE  4096
>> ...
>> static u8 ata_scsi_rbuf[ATA_SCSI_RBUF_SIZE];
>>
>>> +
>>> +   put_unaligned_le16(0x0002,  [0]); /* SCT_ACT_WRITE_SAME */
>>> +   put_unaligned_le16(0x0101,  [1]); /* WRITE PTRN FG */
>>> +   put_unaligned_le64(lba, [2]);
>>> +   put_unaligned_le64(num, [6]);
>>> +   put_unaligned_le32(0u,  [10]);
>>> +
>>> +   sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), sctpg, 
>>> 512);
>>
>> You have no reason to use 512 here instead of ATA_SCSI_RBUF_SIZE this time.
>
> Ah .. because SCT Write Same is a fixed 512 byte transfer?
> Ah .. because I only have 512 bytes to copy?
>
>>> +   spin_unlock_irqrestore(_scsi_rbuf_lock, flags);
>>> +}

Re: [PATCH v2 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property

[Andrzej Hajda]

On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'ddc' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..6a636f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
>   .unbind = hdmi_unbind,
>  };
>  
> -static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
> +static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
>  {
>   const char *compatible_str = "samsung,exynos4210-hdmiddc";
>   struct device_node *np;
> @@ -1769,7 +1769,13 @@ static struct device_node 
> *hdmi_legacy_ddc_dt_binding(struct device *dev)
>   if (np)
>   return of_get_next_parent(np);
>  
> - return NULL;
> + np = of_parse_phandle(dev->of_node, "ddc", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);
This is mistake introduced  by other patch, of_node_put should be called on
np, after calling of_find_i2c_adapter_by_node. You can fix it in your
patch as well.
I think you can move of_find_i2c_adapter_by_node also to this function and
rename it to sth like hdmi_get_ddc_adapter, this way you will enclose
whole logic
of getting resource into one function.

Regards
Andrzej

> +
> + return np;
>  }
>  
>  static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> @@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - ddc_node = hdmi_legacy_ddc_dt_binding(dev);
> - if (ddc_node)
> - goto out_get_ddc_adpt;
> -
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> + ddc_node = hdmi_ddc_dt_binding(dev);
>   if (!ddc_node) {
>   DRM_ERROR("Failed to find ddc node in device tree\n");
>   return -ENODEV;
>   }
> - of_node_put(dev->of_node);
>  
> -out_get_ddc_adpt:
>   hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
>   if (!hdata->ddc_adpt) {
>   DRM_ERROR("Failed to get ddc i2c adapter by node\n");

Re: [PATCH v2 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property

[Andrzej Hajda]

On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'ddc' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..6a636f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
>   .unbind = hdmi_unbind,
>  };
>  
> -static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
> +static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
>  {
>   const char *compatible_str = "samsung,exynos4210-hdmiddc";
>   struct device_node *np;
> @@ -1769,7 +1769,13 @@ static struct device_node 
> *hdmi_legacy_ddc_dt_binding(struct device *dev)
>   if (np)
>   return of_get_next_parent(np);
>  
> - return NULL;
> + np = of_parse_phandle(dev->of_node, "ddc", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);
This is mistake introduced  by other patch, of_node_put should be called on
np, after calling of_find_i2c_adapter_by_node. You can fix it in your
patch as well.
I think you can move of_find_i2c_adapter_by_node also to this function and
rename it to sth like hdmi_get_ddc_adapter, this way you will enclose
whole logic
of getting resource into one function.

Regards
Andrzej

> +
> + return np;
>  }
>  
>  static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> @@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - ddc_node = hdmi_legacy_ddc_dt_binding(dev);
> - if (ddc_node)
> - goto out_get_ddc_adpt;
> -
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> + ddc_node = hdmi_ddc_dt_binding(dev);
>   if (!ddc_node) {
>   DRM_ERROR("Failed to find ddc node in device tree\n");
>   return -ENODEV;
>   }
> - of_node_put(dev->of_node);
>  
> -out_get_ddc_adpt:
>   hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
>   if (!hdata->ddc_adpt) {
>   DRM_ERROR("Failed to get ddc i2c adapter by node\n");

Re: [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

[Corentin LABBE]

Hello

> +/* Read data from the RNG unit */
> +static int cavium_rng_read(struct hwrng *rng, void *dat, size_t max, bool 
> wait)
> +{
> + struct cavium_rng *p = container_of(rng, struct cavium_rng, ops);
> + unsigned int size = max;
> +
> + while (size >= 8) {
> + *((u64 *)dat) = readq(p->result);
> + size -= 8;
> + dat += 8;
> + }

I think you could use readsq()
This will increase throughput

Regards

LABBE Corentin

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Dan Williams]

On Tue, Aug 23, 2016 at 8:58 PM, Dan Williams  wrote:
> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams  
> wrote:
>> On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu  wrote:
 On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu 
 wrote:
 > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
 >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani 
 >> wrote:
 >  :
 >> I'm not sure about this fix.  The point of honoring
 >> vmem_altmap_offset() is because a portion of the resource that is
 >> passed to devm_memremap_pages() also contains the metadata info
 block
 >> for the device.  The offset says "use everything past this point for
 >> pages".  This may work for avoiding a crash, but it may corrupt info
 >> block metadata in the process.  Can you provide more information
 >> about the failing scenario to be sure that we are not triggering a
 >> fault on an address that is not meant to have a page mapping?  I.e.
 >> what is the host physical address of the page that caused this fault,
 >> and is it valid?
 >
 > The fault address in question was the 2nd page of an NVDIMM range.  I
 > assumed this fault address was valid and needed to be handled.  Here is
 > some info about the base and patched cases.  Let me know if you need
 > more info.
 >
 > Base
 > 
 >
 > The following NVDIMM range was set to /dev/dax.

 With ndctl create-namespace or manually via sysfs?  Specifically I'm
 looking for what the 'align' attribute was set to when the
 configuration was established.  Can you provide a dump of the sysfs
 attributes for the /dev/dax parent device?
>>>
>>> I used the ndctl command below.
>>> ndctl create-namespace -f -e namespace0.0 -m dax
>>>
>>> Here is additional info from my note for the base case.
>>>
>>> p {struct dev_pagemap} 0x88046d0453f0
>>> $3 = {
>>>   altmap = 0x88046d045410,
>>>   res = 0x88046d0453a8,
>>>   ref = 0x88046d0452f0,
>>>   dev = 0x880464790410
>>> }
>>>
>>> crash> p {struct vmem_altmap} 0x88046d045410
>>> $6 = {
>>>   base_pfn = 0x48,
>>>   reserve = 0x2,// PHYS_PFN(SZ_8K)
>>>   free = 0x101fe,
>>>   align = 0x1fe,
>>>   alloc = 0x1
>>> }
>>
>> Ah, so, on second look the 0x49020 data offset looks correct.  The
>> total size of the address range is 16GB which equates to 256MB needed
>> for struct page, plus 2MB more to re-align the data on the next 2MB
>> boundary.
>>
>> The question now is why is the guest faulting on an access to an
>> address less than 0x49020?
>
> Does the attached patch fix this for you?

Sorry, should be this much simpler patch that also mirrors what
driver/nvdimm/pmem.c is doing...
From 3369f0e825c12bb2f17c0f7d3ccecb7c60f645e0 Mon Sep 17 00:00:00 2001
From: Dan Williams 
Date: Tue, 23 Aug 2016 19:59:31 -0700
Subject: [PATCH] dax: fix device-dax region base

The data offset for a dax region needs to account for an altmap
reservation in the resource range.  Otherwise, device-dax is allowing
mappings directly into the memmap or device info-block area, with crash
signatures like the following:

 BUG: unable to handle kernel NULL pointer dereference at 0008
 IP: [] get_zone_device_page+0x11/0x30
 Call Trace:
   follow_devmap_pmd+0x298/0x2c0
   follow_page_mask+0x275/0x530
   __get_user_pages+0xe3/0x750
   __gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
   ? hrtimer_try_to_cancel+0x2c/0x120
   ? kvm_read_l1_tsc+0x55/0x60 [kvm]
   try_async_pf+0x66/0x230 [kvm]
   ? kvm_host_page_size+0x90/0xa0 [kvm]
   tdp_page_fault+0x130/0x280 [kvm]
   kvm_mmu_page_fault+0x5f/0xf0 [kvm]
   handle_ept_violation+0x94/0x180 [kvm_intel]
   vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
   ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel]
   ? vmx_vcpu_run+0x2d1/0x490 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
   ? wake_up_q+0x44/0x80
   kvm_vcpu_ioctl+0x33c/0x620 [kvm]
   ? __vfs_write+0x37/0x160
   do_vfs_ioctl+0xa2/0x5d0
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x1a/0xa4

Cc: 
Cc: Andrew Morton 
Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Abhilash Kumar Mulumudi 
Reported-by: Toshi Kani 
Signed-off-by: Dan Williams 
---
 drivers/dax/pmem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index dfb168568af1..1f01e98c83c7 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -116,6 +116,9 @@ static int dax_pmem_probe(struct device *dev)
 	if (rc)
 		return rc;
 
+	/* adjust the dax_region resource to the start of data */
+	res.start += le64_to_cpu(pfn_sb->dataoff);
+
 	nd_region = to_nd_region(dev->parent);
 	dax_region = alloc_dax_region(dev, 

Re: [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

[Corentin LABBE]

Hello

> +/* Read data from the RNG unit */
> +static int cavium_rng_read(struct hwrng *rng, void *dat, size_t max, bool 
> wait)
> +{
> + struct cavium_rng *p = container_of(rng, struct cavium_rng, ops);
> + unsigned int size = max;
> +
> + while (size >= 8) {
> + *((u64 *)dat) = readq(p->result);
> + size -= 8;
> + dat += 8;
> + }

I think you could use readsq()
This will increase throughput

Regards

LABBE Corentin

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Dan Williams]

On Tue, Aug 23, 2016 at 8:58 PM, Dan Williams  wrote:
> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams  
> wrote:
>> On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu  wrote:
 On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu 
 wrote:
 > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
 >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani 
 >> wrote:
 >  :
 >> I'm not sure about this fix.  The point of honoring
 >> vmem_altmap_offset() is because a portion of the resource that is
 >> passed to devm_memremap_pages() also contains the metadata info
 block
 >> for the device.  The offset says "use everything past this point for
 >> pages".  This may work for avoiding a crash, but it may corrupt info
 >> block metadata in the process.  Can you provide more information
 >> about the failing scenario to be sure that we are not triggering a
 >> fault on an address that is not meant to have a page mapping?  I.e.
 >> what is the host physical address of the page that caused this fault,
 >> and is it valid?
 >
 > The fault address in question was the 2nd page of an NVDIMM range.  I
 > assumed this fault address was valid and needed to be handled.  Here is
 > some info about the base and patched cases.  Let me know if you need
 > more info.
 >
 > Base
 > 
 >
 > The following NVDIMM range was set to /dev/dax.

 With ndctl create-namespace or manually via sysfs?  Specifically I'm
 looking for what the 'align' attribute was set to when the
 configuration was established.  Can you provide a dump of the sysfs
 attributes for the /dev/dax parent device?
>>>
>>> I used the ndctl command below.
>>> ndctl create-namespace -f -e namespace0.0 -m dax
>>>
>>> Here is additional info from my note for the base case.
>>>
>>> p {struct dev_pagemap} 0x88046d0453f0
>>> $3 = {
>>>   altmap = 0x88046d045410,
>>>   res = 0x88046d0453a8,
>>>   ref = 0x88046d0452f0,
>>>   dev = 0x880464790410
>>> }
>>>
>>> crash> p {struct vmem_altmap} 0x88046d045410
>>> $6 = {
>>>   base_pfn = 0x48,
>>>   reserve = 0x2,// PHYS_PFN(SZ_8K)
>>>   free = 0x101fe,
>>>   align = 0x1fe,
>>>   alloc = 0x1
>>> }
>>
>> Ah, so, on second look the 0x49020 data offset looks correct.  The
>> total size of the address range is 16GB which equates to 256MB needed
>> for struct page, plus 2MB more to re-align the data on the next 2MB
>> boundary.
>>
>> The question now is why is the guest faulting on an access to an
>> address less than 0x49020?
>
> Does the attached patch fix this for you?

Sorry, should be this much simpler patch that also mirrors what
driver/nvdimm/pmem.c is doing...
From 3369f0e825c12bb2f17c0f7d3ccecb7c60f645e0 Mon Sep 17 00:00:00 2001
From: Dan Williams 
Date: Tue, 23 Aug 2016 19:59:31 -0700
Subject: [PATCH] dax: fix device-dax region base

The data offset for a dax region needs to account for an altmap
reservation in the resource range.  Otherwise, device-dax is allowing
mappings directly into the memmap or device info-block area, with crash
signatures like the following:

 BUG: unable to handle kernel NULL pointer dereference at 0008
 IP: [] get_zone_device_page+0x11/0x30
 Call Trace:
   follow_devmap_pmd+0x298/0x2c0
   follow_page_mask+0x275/0x530
   __get_user_pages+0xe3/0x750
   __gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
   ? hrtimer_try_to_cancel+0x2c/0x120
   ? kvm_read_l1_tsc+0x55/0x60 [kvm]
   try_async_pf+0x66/0x230 [kvm]
   ? kvm_host_page_size+0x90/0xa0 [kvm]
   tdp_page_fault+0x130/0x280 [kvm]
   kvm_mmu_page_fault+0x5f/0xf0 [kvm]
   handle_ept_violation+0x94/0x180 [kvm_intel]
   vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
   ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel]
   ? vmx_vcpu_run+0x2d1/0x490 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
   ? wake_up_q+0x44/0x80
   kvm_vcpu_ioctl+0x33c/0x620 [kvm]
   ? __vfs_write+0x37/0x160
   do_vfs_ioctl+0xa2/0x5d0
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x1a/0xa4

Cc: 
Cc: Andrew Morton 
Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Abhilash Kumar Mulumudi 
Reported-by: Toshi Kani 
Signed-off-by: Dan Williams 
---
 drivers/dax/pmem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index dfb168568af1..1f01e98c83c7 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -116,6 +116,9 @@ static int dax_pmem_probe(struct device *dev)
 	if (rc)
 		return rc;
 
+	/* adjust the dax_region resource to the start of data */
+	res.start += le64_to_cpu(pfn_sb->dataoff);
+
 	nd_region = to_nd_region(dev->parent);
 	dax_region = alloc_dax_region(dev, nd_region->id, ,
 			le32_to_cpu(pfn_sb->align), addr, PFN_DEV|PFN_MAP);
-- 
2.5.5

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

[Tom Yan]

On 24 August 2016 at 11:33, Martin K. Petersen
 wrote:
>> "Tom" == Tom Yan  writes:
>
> Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI
> Tom> terms, parameter list / data-out buffer).
>
> WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we
> have had no good reason to support that yet).

Interesting, I wasn't aware of the bit. I just didn't see any
parameter list defined for any of the Write Same commands. Ah wait, it
carries the pattern (the "same") and so.

Hmm, it doesn't seem like the translation implemented in this patch
series cares about the payload though?

>
> UNMAP has a payload that varies based on the number of range
> descriptors. The SCSI disk driver only ever issues a single descriptor
> but since libata doesn't support UNMAP this doesn't really come into
> play.
>
> Ideally there would be a way to distinguish between device limits for
> WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to
> do that would be to transition the libata discard implementation over to
> single-range UNMAP, fill out the relevant VPD page B0 fields and leave
> the WRITE SAME bits for writing zeroes.
>
> One reason that has not been particularly compelling is that the WRITE
> SAME payload buffer does double duty to hold the ATA DSM TRIM range

Huh? Why would the SATL care about its payload buffer for TRIM (i.e.
when the UNMAP bit is set)? Doesn't it just read the LBA and NUMBER OF
BLOCKS field and pack TRIM ranges/payload according to that?

> descriptors and matches the required ATA payload size. Whereas the UNMAP

Why would it need to "matches the required ATA payload size"?

> command would only provide 24 bytes of TRIM range space.

I don't really follow. The UNMAP descriptor has LBA (8 bytes / 64-bit)
and NUMBER OF BLOCKS (4 bytes / 32-bit) field of the same length as
Write Same (16). Even if the SCSI disk driver will only send one
descriptor, it should work as good as Write Same (16).

>
> Also, please be careful with transfer lengths, __data_len, etc. As
> mentioned, the transfer length WRITE SAME is typically 512 bytes and
> that's the number of bytes that need to be DMA'ed and transferred over
> the wire by the controller. But from a command completion perspective we
> need to complete however many bytes the command acted upon. Unlike reads
> and writes there is not a 1:1 mapping between the transfer length and
> the affected area. So we do a bit of magic after the buffer has been
> mapped to ensure that the completion byte count matches the number of
> blocks that were affected by the command rather than the size of the
> data buffer in bytes.
>
> --
> Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

[Tom Yan]

On 24 August 2016 at 11:33, Martin K. Petersen
 wrote:
>> "Tom" == Tom Yan  writes:
>
> Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI
> Tom> terms, parameter list / data-out buffer).
>
> WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we
> have had no good reason to support that yet).

Interesting, I wasn't aware of the bit. I just didn't see any
parameter list defined for any of the Write Same commands. Ah wait, it
carries the pattern (the "same") and so.

Hmm, it doesn't seem like the translation implemented in this patch
series cares about the payload though?

>
> UNMAP has a payload that varies based on the number of range
> descriptors. The SCSI disk driver only ever issues a single descriptor
> but since libata doesn't support UNMAP this doesn't really come into
> play.
>
> Ideally there would be a way to distinguish between device limits for
> WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to
> do that would be to transition the libata discard implementation over to
> single-range UNMAP, fill out the relevant VPD page B0 fields and leave
> the WRITE SAME bits for writing zeroes.
>
> One reason that has not been particularly compelling is that the WRITE
> SAME payload buffer does double duty to hold the ATA DSM TRIM range

Huh? Why would the SATL care about its payload buffer for TRIM (i.e.
when the UNMAP bit is set)? Doesn't it just read the LBA and NUMBER OF
BLOCKS field and pack TRIM ranges/payload according to that?

> descriptors and matches the required ATA payload size. Whereas the UNMAP

Why would it need to "matches the required ATA payload size"?

> command would only provide 24 bytes of TRIM range space.

I don't really follow. The UNMAP descriptor has LBA (8 bytes / 64-bit)
and NUMBER OF BLOCKS (4 bytes / 32-bit) field of the same length as
Write Same (16). Even if the SCSI disk driver will only send one
descriptor, it should work as good as Write Same (16).

>
> Also, please be careful with transfer lengths, __data_len, etc. As
> mentioned, the transfer length WRITE SAME is typically 512 bytes and
> that's the number of bytes that need to be DMA'ed and transferred over
> the wire by the controller. But from a command completion perspective we
> need to complete however many bytes the command acted upon. Unlike reads
> and writes there is not a 1:1 mapping between the transfer length and
> the affected area. So we do a bit of magic after the buffer has been
> mapped to ensure that the completion byte count matches the number of
> blocks that were affected by the command rather than the size of the
> data buffer in bytes.
>
> --
> Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] drm/gma500: remove unnecessary config_enabled() guard

[Daniel Vetter]

On Wed, Aug 24, 2016 at 01:42:54AM +0900, Masahiro Yamada wrote:
> Commit d112a8163f83 ("gma500/cdv: Add eDP support") replaced the
> code inside this if-conditional with gma_backlight_set(), which
> becomes a nop stub if CONFIG_BACKLIGHT_CLASS_DEVICE is disabled.
> So, there is no need to guard the caller with config_enabled().
> 
> Note:
> This is one of remaining TODOs to deprecate config_enabled() macro.
> Refer to commit 97f2645f358b ("tree-wide: replace config_enabled()
> with IS_ENABLED()").
> 
> Signed-off-by: Masahiro Yamada 

Applied to drm-misc, thanks.
-Daniel
> ---
> 
>  drivers/gpu/drm/gma500/opregion.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/opregion.c 
> b/drivers/gpu/drm/gma500/opregion.c
> index ab696ca..eab6d88 100644
> --- a/drivers/gpu/drm/gma500/opregion.c
> +++ b/drivers/gpu/drm/gma500/opregion.c
> @@ -163,10 +163,7 @@ static u32 asle_set_backlight(struct drm_device *dev, 
> u32 bclp)
>   if (bclp > 255)
>   return ASLE_BACKLIGHT_FAILED;
>  
> - if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
> - int max = bd->props.max_brightness;
> - gma_backlight_set(dev, bclp * max / 255);
> - }
> + gma_backlight_set(dev, bclp * bd->props.max_brightness / 255);
>  
>   asle->cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm/gma500: remove unnecessary config_enabled() guard

[Daniel Vetter]

On Wed, Aug 24, 2016 at 01:42:54AM +0900, Masahiro Yamada wrote:
> Commit d112a8163f83 ("gma500/cdv: Add eDP support") replaced the
> code inside this if-conditional with gma_backlight_set(), which
> becomes a nop stub if CONFIG_BACKLIGHT_CLASS_DEVICE is disabled.
> So, there is no need to guard the caller with config_enabled().
> 
> Note:
> This is one of remaining TODOs to deprecate config_enabled() macro.
> Refer to commit 97f2645f358b ("tree-wide: replace config_enabled()
> with IS_ENABLED()").
> 
> Signed-off-by: Masahiro Yamada 

Applied to drm-misc, thanks.
-Daniel
> ---
> 
>  drivers/gpu/drm/gma500/opregion.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/opregion.c 
> b/drivers/gpu/drm/gma500/opregion.c
> index ab696ca..eab6d88 100644
> --- a/drivers/gpu/drm/gma500/opregion.c
> +++ b/drivers/gpu/drm/gma500/opregion.c
> @@ -163,10 +163,7 @@ static u32 asle_set_backlight(struct drm_device *dev, 
> u32 bclp)
>   if (bclp > 255)
>   return ASLE_BACKLIGHT_FAILED;
>  
> - if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
> - int max = bd->props.max_brightness;
> - gma_backlight_set(dev, bclp * max / 255);
> - }
> + gma_backlight_set(dev, bclp * bd->props.max_brightness / 255);
>  
>   asle->cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v2 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

[Andrzej Hajda]

On 08/24/2016 04:25 AM, Milo Kim wrote:
> This patch enables getting a HPD GPIO descriptor quickly.
> The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
>
>   static int hdmi_resources_init(struct hdmi_context *hdata)
>   {
>   ...
>   hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
>   ...
>   }
>
> This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
> GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
>
> However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
> always retries to get a GPIO descriptor because the first GPIO suffix is not
> 'gpio' but 'gpios'. So you always see the debug message below.
>
>   of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node 
> '/soc/hdmi@1453[0]'
>
> Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
>
> Acked-by: Rob Herring 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
I am not sure if this long Cc list is necessary.
Anyway:

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

Re: [PATCH v2 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

[Andrzej Hajda]

On 08/24/2016 04:25 AM, Milo Kim wrote:
> This patch enables getting a HPD GPIO descriptor quickly.
> The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
>
>   static int hdmi_resources_init(struct hdmi_context *hdata)
>   {
>   ...
>   hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
>   ...
>   }
>
> This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
> GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
>
> However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
> always retries to get a GPIO descriptor because the first GPIO suffix is not
> 'gpio' but 'gpios'. So you always see the debug message below.
>
>   of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node 
> '/soc/hdmi@1453[0]'
>
> Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
>
> Acked-by: Rob Herring 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
I am not sure if this long Cc list is necessary.
Anyway:

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

Re: [PATCH v2 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board

[Andrzej Hajda]

Hi Milo,

On 08/24/2016 04:25 AM, Milo Kim wrote:
> * Support HDMI display data channel
>   I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> * GPIO for HDMI hot plug detect
>   GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
>   single ended.
>
> * Enable HDMI block in Exynos5420
>   HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
>   1.8V LDO7 (PVDD_ANAIP_1V8).
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..df362a2 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,23 @@
>   status = "disabled";
>  };
>  
> +_2 {
> + samsung,i2c-slave-addr = <0x50>;
> + status = "okay";
> +
> + hdmiddc@50 {
> + compatible = "samsung,exynos4210-hdmiddc";
> + reg = <0x50>;
> + };
> +};
> +
> + {
> + hpd-gpios = < 7 GPIO_OPEN_SOURCE>;
> + vdd_osc-supply = <_reg>;
> + vdd_pll-supply = <_reg>;
> + status = "okay";

Please use ddc property in hdmi node, instead of this legacy binding.
See exynos4210-universal_c210.dts or exynos4412-odroid-common.dtsi for
reference.

Regards
Andrzej

> +};
> +
>  _4 {
>   status = "okay";
>  

Re: [PATCH v2 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board

[Andrzej Hajda]

Hi Milo,

On 08/24/2016 04:25 AM, Milo Kim wrote:
> * Support HDMI display data channel
>   I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> * GPIO for HDMI hot plug detect
>   GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
>   single ended.
>
> * Enable HDMI block in Exynos5420
>   HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
>   1.8V LDO7 (PVDD_ANAIP_1V8).
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..df362a2 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,23 @@
>   status = "disabled";
>  };
>  
> +_2 {
> + samsung,i2c-slave-addr = <0x50>;
> + status = "okay";
> +
> + hdmiddc@50 {
> + compatible = "samsung,exynos4210-hdmiddc";
> + reg = <0x50>;
> + };
> +};
> +
> + {
> + hpd-gpios = < 7 GPIO_OPEN_SOURCE>;
> + vdd_osc-supply = <_reg>;
> + vdd_pll-supply = <_reg>;
> + status = "okay";

Please use ddc property in hdmi node, instead of this legacy binding.
See exynos4210-universal_c210.dts or exynos4412-odroid-common.dtsi for
reference.

Regards
Andrzej

> +};
> +
>  _4 {
>   status = "okay";
>  

Re: [PATCH v2 2/4] On Discard either do Reset WP or Write Same

[Shaun Tancheff]

On Mon, Aug 22, 2016 at 8:25 PM, Damien Le Moal  wrote:
>
> Shaun,
>
> On 8/23/16 09:22, Shaun Tancheff wrote:
>> On Mon, Aug 22, 2016 at 6:57 PM, Damien Le Moal  
>> wrote:

>> Also you may note that in my patch to get Host Aware working
>> with the zone cache I do not include the runt zone in the cache.
>
> Why not ? The RB-tree will handle it just fine (the insert and lookup
> code as Hannes had them was not relying on a constant zone size).

A good point. I didn't pay too much attention while brining this
forward. I think a few of my hacks may be pointless now. I'll
try to rework it and get rid of the runt check.

>> So as it sits I need this fallback otherwise doing blkdiscard over
>> the whole device ends in a error, as well as mkfs.f2fs et. al.
>
> Got it, but I do not see a problem with including it. I have not checked
> the code, but the split of a big discard call into "chunks" should be
> already handling the last chunk and make sure that the operation does
> not exceed the device capacity (in any case, that's easy to fix in the
> sd_zbc_setup_discard code).

Yes I agree the split of big discards does handle the last chunk correctly.

>>> Some 10TB host managed disks out there have 1% conventional zone space,
>>> that is 100GB of capacity. When issuing a "reset all", doing a write
>>> same in these zones will take forever... If the user really wants zeroes
>>> in those zones, let it issue a zeroout.
>>>
>>> I think that it would a better choice to simply not report
>>> discard_zeroes_data as true and do nothing for conventional zones reset.
>>
>> I think that would be unfortunate for Host Managed but I think it's
>> the right choice for Host Aware at this time. So either we base
>> it on disk type or we have some other config flag added to sysfs.
>
> I do not see any difference between host managed and host aware. Both
> define the same behavior for reset, and both end up in a NOP for
> conventional zone reset (no data "erasure" required by the standard).
> For write pointer zones, reading unwritten LBAs returns the
> initialization pattern, with the exception of host-managed disks with
> the URSWRZ bit set to 0. But that case is covered in sd.c, so the
> behavior is consistent across all models. So why forcing data zeroing
> when the standards do not mandate it ?

Well you do have point.
It appears to be only mkfs and similar tools that are really utilizing
discard zeros data at the moment.

I did a quick test:

mkfs -t ext4 -b 4096 -g 32768 -G 32  \
 -E 
lazy_itable_init=0,lazy_journal_init=0,offset=0,num_backup_sb=0,packed_meta_blocks=1,discard
  \
 -O flex_bg,extent,sparse_super2

   - discard zeroes data true - 3 minutess
   - discard zeroes data false - 6 minutes
So for the smaller conventional space on the current HA drive
there is some advantage to enabling discard zeroes data.

However for a larger conventional space you are correct the overall
impact is worse performance.

For some reason I had been assuming that some file systems
used or relied on discard zeroes data during normal operation.
Now that I am looking for that I don't seem to be finding any
evidence of it, so aside from mkfs I don't have as good an
argument discard zeroes data as I though I did.

Regards,
Shaun

Re: [PATCH v2 2/4] On Discard either do Reset WP or Write Same

[Shaun Tancheff]

On Mon, Aug 22, 2016 at 8:25 PM, Damien Le Moal  wrote:
>
> Shaun,
>
> On 8/23/16 09:22, Shaun Tancheff wrote:
>> On Mon, Aug 22, 2016 at 6:57 PM, Damien Le Moal  
>> wrote:

>> Also you may note that in my patch to get Host Aware working
>> with the zone cache I do not include the runt zone in the cache.
>
> Why not ? The RB-tree will handle it just fine (the insert and lookup
> code as Hannes had them was not relying on a constant zone size).

A good point. I didn't pay too much attention while brining this
forward. I think a few of my hacks may be pointless now. I'll
try to rework it and get rid of the runt check.

>> So as it sits I need this fallback otherwise doing blkdiscard over
>> the whole device ends in a error, as well as mkfs.f2fs et. al.
>
> Got it, but I do not see a problem with including it. I have not checked
> the code, but the split of a big discard call into "chunks" should be
> already handling the last chunk and make sure that the operation does
> not exceed the device capacity (in any case, that's easy to fix in the
> sd_zbc_setup_discard code).

Yes I agree the split of big discards does handle the last chunk correctly.

>>> Some 10TB host managed disks out there have 1% conventional zone space,
>>> that is 100GB of capacity. When issuing a "reset all", doing a write
>>> same in these zones will take forever... If the user really wants zeroes
>>> in those zones, let it issue a zeroout.
>>>
>>> I think that it would a better choice to simply not report
>>> discard_zeroes_data as true and do nothing for conventional zones reset.
>>
>> I think that would be unfortunate for Host Managed but I think it's
>> the right choice for Host Aware at this time. So either we base
>> it on disk type or we have some other config flag added to sysfs.
>
> I do not see any difference between host managed and host aware. Both
> define the same behavior for reset, and both end up in a NOP for
> conventional zone reset (no data "erasure" required by the standard).
> For write pointer zones, reading unwritten LBAs returns the
> initialization pattern, with the exception of host-managed disks with
> the URSWRZ bit set to 0. But that case is covered in sd.c, so the
> behavior is consistent across all models. So why forcing data zeroing
> when the standards do not mandate it ?

Well you do have point.
It appears to be only mkfs and similar tools that are really utilizing
discard zeros data at the moment.

I did a quick test:

mkfs -t ext4 -b 4096 -g 32768 -G 32  \
 -E 
lazy_itable_init=0,lazy_journal_init=0,offset=0,num_backup_sb=0,packed_meta_blocks=1,discard
  \
 -O flex_bg,extent,sparse_super2

   - discard zeroes data true - 3 minutess
   - discard zeroes data false - 6 minutes
So for the smaller conventional space on the current HA drive
there is some advantage to enabling discard zeroes data.

However for a larger conventional space you are correct the overall
impact is worse performance.

For some reason I had been assuming that some file systems
used or relied on discard zeroes data during normal operation.
Now that I am looking for that I don't seem to be finding any
evidence of it, so aside from mkfs I don't have as good an
argument discard zeroes data as I though I did.

Regards,
Shaun

Re: [PATCH v3] PM / sleep: enable suspend-to-idle even without registered suspend_ops

[Andy Gross]

On 19 August 2016 at 08:41, Sudeep Holla  wrote:
> Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
> in which all of the processors enter deepest possible idle state and
> wait for interrupts right after suspending all the devices.
>
> There is no hard requirement for a platform to support and register
> platform specific suspend_ops to enter suspend-to-idle/freeze state.
> Only deeper system sleep states like PM_SUSPEND_STANDBY and
> PM_SUSPEND_MEM rely on such low level support/implementation.
>
> suspend-to-idle can be entered as along as all the devices can be
> suspended. This patch enables the support for suspend-to-idle even on
> systems that don't have any low level support for deeper system sleep
> states and/or don't register any platform specific suspend_ops.
>
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Sudeep Holla 

I tested this patch on the Qualcomm 410c platform.  It worked like a
charm.  Thanks for working on this!

Tested-by: Andy Gross 

Re: [PATCH v3] PM / sleep: enable suspend-to-idle even without registered suspend_ops

[Andy Gross]

On 19 August 2016 at 08:41, Sudeep Holla  wrote:
> Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
> in which all of the processors enter deepest possible idle state and
> wait for interrupts right after suspending all the devices.
>
> There is no hard requirement for a platform to support and register
> platform specific suspend_ops to enter suspend-to-idle/freeze state.
> Only deeper system sleep states like PM_SUSPEND_STANDBY and
> PM_SUSPEND_MEM rely on such low level support/implementation.
>
> suspend-to-idle can be entered as along as all the devices can be
> suspended. This patch enables the support for suspend-to-idle even on
> systems that don't have any low level support for deeper system sleep
> states and/or don't register any platform specific suspend_ops.
>
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Sudeep Holla 

I tested this patch on the Qualcomm 410c platform.  It worked like a
charm.  Thanks for working on this!

Tested-by: Andy Gross 

[v14 PATCH 4/5] Documentation: bindings: add dt documentation for cdn DP controller

[Chris Zhong]

This patch adds a binding that describes the cdn DP controller for
rk3399.

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 
Reviewed-by: Guenter Roeck 

---

Changes in v14: None
Changes in v13:
- add dptx and apb reset

Changes in v12: None
Changes in v11:
- refer dp phy

Changes in v10:
- add pclk_vio_grf clock

Changes in v9:
- modify the reference phy = < 0>, < 0>;

Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates
- add power-domains

Changes in v5: None
Changes in v4:
- add a reset node
- support 2 phys

Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;

Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description

 .../bindings/display/rockchip/cdn-dp-rockchip.txt  | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
new file mode 100644
index 000..9bd2c13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
@@ -0,0 +1,75 @@
+Rockchip RK3399 specific extensions to the cdn Display Port
+
+
+Required properties:
+- compatible: must be "rockchip,rk3399-cdn-dp"
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+
+- clock-names: from common clock binding:
+  Required elements: "core-clk" "pclk" "spdif" "grf"
+
+- resets : a list of phandle + reset specifier pairs
+- reset-names : string reset name, must be:
+   "spdif", "dptx", "apb".
+- power-domains : power-domain property defined with a phandle
+ to respective power domain.
+- assigned-clocks: main clock, should be < SCLK_DP_CORE>
+- assigned-clock-rates : the DP core clk frequency, shall be: 1
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port nodes with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+contained 2 endpoints, connecting to the output of vop.
+
+- phys: from general PHY binding: the phandle for the PHY device.
+
+- extcon: extcon specifier for the Power Delivery
+
+- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
+
+---
+
+Example:
+   cdn_dp: dp@fec0 {
+   compatible = "rockchip,rk3399-cdn-dp";
+   reg = <0x0 0xfec0 0x0 0x10>;
+   interrupts = ;
+   clocks = < SCLK_DP_CORE>, < PCLK_DP_CTRL>,
+< SCLK_SPDIF_REC_DPTX>, < PCLK_VIO_GRF>;
+   clock-names = "core-clk", "pclk", "spdif", "grf";
+   assigned-clocks = < SCLK_DP_CORE>;
+   assigned-clock-rates = <1>;
+   power-domains = < RK3399_PD_HDCP>;
+   phys = <_dp>, <_dp>;
+   resets = < SRST_DPTX_SPDIF_REC>, < SRST_P_UPHY0_DPTX>,
+< SRST_P_UPHY0_APB>;
+   reset-names = "spdif", "dptx", "apb";
+   extcon = <>, <>;
+   rockchip,grf = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dp_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dp_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_dp>;
+   };
+
+   dp_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_dp>;
+   };
+   };
+   };
+   };
-- 
1.9.1

[v14 PATCH 1/5] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY

[Chris Zhong]

This patch adds a binding that describes the Rockchip USB Type-C PHY
for rk3399

Signed-off-by: Chris Zhong 
Reviewed-by: Tomasz Figa 
Reviewed-by: Kever Yang 
Reviewed-by: Guenter Roeck 
Acked-by: Rob Herring 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- make a clearer emarcation between usb phy and dp phy

Changes in v10:
- remove rockchip,uphy-dp-sel property

Changes in v9:
- change #phy-cells to 1

Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates

Changes in v5: None
Changes in v4:
- add a #phy-cells node

Changes in v3:
- use compatible: rockchip,rk3399-typec-phy
- use dashes instead of underscores.

Changes in v2:
- add some registers description

Changes in v1:
- add extcon node description
- move the registers in phy driver
- remove the suffix of reset

 .../devicetree/bindings/phy/phy-rockchip-typec.txt | 101 +
 1 file changed, 101 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
new file mode 100644
index 000..6ea867e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -0,0 +1,101 @@
+* ROCKCHIP type-c PHY
+-
+
+Required properties:
+ - compatible : must be "rockchip,rk3399-typec-phy"
+ - reg: Address and length of the usb phy control register set
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files"
+ - clocks : phandle + clock specifier for the phy clocks
+ - clock-names : string, clock name, must be "tcpdcore", "tcpdphy-ref";
+ - assigned-clocks: main clock, should be < SCLK_UPHY0_TCPDCORE> or
+   < SCLK_UPHY1_TCPDCORE>;
+ - assigned-clock-rates : the phy core clk frequency, shall be: 5000
+ - resets : a list of phandle + reset specifier pairs
+ - reset-names : string reset name, must be:
+"uphy", "uphy-pipe", "uphy-tcphy"
+ - extcon : extcon specifier for the Power Delivery
+
+Note, there are 2 type-c phys for RK3399, and they are almost identical, except
+these registers(description below), every register node contains 3 sections:
+offset, enable bit, write mask bit.
+ - rockchip,typec-conn-dir : the register of type-c connector direction,
+   for type-c phy0, it must be <0xe580 0 16>;
+   for type-c phy1, it must be <0xe58c 0 16>;
+ - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable
+   control.
+   for type-c phy0, it must be <0xe580 3 19>;
+   for type-c phy1, it must be <0xe58c 3 19>;
+ - rockchip,external-psm : the register of type-c phy external psm clock
+   selection.
+   for type-c phy0, it must be <0xe588 14 30>;
+   for type-c phy1, it must be <0xe594 14 30>;
+ - rockchip,pipe-status : the register of type-c phy pipe status.
+   for type-c phy0, it must be <0xe5c0 0 0>;
+   for type-c phy1, it must be <0xe5c0 16 16>;
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify dp or usb3 port,
+and shall be the following entries:
+   * "dp-port" : the name of DP port.
+   * "usb3-port" : the name of USB3 port.
+
+Required properties (port (child) node):
+- #phy-cells : must be 0, See ./phy-bindings.txt for details.
+
+Example:
+   tcphy0: phy@ff7c {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff7c 0x0 0x4>;
+   rockchip,grf = <>;
+   extcon = <>;
+   clocks = < SCLK_UPHY0_TCPDCORE>,
+< SCLK_UPHY0_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY0_TCPDCORE>;
+   assigned-clock-rates = <5000>;
+   resets = < SRST_UPHY0>,
+< SRST_UPHY0_PIPE_L00>,
+< SRST_P_UPHY0_TCPHY>;
+   reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+   rockchip,typec-conn-dir = <0xe580 0 16>;
+   rockchip,usb3tousb2-en = <0xe580 3 19>;
+   rockchip,external-psm = <0xe588 14 30>;
+   rockchip,pipe-status = <0xe5c0 0 0>;
+
+   tcphy0_dp: dp-port {
+   #phy-cells = <0>;
+   };
+
+   tcphy0_usb3: usb3-port {
+   #phy-cells = <0>;
+   };
+   };
+
+   tcphy1: phy@ff80 {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff80 0x0 0x4>;
+   rockchip,grf = <>;
+   extcon = <>;
+   clocks = < SCLK_UPHY1_TCPDCORE>,
+< SCLK_UPHY1_TCPDPHY_REF>;
+   clock-names = 

[v14 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications.
The USB3 operates in SuperSpeed mode and the DP can operate at RBR,
HBR and HBR2 data rates. This driver create 2 PHY devices separately
for USB3 and DisplyPort, and registers them under the child node.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 

---

Changes in v14:
- change the name of property from super speed to EXTCON_PROP_USB_SS

Changes in v13:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration
- do not return err if nothing connected with Type-C, when usb phy power on,
  since the USB core driver will call phy power without USB3 device connected.

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
  and DP is attached

Changes in v11:
- make a clearer demarcation between usb phy and dp phy.

Changes in v10:
- do not control dp select and hpd config in phy driver

Changes in v9:
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log

Changes in v7:
- support new API of extcon

Changes in v6:
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support

Changes in v4:
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

 drivers/phy/Kconfig  |9 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-typec.c | 1013 ++
 3 files changed, 1023 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 42f3e30..c775fd7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -348,6 +348,15 @@ config PHY_ROCKCHIP_PCIE
help
  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_TYPEC
+   tristate "Rockchip TYPEC PHY Driver"
+   depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
+   select EXTCON
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index fbb91e7..5d58b63 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)  += 
phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..fb58a27
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,1013 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ * Kever Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as 

[v14 PATCH 4/5] Documentation: bindings: add dt documentation for cdn DP controller

[Chris Zhong]

This patch adds a binding that describes the cdn DP controller for
rk3399.

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 
Reviewed-by: Guenter Roeck 

---

Changes in v14: None
Changes in v13:
- add dptx and apb reset

Changes in v12: None
Changes in v11:
- refer dp phy

Changes in v10:
- add pclk_vio_grf clock

Changes in v9:
- modify the reference phy = < 0>, < 0>;

Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates
- add power-domains

Changes in v5: None
Changes in v4:
- add a reset node
- support 2 phys

Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;

Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description

 .../bindings/display/rockchip/cdn-dp-rockchip.txt  | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
new file mode 100644
index 000..9bd2c13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
@@ -0,0 +1,75 @@
+Rockchip RK3399 specific extensions to the cdn Display Port
+
+
+Required properties:
+- compatible: must be "rockchip,rk3399-cdn-dp"
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+
+- clock-names: from common clock binding:
+  Required elements: "core-clk" "pclk" "spdif" "grf"
+
+- resets : a list of phandle + reset specifier pairs
+- reset-names : string reset name, must be:
+   "spdif", "dptx", "apb".
+- power-domains : power-domain property defined with a phandle
+ to respective power domain.
+- assigned-clocks: main clock, should be < SCLK_DP_CORE>
+- assigned-clock-rates : the DP core clk frequency, shall be: 1
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port nodes with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+contained 2 endpoints, connecting to the output of vop.
+
+- phys: from general PHY binding: the phandle for the PHY device.
+
+- extcon: extcon specifier for the Power Delivery
+
+- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
+
+---
+
+Example:
+   cdn_dp: dp@fec0 {
+   compatible = "rockchip,rk3399-cdn-dp";
+   reg = <0x0 0xfec0 0x0 0x10>;
+   interrupts = ;
+   clocks = < SCLK_DP_CORE>, < PCLK_DP_CTRL>,
+< SCLK_SPDIF_REC_DPTX>, < PCLK_VIO_GRF>;
+   clock-names = "core-clk", "pclk", "spdif", "grf";
+   assigned-clocks = < SCLK_DP_CORE>;
+   assigned-clock-rates = <1>;
+   power-domains = < RK3399_PD_HDCP>;
+   phys = <_dp>, <_dp>;
+   resets = < SRST_DPTX_SPDIF_REC>, < SRST_P_UPHY0_DPTX>,
+< SRST_P_UPHY0_APB>;
+   reset-names = "spdif", "dptx", "apb";
+   extcon = <>, <>;
+   rockchip,grf = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #sound-dai-cells = <1>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dp_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dp_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_dp>;
+   };
+
+   dp_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_dp>;
+   };
+   };
+   };
+   };
-- 
1.9.1

[v14 PATCH 1/5] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY

[Chris Zhong]

This patch adds a binding that describes the Rockchip USB Type-C PHY
for rk3399

Signed-off-by: Chris Zhong 
Reviewed-by: Tomasz Figa 
Reviewed-by: Kever Yang 
Reviewed-by: Guenter Roeck 
Acked-by: Rob Herring 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- make a clearer emarcation between usb phy and dp phy

Changes in v10:
- remove rockchip,uphy-dp-sel property

Changes in v9:
- change #phy-cells to 1

Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates

Changes in v5: None
Changes in v4:
- add a #phy-cells node

Changes in v3:
- use compatible: rockchip,rk3399-typec-phy
- use dashes instead of underscores.

Changes in v2:
- add some registers description

Changes in v1:
- add extcon node description
- move the registers in phy driver
- remove the suffix of reset

 .../devicetree/bindings/phy/phy-rockchip-typec.txt | 101 +
 1 file changed, 101 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
new file mode 100644
index 000..6ea867e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -0,0 +1,101 @@
+* ROCKCHIP type-c PHY
+-
+
+Required properties:
+ - compatible : must be "rockchip,rk3399-typec-phy"
+ - reg: Address and length of the usb phy control register set
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files"
+ - clocks : phandle + clock specifier for the phy clocks
+ - clock-names : string, clock name, must be "tcpdcore", "tcpdphy-ref";
+ - assigned-clocks: main clock, should be < SCLK_UPHY0_TCPDCORE> or
+   < SCLK_UPHY1_TCPDCORE>;
+ - assigned-clock-rates : the phy core clk frequency, shall be: 5000
+ - resets : a list of phandle + reset specifier pairs
+ - reset-names : string reset name, must be:
+"uphy", "uphy-pipe", "uphy-tcphy"
+ - extcon : extcon specifier for the Power Delivery
+
+Note, there are 2 type-c phys for RK3399, and they are almost identical, except
+these registers(description below), every register node contains 3 sections:
+offset, enable bit, write mask bit.
+ - rockchip,typec-conn-dir : the register of type-c connector direction,
+   for type-c phy0, it must be <0xe580 0 16>;
+   for type-c phy1, it must be <0xe58c 0 16>;
+ - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable
+   control.
+   for type-c phy0, it must be <0xe580 3 19>;
+   for type-c phy1, it must be <0xe58c 3 19>;
+ - rockchip,external-psm : the register of type-c phy external psm clock
+   selection.
+   for type-c phy0, it must be <0xe588 14 30>;
+   for type-c phy1, it must be <0xe594 14 30>;
+ - rockchip,pipe-status : the register of type-c phy pipe status.
+   for type-c phy0, it must be <0xe5c0 0 0>;
+   for type-c phy1, it must be <0xe5c0 16 16>;
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify dp or usb3 port,
+and shall be the following entries:
+   * "dp-port" : the name of DP port.
+   * "usb3-port" : the name of USB3 port.
+
+Required properties (port (child) node):
+- #phy-cells : must be 0, See ./phy-bindings.txt for details.
+
+Example:
+   tcphy0: phy@ff7c {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff7c 0x0 0x4>;
+   rockchip,grf = <>;
+   extcon = <>;
+   clocks = < SCLK_UPHY0_TCPDCORE>,
+< SCLK_UPHY0_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY0_TCPDCORE>;
+   assigned-clock-rates = <5000>;
+   resets = < SRST_UPHY0>,
+< SRST_UPHY0_PIPE_L00>,
+< SRST_P_UPHY0_TCPHY>;
+   reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+   rockchip,typec-conn-dir = <0xe580 0 16>;
+   rockchip,usb3tousb2-en = <0xe580 3 19>;
+   rockchip,external-psm = <0xe588 14 30>;
+   rockchip,pipe-status = <0xe5c0 0 0>;
+
+   tcphy0_dp: dp-port {
+   #phy-cells = <0>;
+   };
+
+   tcphy0_usb3: usb3-port {
+   #phy-cells = <0>;
+   };
+   };
+
+   tcphy1: phy@ff80 {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff80 0x0 0x4>;
+   rockchip,grf = <>;
+   extcon = <>;
+   clocks = < SCLK_UPHY1_TCPDCORE>,
+< SCLK_UPHY1_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY1_TCPDCORE>;
+   

[v14 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications.
The USB3 operates in SuperSpeed mode and the DP can operate at RBR,
HBR and HBR2 data rates. This driver create 2 PHY devices separately
for USB3 and DisplyPort, and registers them under the child node.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 

---

Changes in v14:
- change the name of property from super speed to EXTCON_PROP_USB_SS

Changes in v13:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration
- do not return err if nothing connected with Type-C, when usb phy power on,
  since the USB core driver will call phy power without USB3 device connected.

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
  and DP is attached

Changes in v11:
- make a clearer demarcation between usb phy and dp phy.

Changes in v10:
- do not control dp select and hpd config in phy driver

Changes in v9:
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log

Changes in v7:
- support new API of extcon

Changes in v6:
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support

Changes in v4:
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

 drivers/phy/Kconfig  |9 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-typec.c | 1013 ++
 3 files changed, 1023 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 42f3e30..c775fd7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -348,6 +348,15 @@ config PHY_ROCKCHIP_PCIE
help
  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_TYPEC
+   tristate "Rockchip TYPEC PHY Driver"
+   depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
+   select EXTCON
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index fbb91e7..5d58b63 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)  += 
phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
new file mode 100644
index 000..fb58a27
--- /dev/null
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -0,0 +1,1013 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ * Kever Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed 

[v14 PATCH 3/5] arm64: dts: rockchip: add Type-C phy for RK3399

[Chris Zhong]

There are 2 Type-C phy on RK3399, they are almost same, except the
address of register. They support USB3.0 Type-C and DisplayPort1.3
Alt Mode on USB Type-C. Register a phy, supply it to USB3 controller
and DP controller.

Signed-off-by: Chris Zhong 
Reviewed-by: Guenter Roeck 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- split the dp-phy and usb3-phy to 2 child-node

Changes in v10:
- remove rockchip,uphy-dp-sel property

Changes in v9:
- change #phy-cells to 1

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 56 
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a44eb67..23f7ae1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1060,6 +1060,62 @@
};
};
 
+   tcphy0: phy@ff7c {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff7c 0x0 0x4>;
+   rockchip,grf = <>;
+   clocks = < SCLK_UPHY0_TCPDCORE>,
+< SCLK_UPHY0_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY0_TCPDCORE>;
+   assigned-clock-rates = <5000>;
+   resets = < SRST_UPHY0>,
+< SRST_UPHY0_PIPE_L00>,
+< SRST_P_UPHY0_TCPHY>;
+   reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+   rockchip,typec-conn-dir = <0xe580 0 16>;
+   rockchip,usb3tousb2-en = <0xe580 3 19>;
+   rockchip,external-psm = <0xe588 14 30>;
+   rockchip,pipe-status = <0xe5c0 0 0>;
+   status = "disabled";
+
+   tcphy0_dp: dp-port {
+   #phy-cells = <0>;
+   };
+
+   tcphy0_usb3: usb3-port {
+   #phy-cells = <0>;
+   };
+   };
+
+   tcphy1: phy@ff80 {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff80 0x0 0x4>;
+   rockchip,grf = <>;
+   clocks = < SCLK_UPHY1_TCPDCORE>,
+< SCLK_UPHY1_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY1_TCPDCORE>;
+   assigned-clock-rates = <5000>;
+   resets = < SRST_UPHY1>,
+< SRST_UPHY1_PIPE_L00>,
+< SRST_P_UPHY1_TCPHY>;
+   reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+   rockchip,typec-conn-dir = <0xe58c 0 16>;
+   rockchip,usb3tousb2-en = <0xe58c 3 19>;
+   rockchip,external-psm = <0xe594 14 30>;
+   rockchip,pipe-status = <0xe5c0 16 16>;
+   status = "disabled";
+
+   tcphy1_dp: dp-port {
+   #phy-cells = <0>;
+   };
+
+   tcphy1_usb3: usb3-port {
+   #phy-cells = <0>;
+   };
+   };
+
watchdog@ff84 {
compatible = "snps,dw-wdt";
reg = <0x0 0xff84 0x0 0x100>;
-- 
1.9.1

[v14 PATCH 0/5] Rockchip Type-C and DisplayPort driver

[Chris Zhong]

Hi all

This series patch is for rockchip Type-C phy and DisplayPort controller
driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file[0] rockchip/dptx.bin to
/lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication
and link training, the host use mailbox to communicate with the ucpu.

The DP contoller has register a notification with extcon API, to get the
alt mode from PD, the PD driver need call the devm_extcon_dev_allocate
to create a extcon device and use extcon_set_state to notify DP
controller. And call extcon_set_cable_property to set orientation.

About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF.
We can reference them in simple-card.

This series is based on Mark Yao's branch[1], the extcon API backport
from linux-next[2].

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.

>From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY
will be init, no matter which PHY be power_on. The DP module will
enter A2 mode (standby mode) after phy_init, if DP PHY is powered on,
the DP module will enter to A0 mode(running mode). Then if DP PHY is
powered off, DP module will back to A2 mode. If everything is
un-plugged, phy will be deinit.

[0]
kernel/git/firmware/linux-firmware.git
[1]
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23
[2]
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master


Changes in v14:
- change the name of property from super speed to EXTCON_PROP_USB_SS
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration
- do not return err if nothing connected with Type-C, when usb phy power on,
  since the USB core driver will call phy power without USB3 device connected.
- add dptx and apb reset
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
  and DP is attached
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- make a clearer emarcation between usb phy and dp phy
- make a clearer demarcation between usb phy and dp phy.
- split the dp-phy and usb3-phy to 2 child-node
- refer dp phy
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove rockchip,uphy-dp-sel property
- do not control dp select and hpd config in phy driver
- remove rockchip,uphy-dp-sel property
- add pclk_vio_grf clock
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- change #phy-cells to 1
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP
- change #phy-cells to 1
- modify the reference phy = < 0>, < 0>;
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log
- optimization the err log

Changes in v7:
- support new API of extcon
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add assigned-clocks and assigned-clock-rates
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode
- add assigned-clocks and assigned-clock-rates
- add power-domains
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- add a #phy-cells node
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_
- add a reset node
- support 2 phys
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use compatible: rockchip,rk3399-typec-phy

[v14 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
Acked-by: Mark Yao 

---

Changes in v14:
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1067 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  106 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  959 
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  482 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 9 files changed, 2646 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20aaafe 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.
 
+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+   select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..6a07809 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..f8bdfd1
--- 

[v14 PATCH 3/5] arm64: dts: rockchip: add Type-C phy for RK3399

[Chris Zhong]

There are 2 Type-C phy on RK3399, they are almost same, except the
address of register. They support USB3.0 Type-C and DisplayPort1.3
Alt Mode on USB Type-C. Register a phy, supply it to USB3 controller
and DP controller.

Signed-off-by: Chris Zhong 
Reviewed-by: Guenter Roeck 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- split the dp-phy and usb3-phy to 2 child-node

Changes in v10:
- remove rockchip,uphy-dp-sel property

Changes in v9:
- change #phy-cells to 1

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 56 
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a44eb67..23f7ae1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1060,6 +1060,62 @@
};
};
 
+   tcphy0: phy@ff7c {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff7c 0x0 0x4>;
+   rockchip,grf = <>;
+   clocks = < SCLK_UPHY0_TCPDCORE>,
+< SCLK_UPHY0_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY0_TCPDCORE>;
+   assigned-clock-rates = <5000>;
+   resets = < SRST_UPHY0>,
+< SRST_UPHY0_PIPE_L00>,
+< SRST_P_UPHY0_TCPHY>;
+   reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+   rockchip,typec-conn-dir = <0xe580 0 16>;
+   rockchip,usb3tousb2-en = <0xe580 3 19>;
+   rockchip,external-psm = <0xe588 14 30>;
+   rockchip,pipe-status = <0xe5c0 0 0>;
+   status = "disabled";
+
+   tcphy0_dp: dp-port {
+   #phy-cells = <0>;
+   };
+
+   tcphy0_usb3: usb3-port {
+   #phy-cells = <0>;
+   };
+   };
+
+   tcphy1: phy@ff80 {
+   compatible = "rockchip,rk3399-typec-phy";
+   reg = <0x0 0xff80 0x0 0x4>;
+   rockchip,grf = <>;
+   clocks = < SCLK_UPHY1_TCPDCORE>,
+< SCLK_UPHY1_TCPDPHY_REF>;
+   clock-names = "tcpdcore", "tcpdphy-ref";
+   assigned-clocks = < SCLK_UPHY1_TCPDCORE>;
+   assigned-clock-rates = <5000>;
+   resets = < SRST_UPHY1>,
+< SRST_UPHY1_PIPE_L00>,
+< SRST_P_UPHY1_TCPHY>;
+   reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+   rockchip,typec-conn-dir = <0xe58c 0 16>;
+   rockchip,usb3tousb2-en = <0xe58c 3 19>;
+   rockchip,external-psm = <0xe594 14 30>;
+   rockchip,pipe-status = <0xe5c0 16 16>;
+   status = "disabled";
+
+   tcphy1_dp: dp-port {
+   #phy-cells = <0>;
+   };
+
+   tcphy1_usb3: usb3-port {
+   #phy-cells = <0>;
+   };
+   };
+
watchdog@ff84 {
compatible = "snps,dw-wdt";
reg = <0x0 0xff84 0x0 0x100>;
-- 
1.9.1

[v14 PATCH 0/5] Rockchip Type-C and DisplayPort driver

[Chris Zhong]

Hi all

This series patch is for rockchip Type-C phy and DisplayPort controller
driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file[0] rockchip/dptx.bin to
/lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication
and link training, the host use mailbox to communicate with the ucpu.

The DP contoller has register a notification with extcon API, to get the
alt mode from PD, the PD driver need call the devm_extcon_dev_allocate
to create a extcon device and use extcon_set_state to notify DP
controller. And call extcon_set_cable_property to set orientation.

About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF.
We can reference them in simple-card.

This series is based on Mark Yao's branch[1], the extcon API backport
from linux-next[2].

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.

>From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY
will be init, no matter which PHY be power_on. The DP module will
enter A2 mode (standby mode) after phy_init, if DP PHY is powered on,
the DP module will enter to A0 mode(running mode). Then if DP PHY is
powered off, DP module will back to A2 mode. If everything is
un-plugged, phy will be deinit.

[0]
kernel/git/firmware/linux-firmware.git
[1]
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23
[2]
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master


Changes in v14:
- change the name of property from super speed to EXTCON_PROP_USB_SS
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration
- do not return err if nothing connected with Type-C, when usb phy power on,
  since the USB core driver will call phy power without USB3 device connected.
- add dptx and apb reset
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
  and DP is attached
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- make a clearer emarcation between usb phy and dp phy
- make a clearer demarcation between usb phy and dp phy.
- split the dp-phy and usb3-phy to 2 child-node
- refer dp phy
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove rockchip,uphy-dp-sel property
- do not control dp select and hpd config in phy driver
- remove rockchip,uphy-dp-sel property
- add pclk_vio_grf clock
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- change #phy-cells to 1
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
  rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP
- change #phy-cells to 1
- modify the reference phy = < 0>, < 0>;
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log
- optimization the err log

Changes in v7:
- support new API of extcon
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add assigned-clocks and assigned-clock-rates
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode
- add assigned-clocks and assigned-clock-rates
- add power-domains
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- add a #phy-cells node
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_
- add a reset node
- support 2 phys
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use compatible: rockchip,rk3399-typec-phy

[v14 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
Acked-by: Mark Yao 

---

Changes in v14:
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1067 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  106 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  959 
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  482 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 9 files changed, 2646 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20aaafe 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.
 
+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+   select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..6a07809 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..f8bdfd1
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,1067 @@

Re: [PATCH 2/8] staging/lustre/mdc: fix panic at mdc_free_open()

[Oleg Drokin]

Actually, please do not apply this one, there was a testing error
that made me not noticing there's a bug in this one that insta-crashes 
everything on access.

I tested the rest nd the rest are good without this one too.

Sorry about this.

On Aug 23, 2016, at 5:11 PM, Oleg Drokin wrote:

> From: Alexander Boyko 
> 
> Assertion was happened for open request when rq_replay is set
> to 1.
>ASSERTION(mod->mod_open_req->rq_replay == 0)
> But this situation is not fatal for client, and could happened
> when mdc_close() failed.
> The fix allow to free such requests. If mdc_close fail, MDS doesn`t
> receive close request from client. And in a worst case client would
> be evicted.
> 
> The test recreates issue when mdc_close failed and
> client asserts:
>   ASSERTION( mod->mod_open_req->rq_replay == 0 ) failed
> 
> Signed-off-by: Alexander Boyko 
> Seagate-bug-id: MRP-3156
> Reviewed-on: http://review.whamcloud.com/17495
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5282
> Reviewed-by: Alex Zhuravlev 
> Reviewed-by: Andreas Dilger 
> Signed-off-by: Oleg Drokin 
> ---
> .../staging/lustre/lustre/include/obd_support.h|  1 +
> drivers/staging/lustre/lustre/mdc/mdc_request.c| 50 ++
> 2 files changed, 32 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_support.h 
> b/drivers/staging/lustre/lustre/include/obd_support.h
> index 0c29a33..4a9fe88 100644
> --- a/drivers/staging/lustre/lustre/include/obd_support.h
> +++ b/drivers/staging/lustre/lustre/include/obd_support.h
> @@ -402,6 +402,7 @@ extern char obd_jobid_var[];
> #define OBD_FAIL_MDC_GETATTR_ENQUEUE 0x803
> #define OBD_FAIL_MDC_RPCS_SEM  0x804
> #define OBD_FAIL_MDC_LIGHTWEIGHT   0x805
> +#define OBD_FAIL_MDC_CLOSE0x806
> 
> #define OBD_FAIL_MGS   0x900
> #define OBD_FAIL_MGS_ALL_REQUEST_NET 0x901
> diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
> b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> index 91c0b45..8369afd 100644
> --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
> +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> @@ -677,9 +677,15 @@ static void mdc_free_open(struct md_open_data *mod)
>   imp_connect_disp_stripe(mod->mod_open_req->rq_import))
>   committed = 1;
> 
> - LASSERT(mod->mod_open_req->rq_replay == 0);
> -
> - DEBUG_REQ(D_RPCTRACE, mod->mod_open_req, "free open request\n");
> + /*
> +  * No reason to asssert here if the open request has
> +  * rq_replay == 1. It means that mdc_close failed, and
> +  * close request wasn`t sent. It is not fatal to client.
> +  * The worst thing is eviction if the client gets open lock
> +  */
> + DEBUG_REQ(D_RPCTRACE, mod->mod_open_req,
> +   "free open request rq_replay = %d\n",
> +mod->mod_open_req->rq_replay);
> 
>   ptlrpc_request_committed(mod->mod_open_req, committed);
>   if (mod->mod_close_req)
> @@ -749,22 +755,10 @@ static int mdc_close(struct obd_export *exp, struct 
> md_op_data *op_data,
>   }
> 
>   *request = NULL;
> - req = ptlrpc_request_alloc(class_exp2cliimp(exp), req_fmt);
> - if (!req)
> - return -ENOMEM;
> -
> - rc = ptlrpc_request_pack(req, LUSTRE_MDS_VERSION, MDS_CLOSE);
> - if (rc) {
> - ptlrpc_request_free(req);
> - return rc;
> - }
> -
> - /* To avoid a livelock (bug 7034), we need to send CLOSE RPCs to a
> -  * portal whose threads are not taking any DLM locks and are therefore
> -  * always progressing
> -  */
> - req->rq_request_portal = MDS_READPAGE_PORTAL;
> - ptlrpc_at_set_req_timeout(req);
> + if (OBD_FAIL_CHECK(OBD_FAIL_MDC_CLOSE))
> + req = NULL;
> + else
> + req = ptlrpc_request_alloc(class_exp2cliimp(exp), req_fmt);
> 
>   /* Ensure that this close's handle is fixed up during replay. */
>   if (likely(mod)) {
> @@ -785,6 +779,23 @@ static int mdc_close(struct obd_export *exp, struct 
> md_op_data *op_data,
>CDEBUG(D_HA,
>   "couldn't find open req; expecting close error\n");
>   }
> + if (!req) {
> + /*
> +  * TODO: repeat close after errors
> +  */
> + CWARN("%s: close of FID "DFID" failed, file reference will be 
> dropped when this client unmounts or is evicted\n",
> +   obd->obd_name, PFID(_data->op_fid1));
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + /*
> +  * To avoid a livelock (bug 7034), we need to send CLOSE RPCs to a
> +  * portal whose threads are not taking any DLM locks and are therefore
> +  * always progressing
> +  */
> + req->rq_request_portal = MDS_READPAGE_PORTAL;
> + 

Re: [PATCH 2/8] staging/lustre/mdc: fix panic at mdc_free_open()

[Oleg Drokin]

Actually, please do not apply this one, there was a testing error
that made me not noticing there's a bug in this one that insta-crashes 
everything on access.

I tested the rest nd the rest are good without this one too.

Sorry about this.

On Aug 23, 2016, at 5:11 PM, Oleg Drokin wrote:

> From: Alexander Boyko 
> 
> Assertion was happened for open request when rq_replay is set
> to 1.
>ASSERTION(mod->mod_open_req->rq_replay == 0)
> But this situation is not fatal for client, and could happened
> when mdc_close() failed.
> The fix allow to free such requests. If mdc_close fail, MDS doesn`t
> receive close request from client. And in a worst case client would
> be evicted.
> 
> The test recreates issue when mdc_close failed and
> client asserts:
>   ASSERTION( mod->mod_open_req->rq_replay == 0 ) failed
> 
> Signed-off-by: Alexander Boyko 
> Seagate-bug-id: MRP-3156
> Reviewed-on: http://review.whamcloud.com/17495
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5282
> Reviewed-by: Alex Zhuravlev 
> Reviewed-by: Andreas Dilger 
> Signed-off-by: Oleg Drokin 
> ---
> .../staging/lustre/lustre/include/obd_support.h|  1 +
> drivers/staging/lustre/lustre/mdc/mdc_request.c| 50 ++
> 2 files changed, 32 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_support.h 
> b/drivers/staging/lustre/lustre/include/obd_support.h
> index 0c29a33..4a9fe88 100644
> --- a/drivers/staging/lustre/lustre/include/obd_support.h
> +++ b/drivers/staging/lustre/lustre/include/obd_support.h
> @@ -402,6 +402,7 @@ extern char obd_jobid_var[];
> #define OBD_FAIL_MDC_GETATTR_ENQUEUE 0x803
> #define OBD_FAIL_MDC_RPCS_SEM  0x804
> #define OBD_FAIL_MDC_LIGHTWEIGHT   0x805
> +#define OBD_FAIL_MDC_CLOSE0x806
> 
> #define OBD_FAIL_MGS   0x900
> #define OBD_FAIL_MGS_ALL_REQUEST_NET 0x901
> diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
> b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> index 91c0b45..8369afd 100644
> --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
> +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> @@ -677,9 +677,15 @@ static void mdc_free_open(struct md_open_data *mod)
>   imp_connect_disp_stripe(mod->mod_open_req->rq_import))
>   committed = 1;
> 
> - LASSERT(mod->mod_open_req->rq_replay == 0);
> -
> - DEBUG_REQ(D_RPCTRACE, mod->mod_open_req, "free open request\n");
> + /*
> +  * No reason to asssert here if the open request has
> +  * rq_replay == 1. It means that mdc_close failed, and
> +  * close request wasn`t sent. It is not fatal to client.
> +  * The worst thing is eviction if the client gets open lock
> +  */
> + DEBUG_REQ(D_RPCTRACE, mod->mod_open_req,
> +   "free open request rq_replay = %d\n",
> +mod->mod_open_req->rq_replay);
> 
>   ptlrpc_request_committed(mod->mod_open_req, committed);
>   if (mod->mod_close_req)
> @@ -749,22 +755,10 @@ static int mdc_close(struct obd_export *exp, struct 
> md_op_data *op_data,
>   }
> 
>   *request = NULL;
> - req = ptlrpc_request_alloc(class_exp2cliimp(exp), req_fmt);
> - if (!req)
> - return -ENOMEM;
> -
> - rc = ptlrpc_request_pack(req, LUSTRE_MDS_VERSION, MDS_CLOSE);
> - if (rc) {
> - ptlrpc_request_free(req);
> - return rc;
> - }
> -
> - /* To avoid a livelock (bug 7034), we need to send CLOSE RPCs to a
> -  * portal whose threads are not taking any DLM locks and are therefore
> -  * always progressing
> -  */
> - req->rq_request_portal = MDS_READPAGE_PORTAL;
> - ptlrpc_at_set_req_timeout(req);
> + if (OBD_FAIL_CHECK(OBD_FAIL_MDC_CLOSE))
> + req = NULL;
> + else
> + req = ptlrpc_request_alloc(class_exp2cliimp(exp), req_fmt);
> 
>   /* Ensure that this close's handle is fixed up during replay. */
>   if (likely(mod)) {
> @@ -785,6 +779,23 @@ static int mdc_close(struct obd_export *exp, struct 
> md_op_data *op_data,
>CDEBUG(D_HA,
>   "couldn't find open req; expecting close error\n");
>   }
> + if (!req) {
> + /*
> +  * TODO: repeat close after errors
> +  */
> + CWARN("%s: close of FID "DFID" failed, file reference will be 
> dropped when this client unmounts or is evicted\n",
> +   obd->obd_name, PFID(_data->op_fid1));
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + /*
> +  * To avoid a livelock (bug 7034), we need to send CLOSE RPCs to a
> +  * portal whose threads are not taking any DLM locks and are therefore
> +  * always progressing
> +  */
> + req->rq_request_portal = MDS_READPAGE_PORTAL;
> + ptlrpc_at_set_req_timeout(req);
> 
>   mdc_close_pack(req, op_data);
> 
> @@ -830,6 +841,7 @@ static int mdc_close(struct obd_export *exp, struct 
> 

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >On Fri, 19 Aug 2016 08:33:21 +0800
> >"Zhou, Wenjian/周文剑"  wrote:
> >
> >>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>I think it is a good choice to describe it in kernel-parameters.txt.
> >>
> >>Then, only two things need to be done I think.
> >>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>
> >>How do you think?
> >
> >That is not quite what I had in mind, sorry.  What I would really like to
> >see in kernel-parameters.txt is an explanation of how those two parameters
> >differ - what do they do differently and how should a user choose one over
> >the other?  What we have now offers no guidance in that matter.
> >
> 
> I thought about it. I think user may not need this.
> What user really want to know is how to choose.
> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use 
> maxcpus.
> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be 
> supported
> by some ARCHes.

I think Jon is suggesting that a note can be added into
kernel-parameter.txt to tell what's the difference between nr_cpus and
max_cpus. I checked code and discussed within our kdump team, max_cpus
is used to limit how many 'present' cpus are allowed to be brought up
during system bootup, while nr_cpus is used to set the upper limit of
'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
plug, means during bootup you want to bring up 4 present cpus, but
later you could physically hot plug 4 others. Because of attribute of
some static percpu variables, we need pre-allocate memory for all
possible cpus though some of them may not be really used if no extra
cpu physically hot plugged after system bootup.

Hence for kdump kernel, people never want to do a cpu hot plug in there.
That's why we want to use nr_cpus to limit the number of possible cpu to
save memory. E.g still on my laptop, if I want to do a kdump, the number
of possible cpu is still 8, but you may want to use only 1 cpu to dump,
maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
is much better. While with specifying max_cpus=1, the number of possible
cpu is still 8. That's the reason. On x86_64 and s390, there's another
kernel para "possible_cpus=xx" which can be used to set possible cpus for
cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
I am not very sure why this is introduced, number of possible cpu is
decided by the min value of nr_cpus= and possible_cpus=.

nr_cpus and maxcpus might not be very clear to people which are
described in Documentation/kernel-parameters.txt.

Hi Jon, do you think change as below is OK to you?


>From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
From: Baoquan He 
Date: Wed, 24 Aug 2016 11:14:34 +0800
Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
 and maxcpus

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in the ARCH. The
reason is nr_cpus is used to limit the max number of possible cpu
in system, the sum of already plugged cpus and hot plug cpus can't
exceed its value. However maxcpus is used to limit how many cpus
are allowed to be brought up during bootup.

Signed-off-by: Baoquan He 
---
 Documentation/kernel-parameters.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 46c030a..25d3b36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
than or equal to this physical address is ignored.
 
maxcpus=[SMP] Maximum number of processors that an SMP kernel
-   should make use of.  maxcpus=n : n >= 0 limits the
-   kernel to using 'n' processors.  n=0 is a special case,
-   it is equivalent to "nosmp", which also disables
-   the IO APIC.
+   will bring up during bootup.  maxcpus=n : n >= 0 limits
+   the kernel to bring up 'n' processors. Surely after
+   bootup you can bring up the other plugged cpu by 
executing
+   "echo 1 > /sys/devices/system/cpu/cpuX/online". So 
maxcpus
+   only 

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Baoquan He]

On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >On Fri, 19 Aug 2016 08:33:21 +0800
> >"Zhou, Wenjian/周文剑"  wrote:
> >
> >>I was also confused by maxcpus and nr_cpus before writing this patch.
> >>I think it is a good choice to describe it in kernel-parameters.txt.
> >>
> >>Then, only two things need to be done I think.
> >>One is move the above description to maxcpus= in kernel-parameters.txt.
> >>And the other is replace maxcpus with maxcpus/nr_cpus in kdump.txt.
> >>
> >>How do you think?
> >
> >That is not quite what I had in mind, sorry.  What I would really like to
> >see in kernel-parameters.txt is an explanation of how those two parameters
> >differ - what do they do differently and how should a user choose one over
> >the other?  What we have now offers no guidance in that matter.
> >
> 
> I thought about it. I think user may not need this.
> What user really want to know is how to choose.
> And it is also not a hard work. If nr_cpus is not supported by the ARCH, use 
> maxcpus.
> Otherwise, nr_cpus. The reason why maxcpus still exists is nr_cpus can't be 
> supported
> by some ARCHes.

I think Jon is suggesting that a note can be added into
kernel-parameter.txt to tell what's the difference between nr_cpus and
max_cpus. I checked code and discussed within our kdump team, max_cpus
is used to limit how many 'present' cpus are allowed to be brought up
during system bootup, while nr_cpus is used to set the upper limit of
'possible' cpus. E.g on my laptop, there are 4 cpus while 4 hotplug
cpus, altogether 8 possible cpus. Possible cpus slot is for cpu hot
plug, means during bootup you want to bring up 4 present cpus, but
later you could physically hot plug 4 others. Because of attribute of
some static percpu variables, we need pre-allocate memory for all
possible cpus though some of them may not be really used if no extra
cpu physically hot plugged after system bootup.

Hence for kdump kernel, people never want to do a cpu hot plug in there.
That's why we want to use nr_cpus to limit the number of possible cpu to
save memory. E.g still on my laptop, if I want to do a kdump, the number
of possible cpu is still 8, but you may want to use only 1 cpu to dump,
maybe 2 or 3 for parallel dumping. But you absolutely don't want to set
nr_cpus=8 in your kdump kernel cmdline, though it doesn't cause failure,
memory is wasted because of percpu pre-allocation. So specifying nr_cpus=1
is much better. While with specifying max_cpus=1, the number of possible
cpu is still 8. That's the reason. On x86_64 and s390, there's another
kernel para "possible_cpus=xx" which can be used to set possible cpus for
cpu hot plug. Only when "possible_cpus=0" is specified, smp is disabled.
I am not very sure why this is introduced, number of possible cpu is
decided by the min value of nr_cpus= and possible_cpus=.

nr_cpus and maxcpus might not be very clear to people which are
described in Documentation/kernel-parameters.txt.

Hi Jon, do you think change as below is OK to you?


>From 8b940193a29acf0857d4975d77f4b9f48e2d6cb8 Mon Sep 17 00:00:00 2001
From: Baoquan He 
Date: Wed, 24 Aug 2016 11:14:34 +0800
Subject: [PATCH] docs: kernel-parameter : Improve the description of nr_cpus
 and maxcpus

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in the ARCH. The
reason is nr_cpus is used to limit the max number of possible cpu
in system, the sum of already plugged cpus and hot plug cpus can't
exceed its value. However maxcpus is used to limit how many cpus
are allowed to be brought up during bootup.

Signed-off-by: Baoquan He 
---
 Documentation/kernel-parameters.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 46c030a..25d3b36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
than or equal to this physical address is ignored.
 
maxcpus=[SMP] Maximum number of processors that an SMP kernel
-   should make use of.  maxcpus=n : n >= 0 limits the
-   kernel to using 'n' processors.  n=0 is a special case,
-   it is equivalent to "nosmp", which also disables
-   the IO APIC.
+   will bring up during bootup.  maxcpus=n : n >= 0 limits
+   the kernel to bring up 'n' processors. Surely after
+   bootup you can bring up the other plugged cpu by 
executing
+   "echo 1 > /sys/devices/system/cpu/cpuX/online". So 
maxcpus
+   only takes effect during system bootup.
+   

[PATCH v2] serial: vt8500_serial: Fix a parameter of find_first_zero_bit.

[Christophe JAILLET]

The 2nd parameter of 'find_first_zero_bit' is the number of bits to search.
In this case, we are passing 'sizeof(vt8500_ports_in_use)'.
'vt8500_ports_in_use' is an 'unsigned long'. So the sizeof is likely to
return 4 on a 32 bits kernel.

A few lines below, we check if it is below VT8500_MAX_PORTS, which is 6.

It is likely that the number of bits in a long was expected here.

In order to fix it:
   - use DECLARE_BITMAP when declaring the vt8500_ports_in_use
   - use VT8500_MAX_PORTS as a maximum value when checking/setting bits in
 this bitmap
   - modify code now that 'vt8500_ports_in_use' has become a pointer
 because of the use of DECLARE_BITMAP


It has been spotted by the following coccinelle script:
@@
expression ret, x;

@@
*  ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));

Signed-off-by: Christophe JAILLET 
---
v2: - use of VT8500_MAX_PORTS instead of BITS_PER_LONG to better self
  document the code
- declare vt8500_ports_in_use with DECLARE_BITMAP in order to self
  document even better and to be foolproof should VT8500_MAX_PORTS
  be changed one day
---
 drivers/tty/serial/vt8500_serial.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/vt8500_serial.c 
b/drivers/tty/serial/vt8500_serial.c
index 23cfc5e16b45..6b85adce0ac9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -118,7 +118,7 @@ struct vt8500_port {
  * have been allocated as we can't use pdev->id in
  * devicetree
  */
-static unsigned long vt8500_ports_in_use;
+static DECLARE_BITMAP(vt8500_ports_in_use, VT8500_MAX_PORTS);
 
 static inline void vt8500_write(struct uart_port *port, unsigned int val,
 unsigned int off)
@@ -663,15 +663,15 @@ static int vt8500_serial_probe(struct platform_device 
*pdev)
 
if (port < 0) {
/* calculate the port id */
-   port = find_first_zero_bit(_ports_in_use,
-   sizeof(vt8500_ports_in_use));
+   port = find_first_zero_bit(vt8500_ports_in_use,
+  VT8500_MAX_PORTS);
}
 
if (port >= VT8500_MAX_PORTS)
return -ENODEV;
 
/* reserve the port id */
-   if (test_and_set_bit(port, _ports_in_use)) {
+   if (test_and_set_bit(port, vt8500_ports_in_use)) {
/* port already in use - shouldn't really happen */
return -EBUSY;
}
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

[PATCH v2] serial: vt8500_serial: Fix a parameter of find_first_zero_bit.

[Christophe JAILLET]

The 2nd parameter of 'find_first_zero_bit' is the number of bits to search.
In this case, we are passing 'sizeof(vt8500_ports_in_use)'.
'vt8500_ports_in_use' is an 'unsigned long'. So the sizeof is likely to
return 4 on a 32 bits kernel.

A few lines below, we check if it is below VT8500_MAX_PORTS, which is 6.

It is likely that the number of bits in a long was expected here.

In order to fix it:
   - use DECLARE_BITMAP when declaring the vt8500_ports_in_use
   - use VT8500_MAX_PORTS as a maximum value when checking/setting bits in
 this bitmap
   - modify code now that 'vt8500_ports_in_use' has become a pointer
 because of the use of DECLARE_BITMAP


It has been spotted by the following coccinelle script:
@@
expression ret, x;

@@
*  ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));

Signed-off-by: Christophe JAILLET 
---
v2: - use of VT8500_MAX_PORTS instead of BITS_PER_LONG to better self
  document the code
- declare vt8500_ports_in_use with DECLARE_BITMAP in order to self
  document even better and to be foolproof should VT8500_MAX_PORTS
  be changed one day
---
 drivers/tty/serial/vt8500_serial.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/vt8500_serial.c 
b/drivers/tty/serial/vt8500_serial.c
index 23cfc5e16b45..6b85adce0ac9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -118,7 +118,7 @@ struct vt8500_port {
  * have been allocated as we can't use pdev->id in
  * devicetree
  */
-static unsigned long vt8500_ports_in_use;
+static DECLARE_BITMAP(vt8500_ports_in_use, VT8500_MAX_PORTS);
 
 static inline void vt8500_write(struct uart_port *port, unsigned int val,
 unsigned int off)
@@ -663,15 +663,15 @@ static int vt8500_serial_probe(struct platform_device 
*pdev)
 
if (port < 0) {
/* calculate the port id */
-   port = find_first_zero_bit(_ports_in_use,
-   sizeof(vt8500_ports_in_use));
+   port = find_first_zero_bit(vt8500_ports_in_use,
+  VT8500_MAX_PORTS);
}
 
if (port >= VT8500_MAX_PORTS)
return -ENODEV;
 
/* reserve the port id */
-   if (test_and_set_bit(port, _ports_in_use)) {
+   if (test_and_set_bit(port, vt8500_ports_in_use)) {
/* port already in use - shouldn't really happen */
return -EBUSY;
}
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: [v13.1 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Hi Chanwoo


On 08/23/2016 01:44 PM, Chanwoo Choi wrote:

Hi Chris,

The name of 'SuperSpeed' property is changed
from EXTCON_PROP_USB_SUPERSPEED to EXTCON_PROP_USB_SS.

The name change was discussed on mail thread[1].
Oh, since I was using the old name in my local kernel, I will change it 
in V14.

Thanks.


Also, this driver depend on the extcon git repository.
So, I created the immutable branch(ib-extcon-phy-4.9)[2] for phy framework
to prevent the build error before merging the Linus git repository.

[1] https://lkml.org/lkml/2016/8/17/622
[2] git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
ib-extcon-phy-4.9

Regards,
Chanwoo Choi

On 2016년 08월 23일 14:02, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications.
The USB3 operates in SuperSpeed mode and the DP can operate at RBR,
HBR and HBR2 data rates. This driver create 2 PHY devices separately
for USB3 and DisplyPort, and registers them under the child node.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 

---

Changes in v13.1:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration

Changes in v13:
- do not return err if nothing connected with Type-C, when usb phy power on,
   since the USB core driver will call phy power without USB3 device connected.

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
   and DP is attached

Changes in v11:
- make a clearer demarcation between usb phy and dp phy.

Changes in v10:
- do not control dp select and hpd config in phy driver

Changes in v9:
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
   rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log

Changes in v7:
- support new API of extcon

Changes in v6:
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support

Changes in v4:
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

  drivers/phy/Kconfig  |9 +
  drivers/phy/Makefile |1 +
  drivers/phy/phy-rockchip-typec.c | 1013 ++
  3 files changed, 1023 insertions(+)
  create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 42f3e30..c775fd7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -348,6 +348,15 @@ config PHY_ROCKCHIP_PCIE
help
  Enable this to support the Rockchip PCIe PHY.
  
+config PHY_ROCKCHIP_TYPEC

+   tristate "Rockchip TYPEC PHY Driver"
+   depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
+   select EXTCON
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
  config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index fbb91e7..5d58b63 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)  += 
phy-rockchip-inno-usb2.o
  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
  obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o
  obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
  

Re: [v13.1 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Hi Chanwoo


On 08/23/2016 01:44 PM, Chanwoo Choi wrote:

Hi Chris,

The name of 'SuperSpeed' property is changed
from EXTCON_PROP_USB_SUPERSPEED to EXTCON_PROP_USB_SS.

The name change was discussed on mail thread[1].
Oh, since I was using the old name in my local kernel, I will change it 
in V14.

Thanks.


Also, this driver depend on the extcon git repository.
So, I created the immutable branch(ib-extcon-phy-4.9)[2] for phy framework
to prevent the build error before merging the Linus git repository.

[1] https://lkml.org/lkml/2016/8/17/622
[2] git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
ib-extcon-phy-4.9

Regards,
Chanwoo Choi

On 2016년 08월 23일 14:02, Chris Zhong wrote:

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications.
The USB3 operates in SuperSpeed mode and the DP can operate at RBR,
HBR and HBR2 data rates. This driver create 2 PHY devices separately
for USB3 and DisplyPort, and registers them under the child node.

Signed-off-by: Chris Zhong 
Signed-off-by: Kever Yang 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 

---

Changes in v13.1:
- add some description in front of driver
- change name of usb to usb3
- add a USB3 RX register configuration

Changes in v13:
- do not return err if nothing connected with Type-C, when usb phy power on,
   since the USB core driver will call phy power without USB3 device connected.

Changes in v12:
- enable DP+USB3 mode, only when EXTCON_PROP_USB_SUPERSPEED equal 1
   and DP is attached

Changes in v11:
- make a clearer demarcation between usb phy and dp phy.

Changes in v10:
- do not control dp select and hpd config in phy driver

Changes in v9:
- the new_mode should be int not u8
- move mutex_lock(>lock); to earlier place. in
   rockchip_usb3_phy_power_off
- better mutex lock for phy mode and flip
- split the Type-C PHY into two PHYs: USB3 and DP

Changes in v8:
- set the default cable id to EXTCON_USB_HOST
- optimization Error log

Changes in v7:
- support new API of extcon

Changes in v6:
- delete the support of PIN_ASSIGN_A/B
- set the default mode to MODE_DFP_USB
- disable DP PLL at USB3 only mode

Changes in v5:
- support get property from extcon
- remove PIN ASSIGN A/B support

Changes in v4:
- select EXTCON
- use phy framework to control the USB3 and DP function
- rename PIN_MAP_ to PIN_ASSIGN_

Changes in v3:
- remove the phy framework(Kishon Vijay Abraham I)
- add parentheses around the macro
- use a single space between type and name
- add spaces after opening and before closing braces.
- use u16 for register value
- remove type-c phy header file
- CodingStyle optimization
- use some cable extcon to get type-c port information
- add a extcon to notify Display Port

Changes in v2:
- select RESET_CONTROLLER
- alphabetic order
- modify some spelling mistakes
- make mode cleaner
- use bool for enable/disable
- check all of the return value
- return a better err number
- use more readx_poll_timeout()
- clk_disable_unprepare(tcphy->clk_ref);
- remove unuse functions, rockchip_typec_phy_power_on/off
- remove unnecessary typecast from void *
- use dts node to distinguish between phys.

Changes in v1:
- update the licence note
- init core clock to 50MHz
- use extcon API
- remove unused global
- add some comments for magic num
- change usleep_range(1000, 2000) tousleep_range(1000, 1050)
- remove __func__ from dev_err
- return err number when get clk failed
- remove ADDR_ADJ define
- use devm_clk_get(>dev, "tcpdcore")

  drivers/phy/Kconfig  |9 +
  drivers/phy/Makefile |1 +
  drivers/phy/phy-rockchip-typec.c | 1013 ++
  3 files changed, 1023 insertions(+)
  create mode 100644 drivers/phy/phy-rockchip-typec.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 42f3e30..c775fd7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -348,6 +348,15 @@ config PHY_ROCKCHIP_PCIE
help
  Enable this to support the Rockchip PCIe PHY.
  
+config PHY_ROCKCHIP_TYPEC

+   tristate "Rockchip TYPEC PHY Driver"
+   depends on OF && (ARCH_ROCKCHIP || COMPILE_TEST)
+   select EXTCON
+   select GENERIC_PHY
+   select RESET_CONTROLLER
+   help
+ Enable this to support the Rockchip USB TYPEC PHY.
+
  config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index fbb91e7..5d58b63 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)  += 
phy-rockchip-inno-usb2.o
  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
  obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o
  obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
+obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)   += phy-qcom-ipq806x-sata.o
  

Re: [PATCH v2 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

[Krzysztof Kozlowski]

On Mon, Aug 22, 2016 at 07:30:36PM +0200, Rafael J. Wysocki wrote:
> On Saturday, August 20, 2016 05:40:49 PM Krzysztof Kozlowski wrote:
> > On Sat, Aug 20, 2016 at 03:08:01AM +0200, Rafael J. Wysocki wrote:
> > > On Friday, August 19, 2016 03:26:21 PM Krzysztof Kozlowski wrote:
> > > > On Fri, Aug 12, 2016 at 2:04 AM, Rafael J. Wysocki  
> > > > wrote:
> > > > > From: Rafael J. Wysocki 
> > > > >
> > > > > It is useful to know the reason why cpufreq_update_util() has just
> > > > > been called and that can be passed as flags to cpufreq_update_util()
> > > > > and to the ->func() callback in struct update_util_data.  However,
> > > > > doing that in addition to passing the util and max arguments they
> > > > > already take would be clumsy, so avoid it.
> > > > >
> > > > > Instead, use the observation that the schedutil governor is part
> > > > > of the scheduler proper, so it can access scheduler data directly.
> > > > > This allows the util and max arguments of cpufreq_update_util()
> > > > > and the ->func() callback in struct update_util_data to be replaced
> > > > > with a flags one, but schedutil has to be modified to follow.
> > > > >
> > > > > Thus make the schedutil governor obtain the CFS utilization
> > > > > information from the scheduler and use the "RT" and "DL" flags
> > > > > instead of the special utilization value of ULONG_MAX to track
> > > > > updates from the RT and DL sched classes.  Make it non-modular
> > > > > too to avoid having to export scheduler variables to modules at
> > > > > large.
> > > > >
> > > > > Next, update all of the other users of cpufreq_update_util()
> > > > > and the ->func() callback in struct update_util_data accordingly.
> > > > >
> > > > > Suggested-by: Peter Zijlstra 
> > > > > Signed-off-by: Rafael J. Wysocki 
> > > > > ---
> > > > >
> > > > > v1 -> v2: Do not check cpu_of(rq) against smp_processor_id() in
> > > > >   cfs_rq_util_change().
> > > > >
> > > > > ---
> > > > >  drivers/cpufreq/Kconfig|5 --
> > > > >  drivers/cpufreq/cpufreq_governor.c |2 -
> > > > >  drivers/cpufreq/intel_pstate.c |2 -
> > > > >  include/linux/sched.h  |   12 --
> > > > >  kernel/sched/cpufreq.c |2 -
> > > > >  kernel/sched/cpufreq_schedutil.c   |   67 
> > > > > -
> > > > >  kernel/sched/deadline.c|4 +-
> > > > >  kernel/sched/fair.c|   10 +
> > > > >  kernel/sched/rt.c  |4 +-
> > > > >  kernel/sched/sched.h   |   31 +
> > > > >  10 files changed, 66 insertions(+), 73 deletions(-)
> > > > 
> > > > (...)
> > > > 
> > > > > --- linux-pm.orig/drivers/cpufreq/Kconfig
> > > > > +++ linux-pm/drivers/cpufreq/Kconfig
> > > > > @@ -194,7 +194,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> > > > >   If in doubt, say N.
> > > > >
> > > > >  config CPU_FREQ_GOV_SCHEDUTIL
> > > > > -   tristate "'schedutil' cpufreq policy governor"
> > > > > +   bool "'schedutil' cpufreq policy governor"
> > > > 
> > > > If you change such symbols please remember to update also all the
> > > > defconfigs. Without the update they start to show errors.
> > > 
> > > Are there defconfigs that use this particular one?
> > 
> > Yes, ARM/multi_v7 and exynos were using this as module. Javier sent a
> > patch for that and should be switched to builtin in upcoming next [1].
> > 
> > If you would like to base on top of that, let me know, so I would
> > prepare a tag.
> 
> I wouldn't like to rebase, but I can pull that branch depending on how
> much more material there is on it.

Not much, I put only the fix m->y on a separate branch. Anyway if you
need it, here it is:


The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-defconfig-schedutil-4.9

for you to fetch changes up to 08023fb9cec03ee2992df51fa728c3f14a1ba0ea:

  ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as module 
(2016-08-19 17:50:13 +0200)


The schedutil cpufreq governor will be switched from tristate to bool. Fix
defconfigs.


Javier Martinez Canillas (2):
  ARM: exynos_defconfig: Don't attempt to enable schedutil governor as 
module
  ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as 
module

 arch/arm/configs/exynos_defconfig   | 2 +-
 arch/arm/configs/multi_v7_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH v2 1/2] cpufreq / sched: Pass flags to cpufreq_update_util()

[Krzysztof Kozlowski]

On Mon, Aug 22, 2016 at 07:30:36PM +0200, Rafael J. Wysocki wrote:
> On Saturday, August 20, 2016 05:40:49 PM Krzysztof Kozlowski wrote:
> > On Sat, Aug 20, 2016 at 03:08:01AM +0200, Rafael J. Wysocki wrote:
> > > On Friday, August 19, 2016 03:26:21 PM Krzysztof Kozlowski wrote:
> > > > On Fri, Aug 12, 2016 at 2:04 AM, Rafael J. Wysocki  
> > > > wrote:
> > > > > From: Rafael J. Wysocki 
> > > > >
> > > > > It is useful to know the reason why cpufreq_update_util() has just
> > > > > been called and that can be passed as flags to cpufreq_update_util()
> > > > > and to the ->func() callback in struct update_util_data.  However,
> > > > > doing that in addition to passing the util and max arguments they
> > > > > already take would be clumsy, so avoid it.
> > > > >
> > > > > Instead, use the observation that the schedutil governor is part
> > > > > of the scheduler proper, so it can access scheduler data directly.
> > > > > This allows the util and max arguments of cpufreq_update_util()
> > > > > and the ->func() callback in struct update_util_data to be replaced
> > > > > with a flags one, but schedutil has to be modified to follow.
> > > > >
> > > > > Thus make the schedutil governor obtain the CFS utilization
> > > > > information from the scheduler and use the "RT" and "DL" flags
> > > > > instead of the special utilization value of ULONG_MAX to track
> > > > > updates from the RT and DL sched classes.  Make it non-modular
> > > > > too to avoid having to export scheduler variables to modules at
> > > > > large.
> > > > >
> > > > > Next, update all of the other users of cpufreq_update_util()
> > > > > and the ->func() callback in struct update_util_data accordingly.
> > > > >
> > > > > Suggested-by: Peter Zijlstra 
> > > > > Signed-off-by: Rafael J. Wysocki 
> > > > > ---
> > > > >
> > > > > v1 -> v2: Do not check cpu_of(rq) against smp_processor_id() in
> > > > >   cfs_rq_util_change().
> > > > >
> > > > > ---
> > > > >  drivers/cpufreq/Kconfig|5 --
> > > > >  drivers/cpufreq/cpufreq_governor.c |2 -
> > > > >  drivers/cpufreq/intel_pstate.c |2 -
> > > > >  include/linux/sched.h  |   12 --
> > > > >  kernel/sched/cpufreq.c |2 -
> > > > >  kernel/sched/cpufreq_schedutil.c   |   67 
> > > > > -
> > > > >  kernel/sched/deadline.c|4 +-
> > > > >  kernel/sched/fair.c|   10 +
> > > > >  kernel/sched/rt.c  |4 +-
> > > > >  kernel/sched/sched.h   |   31 +
> > > > >  10 files changed, 66 insertions(+), 73 deletions(-)
> > > > 
> > > > (...)
> > > > 
> > > > > --- linux-pm.orig/drivers/cpufreq/Kconfig
> > > > > +++ linux-pm/drivers/cpufreq/Kconfig
> > > > > @@ -194,7 +194,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> > > > >   If in doubt, say N.
> > > > >
> > > > >  config CPU_FREQ_GOV_SCHEDUTIL
> > > > > -   tristate "'schedutil' cpufreq policy governor"
> > > > > +   bool "'schedutil' cpufreq policy governor"
> > > > 
> > > > If you change such symbols please remember to update also all the
> > > > defconfigs. Without the update they start to show errors.
> > > 
> > > Are there defconfigs that use this particular one?
> > 
> > Yes, ARM/multi_v7 and exynos were using this as module. Javier sent a
> > patch for that and should be switched to builtin in upcoming next [1].
> > 
> > If you would like to base on top of that, let me know, so I would
> > prepare a tag.
> 
> I wouldn't like to rebase, but I can pull that branch depending on how
> much more material there is on it.

Not much, I put only the fix m->y on a separate branch. Anyway if you
need it, here it is:


The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-defconfig-schedutil-4.9

for you to fetch changes up to 08023fb9cec03ee2992df51fa728c3f14a1ba0ea:

  ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as module 
(2016-08-19 17:50:13 +0200)


The schedutil cpufreq governor will be switched from tristate to bool. Fix
defconfigs.


Javier Martinez Canillas (2):
  ARM: exynos_defconfig: Don't attempt to enable schedutil governor as 
module
  ARM: multi_v7_defconfig: Don't attempt to enable schedutil governor as 
module

 arch/arm/configs/exynos_defconfig   | 2 +-
 arch/arm/configs/multi_v7_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Dan Williams]

On Tue, Aug 23, 2016 at 9:28 PM, Kani, Toshimitsu  wrote:
>> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams 
>> wrote:
>> > On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu 
>> wrote:
>> >>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
>> 
>> >>> wrote:
>  :
>> >>
>> >> crash> p {struct vmem_altmap} 0x88046d045410
>> >> $6 = {
>> >>   base_pfn = 0x48,
>> >>   reserve = 0x2,// PHYS_PFN(SZ_8K)
>> >>   free = 0x101fe,
>> >>   align = 0x1fe,
>> >>   alloc = 0x1
>> >> }
>> >
>> > Ah, so, on second look the 0x49020 data offset looks correct.  The
>> > total size of the address range is 16GB which equates to 256MB needed
>> > for struct page, plus 2MB more to re-align the data on the next 2MB
>> > boundary.
>> >
>> > The question now is why is the guest faulting on an access to an
>> > address less than 0x49020?
>>
>> Does the attached patch fix this for you?
>
> Yeah, that makes sense.  I will test it tomorrow.
>
> BTW, why does devm_memremap_pages() put a whole range to pgmap_radix
> as device memory, but only initialize page->pgmap for its data range?  Is 
> there
> particular reason for this inconsistency?
>

The radix tree is indexed by section number, but we don't always
initialize a full section.  The cases when we don't use a full section
is when it overlaps device metadata, or if a platform multiplexes the
device memory range with another resource within the same section.

Re: [Patch v8] driver/clk/clk-si5338: Add common clock framework driver for si5338

[Stephen Boyd]

On 08/24, kbuild test robot wrote:
> 
>   2827if (drv_type < 0)
>   2828return drv_type;
>   2829
>   2830drv_vdd =  get_drv_vdd(drvdata, i);
>   2831if (drv_vdd < 0)
>   2832return drv_vdd;
>   2833
>   2834drv_trim = get_drv_trim(drvdata, i);
>   2835if (drv_trim < 0)
>   2836return drv_trim;
>   2837
>   2838drv_invert = get_drv_invert(drvdata, i);
>   2839if (drv_invert < 0)
>   2840return drv_invert;
>   2841
>   2842for (j = 0; drv_configs[j].description; j++) {
> > 2843if (drv_configs[j].fmt == drv_type &&
>   2844drv_configs[j].vdd == drv_vdd &&
>   2845drv_configs[j].trim == drv_trim &&
>   2846(drv_invert | (drv_configs[j].invert >> 2)) 
> ==
>   2847((drv_configs[j].invert & 3) |
>   2848 (drv_configs[j].invert>>2)))

It might be better to write it as a set of continues instead so
that it isn't one complicated conditional

config = _configs[j];
if (config->fmt != drv_type)
continue;
if (config->vdd != drv_vdd)
continue;
...
seq_puts()
match = 1;
break;


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

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Dan Williams]

On Tue, Aug 23, 2016 at 9:28 PM, Kani, Toshimitsu  wrote:
>> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams 
>> wrote:
>> > On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu 
>> wrote:
>> >>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
>> 
>> >>> wrote:
>  :
>> >>
>> >> crash> p {struct vmem_altmap} 0x88046d045410
>> >> $6 = {
>> >>   base_pfn = 0x48,
>> >>   reserve = 0x2,// PHYS_PFN(SZ_8K)
>> >>   free = 0x101fe,
>> >>   align = 0x1fe,
>> >>   alloc = 0x1
>> >> }
>> >
>> > Ah, so, on second look the 0x49020 data offset looks correct.  The
>> > total size of the address range is 16GB which equates to 256MB needed
>> > for struct page, plus 2MB more to re-align the data on the next 2MB
>> > boundary.
>> >
>> > The question now is why is the guest faulting on an access to an
>> > address less than 0x49020?
>>
>> Does the attached patch fix this for you?
>
> Yeah, that makes sense.  I will test it tomorrow.
>
> BTW, why does devm_memremap_pages() put a whole range to pgmap_radix
> as device memory, but only initialize page->pgmap for its data range?  Is 
> there
> particular reason for this inconsistency?
>

The radix tree is indexed by section number, but we don't always
initialize a full section.  The cases when we don't use a full section
is when it overlaps device metadata, or if a platform multiplexes the
device memory range with another resource within the same section.

Re: [Patch v8] driver/clk/clk-si5338: Add common clock framework driver for si5338

[Stephen Boyd]

On 08/24, kbuild test robot wrote:
> 
>   2827if (drv_type < 0)
>   2828return drv_type;
>   2829
>   2830drv_vdd =  get_drv_vdd(drvdata, i);
>   2831if (drv_vdd < 0)
>   2832return drv_vdd;
>   2833
>   2834drv_trim = get_drv_trim(drvdata, i);
>   2835if (drv_trim < 0)
>   2836return drv_trim;
>   2837
>   2838drv_invert = get_drv_invert(drvdata, i);
>   2839if (drv_invert < 0)
>   2840return drv_invert;
>   2841
>   2842for (j = 0; drv_configs[j].description; j++) {
> > 2843if (drv_configs[j].fmt == drv_type &&
>   2844drv_configs[j].vdd == drv_vdd &&
>   2845drv_configs[j].trim == drv_trim &&
>   2846(drv_invert | (drv_configs[j].invert >> 2)) 
> ==
>   2847((drv_configs[j].invert & 3) |
>   2848 (drv_configs[j].invert>>2)))

It might be better to write it as a set of continues instead so
that it isn't one complicated conditional

config = _configs[j];
if (config->fmt != drv_type)
continue;
if (config->vdd != drv_vdd)
continue;
...
seq_puts()
match = 1;
break;


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

Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section

[Stephen Boyd]

On 08/23, Sylwester Nawrocki wrote:
> On 08/23/2016 04:35 AM, Chanwoo Choi wrote:
> I checked stripped object files and it seems with the patch there
> is some saving of the kernel image size. Exactly 784 bytes, which
> makes zImage smaller by 480 bytes.
> 
> The patch increases .init.rodata section size by 780 bytes but 
> decreases .init.text section size by 1564 bytes.  Looks like 
> a static initializer is cheaper.
> 
> $ ls -l  drivers/clk/samsung/clk-exynos5260.o
> 
> < -rw-rw-r-- 1 snawrocki snawrocki 29100 Aug 23 11:35 
> drivers/clk/samsung/clk-exynos5260.o
> ---
> > -rw-rw-r-- 1 snawrocki snawrocki 28316 Aug 23 11:32 
> > drivers/clk/samsung/clk-exynos5260.o
> 
> 
> The section size differences are as below:
> 15c15
> <   3 .init.text06b8      0034  2**2
> ---
> >   3 .init.text009c      0034  2**2
> 25c25
> <   8 .init.rodata  3f6c      2f20  2**2
> ---
> >   8 .init.rodata  4278      2904  2**2
> 
> So the saving is rather insignificant but the patch doesn't make
> things worse and I'd say it might be worth applying.
> 

Sounds good. This sort of information should be in the commit
text though. Talking about const doesn't make any sense to me.

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

Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section

[Stephen Boyd]

On 08/23, Sylwester Nawrocki wrote:
> On 08/23/2016 04:35 AM, Chanwoo Choi wrote:
> I checked stripped object files and it seems with the patch there
> is some saving of the kernel image size. Exactly 784 bytes, which
> makes zImage smaller by 480 bytes.
> 
> The patch increases .init.rodata section size by 780 bytes but 
> decreases .init.text section size by 1564 bytes.  Looks like 
> a static initializer is cheaper.
> 
> $ ls -l  drivers/clk/samsung/clk-exynos5260.o
> 
> < -rw-rw-r-- 1 snawrocki snawrocki 29100 Aug 23 11:35 
> drivers/clk/samsung/clk-exynos5260.o
> ---
> > -rw-rw-r-- 1 snawrocki snawrocki 28316 Aug 23 11:32 
> > drivers/clk/samsung/clk-exynos5260.o
> 
> 
> The section size differences are as below:
> 15c15
> <   3 .init.text06b8      0034  2**2
> ---
> >   3 .init.text009c      0034  2**2
> 25c25
> <   8 .init.rodata  3f6c      2f20  2**2
> ---
> >   8 .init.rodata  4278      2904  2**2
> 
> So the saving is rather insignificant but the patch doesn't make
> things worse and I'd say it might be worth applying.
> 

Sounds good. This sort of information should be in the commit
text though. Talking about const doesn't make any sense to me.

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

linux-next: Tree for Aug 24

[Stephen Rothwell]

Hi all,

Changes since 20160823:

The drm-intel tree lost its build failure but gained conflicts against
the drm-intel-fixes tree.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

The sound-asoc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3442
 3439 files changed, 154545 insertions(+), 61198 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (7a1dcf6adaa7 Merge tag 'usercopy-v4.8-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (c57653dc94d0 ARC: export __udivdi3 for modules)
Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for 
undefined instructions)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect 
to build with std=gnu99)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (28a10c426e81 net sched: fix encoding to use real length)
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (b75911b66ad5 netfilter: cttimeout: fix use after free 
error when delete netns)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (c81396f3da22 mwifiex: fix large amsdu packets 
causing firmware hang)
Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv 
compatibility issue with 64 bit Kernel")
Merging sound-current/for-linus (b027d1126383 ALSA: line6: Fix POD sysfs 
attributes segfault)
Merging pci-current/for-linus (21c80c9fefc3 x86/PCI: VMD: Fix infinite loop 
executing irq's)
Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2)
Merging tty.current/tty-linus (87a713c8ffca 8250/fintek: rename IRQ_MODE macro)
Merging usb.current/usb-linus (53e5f36fbd24 USB: avoid left shift by -1)
Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing 
on HWO set)
Merging usb-serial-fixes/usb-linus (6695593e4a76 USB: serial: option: add 
WeTelecom WM-D200)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (eafe5cfe7189 Merge tag 
'iio-fixes-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into work-linus)
Merging char-misc.current/char-misc-linus (51c70261b257 Revert "android: 
binder: fix dangling pointer comparison")
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (e67479b13ede crypto: sha512-mb - fix ctx pointer)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs mo

linux-next: Tree for Aug 24

[Stephen Rothwell]

Hi all,

Changes since 20160823:

The drm-intel tree lost its build failure but gained conflicts against
the drm-intel-fixes tree.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

The sound-asoc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3442
 3439 files changed, 154545 insertions(+), 61198 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (7a1dcf6adaa7 Merge tag 'usercopy-v4.8-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (c57653dc94d0 ARC: export __udivdi3 for modules)
Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for 
undefined instructions)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect 
to build with std=gnu99)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (28a10c426e81 net sched: fix encoding to use real length)
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (b75911b66ad5 netfilter: cttimeout: fix use after free 
error when delete netns)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (c81396f3da22 mwifiex: fix large amsdu packets 
causing firmware hang)
Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv 
compatibility issue with 64 bit Kernel")
Merging sound-current/for-linus (b027d1126383 ALSA: line6: Fix POD sysfs 
attributes segfault)
Merging pci-current/for-linus (21c80c9fefc3 x86/PCI: VMD: Fix infinite loop 
executing irq's)
Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2)
Merging tty.current/tty-linus (87a713c8ffca 8250/fintek: rename IRQ_MODE macro)
Merging usb.current/usb-linus (53e5f36fbd24 USB: avoid left shift by -1)
Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing 
on HWO set)
Merging usb-serial-fixes/usb-linus (6695593e4a76 USB: serial: option: add 
WeTelecom WM-D200)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (eafe5cfe7189 Merge tag 
'iio-fixes-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into work-linus)
Merging char-misc.current/char-misc-linus (51c70261b257 Revert "android: 
binder: fix dangling pointer comparison")
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (e67479b13ede crypto: sha512-mb - fix ctx pointer)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs mo

RE: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Kani, Toshimitsu]

> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams 
> wrote:
> > On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu 
> wrote:
> >>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
> 
> >>> wrote:
 :
> >>
> >> crash> p {struct vmem_altmap} 0x88046d045410
> >> $6 = {
> >>   base_pfn = 0x48,
> >>   reserve = 0x2,// PHYS_PFN(SZ_8K)
> >>   free = 0x101fe,
> >>   align = 0x1fe,
> >>   alloc = 0x1
> >> }
> >
> > Ah, so, on second look the 0x49020 data offset looks correct.  The
> > total size of the address range is 16GB which equates to 256MB needed
> > for struct page, plus 2MB more to re-align the data on the next 2MB
> > boundary.
> >
> > The question now is why is the guest faulting on an access to an
> > address less than 0x49020?
> 
> Does the attached patch fix this for you?

Yeah, that makes sense.  I will test it tomorrow.

BTW, why does devm_memremap_pages() put a whole range to pgmap_radix
as device memory, but only initialize page->pgmap for its data range?  Is there
particular reason for this inconsistency?

Thanks,
-Toshi

RE: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Kani, Toshimitsu]

> On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams 
> wrote:
> > On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu 
> wrote:
> >>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu
> 
> >>> wrote:
 :
> >>
> >> crash> p {struct vmem_altmap} 0x88046d045410
> >> $6 = {
> >>   base_pfn = 0x48,
> >>   reserve = 0x2,// PHYS_PFN(SZ_8K)
> >>   free = 0x101fe,
> >>   align = 0x1fe,
> >>   alloc = 0x1
> >> }
> >
> > Ah, so, on second look the 0x49020 data offset looks correct.  The
> > total size of the address range is 16GB which equates to 256MB needed
> > for struct page, plus 2MB more to re-align the data on the next 2MB
> > boundary.
> >
> > The question now is why is the guest faulting on an access to an
> > address less than 0x49020?
> 
> Does the attached patch fix this for you?

Yeah, that makes sense.  I will test it tomorrow.

BTW, why does devm_memremap_pages() put a whole range to pgmap_radix
as device memory, but only initialize page->pgmap for its data range?  Is there
particular reason for this inconsistency?

Thanks,
-Toshi

linux-next: taking a break

[Stephen Rothwell]

Hi all,

I will not be producing a linux-next release this Friday or next week.
So the next release after tomorrow will be next-20160905.

-- 
Cheers,
Stephen Rothwell

linux-next: taking a break

[Stephen Rothwell]

Hi all,

I will not be producing a linux-next release this Friday or next week.
So the next release after tomorrow will be next-20160905.

-- 
Cheers,
Stephen Rothwell

Re: [RFC PATCH-tip v4 10/10] locking/rwsem: Add a boot parameter to reader spinning threshold

[Davidlohr Bueso]

On Thu, 18 Aug 2016, Waiman Long wrote:


The default reader spining threshold is current set to 4096. However,
the right reader spinning threshold may vary from one system to
another and among the different architectures. This patch adds a new
kernel boot parameter to modify the threshold value. This enables
better tailoring to the needs of different systems as well as for
testing purposes.


It also means that those systems could very easily be incorrectly tailored.
(and worse case scenario: reboot, is obviously a terrible way to get rid
of any issues). I very much disagree with exposing this sort of core stuff,
it should work well for everyone out of the box, not relying on users to
properly configure this.

Thanks,
Davidlohr

Re: [RFC PATCH-tip v4 10/10] locking/rwsem: Add a boot parameter to reader spinning threshold

[Davidlohr Bueso]

On Thu, 18 Aug 2016, Waiman Long wrote:


The default reader spining threshold is current set to 4096. However,
the right reader spinning threshold may vary from one system to
another and among the different architectures. This patch adds a new
kernel boot parameter to modify the threshold value. This enables
better tailoring to the needs of different systems as well as for
testing purposes.


It also means that those systems could very easily be incorrectly tailored.
(and worse case scenario: reboot, is obviously a terrible way to get rid
of any issues). I very much disagree with exposing this sort of core stuff,
it should work well for everyone out of the box, not relying on users to
properly configure this.

Thanks,
Davidlohr

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Dan Williams]

On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams  wrote:
> On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu  wrote:
>>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu 
>>> wrote:
>>> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>>> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani 
>>> >> wrote:
>>> >  :
>>> >> I'm not sure about this fix.  The point of honoring
>>> >> vmem_altmap_offset() is because a portion of the resource that is
>>> >> passed to devm_memremap_pages() also contains the metadata info
>>> block
>>> >> for the device.  The offset says "use everything past this point for
>>> >> pages".  This may work for avoiding a crash, but it may corrupt info
>>> >> block metadata in the process.  Can you provide more information
>>> >> about the failing scenario to be sure that we are not triggering a
>>> >> fault on an address that is not meant to have a page mapping?  I.e.
>>> >> what is the host physical address of the page that caused this fault,
>>> >> and is it valid?
>>> >
>>> > The fault address in question was the 2nd page of an NVDIMM range.  I
>>> > assumed this fault address was valid and needed to be handled.  Here is
>>> > some info about the base and patched cases.  Let me know if you need
>>> > more info.
>>> >
>>> > Base
>>> > 
>>> >
>>> > The following NVDIMM range was set to /dev/dax.
>>>
>>> With ndctl create-namespace or manually via sysfs?  Specifically I'm
>>> looking for what the 'align' attribute was set to when the
>>> configuration was established.  Can you provide a dump of the sysfs
>>> attributes for the /dev/dax parent device?
>>
>> I used the ndctl command below.
>> ndctl create-namespace -f -e namespace0.0 -m dax
>>
>> Here is additional info from my note for the base case.
>>
>> p {struct dev_pagemap} 0x88046d0453f0
>> $3 = {
>>   altmap = 0x88046d045410,
>>   res = 0x88046d0453a8,
>>   ref = 0x88046d0452f0,
>>   dev = 0x880464790410
>> }
>>
>> crash> p {struct vmem_altmap} 0x88046d045410
>> $6 = {
>>   base_pfn = 0x48,
>>   reserve = 0x2,// PHYS_PFN(SZ_8K)
>>   free = 0x101fe,
>>   align = 0x1fe,
>>   alloc = 0x1
>> }
>
> Ah, so, on second look the 0x49020 data offset looks correct.  The
> total size of the address range is 16GB which equates to 256MB needed
> for struct page, plus 2MB more to re-align the data on the next 2MB
> boundary.
>
> The question now is why is the guest faulting on an access to an
> address less than 0x49020?

Does the attached patch fix this for you?
From 506cdd2c4ec0f9283ac4eb92259f2e8a71c5b637 Mon Sep 17 00:00:00 2001
From: Dan Williams 
Date: Tue, 23 Aug 2016 19:59:31 -0700
Subject: [PATCH] dax: fix device-dax region base

The data offset for a dax region needs to account for an altmap
reservation in the resource range.  Otherwise, device-dax is allowing
mappings directly into the memmap or device info-block area, with crash
signatures like the following:

 BUG: unable to handle kernel NULL pointer dereference at 0008
 IP: [] get_zone_device_page+0x11/0x30
 Call Trace:
   follow_devmap_pmd+0x298/0x2c0
   follow_page_mask+0x275/0x530
   __get_user_pages+0xe3/0x750
   __gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
   ? hrtimer_try_to_cancel+0x2c/0x120
   ? kvm_read_l1_tsc+0x55/0x60 [kvm]
   try_async_pf+0x66/0x230 [kvm]
   ? kvm_host_page_size+0x90/0xa0 [kvm]
   tdp_page_fault+0x130/0x280 [kvm]
   kvm_mmu_page_fault+0x5f/0xf0 [kvm]
   handle_ept_violation+0x94/0x180 [kvm_intel]
   vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
   ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel]
   ? vmx_vcpu_run+0x2d1/0x490 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
   ? wake_up_q+0x44/0x80
   kvm_vcpu_ioctl+0x33c/0x620 [kvm]
   ? __vfs_write+0x37/0x160
   do_vfs_ioctl+0xa2/0x5d0
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x1a/0xa4

Cc: 
Cc: Andrew Morton 
Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Abhilash Kumar Mulumudi 
Reported-by: Toshi Kani 
Signed-off-by: Dan Williams 
---
 drivers/dax/pmem.c   | 2 ++
 include/linux/memremap.h | 1 +
 kernel/memremap.c| 9 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index dfb168568af1..0603637df162 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -116,6 +116,8 @@ static int dax_pmem_probe(struct device *dev)
 	if (rc)
 		return rc;
 
+	res.start += vmem_altmap_resource_offset(altmap);
+
 	nd_region = to_nd_region(dev->parent);
 	dax_region = alloc_dax_region(dev, nd_region->id, ,
 			le32_to_cpu(pfn_sb->align), addr, PFN_DEV|PFN_MAP);
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 93416196ba64..7265b83cdbea 100644
--- a/include/linux/memremap.h
+++ 

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Dan Williams]

On Tue, Aug 23, 2016 at 7:53 PM, Dan Williams  wrote:
> On Tue, Aug 23, 2016 at 6:29 PM, Kani, Toshimitsu  wrote:
>>> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu 
>>> wrote:
>>> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
>>> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani 
>>> >> wrote:
>>> >  :
>>> >> I'm not sure about this fix.  The point of honoring
>>> >> vmem_altmap_offset() is because a portion of the resource that is
>>> >> passed to devm_memremap_pages() also contains the metadata info
>>> block
>>> >> for the device.  The offset says "use everything past this point for
>>> >> pages".  This may work for avoiding a crash, but it may corrupt info
>>> >> block metadata in the process.  Can you provide more information
>>> >> about the failing scenario to be sure that we are not triggering a
>>> >> fault on an address that is not meant to have a page mapping?  I.e.
>>> >> what is the host physical address of the page that caused this fault,
>>> >> and is it valid?
>>> >
>>> > The fault address in question was the 2nd page of an NVDIMM range.  I
>>> > assumed this fault address was valid and needed to be handled.  Here is
>>> > some info about the base and patched cases.  Let me know if you need
>>> > more info.
>>> >
>>> > Base
>>> > 
>>> >
>>> > The following NVDIMM range was set to /dev/dax.
>>>
>>> With ndctl create-namespace or manually via sysfs?  Specifically I'm
>>> looking for what the 'align' attribute was set to when the
>>> configuration was established.  Can you provide a dump of the sysfs
>>> attributes for the /dev/dax parent device?
>>
>> I used the ndctl command below.
>> ndctl create-namespace -f -e namespace0.0 -m dax
>>
>> Here is additional info from my note for the base case.
>>
>> p {struct dev_pagemap} 0x88046d0453f0
>> $3 = {
>>   altmap = 0x88046d045410,
>>   res = 0x88046d0453a8,
>>   ref = 0x88046d0452f0,
>>   dev = 0x880464790410
>> }
>>
>> crash> p {struct vmem_altmap} 0x88046d045410
>> $6 = {
>>   base_pfn = 0x48,
>>   reserve = 0x2,// PHYS_PFN(SZ_8K)
>>   free = 0x101fe,
>>   align = 0x1fe,
>>   alloc = 0x1
>> }
>
> Ah, so, on second look the 0x49020 data offset looks correct.  The
> total size of the address range is 16GB which equates to 256MB needed
> for struct page, plus 2MB more to re-align the data on the next 2MB
> boundary.
>
> The question now is why is the guest faulting on an access to an
> address less than 0x49020?

Does the attached patch fix this for you?
From 506cdd2c4ec0f9283ac4eb92259f2e8a71c5b637 Mon Sep 17 00:00:00 2001
From: Dan Williams 
Date: Tue, 23 Aug 2016 19:59:31 -0700
Subject: [PATCH] dax: fix device-dax region base

The data offset for a dax region needs to account for an altmap
reservation in the resource range.  Otherwise, device-dax is allowing
mappings directly into the memmap or device info-block area, with crash
signatures like the following:

 BUG: unable to handle kernel NULL pointer dereference at 0008
 IP: [] get_zone_device_page+0x11/0x30
 Call Trace:
   follow_devmap_pmd+0x298/0x2c0
   follow_page_mask+0x275/0x530
   __get_user_pages+0xe3/0x750
   __gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
   ? hrtimer_try_to_cancel+0x2c/0x120
   ? kvm_read_l1_tsc+0x55/0x60 [kvm]
   try_async_pf+0x66/0x230 [kvm]
   ? kvm_host_page_size+0x90/0xa0 [kvm]
   tdp_page_fault+0x130/0x280 [kvm]
   kvm_mmu_page_fault+0x5f/0xf0 [kvm]
   handle_ept_violation+0x94/0x180 [kvm_intel]
   vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
   ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel]
   ? vmx_vcpu_run+0x2d1/0x490 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
   ? wake_up_q+0x44/0x80
   kvm_vcpu_ioctl+0x33c/0x620 [kvm]
   ? __vfs_write+0x37/0x160
   do_vfs_ioctl+0xa2/0x5d0
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x1a/0xa4

Cc: 
Cc: Andrew Morton 
Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Abhilash Kumar Mulumudi 
Reported-by: Toshi Kani 
Signed-off-by: Dan Williams 
---
 drivers/dax/pmem.c   | 2 ++
 include/linux/memremap.h | 1 +
 kernel/memremap.c| 9 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index dfb168568af1..0603637df162 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -116,6 +116,8 @@ static int dax_pmem_probe(struct device *dev)
 	if (rc)
 		return rc;
 
+	res.start += vmem_altmap_resource_offset(altmap);
+
 	nd_region = to_nd_region(dev->parent);
 	dax_region = alloc_dax_region(dev, nd_region->id, ,
 			le32_to_cpu(pfn_sb->align), addr, PFN_DEV|PFN_MAP);
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 93416196ba64..7265b83cdbea 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -24,6 +24,7 @@ struct vmem_altmap {
 };
 
 unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
+resource_size_t vmem_altmap_resource_offset(struct vmem_altmap *altmap);
 void vmem_altmap_free(struct 

Re: [PATCH 0/3] perf, bts: Fallout from the fuzzer for perf/urgent

[Alexander Shishkin]

Thanks! I'll get back to you with something better.

On 23 August 2016 at 23:55, Vince Weaver  wrote:
> On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>
>> Vince Weaver  writes:
>>
>> > On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>> >
>> >> Recently Vince has reported warnings and panics coming from the
>> >> general direction of AUX tracing. I found two bugs which manifest
>> >> similarly, one in intel_bts driver and one in AUX unmapping path.
>> >>
>> >> Both are triggered by racing SET_OUTPUT against mmap_close while
>> >> running AUX tracing. I have a test case that set fire to the kernel
>> >> within a few seconds by doing this, which I can share if anyone
>> >> cares.
>> >
>> > I've applied these and am fuzzing on my Haswell machine and I'm getting
>> > lots and lots of
>> >
>> > [  945.536374] Dazed and confused, but trying to continue
>> > [  945.542391] Uhhuh. NMI received for unknown reason 21 on CPU 2.
>> > [  945.549360] Do you have a strange power saving mode enabled?
>> > [  945.556701] Dazed and confused, but trying to continue
>> > [  945.563643] Uhhuh. NMI received for unknown reason 31 on CPU 2.
>> > [  945.571379] Do you have a strange power saving mode enabled?
>> > [  945.578754] Dazed and confused, but trying to continue
>> > [  945.630889] Uhhuh. NMI received for unknown reason 31 on CPU 2.
>> > [  945.638141] Do you have a strange power saving mode enabled?
>> > [  945.645523] Dazed and confused, but trying to continue
>> >
>> > messages that I wasn't getting before.  Of course, I updated from -rc2 to
>> > -rc3 before applying the patch so it could also be related to that too, I
>> > can try backing out the patches and see if it still happens.
>>
>> Uhhuh, that's not cool, let me look some more. But it should stop dying
>> on bts/aux stuff at least.
>
> Just wanted to say that when I backed out these patches the NMI errors
> went away, so they do seem to be a result of this patch series.
>
> Vince

Re: [PATCH 0/3] perf, bts: Fallout from the fuzzer for perf/urgent

[Alexander Shishkin]

Thanks! I'll get back to you with something better.

On 23 August 2016 at 23:55, Vince Weaver  wrote:
> On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>
>> Vince Weaver  writes:
>>
>> > On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>> >
>> >> Recently Vince has reported warnings and panics coming from the
>> >> general direction of AUX tracing. I found two bugs which manifest
>> >> similarly, one in intel_bts driver and one in AUX unmapping path.
>> >>
>> >> Both are triggered by racing SET_OUTPUT against mmap_close while
>> >> running AUX tracing. I have a test case that set fire to the kernel
>> >> within a few seconds by doing this, which I can share if anyone
>> >> cares.
>> >
>> > I've applied these and am fuzzing on my Haswell machine and I'm getting
>> > lots and lots of
>> >
>> > [  945.536374] Dazed and confused, but trying to continue
>> > [  945.542391] Uhhuh. NMI received for unknown reason 21 on CPU 2.
>> > [  945.549360] Do you have a strange power saving mode enabled?
>> > [  945.556701] Dazed and confused, but trying to continue
>> > [  945.563643] Uhhuh. NMI received for unknown reason 31 on CPU 2.
>> > [  945.571379] Do you have a strange power saving mode enabled?
>> > [  945.578754] Dazed and confused, but trying to continue
>> > [  945.630889] Uhhuh. NMI received for unknown reason 31 on CPU 2.
>> > [  945.638141] Do you have a strange power saving mode enabled?
>> > [  945.645523] Dazed and confused, but trying to continue
>> >
>> > messages that I wasn't getting before.  Of course, I updated from -rc2 to
>> > -rc3 before applying the patch so it could also be related to that too, I
>> > can try backing out the patches and see if it still happens.
>>
>> Uhhuh, that's not cool, let me look some more. But it should stop dying
>> on bts/aux stuff at least.
>
> Just wanted to say that when I backed out these patches the NMI errors
> went away, so they do seem to be a result of this patch series.
>
> Vince

Re: [PATCH 2/2] mm/usercopy: enable usercopy size checking for modern versions of gcc

[Kees Cook]

On Tue, Aug 23, 2016 at 3:28 PM, Josh Poimboeuf  wrote:
> This is a revert of:
>
>   2fb0815c9ee6 ("gcc4: disable __compiletime_object_size for GCC 4.6+")
>
> The goal of that commit was to silence the "provably correct" gcc
> warnings.  But it went too far: it also disabled the runtime warnings.
>
> Now that the pretty much useless gcc warnings have been properly
> disposed of with the previous patch, re-enable this checking on modern
> versions of gcc so we can get the runtime warnings again.

As far as I know, this will still be broken since it's
__builtin_object_size() that is buggy. Maybe I'm misunderstanding
which piece is busted, though?

-Kees

>
> Signed-off-by: Josh Poimboeuf 
> ---
>  include/linux/compiler-gcc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index e294939..e7f7a68 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -158,7 +158,7 @@
>  #define __compiler_offsetof(a, b)  \
> __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100 && GCC_VERSION < 40600
> +#if GCC_VERSION >= 40100
>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>  #endif
>
> --
> 2.7.4
>



-- 
Kees Cook
Nexus Security

Re: [PATCH 2/2] mm/usercopy: enable usercopy size checking for modern versions of gcc

[Kees Cook]

On Tue, Aug 23, 2016 at 3:28 PM, Josh Poimboeuf  wrote:
> This is a revert of:
>
>   2fb0815c9ee6 ("gcc4: disable __compiletime_object_size for GCC 4.6+")
>
> The goal of that commit was to silence the "provably correct" gcc
> warnings.  But it went too far: it also disabled the runtime warnings.
>
> Now that the pretty much useless gcc warnings have been properly
> disposed of with the previous patch, re-enable this checking on modern
> versions of gcc so we can get the runtime warnings again.

As far as I know, this will still be broken since it's
__builtin_object_size() that is buggy. Maybe I'm misunderstanding
which piece is busted, though?

-Kees

>
> Signed-off-by: Josh Poimboeuf 
> ---
>  include/linux/compiler-gcc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index e294939..e7f7a68 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -158,7 +158,7 @@
>  #define __compiler_offsetof(a, b)  \
> __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100 && GCC_VERSION < 40600
> +#if GCC_VERSION >= 40100
>  # define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
>  #endif
>
> --
> 2.7.4
>



-- 
Kees Cook
Nexus Security

[PATCH v13 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[HS Liao]

This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.

Signed-off-by: HS Liao 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/soc/mediatek/gce.txt   | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt 
b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
new file mode 100644
index 000..55c4105
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
@@ -0,0 +1,44 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+CMDQ driver uses mailbox framework for communication. Please refer to
+../../mailbox/mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+- #mbox-cells: Should be 2
+
+Required properties for a client device:
+- mboxes: client use mailbox to communicate with GCE, it should have this
+  property and list of phandle, mailbox channel specifiers, and atomic
+  execution flag.
+
+Example:
+
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
+Example for a client device:
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys";
+   mboxes = < 0 1 /* main display with atomic execution */
+  1 1>; /* sub display with atomic execution */
+   ...
+   };
-- 
1.9.1

[PATCH v13 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[HS Liao]

This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.

Signed-off-by: HS Liao 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/soc/mediatek/gce.txt   | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt

diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt 
b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
new file mode 100644
index 000..55c4105
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
@@ -0,0 +1,44 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+CMDQ driver uses mailbox framework for communication. Please refer to
+../../mailbox/mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+- #mbox-cells: Should be 2
+
+Required properties for a client device:
+- mboxes: client use mailbox to communicate with GCE, it should have this
+  property and list of phandle, mailbox channel specifiers, and atomic
+  execution flag.
+
+Example:
+
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
+Example for a client device:
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys";
+   mboxes = < 0 1 /* main display with atomic execution */
+  1 1>; /* sub display with atomic execution */
+   ...
+   };
-- 
1.9.1

linux-next: build warning after merge of the thermal tree

[Stephen Rothwell]

Hi Zhang,

After merging the thermal tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

warning: (HISI_THERMAL) selects STUB_CLK_HI6220 which has unmet direct 
dependencies (COMMON_CLK && COMMON_CLK_HI6220 && MAILBOX)

Introduced by commit

  5f63581ce68e ("thermal: hisilicon: Add dependency on the clock driver to 
allow frequency scaling")

BTW: That commit message does not match the change (which adds a
"select" not a "depends on".

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the thermal tree

[Stephen Rothwell]

Hi Zhang,

After merging the thermal tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

warning: (HISI_THERMAL) selects STUB_CLK_HI6220 which has unmet direct 
dependencies (COMMON_CLK && COMMON_CLK_HI6220 && MAILBOX)

Introduced by commit

  5f63581ce68e ("thermal: hisilicon: Add dependency on the clock driver to 
allow frequency scaling")

BTW: That commit message does not match the change (which adds a
"select" not a "depends on".

-- 
Cheers,
Stephen Rothwell

[PATCH v13 2/4] CMDQ: Mediatek CMDQ driver

[HS Liao]

This patch is first version of Mediatek Command Queue(CMDQ) driver. The
CMDQ is used to help write registers with critical time limitation,
such as updating display configuration during the vblank. It controls
Global Command Engine (GCE) hardware to achieve this requirement.
Currently, CMDQ only supports display related hardwares, but we expect
it can be extended to other hardwares for future requirements.

Signed-off-by: HS Liao 
Signed-off-by: CK Hu 
---
 drivers/soc/mediatek/Kconfig|  11 +
 drivers/soc/mediatek/Makefile   |   1 +
 drivers/soc/mediatek/mtk-cmdq.c | 945 
 include/soc/mediatek/cmdq.h | 180 
 4 files changed, 1137 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq.c
 create mode 100644 include/soc/mediatek/cmdq.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 0a4ea80..50869e4 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -1,6 +1,17 @@
 #
 # MediaTek SoC drivers
 #
+config MTK_CMDQ
+   bool "MediaTek CMDQ Support"
+   depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST )
+   select MAILBOX
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..f7397ef 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
new file mode 100644
index 000..7ca3113
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq.c
@@ -0,0 +1,945 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */
+#define CMDQ_INST_SIZE 8 /* instruction is 64-bit */
+#define CMDQ_TIMEOUT_MS1000
+#define CMDQ_IRQ_MASK  0x
+#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / 
CMDQ_INST_SIZE)
+
+#define CMDQ_CURR_IRQ_STATUS   0x10
+#define CMDQ_THR_SLOT_CYCLES   0x30
+
+#define CMDQ_THR_BASE  0x100
+#define CMDQ_THR_SIZE  0x80
+#define CMDQ_THR_WARM_RESET0x00
+#define CMDQ_THR_ENABLE_TASK   0x04
+#define CMDQ_THR_SUSPEND_TASK  0x08
+#define CMDQ_THR_CURR_STATUS   0x0c
+#define CMDQ_THR_IRQ_STATUS0x10
+#define CMDQ_THR_IRQ_ENABLE0x14
+#define CMDQ_THR_CURR_ADDR 0x20
+#define CMDQ_THR_END_ADDR  0x24
+
+#define CMDQ_THR_ENABLED   0x1
+#define CMDQ_THR_DISABLED  0x0
+#define CMDQ_THR_SUSPEND   0x1
+#define CMDQ_THR_RESUME0x0
+#define CMDQ_THR_STATUS_SUSPENDED  BIT(1)
+#define CMDQ_THR_DO_WARM_RESET BIT(0)
+#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200
+#define CMDQ_THR_IRQ_DONE  0x1
+#define CMDQ_THR_IRQ_ERROR 0x12
+#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | 
CMDQ_THR_IRQ_DONE)
+
+#define CMDQ_OP_CODE_SHIFT 24
+#define CMDQ_SUBSYS_SHIFT  16
+
+#define CMDQ_ARG_A_WRITE_MASK  0x
+#define CMDQ_OP_CODE_MASK  (0xff << CMDQ_OP_CODE_SHIFT)
+
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_JUMP_BY_OFFSET0x1000
+#define CMDQ_JUMP_BY_PA0x1001
+#define CMDQ_JUMP_PASS CMDQ_INST_SIZE
+#define CMDQ_WFE_UPDATEBIT(31)
+#define CMDQ_WFE_WAIT  BIT(15)
+#define CMDQ_WFE_WAIT_VALUE0x1
+#define CMDQ_EOC_IRQ_ENBIT(0)
+
+/*
+ * CMDQ_CODE_MASK:
+ *   set write mask
+ *   format: op mask
+ * CMDQ_CODE_WRITE:
+ *   write value into target register

[PATCH v13 2/4] CMDQ: Mediatek CMDQ driver

[HS Liao]

This patch is first version of Mediatek Command Queue(CMDQ) driver. The
CMDQ is used to help write registers with critical time limitation,
such as updating display configuration during the vblank. It controls
Global Command Engine (GCE) hardware to achieve this requirement.
Currently, CMDQ only supports display related hardwares, but we expect
it can be extended to other hardwares for future requirements.

Signed-off-by: HS Liao 
Signed-off-by: CK Hu 
---
 drivers/soc/mediatek/Kconfig|  11 +
 drivers/soc/mediatek/Makefile   |   1 +
 drivers/soc/mediatek/mtk-cmdq.c | 945 
 include/soc/mediatek/cmdq.h | 180 
 4 files changed, 1137 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq.c
 create mode 100644 include/soc/mediatek/cmdq.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 0a4ea80..50869e4 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -1,6 +1,17 @@
 #
 # MediaTek SoC drivers
 #
+config MTK_CMDQ
+   bool "MediaTek CMDQ Support"
+   depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST )
+   select MAILBOX
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..f7397ef 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
new file mode 100644
index 000..7ca3113
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq.c
@@ -0,0 +1,945 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */
+#define CMDQ_INST_SIZE 8 /* instruction is 64-bit */
+#define CMDQ_TIMEOUT_MS1000
+#define CMDQ_IRQ_MASK  0x
+#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / 
CMDQ_INST_SIZE)
+
+#define CMDQ_CURR_IRQ_STATUS   0x10
+#define CMDQ_THR_SLOT_CYCLES   0x30
+
+#define CMDQ_THR_BASE  0x100
+#define CMDQ_THR_SIZE  0x80
+#define CMDQ_THR_WARM_RESET0x00
+#define CMDQ_THR_ENABLE_TASK   0x04
+#define CMDQ_THR_SUSPEND_TASK  0x08
+#define CMDQ_THR_CURR_STATUS   0x0c
+#define CMDQ_THR_IRQ_STATUS0x10
+#define CMDQ_THR_IRQ_ENABLE0x14
+#define CMDQ_THR_CURR_ADDR 0x20
+#define CMDQ_THR_END_ADDR  0x24
+
+#define CMDQ_THR_ENABLED   0x1
+#define CMDQ_THR_DISABLED  0x0
+#define CMDQ_THR_SUSPEND   0x1
+#define CMDQ_THR_RESUME0x0
+#define CMDQ_THR_STATUS_SUSPENDED  BIT(1)
+#define CMDQ_THR_DO_WARM_RESET BIT(0)
+#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200
+#define CMDQ_THR_IRQ_DONE  0x1
+#define CMDQ_THR_IRQ_ERROR 0x12
+#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | 
CMDQ_THR_IRQ_DONE)
+
+#define CMDQ_OP_CODE_SHIFT 24
+#define CMDQ_SUBSYS_SHIFT  16
+
+#define CMDQ_ARG_A_WRITE_MASK  0x
+#define CMDQ_OP_CODE_MASK  (0xff << CMDQ_OP_CODE_SHIFT)
+
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_JUMP_BY_OFFSET0x1000
+#define CMDQ_JUMP_BY_PA0x1001
+#define CMDQ_JUMP_PASS CMDQ_INST_SIZE
+#define CMDQ_WFE_UPDATEBIT(31)
+#define CMDQ_WFE_WAIT  BIT(15)
+#define CMDQ_WFE_WAIT_VALUE0x1
+#define CMDQ_EOC_IRQ_ENBIT(0)
+
+/*
+ * CMDQ_CODE_MASK:
+ *   set write mask
+ *   format: op mask
+ * CMDQ_CODE_WRITE:
+ *   write value into target register
+ *   format: op subsys address value
+ * 

Re: [PATCH] infiniband/mlx5: Remove superfluous include of io-mapping.h

[Laurence Oberman]

- Original Message -
> From: "Chris Wilson" 
> To: linux-r...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org, "Chris Wilson" , 
> "Eli Cohen" , "Jack
> Morgenstein" , "Or Gerlitz" 
> , "Matan Barak" ,
> "Leon Romanovsky" , "Doug Ledford" 
> , "Sean Hefty" ,
> "Hal Rosenstock" 
> Sent: Tuesday, August 23, 2016 4:16:26 PM
> Subject: [PATCH] infiniband/mlx5: Remove superfluous include of io-mapping.h
> 
> This file does not use any structs or functions defined by io-mapping.h
> (nor does it directly use iomap, ioremap, iounamp or friends). Remove it
> to simplify verification of changes to io-mapping.h
> 
> The include existed since its inception in
> 
> commit e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c
> Author: Eli Cohen 
> Date:   Sun Jul 7 17:25:49 2013 +0300
> 
> mlx5: Add driver for Mellanox Connect-IB adapters
> 
> which looks like a copy across from the Mellanox ethernet driver.
> 
> Signed-off-by: Chris Wilson 
> Cc: Eli Cohen 
> Cc: Jack Morgenstein 
> Cc: Or Gerlitz 
> Cc: Matan Barak 
> Cc: Leon Romanovsky 
> Cc: Doug Ledford 
> Cc: Sean Hefty 
> Cc: Hal Rosenstock 
> Cc: linux-r...@vger.kernel.org
> ---
>  drivers/infiniband/hw/mlx5/main.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/main.c
> b/drivers/infiniband/hw/mlx5/main.c
> index a84bb766fc62..1b4094baa2de 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -37,7 +37,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #if defined(CONFIG_X86)
>  #include 
>  #endif
> --
> 2.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
I compiled and tested this with no issues on my mlx5 test bed.

Reviewed-by Laurence Oberman 
Tested-by Laurence Oberman 

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

[Martin K. Petersen]

> "Tom" == Tom Yan  writes:

Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI
Tom> terms, parameter list / data-out buffer).

WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we
have had no good reason to support that yet).

UNMAP has a payload that varies based on the number of range
descriptors. The SCSI disk driver only ever issues a single descriptor
but since libata doesn't support UNMAP this doesn't really come into
play.

Ideally there would be a way to distinguish between device limits for
WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to
do that would be to transition the libata discard implementation over to
single-range UNMAP, fill out the relevant VPD page B0 fields and leave
the WRITE SAME bits for writing zeroes.

One reason that has not been particularly compelling is that the WRITE
SAME payload buffer does double duty to hold the ATA DSM TRIM range
descriptors and matches the required ATA payload size. Whereas the UNMAP
command would only provide 24 bytes of TRIM range space.

Also, please be careful with transfer lengths, __data_len, etc. As
mentioned, the transfer length WRITE SAME is typically 512 bytes and
that's the number of bytes that need to be DMA'ed and transferred over
the wire by the controller. But from a command completion perspective we
need to complete however many bytes the command acted upon. Unlike reads
and writes there is not a 1:1 mapping between the transfer length and
the affected area. So we do a bit of magic after the buffer has been
mapped to ensure that the completion byte count matches the number of
blocks that were affected by the command rather than the size of the
data buffer in bytes.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] infiniband/mlx5: Remove superfluous include of io-mapping.h

[Laurence Oberman]

- Original Message -
> From: "Chris Wilson" 
> To: linux-r...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org, "Chris Wilson" , 
> "Eli Cohen" , "Jack
> Morgenstein" , "Or Gerlitz" 
> , "Matan Barak" ,
> "Leon Romanovsky" , "Doug Ledford" 
> , "Sean Hefty" ,
> "Hal Rosenstock" 
> Sent: Tuesday, August 23, 2016 4:16:26 PM
> Subject: [PATCH] infiniband/mlx5: Remove superfluous include of io-mapping.h
> 
> This file does not use any structs or functions defined by io-mapping.h
> (nor does it directly use iomap, ioremap, iounamp or friends). Remove it
> to simplify verification of changes to io-mapping.h
> 
> The include existed since its inception in
> 
> commit e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c
> Author: Eli Cohen 
> Date:   Sun Jul 7 17:25:49 2013 +0300
> 
> mlx5: Add driver for Mellanox Connect-IB adapters
> 
> which looks like a copy across from the Mellanox ethernet driver.
> 
> Signed-off-by: Chris Wilson 
> Cc: Eli Cohen 
> Cc: Jack Morgenstein 
> Cc: Or Gerlitz 
> Cc: Matan Barak 
> Cc: Leon Romanovsky 
> Cc: Doug Ledford 
> Cc: Sean Hefty 
> Cc: Hal Rosenstock 
> Cc: linux-r...@vger.kernel.org
> ---
>  drivers/infiniband/hw/mlx5/main.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/main.c
> b/drivers/infiniband/hw/mlx5/main.c
> index a84bb766fc62..1b4094baa2de 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -37,7 +37,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #if defined(CONFIG_X86)
>  #include 
>  #endif
> --
> 2.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
I compiled and tested this with no issues on my mlx5 test bed.

Reviewed-by Laurence Oberman 
Tested-by Laurence Oberman 

Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

[Martin K. Petersen]

> "Tom" == Tom Yan  writes:

Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI
Tom> terms, parameter list / data-out buffer).

WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we
have had no good reason to support that yet).

UNMAP has a payload that varies based on the number of range
descriptors. The SCSI disk driver only ever issues a single descriptor
but since libata doesn't support UNMAP this doesn't really come into
play.

Ideally there would be a way to distinguish between device limits for
WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to
do that would be to transition the libata discard implementation over to
single-range UNMAP, fill out the relevant VPD page B0 fields and leave
the WRITE SAME bits for writing zeroes.

One reason that has not been particularly compelling is that the WRITE
SAME payload buffer does double duty to hold the ATA DSM TRIM range
descriptors and matches the required ATA payload size. Whereas the UNMAP
command would only provide 24 bytes of TRIM range space.

Also, please be careful with transfer lengths, __data_len, etc. As
mentioned, the transfer length WRITE SAME is typically 512 bytes and
that's the number of bytes that need to be DMA'ed and transferred over
the wire by the controller. But from a command completion perspective we
need to complete however many bytes the command acted upon. Unlike reads
and writes there is not a 1:1 mapping between the transfer length and
the affected area. So we do a bit of magic after the buffer has been
mapped to ensure that the completion byte count matches the number of
blocks that were affected by the command rather than the size of the
data buffer in bytes.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v13 4/4] CMDQ: save more energy in idle

[HS Liao]

Use clk_disable_unprepare instead of clk_disable to save more energy
when CMDQ is idle.

Signed-off-by: HS Liao 
---
 drivers/soc/mediatek/mtk-cmdq.c | 54 +++--
 1 file changed, 46 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
index 7ca3113..a0fcbef 100644
--- a/drivers/soc/mediatek/mtk-cmdq.c
+++ b/drivers/soc/mediatek/mtk-cmdq.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */
@@ -128,10 +129,16 @@ struct cmdq_task {
struct cmdq_task_cb cb;
 };
 
+struct cmdq_clk_release {
+   struct cmdq *cmdq;
+   struct work_struct  release_work;
+};
+
 struct cmdq {
struct mbox_controller  mbox;
void __iomem*base;
u32 irq;
+   struct workqueue_struct *clk_release_wq;
struct cmdq_thread  thread[CMDQ_THR_MAX_COUNT];
struct mutextask_mutex;
struct clk  *clock;
@@ -297,11 +304,19 @@ static void cmdq_thread_wait_end(struct cmdq_thread 
*thread,
 static void cmdq_task_exec(struct cmdq_task *task, struct cmdq_thread *thread)
 {
struct cmdq *cmdq = task->cmdq;
-   unsigned long curr_pa, end_pa;
+   unsigned long curr_pa, end_pa, flags;
 
task->thread = thread;
if (list_empty(>task_busy_list)) {
-   WARN_ON(clk_enable(cmdq->clock) < 0);
+   /*
+* Unlock for clk prepare (sleeping function).
+* We are safe to do that since we have task_mutex and
+* only flush will add task.
+*/
+   spin_unlock_irqrestore(>chan->lock, flags);
+   WARN_ON(clk_prepare_enable(cmdq->clock) < 0);
+   spin_lock_irqsave(>chan->lock, flags);
+
WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
 
writel(task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
@@ -383,6 +398,26 @@ static void cmdq_task_handle_error(struct cmdq_task *task)
cmdq_thread_resume(thread);
 }
 
+static void cmdq_clk_release_work(struct work_struct *work_item)
+{
+   struct cmdq_clk_release *clk_release = container_of(work_item,
+   struct cmdq_clk_release, release_work);
+   struct cmdq *cmdq = clk_release->cmdq;
+
+   clk_disable_unprepare(cmdq->clock);
+   kfree(clk_release);
+}
+
+static void cmdq_clk_release_schedule(struct cmdq *cmdq)
+{
+   struct cmdq_clk_release *clk_release;
+
+   clk_release = kmalloc(sizeof(*clk_release), GFP_ATOMIC);
+   clk_release->cmdq = cmdq;
+   INIT_WORK(_release->release_work, cmdq_clk_release_work);
+   queue_work(cmdq->clk_release_wq, _release->release_work);
+}
+
 static void cmdq_thread_irq_handler(struct cmdq *cmdq,
struct cmdq_thread *thread)
 {
@@ -432,7 +467,7 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
 
if (list_empty(>task_busy_list)) {
cmdq_thread_disable(cmdq, thread);
-   clk_disable(cmdq->clock);
+   cmdq_clk_release_schedule(cmdq);
} else {
mod_timer(>timeout,
  jiffies + msecs_to_jiffies(CMDQ_TIMEOUT_MS));
@@ -491,7 +526,7 @@ static void cmdq_thread_handle_timeout(unsigned long data)
 
cmdq_thread_resume(thread);
cmdq_thread_disable(cmdq, thread);
-   clk_disable(cmdq->clock);
+   cmdq_clk_release_schedule(cmdq);
spin_unlock_irqrestore(>chan->lock, flags);
 }
 
@@ -779,7 +814,7 @@ static int cmdq_suspend(struct device *dev)
msleep(20);
}
 
-   clk_unprepare(cmdq->clock);
+   flush_workqueue(cmdq->clk_release_wq);
return 0;
 }
 
@@ -787,7 +822,6 @@ static int cmdq_resume(struct device *dev)
 {
struct cmdq *cmdq = dev_get_drvdata(dev);
 
-   WARN_ON(clk_prepare(cmdq->clock) < 0);
cmdq->suspended = false;
return 0;
 }
@@ -796,8 +830,8 @@ static int cmdq_remove(struct platform_device *pdev)
 {
struct cmdq *cmdq = platform_get_drvdata(pdev);
 
+   destroy_workqueue(cmdq->clk_release_wq);
mbox_controller_unregister(>mbox);
-   clk_unprepare(cmdq->clock);
return 0;
 }
 
@@ -916,8 +950,12 @@ static int cmdq_probe(struct platform_device *pdev)
return err;
}
 
+   cmdq->clk_release_wq = alloc_ordered_workqueue(
+   "%s", WQ_MEM_RECLAIM | WQ_HIGHPRI,
+   "cmdq_clk_release");
+
platform_set_drvdata(pdev, cmdq);
-   WARN_ON(clk_prepare(cmdq->clock) < 0);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v13 4/4] CMDQ: save more energy in idle

[HS Liao]

Use clk_disable_unprepare instead of clk_disable to save more energy
when CMDQ is idle.

Signed-off-by: HS Liao 
---
 drivers/soc/mediatek/mtk-cmdq.c | 54 +++--
 1 file changed, 46 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
index 7ca3113..a0fcbef 100644
--- a/drivers/soc/mediatek/mtk-cmdq.c
+++ b/drivers/soc/mediatek/mtk-cmdq.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */
@@ -128,10 +129,16 @@ struct cmdq_task {
struct cmdq_task_cb cb;
 };
 
+struct cmdq_clk_release {
+   struct cmdq *cmdq;
+   struct work_struct  release_work;
+};
+
 struct cmdq {
struct mbox_controller  mbox;
void __iomem*base;
u32 irq;
+   struct workqueue_struct *clk_release_wq;
struct cmdq_thread  thread[CMDQ_THR_MAX_COUNT];
struct mutextask_mutex;
struct clk  *clock;
@@ -297,11 +304,19 @@ static void cmdq_thread_wait_end(struct cmdq_thread 
*thread,
 static void cmdq_task_exec(struct cmdq_task *task, struct cmdq_thread *thread)
 {
struct cmdq *cmdq = task->cmdq;
-   unsigned long curr_pa, end_pa;
+   unsigned long curr_pa, end_pa, flags;
 
task->thread = thread;
if (list_empty(>task_busy_list)) {
-   WARN_ON(clk_enable(cmdq->clock) < 0);
+   /*
+* Unlock for clk prepare (sleeping function).
+* We are safe to do that since we have task_mutex and
+* only flush will add task.
+*/
+   spin_unlock_irqrestore(>chan->lock, flags);
+   WARN_ON(clk_prepare_enable(cmdq->clock) < 0);
+   spin_lock_irqsave(>chan->lock, flags);
+
WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
 
writel(task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
@@ -383,6 +398,26 @@ static void cmdq_task_handle_error(struct cmdq_task *task)
cmdq_thread_resume(thread);
 }
 
+static void cmdq_clk_release_work(struct work_struct *work_item)
+{
+   struct cmdq_clk_release *clk_release = container_of(work_item,
+   struct cmdq_clk_release, release_work);
+   struct cmdq *cmdq = clk_release->cmdq;
+
+   clk_disable_unprepare(cmdq->clock);
+   kfree(clk_release);
+}
+
+static void cmdq_clk_release_schedule(struct cmdq *cmdq)
+{
+   struct cmdq_clk_release *clk_release;
+
+   clk_release = kmalloc(sizeof(*clk_release), GFP_ATOMIC);
+   clk_release->cmdq = cmdq;
+   INIT_WORK(_release->release_work, cmdq_clk_release_work);
+   queue_work(cmdq->clk_release_wq, _release->release_work);
+}
+
 static void cmdq_thread_irq_handler(struct cmdq *cmdq,
struct cmdq_thread *thread)
 {
@@ -432,7 +467,7 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
 
if (list_empty(>task_busy_list)) {
cmdq_thread_disable(cmdq, thread);
-   clk_disable(cmdq->clock);
+   cmdq_clk_release_schedule(cmdq);
} else {
mod_timer(>timeout,
  jiffies + msecs_to_jiffies(CMDQ_TIMEOUT_MS));
@@ -491,7 +526,7 @@ static void cmdq_thread_handle_timeout(unsigned long data)
 
cmdq_thread_resume(thread);
cmdq_thread_disable(cmdq, thread);
-   clk_disable(cmdq->clock);
+   cmdq_clk_release_schedule(cmdq);
spin_unlock_irqrestore(>chan->lock, flags);
 }
 
@@ -779,7 +814,7 @@ static int cmdq_suspend(struct device *dev)
msleep(20);
}
 
-   clk_unprepare(cmdq->clock);
+   flush_workqueue(cmdq->clk_release_wq);
return 0;
 }
 
@@ -787,7 +822,6 @@ static int cmdq_resume(struct device *dev)
 {
struct cmdq *cmdq = dev_get_drvdata(dev);
 
-   WARN_ON(clk_prepare(cmdq->clock) < 0);
cmdq->suspended = false;
return 0;
 }
@@ -796,8 +830,8 @@ static int cmdq_remove(struct platform_device *pdev)
 {
struct cmdq *cmdq = platform_get_drvdata(pdev);
 
+   destroy_workqueue(cmdq->clk_release_wq);
mbox_controller_unregister(>mbox);
-   clk_unprepare(cmdq->clock);
return 0;
 }
 
@@ -916,8 +950,12 @@ static int cmdq_probe(struct platform_device *pdev)
return err;
}
 
+   cmdq->clk_release_wq = alloc_ordered_workqueue(
+   "%s", WQ_MEM_RECLAIM | WQ_HIGHPRI,
+   "cmdq_clk_release");
+
platform_set_drvdata(pdev, cmdq);
-   WARN_ON(clk_prepare(cmdq->clock) < 0);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v13 3/4] arm64: dts: mt8173: Add GCE node

[HS Liao]

This patch adds the device node of the GCE hardware for CMDQ module.

Signed-off-by: HS Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..00d9d92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -383,6 +383,16 @@
#clock-cells = <1>;
};
 
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
-- 
1.9.1

[PATCH v13 3/4] arm64: dts: mt8173: Add GCE node

[HS Liao]

This patch adds the device node of the GCE hardware for CMDQ module.

Signed-off-by: HS Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..00d9d92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -383,6 +383,16 @@
#clock-cells = <1>;
};
 
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
-- 
1.9.1

[PATCH v13 0/4] Mediatek MT8173 CMDQ support

[HS Liao]

Hi,

This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.

These patches have a build dependency on top of v4.8-rc1.

Changes since v12:
 - remove mediatek,gce from device tree

Best regards,
HS Liao

HS Liao (4):
  dt-bindings: soc: Add documentation for the MediaTek GCE unit
  CMDQ: Mediatek CMDQ driver
  arm64: dts: mt8173: Add GCE node
  CMDQ: save more energy in idle

 .../devicetree/bindings/soc/mediatek/gce.txt   |  44 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  10 +
 drivers/soc/mediatek/Kconfig   |  11 +
 drivers/soc/mediatek/Makefile  |   1 +
 drivers/soc/mediatek/mtk-cmdq.c| 983 +
 include/soc/mediatek/cmdq.h| 180 
 6 files changed, 1229 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt
 create mode 100644 drivers/soc/mediatek/mtk-cmdq.c
 create mode 100644 include/soc/mediatek/cmdq.h

-- 
1.9.1

[PATCH v13 0/4] Mediatek MT8173 CMDQ support

[HS Liao]

Hi,

This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.

These patches have a build dependency on top of v4.8-rc1.

Changes since v12:
 - remove mediatek,gce from device tree

Best regards,
HS Liao

HS Liao (4):
  dt-bindings: soc: Add documentation for the MediaTek GCE unit
  CMDQ: Mediatek CMDQ driver
  arm64: dts: mt8173: Add GCE node
  CMDQ: save more energy in idle

 .../devicetree/bindings/soc/mediatek/gce.txt   |  44 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  10 +
 drivers/soc/mediatek/Kconfig   |  11 +
 drivers/soc/mediatek/Makefile  |   1 +
 drivers/soc/mediatek/mtk-cmdq.c| 983 +
 include/soc/mediatek/cmdq.h| 180 
 6 files changed, 1229 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt
 create mode 100644 drivers/soc/mediatek/mtk-cmdq.c
 create mode 100644 include/soc/mediatek/cmdq.h

-- 
1.9.1

Re: [lkp] [x86/irq] 82ba4faca1: [No primary change] [unixbench]

[Aaron Lu]

On 08/24/2016 11:04 AM, kernel test robot wrote:
> 
> FYI, we noticed interrupts.CAL:Function_call_interrupts +771.1% improvement 
> due to commit:

This is expected.

CAL:Function_call_interrupts now contains TLB shootdowns while it
doesn't previously.

Thanks,
Aaron

> 
> commit 82ba4faca1bffad429f15c90c980ffd010366c25 ("x86/irq: Do not substract 
> irq_tlb_count from irq_call_count")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: unixbench
> on test machine: 8 threads Nehalem with 6G memory
> with following parameters:
> 
>   runtime: 300s
>   nr_task: 1
>   test: shell8
> 
> iN addition to that, the commit also has significant impact 
> (interrupts.CAL:Function_call_interrupts +1822.5%)
> on the following tests:
> 
> +--+--+
> | testcase | unixbench|
> | test machine | 8 threads Nehalem with 6G memory |
> | test parameters  | nr_task=100% |
> |  | runtime=300s |
> |  | test=execl   |
> +--+--+
> 
> 
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
> 
> Details are as below:
> -->
> 
> 
> To reproduce:
> 
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
> 
> =
> compiler/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>   
> gcc-6/x86_64-rhel/1/debian-x86_64-2015-02-07.cgz/300s/nhm-white/shell8/unixbench
> 
> commit: 
>   ace7fab7a6 ("x86/mm: Fix swap entry comment and macro")
>   82ba4faca1 ("x86/irq: Do not substract irq_tlb_count from irq_call_count")
> 
> ace7fab7a6cdd363 82ba4faca1bffad429f15c90c9 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>  48379 ±  0%+771.1% 421448 ±  0%  
> interrupts.CAL:Function_call_interrupts
>  19934 ±  8% -10.3%  17882 ±  4%  meminfo.AnonHugePages
> 177575 ±  8% -11.9% 156428 ±  7%  sched_debug.cpu.avg_idle.min
>   0.36 ± 35%+431.2%   1.93 ± 55%  sched_debug.cpu.cpu_load[0].min
>  25.84 ±  1% +11.3%  28.77 ±  4%  sched_debug.cpu.cpu_load[1].min
>   5.38 ±  3% -13.9%   4.63 ±  5%  
> sched_debug.cpu.cpu_load[1].stddev
> 
> 
> 
> 
>interrupts.CAL:Function_call_interrupts
> 
>   45 ++-+
>  O O OO O O OO O O OO O O OO O O O OO   |
>   40 ++ |
>   35 ++ |
>  |  |
>   30 ++ |
>   25 ++ |
>  |  |
>   20 ++ |
>   15 ++ |
>  |  |
>   10 ++ |
>5 *+ .**.*.*.* .**.*.*. *.*.*.*.*   .*. *.*.*.**.*   .*.* .*.*
>  | * :.*.** :.*   *+ .*  *.**   |
>0 ++--*--*---*---+
> 
> 
>   [*] bisect-good sample
>   [O] bisect-bad  sample
> 
> ***
> nhm-white: 8 threads Nehalem with 6G memory
> =
> compiler/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>   
> gcc-6/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/300s/nhm-white/execl/unixbench
> 
> commit: 
>   ace7fab7a6 ("x86/mm: Fix swap entry comment and macro")
>   82ba4faca1 ("x86/irq: Do not substract irq_tlb_count from irq_call_count")
> 
> ace7fab7a6cdd363 82ba4faca1bffad429f15c90c9 
>  -- 
>fail:runs  %reproductionfail:runs
>| | |
>  %stddev 

Re: [lkp] [x86/irq] 82ba4faca1: [No primary change] [unixbench]

[Aaron Lu]

On 08/24/2016 11:04 AM, kernel test robot wrote:
> 
> FYI, we noticed interrupts.CAL:Function_call_interrupts +771.1% improvement 
> due to commit:

This is expected.

CAL:Function_call_interrupts now contains TLB shootdowns while it
doesn't previously.

Thanks,
Aaron

> 
> commit 82ba4faca1bffad429f15c90c980ffd010366c25 ("x86/irq: Do not substract 
> irq_tlb_count from irq_call_count")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: unixbench
> on test machine: 8 threads Nehalem with 6G memory
> with following parameters:
> 
>   runtime: 300s
>   nr_task: 1
>   test: shell8
> 
> iN addition to that, the commit also has significant impact 
> (interrupts.CAL:Function_call_interrupts +1822.5%)
> on the following tests:
> 
> +--+--+
> | testcase | unixbench|
> | test machine | 8 threads Nehalem with 6G memory |
> | test parameters  | nr_task=100% |
> |  | runtime=300s |
> |  | test=execl   |
> +--+--+
> 
> 
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
> 
> Details are as below:
> -->
> 
> 
> To reproduce:
> 
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
> 
> =
> compiler/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>   
> gcc-6/x86_64-rhel/1/debian-x86_64-2015-02-07.cgz/300s/nhm-white/shell8/unixbench
> 
> commit: 
>   ace7fab7a6 ("x86/mm: Fix swap entry comment and macro")
>   82ba4faca1 ("x86/irq: Do not substract irq_tlb_count from irq_call_count")
> 
> ace7fab7a6cdd363 82ba4faca1bffad429f15c90c9 
>  -- 
>  %stddev %change %stddev
>  \  |\  
>  48379 ±  0%+771.1% 421448 ±  0%  
> interrupts.CAL:Function_call_interrupts
>  19934 ±  8% -10.3%  17882 ±  4%  meminfo.AnonHugePages
> 177575 ±  8% -11.9% 156428 ±  7%  sched_debug.cpu.avg_idle.min
>   0.36 ± 35%+431.2%   1.93 ± 55%  sched_debug.cpu.cpu_load[0].min
>  25.84 ±  1% +11.3%  28.77 ±  4%  sched_debug.cpu.cpu_load[1].min
>   5.38 ±  3% -13.9%   4.63 ±  5%  
> sched_debug.cpu.cpu_load[1].stddev
> 
> 
> 
> 
>interrupts.CAL:Function_call_interrupts
> 
>   45 ++-+
>  O O OO O O OO O O OO O O OO O O O OO   |
>   40 ++ |
>   35 ++ |
>  |  |
>   30 ++ |
>   25 ++ |
>  |  |
>   20 ++ |
>   15 ++ |
>  |  |
>   10 ++ |
>5 *+ .**.*.*.* .**.*.*. *.*.*.*.*   .*. *.*.*.**.*   .*.* .*.*
>  | * :.*.** :.*   *+ .*  *.**   |
>0 ++--*--*---*---+
> 
> 
>   [*] bisect-good sample
>   [O] bisect-bad  sample
> 
> ***
> nhm-white: 8 threads Nehalem with 6G memory
> =
> compiler/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>   
> gcc-6/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/300s/nhm-white/execl/unixbench
> 
> commit: 
>   ace7fab7a6 ("x86/mm: Fix swap entry comment and macro")
>   82ba4faca1 ("x86/irq: Do not substract irq_tlb_count from irq_call_count")
> 
> ace7fab7a6cdd363 82ba4faca1bffad429f15c90c9 
>  -- 
>fail:runs  %reproductionfail:runs
>| | |
>  %stddev 

Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

[Yuyang Du]

Hi Vincent,

On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote:
> I still wonder if using a flat util hierarchy is the right solution to
> solve this problem with utilization and task group. I have noticed
> exact same issues with load that generates weird task placement
> decision and i think that we should probably try to solve both wrong
> behavior with same mechanism. but this is not possible with flat
> hierarchy for load

I agree both util and load have the same hierarchical propagation
problem.

But util and load are different with respect to task group distribution
among CPUs and along hierarchical structure. Util is "fundamentally"
flat (CPU's util = tasks' util), so it's pretty natural as well as
simple to implement a flat hierarchy util. And because of that, I
feel util propagating up the hierarchical structure seems unnecessary.

It might be better to have a converged mechanism to solve both, but
it shouldn't be necessary. Right?

> Let me take an example.
> TA is a always running task on CPU1 in group /root/level1/
> TB wakes up on CPU0 and moves TA into group /root/level2/
> Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 0.
> Then, TB forks a new task TC. TC will probably be schedule on CPU1
> because its root cfs_rq's runnable_load_avg is null and CPU1 is the
> next CPU after CPU0
> 
> Similar behavior can happen when TA migrates
> 
> Beside flat utilization consideration, i'm going to have a look at the

Many thanks.

Yuyang

Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

[Yuyang Du]

Hi Vincent,

On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote:
> I still wonder if using a flat util hierarchy is the right solution to
> solve this problem with utilization and task group. I have noticed
> exact same issues with load that generates weird task placement
> decision and i think that we should probably try to solve both wrong
> behavior with same mechanism. but this is not possible with flat
> hierarchy for load

I agree both util and load have the same hierarchical propagation
problem.

But util and load are different with respect to task group distribution
among CPUs and along hierarchical structure. Util is "fundamentally"
flat (CPU's util = tasks' util), so it's pretty natural as well as
simple to implement a flat hierarchy util. And because of that, I
feel util propagating up the hierarchical structure seems unnecessary.

It might be better to have a converged mechanism to solve both, but
it shouldn't be necessary. Right?

> Let me take an example.
> TA is a always running task on CPU1 in group /root/level1/
> TB wakes up on CPU0 and moves TA into group /root/level2/
> Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 0.
> Then, TB forks a new task TC. TC will probably be schedule on CPU1
> because its root cfs_rq's runnable_load_avg is null and CPU1 is the
> next CPU after CPU0
> 
> Similar behavior can happen when TA migrates
> 
> Beside flat utilization consideration, i'm going to have a look at the

Many thanks.

Yuyang

RE: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Kani, Toshimitsu]

> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu 
> wrote:
> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani 
> >> wrote:
> >  :
> >> I'm not sure about this fix.  The point of honoring
> >> vmem_altmap_offset() is because a portion of the resource that is
> >> passed to devm_memremap_pages() also contains the metadata info
> block
> >> for the device.  The offset says "use everything past this point for
> >> pages".  This may work for avoiding a crash, but it may corrupt info
> >> block metadata in the process.  Can you provide more information
> >> about the failing scenario to be sure that we are not triggering a
> >> fault on an address that is not meant to have a page mapping?  I.e.
> >> what is the host physical address of the page that caused this fault,
> >> and is it valid?
> >
> > The fault address in question was the 2nd page of an NVDIMM range.  I
> > assumed this fault address was valid and needed to be handled.  Here is
> > some info about the base and patched cases.  Let me know if you need
> > more info.
> >
> > Base
> > 
> >
> > The following NVDIMM range was set to /dev/dax.
> 
> With ndctl create-namespace or manually via sysfs?  Specifically I'm
> looking for what the 'align' attribute was set to when the
> configuration was established.  Can you provide a dump of the sysfs
> attributes for the /dev/dax parent device?

I used the ndctl command below.
ndctl create-namespace -f -e namespace0.0 -m dax

Here is additional info from my note for the base case.

p {struct dev_pagemap} 0x88046d0453f0
$3 = {
  altmap = 0x88046d045410,
  res = 0x88046d0453a8,
  ref = 0x88046d0452f0,
  dev = 0x880464790410
}

crash> p {struct vmem_altmap} 0x88046d045410
$6 = {
  base_pfn = 0x48,
  reserve = 0x2,// PHYS_PFN(SZ_8K)
  free = 0x101fe,
  align = 0x1fe,
  alloc = 0x1
}

crash> p {struct resource} 0x88046d0453a8
$4 = {
  start = 0x48000,
  end = 0x87fff,
  name = 0x880c7da5d4a8 "region0",
  flags = 0x200,
  desc = 0x0,
  parent = 0x0,
  sibling = 0x0,
  child = 0x0
}

crash> p {struct percpu_ref} 0x88046d0452f0
$7 = {
  count = {
counter = 0x8001
  },
  percpu_count_ptr = 0x60f380403a98,
  release = 0xa008a0a0,
  confirm_switch = 0x0,
  force_atomic = 0x0,
  rcu = {
next = 0x0,
func = 0x0
  }
}

Thanks,
-Toshi

RE: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

[Kani, Toshimitsu]

> On Tue, Aug 23, 2016 at 4:47 PM, Kani, Toshimitsu 
> wrote:
> > On Tue, 2016-08-23 at 15:32 -0700, Dan Williams wrote:
> >> On Tue, Aug 23, 2016 at 11:43 AM, Toshi Kani 
> >> wrote:
> >  :
> >> I'm not sure about this fix.  The point of honoring
> >> vmem_altmap_offset() is because a portion of the resource that is
> >> passed to devm_memremap_pages() also contains the metadata info
> block
> >> for the device.  The offset says "use everything past this point for
> >> pages".  This may work for avoiding a crash, but it may corrupt info
> >> block metadata in the process.  Can you provide more information
> >> about the failing scenario to be sure that we are not triggering a
> >> fault on an address that is not meant to have a page mapping?  I.e.
> >> what is the host physical address of the page that caused this fault,
> >> and is it valid?
> >
> > The fault address in question was the 2nd page of an NVDIMM range.  I
> > assumed this fault address was valid and needed to be handled.  Here is
> > some info about the base and patched cases.  Let me know if you need
> > more info.
> >
> > Base
> > 
> >
> > The following NVDIMM range was set to /dev/dax.
> 
> With ndctl create-namespace or manually via sysfs?  Specifically I'm
> looking for what the 'align' attribute was set to when the
> configuration was established.  Can you provide a dump of the sysfs
> attributes for the /dev/dax parent device?

I used the ndctl command below.
ndctl create-namespace -f -e namespace0.0 -m dax

Here is additional info from my note for the base case.

p {struct dev_pagemap} 0x88046d0453f0
$3 = {
  altmap = 0x88046d045410,
  res = 0x88046d0453a8,
  ref = 0x88046d0452f0,
  dev = 0x880464790410
}

crash> p {struct vmem_altmap} 0x88046d045410
$6 = {
  base_pfn = 0x48,
  reserve = 0x2,// PHYS_PFN(SZ_8K)
  free = 0x101fe,
  align = 0x1fe,
  alloc = 0x1
}

crash> p {struct resource} 0x88046d0453a8
$4 = {
  start = 0x48000,
  end = 0x87fff,
  name = 0x880c7da5d4a8 "region0",
  flags = 0x200,
  desc = 0x0,
  parent = 0x0,
  sibling = 0x0,
  child = 0x0
}

crash> p {struct percpu_ref} 0x88046d0452f0
$7 = {
  count = {
counter = 0x8001
  },
  percpu_count_ptr = 0x60f380403a98,
  release = 0xa008a0a0,
  confirm_switch = 0x0,
  force_atomic = 0x0,
  rcu = {
next = 0x0,
func = 0x0
  }
}

Thanks,
-Toshi

[RFC][PATCH v2] timekeeping: Cap array access in timekeeping_debug to protect against invalid sleep times

[John Stultz]

It was reported that hibernation could fail on the 2nd attempt,
where the system hangs at hibernate() -> syscore_resume() ->
i8237A_resume() -> claim_dma_lock(), because the lock has
already been taken.

However there is actually no other process would like to grab
this lock on that problematic platform.

Further investigation showed that the problem is triggered by
setting /sys/power/pm_trace to 1 before the 1st hibernation.

Since once pm_trace is enabled, the RTC becomes unmeaningful
after suspend, and meanwhile some BIOSes would like to adjust
the 'invalid' RTC (e.g, smaller than 1970) to the release date
of that motherboard during POST stage, thus after resumed, it
may seem that the system had a significant long sleep time might
due to meaningless RTC delta.

Then in timekeeping_resume -> tk_debug_account_sleep_time, if
the bit31 of the sleep time happened to be set to 1, the fls
returns 32 and then we add 1 to sleep_time_bin[32], which
caused a memory overwritten.

As depicted by System.map:
0x81c9d080 b sleep_time_bin
0x81c9d100 B dma_spin_lock
the dma_spin_lock.val is set to 1, which caused this problem.

This patch adds a sanity check in tk_debug_account_sleep_time()
to ensure we don't index past the sleep_time_bin array.

Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Rafael J. Wysocki 
Cc: Janek Kozicki 
Cc: Chen Yu 
Cc: Xunlei Pang 
Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: stable 
Reported-by: Janek Kozicki 
Reported-by: Chen Yu 
[jstultz: Problem diagnosed and original patch by Chen Yu, I've
 solved the issue slightly differently, but borrowed his excelent
 explanation of of the issue here.]
Signed-off-by: John Stultz 
---
v2: Minor tweaks to the commit message

 kernel/time/timekeeping_debug.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
index f6bd652..107310a6 100644
--- a/kernel/time/timekeeping_debug.c
+++ b/kernel/time/timekeeping_debug.c
@@ -23,7 +23,9 @@
 
 #include "timekeeping_internal.h"
 
-static unsigned int sleep_time_bin[32] = {0};
+#define NUM_BINS 32
+
+static unsigned int sleep_time_bin[NUM_BINS] = {0};
 
 static int tk_debug_show_sleep_time(struct seq_file *s, void *data)
 {
@@ -69,6 +71,9 @@ late_initcall(tk_debug_sleep_time_init);
 
 void tk_debug_account_sleep_time(struct timespec64 *t)
 {
-   sleep_time_bin[fls(t->tv_sec)]++;
+   /* Cap bin index so we don't overflow the array */
+   int bin = min(fls(t->tv_sec), NUM_BINS-1);
+
+   sleep_time_bin[bin]++;
 }
 
-- 
1.9.1

Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

[Yuyang Du]

On Tue, Aug 23, 2016 at 04:13:41PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote:
> > I still wonder if using a flat util hierarchy is the right solution to
> > solve this problem with utilization and task group. I have noticed
> > exact same issues with load that generates weird task placement
> > decision and i think that we should probably try to solve both wrong
> > behavior with same mechanism. but this is not possible with flat
> > hierarchy for load
> > 
> > Let me take an example.
> > TA is a always running task on CPU1 in group /root/level1/
> > TB wakes up on CPU0 and moves TA into group /root/level2/
> > Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 
> > 0.
> 
> Because while we migrate the load_avg on /root/level2, we do not
> propagate the load_avg up the hierarchy?
> 
> And always propagating everyrthing up will indeed also fix the
> utilization issue.

Yes, but for util it's actually irrespective to the number of
hirarchical levels, just propagating directly to the top cfs_rq
or simply rq will do. In other words, it's flat :)
 
> Of course, doing that propagation has its costs..
> 
> Didn't you post a patch doing just this a while ago?

[RFC][PATCH v2] timekeeping: Cap array access in timekeeping_debug to protect against invalid sleep times

[John Stultz]

It was reported that hibernation could fail on the 2nd attempt,
where the system hangs at hibernate() -> syscore_resume() ->
i8237A_resume() -> claim_dma_lock(), because the lock has
already been taken.

However there is actually no other process would like to grab
this lock on that problematic platform.

Further investigation showed that the problem is triggered by
setting /sys/power/pm_trace to 1 before the 1st hibernation.

Since once pm_trace is enabled, the RTC becomes unmeaningful
after suspend, and meanwhile some BIOSes would like to adjust
the 'invalid' RTC (e.g, smaller than 1970) to the release date
of that motherboard during POST stage, thus after resumed, it
may seem that the system had a significant long sleep time might
due to meaningless RTC delta.

Then in timekeeping_resume -> tk_debug_account_sleep_time, if
the bit31 of the sleep time happened to be set to 1, the fls
returns 32 and then we add 1 to sleep_time_bin[32], which
caused a memory overwritten.

As depicted by System.map:
0x81c9d080 b sleep_time_bin
0x81c9d100 B dma_spin_lock
the dma_spin_lock.val is set to 1, which caused this problem.

This patch adds a sanity check in tk_debug_account_sleep_time()
to ensure we don't index past the sleep_time_bin array.

Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Rafael J. Wysocki 
Cc: Janek Kozicki 
Cc: Chen Yu 
Cc: Xunlei Pang 
Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: stable 
Reported-by: Janek Kozicki 
Reported-by: Chen Yu 
[jstultz: Problem diagnosed and original patch by Chen Yu, I've
 solved the issue slightly differently, but borrowed his excelent
 explanation of of the issue here.]
Signed-off-by: John Stultz 
---
v2: Minor tweaks to the commit message

 kernel/time/timekeeping_debug.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
index f6bd652..107310a6 100644
--- a/kernel/time/timekeeping_debug.c
+++ b/kernel/time/timekeeping_debug.c
@@ -23,7 +23,9 @@
 
 #include "timekeeping_internal.h"
 
-static unsigned int sleep_time_bin[32] = {0};
+#define NUM_BINS 32
+
+static unsigned int sleep_time_bin[NUM_BINS] = {0};
 
 static int tk_debug_show_sleep_time(struct seq_file *s, void *data)
 {
@@ -69,6 +71,9 @@ late_initcall(tk_debug_sleep_time_init);
 
 void tk_debug_account_sleep_time(struct timespec64 *t)
 {
-   sleep_time_bin[fls(t->tv_sec)]++;
+   /* Cap bin index so we don't overflow the array */
+   int bin = min(fls(t->tv_sec), NUM_BINS-1);
+
+   sleep_time_bin[bin]++;
 }
 
-- 
1.9.1

Re: [PATCH v1 00/10] Optimize sched avgs computation and implement flat util hierarchy

[Yuyang Du]

On Tue, Aug 23, 2016 at 04:13:41PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 23, 2016 at 03:28:19PM +0200, Vincent Guittot wrote:
> > I still wonder if using a flat util hierarchy is the right solution to
> > solve this problem with utilization and task group. I have noticed
> > exact same issues with load that generates weird task placement
> > decision and i think that we should probably try to solve both wrong
> > behavior with same mechanism. but this is not possible with flat
> > hierarchy for load
> > 
> > Let me take an example.
> > TA is a always running task on CPU1 in group /root/level1/
> > TB wakes up on CPU0 and moves TA into group /root/level2/
> > Even if TA stays on CPU1, runnable_load_avg of CPU1 root cfs rq will become 
> > 0.
> 
> Because while we migrate the load_avg on /root/level2, we do not
> propagate the load_avg up the hierarchy?
> 
> And always propagating everyrthing up will indeed also fix the
> utilization issue.

Yes, but for util it's actually irrespective to the number of
hirarchical levels, just propagating directly to the top cfs_rq
or simply rq will do. In other words, it's flat :)
 
> Of course, doing that propagation has its costs..
> 
> Didn't you post a patch doing just this a while ago?