Re: [PATCH] [DRM][KMS][MODE][MEDIATEK] Using the function drm_display_mode_to_videomode

[CK Hu]

Hi, Satendra:

I've applied this patch to my branch mediatek-drm-next-4.18,
and I've added below modification in this patch to prevent build error,

diff --git a/drivers/gpu/drm/mediatek/Kconfig
b/drivers/gpu/drm/mediatek/Kconfig
index 294de45..119ec0a 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -11,6 +11,7 @@ config DRM_MEDIATEK
select DRM_PANEL
select MEMORY
select MTK_SMI
+   select VIDEOMODE_HELPERS
help
  Choose this option if you have a Mediatek SoCs.
  The module will be called mediatek-drm

Regards,
CK

On Sat, 2018-03-31 at 20:17 +0530, Satendra Singh Thakur wrote:
> This patch uses existing method drm_display_mode_to_videomode for
> calculating front/back porches, sync lengths for mediatek dsi/dpi drivers; 
> instead of manually calculating them
> 
> Signed-off-by: Satendra Singh Thakur 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 60 
> +++---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 14 ++---
>  2 files changed, 32 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index e80a603..6c0ea39 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mtk_dpi_regs.h"
>  #include "mtk_drm_ddp_comp.h"
> @@ -429,34 +430,35 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   struct mtk_dpi_sync_param vsync_leven = { 0 };
>   struct mtk_dpi_sync_param vsync_rodd = { 0 };
>   struct mtk_dpi_sync_param vsync_reven = { 0 };
> - unsigned long pix_rate;
> + struct videomode vm = { 0 };
>   unsigned long pll_rate;
>   unsigned int factor;
>  
>   /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
> - pix_rate = 1000UL * mode->clock;
> +
>   if (mode->clock <= 27000)
> - factor = 16 * 3;
> + factor = 3 << 4;
>   else if (mode->clock <= 84000)
> - factor = 8 * 3;
> + factor = 3 << 3;
>   else if (mode->clock <= 167000)
> - factor = 4 * 3;
> + factor = 3 << 2;
>   else
> - factor = 2 * 3;
> - pll_rate = pix_rate * factor;
> + factor = 3 << 1;
> + drm_display_mode_to_videomode(mode, );
> + pll_rate = vm.pixelclock * factor;
>  
>   dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
> - pll_rate, pix_rate);
> + pll_rate, vm.pixelclock);
>  
>   clk_set_rate(dpi->tvd_clk, pll_rate);
>   pll_rate = clk_get_rate(dpi->tvd_clk);
>  
> - pix_rate = pll_rate / factor;
> - clk_set_rate(dpi->pixel_clk, pix_rate);
> - pix_rate = clk_get_rate(dpi->pixel_clk);
> + vm.pixelclock = pll_rate / factor;
> + clk_set_rate(dpi->pixel_clk, vm.pixelclock);
> + vm.pixelclock = clk_get_rate(dpi->pixel_clk);
>  
>   dev_dbg(dpi->dev, "Got  PLL %lu Hz, pixel clock %lu Hz\n",
> - pll_rate, pix_rate);
> + pll_rate, vm.pixelclock);
>  
>   limit.c_bottom = 0x0010;
>   limit.c_top = 0x0FE0;
> @@ -465,33 +467,31 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>  
>   dpi_pol.ck_pol = MTK_DPI_POLARITY_FALLING;
>   dpi_pol.de_pol = MTK_DPI_POLARITY_RISING;
> - dpi_pol.hsync_pol = mode->flags & DRM_MODE_FLAG_PHSYNC ?
> + dpi_pol.hsync_pol = vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ?
>   MTK_DPI_POLARITY_FALLING : MTK_DPI_POLARITY_RISING;
> - dpi_pol.vsync_pol = mode->flags & DRM_MODE_FLAG_PVSYNC ?
> + dpi_pol.vsync_pol = vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ?
>   MTK_DPI_POLARITY_FALLING : MTK_DPI_POLARITY_RISING;
> -
> - hsync.sync_width = mode->hsync_end - mode->hsync_start;
> - hsync.back_porch = mode->htotal - mode->hsync_end;
> - hsync.front_porch = mode->hsync_start - mode->hdisplay;
> + hsync.sync_width = vm.hsync_len;
> + hsync.back_porch = vm.hback_porch;
> + hsync.front_porch = vm.hfront_porch;
>   hsync.shift_half_line = false;
> -
> - vsync_lodd.sync_width = mode->vsync_end - mode->vsync_start;
> - vsync_lodd.back_porch = mode->vtotal - mode->vsync_end;
> - vsync_lodd.front_porch = mode->vsync_start - mode->vdisplay;
> + vsync_lodd.sync_width = vm.vsync_len;
> + vsync_lodd.back_porch = vm.vback_porch;
> + vsync_lodd.front_porch = vm.vfront_porch;
>   vsync_lodd.shift_half_line = false;
>  
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
> + if (vm.flags & DISPLAY_FLAGS_INTERLACED &&
>   mode->flags & DRM_MODE_FLAG_3D_MASK) {
>   vsync_leven = vsync_lodd;
>   vsync_rodd = vsync_lodd;
>   vsync_reven = vsync_lodd;
>   vsync_leven.shift_half_line = true;
>   vsync_reven.shift_half_line = true;
> 

Re: [PATCH] [DRM][KMS][MODE][MEDIATEK] Using the function drm_display_mode_to_videomode

[CK Hu]

Hi, Satendra:

I've applied this patch to my branch mediatek-drm-next-4.18,
and I've added below modification in this patch to prevent build error,

diff --git a/drivers/gpu/drm/mediatek/Kconfig
b/drivers/gpu/drm/mediatek/Kconfig
index 294de45..119ec0a 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -11,6 +11,7 @@ config DRM_MEDIATEK
select DRM_PANEL
select MEMORY
select MTK_SMI
+   select VIDEOMODE_HELPERS
help
  Choose this option if you have a Mediatek SoCs.
  The module will be called mediatek-drm

Regards,
CK

On Sat, 2018-03-31 at 20:17 +0530, Satendra Singh Thakur wrote:
> This patch uses existing method drm_display_mode_to_videomode for
> calculating front/back porches, sync lengths for mediatek dsi/dpi drivers; 
> instead of manually calculating them
> 
> Signed-off-by: Satendra Singh Thakur 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 60 
> +++---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 14 ++---
>  2 files changed, 32 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index e80a603..6c0ea39 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mtk_dpi_regs.h"
>  #include "mtk_drm_ddp_comp.h"
> @@ -429,34 +430,35 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   struct mtk_dpi_sync_param vsync_leven = { 0 };
>   struct mtk_dpi_sync_param vsync_rodd = { 0 };
>   struct mtk_dpi_sync_param vsync_reven = { 0 };
> - unsigned long pix_rate;
> + struct videomode vm = { 0 };
>   unsigned long pll_rate;
>   unsigned int factor;
>  
>   /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
> - pix_rate = 1000UL * mode->clock;
> +
>   if (mode->clock <= 27000)
> - factor = 16 * 3;
> + factor = 3 << 4;
>   else if (mode->clock <= 84000)
> - factor = 8 * 3;
> + factor = 3 << 3;
>   else if (mode->clock <= 167000)
> - factor = 4 * 3;
> + factor = 3 << 2;
>   else
> - factor = 2 * 3;
> - pll_rate = pix_rate * factor;
> + factor = 3 << 1;
> + drm_display_mode_to_videomode(mode, );
> + pll_rate = vm.pixelclock * factor;
>  
>   dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
> - pll_rate, pix_rate);
> + pll_rate, vm.pixelclock);
>  
>   clk_set_rate(dpi->tvd_clk, pll_rate);
>   pll_rate = clk_get_rate(dpi->tvd_clk);
>  
> - pix_rate = pll_rate / factor;
> - clk_set_rate(dpi->pixel_clk, pix_rate);
> - pix_rate = clk_get_rate(dpi->pixel_clk);
> + vm.pixelclock = pll_rate / factor;
> + clk_set_rate(dpi->pixel_clk, vm.pixelclock);
> + vm.pixelclock = clk_get_rate(dpi->pixel_clk);
>  
>   dev_dbg(dpi->dev, "Got  PLL %lu Hz, pixel clock %lu Hz\n",
> - pll_rate, pix_rate);
> + pll_rate, vm.pixelclock);
>  
>   limit.c_bottom = 0x0010;
>   limit.c_top = 0x0FE0;
> @@ -465,33 +467,31 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>  
>   dpi_pol.ck_pol = MTK_DPI_POLARITY_FALLING;
>   dpi_pol.de_pol = MTK_DPI_POLARITY_RISING;
> - dpi_pol.hsync_pol = mode->flags & DRM_MODE_FLAG_PHSYNC ?
> + dpi_pol.hsync_pol = vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ?
>   MTK_DPI_POLARITY_FALLING : MTK_DPI_POLARITY_RISING;
> - dpi_pol.vsync_pol = mode->flags & DRM_MODE_FLAG_PVSYNC ?
> + dpi_pol.vsync_pol = vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ?
>   MTK_DPI_POLARITY_FALLING : MTK_DPI_POLARITY_RISING;
> -
> - hsync.sync_width = mode->hsync_end - mode->hsync_start;
> - hsync.back_porch = mode->htotal - mode->hsync_end;
> - hsync.front_porch = mode->hsync_start - mode->hdisplay;
> + hsync.sync_width = vm.hsync_len;
> + hsync.back_porch = vm.hback_porch;
> + hsync.front_porch = vm.hfront_porch;
>   hsync.shift_half_line = false;
> -
> - vsync_lodd.sync_width = mode->vsync_end - mode->vsync_start;
> - vsync_lodd.back_porch = mode->vtotal - mode->vsync_end;
> - vsync_lodd.front_porch = mode->vsync_start - mode->vdisplay;
> + vsync_lodd.sync_width = vm.vsync_len;
> + vsync_lodd.back_porch = vm.vback_porch;
> + vsync_lodd.front_porch = vm.vfront_porch;
>   vsync_lodd.shift_half_line = false;
>  
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
> + if (vm.flags & DISPLAY_FLAGS_INTERLACED &&
>   mode->flags & DRM_MODE_FLAG_3D_MASK) {
>   vsync_leven = vsync_lodd;
>   vsync_rodd = vsync_lodd;
>   vsync_reven = vsync_lodd;
>   vsync_leven.shift_half_line = true;
>   vsync_reven.shift_half_line = true;
> - } else if (mode->flags & 

[tip:perf/urgent] perf evsel: Only fall back group read for leader

[tip-bot for Kan Liang]

Commit-ID:  121f325f34caf9a7654ec8a50e20942ed9d6dafc
Gitweb: https://git.kernel.org/tip/121f325f34caf9a7654ec8a50e20942ed9d6dafc
Author: Kan Liang 
AuthorDate: Tue, 24 Apr 2018 11:20:12 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 24 Apr 2018 16:11:59 -0300

perf evsel: Only fall back group read for leader

Perf doesn't support mixed events from different PMUs (except software
event) in a group. The perf stat should output / for all events, but it doesn't. For example,

  perf stat -e '{cycles,uncore_imc_5/umask=0xF,event=0x4/,instructions}'
 cycles
   uncore_imc_5/umask=0xF,event=0x4/
   1,024,300  instructions

If perf fails to open an event, it doesn't error out directly. It will
disable some features and retry, until the event is opened or all
features are disabled. The disabled features will not be re-enabled. The
group read is one of these features.

For the example as above, the IMC event and the leader event "cycles"
are from different PMUs. Opening the IMC event must fail. The group read
feature must be disabled for IMC event and the followed event
"instructions". The "instructions" event has the same PMU as the leader
"cycles". It can be opened successfully. Since the group read feature
has been disabled, the "instructions" event will be read as a single
event, which definitely has a value.

The group read fallback is still useful for the case which kernel
doesn't support group read. It is good enough to be handled only by the
leader.

For the fallback request from members, it must be caused by an error.
The fallback only breaks the semantics of group.  Limit the group read
fallback only for the leader.

Committer testing:

On a broadwell t450s notebook:

Before:

  # perf stat -e '{cycles,unc_cbo_cache_lookup.read_i,instructions}' sleep 1

  Performance counter stats for 'sleep 1':

   cycles
 unc_cbo_cache_lookup.read_i
   818,206  instructions

   1.003170887 seconds time elapsed

  Some events weren't counted. Try disabling the NMI watchdog:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog

After:

  # perf stat -e '{cycles,unc_cbo_cache_lookup.read_i,instructions}' sleep 1

  Performance counter stats for 'sleep 1':

   cycles
 unc_cbo_cache_lookup.read_i
   instructions

   1.001380511 seconds time elapsed

  Some events weren't counted. Try disabling the NMI watchdog:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog
  #

Reported-by: Andi Kleen 
Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Agustin Vega-Frias 
Cc: Ganapatrao Kulkarni 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Shaokun Zhang 
Cc: Will Deacon 
Fixes:  82bf311e15d2 ("perf stat: Use group read for event groups")
Link: 
http://lkml.kernel.org/r/1524594014-79243-3-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 26bdeecc0452..4cd2cf93f726 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1925,7 +1925,8 @@ try_fallback:
goto fallback_missing_features;
} else if (!perf_missing_features.group_read &&
evsel->attr.inherit &&
-  (evsel->attr.read_format & PERF_FORMAT_GROUP)) {
+  (evsel->attr.read_format & PERF_FORMAT_GROUP) &&
+  perf_evsel__is_group_leader(evsel)) {
perf_missing_features.group_read = true;
pr_debug2("switching off group read\n");
goto fallback_missing_features;

[tip:perf/urgent] perf evsel: Only fall back group read for leader

[tip-bot for Kan Liang]

Commit-ID:  121f325f34caf9a7654ec8a50e20942ed9d6dafc
Gitweb: https://git.kernel.org/tip/121f325f34caf9a7654ec8a50e20942ed9d6dafc
Author: Kan Liang 
AuthorDate: Tue, 24 Apr 2018 11:20:12 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 24 Apr 2018 16:11:59 -0300

perf evsel: Only fall back group read for leader

Perf doesn't support mixed events from different PMUs (except software
event) in a group. The perf stat should output / for all events, but it doesn't. For example,

  perf stat -e '{cycles,uncore_imc_5/umask=0xF,event=0x4/,instructions}'
 cycles
   uncore_imc_5/umask=0xF,event=0x4/
   1,024,300  instructions

If perf fails to open an event, it doesn't error out directly. It will
disable some features and retry, until the event is opened or all
features are disabled. The disabled features will not be re-enabled. The
group read is one of these features.

For the example as above, the IMC event and the leader event "cycles"
are from different PMUs. Opening the IMC event must fail. The group read
feature must be disabled for IMC event and the followed event
"instructions". The "instructions" event has the same PMU as the leader
"cycles". It can be opened successfully. Since the group read feature
has been disabled, the "instructions" event will be read as a single
event, which definitely has a value.

The group read fallback is still useful for the case which kernel
doesn't support group read. It is good enough to be handled only by the
leader.

For the fallback request from members, it must be caused by an error.
The fallback only breaks the semantics of group.  Limit the group read
fallback only for the leader.

Committer testing:

On a broadwell t450s notebook:

Before:

  # perf stat -e '{cycles,unc_cbo_cache_lookup.read_i,instructions}' sleep 1

  Performance counter stats for 'sleep 1':

   cycles
 unc_cbo_cache_lookup.read_i
   818,206  instructions

   1.003170887 seconds time elapsed

  Some events weren't counted. Try disabling the NMI watchdog:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog

After:

  # perf stat -e '{cycles,unc_cbo_cache_lookup.read_i,instructions}' sleep 1

  Performance counter stats for 'sleep 1':

   cycles
 unc_cbo_cache_lookup.read_i
   instructions

   1.001380511 seconds time elapsed

  Some events weren't counted. Try disabling the NMI watchdog:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog
  #

Reported-by: Andi Kleen 
Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Agustin Vega-Frias 
Cc: Ganapatrao Kulkarni 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Shaokun Zhang 
Cc: Will Deacon 
Fixes:  82bf311e15d2 ("perf stat: Use group read for event groups")
Link: 
http://lkml.kernel.org/r/1524594014-79243-3-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 26bdeecc0452..4cd2cf93f726 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1925,7 +1925,8 @@ try_fallback:
goto fallback_missing_features;
} else if (!perf_missing_features.group_read &&
evsel->attr.inherit &&
-  (evsel->attr.read_format & PERF_FORMAT_GROUP)) {
+  (evsel->attr.read_format & PERF_FORMAT_GROUP) &&
+  perf_evsel__is_group_leader(evsel)) {
perf_missing_features.group_read = true;
pr_debug2("switching off group read\n");
goto fallback_missing_features;

[tip:perf/urgent] perf stat: Print out hint for mixed PMU group error

[tip-bot for Kan Liang]

Commit-ID:  30060eaed769039c6e523b9d159f2b2858fa8907
Gitweb: https://git.kernel.org/tip/30060eaed769039c6e523b9d159f2b2858fa8907
Author: Kan Liang 
AuthorDate: Tue, 24 Apr 2018 11:20:11 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 24 Apr 2018 16:11:59 -0300

perf stat: Print out hint for mixed PMU group error

Perf doesn't support mixed events from different PMUs (except software
event) in a group. For this case, only "" or "" are printed out. There is no hint which guides users to fix
the issue.

Checking the PMU type of events to determine if they are from the same
PMU. There may be false alarm for the checking. E.g. the core PMU has
different PMU type. But it should not happen often.

The false alarm can also be tolerated, because:

- It only happens on error path.
- It just provides a possible solution for the issue.

Signed-off-by: Kan Liang 
Cc: Agustin Vega-Frias 
Cc: Andi Kleen 
Cc: Ganapatrao Kulkarni 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Shaokun Zhang 
Cc: Will Deacon 
Link: 
http://lkml.kernel.org/r/1524594014-79243-2-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 147a27e8c937..30e6b374e095 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -172,6 +172,7 @@ static bool interval_count;
 static const char  *output_name;
 static int output_fd;
 static int print_free_counters_hint;
+static int print_mixed_hw_group_error;
 
 struct perf_stat {
bool record;
@@ -1126,6 +1127,30 @@ static void abs_printout(int id, int nr, struct 
perf_evsel *evsel, double avg)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
 }
 
+static bool is_mixed_hw_group(struct perf_evsel *counter)
+{
+   struct perf_evlist *evlist = counter->evlist;
+   u32 pmu_type = counter->attr.type;
+   struct perf_evsel *pos;
+
+   if (counter->nr_members < 2)
+   return false;
+
+   evlist__for_each_entry(evlist, pos) {
+   /* software events can be part of any hardware group */
+   if (pos->attr.type == PERF_TYPE_SOFTWARE)
+   continue;
+   if (pmu_type == PERF_TYPE_SOFTWARE) {
+   pmu_type = pos->attr.type;
+   continue;
+   }
+   if (pmu_type != pos->attr.type)
+   return true;
+   }
+
+   return false;
+}
+
 static void printout(int id, int nr, struct perf_evsel *counter, double uval,
 char *prefix, u64 run, u64 ena, double noise,
 struct runtime_stat *st)
@@ -1178,8 +1203,11 @@ static void printout(int id, int nr, struct perf_evsel 
*counter, double uval,
counter->supported ? CNTR_NOT_COUNTED : 
CNTR_NOT_SUPPORTED,
csv_sep);
 
-   if (counter->supported)
+   if (counter->supported) {
print_free_counters_hint = 1;
+   if (is_mixed_hw_group(counter))
+   print_mixed_hw_group_error = 1;
+   }
 
fprintf(stat_config.output, "%-*s%s",
csv_output ? 0 : unit_width,
@@ -1757,6 +1785,11 @@ static void print_footer(void)
 "  echo 0 > /proc/sys/kernel/nmi_watchdog\n"
 "  perf stat ...\n"
 "  echo 1 > /proc/sys/kernel/nmi_watchdog\n");
+
+   if (print_mixed_hw_group_error)
+   fprintf(output,
+   "The events in group usually have to be from "
+   "the same PMU. Try reorganizing the group.\n");
 }
 
 static void print_counters(struct timespec *ts, int argc, const char **argv)

[tip:perf/urgent] perf stat: Print out hint for mixed PMU group error

[tip-bot for Kan Liang]

Commit-ID:  30060eaed769039c6e523b9d159f2b2858fa8907
Gitweb: https://git.kernel.org/tip/30060eaed769039c6e523b9d159f2b2858fa8907
Author: Kan Liang 
AuthorDate: Tue, 24 Apr 2018 11:20:11 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 24 Apr 2018 16:11:59 -0300

perf stat: Print out hint for mixed PMU group error

Perf doesn't support mixed events from different PMUs (except software
event) in a group. For this case, only "" or "" are printed out. There is no hint which guides users to fix
the issue.

Checking the PMU type of events to determine if they are from the same
PMU. There may be false alarm for the checking. E.g. the core PMU has
different PMU type. But it should not happen often.

The false alarm can also be tolerated, because:

- It only happens on error path.
- It just provides a possible solution for the issue.

Signed-off-by: Kan Liang 
Cc: Agustin Vega-Frias 
Cc: Andi Kleen 
Cc: Ganapatrao Kulkarni 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Shaokun Zhang 
Cc: Will Deacon 
Link: 
http://lkml.kernel.org/r/1524594014-79243-2-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 147a27e8c937..30e6b374e095 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -172,6 +172,7 @@ static bool interval_count;
 static const char  *output_name;
 static int output_fd;
 static int print_free_counters_hint;
+static int print_mixed_hw_group_error;
 
 struct perf_stat {
bool record;
@@ -1126,6 +1127,30 @@ static void abs_printout(int id, int nr, struct 
perf_evsel *evsel, double avg)
fprintf(output, "%s%s", csv_sep, evsel->cgrp->name);
 }
 
+static bool is_mixed_hw_group(struct perf_evsel *counter)
+{
+   struct perf_evlist *evlist = counter->evlist;
+   u32 pmu_type = counter->attr.type;
+   struct perf_evsel *pos;
+
+   if (counter->nr_members < 2)
+   return false;
+
+   evlist__for_each_entry(evlist, pos) {
+   /* software events can be part of any hardware group */
+   if (pos->attr.type == PERF_TYPE_SOFTWARE)
+   continue;
+   if (pmu_type == PERF_TYPE_SOFTWARE) {
+   pmu_type = pos->attr.type;
+   continue;
+   }
+   if (pmu_type != pos->attr.type)
+   return true;
+   }
+
+   return false;
+}
+
 static void printout(int id, int nr, struct perf_evsel *counter, double uval,
 char *prefix, u64 run, u64 ena, double noise,
 struct runtime_stat *st)
@@ -1178,8 +1203,11 @@ static void printout(int id, int nr, struct perf_evsel 
*counter, double uval,
counter->supported ? CNTR_NOT_COUNTED : 
CNTR_NOT_SUPPORTED,
csv_sep);
 
-   if (counter->supported)
+   if (counter->supported) {
print_free_counters_hint = 1;
+   if (is_mixed_hw_group(counter))
+   print_mixed_hw_group_error = 1;
+   }
 
fprintf(stat_config.output, "%-*s%s",
csv_output ? 0 : unit_width,
@@ -1757,6 +1785,11 @@ static void print_footer(void)
 "  echo 0 > /proc/sys/kernel/nmi_watchdog\n"
 "  perf stat ...\n"
 "  echo 1 > /proc/sys/kernel/nmi_watchdog\n");
+
+   if (print_mixed_hw_group_error)
+   fprintf(output,
+   "The events in group usually have to be from "
+   "the same PMU. Try reorganizing the group.\n");
 }
 
 static void print_counters(struct timespec *ts, int argc, const char **argv)

[tip:perf/urgent] perf pmu: Fix core PMU alias list for X86 platform

[tip-bot for Kan Liang]

Commit-ID:  292c34c10249c64a70def442f0d977bf9d466ed7
Gitweb: https://git.kernel.org/tip/292c34c10249c64a70def442f0d977bf9d466ed7
Author: Kan Liang 
AuthorDate: Tue, 24 Apr 2018 11:20:10 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 24 Apr 2018 16:02:29 -0300

perf pmu: Fix core PMU alias list for X86 platform

When counting uncore event with alias, core event is mistakenly
involved, for example:

  perf stat --no-merge -e "unc_m_cas_count.all" -C0  sleep 1

  Performance counter stats for 'CPU(s) 0':

 0  unc_m_cas_count.all [uncore_imc_4]
 0  unc_m_cas_count.all [uncore_imc_2]
 0  unc_m_cas_count.all [uncore_imc_0]
   153,640  unc_m_cas_count.all [cpu]
 0  unc_m_cas_count.all [uncore_imc_5]
25,026  unc_m_cas_count.all [uncore_imc_3]
 0  unc_m_cas_count.all [uncore_imc_1]

   1.001447890 seconds time elapsed

The reason is that current implementation doesn't check PMU name of a
event when adding its alias into the alias list for core PMU. The
uncore event aliases are mistakenly added.

This bug was introduced in:
  commit 14b22ae028de ("perf pmu: Add helper function is_pmu_core to
  detect PMU CORE devices")

Checking the PMU name for all PMUs on X86 and other architectures except
ARM.
There is no behavior change for ARM.

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Agustin Vega-Frias 
Cc: Andi Kleen 
Cc: Ganapatrao Kulkarni 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Shaokun Zhang 
Cc: Will Deacon 
Fixes: 14b22ae028de ("perf pmu: Add helper function is_pmu_core to detect PMU 
CORE devices")
Link: 
http://lkml.kernel.org/r/1524594014-79243-1-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index af4bedf4cf98..d2fb597c9a8c 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -539,9 +539,10 @@ static bool pmu_is_uncore(const char *name)
 
 /*
  *  PMU CORE devices have different name other than cpu in sysfs on some
- *  platforms. looking for possible sysfs files to identify as core device.
+ *  platforms.
+ *  Looking for possible sysfs files to identify the arm core device.
  */
-static int is_pmu_core(const char *name)
+static int is_arm_pmu_core(const char *name)
 {
struct stat st;
char path[PATH_MAX];
@@ -550,12 +551,6 @@ static int is_pmu_core(const char *name)
if (!sysfs)
return 0;
 
-   /* Look for cpu sysfs (x86 and others) */
-   scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
-   if ((stat(path, ) == 0) &&
-   (strncmp(name, "cpu", strlen("cpu")) == 0))
-   return 1;
-
/* Look for cpu sysfs (specific to arm) */
scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
sysfs, name);
@@ -668,6 +663,7 @@ static void pmu_add_cpu_aliases(struct list_head *head, 
struct perf_pmu *pmu)
struct pmu_events_map *map;
struct pmu_event *pe;
const char *name = pmu->name;
+   const char *pname;
 
map = perf_pmu__find_map(pmu);
if (!map)
@@ -686,11 +682,9 @@ static void pmu_add_cpu_aliases(struct list_head *head, 
struct perf_pmu *pmu)
break;
}
 
-   if (!is_pmu_core(name)) {
-   /* check for uncore devices */
-   if (pe->pmu == NULL)
-   continue;
-   if (strncmp(pe->pmu, name, strlen(pe->pmu)))
+   if (!is_arm_pmu_core(name)) {
+   pname = pe->pmu ? pe->pmu : "cpu";
+   if (strncmp(pname, name, strlen(pname)))
continue;
}
 

[tip:perf/urgent] perf pmu: Fix core PMU alias list for X86 platform

[tip-bot for Kan Liang]

Commit-ID:  292c34c10249c64a70def442f0d977bf9d466ed7
Gitweb: https://git.kernel.org/tip/292c34c10249c64a70def442f0d977bf9d466ed7
Author: Kan Liang 
AuthorDate: Tue, 24 Apr 2018 11:20:10 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 24 Apr 2018 16:02:29 -0300

perf pmu: Fix core PMU alias list for X86 platform

When counting uncore event with alias, core event is mistakenly
involved, for example:

  perf stat --no-merge -e "unc_m_cas_count.all" -C0  sleep 1

  Performance counter stats for 'CPU(s) 0':

 0  unc_m_cas_count.all [uncore_imc_4]
 0  unc_m_cas_count.all [uncore_imc_2]
 0  unc_m_cas_count.all [uncore_imc_0]
   153,640  unc_m_cas_count.all [cpu]
 0  unc_m_cas_count.all [uncore_imc_5]
25,026  unc_m_cas_count.all [uncore_imc_3]
 0  unc_m_cas_count.all [uncore_imc_1]

   1.001447890 seconds time elapsed

The reason is that current implementation doesn't check PMU name of a
event when adding its alias into the alias list for core PMU. The
uncore event aliases are mistakenly added.

This bug was introduced in:
  commit 14b22ae028de ("perf pmu: Add helper function is_pmu_core to
  detect PMU CORE devices")

Checking the PMU name for all PMUs on X86 and other architectures except
ARM.
There is no behavior change for ARM.

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Agustin Vega-Frias 
Cc: Andi Kleen 
Cc: Ganapatrao Kulkarni 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Shaokun Zhang 
Cc: Will Deacon 
Fixes: 14b22ae028de ("perf pmu: Add helper function is_pmu_core to detect PMU 
CORE devices")
Link: 
http://lkml.kernel.org/r/1524594014-79243-1-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index af4bedf4cf98..d2fb597c9a8c 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -539,9 +539,10 @@ static bool pmu_is_uncore(const char *name)
 
 /*
  *  PMU CORE devices have different name other than cpu in sysfs on some
- *  platforms. looking for possible sysfs files to identify as core device.
+ *  platforms.
+ *  Looking for possible sysfs files to identify the arm core device.
  */
-static int is_pmu_core(const char *name)
+static int is_arm_pmu_core(const char *name)
 {
struct stat st;
char path[PATH_MAX];
@@ -550,12 +551,6 @@ static int is_pmu_core(const char *name)
if (!sysfs)
return 0;
 
-   /* Look for cpu sysfs (x86 and others) */
-   scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
-   if ((stat(path, ) == 0) &&
-   (strncmp(name, "cpu", strlen("cpu")) == 0))
-   return 1;
-
/* Look for cpu sysfs (specific to arm) */
scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
sysfs, name);
@@ -668,6 +663,7 @@ static void pmu_add_cpu_aliases(struct list_head *head, 
struct perf_pmu *pmu)
struct pmu_events_map *map;
struct pmu_event *pe;
const char *name = pmu->name;
+   const char *pname;
 
map = perf_pmu__find_map(pmu);
if (!map)
@@ -686,11 +682,9 @@ static void pmu_add_cpu_aliases(struct list_head *head, 
struct perf_pmu *pmu)
break;
}
 
-   if (!is_pmu_core(name)) {
-   /* check for uncore devices */
-   if (pe->pmu == NULL)
-   continue;
-   if (strncmp(pe->pmu, name, strlen(pe->pmu)))
+   if (!is_arm_pmu_core(name)) {
+   pname = pe->pmu ? pe->pmu : "cpu";
+   if (strncmp(pname, name, strlen(pname)))
continue;
}
 

[tip:perf/urgent] perf record: Fix s390 undefined record__auxtrace_init() return value

[tip-bot for Thomas Richter]

Commit-ID:  5d9946c3e5e38e07ab7019db9413a96807a325f2
Gitweb: https://git.kernel.org/tip/5d9946c3e5e38e07ab7019db9413a96807a325f2
Author: Thomas Richter 
AuthorDate: Mon, 23 Apr 2018 16:29:40 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 12:05:02 -0300

perf record: Fix s390 undefined record__auxtrace_init() return value

Command 'perf record' calls:

  cmd_report()
record__auxtrace_init()
   auxtrace_record__init()

On s390 function auxtrace_record__init() returns random return value due
to missing initialization.

This sometime causes 'perf record' to exit immediately without error
message and creating a perf.data file.

Fix this by setting error the return code to zero before returning from
platform specific functions which may not set the error code in call
cases.

Signed-off-by: Thomas Richter 
Cc: Heiko Carstens 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180423142940.21143-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/auxtrace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/arch/s390/util/auxtrace.c 
b/tools/perf/arch/s390/util/auxtrace.c
index 6cb48e4cffd9..3afe8256eff2 100644
--- a/tools/perf/arch/s390/util/auxtrace.c
+++ b/tools/perf/arch/s390/util/auxtrace.c
@@ -87,6 +87,7 @@ struct auxtrace_record *auxtrace_record__init(struct 
perf_evlist *evlist,
struct perf_evsel *pos;
int diagnose = 0;
 
+   *err = 0;
if (evlist->nr_entries == 0)
return NULL;
 

[tip:perf/urgent] perf record: Fix s390 undefined record__auxtrace_init() return value

[tip-bot for Thomas Richter]

Commit-ID:  5d9946c3e5e38e07ab7019db9413a96807a325f2
Gitweb: https://git.kernel.org/tip/5d9946c3e5e38e07ab7019db9413a96807a325f2
Author: Thomas Richter 
AuthorDate: Mon, 23 Apr 2018 16:29:40 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 12:05:02 -0300

perf record: Fix s390 undefined record__auxtrace_init() return value

Command 'perf record' calls:

  cmd_report()
record__auxtrace_init()
   auxtrace_record__init()

On s390 function auxtrace_record__init() returns random return value due
to missing initialization.

This sometime causes 'perf record' to exit immediately without error
message and creating a perf.data file.

Fix this by setting error the return code to zero before returning from
platform specific functions which may not set the error code in call
cases.

Signed-off-by: Thomas Richter 
Cc: Heiko Carstens 
Cc: Hendrik Brueckner 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180423142940.21143-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/auxtrace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/arch/s390/util/auxtrace.c 
b/tools/perf/arch/s390/util/auxtrace.c
index 6cb48e4cffd9..3afe8256eff2 100644
--- a/tools/perf/arch/s390/util/auxtrace.c
+++ b/tools/perf/arch/s390/util/auxtrace.c
@@ -87,6 +87,7 @@ struct auxtrace_record *auxtrace_record__init(struct 
perf_evlist *evlist,
struct perf_evsel *pos;
int diagnose = 0;
 
+   *err = 0;
if (evlist->nr_entries == 0)
return NULL;
 

[tip:perf/urgent] perf evsel: Disable write_backward for leader sampling group events

[tip-bot for Jiri Olsa]

Commit-ID:  e9add8bac6c69edb4bf391e537faa659b2ed70d2
Gitweb: https://git.kernel.org/tip/e9add8bac6c69edb4bf391e537faa659b2ed70d2
Author: Jiri Olsa 
AuthorDate: Mon, 23 Apr 2018 11:08:19 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:21:56 -0300

perf evsel: Disable write_backward for leader sampling group events

.. and other related fields that do not need to be enabled
for events that have sampling leader.

It fixes the perf top usage Ingo reported broken:

  # perf top -e '{cycles,msr/aperf/}:S'

The 'msr/aperf/' event is configured for write_back sampling, which is
not allowed by the MSR PMU, so it fails to create the event.

Adjusting related attr test.

Reported-by: Ingo Molnar 
Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180423090823.32309-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/attr/test-record-group-sampling | 3 +++
 tools/perf/util/evsel.c  | 7 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/attr/test-record-group-sampling 
b/tools/perf/tests/attr/test-record-group-sampling
index f906b793196f..8a33ca4f9e1f 100644
--- a/tools/perf/tests/attr/test-record-group-sampling
+++ b/tools/perf/tests/attr/test-record-group-sampling
@@ -35,3 +35,6 @@ inherit=0
 # sampling disabled
 sample_freq=0
 sample_period=0
+freq=0
+write_backward=0
+sample_id_all=0
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7eb1e9850abf..26bdeecc0452 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -930,8 +930,11 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts,
 * than leader in case leader 'leads' the sampling.
 */
if ((leader != evsel) && leader->sample_read) {
-   attr->sample_freq   = 0;
-   attr->sample_period = 0;
+   attr->freq   = 0;
+   attr->sample_freq= 0;
+   attr->sample_period  = 0;
+   attr->write_backward = 0;
+   attr->sample_id_all  = 0;
}
 
if (opts->no_samples)

[tip:perf/urgent] perf evsel: Disable write_backward for leader sampling group events

[tip-bot for Jiri Olsa]

Commit-ID:  e9add8bac6c69edb4bf391e537faa659b2ed70d2
Gitweb: https://git.kernel.org/tip/e9add8bac6c69edb4bf391e537faa659b2ed70d2
Author: Jiri Olsa 
AuthorDate: Mon, 23 Apr 2018 11:08:19 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:21:56 -0300

perf evsel: Disable write_backward for leader sampling group events

.. and other related fields that do not need to be enabled
for events that have sampling leader.

It fixes the perf top usage Ingo reported broken:

  # perf top -e '{cycles,msr/aperf/}:S'

The 'msr/aperf/' event is configured for write_back sampling, which is
not allowed by the MSR PMU, so it fails to create the event.

Adjusting related attr test.

Reported-by: Ingo Molnar 
Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180423090823.32309-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/attr/test-record-group-sampling | 3 +++
 tools/perf/util/evsel.c  | 7 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/attr/test-record-group-sampling 
b/tools/perf/tests/attr/test-record-group-sampling
index f906b793196f..8a33ca4f9e1f 100644
--- a/tools/perf/tests/attr/test-record-group-sampling
+++ b/tools/perf/tests/attr/test-record-group-sampling
@@ -35,3 +35,6 @@ inherit=0
 # sampling disabled
 sample_freq=0
 sample_period=0
+freq=0
+write_backward=0
+sample_id_all=0
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7eb1e9850abf..26bdeecc0452 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -930,8 +930,11 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts,
 * than leader in case leader 'leads' the sampling.
 */
if ((leader != evsel) && leader->sample_read) {
-   attr->sample_freq   = 0;
-   attr->sample_period = 0;
+   attr->freq   = 0;
+   attr->sample_freq= 0;
+   attr->sample_period  = 0;
+   attr->write_backward = 0;
+   attr->sample_id_all  = 0;
}
 
if (opts->no_samples)

[tip:perf/urgent] perf mem: Document incorrect and missing options

[tip-bot for Sangwon Hong]

Commit-ID:  3138a2ef62667b6ac8eb5fb33a9e0b84ec3ab165
Gitweb: https://git.kernel.org/tip/3138a2ef62667b6ac8eb5fb33a9e0b84ec3ab165
Author: Sangwon Hong 
AuthorDate: Sun, 22 Apr 2018 16:29:06 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:59:18 -0300

perf mem: Document incorrect and missing options

Several options were incorrectly described, some lacked describing
required arguments while others were simply not documented, fix it.

Signed-off-by: Sangwon Hong 
Acked-by: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Taeung Song 
Link: 
http://lkml.kernel.org/r/1524382146-19609-1-git-send-email-qpa...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-mem.txt | 41 +--
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/tools/perf/Documentation/perf-mem.txt 
b/tools/perf/Documentation/perf-mem.txt
index 8806ed5f3802..f8d2167cf3e7 100644
--- a/tools/perf/Documentation/perf-mem.txt
+++ b/tools/perf/Documentation/perf-mem.txt
@@ -28,29 +28,46 @@ OPTIONS
 ...::
Any command you can specify in a shell.
 
+-i::
+--input=::
+   Input file name.
+
 -f::
 --force::
Don't do ownership validation
 
 -t::
---type=::
+--type=::
Select the memory operation type: load or store (default: load,store)
 
 -D::
---dump-raw-samples=::
+--dump-raw-samples::
Dump the raw decoded samples on the screen in a format that is easy to 
parse with
one sample per line.
 
 -x::
---field-separator::
+--field-separator=::
Specify the field separator used when dump raw samples (-D option). By 
default,
The separator is the space character.
 
 -C::
---cpu-list::
-   Restrict dump of raw samples to those provided via this option. Note 
that the same
-   option can be passed in record mode. It will be interpreted the same 
way as perf
-   record.
+--cpu=::
+   Monitor only on the list of CPUs provided. Multiple CPUs can be 
provided as a
+comma-separated list with no space: 0,1. Ranges of CPUs are specified 
with -: 0-2. Default
+is to monitor all CPUS.
+-U::
+--hide-unresolved::
+   Only display entries resolved to a symbol.
+
+-p::
+--phys-data::
+   Record/Report sample physical addresses
+
+RECORD OPTIONS
+--
+-e::
+--event ::
+   Event selector. Use 'perf mem record -e list' to list available events.
 
 -K::
 --all-kernel::
@@ -60,12 +77,12 @@ OPTIONS
 --all-user::
Configure all used events to run in user space.
 
---ldload::
-   Specify desired latency for loads event.
+-v::
+--verbose::
+   Be more verbose (show counter open errors, etc)
 
--p::
---phys-data::
-   Record/Report sample physical addresses
+--ldlat ::
+   Specify desired latency for loads event.
 
 In addition, for report all perf report options are valid, and for record
 all perf record options.

[tip:perf/urgent] perf mem: Document incorrect and missing options

[tip-bot for Sangwon Hong]

Commit-ID:  3138a2ef62667b6ac8eb5fb33a9e0b84ec3ab165
Gitweb: https://git.kernel.org/tip/3138a2ef62667b6ac8eb5fb33a9e0b84ec3ab165
Author: Sangwon Hong 
AuthorDate: Sun, 22 Apr 2018 16:29:06 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:59:18 -0300

perf mem: Document incorrect and missing options

Several options were incorrectly described, some lacked describing
required arguments while others were simply not documented, fix it.

Signed-off-by: Sangwon Hong 
Acked-by: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Taeung Song 
Link: 
http://lkml.kernel.org/r/1524382146-19609-1-git-send-email-qpa...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-mem.txt | 41 +--
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/tools/perf/Documentation/perf-mem.txt 
b/tools/perf/Documentation/perf-mem.txt
index 8806ed5f3802..f8d2167cf3e7 100644
--- a/tools/perf/Documentation/perf-mem.txt
+++ b/tools/perf/Documentation/perf-mem.txt
@@ -28,29 +28,46 @@ OPTIONS
 ...::
Any command you can specify in a shell.
 
+-i::
+--input=::
+   Input file name.
+
 -f::
 --force::
Don't do ownership validation
 
 -t::
---type=::
+--type=::
Select the memory operation type: load or store (default: load,store)
 
 -D::
---dump-raw-samples=::
+--dump-raw-samples::
Dump the raw decoded samples on the screen in a format that is easy to 
parse with
one sample per line.
 
 -x::
---field-separator::
+--field-separator=::
Specify the field separator used when dump raw samples (-D option). By 
default,
The separator is the space character.
 
 -C::
---cpu-list::
-   Restrict dump of raw samples to those provided via this option. Note 
that the same
-   option can be passed in record mode. It will be interpreted the same 
way as perf
-   record.
+--cpu=::
+   Monitor only on the list of CPUs provided. Multiple CPUs can be 
provided as a
+comma-separated list with no space: 0,1. Ranges of CPUs are specified 
with -: 0-2. Default
+is to monitor all CPUS.
+-U::
+--hide-unresolved::
+   Only display entries resolved to a symbol.
+
+-p::
+--phys-data::
+   Record/Report sample physical addresses
+
+RECORD OPTIONS
+--
+-e::
+--event ::
+   Event selector. Use 'perf mem record -e list' to list available events.
 
 -K::
 --all-kernel::
@@ -60,12 +77,12 @@ OPTIONS
 --all-user::
Configure all used events to run in user space.
 
---ldload::
-   Specify desired latency for loads event.
+-v::
+--verbose::
+   Be more verbose (show counter open errors, etc)
 
--p::
---phys-data::
-   Record/Report sample physical addresses
+--ldlat ::
+   Specify desired latency for loads event.
 
 In addition, for report all perf report options are valid, and for record
 all perf record options.

[PATCH 4/4] tty: n_gsm: Fix the test for if DLCI0 is open

[Dan Carpenter]

Logically, if gsm->dlci[0] is NULL then it's not open.  Also if it's
NULL then we would Oops when we do dlci_get(gsm->dlci[0]); at the end
of the function.

Reported-by: Sun Peng 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 44e9c5e3dbc1..660153538ca7 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2919,7 +2919,7 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
perspective as we don't have to worry about this
if DLCI0 is lost */
mutex_lock(>mutex);
-   if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN) {
+   if (!gsm->dlci[0] || gsm->dlci[0]->state != DLCI_OPEN) {
mutex_unlock(>mutex);
return -EL2NSYNC;
}

[tip:perf/urgent] perf pmu: Fix pmu events parsing rule

[tip-bot for Jiri Olsa]

Commit-ID:  9a4a931ce847f4aaa12edf11b2e050e18bf45910
Gitweb: https://git.kernel.org/tip/9a4a931ce847f4aaa12edf11b2e050e18bf45910
Author: Jiri Olsa 
AuthorDate: Mon, 23 Apr 2018 11:08:18 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:17:27 -0300

perf pmu: Fix pmu events parsing rule

Currently all the event parsing fails end up in the event_pmu rule, and
display misleading help like:

  $ perf stat -e inst kill
  event syntax error: 'inst'
   \___ Cannot find PMU `inst'. Missing kernel support?
  ...

The reason is that the event_pmu is too strong and match also single
string. Changing it to force the '/' separators to be part of the rule,
and getting the proper error now:

  $ perf stat -e inst kill
  event syntax error: 'inst'
   \___ parser error
  Run 'perf list' for a list of valid events
  ...

Signed-off-by: Jiri Olsa 
Reported-by: Ingo Molnar 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180423090823.32309-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/parse-events.y | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 7afeb80cc39e..d14464c42714 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -224,15 +224,15 @@ event_def: event_pmu |
   event_bpf_file
 
 event_pmu:
-PE_NAME opt_event_config
+PE_NAME '/' event_config '/'
 {
struct list_head *list, *orig_terms, *terms;
 
-   if (parse_events_copy_term_list($2, _terms))
+   if (parse_events_copy_term_list($3, _terms))
YYABORT;
 
ALLOC_LIST(list);
-   if (parse_events_add_pmu(_parse_state, list, $1, $2, false)) {
+   if (parse_events_add_pmu(_parse_state, list, $1, $3, false)) {
struct perf_pmu *pmu = NULL;
int ok = 0;
char *pattern;
@@ -262,7 +262,7 @@ PE_NAME opt_event_config
if (!ok)
YYABORT;
}
-   parse_events_terms__delete($2);
+   parse_events_terms__delete($3);
parse_events_terms__delete(orig_terms);
$$ = list;
 }

[PATCH 4/4] tty: n_gsm: Fix the test for if DLCI0 is open

[Dan Carpenter]

Logically, if gsm->dlci[0] is NULL then it's not open.  Also if it's
NULL then we would Oops when we do dlci_get(gsm->dlci[0]); at the end
of the function.

Reported-by: Sun Peng 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 44e9c5e3dbc1..660153538ca7 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2919,7 +2919,7 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
perspective as we don't have to worry about this
if DLCI0 is lost */
mutex_lock(>mutex);
-   if (gsm->dlci[0] && gsm->dlci[0]->state != DLCI_OPEN) {
+   if (!gsm->dlci[0] || gsm->dlci[0]->state != DLCI_OPEN) {
mutex_unlock(>mutex);
return -EL2NSYNC;
}

[tip:perf/urgent] perf pmu: Fix pmu events parsing rule

[tip-bot for Jiri Olsa]

Commit-ID:  9a4a931ce847f4aaa12edf11b2e050e18bf45910
Gitweb: https://git.kernel.org/tip/9a4a931ce847f4aaa12edf11b2e050e18bf45910
Author: Jiri Olsa 
AuthorDate: Mon, 23 Apr 2018 11:08:18 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:17:27 -0300

perf pmu: Fix pmu events parsing rule

Currently all the event parsing fails end up in the event_pmu rule, and
display misleading help like:

  $ perf stat -e inst kill
  event syntax error: 'inst'
   \___ Cannot find PMU `inst'. Missing kernel support?
  ...

The reason is that the event_pmu is too strong and match also single
string. Changing it to force the '/' separators to be part of the rule,
and getting the proper error now:

  $ perf stat -e inst kill
  event syntax error: 'inst'
   \___ parser error
  Run 'perf list' for a list of valid events
  ...

Signed-off-by: Jiri Olsa 
Reported-by: Ingo Molnar 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180423090823.32309-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/parse-events.y | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 7afeb80cc39e..d14464c42714 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -224,15 +224,15 @@ event_def: event_pmu |
   event_bpf_file
 
 event_pmu:
-PE_NAME opt_event_config
+PE_NAME '/' event_config '/'
 {
struct list_head *list, *orig_terms, *terms;
 
-   if (parse_events_copy_term_list($2, _terms))
+   if (parse_events_copy_term_list($3, _terms))
YYABORT;
 
ALLOC_LIST(list);
-   if (parse_events_add_pmu(_parse_state, list, $1, $2, false)) {
+   if (parse_events_add_pmu(_parse_state, list, $1, $3, false)) {
struct perf_pmu *pmu = NULL;
int ok = 0;
char *pattern;
@@ -262,7 +262,7 @@ PE_NAME opt_event_config
if (!ok)
YYABORT;
}
-   parse_events_terms__delete($2);
+   parse_events_terms__delete($3);
parse_events_terms__delete(orig_terms);
$$ = list;
 }

[tip:perf/urgent] perf stat: Keep the / modifier separator in fallback

[tip-bot for Jiri Olsa]

Commit-ID:  129193bb0c43d42f1c397c175346e3e0dba5a578
Gitweb: https://git.kernel.org/tip/129193bb0c43d42f1c397c175346e3e0dba5a578
Author: Jiri Olsa 
AuthorDate: Mon, 23 Apr 2018 11:08:17 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:14:10 -0300

perf stat: Keep the / modifier separator in fallback

The 'perf stat' fallback for EACCES error sets the exclude_kernel
perf_event_attr and tries perf_event_open() again with it. In addition,
it also changes the name of the event to reflect that change by adding
the 'u' modifier.

But it does not take into account the '/' separator, so the event name
can end up mangled, like: (note the '/:' characters)

  $ perf stat -e cpu/cpu-cycles/ kill
  ...
 386,832  cpu/cpu-cycles/:u

Adding the code to check on the '/' separator and set the following
correct event name:

  $ perf stat -e cpu/cpu-cycles/ kill
  ...
 388,548  cpu/cpu-cycles/u

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180423090823.32309-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 3e87486c28fe..7eb1e9850abf 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2754,8 +2754,14 @@ bool perf_evsel__fallback(struct perf_evsel *evsel, int 
err,
   (paranoid = perf_event_paranoid()) > 1) {
const char *name = perf_evsel__name(evsel);
char *new_name;
+   const char *sep = ":";
 
-   if (asprintf(_name, "%s%su", name, strchr(name, ':') ? "" : 
":") < 0)
+   /* Is there already the separator in the name. */
+   if (strchr(name, '/') ||
+   strchr(name, ':'))
+   sep = "";
+
+   if (asprintf(_name, "%s%su", name, sep) < 0)
return false;
 
if (evsel->name)

[PATCH 3/4] tty: n_gsm: Remove an unused lock

[Dan Carpenter]

We don't use this spin_lock so we can remove the dead code.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 1f2fd9e76fe0..44e9c5e3dbc1 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -177,7 +177,6 @@ struct gsm_control {
 
 struct gsm_mux {
struct tty_struct *tty; /* The tty our ldisc is bound to */
-   spinlock_t lock;
struct mutex mutex;
unsigned int num;
struct kref ref;
@@ -2188,7 +2187,6 @@ static struct gsm_mux *gsm_alloc_mux(void)
kfree(gsm);
return NULL;
}
-   spin_lock_init(>lock);
mutex_init(>mutex);
kref_init(>ref);
INIT_LIST_HEAD(>tx_list);

[tip:perf/urgent] perf stat: Keep the / modifier separator in fallback

[tip-bot for Jiri Olsa]

Commit-ID:  129193bb0c43d42f1c397c175346e3e0dba5a578
Gitweb: https://git.kernel.org/tip/129193bb0c43d42f1c397c175346e3e0dba5a578
Author: Jiri Olsa 
AuthorDate: Mon, 23 Apr 2018 11:08:17 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:14:10 -0300

perf stat: Keep the / modifier separator in fallback

The 'perf stat' fallback for EACCES error sets the exclude_kernel
perf_event_attr and tries perf_event_open() again with it. In addition,
it also changes the name of the event to reflect that change by adding
the 'u' modifier.

But it does not take into account the '/' separator, so the event name
can end up mangled, like: (note the '/:' characters)

  $ perf stat -e cpu/cpu-cycles/ kill
  ...
 386,832  cpu/cpu-cycles/:u

Adding the code to check on the '/' separator and set the following
correct event name:

  $ perf stat -e cpu/cpu-cycles/ kill
  ...
 388,548  cpu/cpu-cycles/u

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180423090823.32309-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 3e87486c28fe..7eb1e9850abf 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2754,8 +2754,14 @@ bool perf_evsel__fallback(struct perf_evsel *evsel, int 
err,
   (paranoid = perf_event_paranoid()) > 1) {
const char *name = perf_evsel__name(evsel);
char *new_name;
+   const char *sep = ":";
 
-   if (asprintf(_name, "%s%su", name, strchr(name, ':') ? "" : 
":") < 0)
+   /* Is there already the separator in the name. */
+   if (strchr(name, '/') ||
+   strchr(name, ':'))
+   sep = "";
+
+   if (asprintf(_name, "%s%su", name, sep) < 0)
return false;
 
if (evsel->name)

[PATCH 3/4] tty: n_gsm: Remove an unused lock

[Dan Carpenter]

We don't use this spin_lock so we can remove the dead code.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 1f2fd9e76fe0..44e9c5e3dbc1 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -177,7 +177,6 @@ struct gsm_control {
 
 struct gsm_mux {
struct tty_struct *tty; /* The tty our ldisc is bound to */
-   spinlock_t lock;
struct mutex mutex;
unsigned int num;
struct kref ref;
@@ -2188,7 +2187,6 @@ static struct gsm_mux *gsm_alloc_mux(void)
kfree(gsm);
return NULL;
}
-   spin_lock_init(>lock);
mutex_init(>mutex);
kref_init(>ref);
INIT_LIST_HEAD(>tx_list);

[PATCH 2/4] tty: n_gsm: Prevent a potential use after free

[Dan Carpenter]

We're freeing the gsm->dlci[] array elements but leaving the freed
pointers hanging around.

My concern here is if we use the ioctl to change the config, it triggers
a restart in gsmld_config().  In that case, we would only reset the
first ->dlci[0] element and not the others so it does look to me like a
possible use after free.

Reported-by: Sun Peng 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index cc7f68814200..1f2fd9e76fe0 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2075,9 +2075,11 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm)
 
/* Free up any link layer users */
mutex_lock(>mutex);
-   for (i = 0; i < NUM_DLCI; i++)
+   for (i = 0; i < NUM_DLCI; i++) {
if (gsm->dlci[i])
gsm_dlci_release(gsm->dlci[i]);
+   gsm->dlci[i] = NULL;
+   }
mutex_unlock(>mutex);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, >tx_list, list)

[PATCH 2/4] tty: n_gsm: Prevent a potential use after free

[Dan Carpenter]

We're freeing the gsm->dlci[] array elements but leaving the freed
pointers hanging around.

My concern here is if we use the ioctl to change the config, it triggers
a restart in gsmld_config().  In that case, we would only reset the
first ->dlci[0] element and not the others so it does look to me like a
possible use after free.

Reported-by: Sun Peng 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index cc7f68814200..1f2fd9e76fe0 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2075,9 +2075,11 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm)
 
/* Free up any link layer users */
mutex_lock(>mutex);
-   for (i = 0; i < NUM_DLCI; i++)
+   for (i = 0; i < NUM_DLCI; i++) {
if (gsm->dlci[i])
gsm_dlci_release(gsm->dlci[i]);
+   gsm->dlci[i] = NULL;
+   }
mutex_unlock(>mutex);
/* Now wipe the queues */
list_for_each_entry_safe(txq, ntxq, >tx_list, list)

[PATCH 1/4] tty: n_gsm: add some locking around gsm_mux[]

[Dan Carpenter]

We should take "gsm_mux_lock" when we access gsm_mux[].

Reported-by: Sun Peng 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 3b3e1f6632d7..cc7f68814200 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2898,18 +2898,22 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
bool alloc = false;
int ret;
 
-   line = line & 0x3F;
 
if (mux >= MAX_MUX)
return -ENXIO;
-   /* FIXME: we need to lock gsm_mux for lifetimes of ttys eventually */
-   if (gsm_mux[mux] == NULL)
-   return -EUNATCH;
+
+   line = line & 0x3F;
if (line == 0 || line > 61) /* 62/63 reserved */
return -ECHRNG;
+
+   spin_lock(_mux_lock);
gsm = gsm_mux[mux];
+   spin_unlock(_mux_lock);
+   if (!gsm)
+   return -EUNATCH;
if (gsm->dead)
return -EL2HLT;
+
/* If DLCI 0 is not yet fully open return an error.
This is ok from a locking
perspective as we don't have to worry about this

Re: [PATCH 8/9] mtd: nand: qcom: helper function for raw read

[Abhishek Sahu]

On 2018-04-25 18:29, Miquel Raynal wrote:

Hi Abhishek,

On Wed, 25 Apr 2018 12:02:29 +0530, Abhishek Sahu
 wrote:


On 2018-04-23 12:28, Miquel Raynal wrote:
> Hi Abhishek,
> > On Mon, 23 Apr 2018 11:58:42 +0530, Abhishek Sahu
>  wrote:
> >> On 2018-04-22 21:49, Miquel Raynal wrote:
>> > Hi Abhishek,
>> > > On Thu, 12 Apr 2018 12:36:42 +0530, Abhishek Sahu
>> >  wrote:
>> > >> On 2018-04-10 15:14, Miquel Raynal wrote:
>> >> > Hi Abhishek,
>> >> > > On Wed,  4 Apr 2018 18:12:24 +0530, Abhishek Sahu
>> >> >  wrote:
>> >> > >> This patch does minor code reorganization for raw reads.
>> >> >> Currently the raw read is required for complete page but for
>> >> >> subsequent patches related with erased codeword bit flips
>> >> >> detection, only few CW should be read. So, this patch adds
>> >> >> helper function and introduces the read CW bitmask which
>> >> >> specifies which CW reads are required in complete page.
>> >> > > I am not sure this is the right approach for subpage reads. If the
>> >> > controller supports it, you should just enable it in chip->options.
>> >> >
>> >>   Thanks Miquel.
>> >> >>   It is internal to this file only. This patch makes one static helper
>> >>   function which provides the support to read subpages.
>> > > Drivers should expose raw helpers, why keeping this helper static then?
>> > >> >> >> >> Signed-off-by: Abhishek Sahu 
>> >> >> ---
>> >> >>  drivers/mtd/nand/qcom_nandc.c | 186 >> 
+-
>> >> >>  1 file changed, 110 insertions(+), 76 deletions(-)
>> >> >> >> diff --git a/drivers/mtd/nand/qcom_nandc.c >> 
b/drivers/mtd/nand/qcom_nandc.c
>> >> >> index 40c790e..f5d1fa4 100644
>> >> >> --- a/drivers/mtd/nand/qcom_nandc.c
>> >> >> +++ b/drivers/mtd/nand/qcom_nandc.c
>> >> >> @@ -1590,6 +1590,114 @@ static int check_flash_errors(struct >> 
qcom_nand_host *host, int cw_cnt)
>> >> >>  }
>> >> >> >>  /*
>> >> >> + * Helper to perform the page raw read operation. The read_cw_mask >> 
will be
>> >> >> + * used to specify the codewords for which the data should be read. 
>> The
>> >> >> + * single page contains multiple CW. Sometime, only few CW data is >> 
required
>> >> >> + * in complete page. Also, start address will be determined with
>> >> >> + * this CW mask to skip unnecessary data copy from NAND flash device. 
>> Then,
>> >> >> + * actual data copy from NAND controller to data buffer will be done 
>> only
>> >> >> + * for the CWs which have the mask set.
>> >> >> + */
>> >> >> +static int
>> >> >> +nandc_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
>> >> >> +u8 *data_buf, u8 *oob_buf,
>> >> >> +int page, unsigned long read_cw_mask)
>> >> >> +{

  

>> >> >> -free_descs(nandc);
>> >> >> -
>> >> >> -if (!ret)
>> >> >> -ret = check_flash_errors(host, ecc->steps);
>> >> >> -
>> >> >> -return 0;
>> >> >> +return nandc_read_page_raw(mtd, chip, buf, chip->oob_poi, page,
>> >> >> +   BIT(chip->ecc.steps) - 1);
>> >> > > I don't understand this. chip->ecc.steps is constant, right? So you
>> >> > always ask for the same subpage?
>> >> >>   We need to do raw read for subpages in which we got uncorrectable
>> >>   error in next patch for erased page bitflip detection. This patch >> 
does
>> >>   reorganization of raw read and moves common code in helper function
>> >>   nandc_read_page_raw.
>> >> >>   For nomral raw read, all the subpages will be read so
>> >>   BIT(chip->ecc.steps) - 1 is used for qcom_nandc_read_page_raw.
>> >> >>   While for erased page raw read, only those sub pages will be
>> >>   read for which the controller gives the uncorrectable error.
>> > > Still not okay: the driver should expose a way to do raw reads no
>> > matter the length and the start and you should use that in a generic
>> > way.
>> >
>>   Thanks Miquel.
>>   I will explore regarding that.
>>   Looks like, we can some helper like read_subpage.
> > Of course, when you implement raw accessors you can have static helpers
> to clarify the code.
>
  Hi Miquel,

  I checked regarding generic function.

  Normally the other NAND controller stores the data in main area
  and ecc bytes in oob area. So if page size is 2048+64 then 2048
  data bytes will go in main area followed by ECC bytes

  Main |OOB
  
  D1 D2...D2048|E1..E64

  The QCOM nand contoller follows different layout in which this
  2048+64 is internally divided in 528 bytes codeword so it will
  come to 4 codewords. Each codeword contains 516 bytes followed
  by ECC parity bytes. Also in at 0x1f0 offset in each CW, the bad


 Sorry Miquel.
 Its 0x1d0 instead of 0x1f0.


  block marker is stored. so each CW contains badblock marker also.
  The avilable OOB bytes are 16 which is also protected by ECC.

  516 * 4 = 2048 

[PATCH 1/4] tty: n_gsm: add some locking around gsm_mux[]

[Dan Carpenter]

We should take "gsm_mux_lock" when we access gsm_mux[].

Reported-by: Sun Peng 
Signed-off-by: Dan Carpenter 

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 3b3e1f6632d7..cc7f68814200 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2898,18 +2898,22 @@ static int gsmtty_install(struct tty_driver *driver, 
struct tty_struct *tty)
bool alloc = false;
int ret;
 
-   line = line & 0x3F;
 
if (mux >= MAX_MUX)
return -ENXIO;
-   /* FIXME: we need to lock gsm_mux for lifetimes of ttys eventually */
-   if (gsm_mux[mux] == NULL)
-   return -EUNATCH;
+
+   line = line & 0x3F;
if (line == 0 || line > 61) /* 62/63 reserved */
return -ECHRNG;
+
+   spin_lock(_mux_lock);
gsm = gsm_mux[mux];
+   spin_unlock(_mux_lock);
+   if (!gsm)
+   return -EUNATCH;
if (gsm->dead)
return -EL2HLT;
+
/* If DLCI 0 is not yet fully open return an error.
This is ok from a locking
perspective as we don't have to worry about this

Re: [PATCH 8/9] mtd: nand: qcom: helper function for raw read

[Abhishek Sahu]

On 2018-04-25 18:29, Miquel Raynal wrote:

Hi Abhishek,

On Wed, 25 Apr 2018 12:02:29 +0530, Abhishek Sahu
 wrote:


On 2018-04-23 12:28, Miquel Raynal wrote:
> Hi Abhishek,
> > On Mon, 23 Apr 2018 11:58:42 +0530, Abhishek Sahu
>  wrote:
> >> On 2018-04-22 21:49, Miquel Raynal wrote:
>> > Hi Abhishek,
>> > > On Thu, 12 Apr 2018 12:36:42 +0530, Abhishek Sahu
>> >  wrote:
>> > >> On 2018-04-10 15:14, Miquel Raynal wrote:
>> >> > Hi Abhishek,
>> >> > > On Wed,  4 Apr 2018 18:12:24 +0530, Abhishek Sahu
>> >> >  wrote:
>> >> > >> This patch does minor code reorganization for raw reads.
>> >> >> Currently the raw read is required for complete page but for
>> >> >> subsequent patches related with erased codeword bit flips
>> >> >> detection, only few CW should be read. So, this patch adds
>> >> >> helper function and introduces the read CW bitmask which
>> >> >> specifies which CW reads are required in complete page.
>> >> > > I am not sure this is the right approach for subpage reads. If the
>> >> > controller supports it, you should just enable it in chip->options.
>> >> >
>> >>   Thanks Miquel.
>> >> >>   It is internal to this file only. This patch makes one static helper
>> >>   function which provides the support to read subpages.
>> > > Drivers should expose raw helpers, why keeping this helper static then?
>> > >> >> >> >> Signed-off-by: Abhishek Sahu 
>> >> >> ---
>> >> >>  drivers/mtd/nand/qcom_nandc.c | 186 >> 
+-
>> >> >>  1 file changed, 110 insertions(+), 76 deletions(-)
>> >> >> >> diff --git a/drivers/mtd/nand/qcom_nandc.c >> 
b/drivers/mtd/nand/qcom_nandc.c
>> >> >> index 40c790e..f5d1fa4 100644
>> >> >> --- a/drivers/mtd/nand/qcom_nandc.c
>> >> >> +++ b/drivers/mtd/nand/qcom_nandc.c
>> >> >> @@ -1590,6 +1590,114 @@ static int check_flash_errors(struct >> 
qcom_nand_host *host, int cw_cnt)
>> >> >>  }
>> >> >> >>  /*
>> >> >> + * Helper to perform the page raw read operation. The read_cw_mask >> 
will be
>> >> >> + * used to specify the codewords for which the data should be read. 
>> The
>> >> >> + * single page contains multiple CW. Sometime, only few CW data is >> 
required
>> >> >> + * in complete page. Also, start address will be determined with
>> >> >> + * this CW mask to skip unnecessary data copy from NAND flash device. 
>> Then,
>> >> >> + * actual data copy from NAND controller to data buffer will be done 
>> only
>> >> >> + * for the CWs which have the mask set.
>> >> >> + */
>> >> >> +static int
>> >> >> +nandc_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
>> >> >> +u8 *data_buf, u8 *oob_buf,
>> >> >> +int page, unsigned long read_cw_mask)
>> >> >> +{

  

>> >> >> -free_descs(nandc);
>> >> >> -
>> >> >> -if (!ret)
>> >> >> -ret = check_flash_errors(host, ecc->steps);
>> >> >> -
>> >> >> -return 0;
>> >> >> +return nandc_read_page_raw(mtd, chip, buf, chip->oob_poi, page,
>> >> >> +   BIT(chip->ecc.steps) - 1);
>> >> > > I don't understand this. chip->ecc.steps is constant, right? So you
>> >> > always ask for the same subpage?
>> >> >>   We need to do raw read for subpages in which we got uncorrectable
>> >>   error in next patch for erased page bitflip detection. This patch >> 
does
>> >>   reorganization of raw read and moves common code in helper function
>> >>   nandc_read_page_raw.
>> >> >>   For nomral raw read, all the subpages will be read so
>> >>   BIT(chip->ecc.steps) - 1 is used for qcom_nandc_read_page_raw.
>> >> >>   While for erased page raw read, only those sub pages will be
>> >>   read for which the controller gives the uncorrectable error.
>> > > Still not okay: the driver should expose a way to do raw reads no
>> > matter the length and the start and you should use that in a generic
>> > way.
>> >
>>   Thanks Miquel.
>>   I will explore regarding that.
>>   Looks like, we can some helper like read_subpage.
> > Of course, when you implement raw accessors you can have static helpers
> to clarify the code.
>
  Hi Miquel,

  I checked regarding generic function.

  Normally the other NAND controller stores the data in main area
  and ecc bytes in oob area. So if page size is 2048+64 then 2048
  data bytes will go in main area followed by ECC bytes

  Main |OOB
  
  D1 D2...D2048|E1..E64

  The QCOM nand contoller follows different layout in which this
  2048+64 is internally divided in 528 bytes codeword so it will
  come to 4 codewords. Each codeword contains 516 bytes followed
  by ECC parity bytes. Also in at 0x1f0 offset in each CW, the bad


 Sorry Miquel.
 Its 0x1d0 instead of 0x1f0.


  block marker is stored. so each CW contains badblock marker also.
  The avilable OOB bytes are 16 which is also protected by ECC.

  516 * 4 = 2048 data bytes + 16 available oob bytes.

  So for QCOM layout, it will be something lile


  0   D1.D495 

[tip:perf/urgent] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

[tip-bot for Thomas Richter]

Commit-ID:  b31a8cc1a53dda3a33b6c9c62779869d4d5fc142
Gitweb: https://git.kernel.org/tip/b31a8cc1a53dda3a33b6c9c62779869d4d5fc142
Author: Thomas Richter 
AuthorDate: Mon, 23 Apr 2018 10:24:28 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:04:37 -0300

perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

perf test case 58 (record+probe_libc_inet_pton.sh) executed on s390x
using kernel 4.16.0rc3 displays this result:

 # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 
-c 1 ::1
 probe_libc:inet_pton: (3ffa0240448)
  __GI___inet_pton (/usr/lib64/libc-2.26.so)
  gaih_inet (inlined)
  __GI_getaddrinfo (inlined)
  main (/usr/bin/ping)
  __libc_start_main (/usr/lib64/libc-2.26.so)
 _start (/usr/bin/ping)

After I installed kernel 4.16.0 the same tests uses commands:

 # perf record -e probe_libc:inet_pton/call-graph=dwarf/
  -o /tmp/perf.data.abc ping -6 -c 1 ::1
 # perf script -i /tmp/perf.data.abc

and displays:

 ping 39048 [006] 84230.381198: probe_libc:inet_pton: (3ffa0240448)
   140448 __GI___inet_pton (/usr/lib64/libc-2.26.so)
   fbde1 gaih_inet (inlined)
   fe2b9 __GI_getaddrinfo (inlined)
398d main (/usr/bin/ping)

Nothing else changed including glibc elfutils and other libraries picked
up by the build.

The entries for __libc_start_main and _start are missing.

I bisected missing __libc_start_main and _start to commit

Fixes: 3d20c6246690 ("perf unwind: Unwind with libdw doesn't take symfs into 
account")

When I undo this commit I get this call stack on s390:
 [root@s35lp76 perf]# ./perf script  -i /tmp/perf.data.abc
 ping 39048 [006] 84230.381198: probe_libc:inet_pton: (3ffa0240448)
140448 __GI___inet_pton (/usr/lib64/libc-2.26.so)
 fbde1 gaih_inet (inlined)
 fe2b9 __GI_getaddrinfo (inlined)
  398d main (/usr/bin/ping)
 22fbd __libc_start_main (/usr/lib64/libc-2.26.so)
  457b _start (/usr/bin/ping)

Looks like dwarf functions dwfl_xxx create different call back stack
trace when using file /usr/lib/debug/usr/bin/ping-20161105-7.fc27.s390x.debug
instead of file /usr/bin/ping.

Fix this test case on s390 and do not expect any call back stack entry
after the main() function. Also be more robust and accept a leading
__GI_ prefix in front of getaddrinfo.

On x86 this test case shows the same call stack using both kernel
versions 4.16.0rc3 and 4.16.0 and also stops at main:

  [root@f27 perf]# ./perf script -i /tmp/perf.data.tmr
  ping  4446 [000]   172.027088: probe_libc:inet_pton: (7fdfa08c93c0)
 1393c0 __GI___inet_pton (/usr/lib64/libc-2.26.so)
  fe60d getaddrinfo (/usr/lib64/libc-2.26.so)
   2f40 main (/usr/bin/ping)
  [root@f27 perf]#

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Cc: Martin Vuille 
Link: http://lkml.kernel.org/r/20180423082428.7930-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/shell/record+probe_libc_inet_pton.sh | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
index 1ecc1f0ff84a..016882dbbc16 100755
--- a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
@@ -19,12 +19,10 @@ trace_libc_inet_pton_backtrace() {
expected[1]=".*inet_pton[[:space:]]\($libc\)$"
case "$(uname -m)" in
s390x)
-   eventattr='call-graph=dwarf'
+   eventattr='call-graph=dwarf,max-stack=4'
expected[2]="gaih_inet.*[[:space:]]\($libc|inlined\)$"
-   expected[3]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$"
+   expected[3]="(__GI_)?getaddrinfo[[:space:]]\($libc|inlined\)$"
expected[4]="main[[:space:]]\(.*/bin/ping.*\)$"
-   expected[5]="__libc_start_main[[:space:]]\($libc\)$"
-   expected[6]="_start[[:space:]]\(.*/bin/ping.*\)$"
;;
*)
eventattr='max-stack=3'

[tip:perf/urgent] perf list: Remove s390 specific strcmp_cpuid_cmp function

[tip-bot for Thomas Richter]

Commit-ID:  ce04abfbd3ea545a8eb38a8b6a48fb6e7d139dcb
Gitweb: https://git.kernel.org/tip/ce04abfbd3ea545a8eb38a8b6a48fb6e7d139dcb
Author: Thomas Richter 
AuthorDate: Mon, 23 Apr 2018 10:17:45 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:03:13 -0300

perf list: Remove s390 specific strcmp_cpuid_cmp function

Make the type field in pmu-events/arch/s390/mapfile.cvs more generic to
match the created cpuid string for s390.

The pattern also checks for the counter first version number and counter
second version number ([13]\.[1-5]) and the authorization field which
follows.

These numbers do not exist in the cpuid identification string when perf
commands are executed on a z/VM environment (which does not support CPU
counter measurement facility).

CPUID string for LPAR:
   cpuid : IBM,3906,704,M03,3.5,002f
CPUID string for z/VM:
   cpuid : IBM,2964,702,N96

This allows the removal of s390 specific cpuid compare code and uses the
common compare function with its regular expression matching algorithm.

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180423081745.3672-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/header.c  | 18 --
 tools/perf/pmu-events/arch/s390/mapfile.csv | 10 +-
 tools/perf/util/pmu.c   |  2 +-
 3 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/tools/perf/arch/s390/util/header.c 
b/tools/perf/arch/s390/util/header.c
index a4c30f1c70be..163b92f33998 100644
--- a/tools/perf/arch/s390/util/header.c
+++ b/tools/perf/arch/s390/util/header.c
@@ -146,21 +146,3 @@ char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
zfree();
return buf;
 }
-
-/*
- * Compare the cpuid string returned by get_cpuid() function
- * with the name generated by the jevents file read from
- * pmu-events/arch/s390/mapfile.csv.
- *
- * Parameter mapcpuid is the cpuid as stored in the
- * pmu-events/arch/s390/mapfile.csv. This is just the type number.
- * Parameter cpuid is the cpuid returned by function get_cpuid().
- */
-int strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
-{
-   char *cp = strchr(cpuid, ',');
-
-   if (cp == NULL)
-   return -1;
-   return strncmp(cp + 1, mapcpuid, strlen(mapcpuid));
-}
diff --git a/tools/perf/pmu-events/arch/s390/mapfile.csv 
b/tools/perf/pmu-events/arch/s390/mapfile.csv
index ca7682748a4b..78bcf7f8e206 100644
--- a/tools/perf/pmu-events/arch/s390/mapfile.csv
+++ b/tools/perf/pmu-events/arch/s390/mapfile.csv
@@ -1,6 +1,6 @@
 Family-model,Version,Filename,EventType
-209[78],1,cf_z10,core
-281[78],1,cf_z196,core
-282[78],1,cf_zec12,core
-296[45],1,cf_z13,core
-3906,3,cf_z14,core
+^IBM.209[78].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_z10,core
+^IBM.281[78].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_z196,core
+^IBM.282[78].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_zec12,core
+^IBM.296[45].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_z13,core
+^IBM.390[67].*[13]\.[1-5].[[:xdigit:]]+$,3,cf_z14,core
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 61a5e5027338..af4bedf4cf98 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -586,7 +586,7 @@ char * __weak get_cpuid_str(struct perf_pmu *pmu 
__maybe_unused)
  * cpuid string generated on this platform.
  * Otherwise return non-zero.
  */
-int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
+int strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
 {
regex_t re;
regmatch_t pmatch[1];

[tip:perf/urgent] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

[tip-bot for Thomas Richter]

Commit-ID:  b31a8cc1a53dda3a33b6c9c62779869d4d5fc142
Gitweb: https://git.kernel.org/tip/b31a8cc1a53dda3a33b6c9c62779869d4d5fc142
Author: Thomas Richter 
AuthorDate: Mon, 23 Apr 2018 10:24:28 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:04:37 -0300

perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

perf test case 58 (record+probe_libc_inet_pton.sh) executed on s390x
using kernel 4.16.0rc3 displays this result:

 # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 
-c 1 ::1
 probe_libc:inet_pton: (3ffa0240448)
  __GI___inet_pton (/usr/lib64/libc-2.26.so)
  gaih_inet (inlined)
  __GI_getaddrinfo (inlined)
  main (/usr/bin/ping)
  __libc_start_main (/usr/lib64/libc-2.26.so)
 _start (/usr/bin/ping)

After I installed kernel 4.16.0 the same tests uses commands:

 # perf record -e probe_libc:inet_pton/call-graph=dwarf/
  -o /tmp/perf.data.abc ping -6 -c 1 ::1
 # perf script -i /tmp/perf.data.abc

and displays:

 ping 39048 [006] 84230.381198: probe_libc:inet_pton: (3ffa0240448)
   140448 __GI___inet_pton (/usr/lib64/libc-2.26.so)
   fbde1 gaih_inet (inlined)
   fe2b9 __GI_getaddrinfo (inlined)
398d main (/usr/bin/ping)

Nothing else changed including glibc elfutils and other libraries picked
up by the build.

The entries for __libc_start_main and _start are missing.

I bisected missing __libc_start_main and _start to commit

Fixes: 3d20c6246690 ("perf unwind: Unwind with libdw doesn't take symfs into 
account")

When I undo this commit I get this call stack on s390:
 [root@s35lp76 perf]# ./perf script  -i /tmp/perf.data.abc
 ping 39048 [006] 84230.381198: probe_libc:inet_pton: (3ffa0240448)
140448 __GI___inet_pton (/usr/lib64/libc-2.26.so)
 fbde1 gaih_inet (inlined)
 fe2b9 __GI_getaddrinfo (inlined)
  398d main (/usr/bin/ping)
 22fbd __libc_start_main (/usr/lib64/libc-2.26.so)
  457b _start (/usr/bin/ping)

Looks like dwarf functions dwfl_xxx create different call back stack
trace when using file /usr/lib/debug/usr/bin/ping-20161105-7.fc27.s390x.debug
instead of file /usr/bin/ping.

Fix this test case on s390 and do not expect any call back stack entry
after the main() function. Also be more robust and accept a leading
__GI_ prefix in front of getaddrinfo.

On x86 this test case shows the same call stack using both kernel
versions 4.16.0rc3 and 4.16.0 and also stops at main:

  [root@f27 perf]# ./perf script -i /tmp/perf.data.tmr
  ping  4446 [000]   172.027088: probe_libc:inet_pton: (7fdfa08c93c0)
 1393c0 __GI___inet_pton (/usr/lib64/libc-2.26.so)
  fe60d getaddrinfo (/usr/lib64/libc-2.26.so)
   2f40 main (/usr/bin/ping)
  [root@f27 perf]#

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Cc: Martin Vuille 
Link: http://lkml.kernel.org/r/20180423082428.7930-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/shell/record+probe_libc_inet_pton.sh | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
index 1ecc1f0ff84a..016882dbbc16 100755
--- a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
@@ -19,12 +19,10 @@ trace_libc_inet_pton_backtrace() {
expected[1]=".*inet_pton[[:space:]]\($libc\)$"
case "$(uname -m)" in
s390x)
-   eventattr='call-graph=dwarf'
+   eventattr='call-graph=dwarf,max-stack=4'
expected[2]="gaih_inet.*[[:space:]]\($libc|inlined\)$"
-   expected[3]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$"
+   expected[3]="(__GI_)?getaddrinfo[[:space:]]\($libc|inlined\)$"
expected[4]="main[[:space:]]\(.*/bin/ping.*\)$"
-   expected[5]="__libc_start_main[[:space:]]\($libc\)$"
-   expected[6]="_start[[:space:]]\(.*/bin/ping.*\)$"
;;
*)
eventattr='max-stack=3'

[tip:perf/urgent] perf list: Remove s390 specific strcmp_cpuid_cmp function

[tip-bot for Thomas Richter]

Commit-ID:  ce04abfbd3ea545a8eb38a8b6a48fb6e7d139dcb
Gitweb: https://git.kernel.org/tip/ce04abfbd3ea545a8eb38a8b6a48fb6e7d139dcb
Author: Thomas Richter 
AuthorDate: Mon, 23 Apr 2018 10:17:45 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 11:03:13 -0300

perf list: Remove s390 specific strcmp_cpuid_cmp function

Make the type field in pmu-events/arch/s390/mapfile.cvs more generic to
match the created cpuid string for s390.

The pattern also checks for the counter first version number and counter
second version number ([13]\.[1-5]) and the authorization field which
follows.

These numbers do not exist in the cpuid identification string when perf
commands are executed on a z/VM environment (which does not support CPU
counter measurement facility).

CPUID string for LPAR:
   cpuid : IBM,3906,704,M03,3.5,002f
CPUID string for z/VM:
   cpuid : IBM,2964,702,N96

This allows the removal of s390 specific cpuid compare code and uses the
common compare function with its regular expression matching algorithm.

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20180423081745.3672-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/s390/util/header.c  | 18 --
 tools/perf/pmu-events/arch/s390/mapfile.csv | 10 +-
 tools/perf/util/pmu.c   |  2 +-
 3 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/tools/perf/arch/s390/util/header.c 
b/tools/perf/arch/s390/util/header.c
index a4c30f1c70be..163b92f33998 100644
--- a/tools/perf/arch/s390/util/header.c
+++ b/tools/perf/arch/s390/util/header.c
@@ -146,21 +146,3 @@ char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
zfree();
return buf;
 }
-
-/*
- * Compare the cpuid string returned by get_cpuid() function
- * with the name generated by the jevents file read from
- * pmu-events/arch/s390/mapfile.csv.
- *
- * Parameter mapcpuid is the cpuid as stored in the
- * pmu-events/arch/s390/mapfile.csv. This is just the type number.
- * Parameter cpuid is the cpuid returned by function get_cpuid().
- */
-int strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
-{
-   char *cp = strchr(cpuid, ',');
-
-   if (cp == NULL)
-   return -1;
-   return strncmp(cp + 1, mapcpuid, strlen(mapcpuid));
-}
diff --git a/tools/perf/pmu-events/arch/s390/mapfile.csv 
b/tools/perf/pmu-events/arch/s390/mapfile.csv
index ca7682748a4b..78bcf7f8e206 100644
--- a/tools/perf/pmu-events/arch/s390/mapfile.csv
+++ b/tools/perf/pmu-events/arch/s390/mapfile.csv
@@ -1,6 +1,6 @@
 Family-model,Version,Filename,EventType
-209[78],1,cf_z10,core
-281[78],1,cf_z196,core
-282[78],1,cf_zec12,core
-296[45],1,cf_z13,core
-3906,3,cf_z14,core
+^IBM.209[78].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_z10,core
+^IBM.281[78].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_z196,core
+^IBM.282[78].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_zec12,core
+^IBM.296[45].*[13]\.[1-5].[[:xdigit:]]+$,1,cf_z13,core
+^IBM.390[67].*[13]\.[1-5].[[:xdigit:]]+$,3,cf_z14,core
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 61a5e5027338..af4bedf4cf98 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -586,7 +586,7 @@ char * __weak get_cpuid_str(struct perf_pmu *pmu 
__maybe_unused)
  * cpuid string generated on this platform.
  * Otherwise return non-zero.
  */
-int __weak strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
+int strcmp_cpuid_str(const char *mapcpuid, const char *cpuid)
 {
regex_t re;
regmatch_t pmatch[1];

[tip:perf/urgent] perf machine: Set main kernel end address properly

[tip-bot for Namhyung Kim]

Commit-ID:  ee05d21791db6db954bbb7b79bb18d88b5f6b7ff
Gitweb: https://git.kernel.org/tip/ee05d21791db6db954bbb7b79bb18d88b5f6b7ff
Author: Namhyung Kim 
AuthorDate: Mon, 19 Feb 2018 19:05:45 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 10:52:55 -0300

perf machine: Set main kernel end address properly

map_groups__fixup_end() was called to set the end addresses of kernel
and module maps.  But now since machine__create_modules() sets the end
address of modules properly, the only remaining piece is the kernel map.

We can set it with adjacent module's address directly instead of calling
map_groups__fixup_end().  If there's no module after the kernel map, the
end address will be ~0ULL.

Since it also changes the start address of the kernel map, it needs to
re-insert the map to the kmaps in order to keep a correct ordering.  Kim
reported that it caused problems on ARM64.

Reported-by: Kim Phillips 
Tested-by: Kim Phillips 
Signed-off-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: kernel-t...@lge.com
Link: http://lkml.kernel.org/r/20180419235915.GA19067@sejong
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 2eca8478e24f..32d50492505d 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1019,13 +1019,6 @@ int machine__load_vmlinux_path(struct machine *machine, 
enum map_type type)
return ret;
 }
 
-static void map_groups__fixup_end(struct map_groups *mg)
-{
-   int i;
-   for (i = 0; i < MAP__NR_TYPES; ++i)
-   __map_groups__fixup_end(mg, i);
-}
-
 static char *get_kernel_version(const char *root_dir)
 {
char version[PATH_MAX];
@@ -1233,6 +1226,7 @@ int machine__create_kernel_maps(struct machine *machine)
 {
struct dso *kernel = machine__get_kernel(machine);
const char *name = NULL;
+   struct map *map;
u64 addr = 0;
int ret;
 
@@ -1259,13 +1253,25 @@ int machine__create_kernel_maps(struct machine *machine)
machine__destroy_kernel_maps(machine);
return -1;
}
-   machine__set_kernel_mmap(machine, addr, 0);
+
+   /* we have a real start address now, so re-order the kmaps */
+   map = machine__kernel_map(machine);
+
+   map__get(map);
+   map_groups__remove(>kmaps, map);
+
+   /* assume it's the last in the kmaps */
+   machine__set_kernel_mmap(machine, addr, ~0ULL);
+
+   map_groups__insert(>kmaps, map);
+   map__put(map);
}
 
-   /*
-* Now that we have all the maps created, just set the ->end of them:
-*/
-   map_groups__fixup_end(>kmaps);
+   /* update end address of the kernel map using adjacent module address */
+   map = map__next(machine__kernel_map(machine));
+   if (map)
+   machine__set_kernel_mmap(machine, addr, map->start);
+
return 0;
 }
 

[tip:perf/urgent] perf machine: Set main kernel end address properly

[tip-bot for Namhyung Kim]

Commit-ID:  ee05d21791db6db954bbb7b79bb18d88b5f6b7ff
Gitweb: https://git.kernel.org/tip/ee05d21791db6db954bbb7b79bb18d88b5f6b7ff
Author: Namhyung Kim 
AuthorDate: Mon, 19 Feb 2018 19:05:45 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 Apr 2018 10:52:55 -0300

perf machine: Set main kernel end address properly

map_groups__fixup_end() was called to set the end addresses of kernel
and module maps.  But now since machine__create_modules() sets the end
address of modules properly, the only remaining piece is the kernel map.

We can set it with adjacent module's address directly instead of calling
map_groups__fixup_end().  If there's no module after the kernel map, the
end address will be ~0ULL.

Since it also changes the start address of the kernel map, it needs to
re-insert the map to the kmaps in order to keep a correct ordering.  Kim
reported that it caused problems on ARM64.

Reported-by: Kim Phillips 
Tested-by: Kim Phillips 
Signed-off-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: kernel-t...@lge.com
Link: http://lkml.kernel.org/r/20180419235915.GA19067@sejong
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/machine.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 2eca8478e24f..32d50492505d 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1019,13 +1019,6 @@ int machine__load_vmlinux_path(struct machine *machine, 
enum map_type type)
return ret;
 }
 
-static void map_groups__fixup_end(struct map_groups *mg)
-{
-   int i;
-   for (i = 0; i < MAP__NR_TYPES; ++i)
-   __map_groups__fixup_end(mg, i);
-}
-
 static char *get_kernel_version(const char *root_dir)
 {
char version[PATH_MAX];
@@ -1233,6 +1226,7 @@ int machine__create_kernel_maps(struct machine *machine)
 {
struct dso *kernel = machine__get_kernel(machine);
const char *name = NULL;
+   struct map *map;
u64 addr = 0;
int ret;
 
@@ -1259,13 +1253,25 @@ int machine__create_kernel_maps(struct machine *machine)
machine__destroy_kernel_maps(machine);
return -1;
}
-   machine__set_kernel_mmap(machine, addr, 0);
+
+   /* we have a real start address now, so re-order the kmaps */
+   map = machine__kernel_map(machine);
+
+   map__get(map);
+   map_groups__remove(>kmaps, map);
+
+   /* assume it's the last in the kmaps */
+   machine__set_kernel_mmap(machine, addr, ~0ULL);
+
+   map_groups__insert(>kmaps, map);
+   map__put(map);
}
 
-   /*
-* Now that we have all the maps created, just set the ->end of them:
-*/
-   map_groups__fixup_end(>kmaps);
+   /* update end address of the kernel map using adjacent module address */
+   map = map__next(machine__kernel_map(machine));
+   if (map)
+   machine__set_kernel_mmap(machine, addr, map->start);
+
return 0;
 }
 

Re: [PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

Hi Ludovic,

Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf 
---
  drivers/i2c/busses/i2c-at91.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);


You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?


I did a quick test by reading RXFL and it worked as well but I decided 
to use the more readable solution by polling RXRDY. Also I don't need to 
check if the FIFO has been enabled.


If you prefer using RXFL I can create a new patch.

Best regards
- David



Regards

Ludovic


+   }
  
  	/*

 * When a NACK condition is detected, the I2C controller sets the NACK,
--
2.14.1



--
Mit freundlichen Grüßen/Best regards,

David Engraf
Product Engineer

SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany

Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
E-mail: david.eng...@sysgo.com
_

Web: https://www.sysgo.com
Blog: https://www.sysgo.com/blog
Events: https://www.sysgo.com/events
Newsletter: https://www.sysgo.com/newsletter
_

Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066
Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny (COO)
Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon
USt-Id-Nr./VAT-Id-No.: DE 149062328

Re: [PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

Hi Ludovic,

Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf 
---
  drivers/i2c/busses/i2c-at91.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);


You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?


I did a quick test by reading RXFL and it worked as well but I decided 
to use the more readable solution by polling RXRDY. Also I don't need to 
check if the FIFO has been enabled.


If you prefer using RXFL I can create a new patch.

Best regards
- David



Regards

Ludovic


+   }
  
  	/*

 * When a NACK condition is detected, the I2C controller sets the NACK,
--
2.14.1



--
Mit freundlichen Grüßen/Best regards,

David Engraf
Product Engineer

SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany

Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
E-mail: david.eng...@sysgo.com
_

Web: https://www.sysgo.com
Blog: https://www.sysgo.com/blog
Events: https://www.sysgo.com/events
Newsletter: https://www.sysgo.com/newsletter
_

Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066
Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny (COO)
Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon
USt-Id-Nr./VAT-Id-No.: DE 149062328

Re: Linux messages full of `random: get_random_u32 called from`

[Pavel Machek]

Hi!

> Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
> from` messages. I believe, this setting should be reverted by default as
> otherwise a lot of other messages are not seen.
> 
> Please find my configuration attached.

Same here, thinkpad X60:

[3.163839] systemd[1]: Failed to insert module 'ipv6'
[3.181266] systemd[1]: Set hostname to .
[3.267243] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[3.669590] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[3.696242] random: systemd: uninitialized urandom read (16 bytes
read)
[3.700066] random: systemd: uninitialized urandom read (16 bytes
read)
[3.703716] random: systemd: uninitialized urandom read (16 bytes
read)
[3.756137] random: systemd: uninitialized urandom read (16 bytes
read)
[3.760460] random: systemd: uninitialized urandom read (16 bytes
read)
[3.764515] random: systemd: uninitialized urandom read (16 bytes
read)
[3.835312] random: systemd: uninitialized urandom read (16 bytes
read)
[4.173204] systemd[1]: Binding to IPv6 address not available since
kernel does not support IPv6.
[4.176977] systemd[1]: [/lib/systemd/system/gpsd.socket:6] Failed
to parse address value, ignoring: [::1]:2947
[4.186472] systemd[1]: Starting Forward Password Requests to Wall
Directory Watch.
[4.188845] systemd[1]: Started Forward Password Requests to Wall
Directory Watch.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux messages full of `random: get_random_u32 called from`

[Pavel Machek]

Hi!

> Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
> from` messages. I believe, this setting should be reverted by default as
> otherwise a lot of other messages are not seen.
> 
> Please find my configuration attached.

Same here, thinkpad X60:

[3.163839] systemd[1]: Failed to insert module 'ipv6'
[3.181266] systemd[1]: Set hostname to .
[3.267243] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[3.669590] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[3.696242] random: systemd: uninitialized urandom read (16 bytes
read)
[3.700066] random: systemd: uninitialized urandom read (16 bytes
read)
[3.703716] random: systemd: uninitialized urandom read (16 bytes
read)
[3.756137] random: systemd: uninitialized urandom read (16 bytes
read)
[3.760460] random: systemd: uninitialized urandom read (16 bytes
read)
[3.764515] random: systemd: uninitialized urandom read (16 bytes
read)
[3.835312] random: systemd: uninitialized urandom read (16 bytes
read)
[4.173204] systemd[1]: Binding to IPv6 address not available since
kernel does not support IPv6.
[4.176977] systemd[1]: [/lib/systemd/system/gpsd.socket:6] Failed
to parse address value, ignoring: [::1]:2947
[4.186472] systemd[1]: Starting Forward Password Requests to Wall
Directory Watch.
[4.188845] systemd[1]: Started Forward Password Requests to Wall
Directory Watch.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH v2] wlcore: sdio: allow pm to handle sdio power

[Eyal Reizer]

pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.

In case of resume pm_runtime_get sync returns a positive device's usage
count causing the driver to try an re-initialize an already initialized
device. This was causing sdio bus failure on resume.

Remove this manual power on/off sequence as it is in-fact not needed.

Signed-off-by: Eyal Reizer 
Acked-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/sdio.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 1f727ba..6dbe61d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -155,17 +155,11 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue 
*glue)
struct mmc_card *card = func->card;
 
ret = pm_runtime_get_sync(>dev);
-   if (ret) {
-   /*
-* Runtime PM might be temporarily disabled, or the device
-* might have a positive reference counter. Make sure it is
-* really powered on.
-*/
-   ret = mmc_power_restore_host(card->host);
-   if (ret < 0) {
-   pm_runtime_put_sync(>dev);
-   goto out;
-   }
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
+   __func__, ret);
+   goto out;
}
 
sdio_claim_host(func);
@@ -178,7 +172,6 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue 
*glue)
 
 static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
 {
-   int ret;
struct sdio_func *func = dev_to_sdio_func(glue->dev);
struct mmc_card *card = func->card;
 
@@ -186,16 +179,8 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue 
*glue)
sdio_disable_func(func);
sdio_release_host(func);
 
-   /* Power off the card manually in case it wasn't powered off above */
-   ret = mmc_power_save_host(card->host);
-   if (ret < 0)
-   goto out;
-
/* Let runtime PM know the card is powered off */
-   pm_runtime_put_sync(>dev);
-
-out:
-   return ret;
+   return pm_runtime_put_sync(>dev);
 }
 
 static int wl12xx_sdio_set_power(struct device *child, bool enable)
-- 
2.7.4

[PATCH v2] wlcore: sdio: allow pm to handle sdio power

[Eyal Reizer]

pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.

In case of resume pm_runtime_get sync returns a positive device's usage
count causing the driver to try an re-initialize an already initialized
device. This was causing sdio bus failure on resume.

Remove this manual power on/off sequence as it is in-fact not needed.

Signed-off-by: Eyal Reizer 
Acked-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/sdio.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 1f727ba..6dbe61d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -155,17 +155,11 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue 
*glue)
struct mmc_card *card = func->card;
 
ret = pm_runtime_get_sync(>dev);
-   if (ret) {
-   /*
-* Runtime PM might be temporarily disabled, or the device
-* might have a positive reference counter. Make sure it is
-* really powered on.
-*/
-   ret = mmc_power_restore_host(card->host);
-   if (ret < 0) {
-   pm_runtime_put_sync(>dev);
-   goto out;
-   }
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
+   __func__, ret);
+   goto out;
}
 
sdio_claim_host(func);
@@ -178,7 +172,6 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue 
*glue)
 
 static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
 {
-   int ret;
struct sdio_func *func = dev_to_sdio_func(glue->dev);
struct mmc_card *card = func->card;
 
@@ -186,16 +179,8 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue 
*glue)
sdio_disable_func(func);
sdio_release_host(func);
 
-   /* Power off the card manually in case it wasn't powered off above */
-   ret = mmc_power_save_host(card->host);
-   if (ret < 0)
-   goto out;
-
/* Let runtime PM know the card is powered off */
-   pm_runtime_put_sync(>dev);
-
-out:
-   return ret;
+   return pm_runtime_put_sync(>dev);
 }
 
 static int wl12xx_sdio_set_power(struct device *child, bool enable)
-- 
2.7.4

[PATCH] x86/idt: Simplify the idt_setup_apic_and_irq_gates()

[Dou Liyang]

The vectors between FIRST_SYSTEM_VECTOR and NR_VECTORS are special IRQ
vectors used by the SMP architecture. But, if X86_LOCAL_APIC=n, it will
not be used, and the FIRST_SYSTEM_VECTOR is equal to NR_VECTORS.

idt_setup_apic_and_irq_gates() didn't notice that, which make the code
a little complex.

Remove the code of the X86_LOCAL_APIC=n case to simplify it.

Signed-off-by: Dou Liyang 
---
 arch/x86/kernel/idt.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
index 2c3a1b4294eb..8b4174890706 100644
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -317,15 +317,16 @@ void __init idt_setup_apic_and_irq_gates(void)
set_intr_gate(i, entry);
}
 
-   for_each_clear_bit_from(i, system_vectors, NR_VECTORS) {
+   /*
+* If X86_LOCAL_APIC=n, the FIRST_SYSTEM_VECTOR is equal to NR_VECTORS
+* Just consider the X86_LOCAL_APIC=y case
+*/
 #ifdef CONFIG_X86_LOCAL_APIC
+   for_each_clear_bit_from(i, system_vectors, NR_VECTORS) {
set_bit(i, system_vectors);
set_intr_gate(i, spurious_interrupt);
-#else
-   entry = irq_entries_start + 8 * (i - FIRST_EXTERNAL_VECTOR);
-   set_intr_gate(i, entry);
-#endif
}
+#endif
 }
 
 /**
-- 
2.14.3

[PATCH] x86/idt: Simplify the idt_setup_apic_and_irq_gates()

[Dou Liyang]

The vectors between FIRST_SYSTEM_VECTOR and NR_VECTORS are special IRQ
vectors used by the SMP architecture. But, if X86_LOCAL_APIC=n, it will
not be used, and the FIRST_SYSTEM_VECTOR is equal to NR_VECTORS.

idt_setup_apic_and_irq_gates() didn't notice that, which make the code
a little complex.

Remove the code of the X86_LOCAL_APIC=n case to simplify it.

Signed-off-by: Dou Liyang 
---
 arch/x86/kernel/idt.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
index 2c3a1b4294eb..8b4174890706 100644
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -317,15 +317,16 @@ void __init idt_setup_apic_and_irq_gates(void)
set_intr_gate(i, entry);
}
 
-   for_each_clear_bit_from(i, system_vectors, NR_VECTORS) {
+   /*
+* If X86_LOCAL_APIC=n, the FIRST_SYSTEM_VECTOR is equal to NR_VECTORS
+* Just consider the X86_LOCAL_APIC=y case
+*/
 #ifdef CONFIG_X86_LOCAL_APIC
+   for_each_clear_bit_from(i, system_vectors, NR_VECTORS) {
set_bit(i, system_vectors);
set_intr_gate(i, spurious_interrupt);
-#else
-   entry = irq_entries_start + 8 * (i - FIRST_EXTERNAL_VECTOR);
-   set_intr_gate(i, entry);
-#endif
}
+#endif
 }
 
 /**
-- 
2.14.3

Re: [PATCH 0/3] K2G: mmc: Update mmc dt node to use sdhci-omap

[Kishon Vijay Abraham I]

On Wednesday 25 April 2018 11:10 PM, Santosh Shilimkar wrote:
> On 4/25/2018 6:27 AM, Kishon Vijay Abraham I wrote:
>> Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
>> binding.
>>
>> I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
>> Everyone who use a custom .config should also enable
>> CONFIG_MMC_SDHCI_OMAP for MMC to work.
>>
>> This series should be merged only after [1]
>> [1] -> https://marc.info/?l=linux-kernel=152465820531802=2
>>
> Keep me posted once the dependency gets merged.

sure.

Regards
Kishon

Re: [PATCH 0/3] K2G: mmc: Update mmc dt node to use sdhci-omap

[Kishon Vijay Abraham I]

On Wednesday 25 April 2018 11:10 PM, Santosh Shilimkar wrote:
> On 4/25/2018 6:27 AM, Kishon Vijay Abraham I wrote:
>> Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
>> binding.
>>
>> I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
>> Everyone who use a custom .config should also enable
>> CONFIG_MMC_SDHCI_OMAP for MMC to work.
>>
>> This series should be merged only after [1]
>> [1] -> https://marc.info/?l=linux-kernel=152465820531802=2
>>
> Keep me posted once the dependency gets merged.

sure.

Regards
Kishon

Re: [PATCH] net: phy: marvell: clear wol event before setting it

[Bhadram Varka]

Hi,

On 4/19/2018 5:48 PM, Andrew Lunn wrote:

On Thu, Apr 19, 2018 at 04:02:32PM +0800, Jisheng Zhang wrote:

From: Jingju Hou 

If WOL event happened once, the LED[2] interrupt pin will not be
cleared unless reading the CSISR register. So clear the WOL event
before enabling it.

Signed-off-by: Jingju Hou 
Signed-off-by: Jisheng Zhang 
---
  drivers/net/phy/marvell.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c22e8e383247..b6abe1cbc84b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -115,6 +115,9 @@
  /* WOL Event Interrupt Enable */
  #define MII_88E1318S_PHY_CSIER_WOL_EIEBIT(7)
  
+/* Copper Specific Interrupt Status Register */

+#define MII_88E1318S_PHY_CSISR 0x13
+
  /* LED Timer Control Register */
  #define MII_88E1318S_PHY_LED_TCR  0x12
  #define MII_88E1318S_PHY_LED_TCR_FORCE_INTBIT(15)
@@ -1393,6 +1396,12 @@ static int m88e1318_set_wol(struct phy_device *phydev,
if (err < 0)
goto error;
  
+		/* If WOL event happened once, the LED[2] interrupt pin

+* will not be cleared unless reading the CSISR register.
+* So clear the WOL event first before enabling it.
+*/
+   phy_read(phydev, MII_88E1318S_PHY_CSISR);
+

Hi Jisheng

The problem with this is, you could be clearing a real interrupt, link
down/up etc. If interrupts are in use, i think the normal interrupt
handling will clear the WOL interrupt? So can you make this read
conditional on !phy_interrupt_is_valid()?

So this will clear WoL interrupt bit from Copper Interrupt status register.

How about clearing WoL status (Page 17, register 17) for every WOL event ?

Observed that once WoL event occurred for magic packet then for next 
magic packet WoL event is not asserted.
Need to explicitly clear WOL status so that WOL interrupt will be 
generated by the HW.


Thanks,
Bhadram.



Thanks,
Bhadram

Re: [PATCH] net: phy: marvell: clear wol event before setting it

[Bhadram Varka]

Hi,

On 4/19/2018 5:48 PM, Andrew Lunn wrote:

On Thu, Apr 19, 2018 at 04:02:32PM +0800, Jisheng Zhang wrote:

From: Jingju Hou 

If WOL event happened once, the LED[2] interrupt pin will not be
cleared unless reading the CSISR register. So clear the WOL event
before enabling it.

Signed-off-by: Jingju Hou 
Signed-off-by: Jisheng Zhang 
---
  drivers/net/phy/marvell.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c22e8e383247..b6abe1cbc84b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -115,6 +115,9 @@
  /* WOL Event Interrupt Enable */
  #define MII_88E1318S_PHY_CSIER_WOL_EIEBIT(7)
  
+/* Copper Specific Interrupt Status Register */

+#define MII_88E1318S_PHY_CSISR 0x13
+
  /* LED Timer Control Register */
  #define MII_88E1318S_PHY_LED_TCR  0x12
  #define MII_88E1318S_PHY_LED_TCR_FORCE_INTBIT(15)
@@ -1393,6 +1396,12 @@ static int m88e1318_set_wol(struct phy_device *phydev,
if (err < 0)
goto error;
  
+		/* If WOL event happened once, the LED[2] interrupt pin

+* will not be cleared unless reading the CSISR register.
+* So clear the WOL event first before enabling it.
+*/
+   phy_read(phydev, MII_88E1318S_PHY_CSISR);
+

Hi Jisheng

The problem with this is, you could be clearing a real interrupt, link
down/up etc. If interrupts are in use, i think the normal interrupt
handling will clear the WOL interrupt? So can you make this read
conditional on !phy_interrupt_is_valid()?

So this will clear WoL interrupt bit from Copper Interrupt status register.

How about clearing WoL status (Page 17, register 17) for every WOL event ?

Observed that once WoL event occurred for magic packet then for next 
magic packet WoL event is not asserted.
Need to explicitly clear WOL status so that WOL interrupt will be 
generated by the HW.


Thanks,
Bhadram.



Thanks,
Bhadram

Re: [PATCH v2] staging: bcm2835-audio: Disconnect and free vchi_instance on module_exit()

[Dan Carpenter]

Greg deleted your patch already...

regards,
dan carpenter

Re: [PATCH v2] staging: bcm2835-audio: Disconnect and free vchi_instance on module_exit()

[Dan Carpenter]

Greg deleted your patch already...

regards,
dan carpenter

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

[Vittorio Gambaletta (VittGam)]

Hello,

On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote:
> On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote:
>> On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) 
>> wrote:
>> > This patch adds the correct platform data information for the Caroline
>> > Chromebook, so that the mouse button does not get stuck in pressed state
>> > after the first click.
>> >
>> > The Samus button keymap and platform data definition are the correct
>> > ones for Caroline, so they have been reused here.
>> >
>> > v2: updated patch offset after 20180409 changes.
>> >
>> > Cc: sta...@vger.kernel.org
>> > Signed-off-by: Vittorio Gambaletta 
>> > Signed-off-by: Salvatore Bellizzi 
>> >
>>
>> Applied, thank you.
>>
>> > ---
>> >
>> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
>> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
>> > @@ -3035,6 +3035,15 @@
>> >.driver_data = samus_platform_data,
>> >},
>> >{
>> > +  /* Samsung Chromebook Pro */
>> > +  .ident = "Samsung Chromebook Pro",
>> > +  .matches = {
>> > +  DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> 
> I've been alerted that shipping BIOS has vendor not capitalized; where
> did you get the firmware that has vendor all capitals?

Upstream coreboot and mrchromebox's coreboot, which do support loading Linux
natively or with UEFI, both use capitalized GOOGLE as DMI System Vendor
as far as I know.

By the way, the shipping BIOS (coreboot customized by Google) does not support
mainline Linux natively (eg. without seabios and nasty tricks), but only
Chromium OS, which for Caroline is an old 3.something fork of Linux, so this
patch does not really apply to Chromium OS or to Linux running on shipping BIOS.

Anyway if I recall correctly, the DMI System Vendor should be GOOGLE in
Google's coreboot for Caroline too, but I'm not 100% sure and cannot check
right now.

By the way please note that this is the DMI System Vendor and not the DMI
BIOS version string, which indeed starts with "Google_" in the shipping BIOS
(but not in coreboot, see f56db262e46d3368ee4e5c9e19797853cab382cd).

> Thanks.

Cheers,
Vittorio G

>> > +  DMI_MATCH(DMI_PRODUCT_NAME, "Caroline"),
>> > +  },
>> > +  .driver_data = samus_platform_data,
>> > +  },
>> > +  {
>> >/* Other Google Chromebooks */
>> >.ident = "Chromebook",
>> >.matches = {
>>
>> --
>> Dmitry

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

[Vittorio Gambaletta (VittGam)]

Hello,

On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote:
> On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote:
>> On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) 
>> wrote:
>> > This patch adds the correct platform data information for the Caroline
>> > Chromebook, so that the mouse button does not get stuck in pressed state
>> > after the first click.
>> >
>> > The Samus button keymap and platform data definition are the correct
>> > ones for Caroline, so they have been reused here.
>> >
>> > v2: updated patch offset after 20180409 changes.
>> >
>> > Cc: sta...@vger.kernel.org
>> > Signed-off-by: Vittorio Gambaletta 
>> > Signed-off-by: Salvatore Bellizzi 
>> >
>>
>> Applied, thank you.
>>
>> > ---
>> >
>> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
>> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
>> > @@ -3035,6 +3035,15 @@
>> >.driver_data = samus_platform_data,
>> >},
>> >{
>> > +  /* Samsung Chromebook Pro */
>> > +  .ident = "Samsung Chromebook Pro",
>> > +  .matches = {
>> > +  DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> 
> I've been alerted that shipping BIOS has vendor not capitalized; where
> did you get the firmware that has vendor all capitals?

Upstream coreboot and mrchromebox's coreboot, which do support loading Linux
natively or with UEFI, both use capitalized GOOGLE as DMI System Vendor
as far as I know.

By the way, the shipping BIOS (coreboot customized by Google) does not support
mainline Linux natively (eg. without seabios and nasty tricks), but only
Chromium OS, which for Caroline is an old 3.something fork of Linux, so this
patch does not really apply to Chromium OS or to Linux running on shipping BIOS.

Anyway if I recall correctly, the DMI System Vendor should be GOOGLE in
Google's coreboot for Caroline too, but I'm not 100% sure and cannot check
right now.

By the way please note that this is the DMI System Vendor and not the DMI
BIOS version string, which indeed starts with "Google_" in the shipping BIOS
(but not in coreboot, see f56db262e46d3368ee4e5c9e19797853cab382cd).

> Thanks.

Cheers,
Vittorio G

>> > +  DMI_MATCH(DMI_PRODUCT_NAME, "Caroline"),
>> > +  },
>> > +  .driver_data = samus_platform_data,
>> > +  },
>> > +  {
>> >/* Other Google Chromebooks */
>> >.ident = "Chromebook",
>> >.matches = {
>>
>> --
>> Dmitry

[tip:x86/urgent] x86/vector: Remove the macro VECTOR_OFFSET_START

[tip-bot for Dou Liyang]

Commit-ID:  e3072805c61167b85a30ceeef606620704db31f7
Gitweb: https://git.kernel.org/tip/e3072805c61167b85a30ceeef606620704db31f7
Author: Dou Liyang 
AuthorDate: Wed, 25 Apr 2018 10:05:53 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Apr 2018 07:31:17 +0200

x86/vector: Remove the macro VECTOR_OFFSET_START

Now, Linux uses matrix allocator for vector assignment, the original
assignment code which used VECTOR_OFFSET_START has been removed.

So remove the stale macro as well.

Fixes: commit 69cde0004a4b ("x86/vector: Use matrix allocator for vector 
assignment")
Signed-off-by: Dou Liyang 
Signed-off-by: Thomas Gleixner 
Acked-by: David Rientjes 
Cc: h...@zytor.com
Link: https://lkml.kernel.org/r/20180425020553.17210-1-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/irq_vectors.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 404c5fdff859..57003074bd7a 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -34,11 +34,6 @@
  * (0x80 is the syscall vector, 0x30-0x3f are for ISA)
  */
 #define FIRST_EXTERNAL_VECTOR  0x20
-/*
- * We start allocating at 0x21 to spread out vectors evenly between
- * priority levels. (0x80 is the syscall vector)
- */
-#define VECTOR_OFFSET_START1
 
 /*
  * Reserve the lowest usable vector (and hence lowest priority)  0x20 for

[tip:x86/urgent] x86/vector: Remove the macro VECTOR_OFFSET_START

[tip-bot for Dou Liyang]

Commit-ID:  e3072805c61167b85a30ceeef606620704db31f7
Gitweb: https://git.kernel.org/tip/e3072805c61167b85a30ceeef606620704db31f7
Author: Dou Liyang 
AuthorDate: Wed, 25 Apr 2018 10:05:53 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Apr 2018 07:31:17 +0200

x86/vector: Remove the macro VECTOR_OFFSET_START

Now, Linux uses matrix allocator for vector assignment, the original
assignment code which used VECTOR_OFFSET_START has been removed.

So remove the stale macro as well.

Fixes: commit 69cde0004a4b ("x86/vector: Use matrix allocator for vector 
assignment")
Signed-off-by: Dou Liyang 
Signed-off-by: Thomas Gleixner 
Acked-by: David Rientjes 
Cc: h...@zytor.com
Link: https://lkml.kernel.org/r/20180425020553.17210-1-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/irq_vectors.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 404c5fdff859..57003074bd7a 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -34,11 +34,6 @@
  * (0x80 is the syscall vector, 0x30-0x3f are for ISA)
  */
 #define FIRST_EXTERNAL_VECTOR  0x20
-/*
- * We start allocating at 0x21 to spread out vectors evenly between
- * priority levels. (0x80 is the syscall vector)
- */
-#define VECTOR_OFFSET_START1
 
 /*
  * Reserve the lowest usable vector (and hence lowest priority)  0x20 for

[tip:x86/urgent] x86/cpufeatures: Enumerate cldemote instruction

[tip-bot for Fenghua Yu]

Commit-ID:  9124130573950dcfc06b6a59306edfda2fc33ec7
Gitweb: https://git.kernel.org/tip/9124130573950dcfc06b6a59306edfda2fc33ec7
Author: Fenghua Yu 
AuthorDate: Mon, 23 Apr 2018 11:29:22 -0700
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Apr 2018 07:31:12 +0200

x86/cpufeatures: Enumerate cldemote instruction

cldemote is a new instruction in future x86 processors. It hints
to hardware that a specified cache line should be moved ("demoted")
from the cache(s) closest to the processor core to a level more
distant from the processor core. This instruction is faster than
snooping to make the cache line available for other cores.

cldemote instruction is indicated by the presence of the CPUID
feature flag CLDEMOTE (CPUID.(EAX=0x7, ECX=0):ECX[bit25]).

More details on cldemote instruction can be found in the latest
Intel Architecture Instruction Set Extensions and Future Features
Programming Reference.

Signed-off-by: Fenghua Yu 
Signed-off-by: Thomas Gleixner 
Cc: "Ravi V Shankar" 
Cc: "H. Peter Anvin" 
Cc: "Ashok Raj" 
Link: 
https://lkml.kernel.org/r/1524508162-192587-1-git-send-email-fenghua...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index d554c11e01ff..578793e97431 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -320,6 +320,7 @@
 #define X86_FEATURE_AVX512_VPOPCNTDQ   (16*32+14) /* POPCNT for vectors of 
DW/QW */
 #define X86_FEATURE_LA57   (16*32+16) /* 5-level page tables */
 #define X86_FEATURE_RDPID  (16*32+22) /* RDPID instruction */
+#define X86_FEATURE_CLDEMOTE   (16*32+25) /* CLDEMOTE instruction */
 
 /* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery 
support */

Re: issues with suspend on Dell XPS 13 2-in-1

[Pandruvada, Srinivas]

Hi Dennis,

On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote:
> Hi Srinivas,
> 
> Yes I have latest bios, I have version 1.3.1 that was released on
> 18th
> of  Feb.
Can you try these commands and repeat the test?

# cd /sys/kernel/debug/pmc_core/
# for i in {0..32}; do echo $i > ltr_ignore; done

Thanks,
Srinivas

> 
> Dennis
> 
> El jue, 26-04-2018 a las 02:13 +, Pandruvada, Srinivas escribió:
> > 
> > I see around 43% PC10 residency with power drop of 0.7W.
> > Do you have the latest BIOS of Dell 9365?
> > 
> > 
> > Thanks,
> > Srinivas
> > 
> > On Fri, 2018-04-20 at 08:36 -0500, Dennis Gilmore wrote:
> > > Here is the full output 
> > > 
> > > # turbostat
> > > turbostat version 17.06.23 - Len Brown 
> > > CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping
> > > 0x6:8e:9 (6:142:9)
> > > CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM TM
> > > CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow,
> > > HWPepp, No-HWPpkg, EPB
> > > cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT
> > > PREFETCH
> > > TURBO)
> > > CPUID(7): SGX
> > > cpu0: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked )
> > > CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0
> > > TSC: 1608 MHz (2400 Hz * 134 / 2 / 100)
> > > CPUID(0x16): base_mhz: 1600 max_mhz: 3600 bus_mhz: 100
> > > cpu0: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination
> > > DISable-EPB DISable-OOB)
> > > RAPL: 58254 sec. Joule Counter Range, at 4 Watts
> > > cpu0: MSR_PLATFORM_INFO: 0x804043df1011000
> > > 4 * 100.0 = 400.0 MHz max efficiency frequency
> > > 16 * 100.0 = 1600.0 MHz base frequency
> > > cpu0: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion:
> > > DISabled)
> > > cpu0: MSR_TURBO_RATIO_LIMIT: 0x2224
> > > 34 * 100.0 = 3400.0 MHz max turbo 4 active cores
> > > 34 * 100.0 = 3400.0 MHz max turbo 3 active cores
> > > 34 * 100.0 = 3400.0 MHz max turbo 2 active cores
> > > 36 * 100.0 = 3600.0 MHz max turbo 1 active cores
> > > cpu0: MSR_CONFIG_TDP_NOMINAL: 0x000d (base_ratio=13)
> > > cpu0: MSR_CONFIG_TDP_LEVEL_1: 0x0006001c (PKG_MIN_PWR_LVL1=0
> > > PKG_MAX_PWR_LVL1=0 LVL1_RATIO=6 PKG_TDP_LVL1=28)
> > > cpu0: MSR_CONFIG_TDP_LEVEL_2: 0x00100038 (PKG_MIN_PWR_LVL2=0
> > > PKG_MAX_PWR_LVL2=0 LVL2_RATIO=16 PKG_TDP_LVL2=56)
> > > cpu0: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0)
> > > cpu0: MSR_TURBO_ACTIVATION_RATIO: 0x000c
> > > (MAX_NON_TURBO_RATIO=12 lock=0)
> > > cpu0: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3,
> > > UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=8:
> > > unlimited)
> > > cpu0: POLL: CPUIDLE CORE POLL IDLE
> > > cpu0: C1: MWAIT 0x00
> > > cpu0: C1E: MWAIT 0x01
> > > cpu0: C3: MWAIT 0x10
> > > cpu0: C6: MWAIT 0x20
> > > cpu0: C7s: MWAIT 0x33
> > > cpu0: C8: MWAIT 0x40
> > > cpu0: C9: MWAIT 0x50
> > > cpu0: C10: MWAIT 0x60
> > > cpu0: cpufreq driver: intel_pstate
> > > cpu0: cpufreq governor: powersave
> > > cpufreq intel_pstate no_turbo: 0
> > > cpu0: MSR_MISC_FEATURE_CONTROL: 0x (L2-Prefetch L2-
> > > Prefetch-pair L1-Prefetch L1-IP-Prefetch)
> > > cpu0: MSR_PM_ENABLE: 0x0001 (HWP)
> > > cpu0: MSR_HWP_CAPABILITIES: 0x01060d24 (high 36 guar 13 eff 6 low
> > > 1)
> > > cpu0: MSR_HWP_REQUEST: 0x80002404 (min 4 max 36 des 0 epp 0x80
> > > window 0x0 pkg 0x0)
> > > cpu0: MSR_HWP_INTERRUPT: 0x (Dis_Guaranteed_Perf_Change,
> > > Dis_Excursion_Min)
> > > cpu0: MSR_HWP_STATUS: 0x (No-Guaranteed_Perf_Change, No-
> > > Excursion_Min)
> > > cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0006 (balanced)
> > > cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.61
> > > Joules, 0.000977 sec.)
> > > cpu0: MSR_PKG_POWER_INFO: 0x0024 (4 W TDP, RAPL 0 - 0 W,
> > > 0.00 sec.)
> > > cpu0: MSR_PKG_POWER_LIMIT: 0x420078009c8048 (UNlocked)
> > > cpu0: PKG Limit #1: ENabled (9.00 Watts, 24.00 sec, clamp
> > > DISabled)
> > > cpu0: PKG Limit #2: DISabled (15.00 Watts, 0.002441* sec,
> > > clamp
> > > DISabled)
> > > cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de (UNlocked)
> > > cpu0: DRAM Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
> > > DISabled)
> > > cpu0: MSR_PP0_POLICY: 0
> > > cpu0: MSR_PP0_POWER_LIMIT: 0x (UNlocked)
> > > cpu0: Cores Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
> > > DISabled)
> > > cpu0: MSR_PP1_POLICY: 0
> > > cpu0: MSR_PP1_POWER_LIMIT: 0x (UNlocked)
> > > cpu0: GFX Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
> > > DISabled)
> > > cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x0a640080 (100 C)
> > > cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88380802 (44 C)
> > > cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x0003 (100 C, 100 C)
> > > cpu0: MSR_PKGC3_IRTL: 0x884e (valid, 79872 ns)
> > > cpu0: MSR_PKGC6_IRTL: 0x8876 (valid, 120832 ns)
> > > cpu0: MSR_PKGC7_IRTL: 0x8894 (valid, 151552 ns)
> > > cpu0: MSR_PKGC8_IRTL: 0x88fa (valid, 256000 ns)
> > > cpu0: MSR_PKGC9_IRTL: 0x894c (valid, 339968 ns)
> > > cpu0: MSR_PKGC10_IRTL: 

[tip:x86/urgent] x86/cpufeatures: Enumerate cldemote instruction

[tip-bot for Fenghua Yu]

Commit-ID:  9124130573950dcfc06b6a59306edfda2fc33ec7
Gitweb: https://git.kernel.org/tip/9124130573950dcfc06b6a59306edfda2fc33ec7
Author: Fenghua Yu 
AuthorDate: Mon, 23 Apr 2018 11:29:22 -0700
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Apr 2018 07:31:12 +0200

x86/cpufeatures: Enumerate cldemote instruction

cldemote is a new instruction in future x86 processors. It hints
to hardware that a specified cache line should be moved ("demoted")
from the cache(s) closest to the processor core to a level more
distant from the processor core. This instruction is faster than
snooping to make the cache line available for other cores.

cldemote instruction is indicated by the presence of the CPUID
feature flag CLDEMOTE (CPUID.(EAX=0x7, ECX=0):ECX[bit25]).

More details on cldemote instruction can be found in the latest
Intel Architecture Instruction Set Extensions and Future Features
Programming Reference.

Signed-off-by: Fenghua Yu 
Signed-off-by: Thomas Gleixner 
Cc: "Ravi V Shankar" 
Cc: "H. Peter Anvin" 
Cc: "Ashok Raj" 
Link: 
https://lkml.kernel.org/r/1524508162-192587-1-git-send-email-fenghua...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index d554c11e01ff..578793e97431 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -320,6 +320,7 @@
 #define X86_FEATURE_AVX512_VPOPCNTDQ   (16*32+14) /* POPCNT for vectors of 
DW/QW */
 #define X86_FEATURE_LA57   (16*32+16) /* 5-level page tables */
 #define X86_FEATURE_RDPID  (16*32+22) /* RDPID instruction */
+#define X86_FEATURE_CLDEMOTE   (16*32+25) /* CLDEMOTE instruction */
 
 /* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */
 #define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery 
support */

Re: issues with suspend on Dell XPS 13 2-in-1

[Pandruvada, Srinivas]

Hi Dennis,

On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote:
> Hi Srinivas,
> 
> Yes I have latest bios, I have version 1.3.1 that was released on
> 18th
> of  Feb.
Can you try these commands and repeat the test?

# cd /sys/kernel/debug/pmc_core/
# for i in {0..32}; do echo $i > ltr_ignore; done

Thanks,
Srinivas

> 
> Dennis
> 
> El jue, 26-04-2018 a las 02:13 +, Pandruvada, Srinivas escribió:
> > 
> > I see around 43% PC10 residency with power drop of 0.7W.
> > Do you have the latest BIOS of Dell 9365?
> > 
> > 
> > Thanks,
> > Srinivas
> > 
> > On Fri, 2018-04-20 at 08:36 -0500, Dennis Gilmore wrote:
> > > Here is the full output 
> > > 
> > > # turbostat
> > > turbostat version 17.06.23 - Len Brown 
> > > CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping
> > > 0x6:8e:9 (6:142:9)
> > > CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM TM
> > > CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow,
> > > HWPepp, No-HWPpkg, EPB
> > > cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT
> > > PREFETCH
> > > TURBO)
> > > CPUID(7): SGX
> > > cpu0: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked )
> > > CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0
> > > TSC: 1608 MHz (2400 Hz * 134 / 2 / 100)
> > > CPUID(0x16): base_mhz: 1600 max_mhz: 3600 bus_mhz: 100
> > > cpu0: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination
> > > DISable-EPB DISable-OOB)
> > > RAPL: 58254 sec. Joule Counter Range, at 4 Watts
> > > cpu0: MSR_PLATFORM_INFO: 0x804043df1011000
> > > 4 * 100.0 = 400.0 MHz max efficiency frequency
> > > 16 * 100.0 = 1600.0 MHz base frequency
> > > cpu0: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion:
> > > DISabled)
> > > cpu0: MSR_TURBO_RATIO_LIMIT: 0x2224
> > > 34 * 100.0 = 3400.0 MHz max turbo 4 active cores
> > > 34 * 100.0 = 3400.0 MHz max turbo 3 active cores
> > > 34 * 100.0 = 3400.0 MHz max turbo 2 active cores
> > > 36 * 100.0 = 3600.0 MHz max turbo 1 active cores
> > > cpu0: MSR_CONFIG_TDP_NOMINAL: 0x000d (base_ratio=13)
> > > cpu0: MSR_CONFIG_TDP_LEVEL_1: 0x0006001c (PKG_MIN_PWR_LVL1=0
> > > PKG_MAX_PWR_LVL1=0 LVL1_RATIO=6 PKG_TDP_LVL1=28)
> > > cpu0: MSR_CONFIG_TDP_LEVEL_2: 0x00100038 (PKG_MIN_PWR_LVL2=0
> > > PKG_MAX_PWR_LVL2=0 LVL2_RATIO=16 PKG_TDP_LVL2=56)
> > > cpu0: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0)
> > > cpu0: MSR_TURBO_ACTIVATION_RATIO: 0x000c
> > > (MAX_NON_TURBO_RATIO=12 lock=0)
> > > cpu0: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3,
> > > UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=8:
> > > unlimited)
> > > cpu0: POLL: CPUIDLE CORE POLL IDLE
> > > cpu0: C1: MWAIT 0x00
> > > cpu0: C1E: MWAIT 0x01
> > > cpu0: C3: MWAIT 0x10
> > > cpu0: C6: MWAIT 0x20
> > > cpu0: C7s: MWAIT 0x33
> > > cpu0: C8: MWAIT 0x40
> > > cpu0: C9: MWAIT 0x50
> > > cpu0: C10: MWAIT 0x60
> > > cpu0: cpufreq driver: intel_pstate
> > > cpu0: cpufreq governor: powersave
> > > cpufreq intel_pstate no_turbo: 0
> > > cpu0: MSR_MISC_FEATURE_CONTROL: 0x (L2-Prefetch L2-
> > > Prefetch-pair L1-Prefetch L1-IP-Prefetch)
> > > cpu0: MSR_PM_ENABLE: 0x0001 (HWP)
> > > cpu0: MSR_HWP_CAPABILITIES: 0x01060d24 (high 36 guar 13 eff 6 low
> > > 1)
> > > cpu0: MSR_HWP_REQUEST: 0x80002404 (min 4 max 36 des 0 epp 0x80
> > > window 0x0 pkg 0x0)
> > > cpu0: MSR_HWP_INTERRUPT: 0x (Dis_Guaranteed_Perf_Change,
> > > Dis_Excursion_Min)
> > > cpu0: MSR_HWP_STATUS: 0x (No-Guaranteed_Perf_Change, No-
> > > Excursion_Min)
> > > cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0006 (balanced)
> > > cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.61
> > > Joules, 0.000977 sec.)
> > > cpu0: MSR_PKG_POWER_INFO: 0x0024 (4 W TDP, RAPL 0 - 0 W,
> > > 0.00 sec.)
> > > cpu0: MSR_PKG_POWER_LIMIT: 0x420078009c8048 (UNlocked)
> > > cpu0: PKG Limit #1: ENabled (9.00 Watts, 24.00 sec, clamp
> > > DISabled)
> > > cpu0: PKG Limit #2: DISabled (15.00 Watts, 0.002441* sec,
> > > clamp
> > > DISabled)
> > > cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de (UNlocked)
> > > cpu0: DRAM Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
> > > DISabled)
> > > cpu0: MSR_PP0_POLICY: 0
> > > cpu0: MSR_PP0_POWER_LIMIT: 0x (UNlocked)
> > > cpu0: Cores Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
> > > DISabled)
> > > cpu0: MSR_PP1_POLICY: 0
> > > cpu0: MSR_PP1_POWER_LIMIT: 0x (UNlocked)
> > > cpu0: GFX Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
> > > DISabled)
> > > cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x0a640080 (100 C)
> > > cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88380802 (44 C)
> > > cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x0003 (100 C, 100 C)
> > > cpu0: MSR_PKGC3_IRTL: 0x884e (valid, 79872 ns)
> > > cpu0: MSR_PKGC6_IRTL: 0x8876 (valid, 120832 ns)
> > > cpu0: MSR_PKGC7_IRTL: 0x8894 (valid, 151552 ns)
> > > cpu0: MSR_PKGC8_IRTL: 0x88fa (valid, 256000 ns)
> > > cpu0: MSR_PKGC9_IRTL: 0x894c (valid, 339968 ns)
> > > cpu0: MSR_PKGC10_IRTL: 0x8bf2 (valid, 

Re: [GIT PULL 00/12] perf/urgent fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit c042f7e9bb6ad9429ea0f2c9138dc06413198967:
> 
>   Merge tag 'perf-urgent-for-mingo-4.17-20180420' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2018-04-21 09:38:33 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-4.17-20180425
> 
> for you to fetch changes up to 80ee8c588afde077cb0439e15129579a267916c4:
> 
>   perf stat: Fix duplicate PMU name for interval print (2018-04-24 16:12:00 
> -0300)
> 
> 
> perf/urgent fixes:
> 
> perf stat:
> 
> - Keep the '/' event modifier separator in fallback, for example when
>   fallbacking from 'cpu/cpu-cycles/' to user level only, where it should
>   become 'cpu/cpu-cycles/u' and not 'cpu/cpu-cycles/:u' (Jiri Olsa)
> 
> - Fix PMU events parsing rule, improving error reporting for
>   invalid events (Jiri Olsa)
> 
> - Disable write_backward and other event attributes for !group
>   events in a group, fixing, for instance this group: '{cycles,msr/aperf/}:S'
>   that has leader sampling (:S) and where just the 'cycles',
>   the leader event, should have the write_backward attribute
>   set, in this case it all fails because the PMU where 'msr/aperf/'
>   lives doesn't accepts write_backward style sampling (Jiri Olsa)
> 
> - Only fall back group read for leader (Kan Liang)
> 
> - Fix core PMU alias list for X86 platform (Kan Liang)
> 
> - Print out hint for mixed PMU group error (Kan Liang)
> 
> - Fix duplicate PMU name for interval print (Kan Liang)
> 
> Core:
> 
> - Set main kernel end address properly when reading kernel and
>   module maps (Namhyung Kim)
> 
> perf mem:
> 
> - Fix incorrect entries and add missing man options (Sangwon Hong)
> 
> s/390:
> 
> - Remove s390 specific strcmp_cpuid_cmp function (Thomas Richter)
> 
> - Adapt 'perf test' case record+probe_libc_inet_pton.sh for s390
> 
> - Fix s390 undefined record__auxtrace_init() return value in
>   'perf record' (Thomas Richter)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Jiri Olsa (3):
>   perf stat: Keep the / modifier separator in fallback
>   perf pmu: Fix pmu events parsing rule
>   perf evsel: Disable write_backward for leader sampling group events
> 
> Kan Liang (4):
>   perf pmu: Fix core PMU alias list for X86 platform
>   perf stat: Print out hint for mixed PMU group error
>   perf evsel: Only fall back group read for leader
>   perf stat: Fix duplicate PMU name for interval print
> 
> Namhyung Kim (1):
>   perf machine: Set main kernel end address properly
> 
> Sangwon Hong (1):
>   perf mem: Document incorrect and missing options
> 
> Thomas Richter (3):
>   perf list: Remove s390 specific strcmp_cpuid_cmp function
>   perf test: Adapt test case record+probe_libc_inet_pton.sh for s390
>   perf record: Fix s390 undefined record__auxtrace_init() return value
> 
>  tools/perf/Documentation/perf-mem.txt  | 41 
> +++---
>  tools/perf/arch/s390/util/auxtrace.c   |  1 +
>  tools/perf/arch/s390/util/header.c | 18 --
>  tools/perf/builtin-stat.c  | 40 +++--
>  tools/perf/pmu-events/arch/s390/mapfile.csv| 10 +++---
>  tools/perf/tests/attr/test-record-group-sampling   |  3 ++
>  .../tests/shell/record+probe_libc_inet_pton.sh |  6 ++--
>  tools/perf/util/evsel.c| 18 +++---
>  tools/perf/util/evsel.h|  1 +
>  tools/perf/util/machine.c  | 30 +---
>  tools/perf/util/parse-events.y |  8 ++---
>  tools/perf/util/pmu.c  | 22 +---
>  12 files changed, 123 insertions(+), 75 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: [GIT PULL 00/12] perf/urgent fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit c042f7e9bb6ad9429ea0f2c9138dc06413198967:
> 
>   Merge tag 'perf-urgent-for-mingo-4.17-20180420' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2018-04-21 09:38:33 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-4.17-20180425
> 
> for you to fetch changes up to 80ee8c588afde077cb0439e15129579a267916c4:
> 
>   perf stat: Fix duplicate PMU name for interval print (2018-04-24 16:12:00 
> -0300)
> 
> 
> perf/urgent fixes:
> 
> perf stat:
> 
> - Keep the '/' event modifier separator in fallback, for example when
>   fallbacking from 'cpu/cpu-cycles/' to user level only, where it should
>   become 'cpu/cpu-cycles/u' and not 'cpu/cpu-cycles/:u' (Jiri Olsa)
> 
> - Fix PMU events parsing rule, improving error reporting for
>   invalid events (Jiri Olsa)
> 
> - Disable write_backward and other event attributes for !group
>   events in a group, fixing, for instance this group: '{cycles,msr/aperf/}:S'
>   that has leader sampling (:S) and where just the 'cycles',
>   the leader event, should have the write_backward attribute
>   set, in this case it all fails because the PMU where 'msr/aperf/'
>   lives doesn't accepts write_backward style sampling (Jiri Olsa)
> 
> - Only fall back group read for leader (Kan Liang)
> 
> - Fix core PMU alias list for X86 platform (Kan Liang)
> 
> - Print out hint for mixed PMU group error (Kan Liang)
> 
> - Fix duplicate PMU name for interval print (Kan Liang)
> 
> Core:
> 
> - Set main kernel end address properly when reading kernel and
>   module maps (Namhyung Kim)
> 
> perf mem:
> 
> - Fix incorrect entries and add missing man options (Sangwon Hong)
> 
> s/390:
> 
> - Remove s390 specific strcmp_cpuid_cmp function (Thomas Richter)
> 
> - Adapt 'perf test' case record+probe_libc_inet_pton.sh for s390
> 
> - Fix s390 undefined record__auxtrace_init() return value in
>   'perf record' (Thomas Richter)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Jiri Olsa (3):
>   perf stat: Keep the / modifier separator in fallback
>   perf pmu: Fix pmu events parsing rule
>   perf evsel: Disable write_backward for leader sampling group events
> 
> Kan Liang (4):
>   perf pmu: Fix core PMU alias list for X86 platform
>   perf stat: Print out hint for mixed PMU group error
>   perf evsel: Only fall back group read for leader
>   perf stat: Fix duplicate PMU name for interval print
> 
> Namhyung Kim (1):
>   perf machine: Set main kernel end address properly
> 
> Sangwon Hong (1):
>   perf mem: Document incorrect and missing options
> 
> Thomas Richter (3):
>   perf list: Remove s390 specific strcmp_cpuid_cmp function
>   perf test: Adapt test case record+probe_libc_inet_pton.sh for s390
>   perf record: Fix s390 undefined record__auxtrace_init() return value
> 
>  tools/perf/Documentation/perf-mem.txt  | 41 
> +++---
>  tools/perf/arch/s390/util/auxtrace.c   |  1 +
>  tools/perf/arch/s390/util/header.c | 18 --
>  tools/perf/builtin-stat.c  | 40 +++--
>  tools/perf/pmu-events/arch/s390/mapfile.csv| 10 +++---
>  tools/perf/tests/attr/test-record-group-sampling   |  3 ++
>  .../tests/shell/record+probe_libc_inet_pton.sh |  6 ++--
>  tools/perf/util/evsel.c| 18 +++---
>  tools/perf/util/evsel.h|  1 +
>  tools/perf/util/machine.c  | 30 +---
>  tools/perf/util/parse-events.y |  8 ++---
>  tools/perf/util/pmu.c  | 22 +---
>  12 files changed, 123 insertions(+), 75 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

[Viresh Kumar]

@Thomas: Do you guys use this ?

On 25-04-18, 20:57, Rob Herring wrote:
> Remove LPC32xx and SPEAr ADC bindings in staging. They have not been
> touched since 2012.
> 
> Cc: Roland Stigge 
> Cc: Stefan Roese 
> Cc: Jonathan Cameron 
> Cc: Viresh Kumar 
> Signed-off-by: Rob Herring 
> ---
> Move these out of staging please or they are going to be removed.
> 
>  .../bindings/staging/iio/adc/lpc32xx-adc.txt   | 16 -
>  .../bindings/staging/iio/adc/spear-adc.txt | 26 
> --
>  2 files changed, 42 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt 
> b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
> deleted file mode 100644
> index b3629d3a9adf..
> --- a/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -* NXP LPC32xx SoC ADC controller
> -
> -Required properties:
> -- compatible: must be "nxp,lpc3220-adc"
> -- reg: physical base address of the controller and length of memory mapped
> -  region.
> -- interrupts: The ADC interrupt
> -
> -Example:
> -
> - adc@40048000 {
> - compatible = "nxp,lpc3220-adc";
> - reg = <0x40048000 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <39 0>;
> - };
> diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt 
> b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
> deleted file mode 100644
> index 02ea23a63f20..
> --- a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -* ST SPEAr ADC device driver
> -
> -Required properties:
> -- compatible: Should be "st,spear600-adc"
> -- reg: Address and length of the register set for the device
> -- interrupt-parent: Should be the phandle for the interrupt controller
> -  that services interrupts for this device
> -- interrupts: Should contain the ADC interrupt
> -- sampling-frequency: Default sampling frequency
> -
> -Optional properties:
> -- vref-external: External voltage reference in milli-volts. If omitted
> -  the internal voltage reference will be used.
> -- average-samples: Number of samples to generate an average value. If
> -  omitted, single data conversion will be used.
> -
> -Examples:
> -
> - adc: adc@d820 {
> - compatible = "st,spear600-adc";
> - reg = <0xd820 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <6>;
> - sampling-frequency = <500>;
> - vref-external = <2500>; /* 2.5V VRef */
> - };
> -- 
> 2.14.1

-- 
viresh

Re: [PATCH] dt-bindings: staging: remove a couple of ADC bindings

[Viresh Kumar]

@Thomas: Do you guys use this ?

On 25-04-18, 20:57, Rob Herring wrote:
> Remove LPC32xx and SPEAr ADC bindings in staging. They have not been
> touched since 2012.
> 
> Cc: Roland Stigge 
> Cc: Stefan Roese 
> Cc: Jonathan Cameron 
> Cc: Viresh Kumar 
> Signed-off-by: Rob Herring 
> ---
> Move these out of staging please or they are going to be removed.
> 
>  .../bindings/staging/iio/adc/lpc32xx-adc.txt   | 16 -
>  .../bindings/staging/iio/adc/spear-adc.txt | 26 
> --
>  2 files changed, 42 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt 
> b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
> deleted file mode 100644
> index b3629d3a9adf..
> --- a/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -* NXP LPC32xx SoC ADC controller
> -
> -Required properties:
> -- compatible: must be "nxp,lpc3220-adc"
> -- reg: physical base address of the controller and length of memory mapped
> -  region.
> -- interrupts: The ADC interrupt
> -
> -Example:
> -
> - adc@40048000 {
> - compatible = "nxp,lpc3220-adc";
> - reg = <0x40048000 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <39 0>;
> - };
> diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt 
> b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
> deleted file mode 100644
> index 02ea23a63f20..
> --- a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -* ST SPEAr ADC device driver
> -
> -Required properties:
> -- compatible: Should be "st,spear600-adc"
> -- reg: Address and length of the register set for the device
> -- interrupt-parent: Should be the phandle for the interrupt controller
> -  that services interrupts for this device
> -- interrupts: Should contain the ADC interrupt
> -- sampling-frequency: Default sampling frequency
> -
> -Optional properties:
> -- vref-external: External voltage reference in milli-volts. If omitted
> -  the internal voltage reference will be used.
> -- average-samples: Number of samples to generate an average value. If
> -  omitted, single data conversion will be used.
> -
> -Examples:
> -
> - adc: adc@d820 {
> - compatible = "st,spear600-adc";
> - reg = <0xd820 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <6>;
> - sampling-frequency = <500>;
> - vref-external = <2500>; /* 2.5V VRef */
> - };
> -- 
> 2.14.1

-- 
viresh

Re: [PATCH V3] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

[Vaidyanathan Srinivasan]

* Shilpa Bhat  [2018-04-25 16:29:31]:

> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
> 
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 
> (unreliable)
> [c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250
> [c03fe566b3f0] [c0acd3e8] gpstate_timer_handler+0x1e8/0x580
> [c03fe566b4a0] [c01b46b0] call_timer_fn+0x50/0x1c0
> [c03fe566b520] [c01b4958] expire_timers+0x138/0x1f0
> [c03fe566b590] [c01b4bf8] run_timer_softirq+0x1e8/0x270
> [c03fe566b630] [c0d0d6c8] __do_softirq+0x158/0x3e4
> [c03fe566b710] [c0114be8] irq_exit+0xe8/0x120
> [c03fe566b730] [c0024d0c] timer_interrupt+0x9c/0xe0
> [c03fe566b760] [c0009014] decrementer_common+0x114/0x120
> -- interrupt: 901 at doorbell_global_ipi+0x34/0x50
> LR = arch_send_call_function_ipi_mask+0x120/0x130
> [c03fe566ba50] [c004876c]
> arch_send_call_function_ipi_mask+0x4c/0x130
> [c03fe566ba90] [c01d59f0] smp_call_function_many+0x340/0x450
> [c03fe566bb00] [c0075f18] pmdp_invalidate+0x98/0xe0
> [c03fe566bb30] [c03a1120] change_huge_pmd+0xe0/0x270
> [c03fe566bba0] [c0349278] change_protection_range+0xb88/0xe40
> [c03fe566bcf0] [c03496c0] mprotect_fixup+0x140/0x340
> [c03fe566bdb0] [c0349a74] SyS_mprotect+0x1b4/0x350
> [c03fe566be30] [c000b184] system_call+0x58/0x6c
> 
> One way to avoid this is removing the smp-call. We can ensure that the timer
> always runs on one of the policy-cpus. If the timer gets migrated to a
> cpu outside the policy then re-queue it back on the policy->cpus. This way
> we can get rid of the smp-call which was being used to set the pstate
> on the policy->cpus.
> 
> Fixes: 7bc54b652f13 (timers, cpufreq/powernv: Initialize the gpstate timer as 
> pinned)
> Cc: [4.8+]
> Reported-by: Nicholas Piggin 
> Reported-by: Pridhiviraj Paidipeddi 
> Signed-off-by: Shilpasri G Bhat 
> ---
> Changes from V2:
> - Remove the check for active policy while requeing the migrated timer
> Changes from V1:
> - Remove smp_call in the pstate handler.
> 
>  drivers/cpufreq/powernv-cpufreq.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index 71f8682..e368e1f 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -679,6 +679,16 @@ void gpstate_timer_handler(struct timer_list *t)
> 
>   if (!spin_trylock(>gpstate_lock))
>   return;
> + /*
> +  * If the timer has migrated to the different cpu then bring
> +  * it back to one of the policy->cpus
> +  */
> + if (!cpumask_test_cpu(raw_smp_processor_id(), policy->cpus)) {
> + gpstates->timer.expires = jiffies + msecs_to_jiffies(1);
> + add_timer_on(>timer, cpumask_first(policy->cpus));
> + spin_unlock(>gpstate_lock);
> + return;
> + }
> 
>   /*
>* If PMCR was last updated was using fast_swtich then
> @@ -718,10 +728,8 @@ void gpstate_timer_handler(struct timer_list *t)
>   if (gpstate_idx != gpstates->last_lpstate_idx)
>   queue_gpstate_timer(gpstates);
> 
> + set_pstate(_data);
>   spin_unlock(>gpstate_lock);
> -
> - /* Timer may get migrated to a different cpu on cpu hot unplug */
> - smp_call_function_any(policy->cpus, set_pstate, _data, 1);
>  }

Fix looks good. 

Acked-by: Vaidyanathan Srinivasan 

Re: [PATCH V3] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

[Vaidyanathan Srinivasan]

* Shilpa Bhat  [2018-04-25 16:29:31]:

> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
> 
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 
> (unreliable)
> [c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250
> [c03fe566b3f0] [c0acd3e8] gpstate_timer_handler+0x1e8/0x580
> [c03fe566b4a0] [c01b46b0] call_timer_fn+0x50/0x1c0
> [c03fe566b520] [c01b4958] expire_timers+0x138/0x1f0
> [c03fe566b590] [c01b4bf8] run_timer_softirq+0x1e8/0x270
> [c03fe566b630] [c0d0d6c8] __do_softirq+0x158/0x3e4
> [c03fe566b710] [c0114be8] irq_exit+0xe8/0x120
> [c03fe566b730] [c0024d0c] timer_interrupt+0x9c/0xe0
> [c03fe566b760] [c0009014] decrementer_common+0x114/0x120
> -- interrupt: 901 at doorbell_global_ipi+0x34/0x50
> LR = arch_send_call_function_ipi_mask+0x120/0x130
> [c03fe566ba50] [c004876c]
> arch_send_call_function_ipi_mask+0x4c/0x130
> [c03fe566ba90] [c01d59f0] smp_call_function_many+0x340/0x450
> [c03fe566bb00] [c0075f18] pmdp_invalidate+0x98/0xe0
> [c03fe566bb30] [c03a1120] change_huge_pmd+0xe0/0x270
> [c03fe566bba0] [c0349278] change_protection_range+0xb88/0xe40
> [c03fe566bcf0] [c03496c0] mprotect_fixup+0x140/0x340
> [c03fe566bdb0] [c0349a74] SyS_mprotect+0x1b4/0x350
> [c03fe566be30] [c000b184] system_call+0x58/0x6c
> 
> One way to avoid this is removing the smp-call. We can ensure that the timer
> always runs on one of the policy-cpus. If the timer gets migrated to a
> cpu outside the policy then re-queue it back on the policy->cpus. This way
> we can get rid of the smp-call which was being used to set the pstate
> on the policy->cpus.
> 
> Fixes: 7bc54b652f13 (timers, cpufreq/powernv: Initialize the gpstate timer as 
> pinned)
> Cc: [4.8+]
> Reported-by: Nicholas Piggin 
> Reported-by: Pridhiviraj Paidipeddi 
> Signed-off-by: Shilpasri G Bhat 
> ---
> Changes from V2:
> - Remove the check for active policy while requeing the migrated timer
> Changes from V1:
> - Remove smp_call in the pstate handler.
> 
>  drivers/cpufreq/powernv-cpufreq.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index 71f8682..e368e1f 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -679,6 +679,16 @@ void gpstate_timer_handler(struct timer_list *t)
> 
>   if (!spin_trylock(>gpstate_lock))
>   return;
> + /*
> +  * If the timer has migrated to the different cpu then bring
> +  * it back to one of the policy->cpus
> +  */
> + if (!cpumask_test_cpu(raw_smp_processor_id(), policy->cpus)) {
> + gpstates->timer.expires = jiffies + msecs_to_jiffies(1);
> + add_timer_on(>timer, cpumask_first(policy->cpus));
> + spin_unlock(>gpstate_lock);
> + return;
> + }
> 
>   /*
>* If PMCR was last updated was using fast_swtich then
> @@ -718,10 +728,8 @@ void gpstate_timer_handler(struct timer_list *t)
>   if (gpstate_idx != gpstates->last_lpstate_idx)
>   queue_gpstate_timer(gpstates);
> 
> + set_pstate(_data);
>   spin_unlock(>gpstate_lock);
> -
> - /* Timer may get migrated to a different cpu on cpu hot unplug */
> - smp_call_function_any(policy->cpus, set_pstate, _data, 1);
>  }

Fix looks good. 

Acked-by: Vaidyanathan Srinivasan 

Re: [PATCH v14 0/9] Address error and recovery for AER and DPC

[poza]

On 2018-04-23 20:53, Oza Pawandeep wrote:

This patch set brings in error handling support for DPC

The current implementation of AER and error message broadcasting to the
EP driver is tightly coupled and limited to AER service driver.
It is important to factor out broadcasting and other link handling
callbacks. So that not only when AER gets triggered, but also when DPC 
get

triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.

The goal of the patch-set is:
DPC should handle the error handling and recovery similar to AER, 
because

finally both are attempting recovery in some or the other way,
and for that error handling and recovery framework has to be loosely
coupled.

It achieves uniformity and transparency to the error handling agents 
such

as AER, DPC, with respect to recovery and error handling.

So, this patch-set tries to unify lot of things between error agents 
and

make them behave in a well defined way. (be it error (FATAL, NON_FATAL)
handling or recovery).

The FATAL error handling is handled with remove/reset_link/re-enumerate
sequence while the NON_FATAL follows the default path.
Documentation/PCI/pci-error-recovery.txt talks more on that.

Changes since v13:
Bjorn's comments addressed
> handke FATAL errors with remove devices followed by 
re-enumeration.

> changes in AER and DPC along with required Documentation.
Changes since v12:
Bjorn's and Keith's Comments addressed.
> Made DPC and AER error handling identical 
> hanldled cases for hotplug enabled system differently.
Changes since v11:
Bjorn's comments addressed.
> rename pcie-err.c to err.c
> removed EXPORT_SYMBOL
> made generic find_serivce function in port driver.
> removed mutex patch as no need to have mutex in pcie_do_recovery
> brough in DPC_FATAL in aer.h
> so now all the error codes (AER and DPC) are unified in aer.h
Changes since v10:
Christoph Hellwig's, David Laight's and Randy Dunlap's
comments addressed.
> renamed pci_do_recovery to pcie_do_recovery
> removed inner braces in conditional statements.
> restrctured the code in pci_wait_for_link
> EXPORT_SYMBOL_GPL
Changes since v9:
Sinan's comments addressed.
> bool active = true; unnecessary variable removed.
Changes since v8:
Fixed Kbuild errors.
Changes since v7:
Rebased the code on pci master
> 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/helgaas/pci

Changes since v6:
Sinan's and Stefan's comments implemented.
> reordered patch 6 and 7
> cleaned up
Changes since v5:
Sinan's and Keith's comments incorporated.
> made separate patch for mutex
> unified error repotting codes into driver/pci/pci.h
> got rid of wait link active/inactive and
  made generic function in driver/pci/pci.c
Changes since v4:
Bjorn's comments incorporated.
> Renamed only do_recovery.
> moved the things more locally to drivers/pci/pci.h
Changes since v3:
Bjorn's comments incorporated.
> Made separate patch renaming generic pci_err.c
> Introduce pci_err.h to contain all the error types and 
recovery

> removed all the dependencies on pci.h
Changes since v2:
Based on feedback from Keith:
"
When DPC is triggered due to receipt of an uncorrectable error 
Message,

the Requester ID from the Message is recorded in the DPC Error
Source ID register and that Message is discarded and not forwarded 
Upstream.

"
Removed the patch where AER checks if DPC service is active
Changes since v1:
Kbuild errors fixed:
> pci_find_dpc_dev made static
> ras_event.h updated
> pci_find_aer_service call with CONFIG check
> pci_find_dpc_service call with CONFIG check

Oza Pawandeep (9):
  PCI/AER: Rename error recovery to generic PCI naming
  PCI/AER: Factor out error reporting from AER
  PCI/PORTDRV: Implement generic find service
  PCI/PORTDRV: Implement generic find device
  PCI/DPC: Unify and plumb error handling into DPC
  PCI: Unify wait for link active into generic PCI
  PCI/DPC: Disable ERR_NONFATAL for DPC
  PCI/AER/DPC: Align FATAL error handling for AER and DPC
  pci-error-recovery: Add AER_FATAL handling

 Documentation/PCI/pci-error-recovery.txt |  35 ++-
 drivers/pci/hotplug/pciehp_hpc.c |  20 +-
 drivers/pci/pci.c|  30 +++
 drivers/pci/pci.h|   5 +
 drivers/pci/pcie/Makefile|   2 +-
 drivers/pci/pcie/aer/aerdrv.c|   2 +
 drivers/pci/pcie/aer/aerdrv.h|  30 ---
 drivers/pci/pcie/aer/aerdrv_core.c   | 317 
+-
 drivers/pci/pcie/err.c   | 374 
+++

 drivers/pci/pcie/pcie-dpc.c  |  63 +++---
 drivers/pci/pcie/portdrv.h   |   4 +
 drivers/pci/pcie/portdrv_core.c  |  69 ++
 include/linux/aer.h 

Re: [PATCH v14 0/9] Address error and recovery for AER and DPC

[poza]

On 2018-04-23 20:53, Oza Pawandeep wrote:

This patch set brings in error handling support for DPC

The current implementation of AER and error message broadcasting to the
EP driver is tightly coupled and limited to AER service driver.
It is important to factor out broadcasting and other link handling
callbacks. So that not only when AER gets triggered, but also when DPC 
get

triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.

The goal of the patch-set is:
DPC should handle the error handling and recovery similar to AER, 
because

finally both are attempting recovery in some or the other way,
and for that error handling and recovery framework has to be loosely
coupled.

It achieves uniformity and transparency to the error handling agents 
such

as AER, DPC, with respect to recovery and error handling.

So, this patch-set tries to unify lot of things between error agents 
and

make them behave in a well defined way. (be it error (FATAL, NON_FATAL)
handling or recovery).

The FATAL error handling is handled with remove/reset_link/re-enumerate
sequence while the NON_FATAL follows the default path.
Documentation/PCI/pci-error-recovery.txt talks more on that.

Changes since v13:
Bjorn's comments addressed
> handke FATAL errors with remove devices followed by 
re-enumeration.

> changes in AER and DPC along with required Documentation.
Changes since v12:
Bjorn's and Keith's Comments addressed.
> Made DPC and AER error handling identical 
> hanldled cases for hotplug enabled system differently.
Changes since v11:
Bjorn's comments addressed.
> rename pcie-err.c to err.c
> removed EXPORT_SYMBOL
> made generic find_serivce function in port driver.
> removed mutex patch as no need to have mutex in pcie_do_recovery
> brough in DPC_FATAL in aer.h
> so now all the error codes (AER and DPC) are unified in aer.h
Changes since v10:
Christoph Hellwig's, David Laight's and Randy Dunlap's
comments addressed.
> renamed pci_do_recovery to pcie_do_recovery
> removed inner braces in conditional statements.
> restrctured the code in pci_wait_for_link
> EXPORT_SYMBOL_GPL
Changes since v9:
Sinan's comments addressed.
> bool active = true; unnecessary variable removed.
Changes since v8:
Fixed Kbuild errors.
Changes since v7:
Rebased the code on pci master
> 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/helgaas/pci

Changes since v6:
Sinan's and Stefan's comments implemented.
> reordered patch 6 and 7
> cleaned up
Changes since v5:
Sinan's and Keith's comments incorporated.
> made separate patch for mutex
> unified error repotting codes into driver/pci/pci.h
> got rid of wait link active/inactive and
  made generic function in driver/pci/pci.c
Changes since v4:
Bjorn's comments incorporated.
> Renamed only do_recovery.
> moved the things more locally to drivers/pci/pci.h
Changes since v3:
Bjorn's comments incorporated.
> Made separate patch renaming generic pci_err.c
> Introduce pci_err.h to contain all the error types and 
recovery

> removed all the dependencies on pci.h
Changes since v2:
Based on feedback from Keith:
"
When DPC is triggered due to receipt of an uncorrectable error 
Message,

the Requester ID from the Message is recorded in the DPC Error
Source ID register and that Message is discarded and not forwarded 
Upstream.

"
Removed the patch where AER checks if DPC service is active
Changes since v1:
Kbuild errors fixed:
> pci_find_dpc_dev made static
> ras_event.h updated
> pci_find_aer_service call with CONFIG check
> pci_find_dpc_service call with CONFIG check

Oza Pawandeep (9):
  PCI/AER: Rename error recovery to generic PCI naming
  PCI/AER: Factor out error reporting from AER
  PCI/PORTDRV: Implement generic find service
  PCI/PORTDRV: Implement generic find device
  PCI/DPC: Unify and plumb error handling into DPC
  PCI: Unify wait for link active into generic PCI
  PCI/DPC: Disable ERR_NONFATAL for DPC
  PCI/AER/DPC: Align FATAL error handling for AER and DPC
  pci-error-recovery: Add AER_FATAL handling

 Documentation/PCI/pci-error-recovery.txt |  35 ++-
 drivers/pci/hotplug/pciehp_hpc.c |  20 +-
 drivers/pci/pci.c|  30 +++
 drivers/pci/pci.h|   5 +
 drivers/pci/pcie/Makefile|   2 +-
 drivers/pci/pcie/aer/aerdrv.c|   2 +
 drivers/pci/pcie/aer/aerdrv.h|  30 ---
 drivers/pci/pcie/aer/aerdrv_core.c   | 317 
+-
 drivers/pci/pcie/err.c   | 374 
+++

 drivers/pci/pcie/pcie-dpc.c  |  63 +++---
 drivers/pci/pcie/portdrv.h   |   4 +
 drivers/pci/pcie/portdrv_core.c  |  69 ++
 include/linux/aer.h 

Re: Moving unmaintained filesystems to staging

[Willy Tarreau]

On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote:
> 
> 
> On 25.04.2018 23:30, David Sterba wrote:
> > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> >> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> >> developers report bugs in hfs, which they deem a security hole because
> >> Ubuntu attempts to automount an inserted USB device as hfs.
> >>
> >> We have no maintainer for hfs, and no likely prospect of anyone stepping
> >> up soon to become hfs maintainer.  I think it's irresponsible of us
> >> to present unmaintained code on an equal basis with filesystems under
> >> active maintenance like ext2.
> >>
> >> I therefore propose we move the following filesystems which are explicitly
> >> listed as Orphaned to staging:
> >>
> >> affs - Amiga filesystem.
> >> efs - old SGI filesystem predating XFS, used on CDs for a while.
> >> hfs - Mac filesystem.
> >> hfsplus - Mac filesystem.
> >>
> >> I further propose we move the following filesystems which have no entry
> >> in MAINTAINERS to staging:
> >>
> >> adfs - Acorn filesystem from the 1990s.
> >> minix
> >> qnx6
> > 
> > I had similar toughts some time ago while browsing the fs/ directory.
> > Access to the filesystem images can be reimplemented in FUSE, but other
> > than that, I don't think the in-kernel code would be missed.
> > 
> > It's hard to know how many users are there. I was curious eg. about bfs,
> > befs, coda or feevxfs, looked at the last commits and searched around
> > web if there are any mentions or user community. But as long as there's
> > somebody listed in MAINTAINERS, the above are not candidates for moving
> > to staging or deletion.
> > 
> 
> I think the presence of maintainers entry is necessary but insufficient.
> What if the maintainer has long lost interest but just didn't bother
> updating the file. In the very least maintainers should be pinged and
> asked if they are still maintaining the respective piece of code.

That's a good point. However the age of the last commit must not be used
as an excuse for moving them, because if the few users are very happy with
the code, never meet corner cases and never have to report bugs, neither
them nor the maintainers should be punished. In my opinion the only two
reasons for deprecating or removing code are that it's not maintained
anymore or that it's using ancient infrastructure that needs to be
changed and there's no way to adapt the old code to the new one.

In fact I think that the problem with very silent maintainers goes way
beyond FS. Everyone in MAINTAINERS who didn't send a commit in one year
should probably be asked if they're still doing the work, if they'd be
interested in someone else taking over, or if they think the whole code
has no reason to continue to exist.

Willy

Re: Moving unmaintained filesystems to staging

[Willy Tarreau]

On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote:
> 
> 
> On 25.04.2018 23:30, David Sterba wrote:
> > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> >> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> >> developers report bugs in hfs, which they deem a security hole because
> >> Ubuntu attempts to automount an inserted USB device as hfs.
> >>
> >> We have no maintainer for hfs, and no likely prospect of anyone stepping
> >> up soon to become hfs maintainer.  I think it's irresponsible of us
> >> to present unmaintained code on an equal basis with filesystems under
> >> active maintenance like ext2.
> >>
> >> I therefore propose we move the following filesystems which are explicitly
> >> listed as Orphaned to staging:
> >>
> >> affs - Amiga filesystem.
> >> efs - old SGI filesystem predating XFS, used on CDs for a while.
> >> hfs - Mac filesystem.
> >> hfsplus - Mac filesystem.
> >>
> >> I further propose we move the following filesystems which have no entry
> >> in MAINTAINERS to staging:
> >>
> >> adfs - Acorn filesystem from the 1990s.
> >> minix
> >> qnx6
> > 
> > I had similar toughts some time ago while browsing the fs/ directory.
> > Access to the filesystem images can be reimplemented in FUSE, but other
> > than that, I don't think the in-kernel code would be missed.
> > 
> > It's hard to know how many users are there. I was curious eg. about bfs,
> > befs, coda or feevxfs, looked at the last commits and searched around
> > web if there are any mentions or user community. But as long as there's
> > somebody listed in MAINTAINERS, the above are not candidates for moving
> > to staging or deletion.
> > 
> 
> I think the presence of maintainers entry is necessary but insufficient.
> What if the maintainer has long lost interest but just didn't bother
> updating the file. In the very least maintainers should be pinged and
> asked if they are still maintaining the respective piece of code.

That's a good point. However the age of the last commit must not be used
as an excuse for moving them, because if the few users are very happy with
the code, never meet corner cases and never have to report bugs, neither
them nor the maintainers should be punished. In my opinion the only two
reasons for deprecating or removing code are that it's not maintained
anymore or that it's using ancient infrastructure that needs to be
changed and there's no way to adapt the old code to the new one.

In fact I think that the problem with very silent maintainers goes way
beyond FS. Everyone in MAINTAINERS who didn't send a commit in one year
should probably be asked if they're still doing the work, if they'd be
interested in someone else taking over, or if they think the whole code
has no reason to continue to exist.

Willy

Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()

[Sean Wang]

On Tue, 2018-04-03 at 12:29 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to add common attach functions for PM domains to serdev
> > at the probe phase.
> > 
> > Similarly, the relevant dettach function for the PM domains should be
> > properly and reversely added at the remove phase.
> > 
> > Signed-off-by: Sean Wang 
> > Cc: Rob Herring 
> > Cc: Ulf Hansson 
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: linux-ser...@vger.kernel.org
> > ---
> > drivers/tty/serdev/core.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index df93b72..c93d8ee 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -13,6 +13,7 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > #include 
> > #include 
> > 
> > @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> > static int serdev_drv_probe(struct device *dev)
> > {
> > const struct serdev_device_driver *sdrv = 
> > to_serdev_device_driver(dev->driver);
> > +   int ret;
> > +
> > +   ret = dev_pm_domain_attach(dev, true);
> > +   if (ret != -EPROBE_DEFER) {
> > +   ret = sdrv->probe(to_serdev_device(dev));
> > +   if (ret)
> > +   dev_pm_domain_detach(dev, true);
> > +   }
> 
> so if this is deferred, when does the serdev device gets probed?
> 

driver probe deferral mechanism is supported in driver core

deferred_probe_initcall makes sure that deferred probing is
delayed until late_initcall time.


Below is a few of word I got from drivers/base/core.c I thought it helps
to understand the mechanism in complete picture

* If a required resource is not available yet, a driver can
request probing to be deferred by returning -EPROBE_DEFER from
its probe hook.

* A driver returning -EPROBE_DEFER causes the device to be added to the
pending list.  A successful driver probe will trigger moving all devices
from the pending to the active list so that the workqueue will
eventually retry them.

> > 
> > -   return sdrv->probe(to_serdev_device(dev));
> > +   return ret;
> > }
> > 
> > static int serdev_drv_remove(struct device *dev)
> > @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> > const struct serdev_device_driver *sdrv = 
> > to_serdev_device_driver(dev->driver);
> > if (sdrv->remove)
> > sdrv->remove(to_serdev_device(dev));
> > +
> > +   dev_pm_domain_detach(dev, true);
> > +
> > return 0;
> > }
> 
> Regards
> 
> Marcel
> 

Re: [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach()

[Sean Wang]

On Tue, 2018-04-03 at 12:29 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > In order to open up the required power gate before any operation can be
> > effectively performed over the serial bus between CPU and serdev, it's
> > clearly essential to add common attach functions for PM domains to serdev
> > at the probe phase.
> > 
> > Similarly, the relevant dettach function for the PM domains should be
> > properly and reversely added at the remove phase.
> > 
> > Signed-off-by: Sean Wang 
> > Cc: Rob Herring 
> > Cc: Ulf Hansson 
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: linux-ser...@vger.kernel.org
> > ---
> > drivers/tty/serdev/core.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index df93b72..c93d8ee 100644
> > --- a/drivers/tty/serdev/core.c
> > +++ b/drivers/tty/serdev/core.c
> > @@ -13,6 +13,7 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > #include 
> > #include 
> > 
> > @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> > static int serdev_drv_probe(struct device *dev)
> > {
> > const struct serdev_device_driver *sdrv = 
> > to_serdev_device_driver(dev->driver);
> > +   int ret;
> > +
> > +   ret = dev_pm_domain_attach(dev, true);
> > +   if (ret != -EPROBE_DEFER) {
> > +   ret = sdrv->probe(to_serdev_device(dev));
> > +   if (ret)
> > +   dev_pm_domain_detach(dev, true);
> > +   }
> 
> so if this is deferred, when does the serdev device gets probed?
> 

driver probe deferral mechanism is supported in driver core

deferred_probe_initcall makes sure that deferred probing is
delayed until late_initcall time.


Below is a few of word I got from drivers/base/core.c I thought it helps
to understand the mechanism in complete picture

* If a required resource is not available yet, a driver can
request probing to be deferred by returning -EPROBE_DEFER from
its probe hook.

* A driver returning -EPROBE_DEFER causes the device to be added to the
pending list.  A successful driver probe will trigger moving all devices
from the pending to the active list so that the workqueue will
eventually retry them.

> > 
> > -   return sdrv->probe(to_serdev_device(dev));
> > +   return ret;
> > }
> > 
> > static int serdev_drv_remove(struct device *dev)
> > @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> > const struct serdev_device_driver *sdrv = 
> > to_serdev_device_driver(dev->driver);
> > if (sdrv->remove)
> > sdrv->remove(to_serdev_device(dev));
> > +
> > +   dev_pm_domain_detach(dev, true);
> > +
> > return 0;
> > }
> 
> Regards
> 
> Marcel
> 

linux-next: Tree for Apr 26

[Stephen Rothwell]

Hi all,

News: There will be no linux-next release tomorrow.

Changes since 20180424:

The qcom tree gained a build failure so I used the version from
next-20180424.

The clk-samsung tree gained a build failure so I used the version from
next-20180424.

The bpf-next tree gained conflicts against the bpf and net-next trees.

The wireless-drivers-next gained a conflict against the wireless-drivers
tree.

The rpmsg tree gained a build failure so I used the version from
next-20180424.

Non-merge commits (relative to Linus' tree): 2654
 2460 files changed, 93337 insertions(+), 43456 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

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 (3be4aaf4e2d3 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (ad40bdafb495 arm64: support __int128 with 
clang)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (75ecfb49516c powerpc/mce: Fix a bug where mce 
loops on memory UE.)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (91a825290ca4 rds: ib: Fix missing call to rds_ib_dev_put in 
rds_ib_setup_qp)
Merging bpf/master (9c299a32ede9 bpf: fix for lex/yacc build error with gcc-5)
Merging ipsec/master (b48c05ab5d32 xfrm: Fix warning in xfrm6_tunnel_net_exit.)
Merging netfilter/master (6cd968f44814 Merge branch 'amd-xgbe-fixes')
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (af8a41cccf8f rtlwifi: cleanup 8723be ant_sel 
definition)
Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external 
authentication failure)
Merging rdma-fixes/for-rc (dc5640f294e4 IB/core: Fix deleting default GIDs when 
changing mac adddress)
Merging sound-current/for-linus (8a7d6003df41 ALSA: hda - Skip jack and others 
for non-existing PCM streams)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (b93815d0f37e firmware: some 
documentation fixes)
Merging tty.current/tty-linus (bcdd0ca8cb87 tty: Use __GFP_NOFAIL for 
tty_ldisc_get())
Merging usb.current/usb-linus (be75d8f1da08 USB: musb: dsps: drop duplicate phy 
initialisation)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (470b5d6f0cf4 USB: serial: ftdi_sio: use 
jtag quirk for Arrow USB Blaster)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes 

linux-next: Tree for Apr 26

[Stephen Rothwell]

Hi all,

News: There will be no linux-next release tomorrow.

Changes since 20180424:

The qcom tree gained a build failure so I used the version from
next-20180424.

The clk-samsung tree gained a build failure so I used the version from
next-20180424.

The bpf-next tree gained conflicts against the bpf and net-next trees.

The wireless-drivers-next gained a conflict against the wireless-drivers
tree.

The rpmsg tree gained a build failure so I used the version from
next-20180424.

Non-merge commits (relative to Linus' tree): 2654
 2460 files changed, 93337 insertions(+), 43456 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

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 (3be4aaf4e2d3 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (ad40bdafb495 arm64: support __int128 with 
clang)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (75ecfb49516c powerpc/mce: Fix a bug where mce 
loops on memory UE.)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (91a825290ca4 rds: ib: Fix missing call to rds_ib_dev_put in 
rds_ib_setup_qp)
Merging bpf/master (9c299a32ede9 bpf: fix for lex/yacc build error with gcc-5)
Merging ipsec/master (b48c05ab5d32 xfrm: Fix warning in xfrm6_tunnel_net_exit.)
Merging netfilter/master (6cd968f44814 Merge branch 'amd-xgbe-fixes')
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (af8a41cccf8f rtlwifi: cleanup 8723be ant_sel 
definition)
Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external 
authentication failure)
Merging rdma-fixes/for-rc (dc5640f294e4 IB/core: Fix deleting default GIDs when 
changing mac adddress)
Merging sound-current/for-linus (8a7d6003df41 ALSA: hda - Skip jack and others 
for non-existing PCM streams)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (b93815d0f37e firmware: some 
documentation fixes)
Merging tty.current/tty-linus (bcdd0ca8cb87 tty: Use __GFP_NOFAIL for 
tty_ldisc_get())
Merging usb.current/usb-linus (be75d8f1da08 USB: musb: dsps: drop duplicate phy 
initialisation)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (470b5d6f0cf4 USB: serial: ftdi_sio: use 
jtag quirk for Arrow USB Blaster)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes 

Re: [PATCH V3] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

[Viresh Kumar]

On 25-04-18, 16:29, Shilpasri G Bhat wrote:
> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
> 
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 
> (unreliable)
> [c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250
> [c03fe566b3f0] [c0acd3e8] gpstate_timer_handler+0x1e8/0x580
> [c03fe566b4a0] [c01b46b0] call_timer_fn+0x50/0x1c0
> [c03fe566b520] [c01b4958] expire_timers+0x138/0x1f0
> [c03fe566b590] [c01b4bf8] run_timer_softirq+0x1e8/0x270
> [c03fe566b630] [c0d0d6c8] __do_softirq+0x158/0x3e4
> [c03fe566b710] [c0114be8] irq_exit+0xe8/0x120
> [c03fe566b730] [c0024d0c] timer_interrupt+0x9c/0xe0
> [c03fe566b760] [c0009014] decrementer_common+0x114/0x120
> -- interrupt: 901 at doorbell_global_ipi+0x34/0x50
> LR = arch_send_call_function_ipi_mask+0x120/0x130
> [c03fe566ba50] [c004876c]
> arch_send_call_function_ipi_mask+0x4c/0x130
> [c03fe566ba90] [c01d59f0] smp_call_function_many+0x340/0x450
> [c03fe566bb00] [c0075f18] pmdp_invalidate+0x98/0xe0
> [c03fe566bb30] [c03a1120] change_huge_pmd+0xe0/0x270
> [c03fe566bba0] [c0349278] change_protection_range+0xb88/0xe40
> [c03fe566bcf0] [c03496c0] mprotect_fixup+0x140/0x340
> [c03fe566bdb0] [c0349a74] SyS_mprotect+0x1b4/0x350
> [c03fe566be30] [c000b184] system_call+0x58/0x6c
> 
> One way to avoid this is removing the smp-call. We can ensure that the timer
> always runs on one of the policy-cpus. If the timer gets migrated to a
> cpu outside the policy then re-queue it back on the policy->cpus. This way
> we can get rid of the smp-call which was being used to set the pstate
> on the policy->cpus.
> 
> Fixes: 7bc54b652f13 (timers, cpufreq/powernv: Initialize the gpstate timer as 
> pinned)
> Cc: [4.8+]
> Reported-by: Nicholas Piggin 
> Reported-by: Pridhiviraj Paidipeddi 
> Signed-off-by: Shilpasri G Bhat 
> ---
> Changes from V2:
> - Remove the check for active policy while requeing the migrated timer
> Changes from V1:
> - Remove smp_call in the pstate handler.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH V3] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

[Viresh Kumar]

On 25-04-18, 16:29, Shilpasri G Bhat wrote:
> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
> 
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180 
> (unreliable)
> [c03fe566b390] [c01d55e0] smp_call_function_any+0x180/0x250
> [c03fe566b3f0] [c0acd3e8] gpstate_timer_handler+0x1e8/0x580
> [c03fe566b4a0] [c01b46b0] call_timer_fn+0x50/0x1c0
> [c03fe566b520] [c01b4958] expire_timers+0x138/0x1f0
> [c03fe566b590] [c01b4bf8] run_timer_softirq+0x1e8/0x270
> [c03fe566b630] [c0d0d6c8] __do_softirq+0x158/0x3e4
> [c03fe566b710] [c0114be8] irq_exit+0xe8/0x120
> [c03fe566b730] [c0024d0c] timer_interrupt+0x9c/0xe0
> [c03fe566b760] [c0009014] decrementer_common+0x114/0x120
> -- interrupt: 901 at doorbell_global_ipi+0x34/0x50
> LR = arch_send_call_function_ipi_mask+0x120/0x130
> [c03fe566ba50] [c004876c]
> arch_send_call_function_ipi_mask+0x4c/0x130
> [c03fe566ba90] [c01d59f0] smp_call_function_many+0x340/0x450
> [c03fe566bb00] [c0075f18] pmdp_invalidate+0x98/0xe0
> [c03fe566bb30] [c03a1120] change_huge_pmd+0xe0/0x270
> [c03fe566bba0] [c0349278] change_protection_range+0xb88/0xe40
> [c03fe566bcf0] [c03496c0] mprotect_fixup+0x140/0x340
> [c03fe566bdb0] [c0349a74] SyS_mprotect+0x1b4/0x350
> [c03fe566be30] [c000b184] system_call+0x58/0x6c
> 
> One way to avoid this is removing the smp-call. We can ensure that the timer
> always runs on one of the policy-cpus. If the timer gets migrated to a
> cpu outside the policy then re-queue it back on the policy->cpus. This way
> we can get rid of the smp-call which was being used to set the pstate
> on the policy->cpus.
> 
> Fixes: 7bc54b652f13 (timers, cpufreq/powernv: Initialize the gpstate timer as 
> pinned)
> Cc: [4.8+]
> Reported-by: Nicholas Piggin 
> Reported-by: Pridhiviraj Paidipeddi 
> Signed-off-by: Shilpasri G Bhat 
> ---
> Changes from V2:
> - Remove the check for active policy while requeing the migrated timer
> Changes from V1:
> - Remove smp_call in the pstate handler.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RFC 05/10] i2c: s3c2410: Remove support for Exynos5440

[andi]

Hi Krzysztof,

On 25.04.2018 05:32, Krzysztof Kozlowski wrote:

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 


looks good, Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: [RFC 05/10] i2c: s3c2410: Remove support for Exynos5440

[andi]

Hi Krzysztof,

On 25.04.2018 05:32, Krzysztof Kozlowski wrote:

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 


looks good, Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

> Thanks for the report!
>
> I assume since you're upgrading your own kernel, you must not be
> running Chrome OS on your Acer CB3-431 Chromebook (Edgar).  Are you
> running Chromium --- or some Linux distribution on it?
>
> Thanks,
>
>   - Ted

Correct, I'm running Xubuntu 18.04 with my own kernel based off linux-stable.

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

> Thanks for the report!
>
> I assume since you're upgrading your own kernel, you must not be
> running Chrome OS on your Acer CB3-431 Chromebook (Edgar).  Are you
> running Chromium --- or some Linux distribution on it?
>
> Thanks,
>
>   - Ted

Correct, I'm running Xubuntu 18.04 with my own kernel based off linux-stable.

Re: Linux messages full of `random: get_random_u32 called from`

[Theodore Y. Ts'o]

On Wed, Apr 25, 2018 at 09:11:08PM -0700, Sultan Alsawaf wrote:
> I noticed "systems without sufficient boot randomness" and would like to add 
> to this.
> 
> With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec 
> Chromebook does not reach
> the login screen upon boot (it stays stuck on a black screen) until I provide 
> a source of entropy to
> the system via interrupts (e.g., holding down a key on the keyboard for 5 sec 
> or moving my finger
> across the touchpad a lot). After providing a source of entropy for long 
> enough,
> "random: crng init done" prints out in dmesg and the login screen finally 
> pops up.

Thanks for the report!

I assume since you're upgrading your own kernel, you must not be
running Chrome OS on your Acer CB3-431 Chromebook (Edgar).  Are you
running Chromium --- or some Linux distribution on it?

Thanks,

- Ted

Re: Linux messages full of `random: get_random_u32 called from`

[Theodore Y. Ts'o]

On Wed, Apr 25, 2018 at 09:11:08PM -0700, Sultan Alsawaf wrote:
> I noticed "systems without sufficient boot randomness" and would like to add 
> to this.
> 
> With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec 
> Chromebook does not reach
> the login screen upon boot (it stays stuck on a black screen) until I provide 
> a source of entropy to
> the system via interrupts (e.g., holding down a key on the keyboard for 5 sec 
> or moving my finger
> across the touchpad a lot). After providing a source of entropy for long 
> enough,
> "random: crng init done" prints out in dmesg and the login screen finally 
> pops up.

Thanks for the report!

I assume since you're upgrading your own kernel, you must not be
running Chrome OS on your Acer CB3-431 Chromebook (Edgar).  Are you
running Chromium --- or some Linux distribution on it?

Thanks,

- Ted

Re: Moving unmaintained filesystems to staging

[Nikolay Borisov]

On 25.04.2018 23:30, David Sterba wrote:
> On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
>> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
>> developers report bugs in hfs, which they deem a security hole because
>> Ubuntu attempts to automount an inserted USB device as hfs.
>>
>> We have no maintainer for hfs, and no likely prospect of anyone stepping
>> up soon to become hfs maintainer.  I think it's irresponsible of us
>> to present unmaintained code on an equal basis with filesystems under
>> active maintenance like ext2.
>>
>> I therefore propose we move the following filesystems which are explicitly
>> listed as Orphaned to staging:
>>
>> affs - Amiga filesystem.
>> efs - old SGI filesystem predating XFS, used on CDs for a while.
>> hfs - Mac filesystem.
>> hfsplus - Mac filesystem.
>>
>> I further propose we move the following filesystems which have no entry
>> in MAINTAINERS to staging:
>>
>> adfs - Acorn filesystem from the 1990s.
>> minix
>> qnx6
> 
> I had similar toughts some time ago while browsing the fs/ directory.
> Access to the filesystem images can be reimplemented in FUSE, but other
> than that, I don't think the in-kernel code would be missed.
> 
> It's hard to know how many users are there. I was curious eg. about bfs,
> befs, coda or feevxfs, looked at the last commits and searched around
> web if there are any mentions or user community. But as long as there's
> somebody listed in MAINTAINERS, the above are not candidates for moving
> to staging or deletion.
> 

I think the presence of maintainers entry is necessary but insufficient.
What if the maintainer has long lost interest but just didn't bother
updating the file. In the very least maintainers should be pinged and
asked if they are still maintaining the respective piece of code.

Re: Moving unmaintained filesystems to staging

[Nikolay Borisov]

On 25.04.2018 23:30, David Sterba wrote:
> On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
>> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
>> developers report bugs in hfs, which they deem a security hole because
>> Ubuntu attempts to automount an inserted USB device as hfs.
>>
>> We have no maintainer for hfs, and no likely prospect of anyone stepping
>> up soon to become hfs maintainer.  I think it's irresponsible of us
>> to present unmaintained code on an equal basis with filesystems under
>> active maintenance like ext2.
>>
>> I therefore propose we move the following filesystems which are explicitly
>> listed as Orphaned to staging:
>>
>> affs - Amiga filesystem.
>> efs - old SGI filesystem predating XFS, used on CDs for a while.
>> hfs - Mac filesystem.
>> hfsplus - Mac filesystem.
>>
>> I further propose we move the following filesystems which have no entry
>> in MAINTAINERS to staging:
>>
>> adfs - Acorn filesystem from the 1990s.
>> minix
>> qnx6
> 
> I had similar toughts some time ago while browsing the fs/ directory.
> Access to the filesystem images can be reimplemented in FUSE, but other
> than that, I don't think the in-kernel code would be missed.
> 
> It's hard to know how many users are there. I was curious eg. about bfs,
> befs, coda or feevxfs, looked at the last commits and searched around
> web if there are any mentions or user community. But as long as there's
> somebody listed in MAINTAINERS, the above are not candidates for moving
> to staging or deletion.
> 

I think the presence of maintainers entry is necessary but insufficient.
What if the maintainer has long lost interest but just didn't bother
updating the file. In the very least maintainers should be pinged and
asked if they are still maintaining the respective piece of code.

Re: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated

[Janpieter Sollie]

lspci -vv loaded in bugzilla.
I referred to a pci port nr as the nr in an expansion slot

On 25-04-18 19:05, Bjorn Helgaas wrote:

[Please retain the mailing list cc when replying]

On Wed, Apr 25, 2018 at 3:28 AM Janpieter Sollie

wrote:


Hi Bjorn,
I'm at work now, but I saw your mail contained much more info than only

the remark "does it work at 4.17?", so I'll try to answer all your
questions:

1. as stated, it only assigns the address space of the second and 3rd

device when the PCI device is hotplugged and then the pc is restarted on a
port before the first device.  In this case:

   - The Ellesmere 01.0-[4f] device is connected to port 3 (0-7) and

is always reported.  For other devices, this is not the case.

   - The other devices are at port 1 and 2.  When adding them on a

higher port, the workaround does not work.

   - The devices 05.0-[4c] and 07.0-[4b] are ALSO NOT VISIBLE in the

BIOS IRQ listing, it just talks about an endpoint.  Not even with the
workaround.  So a trick to discard bios info and let the PCIe switch report
its devices would be nice.

BIOS info is not used when we enumerate devices, so I don't think there's
really anything to discard.


2. I am always building my kernel from the kernel.org sources, not from

Gentoo sources, so it's not a distro problem.

3. The workaround only works with kernel 4.17
4. You are probably right about the Broadcom driver, as it only picks up

the endpoint at 42.00.1 when loaded.  I have no idea wat it does either,
besides taining the kernel.

Let's simplify the situation by focusing only on v4.17.  We can
also ignore the Broadcom driver, since it's not involved in enumeration.


So, to summarize:
- Why are ports 4-7 not working when a device is plugged in at port 3?

I don't know what "port 3" and "ports 4-7" refer to.  Are these labels on
slots in an expansion chassis?  Something from lspci, e.g., the port number
from Link Capabilites, or the slot number from Slot Capabilities?


- Why do I need a hotplug event to push the device name into the kernel

after a cold start?  This is complete madness, isn't it?

I don't know why the hotplug would make a difference.  It does sound like
complete madness.


- Why are resources allocated while the PCI slot is empty?

I don't know exactly what resources you're referring to (bus numbers, MMIO
space, I/O port space).  In general we try to allocate some space for all
of those even if the slot is currently empty, because that makes it
possible to hot-add devices in the slot later.

In this case, the bus number space is quite constrained because the host
bridge leading to the PEX switch only supports [bus 40-4f].  But I think
that should be enough for this case, since the only switch in this tree is
the PEX, and your Bonaire/Tobago/Ellesmere devices are all endpoints that
only require one bus number each.

If you run "lspci -vv" as root, it'll decode more details.


-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: dinsdag 24 april 2018 21:31
To: janpieter.sol...@dommel.be
Cc: linux-...@vger.kernel.org; Linux Kernel Mailing List
Subject: Fwd: [Bug 199473] New: pcieport does not scan devices behind PEX

switch, while resources are allocated


Thanks for the report!
I don't understand exactly what the issue is yet.  You attached lspci
output from v4.14.27 and v4.17-rc1.  The v4.17-rc1 output shows several
devices (4b:00, 4c:00, 4f:00) below the PEX switch, while the v4.14.27
output shows only the 4f:00 devices.
Is the problem that v4.14.27 doesn't find the 4b:00 and 4c:00 devices?
Does v4.17-rc1 work correctly?
If v4.17-rc1 works but v4.14.27 does not, it's probably a question of
working with your distro to see if they can (1) identify some change that
fixed things, and (2) backport that change to the distro kernel.
The Broadcom driver you attached at comment #4 shouldn't be related to

this

problem.  Device enumeration is performed by the PCI core and doesn't
require any additional drivers.  I didn't look at the Broadcom driver, so

I

don't know what it does.  The PEX switch does include an endpoint
(42:00.1); it's possible the driver is for some functionality provided by
that endpoint.
-- Forwarded message -
From: 
Date: Mon, Apr 23, 2018 at 12:20 AM
Subject: [Bug 199473] New: pcieport does not scan devices behind PEX
switch, while resources are allocated
To: 



https://bugzilla.kernel.org/show_bug.cgi?id=199473
Bug ID: 199473
   Summary: pcieport does not scan devices behind PEX switch,
while resources are allocated
   Product: Drivers
   Version: 2.5
Kernel Version: 4.17-rc1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1

Re: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated

[Janpieter Sollie]

lspci -vv loaded in bugzilla.
I referred to a pci port nr as the nr in an expansion slot

On 25-04-18 19:05, Bjorn Helgaas wrote:

[Please retain the mailing list cc when replying]

On Wed, Apr 25, 2018 at 3:28 AM Janpieter Sollie

wrote:


Hi Bjorn,
I'm at work now, but I saw your mail contained much more info than only

the remark "does it work at 4.17?", so I'll try to answer all your
questions:

1. as stated, it only assigns the address space of the second and 3rd

device when the PCI device is hotplugged and then the pc is restarted on a
port before the first device.  In this case:

   - The Ellesmere 01.0-[4f] device is connected to port 3 (0-7) and

is always reported.  For other devices, this is not the case.

   - The other devices are at port 1 and 2.  When adding them on a

higher port, the workaround does not work.

   - The devices 05.0-[4c] and 07.0-[4b] are ALSO NOT VISIBLE in the

BIOS IRQ listing, it just talks about an endpoint.  Not even with the
workaround.  So a trick to discard bios info and let the PCIe switch report
its devices would be nice.

BIOS info is not used when we enumerate devices, so I don't think there's
really anything to discard.


2. I am always building my kernel from the kernel.org sources, not from

Gentoo sources, so it's not a distro problem.

3. The workaround only works with kernel 4.17
4. You are probably right about the Broadcom driver, as it only picks up

the endpoint at 42.00.1 when loaded.  I have no idea wat it does either,
besides taining the kernel.

Let's simplify the situation by focusing only on v4.17.  We can
also ignore the Broadcom driver, since it's not involved in enumeration.


So, to summarize:
- Why are ports 4-7 not working when a device is plugged in at port 3?

I don't know what "port 3" and "ports 4-7" refer to.  Are these labels on
slots in an expansion chassis?  Something from lspci, e.g., the port number
from Link Capabilites, or the slot number from Slot Capabilities?


- Why do I need a hotplug event to push the device name into the kernel

after a cold start?  This is complete madness, isn't it?

I don't know why the hotplug would make a difference.  It does sound like
complete madness.


- Why are resources allocated while the PCI slot is empty?

I don't know exactly what resources you're referring to (bus numbers, MMIO
space, I/O port space).  In general we try to allocate some space for all
of those even if the slot is currently empty, because that makes it
possible to hot-add devices in the slot later.

In this case, the bus number space is quite constrained because the host
bridge leading to the PEX switch only supports [bus 40-4f].  But I think
that should be enough for this case, since the only switch in this tree is
the PEX, and your Bonaire/Tobago/Ellesmere devices are all endpoints that
only require one bus number each.

If you run "lspci -vv" as root, it'll decode more details.


-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: dinsdag 24 april 2018 21:31
To: janpieter.sol...@dommel.be
Cc: linux-...@vger.kernel.org; Linux Kernel Mailing List
Subject: Fwd: [Bug 199473] New: pcieport does not scan devices behind PEX

switch, while resources are allocated


Thanks for the report!
I don't understand exactly what the issue is yet.  You attached lspci
output from v4.14.27 and v4.17-rc1.  The v4.17-rc1 output shows several
devices (4b:00, 4c:00, 4f:00) below the PEX switch, while the v4.14.27
output shows only the 4f:00 devices.
Is the problem that v4.14.27 doesn't find the 4b:00 and 4c:00 devices?
Does v4.17-rc1 work correctly?
If v4.17-rc1 works but v4.14.27 does not, it's probably a question of
working with your distro to see if they can (1) identify some change that
fixed things, and (2) backport that change to the distro kernel.
The Broadcom driver you attached at comment #4 shouldn't be related to

this

problem.  Device enumeration is performed by the PCI core and doesn't
require any additional drivers.  I didn't look at the Broadcom driver, so

I

don't know what it does.  The PEX switch does include an endpoint
(42:00.1); it's possible the driver is for some functionality provided by
that endpoint.
-- Forwarded message -
From: 
Date: Mon, Apr 23, 2018 at 12:20 AM
Subject: [Bug 199473] New: pcieport does not scan devices behind PEX
switch, while resources are allocated
To: 



https://bugzilla.kernel.org/show_bug.cgi?id=199473
Bug ID: 199473
   Summary: pcieport does not scan devices behind PEX switch,
while resources are allocated
   Product: Drivers
   Version: 2.5
Kernel Version: 4.17-rc1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PCI
  Assignee: drivers_...@kernel-bugs.osdl.org
 

Re: linux-next: build failure after merge of the qcom tree

[Stephen Rothwell]

Hi Evan,

On Thu, 26 Apr 2018 03:39:25 + Evan Green  wrote:
>
> Guenter and I had a fix for compile test here, which had failures that
> looked similar:
> 
> https://lkml.org/lkml/2018/4/18/752

That looks like it could very well be the problem/solution.

> I was hoping to verify myself whether or not this fixed allmodconfig, but
> my machine at home is not so fast, and I must be missing something, either
> in the configuration or the tree. Which tree exactly are you building?

I was attempting to compile my partial linux-next for today after
merging the qcom tree.  So once I release linux-next, it will be commit
a72d0aa48d2e ("Merge remote-tracking branch 'omap/for-next'") plus a
merge of the qcom tree
(git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git#for-next
- which today meant commit c78d6951a806 ("Merge branch 'soc-for-4.18'
into all-for-4.18")).

I suspect that just Linus' tree merged with the qcom tree would have
been enough to cause the failure.

-- 
Cheers,
Stephen Rothwell


pgpUQiTKssTZ_.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the qcom tree

[Stephen Rothwell]

Hi Evan,

On Thu, 26 Apr 2018 03:39:25 + Evan Green  wrote:
>
> Guenter and I had a fix for compile test here, which had failures that
> looked similar:
> 
> https://lkml.org/lkml/2018/4/18/752

That looks like it could very well be the problem/solution.

> I was hoping to verify myself whether or not this fixed allmodconfig, but
> my machine at home is not so fast, and I must be missing something, either
> in the configuration or the tree. Which tree exactly are you building?

I was attempting to compile my partial linux-next for today after
merging the qcom tree.  So once I release linux-next, it will be commit
a72d0aa48d2e ("Merge remote-tracking branch 'omap/for-next'") plus a
merge of the qcom tree
(git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git#for-next
- which today meant commit c78d6951a806 ("Merge branch 'soc-for-4.18'
into all-for-4.18")).

I suspect that just Linus' tree merged with the qcom tree would have
been enough to cause the failure.

-- 
Cheers,
Stephen Rothwell


pgpUQiTKssTZ_.pgp
Description: OpenPGP digital signature

Unable to handle kernel paging request in snd_seq_oss_readq_puts

[DaeRyong Jeong]

We report the crash:
unable to handle kernel paging request in snd_seq_oss_readq_puts

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

Analysis:
We think the concurrent execution of snd_virmidi_output_trigger() and
snd_midi_event_encode_byte() causes the crash. Since the first call site
of snd_seq_kernel_client_dispatch() in snd_virmidi_output_trigger() is not
protected by substream->runtime->lock, it is possible that
snd_seq_oss_readq_puts() and snd_midi_event_encode_byte() are executed
concurrently in the call sequences as below, and snd_seq_oss_readq_puts()
accesses ev->data.ex.ptr before it is initialized.

Thread Interleaving:
CPU1 (snd_virmidi_output_trigger)   
CPU2(snd_midi_event_encode_byte)

ev->type = 
SNDRV_SEQ_EVENT_SYSEX;
if (vmidi->event.type != SNDRV_SEQ_EVENT_NONE) {
if (snd_seq_kernel_client_dispatch(vmidi->client, >event, 
in_atomic(), 0) < 0)
...
/* In snd_seq_oss_readq_puts(),
 * data has the same value with ev->data.ext.ptr
 * which is not initialized yet
 */
rec.c[1] = *data++;
ev->data.ext.len = 
dev->read;
ev->data.ext.ptr = dev->buf;

Call sequence:
CPU1
snd_rawmidi_write
  snd_rawmidi_kernel_write1
snd_rawmidi_output_trigger
  snd_virmidi_output_trigger
snd_seq_kernel_client_dispatch (line #178 in v4.16)
  snd_seq_deliver_event
deliver_to_subscribers
  snd_seq_deliver_single_event.constprop.14
snd_seq_oss_event_input
  snd_seq_oss_midi_input
send_midi_event
  snd_seq_oss_readq_sysex
snd_seq_dump_var_event
  readq_dump_sysex
snd_seq_oss_readq_puts

CPU2
snd_rawmidi_write
  snd_rawmidi_kernel_write1
snd_rawmidi_output_trigger
  snd_virmidi_output_trigger
snd_midi_event_encode
snd_midi_event_encode_byte


Crash log:
==
BUG: KASAN: null-ptr-deref in snd_seq_oss_readq_puts+0xc5/0x160 
sound/core/seq/oss/seq_oss_readq.c:112
Read of size 1 at addr 0049 by task syz-executor0/12892

CPU: 1 PID: 12892 Comm: syz-executor0 Not tainted 4.16.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x171/0x227 lib/dump_stack.c:53
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report.cold.7+0x13b/0x2f5 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 __asan_load1+0x47/0x50 mm/kasan/kasan.c:695
 snd_seq_oss_readq_puts+0xc5/0x160 sound/core/seq/oss/seq_oss_readq.c:112
 readq_dump_sysex+0x3f/0x50 sound/core/seq/oss/seq_oss_readq.c:133
 snd_seq_dump_var_event+0x375/0x3a0 sound/core/seq/seq_memory.c:107
 snd_seq_oss_readq_sysex+0xec/0x100 sound/core/seq/oss/seq_oss_readq.c:146
 send_midi_event sound/core/seq/oss/seq_oss_midi.c:615 [inline]
 snd_seq_oss_midi_input+0x332/0x710 sound/core/seq/oss/seq_oss_midi.c:535
 snd_seq_oss_event_input+0xe9/0x130 sound/core/seq/oss/seq_oss_event.c:439
 snd_seq_deliver_single_event.constprop.14+0x4bd/0x5a0 
sound/core/seq/seq_clientmgr.c:622
 deliver_to_subscribers sound/core/seq/seq_clientmgr.c:677 [inline]
 snd_seq_deliver_event+0x274/0x5d0 sound/core/seq/seq_clientmgr.c:812
 snd_seq_kernel_client_dispatch+0xe2/0x100 sound/core/seq/seq_clientmgr.c:2330
 snd_virmidi_output_trigger+0x156/0x420 sound/core/seq/seq_virmidi.c:178
 snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [inline]
 snd_rawmidi_kernel_write1+0x383/0x410 sound/core/rawmidi.c:1288
 snd_rawmidi_write+0x241/0xa30 sound/core/rawmidi.c:1338
 __vfs_write+0xed/0x510 fs/read_write.c:480
 vfs_write+0x195/0x380 fs/read_write.c:544
 SYSC_write fs/read_write.c:589 [inline]
 SyS_write+0xd7/0x1c0 fs/read_write.c:581
 do_syscall_64+0x209/0x5d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x453bb9
RSP: 002b:7f46902c2af8 EFLAGS: 0212 ORIG_RAX: 0001
RAX: ffda RBX: 007080d8 RCX: 00453bb9
RDX: 00f3 RSI: 20004f0d RDI: 0006
RBP: 5ed0 R08:  R09: 
R10:  R11: 0212 R12: 004ab432
R13:  R14: 0006 R15: 20004f0d
==
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 12892 Comm: syz-executor0 Tainted: GB4.16.0 #1
Hardware name: 

Unable to handle kernel paging request in snd_seq_oss_readq_puts

[DaeRyong Jeong]

We report the crash:
unable to handle kernel paging request in snd_seq_oss_readq_puts

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

Analysis:
We think the concurrent execution of snd_virmidi_output_trigger() and
snd_midi_event_encode_byte() causes the crash. Since the first call site
of snd_seq_kernel_client_dispatch() in snd_virmidi_output_trigger() is not
protected by substream->runtime->lock, it is possible that
snd_seq_oss_readq_puts() and snd_midi_event_encode_byte() are executed
concurrently in the call sequences as below, and snd_seq_oss_readq_puts()
accesses ev->data.ex.ptr before it is initialized.

Thread Interleaving:
CPU1 (snd_virmidi_output_trigger)   
CPU2(snd_midi_event_encode_byte)

ev->type = 
SNDRV_SEQ_EVENT_SYSEX;
if (vmidi->event.type != SNDRV_SEQ_EVENT_NONE) {
if (snd_seq_kernel_client_dispatch(vmidi->client, >event, 
in_atomic(), 0) < 0)
...
/* In snd_seq_oss_readq_puts(),
 * data has the same value with ev->data.ext.ptr
 * which is not initialized yet
 */
rec.c[1] = *data++;
ev->data.ext.len = 
dev->read;
ev->data.ext.ptr = dev->buf;

Call sequence:
CPU1
snd_rawmidi_write
  snd_rawmidi_kernel_write1
snd_rawmidi_output_trigger
  snd_virmidi_output_trigger
snd_seq_kernel_client_dispatch (line #178 in v4.16)
  snd_seq_deliver_event
deliver_to_subscribers
  snd_seq_deliver_single_event.constprop.14
snd_seq_oss_event_input
  snd_seq_oss_midi_input
send_midi_event
  snd_seq_oss_readq_sysex
snd_seq_dump_var_event
  readq_dump_sysex
snd_seq_oss_readq_puts

CPU2
snd_rawmidi_write
  snd_rawmidi_kernel_write1
snd_rawmidi_output_trigger
  snd_virmidi_output_trigger
snd_midi_event_encode
snd_midi_event_encode_byte


Crash log:
==
BUG: KASAN: null-ptr-deref in snd_seq_oss_readq_puts+0xc5/0x160 
sound/core/seq/oss/seq_oss_readq.c:112
Read of size 1 at addr 0049 by task syz-executor0/12892

CPU: 1 PID: 12892 Comm: syz-executor0 Not tainted 4.16.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x171/0x227 lib/dump_stack.c:53
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report.cold.7+0x13b/0x2f5 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 __asan_load1+0x47/0x50 mm/kasan/kasan.c:695
 snd_seq_oss_readq_puts+0xc5/0x160 sound/core/seq/oss/seq_oss_readq.c:112
 readq_dump_sysex+0x3f/0x50 sound/core/seq/oss/seq_oss_readq.c:133
 snd_seq_dump_var_event+0x375/0x3a0 sound/core/seq/seq_memory.c:107
 snd_seq_oss_readq_sysex+0xec/0x100 sound/core/seq/oss/seq_oss_readq.c:146
 send_midi_event sound/core/seq/oss/seq_oss_midi.c:615 [inline]
 snd_seq_oss_midi_input+0x332/0x710 sound/core/seq/oss/seq_oss_midi.c:535
 snd_seq_oss_event_input+0xe9/0x130 sound/core/seq/oss/seq_oss_event.c:439
 snd_seq_deliver_single_event.constprop.14+0x4bd/0x5a0 
sound/core/seq/seq_clientmgr.c:622
 deliver_to_subscribers sound/core/seq/seq_clientmgr.c:677 [inline]
 snd_seq_deliver_event+0x274/0x5d0 sound/core/seq/seq_clientmgr.c:812
 snd_seq_kernel_client_dispatch+0xe2/0x100 sound/core/seq/seq_clientmgr.c:2330
 snd_virmidi_output_trigger+0x156/0x420 sound/core/seq/seq_virmidi.c:178
 snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [inline]
 snd_rawmidi_kernel_write1+0x383/0x410 sound/core/rawmidi.c:1288
 snd_rawmidi_write+0x241/0xa30 sound/core/rawmidi.c:1338
 __vfs_write+0xed/0x510 fs/read_write.c:480
 vfs_write+0x195/0x380 fs/read_write.c:544
 SYSC_write fs/read_write.c:589 [inline]
 SyS_write+0xd7/0x1c0 fs/read_write.c:581
 do_syscall_64+0x209/0x5d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x453bb9
RSP: 002b:7f46902c2af8 EFLAGS: 0212 ORIG_RAX: 0001
RAX: ffda RBX: 007080d8 RCX: 00453bb9
RDX: 00f3 RSI: 20004f0d RDI: 0006
RBP: 5ed0 R08:  R09: 
R10:  R11: 0212 R12: 004ab432
R13:  R14: 0006 R15: 20004f0d
==
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 12892 Comm: syz-executor0 Tainted: GB4.16.0 #1
Hardware name: 

[PATCH] iommu/io-pgtable-arm: Use for_each_set_bit to simplify code

[YueHaibing]

We can use for_each_set_bit() to simplify code slightly in the
ARM io-pgtable self tests while unmapping.

Signed-off-by: YueHaibing 
---
 drivers/iommu/io-pgtable-arm-v7s.c | 5 +
 drivers/iommu/io-pgtable-arm.c | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index 10e4a3d..50e3a9f 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -898,8 +898,7 @@ static int __init arm_v7s_do_selftests(void)
 
/* Full unmap */
iova = 0;
-   i = find_first_bit(_bitmap, BITS_PER_LONG);
-   while (i != BITS_PER_LONG) {
+   for_each_set_bit(i, _bitmap, BITS_PER_LONG) {
size = 1UL << i;
 
if (ops->unmap(ops, iova, size) != size)
@@ -916,8 +915,6 @@ static int __init arm_v7s_do_selftests(void)
return __FAIL(ops);
 
iova += SZ_16M;
-   i++;
-   i = find_next_bit(_bitmap, BITS_PER_LONG, i);
}
 
free_io_pgtable_ops(ops);
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 39c2a05..4ffdd88 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1120,8 +1120,7 @@ static int __init arm_lpae_run_tests(struct 
io_pgtable_cfg *cfg)
 
/* Full unmap */
iova = 0;
-   j = find_first_bit(>pgsize_bitmap, BITS_PER_LONG);
-   while (j != BITS_PER_LONG) {
+   for_each_set_bit(j, >pgsize_bitmap, BITS_PER_LONG) {
size = 1UL << j;
 
if (ops->unmap(ops, iova, size) != size)
@@ -1138,8 +1137,6 @@ static int __init arm_lpae_run_tests(struct 
io_pgtable_cfg *cfg)
return __FAIL(ops, i);
 
iova += SZ_1G;
-   j++;
-   j = find_next_bit(>pgsize_bitmap, BITS_PER_LONG, 
j);
}
 
free_io_pgtable_ops(ops);
-- 
2.7.0

Re: [RFC 01/10] ARM: dts: exynos: Remove Exynos5440

[andi]

Hi Krzysztof,

On 25.04.2018 05:32, Krzysztof Kozlowski wrote:

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
server platforms but it did not make it to the market really.  There 
are

no development boards with it and probably there are no real products
neither.  The development for Exynos5440 ended in 2013 and since then
the platform is in maintenance mode.

Remove all Device Tree sources for Exynos5440, as first step of removal
of the platform to simplify the code and drivers.

Signed-off-by: Krzysztof Kozlowski 


makes sense, please feel free to add:

Reviewed-by: Andi Shyti 

Thanks,
Andi

[PATCH] iommu/io-pgtable-arm: Use for_each_set_bit to simplify code

[YueHaibing]

We can use for_each_set_bit() to simplify code slightly in the
ARM io-pgtable self tests while unmapping.

Signed-off-by: YueHaibing 
---
 drivers/iommu/io-pgtable-arm-v7s.c | 5 +
 drivers/iommu/io-pgtable-arm.c | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index 10e4a3d..50e3a9f 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -898,8 +898,7 @@ static int __init arm_v7s_do_selftests(void)
 
/* Full unmap */
iova = 0;
-   i = find_first_bit(_bitmap, BITS_PER_LONG);
-   while (i != BITS_PER_LONG) {
+   for_each_set_bit(i, _bitmap, BITS_PER_LONG) {
size = 1UL << i;
 
if (ops->unmap(ops, iova, size) != size)
@@ -916,8 +915,6 @@ static int __init arm_v7s_do_selftests(void)
return __FAIL(ops);
 
iova += SZ_16M;
-   i++;
-   i = find_next_bit(_bitmap, BITS_PER_LONG, i);
}
 
free_io_pgtable_ops(ops);
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 39c2a05..4ffdd88 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1120,8 +1120,7 @@ static int __init arm_lpae_run_tests(struct 
io_pgtable_cfg *cfg)
 
/* Full unmap */
iova = 0;
-   j = find_first_bit(>pgsize_bitmap, BITS_PER_LONG);
-   while (j != BITS_PER_LONG) {
+   for_each_set_bit(j, >pgsize_bitmap, BITS_PER_LONG) {
size = 1UL << j;
 
if (ops->unmap(ops, iova, size) != size)
@@ -1138,8 +1137,6 @@ static int __init arm_lpae_run_tests(struct 
io_pgtable_cfg *cfg)
return __FAIL(ops, i);
 
iova += SZ_1G;
-   j++;
-   j = find_next_bit(>pgsize_bitmap, BITS_PER_LONG, 
j);
}
 
free_io_pgtable_ops(ops);
-- 
2.7.0

Re: [RFC 01/10] ARM: dts: exynos: Remove Exynos5440

[andi]

Hi Krzysztof,

On 25.04.2018 05:32, Krzysztof Kozlowski wrote:

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
server platforms but it did not make it to the market really.  There 
are

no development boards with it and probably there are no real products
neither.  The development for Exynos5440 ended in 2013 and since then
the platform is in maintenance mode.

Remove all Device Tree sources for Exynos5440, as first step of removal
of the platform to simplify the code and drivers.

Signed-off-by: Krzysztof Kozlowski 


makes sense, please feel free to add:

Reviewed-by: Andi Shyti 

Thanks,
Andi

[PATCH] md: fix two problems with setting the "re-add" device state.

[NeilBrown]

If "re-add" is written to the "state" file for a device
which is faulty, this has an effect similar to removing
and re-adding the device.  It should take up the
same slot in the array that it previously had, and
an accelerated (e.g. bitmap-based) rebuild should happen.

The slot that "it previously had" is determined by
rdev->saved_raid_disk.
However this is not set when a device fails (only when a device
is added), and it is cleared when resync completes.
This means that "re-add" will normally work once, but may not work a
second time.

This patch includes two fixes.
1/ when a device fails, record the ->raid_disk value in
->saved_raid_disk before clearing ->raid_disk
2/ when "re-add" is written to a device for which
->saved_raid_disk is not set, fail.

I think this is suitable for stable as it can
cause re-adding a device to be forced to do a full
resync which takes a lot longer and so puts data at
more risk.

Cc:  (v4.1)
Fixes: 97f6cd39da22 ("md-cluster: re-add capabilities")
Signed-off-by: NeilBrown 
---
 drivers/md/md.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3bea45e8ccff..ecd4235c6e30 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2853,7 +2853,8 @@ state_store(struct md_rdev *rdev, const char *buf, size_t 
len)
err = 0;
}
} else if (cmd_match(buf, "re-add")) {
-   if (test_bit(Faulty, >flags) && (rdev->raid_disk == -1)) {
+   if (test_bit(Faulty, >flags) && (rdev->raid_disk == -1) &&
+   rdev->saved_raid_disk >= 0) {
/* clear_bit is performed _after_ all the devices
 * have their local Faulty bit cleared. If any writes
 * happen in the meantime in the local node, they
@@ -8641,6 +8642,7 @@ static int remove_and_add_spares(struct mddev *mddev,
if (mddev->pers->hot_remove_disk(
mddev, rdev) == 0) {
sysfs_unlink_rdev(mddev, rdev);
+   rdev->saved_raid_disk = rdev->raid_disk;
rdev->raid_disk = -1;
removed++;
}
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

[PATCH] md: fix two problems with setting the "re-add" device state.

[NeilBrown]

If "re-add" is written to the "state" file for a device
which is faulty, this has an effect similar to removing
and re-adding the device.  It should take up the
same slot in the array that it previously had, and
an accelerated (e.g. bitmap-based) rebuild should happen.

The slot that "it previously had" is determined by
rdev->saved_raid_disk.
However this is not set when a device fails (only when a device
is added), and it is cleared when resync completes.
This means that "re-add" will normally work once, but may not work a
second time.

This patch includes two fixes.
1/ when a device fails, record the ->raid_disk value in
->saved_raid_disk before clearing ->raid_disk
2/ when "re-add" is written to a device for which
->saved_raid_disk is not set, fail.

I think this is suitable for stable as it can
cause re-adding a device to be forced to do a full
resync which takes a lot longer and so puts data at
more risk.

Cc:  (v4.1)
Fixes: 97f6cd39da22 ("md-cluster: re-add capabilities")
Signed-off-by: NeilBrown 
---
 drivers/md/md.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3bea45e8ccff..ecd4235c6e30 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2853,7 +2853,8 @@ state_store(struct md_rdev *rdev, const char *buf, size_t 
len)
err = 0;
}
} else if (cmd_match(buf, "re-add")) {
-   if (test_bit(Faulty, >flags) && (rdev->raid_disk == -1)) {
+   if (test_bit(Faulty, >flags) && (rdev->raid_disk == -1) &&
+   rdev->saved_raid_disk >= 0) {
/* clear_bit is performed _after_ all the devices
 * have their local Faulty bit cleared. If any writes
 * happen in the meantime in the local node, they
@@ -8641,6 +8642,7 @@ static int remove_and_add_spares(struct mddev *mddev,
if (mddev->pers->hot_remove_disk(
mddev, rdev) == 0) {
sysfs_unlink_rdev(mddev, rdev);
+   rdev->saved_raid_disk = rdev->raid_disk;
rdev->raid_disk = -1;
removed++;
}
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: [RFC 08/10] spi: s3c64xx: samsung: Remove support for Exynos5440

[andi]

Hi Krzysztof,

On 25.04.2018 05:32, Krzysztof Kozlowski wrote:

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 


Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: [RFC 08/10] spi: s3c64xx: samsung: Remove support for Exynos5440

[andi]

Hi Krzysztof,

On 25.04.2018 05:32, Krzysztof Kozlowski wrote:

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 


Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: [PATCH 05/11] platform: use a dedicated list_head for early devices

[kbuild test robot]

Hi Bartosz,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc2]
[cannot apply to next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/platform-device-tree-support-for-early-platform-drivers/20180426-003135
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg.signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg.chain_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.filtered' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.retry_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.retry_count' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.lost_packets' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_tdls_pkt_time' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.msdu_retries' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.msdu_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_ack' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_ack_signal' not described 

Re: [PATCH 05/11] platform: use a dedicated list_head for early devices

[kbuild test robot]

Hi Bartosz,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc2]
[cannot apply to next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/platform-device-tree-support-for-early-platform-drivers/20180426-003135
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg.signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'rx_stats_avg.chain_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.filtered' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.retry_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.retry_count' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.lost_packets' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_tdls_pkt_time' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.msdu_retries' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.msdu_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_ack' not described in 'sta_info'
   net/mac80211/sta_info.h:586: warning: Function parameter or member 
'status_stats.last_ack_signal' not described 

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

I noticed "systems without sufficient boot randomness" and would like to add to 
this.

With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec 
Chromebook does not reach
the login screen upon boot (it stays stuck on a black screen) until I provide a 
source of entropy to
the system via interrupts (e.g., holding down a key on the keyboard for 5 sec 
or moving my finger
across the touchpad a lot). After providing a source of entropy for long enough,
"random: crng init done" prints out in dmesg and the login screen finally pops 
up.

Detailed information on my system can be found on this bug report I recently 
worked on:
https://bugzilla.kernel.org/show_bug.cgi?id=199463

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

I noticed "systems without sufficient boot randomness" and would like to add to 
this.

With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec 
Chromebook does not reach
the login screen upon boot (it stays stuck on a black screen) until I provide a 
source of entropy to
the system via interrupts (e.g., holding down a key on the keyboard for 5 sec 
or moving my finger
across the touchpad a lot). After providing a source of entropy for long enough,
"random: crng init done" prints out in dmesg and the login screen finally pops 
up.

Detailed information on my system can be found on this bug report I recently 
worked on:
https://bugzilla.kernel.org/show_bug.cgi?id=199463

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

[Kohli, Gaurav]

On 4/26/2018 1:39 AM, Peter Zijlstra wrote:


On Wed, Apr 25, 2018 at 02:03:19PM +0530, Gaurav Kohli wrote:

diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5043e74..c5c5184 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -122,7 +122,45 @@ static int smpboot_thread_fn(void *data)
}
  
  		if (kthread_should_park()) {

+   /*
+* Serialize against wakeup.

 *
 * Prior wakeups must complete and later wakeups
 * will observe TASK_RUNNING.
 *
 * This avoids the case where the TASK_RUNNING
 * store from ttwu() competes with the
 * TASK_PARKED store from kthread_parkme().
 *
 * If the TASK_PARKED store looses that
 * competition, kthread_unpark() will go wobbly.

+*/
+   raw_spin_lock(>pi_lock);
__set_current_state(TASK_RUNNING);
+   raw_spin_unlock(>pi_lock);
preempt_enable();
if (ht->park && td->status == HP_THREAD_ACTIVE) {
BUG_ON(td->cpu != smp_processor_id());

Does that work for you?


We have given patch for testing, usually it takes around 2-3 days for 
reproduction(we will update for the same).



But looking at this a bit more; don't we have the exact same problem
with the TASK_RUNNING store in the !ht->thread_should_run() case?
Suppose a ttwu() happens concurrently there, it can end up competing
against the TASK_INTERRUPTIBLE store, no?

Of course, that race is not fatal, we'll just end up going around the
loop once again I suppose. Maybe a comment there too?

/*
 * A similar race is possible here, but loosing
 * the TASK_INTERRUPTIBLE store is harmless and
 * will make us go around the loop once more.
 */


Actually instead of race, i am seeing wakeup miss problem which is very rare, 
if we take case of hotplug thread

Controller   Hotplug

                                                         Loop start

                                                         
set_current_state(TASK_INTERRUPTIBLE);

 if 
(kthread_should_park()) { -> fails

Set Should_park

then wake_up

                                                            if 
(!ht->thread_should_run(td->cpu)) {

                                        
preempt_enable_no_resched();

                                        schedule(); Again 
went to schedule(which is very rare to occur,not sure whether it hits)

  



And of course, I suspect we actually want to use TASK_IDLE, smpboot
threads don't want signals do they? But that probably ought to be a
separate patch.


Yes I agree, we can control race from here as well,  Please suggest would below 
change be any help here:

 } else {

    __set_current_state(TASK_RUNNING);

    preempt_enable();

    ht->thread_fn(td->cpu);

                       + set_current_state(TASK_INTERRUPTIBLE);

                       + schedule();

    }




--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

[Kohli, Gaurav]

On 4/26/2018 1:39 AM, Peter Zijlstra wrote:


On Wed, Apr 25, 2018 at 02:03:19PM +0530, Gaurav Kohli wrote:

diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5043e74..c5c5184 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -122,7 +122,45 @@ static int smpboot_thread_fn(void *data)
}
  
  		if (kthread_should_park()) {

+   /*
+* Serialize against wakeup.

 *
 * Prior wakeups must complete and later wakeups
 * will observe TASK_RUNNING.
 *
 * This avoids the case where the TASK_RUNNING
 * store from ttwu() competes with the
 * TASK_PARKED store from kthread_parkme().
 *
 * If the TASK_PARKED store looses that
 * competition, kthread_unpark() will go wobbly.

+*/
+   raw_spin_lock(>pi_lock);
__set_current_state(TASK_RUNNING);
+   raw_spin_unlock(>pi_lock);
preempt_enable();
if (ht->park && td->status == HP_THREAD_ACTIVE) {
BUG_ON(td->cpu != smp_processor_id());

Does that work for you?


We have given patch for testing, usually it takes around 2-3 days for 
reproduction(we will update for the same).



But looking at this a bit more; don't we have the exact same problem
with the TASK_RUNNING store in the !ht->thread_should_run() case?
Suppose a ttwu() happens concurrently there, it can end up competing
against the TASK_INTERRUPTIBLE store, no?

Of course, that race is not fatal, we'll just end up going around the
loop once again I suppose. Maybe a comment there too?

/*
 * A similar race is possible here, but loosing
 * the TASK_INTERRUPTIBLE store is harmless and
 * will make us go around the loop once more.
 */


Actually instead of race, i am seeing wakeup miss problem which is very rare, 
if we take case of hotplug thread

Controller   Hotplug

                                                         Loop start

                                                         
set_current_state(TASK_INTERRUPTIBLE);

 if 
(kthread_should_park()) { -> fails

Set Should_park

then wake_up

                                                            if 
(!ht->thread_should_run(td->cpu)) {

                                        
preempt_enable_no_resched();

                                        schedule(); Again 
went to schedule(which is very rare to occur,not sure whether it hits)

  



And of course, I suspect we actually want to use TASK_IDLE, smpboot
threads don't want signals do they? But that probably ought to be a
separate patch.


Yes I agree, we can control race from here as well,  Please suggest would below 
change be any help here:

 } else {

    __set_current_state(TASK_RUNNING);

    preempt_enable();

    ht->thread_fn(td->cpu);

                       + set_current_state(TASK_INTERRUPTIBLE);

                       + schedule();

    }




--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.