[PATCH] regulator: s2mps11: Fix the voltage linear range for s2mps15

[Alim Akhtar]

This patch fixes some of the LDOs and BUCKs voltage range as per
user manual of s2mps15 (REV0.4).

Fixes: 51af20675800 ("regulator: s2mps11: Add support for S2MPS15 regulators")

Cc: 
Signed-off-by: Alim Akhtar 
---
 drivers/regulator/s2mps11.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 02fb6b4..d838e77 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -750,7 +750,7 @@ static const struct regulator_linear_range 
s2mps15_ldo_voltage_ranges3[] = {
 
 /* voltage range for s2mps15 LDO 7, 8, 9 and 10 */
 static const struct regulator_linear_range s2mps15_ldo_voltage_ranges4[] = {
-   REGULATOR_LINEAR_RANGE(70, 0xc, 0x18, 25000),
+   REGULATOR_LINEAR_RANGE(70, 0x10, 0x20, 25000),
 };
 
 /* voltage range for s2mps15 LDO 1 */
@@ -760,12 +760,12 @@ static const struct regulator_linear_range 
s2mps15_ldo_voltage_ranges5[] = {
 
 /* voltage range for s2mps15 BUCK 1, 2, 3, 4, 5, 6 and 7 */
 static const struct regulator_linear_range s2mps15_buck_voltage_ranges1[] = {
-   REGULATOR_LINEAR_RANGE(50, 0x20, 0xb0, 6250),
+   REGULATOR_LINEAR_RANGE(50, 0x20, 0xc0, 6250),
 };
 
 /* voltage range for s2mps15 BUCK 8, 9 and 10 */
 static const struct regulator_linear_range s2mps15_buck_voltage_ranges2[] = {
-   REGULATOR_LINEAR_RANGE(100, 0x20, 0xc0, 12500),
+   REGULATOR_LINEAR_RANGE(100, 0x20, 0x78, 12500),
 };
 
 static const struct regulator_desc s2mps15_regulators[] = {
-- 
1.7.10.4

[PATCH] regulator: s2mps11: Fix the voltage linear range for s2mps15

[Alim Akhtar]

This patch fixes some of the LDOs and BUCKs voltage range as per
user manual of s2mps15 (REV0.4).

Fixes: 51af20675800 ("regulator: s2mps11: Add support for S2MPS15 regulators")

Cc: 
Signed-off-by: Alim Akhtar 
---
 drivers/regulator/s2mps11.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 02fb6b4..d838e77 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -750,7 +750,7 @@ static const struct regulator_linear_range 
s2mps15_ldo_voltage_ranges3[] = {
 
 /* voltage range for s2mps15 LDO 7, 8, 9 and 10 */
 static const struct regulator_linear_range s2mps15_ldo_voltage_ranges4[] = {
-   REGULATOR_LINEAR_RANGE(70, 0xc, 0x18, 25000),
+   REGULATOR_LINEAR_RANGE(70, 0x10, 0x20, 25000),
 };
 
 /* voltage range for s2mps15 LDO 1 */
@@ -760,12 +760,12 @@ static const struct regulator_linear_range 
s2mps15_ldo_voltage_ranges5[] = {
 
 /* voltage range for s2mps15 BUCK 1, 2, 3, 4, 5, 6 and 7 */
 static const struct regulator_linear_range s2mps15_buck_voltage_ranges1[] = {
-   REGULATOR_LINEAR_RANGE(50, 0x20, 0xb0, 6250),
+   REGULATOR_LINEAR_RANGE(50, 0x20, 0xc0, 6250),
 };
 
 /* voltage range for s2mps15 BUCK 8, 9 and 10 */
 static const struct regulator_linear_range s2mps15_buck_voltage_ranges2[] = {
-   REGULATOR_LINEAR_RANGE(100, 0x20, 0xc0, 12500),
+   REGULATOR_LINEAR_RANGE(100, 0x20, 0x78, 12500),
 };
 
 static const struct regulator_desc s2mps15_regulators[] = {
-- 
1.7.10.4

[PATCH] include instead of

[mariakatosvich]

asm-generic headers are generic implementations for architecture specific
code and should not be included by common code.  Thus use the asm/ version
of sections.h to get at the linker sections.

Signed-off-by: mariakatosvich  lst.de>
---
 kernel/kprobes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index d10ab6b..d630954 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
 -49,7 +49,7 
 #include 
 #include 

-#include 
+#include 
 #include 
 #include 
 #include 
--
Thanks
mariakatosvich
http://www.fixithere.net/sky-contact-number/

[PATCH] include instead of

[mariakatosvich]

asm-generic headers are generic implementations for architecture specific
code and should not be included by common code.  Thus use the asm/ version
of sections.h to get at the linker sections.

Signed-off-by: mariakatosvich  lst.de>
---
 kernel/kprobes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index d10ab6b..d630954 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
 -49,7 +49,7 
 #include 
 #include 

-#include 
+#include 
 #include 
 #include 
 #include 
--
Thanks
mariakatosvich
http://www.fixithere.net/sky-contact-number/

Re: [PATCH v5 7/7] perf config: Initialize annotate_browser__opts with default config items

[Namhyung Kim]

On Wed, Jul 06, 2016 at 02:20:23PM +0900, Taeung Song wrote:
> Set default config values for 'annotate' section with 
> 'annotate_config_items[]'
> instead of actual bool type values.
> (e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value
> instead of 'true' bool type value for 'annotate.use_offset'.)
> 
> Cc: Namhyung Kim 
> Cc: Jiri Olsa 
> Cc: Masami Hiramatsu 
> Cc: Wang Nan 
> Cc: Alexander Shishkin 
> Signed-off-by: Taeung Song 
> ---
>  tools/perf/ui/browsers/annotate.c | 16 
>  tools/perf/util/config.h  |  6 ++
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/ui/browsers/annotate.c 
> b/tools/perf/ui/browsers/annotate.c
> index 29dc6d2..0fb78b5 100644
> --- a/tools/perf/ui/browsers/annotate.c
> +++ b/tools/perf/ui/browsers/annotate.c
> @@ -38,10 +38,7 @@ static struct annotate_browser_opt {
>show_linenr,
>show_nr_jumps,
>show_total_period;
> -} annotate_browser__opts = {
> - .use_offset = true,
> - .jump_arrows= true,
> -};
> +} annotate_browser__opts;
>  
>  struct annotate_browser {
>   struct ui_browser b;
> @@ -1157,7 +1154,18 @@ static int annotate__config(const char *var, const 
> char *value,
>   return 0;
>  }
>  
> +static void default_annotate_config_init(void)
> +{
> + annotate_browser__opts.hide_src_code = 
> CONF_ANNOTATE_DEFAULT_VAL(HIDE_SRC_CODE, b);
> + annotate_browser__opts.use_offset = 
> CONF_ANNOTATE_DEFAULT_VAL(USE_OFFSET, b);
> + annotate_browser__opts.jump_arrows = 
> CONF_ANNOTATE_DEFAULT_VAL(JUMP_ARROWS, b);
> + annotate_browser__opts.show_linenr = 
> CONF_ANNOTATE_DEFAULT_VAL(SHOW_LINENR, b);
> + annotate_browser__opts.show_nr_jumps = 
> CONF_ANNOTATE_DEFAULT_VAL(SHOW_NR_JUMPS, b);
> + annotate_browser__opts.show_total_period = 
> CONF_ANNOTATE_DEFAULT_VAL(SHOW_TOTAL_PERIOD, b);
> +}
> +
>  void annotate_browser__init(void)
>  {
> + default_annotate_config_init();
>   perf_config(annotate__config, NULL);
>  }
> diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
> index 470c93a..c30e6bb 100644
> --- a/tools/perf/util/config.h
> +++ b/tools/perf/util/config.h
> @@ -136,6 +136,12 @@ struct default_config_section {
>  #define CONF_END()   \
>   { .name = NULL }
>  
> +#define CONF_DEFAULT_VAL(section, name, field)   \
> + section##_config_items[CONFIG_##name].value.field
> +
> +#define CONF_ANNOTATE_DEFAULT_VAL(name, field)   \
> + CONF_DEFAULT_VAL(annotate, ANNOTATE_##name, field)
> +

Instead of making accessor macro for each config section, can we make
it more general like below?

  #define CONF_DEFAULT_BOOL(sec, name) \
default_sections[sec##_IDX].items[sec##_##name].b

  opts->hide_src_code = CONF_DEFAULT_BOOL(ANNOTATE, HIDE_SRC_CODE);


Thanks,
Namhyung


>  extern const struct default_config_item colors_config_items[];
>  extern const struct default_config_item annotate_config_items[];
>  
> -- 
> 2.5.0
> 

Re: [PATCH v5 7/7] perf config: Initialize annotate_browser__opts with default config items

[Namhyung Kim]

On Wed, Jul 06, 2016 at 02:20:23PM +0900, Taeung Song wrote:
> Set default config values for 'annotate' section with 
> 'annotate_config_items[]'
> instead of actual bool type values.
> (e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value
> instead of 'true' bool type value for 'annotate.use_offset'.)
> 
> Cc: Namhyung Kim 
> Cc: Jiri Olsa 
> Cc: Masami Hiramatsu 
> Cc: Wang Nan 
> Cc: Alexander Shishkin 
> Signed-off-by: Taeung Song 
> ---
>  tools/perf/ui/browsers/annotate.c | 16 
>  tools/perf/util/config.h  |  6 ++
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/ui/browsers/annotate.c 
> b/tools/perf/ui/browsers/annotate.c
> index 29dc6d2..0fb78b5 100644
> --- a/tools/perf/ui/browsers/annotate.c
> +++ b/tools/perf/ui/browsers/annotate.c
> @@ -38,10 +38,7 @@ static struct annotate_browser_opt {
>show_linenr,
>show_nr_jumps,
>show_total_period;
> -} annotate_browser__opts = {
> - .use_offset = true,
> - .jump_arrows= true,
> -};
> +} annotate_browser__opts;
>  
>  struct annotate_browser {
>   struct ui_browser b;
> @@ -1157,7 +1154,18 @@ static int annotate__config(const char *var, const 
> char *value,
>   return 0;
>  }
>  
> +static void default_annotate_config_init(void)
> +{
> + annotate_browser__opts.hide_src_code = 
> CONF_ANNOTATE_DEFAULT_VAL(HIDE_SRC_CODE, b);
> + annotate_browser__opts.use_offset = 
> CONF_ANNOTATE_DEFAULT_VAL(USE_OFFSET, b);
> + annotate_browser__opts.jump_arrows = 
> CONF_ANNOTATE_DEFAULT_VAL(JUMP_ARROWS, b);
> + annotate_browser__opts.show_linenr = 
> CONF_ANNOTATE_DEFAULT_VAL(SHOW_LINENR, b);
> + annotate_browser__opts.show_nr_jumps = 
> CONF_ANNOTATE_DEFAULT_VAL(SHOW_NR_JUMPS, b);
> + annotate_browser__opts.show_total_period = 
> CONF_ANNOTATE_DEFAULT_VAL(SHOW_TOTAL_PERIOD, b);
> +}
> +
>  void annotate_browser__init(void)
>  {
> + default_annotate_config_init();
>   perf_config(annotate__config, NULL);
>  }
> diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
> index 470c93a..c30e6bb 100644
> --- a/tools/perf/util/config.h
> +++ b/tools/perf/util/config.h
> @@ -136,6 +136,12 @@ struct default_config_section {
>  #define CONF_END()   \
>   { .name = NULL }
>  
> +#define CONF_DEFAULT_VAL(section, name, field)   \
> + section##_config_items[CONFIG_##name].value.field
> +
> +#define CONF_ANNOTATE_DEFAULT_VAL(name, field)   \
> + CONF_DEFAULT_VAL(annotate, ANNOTATE_##name, field)
> +

Instead of making accessor macro for each config section, can we make
it more general like below?

  #define CONF_DEFAULT_BOOL(sec, name) \
default_sections[sec##_IDX].items[sec##_##name].b

  opts->hide_src_code = CONF_DEFAULT_BOOL(ANNOTATE, HIDE_SRC_CODE);


Thanks,
Namhyung


>  extern const struct default_config_item colors_config_items[];
>  extern const struct default_config_item annotate_config_items[];
>  
> -- 
> 2.5.0
> 

Re: [PATCH v5 5/7] perf config: Initialize ui_browser__colorsets with default config items

[Namhyung Kim]

On Wed, Jul 06, 2016 at 02:20:21PM +0900, Taeung Song wrote:
> Set default config values for 'colors' section with 'colors_config_items[]'
> instead of actual const char * type values.
> (e.g. using colors_config_item[CONFIG_COLORS_TOP].value
> instead of "red, default" string value for 'colors.top')
> 
> Cc: Namhyung Kim 
> Cc: Jiri Olsa 
> Cc: Masami Hiramatsu 
> Cc: Wang Nan 
> Cc: Alexander Shishkin 
> Signed-off-by: Taeung Song 
> ---
>  tools/perf/ui/browser.c | 53 
> +
>  1 file changed, 32 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
> index b4e21d1..380abab 100644
> --- a/tools/perf/ui/browser.c
> +++ b/tools/perf/ui/browser.c
> @@ -507,39 +507,32 @@ static struct ui_browser_colorset {
>   int colorset;
>  } ui_browser__colorsets[] = {
>   {
> - .colorset  = HE_COLORSET_TOP,
> - .name  = "top",
> - .fore_back_colors = "red, default",
> + .colorset = HE_COLORSET_TOP,
> + .name = "top",

It seems like an unnecessary whitespace change, please fix the patch 4.

Thanks,
Namhyung


>   },
>   {
> - .colorset  = HE_COLORSET_MEDIUM,
> - .name  = "medium",
> - .fore_back_colors = "green, default",
> + .colorset = HE_COLORSET_MEDIUM,
> + .name = "medium",
>   },
>   {
> - .colorset  = HE_COLORSET_NORMAL,
> - .name  = "normal",
> - .fore_back_colors = "default, default",
> + .colorset = HE_COLORSET_NORMAL,
> + .name = "normal",
>   },
>   {
> - .colorset  = HE_COLORSET_SELECTED,
> - .name  = "selected",
> - .fore_back_colors = "black, yellow",
> + .colorset = HE_COLORSET_SELECTED,
> + .name = "selected",
>   },
>   {
> - .colorset  = HE_COLORSET_JUMP_ARROWS,
> - .name  = "jump_arrows",
> - .fore_back_colors = "blue, default",
> + .colorset = HE_COLORSET_JUMP_ARROWS,
> + .name = "jump_arrows",
>   },
>   {
> - .colorset  = HE_COLORSET_ADDR,
> - .name  = "addr",
> - .fore_back_colors = "magenta, default",
> + .colorset = HE_COLORSET_ADDR,
> + .name = "addr",
>   },
>   {
> - .colorset  = HE_COLORSET_ROOT,
> - .name  = "root",
> - .fore_back_colors = "white, blue",
> + .colorset = HE_COLORSET_ROOT,
> + .name = "root",
>   },
>   {
>   .name = NULL,
> @@ -724,10 +717,28 @@ void __ui_browser__line_arrow(struct ui_browser 
> *browser, unsigned int column,
>   __ui_browser__line_arrow_down(browser, column, start, end);
>  }
>  
> +static void default_colors_config_init(void)
> +{
> + int i, j;
> +
> + for (i = 0; ui_browser__colorsets[i].name != NULL; ++i) {
> + const char *name = ui_browser__colorsets[i].name;
> +
> + for (j = 0; colors_config_items[j].name != NULL; j++) {
> + if (!strcmp(name, colors_config_items[j].name)) {
> + ui_browser__colorsets[i].fore_back_colors =
> + colors_config_items[j].value.s;
> + break;
> + }
> + }
> + }
> +}
> +
>  void ui_browser__init(void)
>  {
>   int i = 0;
>  
> + default_colors_config_init();
>   perf_config(ui_browser__color_config, NULL);
>  
>   while (ui_browser__colorsets[i].name) {
> -- 
> 2.5.0
> 

Re: [PATCH v5 5/7] perf config: Initialize ui_browser__colorsets with default config items

[Namhyung Kim]

On Wed, Jul 06, 2016 at 02:20:21PM +0900, Taeung Song wrote:
> Set default config values for 'colors' section with 'colors_config_items[]'
> instead of actual const char * type values.
> (e.g. using colors_config_item[CONFIG_COLORS_TOP].value
> instead of "red, default" string value for 'colors.top')
> 
> Cc: Namhyung Kim 
> Cc: Jiri Olsa 
> Cc: Masami Hiramatsu 
> Cc: Wang Nan 
> Cc: Alexander Shishkin 
> Signed-off-by: Taeung Song 
> ---
>  tools/perf/ui/browser.c | 53 
> +
>  1 file changed, 32 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
> index b4e21d1..380abab 100644
> --- a/tools/perf/ui/browser.c
> +++ b/tools/perf/ui/browser.c
> @@ -507,39 +507,32 @@ static struct ui_browser_colorset {
>   int colorset;
>  } ui_browser__colorsets[] = {
>   {
> - .colorset  = HE_COLORSET_TOP,
> - .name  = "top",
> - .fore_back_colors = "red, default",
> + .colorset = HE_COLORSET_TOP,
> + .name = "top",

It seems like an unnecessary whitespace change, please fix the patch 4.

Thanks,
Namhyung


>   },
>   {
> - .colorset  = HE_COLORSET_MEDIUM,
> - .name  = "medium",
> - .fore_back_colors = "green, default",
> + .colorset = HE_COLORSET_MEDIUM,
> + .name = "medium",
>   },
>   {
> - .colorset  = HE_COLORSET_NORMAL,
> - .name  = "normal",
> - .fore_back_colors = "default, default",
> + .colorset = HE_COLORSET_NORMAL,
> + .name = "normal",
>   },
>   {
> - .colorset  = HE_COLORSET_SELECTED,
> - .name  = "selected",
> - .fore_back_colors = "black, yellow",
> + .colorset = HE_COLORSET_SELECTED,
> + .name = "selected",
>   },
>   {
> - .colorset  = HE_COLORSET_JUMP_ARROWS,
> - .name  = "jump_arrows",
> - .fore_back_colors = "blue, default",
> + .colorset = HE_COLORSET_JUMP_ARROWS,
> + .name = "jump_arrows",
>   },
>   {
> - .colorset  = HE_COLORSET_ADDR,
> - .name  = "addr",
> - .fore_back_colors = "magenta, default",
> + .colorset = HE_COLORSET_ADDR,
> + .name = "addr",
>   },
>   {
> - .colorset  = HE_COLORSET_ROOT,
> - .name  = "root",
> - .fore_back_colors = "white, blue",
> + .colorset = HE_COLORSET_ROOT,
> + .name = "root",
>   },
>   {
>   .name = NULL,
> @@ -724,10 +717,28 @@ void __ui_browser__line_arrow(struct ui_browser 
> *browser, unsigned int column,
>   __ui_browser__line_arrow_down(browser, column, start, end);
>  }
>  
> +static void default_colors_config_init(void)
> +{
> + int i, j;
> +
> + for (i = 0; ui_browser__colorsets[i].name != NULL; ++i) {
> + const char *name = ui_browser__colorsets[i].name;
> +
> + for (j = 0; colors_config_items[j].name != NULL; j++) {
> + if (!strcmp(name, colors_config_items[j].name)) {
> + ui_browser__colorsets[i].fore_back_colors =
> + colors_config_items[j].value.s;
> + break;
> + }
> + }
> + }
> +}
> +
>  void ui_browser__init(void)
>  {
>   int i = 0;
>  
> + default_colors_config_init();
>   perf_config(ui_browser__color_config, NULL);
>  
>   while (ui_browser__colorsets[i].name) {
> -- 
> 2.5.0
> 

RE: Regression in 4.7-rc7

[Zheng, Lv]

We will revert 3 commits to fix this issue.
And re-enable the reverted feature in the future when it is safe to re-enable 
it.
See this bug for reference:
https://bugzilla.kernel.org/show_bug.cgi?id=121701

Thanks and best regards
-Lv

> From: Jens Axboe [mailto:ax...@kernel.dk]
> Subject: Regression in 4.7-rc7
> 
> Hi,
> 
> Updated the laptop to -rc7 this morning, and it fails to boot. After
> bisecting it, this is the culprit:
> 
> commit 45209046c47b93fadf26dc59a9da724f387b9cf2
> Author: Lv Zheng 
> Date:   Tue Jul 5 13:53:12 2016 +0800
> 
>  ACPICA: Namespace: Fix namespace/interpreter lock ordering
> 
>  There is a lock order issue in acpi_load_tables(). The namespace lock
>  is held before holding the interpreter lock.
> 
> The last I see is grub loading initramfs, after that nothing. Very
> reproducible. Laptop is a Dell XPS 13.
> 
> --
> Jens Axboe

RE: Regression in 4.7-rc7

[Zheng, Lv]

We will revert 3 commits to fix this issue.
And re-enable the reverted feature in the future when it is safe to re-enable 
it.
See this bug for reference:
https://bugzilla.kernel.org/show_bug.cgi?id=121701

Thanks and best regards
-Lv

> From: Jens Axboe [mailto:ax...@kernel.dk]
> Subject: Regression in 4.7-rc7
> 
> Hi,
> 
> Updated the laptop to -rc7 this morning, and it fails to boot. After
> bisecting it, this is the culprit:
> 
> commit 45209046c47b93fadf26dc59a9da724f387b9cf2
> Author: Lv Zheng 
> Date:   Tue Jul 5 13:53:12 2016 +0800
> 
>  ACPICA: Namespace: Fix namespace/interpreter lock ordering
> 
>  There is a lock order issue in acpi_load_tables(). The namespace lock
>  is held before holding the interpreter lock.
> 
> The last I see is grub loading initramfs, after that nothing. Very
> reproducible. Laptop is a Dell XPS 13.
> 
> --
> Jens Axboe

Re: [RFC PATCH v5 0/7] perf config: Introduce default config key-value pairs arrays

[Namhyung Kim]

Hi Taeung,

On Tue, Jul 12, 2016 at 01:20:35PM +0900, Taeung Song wrote:
> Hi, Namhyung :)
> 
> As you know, the patch work from v3 to v4 took too long time
> because of a patchset refactoring perf_config().
> 
> So I guess it is hard for you to recall this patchset for new default
> config arrays but could you a bit response two simple questions ?
> 
> 
> 1) I renamed 'fb_ground' to 'fore_back_colors' in struct ui_browser_colorset
> at ui/browser.c.
> 
> Is it better than before ?

Not sure.  I don't think the renaming is necessary.  If you do, I
prefer simpler name like 'colors' or 'color_pair'.


> 
> 2) I added not only 'struct default_config_item' but also
> 'struct default_config_section'.
> (In order to use const type and 'const struct default_config_item *items'
> instead of using 'struct list_head items')
> 
> could you agree this way ?

I'm ok with it.

Thanks,
Namhyung


> 
> On 07/06/2016 02:20 PM, Taeung Song wrote:
> > Hello, :)
> > 
> > When initializing default perf config values,
> > we currently use values of actual type(int, bool, char *, etc.).
> > But I suggest using default config key-value pairs arrays.
> > 
> > For example,
> > If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' 
> > config variable,
> > default value for it is 'true' bool type value in perf like below.
> > 
> > At ui/browsers/annoate.c
> > 
> > static struct annotate_browser_opt {
> > bool hide_src_code,
> >  use_offset,
> > jump_arrows,
> > show_linenr,
> > show_nr_jumps,
> > show_total_period;
> > } annotate_browser__opts = {
> > .use_offset  = true,
> > .jump_arrows = true,
> > };
> > 
> > But if we use new config arrays that have all default config key-value 
> > pairs,
> > we could initialize default config values with them.
> > 
> > If we do, we can manage default perf config values at one spot (like 
> > util/config.c)
> > and It can be easy and simple to modify default config values or add new 
> > configs.
> > 
> > For example,
> > If we use new default config arrays and there isn't user config value for 
> > 'annoate.use_offset'
> > default value for it will be set as 
> > annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value
> > instead of actual boolean type value 'true'.
> > 
> > IMHO, I think it would needed to use new default config arrays
> > to manage default perf config values more effectively.
> > And this pathset contains patchs for only 'colors' and 'annoate' section
> > because waiting for other opinions.
> > 
> > If you review this patchset, I'd appreciate it :-)
> > 
> > Thanks,
> > Taeung
> > 
> > v5:
> > - rebased on current acme/perf/core
> > 
> > v4:
> > - rename 'fb_ground' to 'fore_back_colors' (Namhyung)
> > - add struct default_config_section
> > - split first patch[PATCH 1/7] as two
> > - remove perf_default_config_init() at perf.c
> > - rebased on current acme/perf/core
> > 
> > v3:
> > - remove default config arrays for the rest sections except 'colors' and 
> > 'annotate'
> > - use combined {fore, back}ground colors instead of each two color
> > - introduce perf_default_config_init() that call all default_*_config_init()
> >for each config section
> > 
> > v2:
> > - rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' 
> > (Arnaldo)
> > - change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
> > - use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)
> > 
> > Taeung Song (7):
> >perf config: Introduce default_config_section and default_config_item
> >  for default config key-value pairs
> >perf config: Add macros assigning key-value pairs to
> >  default_config_item
> >perf config: Add 'colors' section default configs arrrays
> >perf config: Use combined {fore,back}ground colors value instead of
> >  each two color
> >perf config: Initialize ui_browser__colorsets with default config
> >  items
> >perf config: Add 'annotate' section default configs arrrays
> >perf config: Initialize annotate_browser__opts with default config
> >  items
> > 
> >   tools/perf/ui/browser.c   | 64 +-
> >   tools/perf/ui/browsers/annotate.c | 16 ++--
> >   tools/perf/util/config.c  | 26 +
> >   tools/perf/util/config.h  | 82 
> > +++
> >   4 files changed, 156 insertions(+), 32 deletions(-)
> > 

Re: [RFC PATCH v5 0/7] perf config: Introduce default config key-value pairs arrays

[Namhyung Kim]

Hi Taeung,

On Tue, Jul 12, 2016 at 01:20:35PM +0900, Taeung Song wrote:
> Hi, Namhyung :)
> 
> As you know, the patch work from v3 to v4 took too long time
> because of a patchset refactoring perf_config().
> 
> So I guess it is hard for you to recall this patchset for new default
> config arrays but could you a bit response two simple questions ?
> 
> 
> 1) I renamed 'fb_ground' to 'fore_back_colors' in struct ui_browser_colorset
> at ui/browser.c.
> 
> Is it better than before ?

Not sure.  I don't think the renaming is necessary.  If you do, I
prefer simpler name like 'colors' or 'color_pair'.


> 
> 2) I added not only 'struct default_config_item' but also
> 'struct default_config_section'.
> (In order to use const type and 'const struct default_config_item *items'
> instead of using 'struct list_head items')
> 
> could you agree this way ?

I'm ok with it.

Thanks,
Namhyung


> 
> On 07/06/2016 02:20 PM, Taeung Song wrote:
> > Hello, :)
> > 
> > When initializing default perf config values,
> > we currently use values of actual type(int, bool, char *, etc.).
> > But I suggest using default config key-value pairs arrays.
> > 
> > For example,
> > If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' 
> > config variable,
> > default value for it is 'true' bool type value in perf like below.
> > 
> > At ui/browsers/annoate.c
> > 
> > static struct annotate_browser_opt {
> > bool hide_src_code,
> >  use_offset,
> > jump_arrows,
> > show_linenr,
> > show_nr_jumps,
> > show_total_period;
> > } annotate_browser__opts = {
> > .use_offset  = true,
> > .jump_arrows = true,
> > };
> > 
> > But if we use new config arrays that have all default config key-value 
> > pairs,
> > we could initialize default config values with them.
> > 
> > If we do, we can manage default perf config values at one spot (like 
> > util/config.c)
> > and It can be easy and simple to modify default config values or add new 
> > configs.
> > 
> > For example,
> > If we use new default config arrays and there isn't user config value for 
> > 'annoate.use_offset'
> > default value for it will be set as 
> > annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value
> > instead of actual boolean type value 'true'.
> > 
> > IMHO, I think it would needed to use new default config arrays
> > to manage default perf config values more effectively.
> > And this pathset contains patchs for only 'colors' and 'annoate' section
> > because waiting for other opinions.
> > 
> > If you review this patchset, I'd appreciate it :-)
> > 
> > Thanks,
> > Taeung
> > 
> > v5:
> > - rebased on current acme/perf/core
> > 
> > v4:
> > - rename 'fb_ground' to 'fore_back_colors' (Namhyung)
> > - add struct default_config_section
> > - split first patch[PATCH 1/7] as two
> > - remove perf_default_config_init() at perf.c
> > - rebased on current acme/perf/core
> > 
> > v3:
> > - remove default config arrays for the rest sections except 'colors' and 
> > 'annotate'
> > - use combined {fore, back}ground colors instead of each two color
> > - introduce perf_default_config_init() that call all default_*_config_init()
> >for each config section
> > 
> > v2:
> > - rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' 
> > (Arnaldo)
> > - change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
> > - use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)
> > 
> > Taeung Song (7):
> >perf config: Introduce default_config_section and default_config_item
> >  for default config key-value pairs
> >perf config: Add macros assigning key-value pairs to
> >  default_config_item
> >perf config: Add 'colors' section default configs arrrays
> >perf config: Use combined {fore,back}ground colors value instead of
> >  each two color
> >perf config: Initialize ui_browser__colorsets with default config
> >  items
> >perf config: Add 'annotate' section default configs arrrays
> >perf config: Initialize annotate_browser__opts with default config
> >  items
> > 
> >   tools/perf/ui/browser.c   | 64 +-
> >   tools/perf/ui/browsers/annotate.c | 16 ++--
> >   tools/perf/util/config.c  | 26 +
> >   tools/perf/util/config.h  | 82 
> > +++
> >   4 files changed, 156 insertions(+), 32 deletions(-)
> > 

Re: [PATCH 1/2] Bluetooth: Add LED triggers for HCI frames tx and rx

[Guodong Xu]

Dear maintainers,

Would you have a review on this?

-Guodong

On 23 June 2016 at 12:58, Guodong Xu  wrote:
> Two LED triggers are defined: tx_led and rx_led. Upon frames
> available in HCI core layer, for tx or for rx, the combined LED
> can blink.
>
> Verified on HiKey, 96boards. It uses hi6220 SoC and TI WL1835 combo
> chip.
>
> Signed-off-by: Guodong Xu 
> ---
>  include/net/bluetooth/hci_core.h |  1 +
>  net/bluetooth/hci_core.c |  3 +++
>  net/bluetooth/leds.c | 15 +++
>  net/bluetooth/leds.h |  2 ++
>  4 files changed, 21 insertions(+)
>
> diff --git a/include/net/bluetooth/hci_core.h 
> b/include/net/bluetooth/hci_core.h
> index dc71473..37b8dd9 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -398,6 +398,7 @@ struct hci_dev {
> bdaddr_trpa;
>
> struct led_trigger  *power_led;
> +   struct led_trigger  *tx_led, *rx_led;
>
> int (*open)(struct hci_dev *hdev);
> int (*close)(struct hci_dev *hdev);
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 45a9fc6..c6e1210 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -3248,6 +3248,7 @@ int hci_recv_frame(struct hci_dev *hdev, struct sk_buff 
> *skb)
> skb_queue_tail(>rx_q, skb);
> queue_work(hdev->workqueue, >rx_work);
>
> +   hci_leds_blink_oneshot(hdev->rx_led);
> return 0;
>  }
>  EXPORT_SYMBOL(hci_recv_frame);
> @@ -3325,6 +3326,8 @@ static void hci_send_frame(struct hci_dev *hdev, struct 
> sk_buff *skb)
> BT_ERR("%s sending frame failed (%d)", hdev->name, err);
> kfree_skb(skb);
> }
> +
> +   hci_leds_blink_oneshot(hdev->tx_led);
>  }
>
>  /* Send HCI command */
> diff --git a/net/bluetooth/leds.c b/net/bluetooth/leds.c
> index 8319c84..c4825d5 100644
> --- a/net/bluetooth/leds.c
> +++ b/net/bluetooth/leds.c
> @@ -19,6 +19,8 @@ struct hci_basic_led_trigger {
>  #define to_hci_basic_led_trigger(arg) container_of(arg, \
> struct hci_basic_led_trigger, led_trigger)
>
> +#define BLUETOOTH_BLINK_DELAY  50 /* ms */
> +
>  void hci_leds_update_powered(struct hci_dev *hdev, bool enabled)
>  {
> if (hdev->power_led)
> @@ -37,6 +39,15 @@ static void power_activate(struct led_classdev *led_cdev)
> led_trigger_event(led_cdev->trigger, powered ? LED_FULL : LED_OFF);
>  }
>
> +void hci_leds_blink_oneshot(struct led_trigger *trig)
> +{
> +   unsigned long led_delay = BLUETOOTH_BLINK_DELAY;
> +
> +   if (!trig)
> +   return;
> +   led_trigger_blink_oneshot(trig, _delay, _delay, 0);
> +}
> +
>  static struct led_trigger *led_allocate_basic(struct hci_dev *hdev,
> void (*activate)(struct led_classdev *led_cdev),
> const char *name)
> @@ -71,4 +82,8 @@ void hci_leds_init(struct hci_dev *hdev)
>  {
> /* initialize power_led */
> hdev->power_led = led_allocate_basic(hdev, power_activate, "power");
> +   /* initialize tx_led */
> +   hdev->tx_led = led_allocate_basic(hdev, NULL, "tx");
> +   /* initialize rx_led */
> +   hdev->rx_led = led_allocate_basic(hdev, NULL, "rx");
>  }
> diff --git a/net/bluetooth/leds.h b/net/bluetooth/leds.h
> index a9c4d6e..9b1cccd 100644
> --- a/net/bluetooth/leds.h
> +++ b/net/bluetooth/leds.h
> @@ -9,8 +9,10 @@
>  #if IS_ENABLED(CONFIG_BT_LEDS)
>  void hci_leds_update_powered(struct hci_dev *hdev, bool enabled);
>  void hci_leds_init(struct hci_dev *hdev);
> +void hci_leds_blink_oneshot(struct led_trigger *trig);
>  #else
>  static inline void hci_leds_update_powered(struct hci_dev *hdev,
>bool enabled) {}
>  static inline void hci_leds_init(struct hci_dev *hdev) {}
> +static inline void hci_leds_blink_oneshot(struct led_trigger *trig) {}
>  #endif
> --
> 1.9.1
>

Re: [PATCH 1/2] Bluetooth: Add LED triggers for HCI frames tx and rx

[Guodong Xu]

Dear maintainers,

Would you have a review on this?

-Guodong

On 23 June 2016 at 12:58, Guodong Xu  wrote:
> Two LED triggers are defined: tx_led and rx_led. Upon frames
> available in HCI core layer, for tx or for rx, the combined LED
> can blink.
>
> Verified on HiKey, 96boards. It uses hi6220 SoC and TI WL1835 combo
> chip.
>
> Signed-off-by: Guodong Xu 
> ---
>  include/net/bluetooth/hci_core.h |  1 +
>  net/bluetooth/hci_core.c |  3 +++
>  net/bluetooth/leds.c | 15 +++
>  net/bluetooth/leds.h |  2 ++
>  4 files changed, 21 insertions(+)
>
> diff --git a/include/net/bluetooth/hci_core.h 
> b/include/net/bluetooth/hci_core.h
> index dc71473..37b8dd9 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -398,6 +398,7 @@ struct hci_dev {
> bdaddr_trpa;
>
> struct led_trigger  *power_led;
> +   struct led_trigger  *tx_led, *rx_led;
>
> int (*open)(struct hci_dev *hdev);
> int (*close)(struct hci_dev *hdev);
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 45a9fc6..c6e1210 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -3248,6 +3248,7 @@ int hci_recv_frame(struct hci_dev *hdev, struct sk_buff 
> *skb)
> skb_queue_tail(>rx_q, skb);
> queue_work(hdev->workqueue, >rx_work);
>
> +   hci_leds_blink_oneshot(hdev->rx_led);
> return 0;
>  }
>  EXPORT_SYMBOL(hci_recv_frame);
> @@ -3325,6 +3326,8 @@ static void hci_send_frame(struct hci_dev *hdev, struct 
> sk_buff *skb)
> BT_ERR("%s sending frame failed (%d)", hdev->name, err);
> kfree_skb(skb);
> }
> +
> +   hci_leds_blink_oneshot(hdev->tx_led);
>  }
>
>  /* Send HCI command */
> diff --git a/net/bluetooth/leds.c b/net/bluetooth/leds.c
> index 8319c84..c4825d5 100644
> --- a/net/bluetooth/leds.c
> +++ b/net/bluetooth/leds.c
> @@ -19,6 +19,8 @@ struct hci_basic_led_trigger {
>  #define to_hci_basic_led_trigger(arg) container_of(arg, \
> struct hci_basic_led_trigger, led_trigger)
>
> +#define BLUETOOTH_BLINK_DELAY  50 /* ms */
> +
>  void hci_leds_update_powered(struct hci_dev *hdev, bool enabled)
>  {
> if (hdev->power_led)
> @@ -37,6 +39,15 @@ static void power_activate(struct led_classdev *led_cdev)
> led_trigger_event(led_cdev->trigger, powered ? LED_FULL : LED_OFF);
>  }
>
> +void hci_leds_blink_oneshot(struct led_trigger *trig)
> +{
> +   unsigned long led_delay = BLUETOOTH_BLINK_DELAY;
> +
> +   if (!trig)
> +   return;
> +   led_trigger_blink_oneshot(trig, _delay, _delay, 0);
> +}
> +
>  static struct led_trigger *led_allocate_basic(struct hci_dev *hdev,
> void (*activate)(struct led_classdev *led_cdev),
> const char *name)
> @@ -71,4 +82,8 @@ void hci_leds_init(struct hci_dev *hdev)
>  {
> /* initialize power_led */
> hdev->power_led = led_allocate_basic(hdev, power_activate, "power");
> +   /* initialize tx_led */
> +   hdev->tx_led = led_allocate_basic(hdev, NULL, "tx");
> +   /* initialize rx_led */
> +   hdev->rx_led = led_allocate_basic(hdev, NULL, "rx");
>  }
> diff --git a/net/bluetooth/leds.h b/net/bluetooth/leds.h
> index a9c4d6e..9b1cccd 100644
> --- a/net/bluetooth/leds.h
> +++ b/net/bluetooth/leds.h
> @@ -9,8 +9,10 @@
>  #if IS_ENABLED(CONFIG_BT_LEDS)
>  void hci_leds_update_powered(struct hci_dev *hdev, bool enabled);
>  void hci_leds_init(struct hci_dev *hdev);
> +void hci_leds_blink_oneshot(struct led_trigger *trig);
>  #else
>  static inline void hci_leds_update_powered(struct hci_dev *hdev,
>bool enabled) {}
>  static inline void hci_leds_init(struct hci_dev *hdev) {}
> +static inline void hci_leds_blink_oneshot(struct led_trigger *trig) {}
>  #endif
> --
> 1.9.1
>

Re: [PATCH] vfs: check i_count under lock in evict_inodes

[Al Viro]

On Mon, Jul 11, 2016 at 06:31:57PM -0700, David Chen wrote:
> Hi Al,
> 
> I'm not sure about the in-tree fs, but in zfsonlinux, it would offload
> iput to a thread, so this would happen there. And it would wait for
> the thread in put_super(), so that part is not a problem...

*shrug*  I hadn't looked (and won't look) at zfs glue, but I'd suggest
trying something along the line of stopping that thread in the beginning
of your ->kill_sb() (having told the sucker to stop offloading, of course)
and only then calling generic_shutdown_super()...

Re: [PATCH] vfs: check i_count under lock in evict_inodes

[Al Viro]

On Mon, Jul 11, 2016 at 06:31:57PM -0700, David Chen wrote:
> Hi Al,
> 
> I'm not sure about the in-tree fs, but in zfsonlinux, it would offload
> iput to a thread, so this would happen there. And it would wait for
> the thread in put_super(), so that part is not a problem...

*shrug*  I hadn't looked (and won't look) at zfs glue, but I'd suggest
trying something along the line of stopping that thread in the beginning
of your ->kill_sb() (having told the sucker to stop offloading, of course)
and only then calling generic_shutdown_super()...

[git pull] vfs.git fixes

[Al Viro]

The following changes since commit a99cde438de0c4c0cecc1d1af1a55a75b10bfdef:

  Linux 4.7-rc6 (2016-07-03 23:01:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 6d4e56ce977864b0fcd28c61555060e6010aa89b:

  posix_acl: de-union a_refcount and a_rcu (2016-07-11 13:48:02 -0400)


Al Viro (2):
  Use the right predicate in ->atomic_open() instances
  nfs_atomic_open(): prevent parallel nfs_lookup() on a negative hashed

Jeff Layton (1):
  posix_acl: de-union a_refcount and a_rcu

 fs/9p/vfs_inode.c |  2 +-
 fs/9p/vfs_inode_dotl.c|  2 +-
 fs/ceph/file.c|  2 +-
 fs/cifs/dir.c |  2 +-
 fs/fuse/dir.c |  2 +-
 fs/gfs2/inode.c   |  2 +-
 fs/nfs/dir.c  | 30 ++
 include/linux/posix_acl.h |  6 ++
 8 files changed, 34 insertions(+), 14 deletions(-)

[git pull] vfs.git fixes

[Al Viro]

The following changes since commit a99cde438de0c4c0cecc1d1af1a55a75b10bfdef:

  Linux 4.7-rc6 (2016-07-03 23:01:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 6d4e56ce977864b0fcd28c61555060e6010aa89b:

  posix_acl: de-union a_refcount and a_rcu (2016-07-11 13:48:02 -0400)


Al Viro (2):
  Use the right predicate in ->atomic_open() instances
  nfs_atomic_open(): prevent parallel nfs_lookup() on a negative hashed

Jeff Layton (1):
  posix_acl: de-union a_refcount and a_rcu

 fs/9p/vfs_inode.c |  2 +-
 fs/9p/vfs_inode_dotl.c|  2 +-
 fs/ceph/file.c|  2 +-
 fs/cifs/dir.c |  2 +-
 fs/fuse/dir.c |  2 +-
 fs/gfs2/inode.c   |  2 +-
 fs/nfs/dir.c  | 30 ++
 include/linux/posix_acl.h |  6 ++
 8 files changed, 34 insertions(+), 14 deletions(-)

Re: [PATCH v2] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

[Baolin Wang]

On 11 July 2016 at 19:38, Michal Nazarewicz  wrote:
> On Mon, Jul 11 2016, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>> Acked-by: Michal Nazarewicz 
>> ---
>> Changelog since v1:
>>  - Remove the in_ep modification.
>>  - Remove max_t() function.
>>
>>  drivers/usb/gadget/function/f_midi.c |   12 
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..59f6278 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -359,10 +359,14 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> + unsigned length;
>> +
>> + length = midi->buflen < bulk_out_desc.wMaxPacketSize
>> + ? bulk_out_desc.wMaxPacketSize
>> + : usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> +  midi->buflen);
>
> As pointed out by Felipe, the packet does not need to be wMaxPacketSize
> so this can simply be:

OK. Thanks.

>
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>
>> + req = midi_alloc_ep_req(midi->out_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>> --
>> 1.7.9.5
>>
>
> --
> Best regards
> ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
> «If at first you don’t succeed, give up skydiving»



-- 
Baolin.wang
Best Regards

Re: [PATCH v2] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

[Baolin Wang]

On 11 July 2016 at 19:38, Michal Nazarewicz  wrote:
> On Mon, Jul 11 2016, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>> Acked-by: Michal Nazarewicz 
>> ---
>> Changelog since v1:
>>  - Remove the in_ep modification.
>>  - Remove max_t() function.
>>
>>  drivers/usb/gadget/function/f_midi.c |   12 
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..59f6278 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -359,10 +359,14 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> + unsigned length;
>> +
>> + length = midi->buflen < bulk_out_desc.wMaxPacketSize
>> + ? bulk_out_desc.wMaxPacketSize
>> + : usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> +  midi->buflen);
>
> As pointed out by Felipe, the packet does not need to be wMaxPacketSize
> so this can simply be:

OK. Thanks.

>
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>
>> + req = midi_alloc_ep_req(midi->out_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>> --
>> 1.7.9.5
>>
>
> --
> Best regards
> ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
> «If at first you don’t succeed, give up skydiving»



-- 
Baolin.wang
Best Regards

Re: [PATCH v3 0/7] PCI: Add support for enforcing all MMIO BARs not to share PAGE_SIZE

[Yongji Xie]

Hi Bjorn,

Any comment on V3?

Thanks,

Yongji


On 2016/6/30 18:53, Yongji Xie wrote:

This series aims to add an option for PCI resource allocator to
force BARs not to share PAGE_SIZE. This would make sense to VFIO
driver. Because current VFIO implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs which may share the same page
with other BARs for security reasons. Thus, we have to handle mmio
access to these BARs in QEMU emulation rather than in guest which
will cause some performance loss.

To achieve that, we would like to make use of the existing
resource_alignment kernel parameter and force a minimum alignment
of PAGE_SIZE. It's flexible. And we can enable it by default on
some archs which may easily hit the performance issue because of
their 64K page.

In this series, patch 1,2,3 fixed bugs of using resource_alignment;
patch 4,5 tried to add a new option for resource_alignment to use
IORESOURCE_STARTALIGN to specify the alignment of PCI BARs; patch 6
modified resource_alignment to support syntax which can be used to
enforce the alignment of all MMIO BARs to be at least PAGE_SIZE;
patch 7 enabled this feature by default on PowerNV platform.

Changelog v3:
- Ignore enforced alignment to fixed BARs
- Fix issue that disabling memory decoding when reassigning the alignment
- Only enable default alignment on PowerNV platform

Changelog v2:
- Ignore enforced alignment to VF BARs on pci_reassigndev_resource_alignment()

Yongji Xie (7):
   PCI: Ignore enforced alignment when kernel uses existing firmware setup
   PCI: Ignore enforced alignment to VF BARs
   PCI: Do not disable memory decoding in pci_reassigndev_resource_alignment()
   PCI: Add a new option for resource_alignment to reassign alignment
   PCI: Do not use IORESOURCE_STARTALIGN to identify bridge resources
   PCI: Add support for enforcing all MMIO BARs to be page aligned
   PCI: Add a macro to set default alignment for all PCI devices

  Documentation/kernel-parameters.txt |7 +-
  arch/powerpc/include/asm/pci.h  |4 ++
  drivers/pci/pci.c   |  123 +++
  drivers/pci/setup-bus.c |9 ++-
  4 files changed, 111 insertions(+), 32 deletions(-)

Re: [PATCH v3 0/7] PCI: Add support for enforcing all MMIO BARs not to share PAGE_SIZE

[Yongji Xie]

Hi Bjorn,

Any comment on V3?

Thanks,

Yongji


On 2016/6/30 18:53, Yongji Xie wrote:

This series aims to add an option for PCI resource allocator to
force BARs not to share PAGE_SIZE. This would make sense to VFIO
driver. Because current VFIO implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs which may share the same page
with other BARs for security reasons. Thus, we have to handle mmio
access to these BARs in QEMU emulation rather than in guest which
will cause some performance loss.

To achieve that, we would like to make use of the existing
resource_alignment kernel parameter and force a minimum alignment
of PAGE_SIZE. It's flexible. And we can enable it by default on
some archs which may easily hit the performance issue because of
their 64K page.

In this series, patch 1,2,3 fixed bugs of using resource_alignment;
patch 4,5 tried to add a new option for resource_alignment to use
IORESOURCE_STARTALIGN to specify the alignment of PCI BARs; patch 6
modified resource_alignment to support syntax which can be used to
enforce the alignment of all MMIO BARs to be at least PAGE_SIZE;
patch 7 enabled this feature by default on PowerNV platform.

Changelog v3:
- Ignore enforced alignment to fixed BARs
- Fix issue that disabling memory decoding when reassigning the alignment
- Only enable default alignment on PowerNV platform

Changelog v2:
- Ignore enforced alignment to VF BARs on pci_reassigndev_resource_alignment()

Yongji Xie (7):
   PCI: Ignore enforced alignment when kernel uses existing firmware setup
   PCI: Ignore enforced alignment to VF BARs
   PCI: Do not disable memory decoding in pci_reassigndev_resource_alignment()
   PCI: Add a new option for resource_alignment to reassign alignment
   PCI: Do not use IORESOURCE_STARTALIGN to identify bridge resources
   PCI: Add support for enforcing all MMIO BARs to be page aligned
   PCI: Add a macro to set default alignment for all PCI devices

  Documentation/kernel-parameters.txt |7 +-
  arch/powerpc/include/asm/pci.h  |4 ++
  drivers/pci/pci.c   |  123 +++
  drivers/pci/setup-bus.c |9 ++-
  4 files changed, 111 insertions(+), 32 deletions(-)

Re: [patch 10/15] sched/migration: Move calc_load_migrate() into CPU_DYING

[Anton Blanchard]

Hi Thomas,

> It really does not matter when we fold the load for the outgoing cpu.
> It's almost dead anyway, so there is no harm if we fail to fold the
> few microseconds which are required for going fully away.

We are seeing the load average shoot up when hot unplugging CPUs (+1
for every CPU we offline) on ppc64. This reproduces on bare metal as
well as inside a KVM guest. A bisect points at this commit.

As an example, a completely idle box with 128 CPUS and 112 hot
unplugged:

# uptime
 04:35:30 up  1:23,  2 users,  load average: 112.43, 122.94, 125.54

Anton

Re: [patch 10/15] sched/migration: Move calc_load_migrate() into CPU_DYING

[Anton Blanchard]

Hi Thomas,

> It really does not matter when we fold the load for the outgoing cpu.
> It's almost dead anyway, so there is no harm if we fail to fold the
> few microseconds which are required for going fully away.

We are seeing the load average shoot up when hot unplugging CPUs (+1
for every CPU we offline) on ppc64. This reproduces on bare metal as
well as inside a KVM guest. A bisect points at this commit.

As an example, a completely idle box with 128 CPUS and 112 hot
unplugged:

# uptime
 04:35:30 up  1:23,  2 users,  load average: 112.43, 122.94, 125.54

Anton

Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

[Archit Taneja]

On 07/06/2016 07:28 AM, Nicolas Boichat wrote:

Hi Archit,

Sorry got swamped by other things and forgot to reply.

On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja  wrote:



On 06/27/2016 01:18 PM, Nicolas Boichat wrote:


Hi all,

This is a follow up to the 2 patches to add support for ANX7688 sent here:
https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for
the comments.

I also added 2 patches to add support for a simple display MUX, as I'm
facing
similar issues while trying to implement it, i.e. the current DRM core
does not
seem to support this kind of simple pass-thru bridge very well: it is not
very
clear where connectors should be defined and attached. In this case, not
defining any connectors in the 2 bridges (and reusing the connector in MTK
HDMI driver) seem to work best, but makes little logical sense as the
physical
connectors are actually attached to the bridges.



Bridges aren't really drm objects in themselves, they can just be
thought of as entities that attach to an encoder. From a drm
perspective, the connector is only linked to an encoder. It
doesn't see any bridges. Therefore, it doesn't matter much
if the bridge driver doesn't create connectors. The DT bindings,
however, should be close to the physical connections.



In any case, the board has the following layout:
   - MT8173 HDMI bridge
 - HDMI mux with 2 ports
   1. ANX7688 for HDMI->DP over USB-C conversion
   2. Native HDMI



So, the MTK SoC's HDMI output (TMDS lines) can be routed to the
connector on the board directly (native mode), or via the ANX7688
bridge using the gpio mux. Did I get this part right?


Yes.


Is there only one connector at the end of both the output paths?


Err, there are:
  - 2 physical connectors (HDMI, USB-C)
  - 1 DT connector in the device tree (native HDMI), I don't bother
adding a connector to anx7688, but in theory I could.
  - 1 DRM connector object (defined in the mtk hdmi driver)


The mux is controlled by hardware, looking at the HPD signals from both
ANX7688
and native HDMI, with a priority on the native HDMI output.



I didn't understand this. I can see that ANX7688 could generate a HPD
signal on behalf of the connected monitor, but why would the native MTK
HDMI controller generate a HPD signal? I would expect it to receive HPD
and trigger a CPU interrupt.

Could you also give an idea about why the hardware switches between the
two paths? It it based on what kind of device plugs into the connector?


The mux is controlled in hardware, by looking at both HPD lines:
  - USB-C (HPD controlled by ANX7688, depending if there is a DP over
USB-C device connected)
  - native HDMI (HPD controlled by monitor on remote side)

Note that, like the other HDMI lines, HPD is "muxed" (depending on the
logic above), and wired up to MTK SoC HDMI/CEC module, which generates
the interrupts.

Priority is set to native HDMI port, so if both HPD signals are
active, the output will stay on the HDMI port.


Thanks for the clarification.

It's a strange setup. It would be ideal to have 2 connectors visible to
userspace, with only one of them being 'DRM_MODE_CONNECTED' at a time.
There would be a bit of an overkill whenever userspace gets a hotplug
event, resulting in tearing down and setting up crtcs, encoders even
though nothing really changes much upstream.

I think the mux bridge part looks fine, but I don't know what's the best
way how to describe the connectors here :) (one drm_connector
representing both the physical connectors, or 2 separate drm_connector
entities which both can't be connected at the same time). Maybe someone
else from the list could help us out here.

Archit



Best,

Nicolas


Thanks,
Archit




The whole setup works fairly well without any Linux kernel drivers, except
the
2 following cases:
   1. When ANX7688 is active, DP bandwidth may be limited, so we need to
filter
  resolutions that would exceed the available bandwidth.
   2. When both outputs HPD signals are active, the kernel does not receive
an
  HPD pulse when the HDMI input is unplugged.

ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel
to
re-read the EDID on mux output change, and also issue 1 by filtering only
when
ANX7688 is active.

I understand this patch series might not be acceptable as-is, but I hope
this
sort of setup can be taken into account when better support for connector
drivers is introduced.

Thanks!

Best,

Nicolas

Nicolas Boichat (4):
drm: bridge: anx7688: Add anx7688 bridge driver support.
devicetree: Add ANX7688 transmitter binding
drm: bridge: Generic GPIO mux driver
devicetree: Add GPIO display mux binding

   .../devicetree/bindings/drm/bridge/anx7688.txt |  32 ++
   .../devicetree/bindings/drm/bridge/gpio-mux.txt|  59 
   drivers/gpu/drm/bridge/Kconfig |  20 ++
   drivers/gpu/drm/bridge/Makefile|   2 +
   

Re: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

[Archit Taneja]

On 07/06/2016 07:28 AM, Nicolas Boichat wrote:

Hi Archit,

Sorry got swamped by other things and forgot to reply.

On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja  wrote:



On 06/27/2016 01:18 PM, Nicolas Boichat wrote:


Hi all,

This is a follow up to the 2 patches to add support for ANX7688 sent here:
https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for
the comments.

I also added 2 patches to add support for a simple display MUX, as I'm
facing
similar issues while trying to implement it, i.e. the current DRM core
does not
seem to support this kind of simple pass-thru bridge very well: it is not
very
clear where connectors should be defined and attached. In this case, not
defining any connectors in the 2 bridges (and reusing the connector in MTK
HDMI driver) seem to work best, but makes little logical sense as the
physical
connectors are actually attached to the bridges.



Bridges aren't really drm objects in themselves, they can just be
thought of as entities that attach to an encoder. From a drm
perspective, the connector is only linked to an encoder. It
doesn't see any bridges. Therefore, it doesn't matter much
if the bridge driver doesn't create connectors. The DT bindings,
however, should be close to the physical connections.



In any case, the board has the following layout:
   - MT8173 HDMI bridge
 - HDMI mux with 2 ports
   1. ANX7688 for HDMI->DP over USB-C conversion
   2. Native HDMI



So, the MTK SoC's HDMI output (TMDS lines) can be routed to the
connector on the board directly (native mode), or via the ANX7688
bridge using the gpio mux. Did I get this part right?


Yes.


Is there only one connector at the end of both the output paths?


Err, there are:
  - 2 physical connectors (HDMI, USB-C)
  - 1 DT connector in the device tree (native HDMI), I don't bother
adding a connector to anx7688, but in theory I could.
  - 1 DRM connector object (defined in the mtk hdmi driver)


The mux is controlled by hardware, looking at the HPD signals from both
ANX7688
and native HDMI, with a priority on the native HDMI output.



I didn't understand this. I can see that ANX7688 could generate a HPD
signal on behalf of the connected monitor, but why would the native MTK
HDMI controller generate a HPD signal? I would expect it to receive HPD
and trigger a CPU interrupt.

Could you also give an idea about why the hardware switches between the
two paths? It it based on what kind of device plugs into the connector?


The mux is controlled in hardware, by looking at both HPD lines:
  - USB-C (HPD controlled by ANX7688, depending if there is a DP over
USB-C device connected)
  - native HDMI (HPD controlled by monitor on remote side)

Note that, like the other HDMI lines, HPD is "muxed" (depending on the
logic above), and wired up to MTK SoC HDMI/CEC module, which generates
the interrupts.

Priority is set to native HDMI port, so if both HPD signals are
active, the output will stay on the HDMI port.


Thanks for the clarification.

It's a strange setup. It would be ideal to have 2 connectors visible to
userspace, with only one of them being 'DRM_MODE_CONNECTED' at a time.
There would be a bit of an overkill whenever userspace gets a hotplug
event, resulting in tearing down and setting up crtcs, encoders even
though nothing really changes much upstream.

I think the mux bridge part looks fine, but I don't know what's the best
way how to describe the connectors here :) (one drm_connector
representing both the physical connectors, or 2 separate drm_connector
entities which both can't be connected at the same time). Maybe someone
else from the list could help us out here.

Archit



Best,

Nicolas


Thanks,
Archit




The whole setup works fairly well without any Linux kernel drivers, except
the
2 following cases:
   1. When ANX7688 is active, DP bandwidth may be limited, so we need to
filter
  resolutions that would exceed the available bandwidth.
   2. When both outputs HPD signals are active, the kernel does not receive
an
  HPD pulse when the HDMI input is unplugged.

ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel
to
re-read the EDID on mux output change, and also issue 1 by filtering only
when
ANX7688 is active.

I understand this patch series might not be acceptable as-is, but I hope
this
sort of setup can be taken into account when better support for connector
drivers is introduced.

Thanks!

Best,

Nicolas

Nicolas Boichat (4):
drm: bridge: anx7688: Add anx7688 bridge driver support.
devicetree: Add ANX7688 transmitter binding
drm: bridge: Generic GPIO mux driver
devicetree: Add GPIO display mux binding

   .../devicetree/bindings/drm/bridge/anx7688.txt |  32 ++
   .../devicetree/bindings/drm/bridge/gpio-mux.txt|  59 
   drivers/gpu/drm/bridge/Kconfig |  20 ++
   drivers/gpu/drm/bridge/Makefile|   2 +
   drivers/gpu/drm/bridge/analogix-anx7688.c  | 233 

Re: crypto: ux500 - memmove the right size

[Herbert Xu]

On Mon, Jul 11, 2016 at 04:40:34PM +0200, Toralf Förster wrote:
> While reading the comment to 19ced623d :
> 
> "The hash buffer is really HASH_BLOCK_SIZE bytes, someone
> must have thought that memmove takes n*u32 words by mistake.
> Tests work as good/bad as before after this patch.
> "
> 
> I was just curious why the tests doesn't fail now and since when the bug were 
> in the code.
> The answer to the later is simple - the bug is there since the beginning of 
> that file.
> What's do you think about the first question ?

The tests do/can not cover every possible execution path.  Of course
if you can write a simple vector/test that covers this case that
would be very nice.

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

Re: crypto: ux500 - memmove the right size

[Herbert Xu]

On Mon, Jul 11, 2016 at 04:40:34PM +0200, Toralf Förster wrote:
> While reading the comment to 19ced623d :
> 
> "The hash buffer is really HASH_BLOCK_SIZE bytes, someone
> must have thought that memmove takes n*u32 words by mistake.
> Tests work as good/bad as before after this patch.
> "
> 
> I was just curious why the tests doesn't fail now and since when the bug were 
> in the code.
> The answer to the later is simple - the bug is there since the beginning of 
> that file.
> What's do you think about the first question ?

The tests do/can not cover every possible execution path.  Of course
if you can write a simple vector/test that covers this case that
would be very nice.

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

Re: [PATCH 3/3] crypto: Added Chelsio Menu to the Kconfig file

[kbuild test robot]

Hi,

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.7-rc7 next-20160711]
[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/Yeshaswi-M-R-Gowda/crypto-chcr-Add-Chelsio-Crypto-Driver/20160712-023513
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

   In file included from include/linux/swab.h:4:0,
from include/uapi/linux/byteorder/little_endian.h:12,
from include/linux/byteorder/little_endian.h:4,
from arch/sh/include/uapi/asm/byteorder.h:5,
from arch/sh/include/asm/bitops.h:11,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from drivers/crypto/chelsio/chcr_algo.c:42:
   drivers/crypto/chelsio/chcr_algo.c: In function 'create_wreq':
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:129:32: note: in definition of macro '__swab64'
 (__builtin_constant_p((__u64)(x)) ? \
   ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:23:12: note: in definition of macro 
'___constant_swab64'
 (((__u64)(x) & (__u64)0x00ffULL) << 56) | \
   ^
>> include/uapi/linux/byteorder/little_endian.h:36:43: note: in expansion of 
>> macro '__swab64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
  ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:24:12: note: in definition of macro 
'___constant_swab64'
 (((__u64)(x) & (__u64)0xff00ULL) << 40) | \
   ^
>> include/uapi/linux/byteorder/little_endian.h:36:43: note: in expansion of 
>> macro '__swab64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
  ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:25:12: note: in definition of macro 
'___constant_swab64'
 (((__u64)(x) & (__u64)0x00ffULL) << 24) | \
   ^
>> include/uapi/linux/byteorder/little_endian.h:36:43: note: in expansion of 
>> macro '__swab64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
  ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:26:12: note: in definition of macro 
'___constant_swab64'
 (((__

Re: [PATCH 3/3] crypto: Added Chelsio Menu to the Kconfig file

[kbuild test robot]

Hi,

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.7-rc7 next-20160711]
[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/Yeshaswi-M-R-Gowda/crypto-chcr-Add-Chelsio-Crypto-Driver/20160712-023513
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

   In file included from include/linux/swab.h:4:0,
from include/uapi/linux/byteorder/little_endian.h:12,
from include/linux/byteorder/little_endian.h:4,
from arch/sh/include/uapi/asm/byteorder.h:5,
from arch/sh/include/asm/bitops.h:11,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from drivers/crypto/chelsio/chcr_algo.c:42:
   drivers/crypto/chelsio/chcr_algo.c: In function 'create_wreq':
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:129:32: note: in definition of macro '__swab64'
 (__builtin_constant_p((__u64)(x)) ? \
   ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:23:12: note: in definition of macro 
'___constant_swab64'
 (((__u64)(x) & (__u64)0x00ffULL) << 56) | \
   ^
>> include/uapi/linux/byteorder/little_endian.h:36:43: note: in expansion of 
>> macro '__swab64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
  ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:24:12: note: in definition of macro 
'___constant_swab64'
 (((__u64)(x) & (__u64)0xff00ULL) << 40) | \
   ^
>> include/uapi/linux/byteorder/little_endian.h:36:43: note: in expansion of 
>> macro '__swab64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
  ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:25:12: note: in definition of macro 
'___constant_swab64'
 (((__u64)(x) & (__u64)0x00ffULL) << 24) | \
   ^
>> include/uapi/linux/byteorder/little_endian.h:36:43: note: in expansion of 
>> macro '__swab64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
  ^
   include/linux/byteorder/generic.h:91:21: note: in expansion of macro 
'__cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
   drivers/crypto/chelsio/chcr_algo.c:454:17: note: in expansion of macro 
'cpu_to_be64'
 wreq->cookie = cpu_to_be64((u64)req);
^
   drivers/crypto/chelsio/chcr_algo.c:454:29: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
 wreq->cookie = cpu_to_be64((u64)req);
^
   include/uapi/linux/swab.h:26:12: note: in definition of macro 
'___constant_swab64'
 (((__

Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

[Wan Zongshun]

On 2016年07月12日 00:04, Arnd Bergmann wrote:

On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote:

+ifeq ($(CONFIG_SOC_NUC970),)
  obj-y  := irq.o time.o mfp.o gpio.o clock.o
  obj-y  += clksel.o dev.o cpu.o
+endif
  # W90X900 CPU support files


When mfp.o is disabled like this, I get a link error in two drivers
using the exported interface:

ERROR: "mfp_set_groupg" [drivers/spi/spi-nuc900.ko] undefined!
ERROR: "mfp_set_groupi" [drivers/input/keyboard/w90p910_keypad.ko] undefined!


Why remove mfp modules? this multifunction pin driver should be used for 
those two drivers, if no mfp_set_groupX, I don't think driver can work.


Now mfp has standard driver subsystem?



Any idea for a better migration strategy?

Arnd

Re: [PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

[Wan Zongshun]

On 2016年07月12日 00:04, Arnd Bergmann wrote:

On Sunday, July 10, 2016 3:27:21 PM CEST Wan Zongshun wrote:

+ifeq ($(CONFIG_SOC_NUC970),)
  obj-y  := irq.o time.o mfp.o gpio.o clock.o
  obj-y  += clksel.o dev.o cpu.o
+endif
  # W90X900 CPU support files


When mfp.o is disabled like this, I get a link error in two drivers
using the exported interface:

ERROR: "mfp_set_groupg" [drivers/spi/spi-nuc900.ko] undefined!
ERROR: "mfp_set_groupi" [drivers/input/keyboard/w90p910_keypad.ko] undefined!


Why remove mfp modules? this multifunction pin driver should be used for 
those two drivers, if no mfp_set_groupX, I don't think driver can work.


Now mfp has standard driver subsystem?



Any idea for a better migration strategy?

Arnd

Re: [PATCH] dmaengine: pxa_dma: implement device_synchronize

[Vinod Koul]

On Sun, Jul 10, 2016 at 11:50:49PM +0200, Robert Jarzmik wrote:
> Implement the function which wait until a dma channel is stopped to have
> a synchronization point.
> 
> This also protects the pxad_remove() from races, such as spurious
> interrupts while removing the driver, because :
>  - as long as there is one dma channel requested, ie. dma_chan_get() but
>no dma_chan_put(), the try_module_get() of dma_chan_get() prevents
>the remove() routine from running
>  - when the last channel is released, ie. the last dma_chan_put() is
>called, if there is a running DMA, pxad_synchronize() is called
>  - pxad_synchronize() waits for the channel to stop, which in turn
>ensures on pxa architecture that the interrupt cannot be fired anymore

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: pxa_dma: implement device_synchronize

[Vinod Koul]

On Sun, Jul 10, 2016 at 11:50:49PM +0200, Robert Jarzmik wrote:
> Implement the function which wait until a dma channel is stopped to have
> a synchronization point.
> 
> This also protects the pxad_remove() from races, such as spurious
> interrupts while removing the driver, because :
>  - as long as there is one dma channel requested, ie. dma_chan_get() but
>no dma_chan_put(), the try_module_get() of dma_chan_get() prevents
>the remove() routine from running
>  - when the last channel is released, ie. the last dma_chan_put() is
>called, if there is a running DMA, pxad_synchronize() is called
>  - pxad_synchronize() waits for the channel to stop, which in turn
>ensures on pxa architecture that the interrupt cannot be fired anymore

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: zynqmp: avoid cast warning

[Vinod Koul]

On Mon, Jul 11, 2016 at 11:46:09PM +0200, Arnd Bergmann wrote:
> The newly added zynqmp_dma driver produces a warning on 32-bit architectures
> when dma_addr_t is 64-bit wide:
> 
> drivers/dma/xilinx/zynqmp_dma.c: In function 'zynqmp_dma_config_sg_ll_desc':
> drivers/dma/xilinx/zynqmp_dma.c:321:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> ((dma_addr_t)sdesc - (dma_addr_t)chan->desc_pool_v);
>  ^
> drivers/dma/xilinx/zynqmp_dma.c:321:29: error: cast from pointer to integer 
> of different size [-Werror=pointer-to-int-cast]
> ((dma_addr_t)sdesc - (dma_addr_t)chan->desc_pool_v);
> 
> This changes the cast to the more appropriate uintptr_t.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: zynqmp: avoid cast warning

[Vinod Koul]

On Mon, Jul 11, 2016 at 11:46:09PM +0200, Arnd Bergmann wrote:
> The newly added zynqmp_dma driver produces a warning on 32-bit architectures
> when dma_addr_t is 64-bit wide:
> 
> drivers/dma/xilinx/zynqmp_dma.c: In function 'zynqmp_dma_config_sg_ll_desc':
> drivers/dma/xilinx/zynqmp_dma.c:321:9: error: cast from pointer to integer of 
> different size [-Werror=pointer-to-int-cast]
> ((dma_addr_t)sdesc - (dma_addr_t)chan->desc_pool_v);
>  ^
> drivers/dma/xilinx/zynqmp_dma.c:321:29: error: cast from pointer to integer 
> of different size [-Werror=pointer-to-int-cast]
> ((dma_addr_t)sdesc - (dma_addr_t)chan->desc_pool_v);
> 
> This changes the cast to the more appropriate uintptr_t.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: xilinx: Fix race condition in axi dma cyclic dma mode

[Vinod Koul]

On Sat, Jul 09, 2016 at 02:09:48PM +0530, Kedareswara rao Appana wrote:
> In cyclic DMA mode need to link the tail bd segment
> with the head bd segment to process bd's in cyclic.
> 
> Current driver is doing this only for tx channel
> needs to update the same for rx channel case also.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: xilinx: Fix race condition in axi dma cyclic dma mode

[Vinod Koul]

On Sat, Jul 09, 2016 at 02:09:48PM +0530, Kedareswara rao Appana wrote:
> In cyclic DMA mode need to link the tail bd segment
> with the head bd segment to process bd's in cyclic.
> 
> Current driver is doing this only for tx channel
> needs to update the same for rx channel case also.

Applied, thanks

-- 
~Vinod

Re: [RFC PATCH v5 0/7] perf config: Introduce default config key-value pairs arrays

[Taeung Song]

Hi, Namhyung :)

As you know, the patch work from v3 to v4 took too long time
because of a patchset refactoring perf_config().

So I guess it is hard for you to recall this patchset for new default
config arrays but could you a bit response two simple questions ?


1) I renamed 'fb_ground' to 'fore_back_colors' in struct 
ui_browser_colorset at ui/browser.c.


Is it better than before ?

2) I added not only 'struct default_config_item' but also
'struct default_config_section'.
(In order to use const type and 'const struct default_config_item *items'
instead of using 'struct list_head items')

could you agree this way ?


Thanks,
Taeung

On 07/06/2016 02:20 PM, Taeung Song wrote:

Hello, :)

When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.

For example,
If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' 
config variable,
default value for it is 'true' bool type value in perf like below.

At ui/browsers/annoate.c

static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
.use_offset  = true,
.jump_arrows = true,
};

But if we use new config arrays that have all default config key-value pairs,
we could initialize default config values with them.

If we do, we can manage default perf config values at one spot (like 
util/config.c)
and It can be easy and simple to modify default config values or add new 
configs.

For example,
If we use new default config arrays and there isn't user config value for 
'annoate.use_offset'
default value for it will be set as 
annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value
instead of actual boolean type value 'true'.

IMHO, I think it would needed to use new default config arrays
to manage default perf config values more effectively.
And this pathset contains patchs for only 'colors' and 'annoate' section
because waiting for other opinions.

If you review this patchset, I'd appreciate it :-)

Thanks,
Taeung

v5:
- rebased on current acme/perf/core

v4:
- rename 'fb_ground' to 'fore_back_colors' (Namhyung)
- add struct default_config_section
- split first patch[PATCH 1/7] as two
- remove perf_default_config_init() at perf.c
- rebased on current acme/perf/core

v3:
- remove default config arrays for the rest sections except 'colors' and 
'annotate'
- use combined {fore, back}ground colors instead of each two color
- introduce perf_default_config_init() that call all default_*_config_init()
   for each config section

v2:
- rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' (Arnaldo)
- change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
- use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)

Taeung Song (7):
   perf config: Introduce default_config_section and default_config_item
 for default config key-value pairs
   perf config: Add macros assigning key-value pairs to
 default_config_item
   perf config: Add 'colors' section default configs arrrays
   perf config: Use combined {fore,back}ground colors value instead of
 each two color
   perf config: Initialize ui_browser__colorsets with default config
 items
   perf config: Add 'annotate' section default configs arrrays
   perf config: Initialize annotate_browser__opts with default config
 items

  tools/perf/ui/browser.c   | 64 +-
  tools/perf/ui/browsers/annotate.c | 16 ++--
  tools/perf/util/config.c  | 26 +
  tools/perf/util/config.h  | 82 +++
  4 files changed, 156 insertions(+), 32 deletions(-)

Re: [RFC PATCH v5 0/7] perf config: Introduce default config key-value pairs arrays

[Taeung Song]

Hi, Namhyung :)

As you know, the patch work from v3 to v4 took too long time
because of a patchset refactoring perf_config().

So I guess it is hard for you to recall this patchset for new default
config arrays but could you a bit response two simple questions ?


1) I renamed 'fb_ground' to 'fore_back_colors' in struct 
ui_browser_colorset at ui/browser.c.


Is it better than before ?

2) I added not only 'struct default_config_item' but also
'struct default_config_section'.
(In order to use const type and 'const struct default_config_item *items'
instead of using 'struct list_head items')

could you agree this way ?


Thanks,
Taeung

On 07/06/2016 02:20 PM, Taeung Song wrote:

Hello, :)

When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.

For example,
If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' 
config variable,
default value for it is 'true' bool type value in perf like below.

At ui/browsers/annoate.c

static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
.use_offset  = true,
.jump_arrows = true,
};

But if we use new config arrays that have all default config key-value pairs,
we could initialize default config values with them.

If we do, we can manage default perf config values at one spot (like 
util/config.c)
and It can be easy and simple to modify default config values or add new 
configs.

For example,
If we use new default config arrays and there isn't user config value for 
'annoate.use_offset'
default value for it will be set as 
annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value
instead of actual boolean type value 'true'.

IMHO, I think it would needed to use new default config arrays
to manage default perf config values more effectively.
And this pathset contains patchs for only 'colors' and 'annoate' section
because waiting for other opinions.

If you review this patchset, I'd appreciate it :-)

Thanks,
Taeung

v5:
- rebased on current acme/perf/core

v4:
- rename 'fb_ground' to 'fore_back_colors' (Namhyung)
- add struct default_config_section
- split first patch[PATCH 1/7] as two
- remove perf_default_config_init() at perf.c
- rebased on current acme/perf/core

v3:
- remove default config arrays for the rest sections except 'colors' and 
'annotate'
- use combined {fore, back}ground colors instead of each two color
- introduce perf_default_config_init() that call all default_*_config_init()
   for each config section

v2:
- rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' (Arnaldo)
- change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
- use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)

Taeung Song (7):
   perf config: Introduce default_config_section and default_config_item
 for default config key-value pairs
   perf config: Add macros assigning key-value pairs to
 default_config_item
   perf config: Add 'colors' section default configs arrrays
   perf config: Use combined {fore,back}ground colors value instead of
 each two color
   perf config: Initialize ui_browser__colorsets with default config
 items
   perf config: Add 'annotate' section default configs arrrays
   perf config: Initialize annotate_browser__opts with default config
 items

  tools/perf/ui/browser.c   | 64 +-
  tools/perf/ui/browsers/annotate.c | 16 ++--
  tools/perf/util/config.c  | 26 +
  tools/perf/util/config.h  | 82 +++
  4 files changed, 156 insertions(+), 32 deletions(-)

Re: [PATCH 4.6 00/31] 4.6.4-stable review

[Kevin Hilman]

Guenter Roeck  writes:

> On Mon, Jul 11, 2016 at 01:04:35PM -0700, Kevin Hilman wrote:
>> kernelci.org bot  writes:
>> 
>> > stable-rc boot: 558 boots: 4 failed, 549 passed with 5 offline 
>> > (v4.6.2-121-g6b5d7d0432d9)
>> >
>> > Full Boot Summary: 
>> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.6.2-121-g6b5d7d0432d9/
>> > Full Build Summary: 
>> > https://kernelci.org/build/stable-rc/kernel/v4.6.2-121-g6b5d7d0432d9/
>> >
>> > Tree: stable-rc
>> > Branch: local/linux-4.6.y
>> > Git Describe: v4.6.2-121-g6b5d7d0432d9
>> > Git Commit: 6b5d7d0432d9fe4c69436a289f96cce81ab00c1d
>> > Git URL: 
>> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> > Tested: 100 unique boards, 25 SoC families, 36 builds out of 140
>> >
>> > Boot Failures Detected: 
>> > https://kernelci.org/boot/?v4.6.2-121-g6b5d7d0432d9
>> >
>> > arm64:
>> >
>> > defconfig:
>> > apm-mustang-kvm-guest: 1 failed lab
>> > apm-mustang-kvm-uefi-guest: 1 failed lab
>> > juno-kvm-guest: 1 failed lab
>> > juno-kvm-uefi-guest: 1 failed lab
>> 
>> All is well.
>> 
>> These KVM failures are due to a QEMU upgrade, and are not related to the
>> kernel.
>
> Are you also having trouble with the latest version of qemu ?
>

I wasn't the one looking into this, so I don't know the details.  I
think it was a broader issue with upgrading the rootfs, but not having a
new enough QEMU.  I'll look into it a little closer and let you knwo if
it's a problem with the latest QEMU.

Kevin

Re: [PATCH 4.6 00/31] 4.6.4-stable review

[Kevin Hilman]

Guenter Roeck  writes:

> On Mon, Jul 11, 2016 at 01:04:35PM -0700, Kevin Hilman wrote:
>> kernelci.org bot  writes:
>> 
>> > stable-rc boot: 558 boots: 4 failed, 549 passed with 5 offline 
>> > (v4.6.2-121-g6b5d7d0432d9)
>> >
>> > Full Boot Summary: 
>> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.6.2-121-g6b5d7d0432d9/
>> > Full Build Summary: 
>> > https://kernelci.org/build/stable-rc/kernel/v4.6.2-121-g6b5d7d0432d9/
>> >
>> > Tree: stable-rc
>> > Branch: local/linux-4.6.y
>> > Git Describe: v4.6.2-121-g6b5d7d0432d9
>> > Git Commit: 6b5d7d0432d9fe4c69436a289f96cce81ab00c1d
>> > Git URL: 
>> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> > Tested: 100 unique boards, 25 SoC families, 36 builds out of 140
>> >
>> > Boot Failures Detected: 
>> > https://kernelci.org/boot/?v4.6.2-121-g6b5d7d0432d9
>> >
>> > arm64:
>> >
>> > defconfig:
>> > apm-mustang-kvm-guest: 1 failed lab
>> > apm-mustang-kvm-uefi-guest: 1 failed lab
>> > juno-kvm-guest: 1 failed lab
>> > juno-kvm-uefi-guest: 1 failed lab
>> 
>> All is well.
>> 
>> These KVM failures are due to a QEMU upgrade, and are not related to the
>> kernel.
>
> Are you also having trouble with the latest version of qemu ?
>

I wasn't the one looking into this, so I don't know the details.  I
think it was a broader issue with upgrading the rootfs, but not having a
new enough QEMU.  I'll look into it a little closer and let you knwo if
it's a problem with the latest QEMU.

Kevin

Re: [PATCH v2 0/4] implement vcpu preempted check

[Juergen Gross]

On 11/07/16 17:10, Waiman Long wrote:
> On 07/06/2016 02:52 AM, Peter Zijlstra wrote:
>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote:
>>> change fomr v1:
>>> a simplier definition of default vcpu_is_preempted
>>> skip mahcine type check on ppc, and add config. remove dedicated
>>> macro.
>>> add one patch to drop overload of rwsem_spin_on_owner and
>>> mutex_spin_on_owner.
>>> add more comments
>>> thanks boqun and Peter's suggestion.
>>>
>>> This patch set aims to fix lock holder preemption issues.
>>>
>>> test-case:
>>> perf record -a perf bench sched messaging -g 400 -p&&  perf report
>>>
>>> 18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
>>> 12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
>>>   5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
>>>   3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
>>>   3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
>>>   3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
>>>   2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call
>>>
>>> We introduce interface bool vcpu_is_preempted(int cpu) and use it in
>>> some spin
>>> loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
>>> These spin_on_onwer variant also cause rcu stall before we apply this
>>> patch set
>>>
>> Paolo, could you help out with an (x86) KVM interface for this?
>>
>> Waiman, could you see if you can utilize this to get rid of the
>> SPIN_THRESHOLD in qspinlock_paravirt?
> 
> That API is certainly useful to make the paravirt spinlock perform
> better. However, I am not sure if we can completely get rid of the
> SPIN_THRESHOLD at this point. It is not just the kvm, the xen code need
> to be modified as well.

This should be rather easy. The relevant information is included in the
runstate data mapped into kernel memory. I can provide a patch for Xen
if needed.


Juergen

Re: [PATCH v2 0/4] implement vcpu preempted check

[Juergen Gross]

On 11/07/16 17:10, Waiman Long wrote:
> On 07/06/2016 02:52 AM, Peter Zijlstra wrote:
>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote:
>>> change fomr v1:
>>> a simplier definition of default vcpu_is_preempted
>>> skip mahcine type check on ppc, and add config. remove dedicated
>>> macro.
>>> add one patch to drop overload of rwsem_spin_on_owner and
>>> mutex_spin_on_owner.
>>> add more comments
>>> thanks boqun and Peter's suggestion.
>>>
>>> This patch set aims to fix lock holder preemption issues.
>>>
>>> test-case:
>>> perf record -a perf bench sched messaging -g 400 -p&&  perf report
>>>
>>> 18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
>>> 12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
>>>   5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
>>>   3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
>>>   3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
>>>   3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
>>>   2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call
>>>
>>> We introduce interface bool vcpu_is_preempted(int cpu) and use it in
>>> some spin
>>> loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
>>> These spin_on_onwer variant also cause rcu stall before we apply this
>>> patch set
>>>
>> Paolo, could you help out with an (x86) KVM interface for this?
>>
>> Waiman, could you see if you can utilize this to get rid of the
>> SPIN_THRESHOLD in qspinlock_paravirt?
> 
> That API is certainly useful to make the paravirt spinlock perform
> better. However, I am not sure if we can completely get rid of the
> SPIN_THRESHOLD at this point. It is not just the kvm, the xen code need
> to be modified as well.

This should be rather easy. The relevant information is included in the
runstate data mapped into kernel memory. I can provide a patch for Xen
if needed.


Juergen

RE: [PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0 controller

[Rajesh Bhagat]

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, July 11, 2016 12:19 PM
> To: Rajesh Bhagat 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Peter Chen ;
> gre...@linuxfoundation.org; kis...@ti.com; robh...@kernel.org;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0
> controller
> 
> On Sat, Jul 09, 2016 at 10:00:53AM +0530, Rajesh Bhagat wrote:
> > Describes the qoriq usb 2.0 controller driver binding, currently used
> > for LS1021A and LS1012A platform.
> >
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v2:
> >  - Adds DT binding documentation for qoriq usb 2.0 controller
> >  - Changed the compatible string to fsl,ci-qoriq-usb2
> >
> >  .../devicetree/bindings/usb/ci-hdrc-qoriq.txt  | 34
> ++
> >  1 file changed, 34 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> > b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> > new file mode 100644
> > index 000..8ad7306
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> > @@ -0,0 +1,34 @@
> > +* Freescale QorIQ SoC USB 2.0 Controllers
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,ci-qoriq-usb2"
> > +  Wherever applicable, the IP version of the USB controller should
> > +  also be mentioned (for eg. fsl,ci-qoriq-usb2-vX.Y).
> > +  where, X.Y is IP version of USB controller.

Hello Peter, 

> 
> Why you need to add IP version at compatible string?
> Does it can't be read out from ID register of Identification Registers.
> 

I agree. Will drop this controller version thing in DTS in v3.

> > +- reg: Should contain registers location and length
> > +- interrupts: Should contain controller interrupt
> > +- phy-names: from the *Generic PHY* bindings
> > +- phys: from the *Generic PHY* bindings
> > +- clocks: clock provider specifier
> > +- clock-names: shall be "usb2-clock"
> > +Refer to clk/clock-bindings.txt for generic clock consumer properties
> > +
> > +Recommended properties:
> > +- dr_mode: One of "host" or "peripheral".
> 
> Do you support dual-role?
> 

Yes. We do support  both host/peripheral mode. 


Best Regards,
Rajesh Bhagat 

> > +- phy_type: the type of the phy connected to the core. Should be one
> > +  of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
> > +  property the PORTSC register won't be touched
> > +
> > +Examples:
> > +usb@860 {
> > +   compatible =  "fsl,ci-qoriq-usb2",
> > + "fsl,ci-qoriq-usb2-v2.5";
> > +   reg = <0x0 0x860 0x0 0x1000>;
> > +   interrupts = <0 139 0x4>;
> > +   phy-names = "usb2-phy";
> > +   phys = <>;
> > +   clock-names = "usb2-clock";
> > +   clocks = < 4 3>;
> > +   dr_mode = "host";
> > +   phy_type = "ulpi";
> > +};
> > --
> > 2.6.2.198.g614a2ac
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> 
> Best Regards,
> Peter Chen

RE: [PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0 controller

[Rajesh Bhagat]

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, July 11, 2016 12:19 PM
> To: Rajesh Bhagat 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Peter Chen ;
> gre...@linuxfoundation.org; kis...@ti.com; robh...@kernel.org;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0
> controller
> 
> On Sat, Jul 09, 2016 at 10:00:53AM +0530, Rajesh Bhagat wrote:
> > Describes the qoriq usb 2.0 controller driver binding, currently used
> > for LS1021A and LS1012A platform.
> >
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v2:
> >  - Adds DT binding documentation for qoriq usb 2.0 controller
> >  - Changed the compatible string to fsl,ci-qoriq-usb2
> >
> >  .../devicetree/bindings/usb/ci-hdrc-qoriq.txt  | 34
> ++
> >  1 file changed, 34 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> > b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> > new file mode 100644
> > index 000..8ad7306
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> > @@ -0,0 +1,34 @@
> > +* Freescale QorIQ SoC USB 2.0 Controllers
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,ci-qoriq-usb2"
> > +  Wherever applicable, the IP version of the USB controller should
> > +  also be mentioned (for eg. fsl,ci-qoriq-usb2-vX.Y).
> > +  where, X.Y is IP version of USB controller.

Hello Peter, 

> 
> Why you need to add IP version at compatible string?
> Does it can't be read out from ID register of Identification Registers.
> 

I agree. Will drop this controller version thing in DTS in v3.

> > +- reg: Should contain registers location and length
> > +- interrupts: Should contain controller interrupt
> > +- phy-names: from the *Generic PHY* bindings
> > +- phys: from the *Generic PHY* bindings
> > +- clocks: clock provider specifier
> > +- clock-names: shall be "usb2-clock"
> > +Refer to clk/clock-bindings.txt for generic clock consumer properties
> > +
> > +Recommended properties:
> > +- dr_mode: One of "host" or "peripheral".
> 
> Do you support dual-role?
> 

Yes. We do support  both host/peripheral mode. 


Best Regards,
Rajesh Bhagat 

> > +- phy_type: the type of the phy connected to the core. Should be one
> > +  of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
> > +  property the PORTSC register won't be touched
> > +
> > +Examples:
> > +usb@860 {
> > +   compatible =  "fsl,ci-qoriq-usb2",
> > + "fsl,ci-qoriq-usb2-v2.5";
> > +   reg = <0x0 0x860 0x0 0x1000>;
> > +   interrupts = <0 139 0x4>;
> > +   phy-names = "usb2-phy";
> > +   phys = <>;
> > +   clock-names = "usb2-clock";
> > +   clocks = < 4 3>;
> > +   dr_mode = "host";
> > +   phy_type = "ulpi";
> > +};
> > --
> > 2.6.2.198.g614a2ac
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> 
> Best Regards,
> Peter Chen

RE: [PATCH v2 3/5] drivers: usb: phy: Add qoriq usb 2.0 phy driver support

[Rajesh Bhagat]

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, July 11, 2016 12:24 PM
> To: Rajesh Bhagat 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Peter Chen ;
> gre...@linuxfoundation.org; kis...@ti.com; robh...@kernel.org;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 3/5] drivers: usb: phy: Add qoriq usb 2.0 phy driver 
> support
> 
> On Sat, Jul 09, 2016 at 10:00:54AM +0530, Rajesh Bhagat wrote:
> > Adds qoriq usb 2.0 phy driver support for LS1021A and LS1012A
> > platform.
> >
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v2:
> >  - Replaced Freescale with QorIQ in comments section
> >  - Changed the compatible string to fsl,qoriq-usb2-phy and added
> > version
> >  - Added dependency on ARCH_MXC/ARCH_LAYERSCAPE and OF in Kconfig
> >  - Dropped CONFIG_ULPI #ifdefs to make code generic
> >  - Removed calls to devm free/release calls
> >
> >  drivers/phy/Kconfig  |   8 ++
> >  drivers/phy/Makefile |   1 +
> >  drivers/phy/phy-qoriq-usb2.c | 228
> > +++
> >  drivers/phy/phy-qoriq-usb2.h |  50 ++
> >  4 files changed, 287 insertions(+)
> >  create mode 100644 drivers/phy/phy-qoriq-usb2.c  create mode 100644
> > drivers/phy/phy-qoriq-usb2.h
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> > b869b98..cc69299 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -434,4 +434,12 @@ config PHY_CYGNUS_PCIE
> >
> >  source "drivers/phy/tegra/Kconfig"
> >
> > +config PHY_QORIQ_USB2
> > +   tristate "QorIQ USB 2.0 PHY driver"
> > +   depends on ARCH_MXC || ARCH_LAYERSCAPE
> 

Hello Peter,

> It seems mxc platforms do not use this PHY.
> Besides, if you are using ULPI phy, you need to depend on ULPI bus.
> 

QorIQ platform are having both ULPI and non-ULPI PHY variants, Hence
this PHY driver is targeted for both. And driver takes decision on run time 
which PHY is there according to information passed in DTS files. 


Best Regards,
Rajesh Bhagat 

> Peter
> > +   depends on OF
> > +   select GENERIC_PHY
> > +   help
> > + Enable this to support the USB2.0 PHY on the QorIQ SoC.
> > +
> >  endmenu
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> > 9c3e73c..044105a 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -53,5 +53,6 @@ obj-$(CONFIG_PHY_TUSB1210)+= 
> > phy-tusb1210.o
> >  obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
> >  obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
> >  obj-$(CONFIG_PHY_CYGNUS_PCIE)  += phy-bcm-cygnus-pcie.o
> > +obj-$(CONFIG_PHY_QORIQ_USB2)+= phy-qoriq-usb2.o
> >
> >  obj-$(CONFIG_ARCH_TEGRA) += tegra/
> > diff --git a/drivers/phy/phy-qoriq-usb2.c
> > b/drivers/phy/phy-qoriq-usb2.c new file mode 100644 index
> > 000..f74d255
> > --- /dev/null
> > +++ b/drivers/phy/phy-qoriq-usb2.c
> > @@ -0,0 +1,228 @@
> > +/*
> > + * QorIQ SoC USB 2.0 PHY driver
> > + *
> > + * Copyright 2016 Freescale Semiconductor, Inc.
> > + * Author: Rajesh Bhagat 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "phy-qoriq-usb2.h"
> > +
> > +static int qoriq_usb2_phy_init(struct phy *_phy) {
> > +   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
> > +   struct device *dev = ctx->dev;
> > +
> > +   if (ctx->ulpi_phy) {
> > +   if (usb_phy_init(ctx->ulpi_phy)) {
> > +   dev_err(dev, "unable to init transceiver, probably 
> > missing\n");
> > +   return -ENODEV;
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int qoriq_usb2_phy_power_on(struct phy *_phy) {
> > +   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
> > +   u32 flags;
> > +
> > +   if (ctx->ulpi_phy) {
> > +   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_OTG_CTRL);
> > +   usb_phy_io_write(ctx->ulpi_phy, flags |
> > +(ULPI_OTG_CTRL_DRVVBUS_EXT |
> > +ULPI_OTG_CTRL_EXTVBUSIND), ULPI_OTG_CTRL);
> > +   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_IFC_CTRL);
> > +   usb_phy_io_write(ctx->ulpi_phy, flags |
> > +(ULPI_IFC_CTRL_EXTERNAL_VBUS |
> > +ULPI_IFC_CTRL_PASSTHRU), ULPI_IFC_CTRL);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int qoriq_usb2_phy_power_off(struct 

RE: [PATCH v2 3/5] drivers: usb: phy: Add qoriq usb 2.0 phy driver support

[Rajesh Bhagat]

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, July 11, 2016 12:24 PM
> To: Rajesh Bhagat 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Peter Chen ;
> gre...@linuxfoundation.org; kis...@ti.com; robh...@kernel.org;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 3/5] drivers: usb: phy: Add qoriq usb 2.0 phy driver 
> support
> 
> On Sat, Jul 09, 2016 at 10:00:54AM +0530, Rajesh Bhagat wrote:
> > Adds qoriq usb 2.0 phy driver support for LS1021A and LS1012A
> > platform.
> >
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v2:
> >  - Replaced Freescale with QorIQ in comments section
> >  - Changed the compatible string to fsl,qoriq-usb2-phy and added
> > version
> >  - Added dependency on ARCH_MXC/ARCH_LAYERSCAPE and OF in Kconfig
> >  - Dropped CONFIG_ULPI #ifdefs to make code generic
> >  - Removed calls to devm free/release calls
> >
> >  drivers/phy/Kconfig  |   8 ++
> >  drivers/phy/Makefile |   1 +
> >  drivers/phy/phy-qoriq-usb2.c | 228
> > +++
> >  drivers/phy/phy-qoriq-usb2.h |  50 ++
> >  4 files changed, 287 insertions(+)
> >  create mode 100644 drivers/phy/phy-qoriq-usb2.c  create mode 100644
> > drivers/phy/phy-qoriq-usb2.h
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> > b869b98..cc69299 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -434,4 +434,12 @@ config PHY_CYGNUS_PCIE
> >
> >  source "drivers/phy/tegra/Kconfig"
> >
> > +config PHY_QORIQ_USB2
> > +   tristate "QorIQ USB 2.0 PHY driver"
> > +   depends on ARCH_MXC || ARCH_LAYERSCAPE
> 

Hello Peter,

> It seems mxc platforms do not use this PHY.
> Besides, if you are using ULPI phy, you need to depend on ULPI bus.
> 

QorIQ platform are having both ULPI and non-ULPI PHY variants, Hence
this PHY driver is targeted for both. And driver takes decision on run time 
which PHY is there according to information passed in DTS files. 


Best Regards,
Rajesh Bhagat 

> Peter
> > +   depends on OF
> > +   select GENERIC_PHY
> > +   help
> > + Enable this to support the USB2.0 PHY on the QorIQ SoC.
> > +
> >  endmenu
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> > 9c3e73c..044105a 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -53,5 +53,6 @@ obj-$(CONFIG_PHY_TUSB1210)+= 
> > phy-tusb1210.o
> >  obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
> >  obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
> >  obj-$(CONFIG_PHY_CYGNUS_PCIE)  += phy-bcm-cygnus-pcie.o
> > +obj-$(CONFIG_PHY_QORIQ_USB2)+= phy-qoriq-usb2.o
> >
> >  obj-$(CONFIG_ARCH_TEGRA) += tegra/
> > diff --git a/drivers/phy/phy-qoriq-usb2.c
> > b/drivers/phy/phy-qoriq-usb2.c new file mode 100644 index
> > 000..f74d255
> > --- /dev/null
> > +++ b/drivers/phy/phy-qoriq-usb2.c
> > @@ -0,0 +1,228 @@
> > +/*
> > + * QorIQ SoC USB 2.0 PHY driver
> > + *
> > + * Copyright 2016 Freescale Semiconductor, Inc.
> > + * Author: Rajesh Bhagat 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "phy-qoriq-usb2.h"
> > +
> > +static int qoriq_usb2_phy_init(struct phy *_phy) {
> > +   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
> > +   struct device *dev = ctx->dev;
> > +
> > +   if (ctx->ulpi_phy) {
> > +   if (usb_phy_init(ctx->ulpi_phy)) {
> > +   dev_err(dev, "unable to init transceiver, probably 
> > missing\n");
> > +   return -ENODEV;
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int qoriq_usb2_phy_power_on(struct phy *_phy) {
> > +   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
> > +   u32 flags;
> > +
> > +   if (ctx->ulpi_phy) {
> > +   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_OTG_CTRL);
> > +   usb_phy_io_write(ctx->ulpi_phy, flags |
> > +(ULPI_OTG_CTRL_DRVVBUS_EXT |
> > +ULPI_OTG_CTRL_EXTVBUSIND), ULPI_OTG_CTRL);
> > +   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_IFC_CTRL);
> > +   usb_phy_io_write(ctx->ulpi_phy, flags |
> > +(ULPI_IFC_CTRL_EXTERNAL_VBUS |
> > +ULPI_IFC_CTRL_PASSTHRU), ULPI_IFC_CTRL);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int qoriq_usb2_phy_power_off(struct phy *_phy) {
> > +   /* TODO: Add logic to power off phy */
> > +
> > +   return 0;
> > 

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

[Kevin Hilman]

Guenter Roeck  writes:

> On 07/10/2016 02:11 AM, Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong 
>
> Reviewed-by: Guenter Roeck 
>
> Would this go in through one of the arm trees ?

You can take the driver through the watchdog tree, but I'll take the DT
stuff through the amlogic tree (and submit via arm-soc).  

However, with your ack, and since this is a brand new driver, I could
take the driver as well.  Just let me know your preference.

Thanks,

Kevin

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

[Kevin Hilman]

Guenter Roeck  writes:

> On 07/10/2016 02:11 AM, Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong 
>
> Reviewed-by: Guenter Roeck 
>
> Would this go in through one of the arm trees ?

You can take the driver through the watchdog tree, but I'll take the DT
stuff through the amlogic tree (and submit via arm-soc).  

However, with your ack, and since this is a brand new driver, I could
take the driver as well.  Just let me know your preference.

Thanks,

Kevin

linux-next: manual merge of the xen-tip tree with the pm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  drivers/acpi/scan.c

between commit:

  68bdb6773289 ("ACPI: add support for ACPI reconfiguration notifiers")

from the pm tree and commit:

  c8ac8b6fb495 ("Xen: ACPI: Hide UART used by Xen")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/acpi/scan.c
index 405056b95b05,cfc73fecaba4..
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@@ -1925,8 -1961,19 +1970,21 @@@ static int acpi_bus_scan_fixed(void
return result < 0 ? result : 0;
  }
  
+ static void __init acpi_get_spcr_uart_addr(void)
+ {
+   acpi_status status;
+   struct acpi_table_spcr *spcr_ptr;
+ 
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
missing\n");
+ }
+ 
 +static bool acpi_scan_initialized;
 +
  int __init acpi_scan_init(void)
  {
int result;

linux-next: manual merge of the xen-tip tree with the pm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  drivers/acpi/scan.c

between commit:

  68bdb6773289 ("ACPI: add support for ACPI reconfiguration notifiers")

from the pm tree and commit:

  c8ac8b6fb495 ("Xen: ACPI: Hide UART used by Xen")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/acpi/scan.c
index 405056b95b05,cfc73fecaba4..
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@@ -1925,8 -1961,19 +1970,21 @@@ static int acpi_bus_scan_fixed(void
return result < 0 ? result : 0;
  }
  
+ static void __init acpi_get_spcr_uart_addr(void)
+ {
+   acpi_status status;
+   struct acpi_table_spcr *spcr_ptr;
+ 
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
missing\n");
+ }
+ 
 +static bool acpi_scan_initialized;
 +
  int __init acpi_scan_init(void)
  {
int result;

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[河合英宏 / KAWAI，HIDEHIRO]

Hi Xunlei,

Thanks for the review.

> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, July 12, 2016 12:12 PM
> On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If crash_kexec_post_notifiers boot option is specified, other CPUs
> > are stopped by smp_send_stop() instead of machine_crash_shutdown()
> > in crash_kexec() path.  This behavior change leads two problems.
> >
> >  Problem 1:
> >  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are
> >  still online and try to stop their watchdog timer.  If
> >  smp_send_stop() is called before octeon_generic_shutdown(), stopping
> >  watchdog timer will fail because other CPUs have been offlined by
> >  smp_send_stop().
> >
> >panic()
> >  if crash_kexec_post_notifiers == 1
> >smp_send_stop()
> >atomic_notifier_call_chain()
> >kmsg_dump()
> >  crash_kexec()
> >machine_crash_shutdown()
> >  octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs
> >
> >  Problem 2:
> >  Most of architectures stop other CPUs in machine_crash_shutdown()
> >  path, and they also do something needed for kdump.  For example,
> >  they save registers, disable virtualization extensions, and so on.
> >  However, if smp_send_stop() stops other CPUs before
> >  machine_crash_shutdown(), we miss those operations.
> >
> > How do we fix these problems?  In the first place, we should stop
> > other CPUs as soon as possible when panic() was called, otherwise
> > other CPUs may wipe out a clue to the cause of the failure.  So, we
> > replace smp_send_stop() with more suitable one for kdump.
> >
> > This patch solves Problem 2 by replacing smp_send_stop() in panic()
> > with panic_smp_send_stop().  This is a weak function which calls
> > smp_send_stop(), and architecture dependent code may override this
> > with appropriate one.  This patch only provides x86-specific version.
> >
> > Changes in V3:
> > - Revise comments, description, and symbol names
> >
> > Changes in V2:
> > - Replace smp_send_stop() call with crash_kexec version which
> >   saves cpu states and cleans up VMX/SVM
> > - Drop a fix for Problem 1 at this moment
> >
> > Reported-by: Daniel Walker 
> > Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" 
> > option)
> > Signed-off-by: Hidehiro Kawai 
> > Cc: Dave Young 
> > Cc: Baoquan He 
> > Cc: Vivek Goyal 
> > Cc: Eric Biederman 
> > Cc: Masami Hiramatsu 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: Borislav Petkov 
> > Cc: Toshi Kani 
> > Cc: "Peter Zijlstra (Intel)" 
> > Cc: Takao Indoh 
> > Cc: "Lee, Chun-Yi" 
> > Cc: Minfei Huang 
> > Cc: Andrew Morton 
> > Cc: Michal Hocko 
> > Cc: Vitaly Kuznetsov 
> > Cc: Petr Mladek 
> > Cc: Tejun Heo 
> > Cc: Josh Poimboeuf 
> > ---
> >  arch/x86/kernel/crash.c |   14 ++
> >  kernel/panic.c  |   43 ---
> >  2 files changed, 42 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> > index 9ef978d..3305433 100644
> > --- a/arch/x86/kernel/crash.c
> > +++ b/arch/x86/kernel/crash.c
> > @@ -133,15 +133,21 @@ static void kdump_nmi_callback(int cpu, struct 
> > pt_regs *regs)
> > disable_local_APIC();
> >  }
> >
> > -static void kdump_nmi_shootdown_cpus(void)
> > +/* Override the weak function in kernel/panic.c */
> > +void panic_smp_send_stop(void)
> >  {
> > -   nmi_shootdown_cpus(kdump_nmi_callback);
> > +   static int cpus_stopped;
> 
> Should be atomic_t type?

panic_smp_send_stop() can be called by only one panicking CPU
(but can be called twice). It is sufficient to be normal variable.

> > +
> > +   if (cpus_stopped)
> > +   return;
> >
> > +   nmi_shootdown_cpus(kdump_nmi_callback);
> > disable_local_APIC();
> > +   cpus_stopped = 1;
> >  }
> >
> >  #else
> > -static void kdump_nmi_shootdown_cpus(void)
> > +void panic_smp_send_stop(void)
> >  {
> > /* There are no cpus to shootdown */
> >  }
> > @@ -160,7 +166,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> > /* The kernel is broken so disable interrupts */
> > local_irq_disable();
> >
> > -   kdump_nmi_shootdown_cpus();
> > +   panic_smp_send_stop();
> >
> > /*
> >  * VMCLEAR VMCSs loaded on this cpu if needed.
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 8aa7449..da8062d2 100644
> > --- a/kernel/panic.c
> > +++ 

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[河合英宏 / KAWAI，HIDEHIRO]

Hi Xunlei,

Thanks for the review.

> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, July 12, 2016 12:12 PM
> On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If crash_kexec_post_notifiers boot option is specified, other CPUs
> > are stopped by smp_send_stop() instead of machine_crash_shutdown()
> > in crash_kexec() path.  This behavior change leads two problems.
> >
> >  Problem 1:
> >  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are
> >  still online and try to stop their watchdog timer.  If
> >  smp_send_stop() is called before octeon_generic_shutdown(), stopping
> >  watchdog timer will fail because other CPUs have been offlined by
> >  smp_send_stop().
> >
> >panic()
> >  if crash_kexec_post_notifiers == 1
> >smp_send_stop()
> >atomic_notifier_call_chain()
> >kmsg_dump()
> >  crash_kexec()
> >machine_crash_shutdown()
> >  octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs
> >
> >  Problem 2:
> >  Most of architectures stop other CPUs in machine_crash_shutdown()
> >  path, and they also do something needed for kdump.  For example,
> >  they save registers, disable virtualization extensions, and so on.
> >  However, if smp_send_stop() stops other CPUs before
> >  machine_crash_shutdown(), we miss those operations.
> >
> > How do we fix these problems?  In the first place, we should stop
> > other CPUs as soon as possible when panic() was called, otherwise
> > other CPUs may wipe out a clue to the cause of the failure.  So, we
> > replace smp_send_stop() with more suitable one for kdump.
> >
> > This patch solves Problem 2 by replacing smp_send_stop() in panic()
> > with panic_smp_send_stop().  This is a weak function which calls
> > smp_send_stop(), and architecture dependent code may override this
> > with appropriate one.  This patch only provides x86-specific version.
> >
> > Changes in V3:
> > - Revise comments, description, and symbol names
> >
> > Changes in V2:
> > - Replace smp_send_stop() call with crash_kexec version which
> >   saves cpu states and cleans up VMX/SVM
> > - Drop a fix for Problem 1 at this moment
> >
> > Reported-by: Daniel Walker 
> > Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" 
> > option)
> > Signed-off-by: Hidehiro Kawai 
> > Cc: Dave Young 
> > Cc: Baoquan He 
> > Cc: Vivek Goyal 
> > Cc: Eric Biederman 
> > Cc: Masami Hiramatsu 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: Borislav Petkov 
> > Cc: Toshi Kani 
> > Cc: "Peter Zijlstra (Intel)" 
> > Cc: Takao Indoh 
> > Cc: "Lee, Chun-Yi" 
> > Cc: Minfei Huang 
> > Cc: Andrew Morton 
> > Cc: Michal Hocko 
> > Cc: Vitaly Kuznetsov 
> > Cc: Petr Mladek 
> > Cc: Tejun Heo 
> > Cc: Josh Poimboeuf 
> > ---
> >  arch/x86/kernel/crash.c |   14 ++
> >  kernel/panic.c  |   43 ---
> >  2 files changed, 42 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> > index 9ef978d..3305433 100644
> > --- a/arch/x86/kernel/crash.c
> > +++ b/arch/x86/kernel/crash.c
> > @@ -133,15 +133,21 @@ static void kdump_nmi_callback(int cpu, struct 
> > pt_regs *regs)
> > disable_local_APIC();
> >  }
> >
> > -static void kdump_nmi_shootdown_cpus(void)
> > +/* Override the weak function in kernel/panic.c */
> > +void panic_smp_send_stop(void)
> >  {
> > -   nmi_shootdown_cpus(kdump_nmi_callback);
> > +   static int cpus_stopped;
> 
> Should be atomic_t type?

panic_smp_send_stop() can be called by only one panicking CPU
(but can be called twice). It is sufficient to be normal variable.

> > +
> > +   if (cpus_stopped)
> > +   return;
> >
> > +   nmi_shootdown_cpus(kdump_nmi_callback);
> > disable_local_APIC();
> > +   cpus_stopped = 1;
> >  }
> >
> >  #else
> > -static void kdump_nmi_shootdown_cpus(void)
> > +void panic_smp_send_stop(void)
> >  {
> > /* There are no cpus to shootdown */
> >  }
> > @@ -160,7 +166,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> > /* The kernel is broken so disable interrupts */
> > local_irq_disable();
> >
> > -   kdump_nmi_shootdown_cpus();
> > +   panic_smp_send_stop();
> >
> > /*
> >  * VMCLEAR VMCSs loaded on this cpu if needed.
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 8aa7449..da8062d2 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -71,6 +71,32 @@ void __weak nmi_panic_self_stop(struct pt_regs *regs)
> > panic_smp_self_stop();
> >  }
> >
> > +/*
> > + * Stop other CPUs in panic.  Architecture dependent code may override this
> > + * with more suitable version.  For example, if the architecture supports
> > + * crash dump, it should save registers of each stopped CPU and disable
> > + * per-CPU features such as virtualization extensions.
> > + */
> > 

[PATCH] irqchip/gicv3-its: Enable cacheable attribute Read-allocate hints

[Shanker Donthineni]

Read-allocation hints are not enabled for both the GIC-ITS and GICR
tables. This forces the hardware to always read the table contents
from an external memory (DDR) which is slow compared to cache memory.
Most of the tables are often read by hardware. So, it's better to
enable Read-allocate hints in addition to Write-allocate hints in
order to improve the GICR_PEND, GICR_PROP, Collection, Device, and
vCPU tables lookup time.

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 7ceaba8..6fc92a8 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -954,7 +954,7 @@ static bool its_parse_baser_device(struct its_node *its, 
struct its_baser *baser
   u32 psz, u32 *order)
 {
u64 esz = GITS_BASER_ENTRY_SIZE(its_read_baser(its, baser));
-   u64 val = GITS_BASER_InnerShareable | GITS_BASER_WaWb;
+   u64 val = GITS_BASER_InnerShareable | GITS_BASER_RaWaWb;
u32 ids = its->device_ids;
u32 new_order = *order;
bool indirect = false;
@@ -1019,7 +1019,7 @@ static int its_alloc_tables(struct its_node *its)
u64 typer = readq_relaxed(its->base + GITS_TYPER);
u32 ids = GITS_TYPER_DEVBITS(typer);
u64 shr = GITS_BASER_InnerShareable;
-   u64 cache = GITS_BASER_WaWb;
+   u64 cache = GITS_BASER_RaWaWb;
u32 psz = SZ_64K;
int err, i;
 
@@ -1116,7 +1116,7 @@ static void its_cpu_init_lpis(void)
/* set PROPBASE */
val = (page_to_phys(gic_rdists->prop_page) |
   GICR_PROPBASER_InnerShareable |
-  GICR_PROPBASER_WaWb |
+  GICR_PROPBASER_RaWaWb |
   ((LPI_NRBITS - 1) & GICR_PROPBASER_IDBITS_MASK));
 
writeq_relaxed(val, rbase + GICR_PROPBASER);
@@ -1141,7 +1141,7 @@ static void its_cpu_init_lpis(void)
/* set PENDBASE */
val = (page_to_phys(pend_page) |
   GICR_PENDBASER_InnerShareable |
-  GICR_PENDBASER_WaWb);
+  GICR_PENDBASER_RaWaWb);
 
writeq_relaxed(val, rbase + GICR_PENDBASER);
tmp = readq_relaxed(rbase + GICR_PENDBASER);
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH] irqchip/gicv3-its: Enable cacheable attribute Read-allocate hints

[Shanker Donthineni]

Read-allocation hints are not enabled for both the GIC-ITS and GICR
tables. This forces the hardware to always read the table contents
from an external memory (DDR) which is slow compared to cache memory.
Most of the tables are often read by hardware. So, it's better to
enable Read-allocate hints in addition to Write-allocate hints in
order to improve the GICR_PEND, GICR_PROP, Collection, Device, and
vCPU tables lookup time.

Signed-off-by: Shanker Donthineni 
---
 drivers/irqchip/irq-gic-v3-its.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 7ceaba8..6fc92a8 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -954,7 +954,7 @@ static bool its_parse_baser_device(struct its_node *its, 
struct its_baser *baser
   u32 psz, u32 *order)
 {
u64 esz = GITS_BASER_ENTRY_SIZE(its_read_baser(its, baser));
-   u64 val = GITS_BASER_InnerShareable | GITS_BASER_WaWb;
+   u64 val = GITS_BASER_InnerShareable | GITS_BASER_RaWaWb;
u32 ids = its->device_ids;
u32 new_order = *order;
bool indirect = false;
@@ -1019,7 +1019,7 @@ static int its_alloc_tables(struct its_node *its)
u64 typer = readq_relaxed(its->base + GITS_TYPER);
u32 ids = GITS_TYPER_DEVBITS(typer);
u64 shr = GITS_BASER_InnerShareable;
-   u64 cache = GITS_BASER_WaWb;
+   u64 cache = GITS_BASER_RaWaWb;
u32 psz = SZ_64K;
int err, i;
 
@@ -1116,7 +1116,7 @@ static void its_cpu_init_lpis(void)
/* set PROPBASE */
val = (page_to_phys(gic_rdists->prop_page) |
   GICR_PROPBASER_InnerShareable |
-  GICR_PROPBASER_WaWb |
+  GICR_PROPBASER_RaWaWb |
   ((LPI_NRBITS - 1) & GICR_PROPBASER_IDBITS_MASK));
 
writeq_relaxed(val, rbase + GICR_PROPBASER);
@@ -1141,7 +1141,7 @@ static void its_cpu_init_lpis(void)
/* set PENDBASE */
val = (page_to_phys(pend_page) |
   GICR_PENDBASER_InnerShareable |
-  GICR_PENDBASER_WaWb);
+  GICR_PENDBASER_RaWaWb);
 
writeq_relaxed(val, rbase + GICR_PENDBASER);
tmp = readq_relaxed(rbase + GICR_PENDBASER);
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH v7 1/4] soc: mediatek: Refine scpsys to support multiple platform

[James Liao]

Hi Matthias,

On Mon, 2016-07-11 at 15:10 +0200, Matthias Brugger wrote:
> 
> On 11/07/16 10:56, James Liao wrote:
> 
> [...]
> 
> > @@ -467,28 +386,54 @@ static int scpsys_probe(struct platform_device 
> > *pdev)
> > if (PTR_ERR(scpd->supply) == -ENODEV)
> > scpd->supply = NULL;
> > else
> > -   return PTR_ERR(scpd->supply);
> > +   return ERR_CAST(scpd->supply);
> > }
> > }
> >
> > -   pd_data->num_domains = NUM_DOMAINS;
> > +   pd_data->num_domains = num;
> >
> > -   for (i = 0; i < NUM_DOMAINS; i++) {
> > +   init_clks(pdev, clk);
> > +
> > +   for (i = 0; i < num; i++) {
> > struct scp_domain *scpd = >domains[i];
> > struct generic_pm_domain *genpd = >genpd;
> > const struct scp_domain_data *data = 
> > _domain_data[i];
> >
> > +   for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
> > +   struct clk *c = clk[data->clk_id[j]];
> > +
> > +   if (IS_ERR(c)) {
> > +   dev_err(>dev, "%s: clk 
> > unavailable\n",
> > +   data->name);
> > +   return ERR_CAST(c);
> > +   }
> > +
> > +   scpd->clk[j] = c;
> 
>  Put this in the else branch. Apart from that is there any reason you
> >>>
> >>> Do you mean to change like this?
> >>>
> >>>   if (IS_ERR(c)) {
> >>>   ...
> >>>   return ERR_CAST(c);
> >>>   } else {
> >>>   scpd->clk[j] = c;
> >>>   }
> >>>
> >>> checkpatch.pl will warn for above code due to it returns in 'if' branch.
> >>>
> >>
> >> I tried that on top of next-20160706 and it checkpatch didn't throw any
> >> warning. Which kernel version are based on?
> >
> > I don't remember which version of checkpatch warn on this pattern. This
> > patch series develop across several kernel versions.
> 
> We as the kernel community develop against master or linux-next. We only 
> care about older kernel version in the sense that we intent hard not to 
> break any userspace/kernel or firmware/kernel interfaces. Apart from 
> that it's up to every individual to backport patches from mainline 
> kernel to his respective version. But that's nothing the community as a 
> hole can take care of.
> 
> >
> > So do you prefer to put "scpd->clk[j] = c;" into 'else' branch?
> >
> 
> Yes please :)

Yingjoe had tested in the latest checkpatch.pl and it showed checkpatch
warn on the else-branch. He had replied the results in previous email.
 
>  moved the for up in the function? If not, I would prefer not to move it,
>  to make it easier to read the diff.
> >>>
> >>> The new 'for' block are far different from original one. And I think
> >>> it's easy to read if we keep simple assign statements in the same block.
> >>>
> >>
> >> It's different in the sense that it checks if struct clk *c is an error.
> >> I don't see the reason why we need to move it up in the file.
> >> It's not too important but I would prefer not to move it if there is no
> >> reason.
> >
> > I think I may misunderstand your comments. Which 'for' block did you
> > mention for? 'for (i = 0; i < num ...' or 'for (j = 0; j < MAX_CLKS
> > && ...' ?
> >
> > The 'for(i)' exists in original code, this patch just change its counter
> > from 'NUM_DOMAINS' to 'num'. The 'for(j)' is a new for-block, so it was
> > not moved from other blocks.
> >
> 
> for (j = 0; j < MAX_CLKS... is present in the actual scpsys_probe in 
> linux-next (line 485 as of today). This patch moves this for a few lines 
> up, to be precise before executing this code sequence:
> 
> pd_data->domains[i] = genpd;
> scpd->scp = scp;
> 
> scpd->data = data;
> 
> 
> AFAIK there is no reason to do so. It adds unnecessary complexity to the 
> patch. So please fix this together with the other comments you got.

I see. So you prefer to put the for(j < MAX_CLKS) after 'scpd->data =
data' right? I can change it in next patch.


Best regards,

James

Re: [PATCH v7 1/4] soc: mediatek: Refine scpsys to support multiple platform

[James Liao]

Hi Matthias,

On Mon, 2016-07-11 at 15:10 +0200, Matthias Brugger wrote:
> 
> On 11/07/16 10:56, James Liao wrote:
> 
> [...]
> 
> > @@ -467,28 +386,54 @@ static int scpsys_probe(struct platform_device 
> > *pdev)
> > if (PTR_ERR(scpd->supply) == -ENODEV)
> > scpd->supply = NULL;
> > else
> > -   return PTR_ERR(scpd->supply);
> > +   return ERR_CAST(scpd->supply);
> > }
> > }
> >
> > -   pd_data->num_domains = NUM_DOMAINS;
> > +   pd_data->num_domains = num;
> >
> > -   for (i = 0; i < NUM_DOMAINS; i++) {
> > +   init_clks(pdev, clk);
> > +
> > +   for (i = 0; i < num; i++) {
> > struct scp_domain *scpd = >domains[i];
> > struct generic_pm_domain *genpd = >genpd;
> > const struct scp_domain_data *data = 
> > _domain_data[i];
> >
> > +   for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
> > +   struct clk *c = clk[data->clk_id[j]];
> > +
> > +   if (IS_ERR(c)) {
> > +   dev_err(>dev, "%s: clk 
> > unavailable\n",
> > +   data->name);
> > +   return ERR_CAST(c);
> > +   }
> > +
> > +   scpd->clk[j] = c;
> 
>  Put this in the else branch. Apart from that is there any reason you
> >>>
> >>> Do you mean to change like this?
> >>>
> >>>   if (IS_ERR(c)) {
> >>>   ...
> >>>   return ERR_CAST(c);
> >>>   } else {
> >>>   scpd->clk[j] = c;
> >>>   }
> >>>
> >>> checkpatch.pl will warn for above code due to it returns in 'if' branch.
> >>>
> >>
> >> I tried that on top of next-20160706 and it checkpatch didn't throw any
> >> warning. Which kernel version are based on?
> >
> > I don't remember which version of checkpatch warn on this pattern. This
> > patch series develop across several kernel versions.
> 
> We as the kernel community develop against master or linux-next. We only 
> care about older kernel version in the sense that we intent hard not to 
> break any userspace/kernel or firmware/kernel interfaces. Apart from 
> that it's up to every individual to backport patches from mainline 
> kernel to his respective version. But that's nothing the community as a 
> hole can take care of.
> 
> >
> > So do you prefer to put "scpd->clk[j] = c;" into 'else' branch?
> >
> 
> Yes please :)

Yingjoe had tested in the latest checkpatch.pl and it showed checkpatch
warn on the else-branch. He had replied the results in previous email.
 
>  moved the for up in the function? If not, I would prefer not to move it,
>  to make it easier to read the diff.
> >>>
> >>> The new 'for' block are far different from original one. And I think
> >>> it's easy to read if we keep simple assign statements in the same block.
> >>>
> >>
> >> It's different in the sense that it checks if struct clk *c is an error.
> >> I don't see the reason why we need to move it up in the file.
> >> It's not too important but I would prefer not to move it if there is no
> >> reason.
> >
> > I think I may misunderstand your comments. Which 'for' block did you
> > mention for? 'for (i = 0; i < num ...' or 'for (j = 0; j < MAX_CLKS
> > && ...' ?
> >
> > The 'for(i)' exists in original code, this patch just change its counter
> > from 'NUM_DOMAINS' to 'num'. The 'for(j)' is a new for-block, so it was
> > not moved from other blocks.
> >
> 
> for (j = 0; j < MAX_CLKS... is present in the actual scpsys_probe in 
> linux-next (line 485 as of today). This patch moves this for a few lines 
> up, to be precise before executing this code sequence:
> 
> pd_data->domains[i] = genpd;
> scpd->scp = scp;
> 
> scpd->data = data;
> 
> 
> AFAIK there is no reason to do so. It adds unnecessary complexity to the 
> patch. So please fix this together with the other comments you got.

I see. So you prefer to put the for(j < MAX_CLKS) after 'scpd->data =
data' right? I can change it in next patch.


Best regards,

James

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

[Yang Zhang]

On 2016/7/11 23:52, Radim Krčmář wrote:

2016-07-11 16:14+0200, Paolo Bonzini:

On 11/07/2016 15:48, Radim Krčmář wrote:

I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.


(I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
 x2apic id.  xapic id cannot be greater than 255 and all of those are
 covered by the initial value of max_id.)


Yes, this would work too.  Or even better perhaps, look at vcpu->vcpu_id
in kvm_apic_id?


APIC ID is writeable in xAPIC mode, which would make the implementation
weird without an extra variable.  Always read-only APIC ID would be
best, IMO.


Or we can just simply put the assignment of apic_base to the end.


Yes, this would work, I'd also remove recalculates from
kvm_apic_set_*apic_id() and add a compiler barrier with comment for good
measure, even though set_virtual_x2apic_mode() serves as one.


Why a compiler barrier?


True, it should be a proper pair of smp_wmb() and smp_rmb() in
recalculate ... and current kvm_apic_id() reads in a wrong order, so
changing the apic_base alone update wouldn't get rid of this race.


(What makes a bit wary is that it doesn't avoid the same problem if we
 changed KVM to reset apic id to xapic id first when disabling apic.)


Yes, this is why I prefer it fixed once and for all in kvm_apic_id...


Seems most reasonable.  We'll need to be careful to have a correct value
in the apic page, but there shouldn't be any races there.


Yes, it is more reasonable.




Races in recalculation and APIC ID changes also lead to invalid physical
maps, which haven't been taken care of properly ...


Hmm, true, but can be fixed separately.  Probably the mutex should be
renamed so that it can be taken outside recalculate_apic_map...


Good point, it'll make reasoning easier and shouldn't introduce any
extra scalability issues.


If we can ensure all the updates to LDR,DFR,ID and apic mode are in 
correct sequence and followed with apic map recalculation, it should be 
enough. It's guest's responsibility to ensure the apic updating must
happen in right time(means no interrupt is in flying), otherwise the 
interrupt may deliver to wrong VCPU.


--
best regards
yang

Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map

[Yang Zhang]

On 2016/7/11 23:52, Radim Krčmář wrote:

2016-07-11 16:14+0200, Paolo Bonzini:

On 11/07/2016 15:48, Radim Krčmář wrote:

I guess the easiest solution is to replace kvm_apic_id with a field in
struct kvm_lapic, which is already shifted right by 24 in xAPIC mode.


(I guess the fewest LOC is to look at vcpu->vcpu_id, which is equal to
 x2apic id.  xapic id cannot be greater than 255 and all of those are
 covered by the initial value of max_id.)


Yes, this would work too.  Or even better perhaps, look at vcpu->vcpu_id
in kvm_apic_id?


APIC ID is writeable in xAPIC mode, which would make the implementation
weird without an extra variable.  Always read-only APIC ID would be
best, IMO.


Or we can just simply put the assignment of apic_base to the end.


Yes, this would work, I'd also remove recalculates from
kvm_apic_set_*apic_id() and add a compiler barrier with comment for good
measure, even though set_virtual_x2apic_mode() serves as one.


Why a compiler barrier?


True, it should be a proper pair of smp_wmb() and smp_rmb() in
recalculate ... and current kvm_apic_id() reads in a wrong order, so
changing the apic_base alone update wouldn't get rid of this race.


(What makes a bit wary is that it doesn't avoid the same problem if we
 changed KVM to reset apic id to xapic id first when disabling apic.)


Yes, this is why I prefer it fixed once and for all in kvm_apic_id...


Seems most reasonable.  We'll need to be careful to have a correct value
in the apic page, but there shouldn't be any races there.


Yes, it is more reasonable.




Races in recalculation and APIC ID changes also lead to invalid physical
maps, which haven't been taken care of properly ...


Hmm, true, but can be fixed separately.  Probably the mutex should be
renamed so that it can be taken outside recalculate_apic_map...


Good point, it'll make reasoning easier and shouldn't introduce any
extra scalability issues.


If we can ensure all the updates to LDR,DFR,ID and apic mode are in 
correct sequence and followed with apic map recalculation, it should be 
enough. It's guest's responsibility to ensure the apic updating must
happen in right time(means no interrupt is in flying), otherwise the 
interrupt may deliver to wrong VCPU.


--
best regards
yang

[PATCH v2] sound: oss: Remove useless initialisation

[Amitoj Kaur Chawla]

Remove useless initialisation of variable whose value is reinitialised
later.

The Coccinelle semantic patch used to make this change is as follows:
@@
type T;
identifier x;
constant C;
expression e;
@@

T x
- = C
 ;
x = e;

Signed-off-by: Amitoj Kaur Chawla 
---
Changes in v2:
-Modify commit message
 sound/oss/ad1848.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c
index 10c8de1..6368e5c 100644
--- a/sound/oss/ad1848.c
+++ b/sound/oss/ad1848.c
@@ -254,7 +254,7 @@ static void ad_write(ad1848_info * devc, int reg, int data)
 
 static void wait_for_calibration(ad1848_info * devc)
 {
-   int timeout = 0;
+   int timeout;
 
/*
 * Wait until the auto calibration process has finished.
-- 
1.9.1

[PATCH v2] sound: oss: Remove useless initialisation

[Amitoj Kaur Chawla]

Remove useless initialisation of variable whose value is reinitialised
later.

The Coccinelle semantic patch used to make this change is as follows:
@@
type T;
identifier x;
constant C;
expression e;
@@

T x
- = C
 ;
x = e;

Signed-off-by: Amitoj Kaur Chawla 
---
Changes in v2:
-Modify commit message
 sound/oss/ad1848.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c
index 10c8de1..6368e5c 100644
--- a/sound/oss/ad1848.c
+++ b/sound/oss/ad1848.c
@@ -254,7 +254,7 @@ static void ad_write(ad1848_info * devc, int reg, int data)
 
 static void wait_for_calibration(ad1848_info * devc)
 {
-   int timeout = 0;
+   int timeout;
 
/*
 * Wait until the auto calibration process has finished.
-- 
1.9.1

Re: [PATCH v5] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

[Madhavan Srinivasan]

Hi Arnaldo,

Any updates for this fix. Kindly let me know.

Maddy

On Tuesday 28 June 2016 02:24 PM, Jiri Olsa wrote:
> On Thu, Jun 23, 2016 at 11:19:27AM +0530, Madhavan Srinivasan wrote:
>
> SNIP
>
>> Changelog v1:
>> 1)updated commit message and patch subject
>> 2)Add the fix to print_sample_iregs() in builtin-script.c
>>
>>  tools/include/linux/bitmap.h |  2 ++
>>  tools/lib/bitmap.c   | 18 ++
>>  tools/perf/builtin-script.c  |  4 +++-
>>  tools/perf/util/session.c|  4 +++-
>>  4 files changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
>> index 28f5493da491..5e98525387dc 100644
>> --- a/tools/include/linux/bitmap.h
>> +++ b/tools/include/linux/bitmap.h
>> @@ -2,6 +2,7 @@
>>  #define _PERF_BITOPS_H
>>  
>>  #include 
>> +#include 
> this could go in the bitmap.c file, but anyway:
>
> Acked-by: Jiri Olsa 
>
> thanks,
> jirka
>
>>  #include 
>>  
>>  #define DECLARE_BITMAP(name,bits) \
>> @@ -10,6 +11,7 @@
>>  int __bitmap_weight(const unsigned long *bitmap, int bits);
>>  void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
>>   const unsigned long *bitmap2, int bits);
>> +void bitmap_from_u64(unsigned long *dst, u64 mask);
>>  
>>  #define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 
>> 1)))
>>  
> SNIP
>

Re: [PATCH v5] tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs

[Madhavan Srinivasan]

Hi Arnaldo,

Any updates for this fix. Kindly let me know.

Maddy

On Tuesday 28 June 2016 02:24 PM, Jiri Olsa wrote:
> On Thu, Jun 23, 2016 at 11:19:27AM +0530, Madhavan Srinivasan wrote:
>
> SNIP
>
>> Changelog v1:
>> 1)updated commit message and patch subject
>> 2)Add the fix to print_sample_iregs() in builtin-script.c
>>
>>  tools/include/linux/bitmap.h |  2 ++
>>  tools/lib/bitmap.c   | 18 ++
>>  tools/perf/builtin-script.c  |  4 +++-
>>  tools/perf/util/session.c|  4 +++-
>>  4 files changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
>> index 28f5493da491..5e98525387dc 100644
>> --- a/tools/include/linux/bitmap.h
>> +++ b/tools/include/linux/bitmap.h
>> @@ -2,6 +2,7 @@
>>  #define _PERF_BITOPS_H
>>  
>>  #include 
>> +#include 
> this could go in the bitmap.c file, but anyway:
>
> Acked-by: Jiri Olsa 
>
> thanks,
> jirka
>
>>  #include 
>>  
>>  #define DECLARE_BITMAP(name,bits) \
>> @@ -10,6 +11,7 @@
>>  int __bitmap_weight(const unsigned long *bitmap, int bits);
>>  void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
>>   const unsigned long *bitmap2, int bits);
>> +void bitmap_from_u64(unsigned long *dst, u64 mask);
>>  
>>  #define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 
>> 1)))
>>  
> SNIP
>

[PATCH] sound: oss: Remove useless initialisation

[Amitoj Kaur Chawla]

@@
type T;
identifier x;
constant C;
expression e;
@@

T x
- = C
 ;
x = e;

Signed-off-by: Amitoj Kaur Chawla 
---
 sound/oss/ad1848.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c
index 10c8de1..6368e5c 100644
--- a/sound/oss/ad1848.c
+++ b/sound/oss/ad1848.c
@@ -254,7 +254,7 @@ static void ad_write(ad1848_info * devc, int reg, int data)
 
 static void wait_for_calibration(ad1848_info * devc)
 {
-   int timeout = 0;
+   int timeout;
 
/*
 * Wait until the auto calibration process has finished.
-- 
1.9.1

[PATCH] sound: oss: Remove useless initialisation

[Amitoj Kaur Chawla]

@@
type T;
identifier x;
constant C;
expression e;
@@

T x
- = C
 ;
x = e;

Signed-off-by: Amitoj Kaur Chawla 
---
 sound/oss/ad1848.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c
index 10c8de1..6368e5c 100644
--- a/sound/oss/ad1848.c
+++ b/sound/oss/ad1848.c
@@ -254,7 +254,7 @@ static void ad_write(ad1848_info * devc, int reg, int data)
 
 static void wait_for_calibration(ad1848_info * devc)
 {
-   int timeout = 0;
+   int timeout;
 
/*
 * Wait until the auto calibration process has finished.
-- 
1.9.1

Re: [PATCH] iscsi-target: fix panic when add the second TCP connection to iSCSI session

[Feng Li]

Add ls...@suse.com

2016-07-11 22:23 GMT+08:00 冯力 :
> This problem exists at least from v3.16.
> The upstream kernel still exists this issue.
>
> I have tested my patch and the following panic is disappeared.
>
> Thanks,
> - Alex
>
> #dmesg
>
> [ 1160.788676] sd 16:0:0:0: [sde] Attached SCSI disk
> [ 1383.962626] target_core_get_fabric() failed for usb_gadget
> [ 1404.788910] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x1b,
> sending CHECK_CONDITION.
> [ 1404.858451] BUG: unable to handle kernel NULL pointer dereference
> at 01f8
> [ 1404.858911] IP: []
> iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
> [ 1404.859746] PGD 230c29067 PUD 232060067 PMD 0
> [ 1404.859963] Oops:  [#1] SMP
> [ 1404.860154] Modules linked in: crc32c_generic tcm_loop tcm_qla2xxx
> qla2xxx iscsi_target_mod ib_srpt vhost_scsi vhost tcm_fc libfc
> scsi_transport_fc scsi_tgt target_core_file target_core_iblock
> target_core_pscsi target_core_mod configfs nbd
> vmw_vsock_vmci_transport vsock bridge stp llc vmhgfs(O) snd_ens1371
> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd
> vmw_balloon evdev soundcore ac97_bus gameport ppdev pcspkr sg psmouse
> serio_raw parport_pc vmwgfx parport battery ttm drm_kms_helper drm
> i2c_piix4 shpchp i2c_core vmw_vmci processor thermal_sys ac button
> binfmt_misc md_mod ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core
> ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> hid_generic usbhid hid ext4 crc16 mbcache jbd2 sd_mod crc_t10dif
> crct10dif_generic crct10dif_common ata_generic
> [ 1404.861278]  mptspi scsi_transport_spi mptscsih ata_piix uhci_hcd
> ehci_pci ehci_hcd mptbase libata usbcore e1000 usb_common scsi_mod
> sunrpc dm_mirror dm_region_hash dm_log dm_mod autofs4
> [ 1404.861742] CPU: 2 PID: 1865 Comm: iscsi_np Tainted: G   O
> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1
> [ 1404.861868] Hardware name: VMware, Inc. VMware Virtual
> Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
> [ 1404.862033] task: 880234c849a0 ti: 8800b9c2 task.ti:
> 8800b9c2
> [ 1404.862114] RIP: 0010:[]  []
> iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
> [ 1404.862233] RSP: 0018:8800b9c23e60  EFLAGS: 00010246
> [ 1404.862282] RAX:  RBX: 88023125b800 RCX: 
> 8802b4d8d000
> [ 1404.862344] RDX: 002d RSI: fe01 RDI: 
> 880233ef1800
> [ 1404.862406] RBP: 8800b9651a00 R08: d5a073de R09: 
> 88023487e6c0
> [ 1404.862585] R10: ead0c2e5 R11: d039ef6a R12: 
> 88023125b854
> [ 1404.865580] R13: 88023125b908 R14: 880233ef1800 R15: 
> 880234c849a0
> [ 1404.867732] FS:  7fba67e2fb80() GS:88023e64()
> knlGS:
> [ 1404.869772] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 1404.871850] CR2: 01f8 CR3: 000230ffa000 CR4: 
> 07e0
> [ 1404.874271] Stack:
> [ 1404.877492]  88023125b908 00ff880234c849a0 88023125b858
> 88023481f400
> [ 1404.880162]  81510d00 880230768000 8800b9c23fd8
> 00012f00
> [ 1404.883545]  880234c849a0 880233e9da40 88023125b800
> a05edeb0
> [ 1404.885865] Call Trace:
> [ 1404.888384]  [] ? __schedule+0x250/0x700
> [ 1404.890619]  [] ?
> iscsi_target_login_sess_out+0x240/0x240 [iscsi_target_mod]
> [ 1404.892668]  [] ? kthread+0xbd/0xe0
> [ 1404.894646]  [] ? kthread_create_on_node+0x180/0x180
> [ 1404.896553]  [] ? ret_from_fork+0x58/0x90
> [ 1404.898556]  [] ? kthread_create_on_node+0x180/0x180
> [ 1404.900597] Code: 09 00 00 48 89 ea 4c 89 f6 48 89 df e8 52 1b 00
> 00 85 c0 0f 88 82 02 00 00 0f b6 44 24 0f 4c 89 f7 88 45 09 49 8b 86
> d8 04 00 00 <4c> 8b a8 f8 01 00 00 49 8b 86 a0 04 00 00 ff 90 98 00 00
> 00 41
> [ 1404.906962] RIP  []
> iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
> [ 1404.908962]  RSP 
> [ 1404.910940] CR2: 01f8
> [ 1404.917670] ---[ end trace d29d8c681ab2bdfb ]---
> [ 1419.859690] iSCSI Login timeout on Network Portal 10.182.70.69:3260
> [ 1479.832056] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1479.835739] iSCSI Login negotiation failed.
> [ 1549.332632] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1549.338432] iSCSI Login negotiation failed.
> [ 1564.358423] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1564.362443] iSCSI Login negotiation failed.
>
> 2016-07-12 6:15 GMT+08:00 Feng Li :
>> From: Feng Li 
>>
>> In MC/S scenario, the conn->sess has been set NULL in
>> iscsi_login_non_zero_tsih_s1 when the second connection comes here,
>> then kernel panic.
>>
>> The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
>> we should check whether it's NULL before calling.
>>
>> Signed-off-by: Feng Li 
>> ---
>>  drivers/target/iscsi/iscsi_target_login.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 

Re: [PATCH] iscsi-target: fix panic when add the second TCP connection to iSCSI session

[Feng Li]

Add ls...@suse.com

2016-07-11 22:23 GMT+08:00 冯力 :
> This problem exists at least from v3.16.
> The upstream kernel still exists this issue.
>
> I have tested my patch and the following panic is disappeared.
>
> Thanks,
> - Alex
>
> #dmesg
>
> [ 1160.788676] sd 16:0:0:0: [sde] Attached SCSI disk
> [ 1383.962626] target_core_get_fabric() failed for usb_gadget
> [ 1404.788910] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x1b,
> sending CHECK_CONDITION.
> [ 1404.858451] BUG: unable to handle kernel NULL pointer dereference
> at 01f8
> [ 1404.858911] IP: []
> iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
> [ 1404.859746] PGD 230c29067 PUD 232060067 PMD 0
> [ 1404.859963] Oops:  [#1] SMP
> [ 1404.860154] Modules linked in: crc32c_generic tcm_loop tcm_qla2xxx
> qla2xxx iscsi_target_mod ib_srpt vhost_scsi vhost tcm_fc libfc
> scsi_transport_fc scsi_tgt target_core_file target_core_iblock
> target_core_pscsi target_core_mod configfs nbd
> vmw_vsock_vmci_transport vsock bridge stp llc vmhgfs(O) snd_ens1371
> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd
> vmw_balloon evdev soundcore ac97_bus gameport ppdev pcspkr sg psmouse
> serio_raw parport_pc vmwgfx parport battery ttm drm_kms_helper drm
> i2c_piix4 shpchp i2c_core vmw_vmci processor thermal_sys ac button
> binfmt_misc md_mod ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core
> ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> hid_generic usbhid hid ext4 crc16 mbcache jbd2 sd_mod crc_t10dif
> crct10dif_generic crct10dif_common ata_generic
> [ 1404.861278]  mptspi scsi_transport_spi mptscsih ata_piix uhci_hcd
> ehci_pci ehci_hcd mptbase libata usbcore e1000 usb_common scsi_mod
> sunrpc dm_mirror dm_region_hash dm_log dm_mod autofs4
> [ 1404.861742] CPU: 2 PID: 1865 Comm: iscsi_np Tainted: G   O
> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1
> [ 1404.861868] Hardware name: VMware, Inc. VMware Virtual
> Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
> [ 1404.862033] task: 880234c849a0 ti: 8800b9c2 task.ti:
> 8800b9c2
> [ 1404.862114] RIP: 0010:[]  []
> iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
> [ 1404.862233] RSP: 0018:8800b9c23e60  EFLAGS: 00010246
> [ 1404.862282] RAX:  RBX: 88023125b800 RCX: 
> 8802b4d8d000
> [ 1404.862344] RDX: 002d RSI: fe01 RDI: 
> 880233ef1800
> [ 1404.862406] RBP: 8800b9651a00 R08: d5a073de R09: 
> 88023487e6c0
> [ 1404.862585] R10: ead0c2e5 R11: d039ef6a R12: 
> 88023125b854
> [ 1404.865580] R13: 88023125b908 R14: 880233ef1800 R15: 
> 880234c849a0
> [ 1404.867732] FS:  7fba67e2fb80() GS:88023e64()
> knlGS:
> [ 1404.869772] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 1404.871850] CR2: 01f8 CR3: 000230ffa000 CR4: 
> 07e0
> [ 1404.874271] Stack:
> [ 1404.877492]  88023125b908 00ff880234c849a0 88023125b858
> 88023481f400
> [ 1404.880162]  81510d00 880230768000 8800b9c23fd8
> 00012f00
> [ 1404.883545]  880234c849a0 880233e9da40 88023125b800
> a05edeb0
> [ 1404.885865] Call Trace:
> [ 1404.888384]  [] ? __schedule+0x250/0x700
> [ 1404.890619]  [] ?
> iscsi_target_login_sess_out+0x240/0x240 [iscsi_target_mod]
> [ 1404.892668]  [] ? kthread+0xbd/0xe0
> [ 1404.894646]  [] ? kthread_create_on_node+0x180/0x180
> [ 1404.896553]  [] ? ret_from_fork+0x58/0x90
> [ 1404.898556]  [] ? kthread_create_on_node+0x180/0x180
> [ 1404.900597] Code: 09 00 00 48 89 ea 4c 89 f6 48 89 df e8 52 1b 00
> 00 85 c0 0f 88 82 02 00 00 0f b6 44 24 0f 4c 89 f7 88 45 09 49 8b 86
> d8 04 00 00 <4c> 8b a8 f8 01 00 00 49 8b 86 a0 04 00 00 ff 90 98 00 00
> 00 41
> [ 1404.906962] RIP  []
> iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
> [ 1404.908962]  RSP 
> [ 1404.910940] CR2: 01f8
> [ 1404.917670] ---[ end trace d29d8c681ab2bdfb ]---
> [ 1419.859690] iSCSI Login timeout on Network Portal 10.182.70.69:3260
> [ 1479.832056] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1479.835739] iSCSI Login negotiation failed.
> [ 1549.332632] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1549.338432] iSCSI Login negotiation failed.
> [ 1564.358423] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1564.362443] iSCSI Login negotiation failed.
>
> 2016-07-12 6:15 GMT+08:00 Feng Li :
>> From: Feng Li 
>>
>> In MC/S scenario, the conn->sess has been set NULL in
>> iscsi_login_non_zero_tsih_s1 when the second connection comes here,
>> then kernel panic.
>>
>> The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
>> we should check whether it's NULL before calling.
>>
>> Signed-off-by: Feng Li 
>> ---
>>  drivers/target/iscsi/iscsi_target_login.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/target/iscsi/iscsi_target_login.c 
>> 

Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[Xunlei Pang]

On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> This patch fixes one of the problems reported by Daniel Walker
> (https://lkml.org/lkml/2015/6/24/44).
>
> If crash_kexec_post_notifiers boot option is specified, other CPUs
> are stopped by smp_send_stop() instead of machine_crash_shutdown()
> in crash_kexec() path.  This behavior change leads two problems.
>
>  Problem 1:
>  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are
>  still online and try to stop their watchdog timer.  If
>  smp_send_stop() is called before octeon_generic_shutdown(), stopping
>  watchdog timer will fail because other CPUs have been offlined by
>  smp_send_stop().
>
>panic()
>  if crash_kexec_post_notifiers == 1
>smp_send_stop()
>atomic_notifier_call_chain()
>kmsg_dump()
>  crash_kexec()
>machine_crash_shutdown()
>  octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs
>
>  Problem 2:
>  Most of architectures stop other CPUs in machine_crash_shutdown()
>  path, and they also do something needed for kdump.  For example,
>  they save registers, disable virtualization extensions, and so on.
>  However, if smp_send_stop() stops other CPUs before
>  machine_crash_shutdown(), we miss those operations.
>
> How do we fix these problems?  In the first place, we should stop
> other CPUs as soon as possible when panic() was called, otherwise
> other CPUs may wipe out a clue to the cause of the failure.  So, we
> replace smp_send_stop() with more suitable one for kdump.
>
> This patch solves Problem 2 by replacing smp_send_stop() in panic()
> with panic_smp_send_stop().  This is a weak function which calls
> smp_send_stop(), and architecture dependent code may override this
> with appropriate one.  This patch only provides x86-specific version.
>
> Changes in V3:
> - Revise comments, description, and symbol names
>
> Changes in V2:
> - Replace smp_send_stop() call with crash_kexec version which
>   saves cpu states and cleans up VMX/SVM
> - Drop a fix for Problem 1 at this moment
>
> Reported-by: Daniel Walker 
> Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
> Signed-off-by: Hidehiro Kawai 
> Cc: Dave Young 
> Cc: Baoquan He 
> Cc: Vivek Goyal 
> Cc: Eric Biederman 
> Cc: Masami Hiramatsu 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Borislav Petkov 
> Cc: Toshi Kani 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: Takao Indoh 
> Cc: "Lee, Chun-Yi" 
> Cc: Minfei Huang 
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: Vitaly Kuznetsov 
> Cc: Petr Mladek 
> Cc: Tejun Heo 
> Cc: Josh Poimboeuf 
> ---
>  arch/x86/kernel/crash.c |   14 ++
>  kernel/panic.c  |   43 ---
>  2 files changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ef978d..3305433 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -133,15 +133,21 @@ static void kdump_nmi_callback(int cpu, struct pt_regs 
> *regs)
>   disable_local_APIC();
>  }
>  
> -static void kdump_nmi_shootdown_cpus(void)
> +/* Override the weak function in kernel/panic.c */
> +void panic_smp_send_stop(void)
>  {
> - nmi_shootdown_cpus(kdump_nmi_callback);
> + static int cpus_stopped;

Should be atomic_t type?

> +
> + if (cpus_stopped)
> + return;
>  
> + nmi_shootdown_cpus(kdump_nmi_callback);
>   disable_local_APIC();
> + cpus_stopped = 1;
>  }
>  
>  #else
> -static void kdump_nmi_shootdown_cpus(void)
> +void panic_smp_send_stop(void)
>  {
>   /* There are no cpus to shootdown */
>  }
> @@ -160,7 +166,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>   /* The kernel is broken so disable interrupts */
>   local_irq_disable();
>  
> - kdump_nmi_shootdown_cpus();
> + panic_smp_send_stop();
>  
>   /*
>* VMCLEAR VMCSs loaded on this cpu if needed.
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 8aa7449..da8062d2 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -71,6 +71,32 @@ void __weak nmi_panic_self_stop(struct pt_regs *regs)
>   panic_smp_self_stop();
>  }
>  
> +/*
> + * Stop other CPUs in panic.  Architecture dependent code may override this
> + * with more suitable version.  For example, if the architecture supports
> + * crash dump, it should save registers of each stopped CPU and disable
> + * per-CPU features such as virtualization extensions.
> + */
> +void __weak 

Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[Xunlei Pang]

On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> This patch fixes one of the problems reported by Daniel Walker
> (https://lkml.org/lkml/2015/6/24/44).
>
> If crash_kexec_post_notifiers boot option is specified, other CPUs
> are stopped by smp_send_stop() instead of machine_crash_shutdown()
> in crash_kexec() path.  This behavior change leads two problems.
>
>  Problem 1:
>  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are
>  still online and try to stop their watchdog timer.  If
>  smp_send_stop() is called before octeon_generic_shutdown(), stopping
>  watchdog timer will fail because other CPUs have been offlined by
>  smp_send_stop().
>
>panic()
>  if crash_kexec_post_notifiers == 1
>smp_send_stop()
>atomic_notifier_call_chain()
>kmsg_dump()
>  crash_kexec()
>machine_crash_shutdown()
>  octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs
>
>  Problem 2:
>  Most of architectures stop other CPUs in machine_crash_shutdown()
>  path, and they also do something needed for kdump.  For example,
>  they save registers, disable virtualization extensions, and so on.
>  However, if smp_send_stop() stops other CPUs before
>  machine_crash_shutdown(), we miss those operations.
>
> How do we fix these problems?  In the first place, we should stop
> other CPUs as soon as possible when panic() was called, otherwise
> other CPUs may wipe out a clue to the cause of the failure.  So, we
> replace smp_send_stop() with more suitable one for kdump.
>
> This patch solves Problem 2 by replacing smp_send_stop() in panic()
> with panic_smp_send_stop().  This is a weak function which calls
> smp_send_stop(), and architecture dependent code may override this
> with appropriate one.  This patch only provides x86-specific version.
>
> Changes in V3:
> - Revise comments, description, and symbol names
>
> Changes in V2:
> - Replace smp_send_stop() call with crash_kexec version which
>   saves cpu states and cleans up VMX/SVM
> - Drop a fix for Problem 1 at this moment
>
> Reported-by: Daniel Walker 
> Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
> Signed-off-by: Hidehiro Kawai 
> Cc: Dave Young 
> Cc: Baoquan He 
> Cc: Vivek Goyal 
> Cc: Eric Biederman 
> Cc: Masami Hiramatsu 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Borislav Petkov 
> Cc: Toshi Kani 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: Takao Indoh 
> Cc: "Lee, Chun-Yi" 
> Cc: Minfei Huang 
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: Vitaly Kuznetsov 
> Cc: Petr Mladek 
> Cc: Tejun Heo 
> Cc: Josh Poimboeuf 
> ---
>  arch/x86/kernel/crash.c |   14 ++
>  kernel/panic.c  |   43 ---
>  2 files changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ef978d..3305433 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -133,15 +133,21 @@ static void kdump_nmi_callback(int cpu, struct pt_regs 
> *regs)
>   disable_local_APIC();
>  }
>  
> -static void kdump_nmi_shootdown_cpus(void)
> +/* Override the weak function in kernel/panic.c */
> +void panic_smp_send_stop(void)
>  {
> - nmi_shootdown_cpus(kdump_nmi_callback);
> + static int cpus_stopped;

Should be atomic_t type?

> +
> + if (cpus_stopped)
> + return;
>  
> + nmi_shootdown_cpus(kdump_nmi_callback);
>   disable_local_APIC();
> + cpus_stopped = 1;
>  }
>  
>  #else
> -static void kdump_nmi_shootdown_cpus(void)
> +void panic_smp_send_stop(void)
>  {
>   /* There are no cpus to shootdown */
>  }
> @@ -160,7 +166,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
>   /* The kernel is broken so disable interrupts */
>   local_irq_disable();
>  
> - kdump_nmi_shootdown_cpus();
> + panic_smp_send_stop();
>  
>   /*
>* VMCLEAR VMCSs loaded on this cpu if needed.
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 8aa7449..da8062d2 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -71,6 +71,32 @@ void __weak nmi_panic_self_stop(struct pt_regs *regs)
>   panic_smp_self_stop();
>  }
>  
> +/*
> + * Stop other CPUs in panic.  Architecture dependent code may override this
> + * with more suitable version.  For example, if the architecture supports
> + * crash dump, it should save registers of each stopped CPU and disable
> + * per-CPU features such as virtualization extensions.
> + */
> +void __weak panic_smp_send_stop(void)
> +{
> + static int cpus_stopped;
> +
> + /*
> +  * This function can be called twice in panic path, but obviously
> +  * we execute this only once.
> +  */
> + if (cpus_stopped)
> + return;
> +
> + /*
> +  * Note smp_send_stop is the usual smp shutdown function, which
> +  * unfortunately means it may not be hardened to work in a panic
> +  * situation.
> +  */
> + 

Re: [RFC PATCH v2 6/7] lib/persubnode: Introducing a simple per-subnode APIs

[Boqun Feng]

On Mon, Jul 11, 2016 at 01:32:11PM -0400, Waiman Long wrote:
> The percpu APIs are extensively used in the Linux kernel to reduce
> cacheline contention and improve performance. For some use cases, the
> percpu APIs may be too fine-grain for distributed resources whereas
> a per-node based allocation may be too coarse as we can have dozens
> of CPUs in a NUMA node in some high-end systems.
> 
> This patch introduces a simple per-subnode APIs where each of the
> distributed resources will be shared by only a handful of CPUs within
> a NUMA node. The per-subnode APIs are built on top of the percpu APIs
> and hence requires the same amount of memory as if the percpu APIs
> are used. However, it helps to reduce the total number of separate
> resources that needed to be managed. As a result, it can speed up code
> that need to iterate all the resources compared with using the percpu
> APIs. Cacheline contention, however, will increases slightly as each
> resource is shared by more than one CPU. As long as the number of CPUs
> in each subnode is small, the performance impact won't be significant.
> 
> In this patch, at most 2 sibling groups can be put into a subnode. For
> an x86-64 CPU, at most 4 CPUs will be in a subnode when HT is enabled
> and 2 when it is not.
> 
> Signed-off-by: Waiman Long 
> ---
>  include/linux/persubnode.h |   80 +
>  init/main.c|2 +
>  lib/Makefile   |2 +
>  lib/persubnode.c   |  119 
> 
>  4 files changed, 203 insertions(+), 0 deletions(-)
>  create mode 100644 include/linux/persubnode.h
>  create mode 100644 lib/persubnode.c
> 
> diff --git a/include/linux/persubnode.h b/include/linux/persubnode.h
> new file mode 100644
> index 000..b777daa
> --- /dev/null
> +++ b/include/linux/persubnode.h
> @@ -0,0 +1,80 @@
> +/*
> + * Per-subnode definitions
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * (C) Copyright 2016 Hewlett-Packard Enterprise Development LP
> + *
> + * Authors: Waiman Long 
> + */
> +#ifndef __LINUX_PERSUBNODE_H
> +#define __LINUX_PERSUBNODE_H
> +
> +#include 
> +#include 
> +
> +/*
> + * Per-subnode APIs
> + */
> +#define __persubnode __percpu
> +#define nr_subnode_ids   nr_cpu_ids
> +#define alloc_persubnode(type)   alloc_percpu(type)
> +#define free_persubnode(var) free_percpu(var)
> +#define for_each_subnode(snode)  for_each_cpu(snode, 
> subnode_mask)
> +#define per_subnode_ptr(ptr, subnode)per_cpu_ptr(ptr, subnode)
> +#define per_subnode(var, subnode)per_cpu(var, subnode)
> +
> +#ifdef CONFIG_SMP
> +
> +extern struct cpumask __subnode_mask __read_mostly;
> +DECLARE_PER_CPU_READ_MOSTLY(int, cpu_subnode_id);
> +
> +#define subnode_mask (&__subnode_mask)
> +
> +static inline int this_cpu_to_subnode(void)
> +{
> + return *this_cpu_ptr(_subnode_id);
> +}
> +
> +/*
> + * For safety, preemption should be disabled before using this_subnode_ptr().
> + */
> +#define this_subnode_ptr(ptr)\
> +({   \
> + int _snid = this_cpu_to_subnode();  \
> + per_cpu_ptr(ptr, _snid);\
> +})
> +
> +#define get_subnode_ptr(ptr) \
> +({   \
> + preempt_disable();  \
> + this_subnode_ptr(ptr);  \
> +})
> +
> +#define put_subnode_ptr(ptr) \
> +do { \
> + (void)(ptr);\
> + preempt_enable();   \
> +} while (0)
> +
> +extern void __init subnode_early_init(void);
> +
> +#else /* CONFIG_SMP */
> +
> +#define subnode_mask cpu_possible_mask
> +#define this_subnode_ptr(ptr)this_cpu_ptr(ptr)
> +#define get_subnode_ptr(ptr) get_cpu_ptr(ptr)
> +#define put_subnode_ptr(ptr) put_cpu_ptr(ptr)
> +
> +static inline void subnode_early_init(void) { }
> +
> +#endif /* CONFIG_SMP */
> +#endif /* __LINUX_PERSUBNODE_H */
> diff --git a/init/main.c b/init/main.c
> index 4c17fda..28e4425 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -81,6 +81,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -524,6 +525,7 @@ asmlinkage __visible void __init start_kernel(void)
>  NULL, set_init_arg);
>  
>   

Re: [RFC PATCH v2 6/7] lib/persubnode: Introducing a simple per-subnode APIs

[Boqun Feng]

On Mon, Jul 11, 2016 at 01:32:11PM -0400, Waiman Long wrote:
> The percpu APIs are extensively used in the Linux kernel to reduce
> cacheline contention and improve performance. For some use cases, the
> percpu APIs may be too fine-grain for distributed resources whereas
> a per-node based allocation may be too coarse as we can have dozens
> of CPUs in a NUMA node in some high-end systems.
> 
> This patch introduces a simple per-subnode APIs where each of the
> distributed resources will be shared by only a handful of CPUs within
> a NUMA node. The per-subnode APIs are built on top of the percpu APIs
> and hence requires the same amount of memory as if the percpu APIs
> are used. However, it helps to reduce the total number of separate
> resources that needed to be managed. As a result, it can speed up code
> that need to iterate all the resources compared with using the percpu
> APIs. Cacheline contention, however, will increases slightly as each
> resource is shared by more than one CPU. As long as the number of CPUs
> in each subnode is small, the performance impact won't be significant.
> 
> In this patch, at most 2 sibling groups can be put into a subnode. For
> an x86-64 CPU, at most 4 CPUs will be in a subnode when HT is enabled
> and 2 when it is not.
> 
> Signed-off-by: Waiman Long 
> ---
>  include/linux/persubnode.h |   80 +
>  init/main.c|2 +
>  lib/Makefile   |2 +
>  lib/persubnode.c   |  119 
> 
>  4 files changed, 203 insertions(+), 0 deletions(-)
>  create mode 100644 include/linux/persubnode.h
>  create mode 100644 lib/persubnode.c
> 
> diff --git a/include/linux/persubnode.h b/include/linux/persubnode.h
> new file mode 100644
> index 000..b777daa
> --- /dev/null
> +++ b/include/linux/persubnode.h
> @@ -0,0 +1,80 @@
> +/*
> + * Per-subnode definitions
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * (C) Copyright 2016 Hewlett-Packard Enterprise Development LP
> + *
> + * Authors: Waiman Long 
> + */
> +#ifndef __LINUX_PERSUBNODE_H
> +#define __LINUX_PERSUBNODE_H
> +
> +#include 
> +#include 
> +
> +/*
> + * Per-subnode APIs
> + */
> +#define __persubnode __percpu
> +#define nr_subnode_ids   nr_cpu_ids
> +#define alloc_persubnode(type)   alloc_percpu(type)
> +#define free_persubnode(var) free_percpu(var)
> +#define for_each_subnode(snode)  for_each_cpu(snode, 
> subnode_mask)
> +#define per_subnode_ptr(ptr, subnode)per_cpu_ptr(ptr, subnode)
> +#define per_subnode(var, subnode)per_cpu(var, subnode)
> +
> +#ifdef CONFIG_SMP
> +
> +extern struct cpumask __subnode_mask __read_mostly;
> +DECLARE_PER_CPU_READ_MOSTLY(int, cpu_subnode_id);
> +
> +#define subnode_mask (&__subnode_mask)
> +
> +static inline int this_cpu_to_subnode(void)
> +{
> + return *this_cpu_ptr(_subnode_id);
> +}
> +
> +/*
> + * For safety, preemption should be disabled before using this_subnode_ptr().
> + */
> +#define this_subnode_ptr(ptr)\
> +({   \
> + int _snid = this_cpu_to_subnode();  \
> + per_cpu_ptr(ptr, _snid);\
> +})
> +
> +#define get_subnode_ptr(ptr) \
> +({   \
> + preempt_disable();  \
> + this_subnode_ptr(ptr);  \
> +})
> +
> +#define put_subnode_ptr(ptr) \
> +do { \
> + (void)(ptr);\
> + preempt_enable();   \
> +} while (0)
> +
> +extern void __init subnode_early_init(void);
> +
> +#else /* CONFIG_SMP */
> +
> +#define subnode_mask cpu_possible_mask
> +#define this_subnode_ptr(ptr)this_cpu_ptr(ptr)
> +#define get_subnode_ptr(ptr) get_cpu_ptr(ptr)
> +#define put_subnode_ptr(ptr) put_cpu_ptr(ptr)
> +
> +static inline void subnode_early_init(void) { }
> +
> +#endif /* CONFIG_SMP */
> +#endif /* __LINUX_PERSUBNODE_H */
> diff --git a/init/main.c b/init/main.c
> index 4c17fda..28e4425 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -81,6 +81,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -524,6 +525,7 @@ asmlinkage __visible void __init start_kernel(void)
>  NULL, set_init_arg);
>  
>   jump_label_init();
> + 

Re: tty/vt/keyboard: out of bounds access in do_compute_shiftstate

[Dmitry Torokhov]

On Mon, Jun 27, 2016 at 02:27:56PM -0700, Dmitry Torokhov wrote:
> On Sun, May 29, 2016 at 01:52:44PM -0400, Sasha Levin wrote:
> > Hi all,
> > 
> > I've hit the following while fuzzing with syzkaller inside a KVM tools guest
> > running the latest -next kernel:
> > 
> > [ 2662.777566] BUG: KASAN: global-out-of-bounds in 
> > do_compute_shiftstate+0x161/0x370 at addr b2e686a0
> > 
> > [ 2662.777592] Read of size 2 by task syz-executor/30576
> > 
> > [ 2662.777676] Address belongs to variable plain_map+0x200/0x3540
> > 
> > [ 2662.27] CPU: 2 PID: 30576 Comm: syz-executor Tainted: GB 
> >   4.6.0-next-20160527-sasha-00024-g6ab0dc9-dirty #3098
> > 
> > [ 2662.92]  11001635bde7 dc4d92d7 8800b1adefc0 
> > a3fd0b37
> > 
> > [ 2662.777826]  0002 fbfff5deeda4 41b58ab3 
> > ae8dd830
> > 
> > [ 2662.777862]  a3fd09c8 a23fa2e8 8800b1adef98 
> > 8801d42a20f8
> > 
> > [ 2662.777868] Call Trace:
> > 
> > [ 2662.777935] dump_stack (lib/dump_stack.c:53)
> > [ 2662.778136] kasan_report_error (include/linux/kasan.h:28 
> > mm/kasan/report.c:211 mm/kasan/report.c:277)
> > [ 2662.778265] __asan_report_load2_noabort (mm/kasan/report.c:317)
> > [ 2662.778318] do_compute_shiftstate (drivers/tty/vt/keyboard.c:386)
> > [ 2662.778332] fn_null (drivers/tty/vt/keyboard.c:625)
> > [ 2662.778345] k_spec (drivers/tty/vt/keyboard.c:645)
> > [ 2662.778361] kbd_event (drivers/tty/vt/keyboard.c:1459 
> > drivers/tty/vt/keyboard.c:1475)
> > [ 2662.778907] input_to_handler (drivers/input/input.c:120 (discriminator 
> > 3))
> > [ 2662.778926] input_pass_values (drivers/input/input.c:148)
> > [ 2662.778944] input_handle_event (drivers/input/input.c:406)
> > [ 2662.779015] input_inject_event (include/linux/rcupdate.h:910 
> > drivers/input/input.c:467)
> > [ 2662.779034] evdev_do_ioctl (drivers/input/evdev.c:1102)
> > [ 2662.779271] evdev_ioctl_handler (drivers/input/evdev.c:1302)
> > [ 2662.779305] evdev_ioctl (drivers/input/evdev.c:1312)
> > [ 2662.779320] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:674)
> > [ 2662.779463] SyS_ioctl (fs/ioctl.c:689 fs/ioctl.c:680)
> > [ 2662.779511] do_syscall_64 (arch/x86/entry/common.c:350)
> > [ 2662.779530] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:251)
> > [ 2662.779535] Memory state around the buggy address:
> > 
> > [ 2662.779566]  b2e68580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779579]  b2e68600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779589] >b2e68680: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779594]^
> > 
> > [ 2662.779604]  b2e68700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779615]  b2e68780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> 
> I think this happens because keymap size in keyboard.c is smaller than
> keymaps in input devices. Does the patch below fixes this?

Anyone willing to look it over and add reviewed-by/tested-by?

> 
> Thanks.
> 
> -- 
> Dmitry
> 
> 
> tty/vt/keyboard: fix OOB access in do_compute_shiftstate()
> 
> From: Dmitry Torokhov 
> 
> The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
> which is currently 256, whereas number of keys/buttons in input device (and
> therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
> out-of-bound access when we do
> 
>   sym = U(key_maps[0][k]);
> 
> with large 'k'.
> 
> To fix it we should not attempt iterating beyond smaller of NR_KEYS and
> KEY_CNT.
> 
> Also while at it let's switch to for_each_set_bit() instead of open-coding
> it.
> 
> Reported-by: Sasha Levin 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/tty/vt/keyboard.c |   30 +-
>  1 file changed, 9 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f973bfc..1e93a37 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -366,34 +366,22 @@ static void to_utf8(struct vc_data *vc, uint c)
>  
>  static void do_compute_shiftstate(void)
>  {
> - unsigned int i, j, k, sym, val;
> + unsigned int k, sym, val;
>  
>   shift_state = 0;
>   memset(shift_down, 0, sizeof(shift_down));
>  
> - for (i = 0; i < ARRAY_SIZE(key_down); i++) {
> -
> - if (!key_down[i])
> + for_each_set_bit(k, key_down, min(NR_KEYS, KEY_CNT)) {
> + sym = U(key_maps[0][k]);
> + if (KTYP(sym) != KT_SHIFT && KTYP(sym) != KT_SLOCK)
>   continue;
>  
> - k = i * BITS_PER_LONG;
> -
> - for (j = 0; j < BITS_PER_LONG; j++, k++) {
> -
> - if (!test_bit(k, key_down))
> - continue;
> + val = 

Re: tty/vt/keyboard: out of bounds access in do_compute_shiftstate

[Dmitry Torokhov]

On Mon, Jun 27, 2016 at 02:27:56PM -0700, Dmitry Torokhov wrote:
> On Sun, May 29, 2016 at 01:52:44PM -0400, Sasha Levin wrote:
> > Hi all,
> > 
> > I've hit the following while fuzzing with syzkaller inside a KVM tools guest
> > running the latest -next kernel:
> > 
> > [ 2662.777566] BUG: KASAN: global-out-of-bounds in 
> > do_compute_shiftstate+0x161/0x370 at addr b2e686a0
> > 
> > [ 2662.777592] Read of size 2 by task syz-executor/30576
> > 
> > [ 2662.777676] Address belongs to variable plain_map+0x200/0x3540
> > 
> > [ 2662.27] CPU: 2 PID: 30576 Comm: syz-executor Tainted: GB 
> >   4.6.0-next-20160527-sasha-00024-g6ab0dc9-dirty #3098
> > 
> > [ 2662.92]  11001635bde7 dc4d92d7 8800b1adefc0 
> > a3fd0b37
> > 
> > [ 2662.777826]  0002 fbfff5deeda4 41b58ab3 
> > ae8dd830
> > 
> > [ 2662.777862]  a3fd09c8 a23fa2e8 8800b1adef98 
> > 8801d42a20f8
> > 
> > [ 2662.777868] Call Trace:
> > 
> > [ 2662.777935] dump_stack (lib/dump_stack.c:53)
> > [ 2662.778136] kasan_report_error (include/linux/kasan.h:28 
> > mm/kasan/report.c:211 mm/kasan/report.c:277)
> > [ 2662.778265] __asan_report_load2_noabort (mm/kasan/report.c:317)
> > [ 2662.778318] do_compute_shiftstate (drivers/tty/vt/keyboard.c:386)
> > [ 2662.778332] fn_null (drivers/tty/vt/keyboard.c:625)
> > [ 2662.778345] k_spec (drivers/tty/vt/keyboard.c:645)
> > [ 2662.778361] kbd_event (drivers/tty/vt/keyboard.c:1459 
> > drivers/tty/vt/keyboard.c:1475)
> > [ 2662.778907] input_to_handler (drivers/input/input.c:120 (discriminator 
> > 3))
> > [ 2662.778926] input_pass_values (drivers/input/input.c:148)
> > [ 2662.778944] input_handle_event (drivers/input/input.c:406)
> > [ 2662.779015] input_inject_event (include/linux/rcupdate.h:910 
> > drivers/input/input.c:467)
> > [ 2662.779034] evdev_do_ioctl (drivers/input/evdev.c:1102)
> > [ 2662.779271] evdev_ioctl_handler (drivers/input/evdev.c:1302)
> > [ 2662.779305] evdev_ioctl (drivers/input/evdev.c:1312)
> > [ 2662.779320] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:674)
> > [ 2662.779463] SyS_ioctl (fs/ioctl.c:689 fs/ioctl.c:680)
> > [ 2662.779511] do_syscall_64 (arch/x86/entry/common.c:350)
> > [ 2662.779530] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:251)
> > [ 2662.779535] Memory state around the buggy address:
> > 
> > [ 2662.779566]  b2e68580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779579]  b2e68600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779589] >b2e68680: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779594]^
> > 
> > [ 2662.779604]  b2e68700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> > 
> > [ 2662.779615]  b2e68780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > 00 00
> 
> I think this happens because keymap size in keyboard.c is smaller than
> keymaps in input devices. Does the patch below fixes this?

Anyone willing to look it over and add reviewed-by/tested-by?

> 
> Thanks.
> 
> -- 
> Dmitry
> 
> 
> tty/vt/keyboard: fix OOB access in do_compute_shiftstate()
> 
> From: Dmitry Torokhov 
> 
> The size of individual keymap in drivers/tty/vt/keyboard.c is NR_KEYS,
> which is currently 256, whereas number of keys/buttons in input device (and
> therefor in key_down) is much larger - KEY_CNT - 768, and that can cause
> out-of-bound access when we do
> 
>   sym = U(key_maps[0][k]);
> 
> with large 'k'.
> 
> To fix it we should not attempt iterating beyond smaller of NR_KEYS and
> KEY_CNT.
> 
> Also while at it let's switch to for_each_set_bit() instead of open-coding
> it.
> 
> Reported-by: Sasha Levin 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/tty/vt/keyboard.c |   30 +-
>  1 file changed, 9 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f973bfc..1e93a37 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -366,34 +366,22 @@ static void to_utf8(struct vc_data *vc, uint c)
>  
>  static void do_compute_shiftstate(void)
>  {
> - unsigned int i, j, k, sym, val;
> + unsigned int k, sym, val;
>  
>   shift_state = 0;
>   memset(shift_down, 0, sizeof(shift_down));
>  
> - for (i = 0; i < ARRAY_SIZE(key_down); i++) {
> -
> - if (!key_down[i])
> + for_each_set_bit(k, key_down, min(NR_KEYS, KEY_CNT)) {
> + sym = U(key_maps[0][k]);
> + if (KTYP(sym) != KT_SHIFT && KTYP(sym) != KT_SLOCK)
>   continue;
>  
> - k = i * BITS_PER_LONG;
> -
> - for (j = 0; j < BITS_PER_LONG; j++, k++) {
> -
> - if (!test_bit(k, key_down))
> - continue;
> + val = KVAL(sym);
> + if (val == KVAL(K_CAPSSHIFT))
> + 

[Patch v1] netlogic/platform_net: Catch failure to register NETLOGIC_XLR_NET device.

[Arvind Yadav]

This driver Kconfig is depend on CPU_XLR. If default Kconfig
NETLOGIC_XLR_NET value are used with CPU_XLR then you end up
with a resource. This causes __request_resource to return a
conflict which then returns an -EBUSY error code. The  driver
netlogic/platform_net.c assumes that the platfom_device_register
will always succeed.

Catch this failure during xlr_net_init. Driver should not ignore
return value of platform_device_register.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/netlogic/platform_net.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/netlogic/platform_net.c 
b/drivers/staging/netlogic/platform_net.c
index abf4c71..d8ce50d 100644
--- a/drivers/staging/netlogic/platform_net.c
+++ b/drivers/staging/netlogic/platform_net.c
@@ -130,9 +130,10 @@ static struct platform_device *gmac_controller2_init(void 
*gmac0_addr)
return _net_dev1;
 }
 
-static void xls_gmac_init(void)
+static int xls_gmac_init(void)
 {
int mac;
+   int ret;
struct platform_device *xlr_net_dev1;
void __iomem *gmac0_addr = ioremap(CPHYSADDR(
nlm_mmio_base(NETLOGIC_IO_GMAC_0_OFFSET)), 0xfff);
@@ -171,7 +172,7 @@ static void xls_gmac_init(void)
 
xlr_resource_init(_net0_res[0], xlr_gmac_offsets[0],
  xlr_gmac_irqs[0]);
-   platform_device_register(_net_dev0);
+   ret = platform_device_register(_net_dev0);
 
/* second block is XAUI, not supported yet */
break;
@@ -187,14 +188,20 @@ static void xls_gmac_init(void)
xlr_gmac_irqs[mac]);
}
xlr_net_dev0.num_resources = 8;
-   platform_device_register(_net_dev0);
+   ret = platform_device_register(_net_dev0);
 
xlr_net_dev1 = gmac_controller2_init(gmac0_addr);
-   platform_device_register(xlr_net_dev1);
+   if (ret == 0) {
+   ret = platform_device_register(xlr_net_dev1);
+   if (ret)
+   platform_driver_unregister(_net_dev0);
+   }
+
}
+   return ret;
 }
 
-static void xlr_gmac_init(void)
+static int xlr_gmac_init(void)
 {
int mac;
 
@@ -228,17 +235,18 @@ static void xlr_gmac_init(void)
xlr_net_dev0.num_resources = 8;
xlr_net_dev0.resource = xlr_net0_res;
 
-   platform_device_register(_net_dev0);
+   return platform_device_register(_net_dev0);
 }
 
 static int __init xlr_net_init(void)
 {
+   int ret;
if (nlm_chip_is_xls())
-   xls_gmac_init();
+   ret = xls_gmac_init();
else
-   xlr_gmac_init();
+   ret = xlr_gmac_init();
 
-   return 0;
+   return ret;
 }
 
 arch_initcall(xlr_net_init);
-- 
1.9.1

[Patch v1] netlogic/platform_net: Catch failure to register NETLOGIC_XLR_NET device.

[Arvind Yadav]

This driver Kconfig is depend on CPU_XLR. If default Kconfig
NETLOGIC_XLR_NET value are used with CPU_XLR then you end up
with a resource. This causes __request_resource to return a
conflict which then returns an -EBUSY error code. The  driver
netlogic/platform_net.c assumes that the platfom_device_register
will always succeed.

Catch this failure during xlr_net_init. Driver should not ignore
return value of platform_device_register.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/netlogic/platform_net.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/netlogic/platform_net.c 
b/drivers/staging/netlogic/platform_net.c
index abf4c71..d8ce50d 100644
--- a/drivers/staging/netlogic/platform_net.c
+++ b/drivers/staging/netlogic/platform_net.c
@@ -130,9 +130,10 @@ static struct platform_device *gmac_controller2_init(void 
*gmac0_addr)
return _net_dev1;
 }
 
-static void xls_gmac_init(void)
+static int xls_gmac_init(void)
 {
int mac;
+   int ret;
struct platform_device *xlr_net_dev1;
void __iomem *gmac0_addr = ioremap(CPHYSADDR(
nlm_mmio_base(NETLOGIC_IO_GMAC_0_OFFSET)), 0xfff);
@@ -171,7 +172,7 @@ static void xls_gmac_init(void)
 
xlr_resource_init(_net0_res[0], xlr_gmac_offsets[0],
  xlr_gmac_irqs[0]);
-   platform_device_register(_net_dev0);
+   ret = platform_device_register(_net_dev0);
 
/* second block is XAUI, not supported yet */
break;
@@ -187,14 +188,20 @@ static void xls_gmac_init(void)
xlr_gmac_irqs[mac]);
}
xlr_net_dev0.num_resources = 8;
-   platform_device_register(_net_dev0);
+   ret = platform_device_register(_net_dev0);
 
xlr_net_dev1 = gmac_controller2_init(gmac0_addr);
-   platform_device_register(xlr_net_dev1);
+   if (ret == 0) {
+   ret = platform_device_register(xlr_net_dev1);
+   if (ret)
+   platform_driver_unregister(_net_dev0);
+   }
+
}
+   return ret;
 }
 
-static void xlr_gmac_init(void)
+static int xlr_gmac_init(void)
 {
int mac;
 
@@ -228,17 +235,18 @@ static void xlr_gmac_init(void)
xlr_net_dev0.num_resources = 8;
xlr_net_dev0.resource = xlr_net0_res;
 
-   platform_device_register(_net_dev0);
+   return platform_device_register(_net_dev0);
 }
 
 static int __init xlr_net_init(void)
 {
+   int ret;
if (nlm_chip_is_xls())
-   xls_gmac_init();
+   ret = xls_gmac_init();
else
-   xlr_gmac_init();
+   ret = xlr_gmac_init();
 
-   return 0;
+   return ret;
 }
 
 arch_initcall(xlr_net_init);
-- 
1.9.1

Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

[Dave Chinner]

On Mon, Jul 11, 2016 at 10:02:24AM +0100, Mel Gorman wrote:
> On Mon, Jul 11, 2016 at 10:47:57AM +1000, Dave Chinner wrote:
> > > I had tested XFS with earlier releases and noticed no major problems
> > > so later releases tested only one filesystem.  Given the changes since,
> > > a retest is desirable. I've posted the current version of the series but
> > > I'll queue the tests to run over the weekend. They are quite time 
> > > consuming
> > > to run unfortunately.
> > 
> > Understood. I'm not following the patchset all that closely, so I
> > didn' know you'd already tested XFS.
> > 
> 
> It was needed anyway. Not all of them completed over the weekend. In
> particular, the NUMA machine is taking its time because many of the
> workloads are scaled by memory size and it takes longer.
> 
> > > On the fsmark configuration, I configured the test to use 4K files
> > > instead of 0-sized files that normally would be used to stress inode
> > > creation/deletion. This is to have a mix of page cache and slab
> > > allocations. Shout if this does not suit your expectations.
> > 
> > Sounds fine. I usually limit that test to 10 million inodes - that's
> > my "10-4" test.
> > 
> 
> Thanks.
> 
> 
> I'm not going to go through most of the results in detail. The raw data
> is verbose and not necessarily useful in most cases.

Yup, numbers look pretty good and all my concerns have gone away.
Thanks for testing, Mel! :P

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

[Dave Chinner]

On Mon, Jul 11, 2016 at 10:02:24AM +0100, Mel Gorman wrote:
> On Mon, Jul 11, 2016 at 10:47:57AM +1000, Dave Chinner wrote:
> > > I had tested XFS with earlier releases and noticed no major problems
> > > so later releases tested only one filesystem.  Given the changes since,
> > > a retest is desirable. I've posted the current version of the series but
> > > I'll queue the tests to run over the weekend. They are quite time 
> > > consuming
> > > to run unfortunately.
> > 
> > Understood. I'm not following the patchset all that closely, so I
> > didn' know you'd already tested XFS.
> > 
> 
> It was needed anyway. Not all of them completed over the weekend. In
> particular, the NUMA machine is taking its time because many of the
> workloads are scaled by memory size and it takes longer.
> 
> > > On the fsmark configuration, I configured the test to use 4K files
> > > instead of 0-sized files that normally would be used to stress inode
> > > creation/deletion. This is to have a mix of page cache and slab
> > > allocations. Shout if this does not suit your expectations.
> > 
> > Sounds fine. I usually limit that test to 10 million inodes - that's
> > my "10-4" test.
> > 
> 
> Thanks.
> 
> 
> I'm not going to go through most of the results in detail. The raw data
> is verbose and not necessarily useful in most cases.

Yup, numbers look pretty good and all my concerns have gone away.
Thanks for testing, Mel! :P

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

[NeilBrown]

On Tue, Jul 12 2016, Lars Ellenberg wrote:

>
> Instead, I suggest to distinguish between recursive calls to
> generic_make_request(), and pushing back the remainder part in
> blk_queue_split(), by pointing current->bio_lists to a
>   struct recursion_to_iteration_bio_lists {
>   struct bio_list recursion;
>   struct bio_list queue;
>   }
>
> By providing each q->make_request_fn() with an empty "recursion"
> bio_list, then merging any recursively submitted bios to the
> head of the "queue" list, we can make the recursion-to-iteration
> logic in generic_make_request() process deepest level bios first,
> and "sibling" bios of the same level in "natural" order.
>
> Signed-off-by: Lars Ellenberg 
> Signed-off-by: Roland Kammerer 

Reviewed-by: NeilBrown 

Thanks again for doing this - I think this is a very significant
improvement and could allow other simplifications.

NeilBrown


signature.asc
Description: PGP signature

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

[NeilBrown]

On Tue, Jul 12 2016, Lars Ellenberg wrote:

>
> Instead, I suggest to distinguish between recursive calls to
> generic_make_request(), and pushing back the remainder part in
> blk_queue_split(), by pointing current->bio_lists to a
>   struct recursion_to_iteration_bio_lists {
>   struct bio_list recursion;
>   struct bio_list queue;
>   }
>
> By providing each q->make_request_fn() with an empty "recursion"
> bio_list, then merging any recursively submitted bios to the
> head of the "queue" list, we can make the recursion-to-iteration
> logic in generic_make_request() process deepest level bios first,
> and "sibling" bios of the same level in "natural" order.
>
> Signed-off-by: Lars Ellenberg 
> Signed-off-by: Roland Kammerer 

Reviewed-by: NeilBrown 

Thanks again for doing this - I think this is a very significant
improvement and could allow other simplifications.

NeilBrown


signature.asc
Description: PGP signature

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[河合英宏 / KAWAI，HIDEHIRO]

Hi Dave,

Thanks for the comments.

> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Monday, July 11, 2016 5:35 PM
> 
> On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If crash_kexec_post_notifiers boot option is specified, other CPUs
> > are stopped by smp_send_stop() instead of machine_crash_shutdown()
> > in crash_kexec() path.  This behavior change leads two problems.
> >
> >  Problem 1:
> >  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are
> >  still online and try to stop their watchdog timer.  If
> >  smp_send_stop() is called before octeon_generic_shutdown(), stopping
> >  watchdog timer will fail because other CPUs have been offlined by
> >  smp_send_stop().
> >
> >panic()
> >  if crash_kexec_post_notifiers == 1
> >smp_send_stop()
> >atomic_notifier_call_chain()
> >kmsg_dump()
> >  crash_kexec()
> >machine_crash_shutdown()
> >  octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs
> >
> >  Problem 2:
> >  Most of architectures stop other CPUs in machine_crash_shutdown()
> >  path, and they also do something needed for kdump.  For example,
> >  they save registers, disable virtualization extensions, and so on.
> >  However, if smp_send_stop() stops other CPUs before
> >  machine_crash_shutdown(), we miss those operations.
> >
> > How do we fix these problems?  In the first place, we should stop
> > other CPUs as soon as possible when panic() was called, otherwise
> > other CPUs may wipe out a clue to the cause of the failure.  So, we
> > replace smp_send_stop() with more suitable one for kdump.
> 
> We have been avoiding extra things in panic path, but unfortunately
> crash_kexec_post_notifiers were added. I tend to agree the best place
> for this stuff is in 2nd kernel or purgatory instead of in 1st kernel.

Several months ago, I posted a patch set which writes regs to SEL, generate
an event to send SNMP message, and start/stop BMC's watchdog timer in
purgatory.  This feature requires BMC with KCS (Keyboard Controller Style)
I/F, but the most of enterprise grade server would have it.
(http://thread.gmane.org/gmane.linux.kernel.kexec/15382)

Doing kmsg_dump things in purgatory wouldn't be suitable (should be done
in the 2nd kernel before enabling devices and IRQs?)
 
> As for this patch I'm not sure it is safe to replace the smp_send_stop
> with the kdump friendly function. I'm also not sure if the kdump friendly
> function is safe for kdump. Will glad to hear opinions from other
> arch experts.

This stuff depends on architectures, so I speak only about
x86 (the logic doesn't change on other architectures at this time).

kdump path with crash_kexec_post_notifiers disabled:
 panic()
   __crash_kexec()
 crash_setup_regs()
 crash_save_vmcoreinfo()
 machine_crash_shutdown()
   native_machine_crash_shutdown()
 panic_smp_send_stop() /* mostly same as original 
* kdump_nmi_shootdown_cpus()
*/

kdump path with crash_kexec_post_notifiers enabled:
 panic()
   panic_smp_send_stop()
   __crash_kexec()
 crash_setup_regs()
 crash_save_vmcoreinfo()
 machine_crash_shutdown()
   native_machine_crash_shutdown()
 panic_smp_send_stop() // do nothing

The difference is that stopping other CPUs before crash_setup_regs()
and crash_save_vmcoreinfo() or not.  Since crash_setup_regs() and
crash_save_vmcoreinfo() just save information to some memory area, 
they wouldn't be affected by panic_smp_send_stop().  This means
placing panic_smp_send_stop before __crash_kexec is safe.

BTW, I noticed my patch breaks Xen kernel.  I'll fix it in the
next version.

> BTW, if one want to use crash_kexec_post_notifiers he should take the
> risk of unreliable kdump. How about only call smp_send_stop in case no
> crash_kexec_post_notifiers being used.

Unlike panic_smp_send_stop()/kdump_nmi_shootdown_cpus(), smp_send_stop()
for x86 tries to stop other CPUs with normal IPI before issuing NMI IPI.
This would be because NMI IPI has a risk of deadlock.  We checked if
the kdump path has a risk of deadlock in the case of NMI panic and fixed
it.  But I'm not sure about normal panic path.  I agree with that use
smp_send_stop if crash_kexec_post_notifiers or kdump is disabled.

> > This patch solves Problem 2 by replacing smp_send_stop() in panic()
> > with panic_smp_send_stop().  This is a weak function which calls
> > smp_send_stop(), and architecture dependent code may override this
> > with appropriate one.  This patch only provides x86-specific version.
> 
> It does not fix the Problem 1, it seem not possible to fix it?

Problem 1 depends on architectures, and at least it doesn't happen
on x86.  I can try to fix the Problem 1 for MIPS, but I can't test it.
Possible solution will be to use an smp_send_stop variant which stop
the CPU 

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[河合英宏 / KAWAI，HIDEHIRO]

Hi Dave,

Thanks for the comments.

> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Monday, July 11, 2016 5:35 PM
> 
> On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If crash_kexec_post_notifiers boot option is specified, other CPUs
> > are stopped by smp_send_stop() instead of machine_crash_shutdown()
> > in crash_kexec() path.  This behavior change leads two problems.
> >
> >  Problem 1:
> >  octeon_generic_shutdown() for MIPS OCTEON assumes that other CPUs are
> >  still online and try to stop their watchdog timer.  If
> >  smp_send_stop() is called before octeon_generic_shutdown(), stopping
> >  watchdog timer will fail because other CPUs have been offlined by
> >  smp_send_stop().
> >
> >panic()
> >  if crash_kexec_post_notifiers == 1
> >smp_send_stop()
> >atomic_notifier_call_chain()
> >kmsg_dump()
> >  crash_kexec()
> >machine_crash_shutdown()
> >  octeon_generic_shutdown() // shutdown watchdog for ONLINE CPUs
> >
> >  Problem 2:
> >  Most of architectures stop other CPUs in machine_crash_shutdown()
> >  path, and they also do something needed for kdump.  For example,
> >  they save registers, disable virtualization extensions, and so on.
> >  However, if smp_send_stop() stops other CPUs before
> >  machine_crash_shutdown(), we miss those operations.
> >
> > How do we fix these problems?  In the first place, we should stop
> > other CPUs as soon as possible when panic() was called, otherwise
> > other CPUs may wipe out a clue to the cause of the failure.  So, we
> > replace smp_send_stop() with more suitable one for kdump.
> 
> We have been avoiding extra things in panic path, but unfortunately
> crash_kexec_post_notifiers were added. I tend to agree the best place
> for this stuff is in 2nd kernel or purgatory instead of in 1st kernel.

Several months ago, I posted a patch set which writes regs to SEL, generate
an event to send SNMP message, and start/stop BMC's watchdog timer in
purgatory.  This feature requires BMC with KCS (Keyboard Controller Style)
I/F, but the most of enterprise grade server would have it.
(http://thread.gmane.org/gmane.linux.kernel.kexec/15382)

Doing kmsg_dump things in purgatory wouldn't be suitable (should be done
in the 2nd kernel before enabling devices and IRQs?)
 
> As for this patch I'm not sure it is safe to replace the smp_send_stop
> with the kdump friendly function. I'm also not sure if the kdump friendly
> function is safe for kdump. Will glad to hear opinions from other
> arch experts.

This stuff depends on architectures, so I speak only about
x86 (the logic doesn't change on other architectures at this time).

kdump path with crash_kexec_post_notifiers disabled:
 panic()
   __crash_kexec()
 crash_setup_regs()
 crash_save_vmcoreinfo()
 machine_crash_shutdown()
   native_machine_crash_shutdown()
 panic_smp_send_stop() /* mostly same as original 
* kdump_nmi_shootdown_cpus()
*/

kdump path with crash_kexec_post_notifiers enabled:
 panic()
   panic_smp_send_stop()
   __crash_kexec()
 crash_setup_regs()
 crash_save_vmcoreinfo()
 machine_crash_shutdown()
   native_machine_crash_shutdown()
 panic_smp_send_stop() // do nothing

The difference is that stopping other CPUs before crash_setup_regs()
and crash_save_vmcoreinfo() or not.  Since crash_setup_regs() and
crash_save_vmcoreinfo() just save information to some memory area, 
they wouldn't be affected by panic_smp_send_stop().  This means
placing panic_smp_send_stop before __crash_kexec is safe.

BTW, I noticed my patch breaks Xen kernel.  I'll fix it in the
next version.

> BTW, if one want to use crash_kexec_post_notifiers he should take the
> risk of unreliable kdump. How about only call smp_send_stop in case no
> crash_kexec_post_notifiers being used.

Unlike panic_smp_send_stop()/kdump_nmi_shootdown_cpus(), smp_send_stop()
for x86 tries to stop other CPUs with normal IPI before issuing NMI IPI.
This would be because NMI IPI has a risk of deadlock.  We checked if
the kdump path has a risk of deadlock in the case of NMI panic and fixed
it.  But I'm not sure about normal panic path.  I agree with that use
smp_send_stop if crash_kexec_post_notifiers or kdump is disabled.

> > This patch solves Problem 2 by replacing smp_send_stop() in panic()
> > with panic_smp_send_stop().  This is a weak function which calls
> > smp_send_stop(), and architecture dependent code may override this
> > with appropriate one.  This patch only provides x86-specific version.
> 
> It does not fix the Problem 1, it seem not possible to fix it?

Problem 1 depends on architectures, and at least it doesn't happen
on x86.  I can try to fix the Problem 1 for MIPS, but I can't test it.
Possible solution will be to use an smp_send_stop variant which stop
the CPU 

Re: [PATCH v4 1/3] dt-bindings: auxadc: Add binding document for Mediatek auxadc.

[zhiyong tao]

On Mon, 2016-07-11 at 14:39 +0800, Zhiyong Tao wrote:
> The commit adds the device tree binding documentation for the mediatek
> auxadc found on Mediatek MT2701.
> Thermal gets auxadc sample data by iio device.
> So the commit changes auxadc device tree binding documentation from
> /soc/mediatek/auxadc.txt to /iio/adc/mt6577_auxadc.txt.
> 
> Signed-off-by: Zhiyong Tao 
> ---

I forgot that I should use the command 'git format-patch -M' to submit
this patch. The follow information is the patch after executing the
above command. If the patch needs to be resent, please help to notify
me. I will resend the patch quickly.
The follow information:

 .../auxadc.txt => iio/adc/mt6577_auxadc.txt}   |   16
+++-
 1 file changed, 11 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/{soc/mediatek/auxadc.txt =>
iio/adc/mt6577_auxadc.txt} (50%)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
similarity index 50%
rename from Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
rename to Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
index bdb7829..bc23792 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
@@ -1,4 +1,4 @@
-MediaTek AUXADC
+* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc
(mt65xx/mt81xx/mt27xx)
 ===

 The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
@@ -10,12 +10,18 @@
Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
 for the Thermal Controller which holds a phandle to the AUXADC.

 Required properties:
-- compatible: Must be "mediatek,mt8173-auxadc"
-- reg: Address range of the AUXADC unit
+  - compatible: "mediatek,mt2701-auxadc" or "mediatek,mt8173-auxadc"
+  - reg: Address range of the AUXADC unit.
+  - clocks: Should contain a clock specifier for each entry in
clock-names
+  - clock-names: Should contain "main".
+  - #io-channel-cells: Should be 1, see ../iio-bindings.txt

 Example:

-auxadc: auxadc@11001000 {
-   compatible = "mediatek,mt8173-auxadc";
+auxadc: adc@11001000 {
+   compatible = "mediatek,mt2701-auxadc";
reg = <0 0x11001000 0 0x1000>;
+   clocks = < CLK_PERI_AUXADC>;
+   clock-names = "main";
+   #io-channel-cells = <1>;
 };
-- 
1.7.9.5


>  .../devicetree/bindings/iio/adc/mt6577_auxadc.txt  |   27 
> 
>  .../devicetree/bindings/soc/mediatek/auxadc.txt|   21 ---
>  2 files changed, 27 insertions(+), 21 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
>  delete mode 100644 Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
> new file mode 100644
> index 000..bc23792
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
> @@ -0,0 +1,27 @@
> +* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc 
> (mt65xx/mt81xx/mt27xx)
> +===
> +
> +The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
> +in some Mediatek SoCs which among other things measures the temperatures
> +in the SoC. It can be used directly with register accesses, but it is also
> +used by thermal controller which reads the temperatures from the AUXADC
> +directly via its own bus interface. See
> +Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> +for the Thermal Controller which holds a phandle to the AUXADC.
> +
> +Required properties:
> +  - compatible: "mediatek,mt2701-auxadc" or "mediatek,mt8173-auxadc"
> +  - reg: Address range of the AUXADC unit.
> +  - clocks: Should contain a clock specifier for each entry in clock-names
> +  - clock-names: Should contain "main".
> +  - #io-channel-cells: Should be 1, see ../iio-bindings.txt
> +
> +Example:
> +
> +auxadc: adc@11001000 {
> + compatible = "mediatek,mt2701-auxadc";
> + reg = <0 0x11001000 0 0x1000>;
> + clocks = < CLK_PERI_AUXADC>;
> + clock-names = "main";
> + #io-channel-cells = <1>;
> +};
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt 
> b/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
> deleted file mode 100644
> index bdb7829..000
> --- a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -MediaTek AUXADC
> -===
> -
> -The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
> -in some Mediatek SoCs which among other things measures the temperatures
> -in the SoC. It can be used directly with register accesses, but it is also
> -used by thermal controller which reads the temperatures from the AUXADC
> -directly via its own bus interface. See
> 

Re: [PATCH v4 1/3] dt-bindings: auxadc: Add binding document for Mediatek auxadc.

[zhiyong tao]

On Mon, 2016-07-11 at 14:39 +0800, Zhiyong Tao wrote:
> The commit adds the device tree binding documentation for the mediatek
> auxadc found on Mediatek MT2701.
> Thermal gets auxadc sample data by iio device.
> So the commit changes auxadc device tree binding documentation from
> /soc/mediatek/auxadc.txt to /iio/adc/mt6577_auxadc.txt.
> 
> Signed-off-by: Zhiyong Tao 
> ---

I forgot that I should use the command 'git format-patch -M' to submit
this patch. The follow information is the patch after executing the
above command. If the patch needs to be resent, please help to notify
me. I will resend the patch quickly.
The follow information:

 .../auxadc.txt => iio/adc/mt6577_auxadc.txt}   |   16
+++-
 1 file changed, 11 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/{soc/mediatek/auxadc.txt =>
iio/adc/mt6577_auxadc.txt} (50%)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
similarity index 50%
rename from Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
rename to Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
index bdb7829..bc23792 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
@@ -1,4 +1,4 @@
-MediaTek AUXADC
+* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc
(mt65xx/mt81xx/mt27xx)
 ===

 The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
@@ -10,12 +10,18 @@
Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
 for the Thermal Controller which holds a phandle to the AUXADC.

 Required properties:
-- compatible: Must be "mediatek,mt8173-auxadc"
-- reg: Address range of the AUXADC unit
+  - compatible: "mediatek,mt2701-auxadc" or "mediatek,mt8173-auxadc"
+  - reg: Address range of the AUXADC unit.
+  - clocks: Should contain a clock specifier for each entry in
clock-names
+  - clock-names: Should contain "main".
+  - #io-channel-cells: Should be 1, see ../iio-bindings.txt

 Example:

-auxadc: auxadc@11001000 {
-   compatible = "mediatek,mt8173-auxadc";
+auxadc: adc@11001000 {
+   compatible = "mediatek,mt2701-auxadc";
reg = <0 0x11001000 0 0x1000>;
+   clocks = < CLK_PERI_AUXADC>;
+   clock-names = "main";
+   #io-channel-cells = <1>;
 };
-- 
1.7.9.5


>  .../devicetree/bindings/iio/adc/mt6577_auxadc.txt  |   27 
> 
>  .../devicetree/bindings/soc/mediatek/auxadc.txt|   21 ---
>  2 files changed, 27 insertions(+), 21 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
>  delete mode 100644 Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
> new file mode 100644
> index 000..bc23792
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
> @@ -0,0 +1,27 @@
> +* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc 
> (mt65xx/mt81xx/mt27xx)
> +===
> +
> +The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
> +in some Mediatek SoCs which among other things measures the temperatures
> +in the SoC. It can be used directly with register accesses, but it is also
> +used by thermal controller which reads the temperatures from the AUXADC
> +directly via its own bus interface. See
> +Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> +for the Thermal Controller which holds a phandle to the AUXADC.
> +
> +Required properties:
> +  - compatible: "mediatek,mt2701-auxadc" or "mediatek,mt8173-auxadc"
> +  - reg: Address range of the AUXADC unit.
> +  - clocks: Should contain a clock specifier for each entry in clock-names
> +  - clock-names: Should contain "main".
> +  - #io-channel-cells: Should be 1, see ../iio-bindings.txt
> +
> +Example:
> +
> +auxadc: adc@11001000 {
> + compatible = "mediatek,mt2701-auxadc";
> + reg = <0 0x11001000 0 0x1000>;
> + clocks = < CLK_PERI_AUXADC>;
> + clock-names = "main";
> + #io-channel-cells = <1>;
> +};
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt 
> b/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
> deleted file mode 100644
> index bdb7829..000
> --- a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -MediaTek AUXADC
> -===
> -
> -The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
> -in some Mediatek SoCs which among other things measures the temperatures
> -in the SoC. It can be used directly with register accesses, but it is also
> -used by thermal controller which reads the temperatures from the AUXADC
> -directly via its own bus interface. See
> -Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
> -for the 

Re: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

[David Miller]

From: Mario Limonciello 
Date: Mon, 11 Jul 2016 19:58:04 -0500

> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
> 
> This information for the system's persistent MAC address is burned in when
> the system HW is built and available under \_SB.AMAC in the DSDT at runtime.
> 
> This technology is currently implemented in the Dell TB15 and WD15 Type-C
> docks.  More information is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 

Applied.

Re: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

[David Miller]

From: Mario Limonciello 
Date: Mon, 11 Jul 2016 19:58:04 -0500

> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
> 
> This information for the system's persistent MAC address is burned in when
> the system HW is built and available under \_SB.AMAC in the DSDT at runtime.
> 
> This technology is currently implemented in the Dell TB15 and WD15 Type-C
> docks.  More information is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 

Applied.

Re: [PATCH v3 3/4] perf annotate: add powerpc support

[Arnaldo Carvalho de Melo]

Em Tue, Jul 12, 2016 at 07:51:46AM +0530, Ravi Bangoria escreveu:
> Hi Arnaldo,
> 
> On Friday 08 July 2016 02:01 PM, Michael Ellerman wrote:
> > Ravi Bangoria  writes:
> > 
> > > On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote:
> > > 
> > > I've sent v4 which enables annotate for bctr' instructions.
> > > 
> > > for 'bctr', it will show down arrow(indicate jump) and 'bctrl' will show
> > > right arrow(indicate call). But no navigation options will be provided.
> > > By pressing Enter key on that, message will be shown that like
> > > "Invalid target"
> > Great thanks.
> 
> I've sent v4 series. Please review it.

If somebody else could do it and provide acks/reviewed by, that would
help,

Michael, can I get your comments as such?

Thanks,

- Arnaldo
 
> -Ravi
> 
> > > > > > It doesn't look like we have the opcode handy here? Could we get it 
> > > > > > somehow?
> > > > > > That would make this a *lot* more robust.
> > > > > objdump prints machine code, but I don't know how difficult that would
> > > > > be to parse to get opcode.
> > > > Normal objdump -d output includes the opcode, eg:
> > > > 
> > > > c000886c:   2c 2c 00 00 cmpdi   r12,0
> > > >   ^^^
> > > > 
> > > > The only thing you need to know is the endian and you can reconstruct
> > > > the raw instruction.
> > > > 
> > > > Then you can just decode the opcode, see how we do it in the kernel with
> > > > eg. instr_is_relative_branch().
> > > I'm sorry. I was thinking that you wants to show opcodes with perf
> > > annotate. But you were asking to use opcode instead of parsing
> > > instructions.
> > Yeah.
> > 
> > > This looks like rewrite parsing code. I don't know whether there is any
> > > library already available for this which we can directly use. I'm thinking
> > > about this.
> > OK don't worry about it for now. We should get this merged for starters
> > and we can always improve it later.
> > 
> > cheers
> > 

Re: [PATCH v3 3/4] perf annotate: add powerpc support

[Arnaldo Carvalho de Melo]

Em Tue, Jul 12, 2016 at 07:51:46AM +0530, Ravi Bangoria escreveu:
> Hi Arnaldo,
> 
> On Friday 08 July 2016 02:01 PM, Michael Ellerman wrote:
> > Ravi Bangoria  writes:
> > 
> > > On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote:
> > > 
> > > I've sent v4 which enables annotate for bctr' instructions.
> > > 
> > > for 'bctr', it will show down arrow(indicate jump) and 'bctrl' will show
> > > right arrow(indicate call). But no navigation options will be provided.
> > > By pressing Enter key on that, message will be shown that like
> > > "Invalid target"
> > Great thanks.
> 
> I've sent v4 series. Please review it.

If somebody else could do it and provide acks/reviewed by, that would
help,

Michael, can I get your comments as such?

Thanks,

- Arnaldo
 
> -Ravi
> 
> > > > > > It doesn't look like we have the opcode handy here? Could we get it 
> > > > > > somehow?
> > > > > > That would make this a *lot* more robust.
> > > > > objdump prints machine code, but I don't know how difficult that would
> > > > > be to parse to get opcode.
> > > > Normal objdump -d output includes the opcode, eg:
> > > > 
> > > > c000886c:   2c 2c 00 00 cmpdi   r12,0
> > > >   ^^^
> > > > 
> > > > The only thing you need to know is the endian and you can reconstruct
> > > > the raw instruction.
> > > > 
> > > > Then you can just decode the opcode, see how we do it in the kernel with
> > > > eg. instr_is_relative_branch().
> > > I'm sorry. I was thinking that you wants to show opcodes with perf
> > > annotate. But you were asking to use opcode instead of parsing
> > > instructions.
> > Yeah.
> > 
> > > This looks like rewrite parsing code. I don't know whether there is any
> > > library already available for this which we can directly use. I'm thinking
> > > about this.
> > OK don't worry about it for now. We should get this merged for starters
> > and we can always improve it later.
> > 
> > cheers
> > 

[RFC PATCH 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI

[Dongdong Liu]

re-architect the Hip05/Hip06 host controllers driver to prepare
for the ACPI based driver.
The common functions used also by the ACPI driver have been grouped
into a new "common" file.

Signed-off-by: Gabriele Paoloni 
Signed-off-by: Dongdong Liu 
---
 MAINTAINERS |   2 +
 drivers/pci/host/Makefile   |   2 +-
 drivers/pci/host/pcie-hisi-common.c |  66 ++
 drivers/pci/host/pcie-hisi.c| 110 ++--
 drivers/pci/host/pcie-hisi.h|  23 
 5 files changed, 123 insertions(+), 80 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index ed42cb6..7e8e2c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8829,7 +8829,9 @@ M:Gabriele Paoloni 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+F: drivers/pci/host/pcie-hisi.h
 F: drivers/pci/host/pcie-hisi.c
+F: drivers/pci/host/pcie-hisi-common.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M: Stanimir Varbanov 
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 5fadfd9..05950f3 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
-obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pcie-hisi-common.c 
b/drivers/pci/host/pcie-hisi-common.c
new file mode 100644
index 000..5a5f269
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-common.c
@@ -0,0 +1,66 @@
+/*
+ * PCIe host controller common functions for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang 
+ * Dacai Zhu 
+ * Gabriele Paoloni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include "pcie-hisi.h"
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
+ u32 *val)
+{
+   u32 reg;
+   u32 reg_val;
+   void *walker = _val;
+
+   walker += (where & 0x3);
+   reg = where & ~0x3;
+   reg_val = readl(reg_base + reg);
+
+   if (size == 1)
+   *val = *(u8 __force *) walker;
+   else if (size == 2)
+   *val = *(u16 __force *) walker;
+   else if (size == 4)
+   *val = reg_val;
+   else
+   return PCIBIOS_BAD_REGISTER_NUMBER;
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_write(void __iomem *reg_base, int where, int  size,
+   u32 val)
+{
+   u32 reg_val;
+   u32 reg;
+   void *walker = _val;
+
+   walker += (where & 0x3);
+   reg = where & ~0x3;
+   if (size == 4)
+   writel(val, reg_base + reg);
+   else if (size == 2) {
+   reg_val = readl(reg_base + reg);
+   *(u16 __force *) walker = val;
+   writel(reg_val, reg_base + reg);
+   } else if (size == 1) {
+   reg_val = readl(reg_base + reg);
+   *(u8 __force *) walker = val;
+   writel(reg_val, reg_base + reg);
+   } else
+   return PCIBIOS_BAD_REGISTER_NUMBER;
+
+   return PCIBIOS_SUCCESSFUL;
+}
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 3e98d4e..086af15 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -21,6 +21,7 @@
 #include 
 
 #include "pcie-designware.h"
+#include "pcie-hisi.h"
 
 #define PCIE_LTSSM_LINKUP_STATE0x11
 #define PCIE_LTSSM_STATE_MASK  0x3F
@@ -30,12 +31,6 @@
 
 #define to_hisi_pcie(x)container_of(x, struct hisi_pcie, pp)
 
-struct hisi_pcie;
-
-struct pcie_soc_ops {
-   int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
-};
-
 struct hisi_pcie {
struct regmap *subctrl;
void __iomem *reg_base;
@@ -44,87 +39,24 @@ struct hisi_pcie {
struct pcie_soc_ops *soc_ops;
 };
 
-static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
-   u32 

[RFC PATCH 2/3] PCI: hisi: Add ECAM support for devices that are not RC

[Dongdong Liu]

This patch modifies the current Hip05/Hip06 PCIe host
controller driver to add support for 'almost ECAM'
compliant platforms. Some controllers are ECAM compliant
for all the devices of the hierarchy except the root
complex; this patch adds support for such controllers.

This is needed in preparation for the ACPI based driver
to allow both DT and ACPI drivers to use the same BIOS
(that configure the Designware iATUs).
This commit doesn't break backward compatibility with
previous non-ECAM platforms.

Signed-off-by: Gabriele Paoloni 
Signed-off-by: Dongdong Liu 
---
 .../devicetree/bindings/pci/hisilicon-pcie.txt | 15 +---
 drivers/pci/host/pcie-designware.c |  3 +-
 drivers/pci/host/pcie-designware.h |  2 +
 drivers/pci/host/pcie-hisi.c   | 43 ++
 4 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt 
b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
index 59c2f47..87a597a 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -9,10 +9,13 @@ Additional properties are described here:
 
 Required properties
 - compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
-- reg: Should contain rc_dbi, config registers location and length.
-- reg-names: Must include the following entries:
+- reg: Should contain rc_dbi and  either config or ecam-cfg registers
+   location and length (it depends on the platform BIOS).
+- reg-names: Must include
   "rc_dbi": controller configuration registers;
-  "config": PCIe configuration space registers.
+  and one of the following entries:
+"config": PCIe configuration space registers for non-ECAM platforms.
+"ecam-cfg": PCIe configuration space registers for ECAM platforms
 - msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
 - port-id: Should be 0, 1, 2 or 3.
 
@@ -23,8 +26,10 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
pcie@0xb008 {
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
-   reg = <0 0xb008 0 0x1>, <0x220 0x 0 0x2000>;
-   reg-names = "rc_dbi", "config";
+   reg = <0 0xb008 0 0x1>,
+ <0x220 0x 0 0x2000>
+   /* or <0x220 0x0010 0 0x0f0> for ecam-cfg*/;
+   reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
bus-range = <0  15>;
msi-parent = <_pcie>;
#address-cells = <3>;
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index aafd766..239eb39 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -75,7 +75,6 @@
 #define PCIE_PHY_DEBUG_R1  (PLR_OFFSET + 0x2c)
 #define PCIE_PHY_DEBUG_R1_LINK_UP  0x0010
 
-static struct pci_ops dw_pcie_ops;
 
 int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
 {
@@ -700,7 +699,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
 }
 
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
.read = dw_pcie_rd_conf,
.write = dw_pcie_wr_conf,
 };
diff --git a/drivers/pci/host/pcie-designware.h 
b/drivers/pci/host/pcie-designware.h
index f437f9b..234f360 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -86,4 +86,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
 
+extern struct pci_ops dw_pcie_ops;
+
 #endif /* _PCIE_DESIGNWARE_H */
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 086af15..c42ef84 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -43,6 +43,18 @@ struct pcie_soc_ops {
int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
 };
 
+static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 *value)
+{
+   return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 value)
+{
+   return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
 static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
int size, u32 *val)
 {
@@ -72,6 +84,20 @@ static struct pcie_host_ops hisi_pcie_host_ops = {
.link_up = hisi_pcie_link_up,
 };
 
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+ unsigned int devfn,
+ 

[RFC PATCH 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

[Dongdong Liu]

Add specific quirks for PCI config space accessors.This involves:
1. New initialization call hisi_pcie_acpi_init() to get RC config resource
with hardcoded range address and setup ecam mapping.
2. New entry in common quirk array.

Signed-off-by: Dongdong Liu 
Signed-off-by: Gabriele Paoloni 
---
 MAINTAINERS   |   1 +
 drivers/pci/host/Kconfig  |   7 ++
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/mcfg-quirks.c|   8 ++
 drivers/pci/host/mcfg-quirks.h|   8 ++
 drivers/pci/host/pcie-hisi-acpi.c | 151 ++
 drivers/pci/host/pcie-hisi.c  |   2 -
 drivers/pci/host/pcie-hisi.h  |   2 +
 8 files changed, 178 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7e8e2c9..c51c736 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8832,6 +8832,7 @@ F:
Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/host/pcie-hisi.h
 F: drivers/pci/host/pcie-hisi.c
 F: drivers/pci/host/pcie-hisi-common.c
+F: drivers/pci/host/pcie-hisi-acpi.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M: Stanimir Varbanov 
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 5d2374e..15b73a6 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -210,6 +210,13 @@ config PCI_HISI
  Say Y here if you want PCIe controller support on HiSilicon
  Hip05 and Hip06 SoCs
 
+config PCI_HISI_ACPI
+   depends on ACPI && ARM64
+   bool "HiSilicon Hip05 and Hip06 SoCs ACPI PCIe controllers"
+   help
+ Say Y here if you want ACPI PCIe controller support on HiSilicon
+ Hip05 and Hip06 SoCs
+
 config PCIE_QCOM
bool "Qualcomm PCIe controller"
depends on ARCH_QCOM && OF
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 05950f3..4843142 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
+obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
index a4bb76a..e65cd99 100644
--- a/drivers/pci/host/mcfg-quirks.c
+++ b/drivers/pci/host/mcfg-quirks.c
@@ -51,6 +51,14 @@ static struct pci_cfg_fixup mcfg_qurks[] __initconst = {
{ "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY,
  NULL, thunder_pem_cfg_init},
 #endif
+#ifdef CONFIG_PCI_HISI_ACPI
+   { "HISI", "HISI0660", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
+ NULL, hisi_pcie_acpi_hip05_init},
+   { "HISI", "HISI1610", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
+ NULL, hisi_pcie_acpi_hip06_init},
+   { "HISI", "HISI1612", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
+ NULL, hisi_pcie_acpi_hip06_init},
+#endif
 };
 
 static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
diff --git a/drivers/pci/host/mcfg-quirks.h b/drivers/pci/host/mcfg-quirks.h
index 411c667..a2d2aaa 100644
--- a/drivers/pci/host/mcfg-quirks.h
+++ b/drivers/pci/host/mcfg-quirks.h
@@ -21,4 +21,12 @@ struct pci_config_window *
 thunder_pem_cfg_init(struct acpi_pci_root *root, struct pci_ops *ops);
 #endif
 
+#ifdef CONFIG_PCI_HISI_ACPI
+struct pci_config_window *
+hisi_pcie_acpi_hip05_init(struct acpi_pci_root *root, struct pci_ops *ops);
+
+struct pci_config_window *
+hisi_pcie_acpi_hip06_init(struct acpi_pci_root *root, struct pci_ops *ops);
+#endif
+
 #endif /* __MCFG_QUIRKS_H__ */
diff --git a/drivers/pci/host/pcie-hisi-acpi.c 
b/drivers/pci/host/pcie-hisi-acpi.c
new file mode 100644
index 000..93572d0
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-acpi.c
@@ -0,0 +1,151 @@
+/*
+ * PCIe host controller driver for HiSilicon HipXX SoCs
+ *
+ * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Dongdong Liu 
+ * Gabriele Paoloni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+
+#include "mcfg-quirks.h"
+#include "pcie-hisi.h"
+
+#define DEBUG0  0x728
+#define RC_NUM  4
+
+enum soc_type {
+   HIP05,
+   HIP06,
+};
+
+struct hisi_rc_res {
+   int soc_type;
+   struct resource res[RC_NUM];
+};
+
+static int hisi_pcie_link_up_acpi(struct pci_config_window *cfg)
+{
+   u32 val;
+   void __iomem *reg_base = cfg->priv;
+
+   

[RFC PATCH 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI

[Dongdong Liu]

re-architect the Hip05/Hip06 host controllers driver to prepare
for the ACPI based driver.
The common functions used also by the ACPI driver have been grouped
into a new "common" file.

Signed-off-by: Gabriele Paoloni 
Signed-off-by: Dongdong Liu 
---
 MAINTAINERS |   2 +
 drivers/pci/host/Makefile   |   2 +-
 drivers/pci/host/pcie-hisi-common.c |  66 ++
 drivers/pci/host/pcie-hisi.c| 110 ++--
 drivers/pci/host/pcie-hisi.h|  23 
 5 files changed, 123 insertions(+), 80 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index ed42cb6..7e8e2c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8829,7 +8829,9 @@ M:Gabriele Paoloni 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+F: drivers/pci/host/pcie-hisi.h
 F: drivers/pci/host/pcie-hisi.c
+F: drivers/pci/host/pcie-hisi-common.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M: Stanimir Varbanov 
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 5fadfd9..05950f3 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
-obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pcie-hisi-common.c 
b/drivers/pci/host/pcie-hisi-common.c
new file mode 100644
index 000..5a5f269
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-common.c
@@ -0,0 +1,66 @@
+/*
+ * PCIe host controller common functions for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang 
+ * Dacai Zhu 
+ * Gabriele Paoloni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include "pcie-hisi.h"
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
+ u32 *val)
+{
+   u32 reg;
+   u32 reg_val;
+   void *walker = _val;
+
+   walker += (where & 0x3);
+   reg = where & ~0x3;
+   reg_val = readl(reg_base + reg);
+
+   if (size == 1)
+   *val = *(u8 __force *) walker;
+   else if (size == 2)
+   *val = *(u16 __force *) walker;
+   else if (size == 4)
+   *val = reg_val;
+   else
+   return PCIBIOS_BAD_REGISTER_NUMBER;
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_write(void __iomem *reg_base, int where, int  size,
+   u32 val)
+{
+   u32 reg_val;
+   u32 reg;
+   void *walker = _val;
+
+   walker += (where & 0x3);
+   reg = where & ~0x3;
+   if (size == 4)
+   writel(val, reg_base + reg);
+   else if (size == 2) {
+   reg_val = readl(reg_base + reg);
+   *(u16 __force *) walker = val;
+   writel(reg_val, reg_base + reg);
+   } else if (size == 1) {
+   reg_val = readl(reg_base + reg);
+   *(u8 __force *) walker = val;
+   writel(reg_val, reg_base + reg);
+   } else
+   return PCIBIOS_BAD_REGISTER_NUMBER;
+
+   return PCIBIOS_SUCCESSFUL;
+}
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 3e98d4e..086af15 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -21,6 +21,7 @@
 #include 
 
 #include "pcie-designware.h"
+#include "pcie-hisi.h"
 
 #define PCIE_LTSSM_LINKUP_STATE0x11
 #define PCIE_LTSSM_STATE_MASK  0x3F
@@ -30,12 +31,6 @@
 
 #define to_hisi_pcie(x)container_of(x, struct hisi_pcie, pp)
 
-struct hisi_pcie;
-
-struct pcie_soc_ops {
-   int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
-};
-
 struct hisi_pcie {
struct regmap *subctrl;
void __iomem *reg_base;
@@ -44,87 +39,24 @@ struct hisi_pcie {
struct pcie_soc_ops *soc_ops;
 };
 
-static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
-   u32 val, u32 reg)
-{
-   writel(val, pcie->reg_base + reg);
-}
-
-static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
-{
-   return readl(pcie->reg_base + reg);

[RFC PATCH 2/3] PCI: hisi: Add ECAM support for devices that are not RC

[Dongdong Liu]

This patch modifies the current Hip05/Hip06 PCIe host
controller driver to add support for 'almost ECAM'
compliant platforms. Some controllers are ECAM compliant
for all the devices of the hierarchy except the root
complex; this patch adds support for such controllers.

This is needed in preparation for the ACPI based driver
to allow both DT and ACPI drivers to use the same BIOS
(that configure the Designware iATUs).
This commit doesn't break backward compatibility with
previous non-ECAM platforms.

Signed-off-by: Gabriele Paoloni 
Signed-off-by: Dongdong Liu 
---
 .../devicetree/bindings/pci/hisilicon-pcie.txt | 15 +---
 drivers/pci/host/pcie-designware.c |  3 +-
 drivers/pci/host/pcie-designware.h |  2 +
 drivers/pci/host/pcie-hisi.c   | 43 ++
 4 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt 
b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
index 59c2f47..87a597a 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -9,10 +9,13 @@ Additional properties are described here:
 
 Required properties
 - compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
-- reg: Should contain rc_dbi, config registers location and length.
-- reg-names: Must include the following entries:
+- reg: Should contain rc_dbi and  either config or ecam-cfg registers
+   location and length (it depends on the platform BIOS).
+- reg-names: Must include
   "rc_dbi": controller configuration registers;
-  "config": PCIe configuration space registers.
+  and one of the following entries:
+"config": PCIe configuration space registers for non-ECAM platforms.
+"ecam-cfg": PCIe configuration space registers for ECAM platforms
 - msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
 - port-id: Should be 0, 1, 2 or 3.
 
@@ -23,8 +26,10 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
pcie@0xb008 {
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
-   reg = <0 0xb008 0 0x1>, <0x220 0x 0 0x2000>;
-   reg-names = "rc_dbi", "config";
+   reg = <0 0xb008 0 0x1>,
+ <0x220 0x 0 0x2000>
+   /* or <0x220 0x0010 0 0x0f0> for ecam-cfg*/;
+   reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
bus-range = <0  15>;
msi-parent = <_pcie>;
#address-cells = <3>;
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index aafd766..239eb39 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -75,7 +75,6 @@
 #define PCIE_PHY_DEBUG_R1  (PLR_OFFSET + 0x2c)
 #define PCIE_PHY_DEBUG_R1_LINK_UP  0x0010
 
-static struct pci_ops dw_pcie_ops;
 
 int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
 {
@@ -700,7 +699,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
 }
 
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
.read = dw_pcie_rd_conf,
.write = dw_pcie_wr_conf,
 };
diff --git a/drivers/pci/host/pcie-designware.h 
b/drivers/pci/host/pcie-designware.h
index f437f9b..234f360 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -86,4 +86,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
 
+extern struct pci_ops dw_pcie_ops;
+
 #endif /* _PCIE_DESIGNWARE_H */
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 086af15..c42ef84 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -43,6 +43,18 @@ struct pcie_soc_ops {
int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
 };
 
+static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 *value)
+{
+   return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 value)
+{
+   return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
 static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
int size, u32 *val)
 {
@@ -72,6 +84,20 @@ static struct pcie_host_ops hisi_pcie_host_ops = {
.link_up = hisi_pcie_link_up,
 };
 
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+ unsigned int devfn,
+ int where)
+{
+   

[RFC PATCH 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

[Dongdong Liu]

Add specific quirks for PCI config space accessors.This involves:
1. New initialization call hisi_pcie_acpi_init() to get RC config resource
with hardcoded range address and setup ecam mapping.
2. New entry in common quirk array.

Signed-off-by: Dongdong Liu 
Signed-off-by: Gabriele Paoloni 
---
 MAINTAINERS   |   1 +
 drivers/pci/host/Kconfig  |   7 ++
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/mcfg-quirks.c|   8 ++
 drivers/pci/host/mcfg-quirks.h|   8 ++
 drivers/pci/host/pcie-hisi-acpi.c | 151 ++
 drivers/pci/host/pcie-hisi.c  |   2 -
 drivers/pci/host/pcie-hisi.h  |   2 +
 8 files changed, 178 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7e8e2c9..c51c736 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8832,6 +8832,7 @@ F:
Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/host/pcie-hisi.h
 F: drivers/pci/host/pcie-hisi.c
 F: drivers/pci/host/pcie-hisi-common.c
+F: drivers/pci/host/pcie-hisi-acpi.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M: Stanimir Varbanov 
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 5d2374e..15b73a6 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -210,6 +210,13 @@ config PCI_HISI
  Say Y here if you want PCIe controller support on HiSilicon
  Hip05 and Hip06 SoCs
 
+config PCI_HISI_ACPI
+   depends on ACPI && ARM64
+   bool "HiSilicon Hip05 and Hip06 SoCs ACPI PCIe controllers"
+   help
+ Say Y here if you want ACPI PCIe controller support on HiSilicon
+ Hip05 and Hip06 SoCs
+
 config PCIE_QCOM
bool "Qualcomm PCIe controller"
depends on ARCH_QCOM && OF
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 05950f3..4843142 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
+obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
index a4bb76a..e65cd99 100644
--- a/drivers/pci/host/mcfg-quirks.c
+++ b/drivers/pci/host/mcfg-quirks.c
@@ -51,6 +51,14 @@ static struct pci_cfg_fixup mcfg_qurks[] __initconst = {
{ "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY,
  NULL, thunder_pem_cfg_init},
 #endif
+#ifdef CONFIG_PCI_HISI_ACPI
+   { "HISI", "HISI0660", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
+ NULL, hisi_pcie_acpi_hip05_init},
+   { "HISI", "HISI1610", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
+ NULL, hisi_pcie_acpi_hip06_init},
+   { "HISI", "HISI1612", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
+ NULL, hisi_pcie_acpi_hip06_init},
+#endif
 };
 
 static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
diff --git a/drivers/pci/host/mcfg-quirks.h b/drivers/pci/host/mcfg-quirks.h
index 411c667..a2d2aaa 100644
--- a/drivers/pci/host/mcfg-quirks.h
+++ b/drivers/pci/host/mcfg-quirks.h
@@ -21,4 +21,12 @@ struct pci_config_window *
 thunder_pem_cfg_init(struct acpi_pci_root *root, struct pci_ops *ops);
 #endif
 
+#ifdef CONFIG_PCI_HISI_ACPI
+struct pci_config_window *
+hisi_pcie_acpi_hip05_init(struct acpi_pci_root *root, struct pci_ops *ops);
+
+struct pci_config_window *
+hisi_pcie_acpi_hip06_init(struct acpi_pci_root *root, struct pci_ops *ops);
+#endif
+
 #endif /* __MCFG_QUIRKS_H__ */
diff --git a/drivers/pci/host/pcie-hisi-acpi.c 
b/drivers/pci/host/pcie-hisi-acpi.c
new file mode 100644
index 000..93572d0
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-acpi.c
@@ -0,0 +1,151 @@
+/*
+ * PCIe host controller driver for HiSilicon HipXX SoCs
+ *
+ * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Dongdong Liu 
+ * Gabriele Paoloni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+
+#include "mcfg-quirks.h"
+#include "pcie-hisi.h"
+
+#define DEBUG0  0x728
+#define RC_NUM  4
+
+enum soc_type {
+   HIP05,
+   HIP06,
+};
+
+struct hisi_rc_res {
+   int soc_type;
+   struct resource res[RC_NUM];
+};
+
+static int hisi_pcie_link_up_acpi(struct pci_config_window *cfg)
+{
+   u32 val;
+   void __iomem *reg_base = cfg->priv;
+
+   val = readl(reg_base + DEBUG0);
+   return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+
+}
+
+static int 

[RFC PATCH 0/3] Add ACPI support for Hisilicon PCIe Host Controller

[Dongdong Liu]

This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC PCIe
controllers.
The three patches respectively:
- re-architect the current HiSilicon driver to make it scalable to
  the new ACPI quirks.
- rework the current HiSilicon driver to add support for ECAM
  platforms(not RC).
- adds the HiSilicon ACPI specific quirks.

This patchset is base on Tomasz RFC V4 quirk mechanism:
https://lkml.org/lkml/2016/6/28/165

Dongdong Liu (3):
  PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for
ACPI
  PCI: hisi: Add ECAM support for devices that are not RC
  PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

 .../devicetree/bindings/pci/hisilicon-pcie.txt |  15 +-
 MAINTAINERS|   3 +
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   3 +-
 drivers/pci/host/mcfg-quirks.c |   8 ++
 drivers/pci/host/mcfg-quirks.h |   8 ++
 drivers/pci/host/pcie-designware.c |   3 +-
 drivers/pci/host/pcie-designware.h |   2 +
 drivers/pci/host/pcie-hisi-acpi.c  | 151 +
 drivers/pci/host/pcie-hisi-common.c|  66 +
 drivers/pci/host/pcie-hisi.c   | 143 ++-
 drivers/pci/host/pcie-hisi.h   |  25 
 12 files changed, 351 insertions(+), 83 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

-- 
1.9.1

[RFC PATCH 0/3] Add ACPI support for Hisilicon PCIe Host Controller

[Dongdong Liu]

This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC PCIe
controllers.
The three patches respectively:
- re-architect the current HiSilicon driver to make it scalable to
  the new ACPI quirks.
- rework the current HiSilicon driver to add support for ECAM
  platforms(not RC).
- adds the HiSilicon ACPI specific quirks.

This patchset is base on Tomasz RFC V4 quirk mechanism:
https://lkml.org/lkml/2016/6/28/165

Dongdong Liu (3):
  PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for
ACPI
  PCI: hisi: Add ECAM support for devices that are not RC
  PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

 .../devicetree/bindings/pci/hisilicon-pcie.txt |  15 +-
 MAINTAINERS|   3 +
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   3 +-
 drivers/pci/host/mcfg-quirks.c |   8 ++
 drivers/pci/host/mcfg-quirks.h |   8 ++
 drivers/pci/host/pcie-designware.c |   3 +-
 drivers/pci/host/pcie-designware.h |   2 +
 drivers/pci/host/pcie-hisi-acpi.c  | 151 +
 drivers/pci/host/pcie-hisi-common.c|  66 +
 drivers/pci/host/pcie-hisi.c   | 143 ++-
 drivers/pci/host/pcie-hisi.h   |  25 
 12 files changed, 351 insertions(+), 83 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

-- 
1.9.1

Re: [PATCH] usb:solve resume usb device identification problem

[Lu Baolu]

Hi,

On 07/12/2016 09:48 AM, Lipengcheng wrote:
> Hi,
>
>> -Original Message-
>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>> Sent: Tuesday, July 12, 2016 8:42 AM
>> To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu; 
>> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
>> oneu...@suse.com; jun...@freescale.com
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] usb:solve resume usb device identification problem
>>
>> Hi,
>>
>> On 07/11/2016 08:57 PM, Pengcheng Li wrote:
>>> A usb device in the connection state. Then host is suspend and resume.
>>> But the usb device could not be at the right speed. We should be reset
>>> the reset.
>> Have you tried applying XHCI_RESET_ON_RESUME quirk to your host controller 
>> driver? Is your usb device self powered?
>>
> I do not apply XHCI_RESET_ON_RESUME quir to my host controller driver. I 
> select no pci platform. Our usb device is not self powered.

This quirk is not pci specific.

>> Best regards,
>> Lu  Baolu
>>
>>> Signed-off-by: Pengcheng Li 
>>> ---
>>>  drivers/usb/core/hub.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
>>> bee1351..cd71bb3 100644
>>> --- a/drivers/usb/core/hub.c
>>> +++ b/drivers/usb/core/hub.c
>>> @@ -3455,7 +3455,7 @@ int usb_port_resume(struct usb_device *udev, 
>>> pm_message_t msg)
>>> struct usb_hub  *hub = usb_hub_to_struct_hub(udev->parent);
>>> struct usb_port *port_dev = hub->ports[udev->portnum  - 1];
>>> int port1 = udev->portnum;
>>> -   int status;
>>> +   int status, retval;
>>> u16 portchange, portstatus;
>>>
>>> if (!test_and_set_bit(port1, hub->child_usage_bits)) { @@ -3512,6
>>> +3512,10 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>>> }
>>> }
>>>
>>> +   retval = hub_port_reset(hub, port1, udev, HUB_ROOT_RESET_TIME, false);
>>> +   if (retval < 0)
>>> +   hub_port_disable(hub, port1, 0);
>>> +

If I understand it right, this is a "host + device" specific issue. This line 
of code
might solve your issue, but it impacts all other hosts and devices which don't
have such problem.

Best regards,
Lu Baolu

Re: [PATCH] usb:solve resume usb device identification problem

[Lu Baolu]

Hi,

On 07/12/2016 09:48 AM, Lipengcheng wrote:
> Hi,
>
>> -Original Message-
>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>> Sent: Tuesday, July 12, 2016 8:42 AM
>> To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu; 
>> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
>> oneu...@suse.com; jun...@freescale.com
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] usb:solve resume usb device identification problem
>>
>> Hi,
>>
>> On 07/11/2016 08:57 PM, Pengcheng Li wrote:
>>> A usb device in the connection state. Then host is suspend and resume.
>>> But the usb device could not be at the right speed. We should be reset
>>> the reset.
>> Have you tried applying XHCI_RESET_ON_RESUME quirk to your host controller 
>> driver? Is your usb device self powered?
>>
> I do not apply XHCI_RESET_ON_RESUME quir to my host controller driver. I 
> select no pci platform. Our usb device is not self powered.

This quirk is not pci specific.

>> Best regards,
>> Lu  Baolu
>>
>>> Signed-off-by: Pengcheng Li 
>>> ---
>>>  drivers/usb/core/hub.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
>>> bee1351..cd71bb3 100644
>>> --- a/drivers/usb/core/hub.c
>>> +++ b/drivers/usb/core/hub.c
>>> @@ -3455,7 +3455,7 @@ int usb_port_resume(struct usb_device *udev, 
>>> pm_message_t msg)
>>> struct usb_hub  *hub = usb_hub_to_struct_hub(udev->parent);
>>> struct usb_port *port_dev = hub->ports[udev->portnum  - 1];
>>> int port1 = udev->portnum;
>>> -   int status;
>>> +   int status, retval;
>>> u16 portchange, portstatus;
>>>
>>> if (!test_and_set_bit(port1, hub->child_usage_bits)) { @@ -3512,6
>>> +3512,10 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>>> }
>>> }
>>>
>>> +   retval = hub_port_reset(hub, port1, udev, HUB_ROOT_RESET_TIME, false);
>>> +   if (retval < 0)
>>> +   hub_port_disable(hub, port1, 0);
>>> +

If I understand it right, this is a "host + device" specific issue. This line 
of code
might solve your issue, but it impacts all other hosts and devices which don't
have such problem.

Best regards,
Lu Baolu

Re: [PATCH v3 3/4] perf annotate: add powerpc support

[Ravi Bangoria]

Hi Arnaldo,

On Friday 08 July 2016 02:01 PM, Michael Ellerman wrote:

Ravi Bangoria  writes:


On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote:

I've sent v4 which enables annotate for bctr' instructions.

for 'bctr', it will show down arrow(indicate jump) and 'bctrl' will show
right arrow(indicate call). But no navigation options will be provided.
By pressing Enter key on that, message will be shown that like
"Invalid target"

Great thanks.


I've sent v4 series. Please review it.

-Ravi


It doesn't look like we have the opcode handy here? Could we get it somehow?
That would make this a *lot* more robust.

objdump prints machine code, but I don't know how difficult that would
be to parse to get opcode.

Normal objdump -d output includes the opcode, eg:

c000886c:   2c 2c 00 00 cmpdi   r12,0
  ^^^

The only thing you need to know is the endian and you can reconstruct
the raw instruction.

Then you can just decode the opcode, see how we do it in the kernel with
eg. instr_is_relative_branch().

I'm sorry. I was thinking that you wants to show opcodes with perf
annotate. But you were asking to use opcode instead of parsing
instructions.

Yeah.


This looks like rewrite parsing code. I don't know whether there is any
library already available for this which we can directly use. I'm thinking
about this.

OK don't worry about it for now. We should get this merged for starters
and we can always improve it later.

cheers

Re: [PATCH v3 3/4] perf annotate: add powerpc support

[Ravi Bangoria]

Hi Arnaldo,

On Friday 08 July 2016 02:01 PM, Michael Ellerman wrote:

Ravi Bangoria  writes:


On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote:

I've sent v4 which enables annotate for bctr' instructions.

for 'bctr', it will show down arrow(indicate jump) and 'bctrl' will show
right arrow(indicate call). But no navigation options will be provided.
By pressing Enter key on that, message will be shown that like
"Invalid target"

Great thanks.


I've sent v4 series. Please review it.

-Ravi


It doesn't look like we have the opcode handy here? Could we get it somehow?
That would make this a *lot* more robust.

objdump prints machine code, but I don't know how difficult that would
be to parse to get opcode.

Normal objdump -d output includes the opcode, eg:

c000886c:   2c 2c 00 00 cmpdi   r12,0
  ^^^

The only thing you need to know is the endian and you can reconstruct
the raw instruction.

Then you can just decode the opcode, see how we do it in the kernel with
eg. instr_is_relative_branch().

I'm sorry. I was thinking that you wants to show opcodes with perf
annotate. But you were asking to use opcode instead of parsing
instructions.

Yeah.


This looks like rewrite parsing code. I don't know whether there is any
library already available for this which we can directly use. I'm thinking
about this.

OK don't worry about it for now. We should get this merged for starters
and we can always improve it later.

cheers