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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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: crypto: ux500 - memmove the right size

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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 v3 3/3] ARM64: dts: amlogic: meson-gxbb: Add watchdog node

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 河合英宏 / 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
> > +++ 

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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

2016-07-11 Thread 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: [RFC PATCH v2 6/7] lib/persubnode: Introducing a simple per-subnode APIs

2016-07-11 Thread 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: tty/vt/keyboard: out of bounds access in do_compute_shiftstate

2016-07-11 Thread 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 = 

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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 河合英宏 / 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.

2016-07-11 Thread 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 v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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 0/3] Add ACPI support for Hisilicon PCIe Host Controller

2016-07-11 Thread 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

2016-07-11 Thread 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

2016-07-11 Thread 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 2/2] kexec: add a pmd huge entry condition during the page table

2016-07-11 Thread zhong jiang
On 2016/7/12 4:25, Andrew Morton wrote:
> On Mon, 11 Jul 2016 14:36:01 +0800 zhongjiang  wrote:
>
>> From: zhong jiang 
>>
>> when image is loaded into kernel, we need set up page table for it.
>> and all valid pfn also set up new mapping. it will set up a pmd huge
>> entry if pud_present is true.  relocate_kernel points to code segment
>> can locate in the pmd huge entry in init_transtion_pgtable. therefore,
>> we need to take the situation into account.
> Sorry, I just don't understand this changelog.  The second sentence is
> particularly hard.
>
> So can you please have another attempt at preparing the changelog text?
> The resend the patches and this time be sure to Cc the kexec
> maintainers.  I suggest this list:
>
> Cc: ke...@lists.infradead.org
> Cc: Eric Biederman 
> Cc: Dave Young 
> Cc: Vivek Goyal 
> Cc: Simon Horman 
>
>
> .
>
 ok ,  I will modify the changelog and resend to this list. thanks.



Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

2016-07-11 Thread Simon Guo
On Fri, Jul 08, 2016 at 08:02:42PM +1000, Michael Ellerman wrote:
> Benjamin Herrenschmidt  writes:
> 
> > On Thu, 2016-07-07 at 23:21 +1000, Benjamin Herrenschmidt wrote:
> >> 
> >> I think the right fix is that if a restore_sigcontext() has the MSR
> >> bits set,
> >> it should set the corresponding used_* flag.
> >
> > Something like this:
> >
> > (totally untested)
> 
> Simon/Laurent, can you guys test this and let me know if it works for
> your usecase.

Just notice this note.
Yes I will test it on CRIU and update later.

Thanks,
- Simon


Re: [PATCH v2] clk: imx7d: do not set parent of ethernet time/ref clocks

2016-07-11 Thread Fabio Estevam
Hi Mike,

On Wed, Jul 6, 2016 at 9:53 PM, Michael Turquette
 wrote:
> Quoting Stefan Agner (2016-07-03 10:48:13)
>> All device trees currently in mainline specify the time clock parent
>> using the assigned-clocks/assigned-clock-parents method, there is no
>> need to statically assign the parent in the core clock driver.
>> Also all current boards provide an Ethernet reference clock for the
>> PHY externally, hence configuring the internal PHY reference clock.
>>
>> Furthermore, and the actual driver of this patch, specify ethernet
>> related parents at that early point in boot leads to a warning:
>> bad: scheduling from the idle thread!
>>
>> The reason for the warning is that setting the parent enables the ENET
>> PLL since we are using CLK_OPS_PARENT_ENABLE. Enabling the ENET PLL can
>> cause clk_pllv3_wait_lock to sleep. See also:
>> commit fc8726a2c021 ("clk: core: support clocks which requires parents
>> enable (part 2)").
>>
>> Note that setting the ENET AXI root clock parent also requires ENET
>> PLL to be enabled. However, U-Boot typically leaves the ENET PLL on,
>> hence when the framework sets the parent of the first clock, it does
>> not need to wait for the PLL to come up. But because there is currently
>> no user of that clock, the PLL gets disabled after setting the parent.
>> Therefore, subsequent reparenting calls of any clock which somehow rely
>> on the ENET PLL, need to reenable the ENET PLL which leads to a sleep.
>> Removing those subsequent reparenting calls works around this issue.
>>
>> Also remove comments. The code is really verbose enough.
>>
>> Signed-off-by: Stefan Agner 
>
> Applied.

I still don't see this patch applied in clk-next.


Re: [PATCH v5 7/7] ARM: dts: sun9i: Switch to the AC100 RTC clock outputs for osc32k

2016-07-11 Thread Chen-Yu Tsai
On Mon, Jul 11, 2016 at 2:50 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Fri, Jul 08, 2016 at 10:33:42PM +0800, Chen-Yu Tsai wrote:
>> The 32.768 kHz clock inside the A80 SoC is fed from an external source,
>> typically the AC100 RTC module.
>>
>> Make the osc32k placeholder a fixed-factor clock so board dts files can
>> specify its source.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>> Changes since v4: none
>> Changes since v3: none
>> Changes since v2: none
>> Changes since v1: none
>> ---
>>  arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 5 +
>>  arch/arm/boot/dts/sun9i-a80-optimus.dts | 5 +
>>  arch/arm/boot/dts/sun9i-a80.dtsi| 9 +++--
>>  3 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
>> b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
>> index cf2f4b72a841..04b014603659 100644
>> --- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
>> +++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
>> @@ -103,6 +103,11 @@
>>   allwinner,drive = ;
>>  };
>>
>> + {
>> + /* osc32k input is from AC100 */
>> + clocks = <_rtc 0>;
>> +};
>> +
>
> I'm guessing that an unresolved dependency when the driver has not
> loaded yet, or is not even compiled ?
>
> How is it working then?

I assume the clk framework will leave it unresolved and unusable.
Also it seems that none of existing clks use it as a parent by
default. I will need to check the remaining unimplemented ones
though.

ChenYu


Re: [PATCH v1 0/3] Fix seccomp for UM (next)

2016-07-11 Thread Kees Cook
On Mon, Jul 11, 2016 at 5:56 PM, Mickaël Salaün  wrote:
> Hi,
>
> This series fix the recent seccomp update for the User-mode Linux architecture
> (32-bit and 64-bit) since commit 26703c636c1f3272b39bd0f6d04d2e970984f1b6
> (close the hole where ptrace can change a syscall out from under seccomp).
>
> Regards,
>
> Mickaël Salaün (3):
>   um/ptrace: Fix the syscall_trace_leave call
>   um/ptrace: Fix the syscall number update after a ptrace
>   seccomp: Remove 2-phase API documentation
>
>  arch/Kconfig  | 11 ---
>  arch/um/kernel/skas/syscall.c | 10 +++---
>  arch/x86/um/ptrace_32.c   |  3 +++
>  arch/x86/um/ptrace_64.c   |  4 
>  4 files changed, 10 insertions(+), 18 deletions(-)

Ah, perfect! Thanks for fixing this! James, can you pick this up for -next?

Acked-by: Kees Cook 

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


Re: [PATCH 25/27] HID: wacom: leds: fix ordering of LED banks

2016-07-11 Thread Peter Hutterer
On Tue, Jul 05, 2016 at 04:39:21PM +0200, Benjamin Tissoires wrote:
> Historically, 21UX2 and 24HD have the select groups inverted
> (0 is the right LED bank, and 1 the left one).
> 
> This is not right, so fix that in the new LED API. For backward
> compatibility, we keep the wacom_led sysfs ABI stable. We don't
> need to care about luminance for these two devices as only the
> select sysfs file gets exported (brightness is not configurable).

For the archives:
unfortunately we can't do this, it breaks userspace, sort-of. Due to the
information we require about wacom tablets that isn't accessible from the
device we rely heavily on libwacom. libwacom already has calls to return the
led group based on the button index, changing the order means those values
are now incorrect. And since clients using libwacom don't necessarily have
access to the sysfs or know whether the underlying process uses the old or
new sysfs approach we can't hack around this either.

so we'll have to stick with the inverted ordering of led groups.

Cheers,
   Peter

> 
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/hid/wacom_sys.c | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index b88896c..153e453 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -683,8 +683,10 @@ static int wacom_led_control(struct wacom *wacom)
>   int led = wacom->led.groups[0].select | 0x4;
>  
>   if (wacom->wacom_wac.features.type == WACOM_21UX2 ||
> - wacom->wacom_wac.features.type == WACOM_24HD)
> - led |= (wacom->led.groups[1].select << 4) | 0x40;
> + wacom->wacom_wac.features.type == WACOM_24HD) {
> + led <<= 4;
> + led |= wacom->led.groups[1].select | 0x04;
> + }
>  
>   buf[0] = report_id;
>   buf[1] = led;
> @@ -742,6 +744,19 @@ out:
>   return retval;
>  }
>  
> +static inline int wacom_led_select_get_id(struct wacom *wacom, int set_id)
> +{
> + /*
> +  * Historically, 21UX2 and 24HD have the select groups inverted
> +  * (0 is the right LED bank, and 1 the left one)
> +  */
> + if (wacom->wacom_wac.features.type == WACOM_21UX2 ||
> + wacom->wacom_wac.features.type == WACOM_24HD)
> + return 1 - set_id;
> +
> + return set_id;
> +}
> +
>  static ssize_t wacom_led_select_store(struct device *dev, int set_id,
> const char *buf, size_t count)
>  {
> @@ -754,6 +769,8 @@ static ssize_t wacom_led_select_store(struct device *dev, 
> int set_id,
>   if (err)
>   return err;
>  
> + set_id = wacom_led_select_get_id(wacom, set_id);
> +
>   mutex_lock(>lock);
>  
>   wacom->led.groups[set_id].select = id & 0x3;
> @@ -775,8 +792,9 @@ static ssize_t wacom_led##SET_ID##_select_show(struct 
> device *dev,\
>  {\
>   struct hid_device *hdev = to_hid_device(dev);\
>   struct wacom *wacom = hid_get_drvdata(hdev);\
> + int set_id = wacom_led_select_get_id(wacom, SET_ID);\
>   return scnprintf(buf, PAGE_SIZE, "%d\n",\
> -  wacom->led.groups[SET_ID].select); \
> +  wacom->led.groups[set_id].select); \
>  }\
>  static DEVICE_ATTR(status_led##SET_ID##_select, DEV_ATTR_RW_PERM,\
>   wacom_led##SET_ID##_select_show,\
> -- 
> 2.5.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


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

2016-07-11 Thread Yingjoe Chen
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 :)


Hi,

I just got next-20160711 and change this chunk to:

+   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);
+   } else {
+   scpd->clk[j] = c;
+   }
+   }
+


and checkpatch give me this warning:

WARNING: else is not generally useful after a break or return
#313: FILE: drivers/soc/mediatek/mtk-scpsys.c:409:
+   return ERR_CAST(c);
+   } else {

Joe.C




Re: [PATCH 3/3] Documentation: mmc: add description for new no-sd* and no-mmc

2016-07-11 Thread Shawn Lin

Hi Rob,

On 2016/7/11 21:57, Rob Herring WROTE:

On Fri, Jul 01, 2016 at 03:45:30PM +0800, Shawn Lin wrote:

This patch adds description for no-sd, no-sdio, no-mmc. We
expect the specific boards adds these in DT to improve
the initialization. For instance, for a soldered eMMC slot,
we could skip sending SDIO and SD commands to probe its card
types as it's always should be the type fo MMC card.

Signed-off-by: Shawn Lin 
---

 Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index ecc007a..b2046c6 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -49,6 +49,9 @@ Optional properties:
 - mmc-hs400-enhanced-strobe: eMMC HS400 enhanced strobe mode is supported
 - dsr: Value the card's (optional) Driver Stage Register (DSR) should be
   programmed with. Valid range: [0 .. 0x].
+- no-sdio: skip sending sdio cmd during initialization
+- no-sd: skip sending sd cmd during initialization
+- no-mmc: skip sending mmc cmd during initialization


I still have issue with the description for these properties and the
commit msg. They are fine if described as controller limitations as Ulf
described. If folks want to (ab)use the properties for just skipping
init, then that's their problem.


Sounds like it's okay for you if I amend the commit msg and drscription
to emphasize that these properties are intent to describe the
limitations of controllers rather than to skip init.

I will fix them.

Thanks.



Rob






--
Best Regards
Shawn Lin



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

2016-07-11 Thread Lipengcheng
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.
> 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 (udev->persist_enabled)
> > status = wait_for_connected(udev, hub, , ,
> > );
Best regards
Pengcheng Li


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

2016-07-11 Thread Lipengcheng

Hi,
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Monday, July 11, 2016 10:51 PM
> To: Lipengcheng
> Cc: gre...@linuxfoundation.org; baolu...@linux.intel.com; 
> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
> oneu...@suse.com; jun...@freescale.com; linux-...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] usb:solve resume usb device identification problem
> 
> On Mon, 11 Jul 2016, 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.
> >
> > Signed-off-by: Pengcheng Li 
> 
> Why wouldn't the USB device be at the right speed?
> 
For example, some USB3 devices are resume, the device may be in USB 2.0 Device 
States. We should have USB 2.0 reset and
make the device into the right speed.
 
> You should _not_ reset the device if it is at the right speed.
>
> > @@ -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);
> > +
> 
> Most of the time (for example, for non-USB3 devices) this would be wrong.
> 
Yes, USB3 devices have this problem. So far, USB2 device can not find this 
problem. 
I mainly refer to the reset process of usb enumeration process.
> Alan Stern

Thanks,
Pengcheng Li



Re: a question about protection_map[]

2016-07-11 Thread Kirill A. Shutemov
On Tue, Jul 12, 2016 at 09:31:30AM +0800, Xishi Qiu wrote:
> On 2016/7/11 21:30, Kirill A. Shutemov wrote:
> 
> > On Mon, Jul 11, 2016 at 06:12:30PM +0800, Xishi Qiu wrote:
> >> Hi,
> >>
> >> We can use mprotect to set read only or read/write.
> >>
> >> mprotect_fixup()
> >>vma_set_page_prot()
> >>vm_pgprot_modify()
> >>vm_get_page_prot()
> >>protection_map[vm_flags & 
> >> (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]
> >>
> >> The following code shows that prots from __P001(PROT_READ) and 
> >> __P010(PROT_WRITE)
> >> are the same, so how does it distinguish read only or read/write from 
> >> mprotect?
> > 
> > It doesn't.
> > 
> > Write protection will be removed by fault handler on next write access to
> > the page. Somewhat suboptiomal, but zero page implemenation relies on this
> > to work properly.
> > 
> 
> Hi Kirill,
> 
> I know, PAGE_READONLY and PAGE_COPY are both missed _PAGE_RW,
> so it will cause page fault, then we will set new prot flag from
> vma, right?

Yes. See wp_page_reuse().

-- 
 Kirill A. Shutemov


Re: [f2fs-dev] [PATCH] f2fs: return proper error code

2016-07-11 Thread Chao Yu
On 2016/7/11 7:20, Tiezhu Yang wrote:
> When the length of file name is more than F2FS_NAME_LEN,

Seem @name indicates a xattr/key name, not a file name.

Thanks,

> it should return -ENAMETOOLONG.
> 
> Signed-off-by: Tiezhu Yang 
> ---
>  fs/f2fs/xattr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
> index 28a5023..b225062 100644
> --- a/fs/f2fs/xattr.c
> +++ b/fs/f2fs/xattr.c
> @@ -364,7 +364,7 @@ int f2fs_getxattr(struct inode *inode, int index, const 
> char *name,
>  
>   len = strlen(name);
>   if (len > F2FS_NAME_LEN)
> - return -ERANGE;
> + return -ENAMETOOLONG;
>  
>   base_addr = read_all_xattrs(inode, ipage);
>   if (!base_addr)
> @@ -458,7 +458,7 @@ static int __f2fs_setxattr(struct inode *inode, int index,
>   len = strlen(name);
>  
>   if (len > F2FS_NAME_LEN)
> - return -ERANGE;
> + return -ENAMETOOLONG;
>  
>   if (size > MAX_VALUE_LEN(inode))
>   return -E2BIG;
> 



Re: [PATCH 23/27] HID: wacom: leds: use the ledclass instead of custom made sysfs files

2016-07-11 Thread Peter Hutterer
On Tue, Jul 05, 2016 at 04:39:19PM +0200, Benjamin Tissoires wrote:
> The now obsolete sysfs files for LEDs and EKRemote are kept for backward
> compatibility.
> Both the EKR (read-only) and the regular Cintiqs and Intuos are now
> sharing the same led API.
> 
> Signed-off-by: Benjamin Tissoires 
> ---
>  Documentation/ABI/testing/sysfs-driver-wacom |   5 +
>  drivers/hid/wacom.h  |  19 +++
>  drivers/hid/wacom_sys.c  | 191 
> +--
>  3 files changed, 205 insertions(+), 10 deletions(-)
> 
[...]

> +static int wacom_led_register_one(struct device *dev, struct wacom *wacom,
> +   struct wacom_led *led, unsigned int group,
> +   unsigned int id, bool read_only)
> +{
> + int error;
> + char *name;
> +
> + name = devm_kasprintf(dev, GFP_KERNEL,
> +   "%s::wacom-led_%d.%d",
> +   dev_name(dev),
> +   group,
> +   id);

let's use something other than the - and _ mix please. I'd prefer
wacom-led-0.1 but I'll also accept wacom_led_0.1, the mix is a bit of an
eyesore.

also, arguably you don't need the "led" bit, see e.g.  "input3::capslock" so
even "input123::wacom-0.1" would be ok too.

Cheers,
   Peter



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

2016-07-11 Thread Christoph Hellwig
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...

And why exactly is your use of a broken and undistributable out of tree
module our problem?


Re: [f2fs-dev] [PATCH 3/7] f2fs: drop any block plugging

2016-07-11 Thread Chao Yu
On 2016/7/10 0:32, Jaegeuk Kim wrote:
> On Sat, Jul 09, 2016 at 10:28:49AM +0800, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2016/6/9 1:24, Jaegeuk Kim wrote:
>>> In f2fs, we don't need to keep block plugging for NODE and DATA writes, 
>>> since
>>> we already merged bios as much as possible.
>>
>> IMO, we can not remove block plug, this is because there are still many
>> conditions which stops us merging r/w IOs into one bio as we expect,
>> theoretically, block plug can hold bios as much as possible, then submitting
>> them into queue in batch, it will reduce racing of grabbing queue->lock 
>> during
>> bio submitting, if we drop them, when syncing nodes or flushing datas, we 
>> will
>> suffer more lock racing.
>>
>> Or there are something I am missing, do you suffer any performance issue on
>> block plug?
> 
> In the latest patch, I've turned off plugging forcefully, only if the 
> underlying
> device is SMR drive.

Got it.

> And, still I removed other block plugging, since I couldn't see any 
> performance
> regression.

I suspect that in low-end machine with single-queue which is used in block
layer, we will suffer regression.

> Even in some workloads, I could have seen some inverted IOs due to
> race condition between plugged and unplugged IOs.

For data path, what about enabling block plug for IPU/SSR ?

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Jaegeuk Kim 
>>> ---
>>>  fs/f2fs/checkpoint.c |  4 
>>>  fs/f2fs/data.c   | 17 ++---
>>>  fs/f2fs/gc.c |  5 -
>>>  fs/f2fs/segment.c|  7 +--
>>>  4 files changed, 11 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>> index 5ddd15c..4179c7b 100644
>>> --- a/fs/f2fs/checkpoint.c
>>> +++ b/fs/f2fs/checkpoint.c
>>> @@ -897,11 +897,8 @@ static int block_operations(struct f2fs_sb_info *sbi)
>>> .nr_to_write = LONG_MAX,
>>> .for_reclaim = 0,
>>> };
>>> -   struct blk_plug plug;
>>> int err = 0;
>>>  
>>> -   blk_start_plug();
>>> -
>>>  retry_flush_dents:
>>> f2fs_lock_all(sbi);
>>> /* write all the dirty dentry pages */
>>> @@ -938,7 +935,6 @@ retry_flush_nodes:
>>> goto retry_flush_nodes;
>>> }
>>>  out:
>>> -   blk_finish_plug();
>>> return err;
>>>  }
>>>  
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 30dc448..5f655d0 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -98,10 +98,13 @@ static struct bio *__bio_alloc(struct f2fs_sb_info 
>>> *sbi, block_t blk_addr,
>>>  }
>>>  
>>>  static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
>>> -   struct bio *bio)
>>> +   struct bio *bio, enum page_type type)
>>>  {
>>> -   if (!is_read_io(rw))
>>> +   if (!is_read_io(rw)) {
>>> atomic_inc(>nr_wb_bios);
>>> +   if (current->plug && (type == DATA || type == NODE))
>>> +   blk_finish_plug(current->plug);
>>> +   }
>>> submit_bio(rw, bio);
>>>  }
>>>  
>>> @@ -117,7 +120,7 @@ static void __submit_merged_bio(struct f2fs_bio_info 
>>> *io)
>>> else
>>> trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
>>>  
>>> -   __submit_bio(io->sbi, fio->rw, io->bio);
>>> +   __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
>>> io->bio = NULL;
>>>  }
>>>  
>>> @@ -235,7 +238,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>>> return -EFAULT;
>>> }
>>>  
>>> -   __submit_bio(fio->sbi, fio->rw, bio);
>>> +   __submit_bio(fio->sbi, fio->rw, bio, fio->type);
>>> return 0;
>>>  }
>>>  
>>> @@ -1040,7 +1043,7 @@ got_it:
>>>  */
>>> if (bio && (last_block_in_bio != block_nr - 1)) {
>>>  submit_and_realloc:
>>> -   __submit_bio(F2FS_I_SB(inode), READ, bio);
>>> +   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>>> bio = NULL;
>>> }
>>> if (bio == NULL) {
>>> @@ -1083,7 +1086,7 @@ set_error_page:
>>> goto next_page;
>>>  confused:
>>> if (bio) {
>>> -   __submit_bio(F2FS_I_SB(inode), READ, bio);
>>> +   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>>> bio = NULL;
>>> }
>>> unlock_page(page);
>>> @@ -1093,7 +1096,7 @@ next_page:
>>> }
>>> BUG_ON(pages && !list_empty(pages));
>>> if (bio)
>>> -   __submit_bio(F2FS_I_SB(inode), READ, bio);
>>> +   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>>> return 0;
>>>  }
>>>  
>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>> index 4a03076..67fd285 100644
>>> --- a/fs/f2fs/gc.c
>>> +++ b/fs/f2fs/gc.c
>>> @@ -777,7 +777,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>>>  {
>>> struct page *sum_page;
>>> struct f2fs_summary_block *sum;
>>> -   struct blk_plug plug;
>>> unsigned int segno = start_segno;
>>> 

[RFC 1/3] syscall: add kexec_file_load to generic unistd.h

2016-07-11 Thread AKASHI Takahiro
Currently kexec_file_load is supported only on x86, but it will be
supported on powerpc and arm64 in near future. Since both archs
use asm-generic/unistd.h, this patch adds the entry to this file.

Signed-off-by: AKASHI Takahiro 
---
 include/uapi/asm-generic/unistd.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/uapi/asm-generic/unistd.h 
b/include/uapi/asm-generic/unistd.h
index a26415b..9ead10f 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -724,9 +724,15 @@ __SYSCALL(__NR_copy_file_range, sys_copy_file_range)
 __SC_COMP(__NR_preadv2, sys_preadv2, compat_sys_preadv2)
 #define __NR_pwritev2 287
 __SC_COMP(__NR_pwritev2, sys_pwritev2, compat_sys_pwritev2)
+#define __NR_kexec_file_load 288
+#ifdef CONFIG_KEXEC_FILE
+__SYSCALL(__NR_kexec_file_load, sys_kexec_file_load)
+#else
+__SYSCALL(__NR_kexec_file_load, sys_ni_syscall)
+#endif /* CONFIG_KEXEC_FILE */
 
 #undef __NR_syscalls
-#define __NR_syscalls 288
+#define __NR_syscalls 289
 
 /*
  * All syscalls below here should go away really,
-- 
2.9.0



[RFC 3/3] kexec: extend kexec_file_load system call

2016-07-11 Thread AKASHI Takahiro
Device tree blob must be passed to a second kernel on DTB-capable
archs, like powerpc and arm64, but the current kernel interface
lacks this support.

This patch extends kexec_file_load system call by adding an extra
argument to this syscall so that an arbitrary number of file descriptors
can be handed out from user space to the kernel.

long sys_kexec_file_load(int kernel_fd, int initrd_fd,
 unsigned long cmdline_len,
 const char __user *cmdline_ptr,
 unsigned long flags,
 const struct kexec_fdset __user *ufdset);

If KEXEC_FILE_EXTRA_FDS is set to the "flags" argument, the "ufdset"
argument points to the following struct buffer:

struct kexec_fdset {
int nr_fds;
struct kexec_file_fd fds[0];
}

Signed-off-by: AKASHI Takahiro 
---
 include/linux/fs.h |  1 +
 include/linux/kexec.h  |  2 +-
 include/linux/syscalls.h   |  4 +++-
 include/uapi/linux/kexec.h | 17 ++
 kernel/kexec_file.c| 57 --
 5 files changed, 72 insertions(+), 9 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index dd28814..6dd6fdf 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2634,6 +2634,7 @@ extern int do_pipe_flags(int *, int);
id(MODULE, kernel-module)   \
id(KEXEC_IMAGE, kexec-image)\
id(KEXEC_INITRAMFS, kexec-initramfs)\
+   id(KEXEC_DTB, kexec-dtb)\
id(POLICY, security-policy) \
id(MAX_ID, )
 
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 554c848..5f11bd5 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -277,7 +277,7 @@ extern int kexec_load_disabled;
 
 /* List of defined/legal kexec file flags */
 #define KEXEC_FILE_FLAGS   (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
-KEXEC_FILE_NO_INITRAMFS)
+KEXEC_FILE_NO_INITRAMFS | KEXEC_FILE_EXTRA_FDS)
 
 #define VMCOREINFO_BYTES   (4096)
 #define VMCOREINFO_NOTE_NAME   "VMCOREINFO"
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index d022390..fc072bd 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -66,6 +66,7 @@ struct perf_event_attr;
 struct file_handle;
 struct sigaltstack;
 union bpf_attr;
+struct kexec_fdset;
 
 #include 
 #include 
@@ -321,7 +322,8 @@ asmlinkage long sys_kexec_load(unsigned long entry, 
unsigned long nr_segments,
 asmlinkage long sys_kexec_file_load(int kernel_fd, int initrd_fd,
unsigned long cmdline_len,
const char __user *cmdline_ptr,
-   unsigned long flags);
+   unsigned long flags,
+   const struct kexec_fdset __user *ufdset);
 
 asmlinkage long sys_exit(int error_code);
 asmlinkage long sys_exit_group(int error_code);
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index aae5ebf..adf53b6 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -23,6 +23,23 @@
 #define KEXEC_FILE_UNLOAD  0x0001
 #define KEXEC_FILE_ON_CRASH0x0002
 #define KEXEC_FILE_NO_INITRAMFS0x0004
+#define KEXEC_FILE_EXTRA_FDS   0x0008
+
+enum kexec_file_type {
+   KEXEC_FILE_TYPE_KERNEL,
+   KEXEC_FILE_TYPE_INITRAMFS,
+   KEXEC_FILE_TYPE_DTB,
+};
+
+struct kexec_file_fd {
+   enum kexec_file_type type;
+   int fd;
+};
+
+struct kexec_fdset {
+   int nr_fds;
+   struct kexec_file_fd fds[0];
+};
 
 /* These values match the ELF architecture values.
  * Unless there is a good reason that should continue to be the case.
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 7278329..451b4b0 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -137,11 +137,14 @@ void kimage_file_post_load_cleanup(struct kimage *image)
 static int
 kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int 
initrd_fd,
 const char __user *cmdline_ptr,
-unsigned long cmdline_len, unsigned flags)
+unsigned long cmdline_len, unsigned long flags,
+const struct kexec_fdset __user *ufdset)
 {
-   int ret = 0;
+   int ret = 0, nr_fds, i;
void *ldata;
loff_t size;
+   struct kexec_fdset *fdset = NULL;
+   size_t fdset_size;
 
ret = kernel_read_file_from_fd(kernel_fd, >kernel_buf,
   , INT_MAX, READING_KEXEC_IMAGE);
@@ -174,6 +177,42 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
image->initrd_buf_len = size;
}
 
+   if 

[RFC 2/3] kexec: add dtb info to struct kimage

2016-07-11 Thread AKASHI Takahiro
Device tree blob must be passed to a second kernel on DTB-capable
archs, like powerpc and arm64, but the current kernel interface
lacks this support.

This patch adds dtb buffer information to struct kimage.
When users don't specify dtb explicitly and the one used for the current
kernel can be re-used, this change will be good enough for implementing
kexec_file_load feature.

Signed-off-by: AKASHI Takahiro 
---
 include/linux/kexec.h | 3 +++
 kernel/kexec_file.c   | 5 +
 2 files changed, 8 insertions(+)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e8acb2b..554c848 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -190,6 +190,9 @@ struct kimage {
char *cmdline_buf;
unsigned long cmdline_buf_len;
 
+   void *dtb_buf;
+   unsigned long dtb_buf_len;
+
/* File operations provided by image loader */
struct kexec_file_ops *fops;
 
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 9891464..7278329 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -96,6 +96,11 @@ void kimage_file_post_load_cleanup(struct kimage *image)
image->initrd_buf = NULL;
}
 
+   if (image->dtb_buf) {
+   vfree(image->dtb_buf);
+   image->dtb_buf = NULL;
+   }
+
if (image->cmdline_buf) {
kfree(image->cmdline_buf);
image->cmdline_buf = NULL;
-- 
2.9.0



[RFC 0/3] extend kexec_file_load system call

2016-07-11 Thread AKASHI Takahiro
Device tree blob must be passed to a second kernel on DTB-capable
archs, like powerpc and arm64, but the current kernel interface
lacks this support.
  
This patch extends kexec_file_load system call by adding an extra
argument to this syscall so that an arbitrary number of file descriptors
can be handed out from user space to the kernel.

See the background [1].

Please note that the new interface looks quite similar to the current
system call, but that it won't always mean that it provides the "binary
compatibility."

[1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html


AKASHI Takahiro (3):
  syscall: add kexec_file_load to generic unistd.h
  kexec: add dtb info to struct kimage
  kexec: extend kexec_file_load system call

 include/linux/fs.h|  1 +
 include/linux/kexec.h |  5 +++-
 include/linux/syscalls.h  |  4 ++-
 include/uapi/asm-generic/unistd.h |  8 -
 include/uapi/linux/kexec.h| 17 +++
 kernel/kexec_file.c   | 62 ++-
 6 files changed, 87 insertions(+), 10 deletions(-)

-- 
2.9.0



[PATCH] iommu: arm-smmu: drop devm_free_irq when driver detach

2016-07-11 Thread Peng Fan
There is no need to call devm_free_irq when driver detach.
devres_release_all which is called after 'drv->remove' will
release all managed resources.

Signed-off-by: Peng Fan 
Cc: Will Deacon 
Cc: Robin Murphy 
---
 drivers/iommu/arm-smmu.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 860652e..5837391c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2045,9 +2045,6 @@ static int arm_smmu_device_remove(struct platform_device 
*pdev)
if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
dev_err(dev, "removing device with active domains!\n");
 
-   for (i = 0; i < smmu->num_global_irqs; ++i)
-   devm_free_irq(smmu->dev, smmu->irqs[i], smmu);
-
/* Turn the thing off */
writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
return 0;
-- 
2.6.2



Re: a question about protection_map[]

2016-07-11 Thread Xishi Qiu
On 2016/7/11 21:30, Kirill A. Shutemov wrote:

> On Mon, Jul 11, 2016 at 06:12:30PM +0800, Xishi Qiu wrote:
>> Hi,
>>
>> We can use mprotect to set read only or read/write.
>>
>> mprotect_fixup()
>>  vma_set_page_prot()
>>  vm_pgprot_modify()
>>  vm_get_page_prot()
>>  protection_map[vm_flags & 
>> (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]
>>
>> The following code shows that prots from __P001(PROT_READ) and 
>> __P010(PROT_WRITE)
>> are the same, so how does it distinguish read only or read/write from 
>> mprotect?
> 
> It doesn't.
> 
> Write protection will be removed by fault handler on next write access to
> the page. Somewhat suboptiomal, but zero page implemenation relies on this
> to work properly.
> 

Hi Kirill,

I know, PAGE_READONLY and PAGE_COPY are both missed _PAGE_RW,
so it will cause page fault, then we will set new prot flag from
vma, right?

Thanks,
Xishi Qiu



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

2016-07-11 Thread David Chen
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...

Thanks

2016-07-11 17:46 GMT-07:00 Al Viro :
> On Mon, Jul 11, 2016 at 05:15:04PM -0700, Chunwei Chen wrote:
>> We need to check i_count again with i_lock held, because iput might re-add
>> i_count when lazytime is on. Without this check, we could end up with
>> double-free or use-after-free.
>
> Details, please.  Ideally - with a reproducer.  Who is calling that iput()
> at that point of generic_shutdown_super() (has to be another thread) and
> just what will happen if the same iput() is delayed until *after*
> evict_inodes(), all the way into ->put_super().  At which point there's
> no promise whatsoever that the data structures used by ->evict_inode()
> hadn't been already freed...
>


Re: [PATCH v3] f2fs: fix to avoid data update racing between GC and DIO

2016-07-11 Thread Chao Yu
On 2016/7/10 0:22, Jaegeuk Kim wrote:
> On Fri, Jul 08, 2016 at 11:50:02PM +0800, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2016/7/8 11:19, Jaegeuk Kim wrote:
>>> Hi Chao,
>>>
>>> Could you take a look at this in xfstests/generic/013?
>>>
>>> [  502.480850] ==
>>> [  502.480864] [ INFO: possible circular locking dependency detected ]
>>> [  502.480877] 4.7.0-rc1+ #124 Tainted: G   OE  
>>> [  502.480886] ---
>>> [  502.480897] fsstress/10729 is trying to acquire lock:
>>> [  502.480906]  (>s_type->i_mutex_key#18){+.+.+.}, at: 
>>> [] do_blockdev_direct_IO+0x1db/0x2310
>>> [  502.480948] 
>>> [  502.480948] but task is already holding lock:
>>> [  502.480959]  (>dio_rwsem){.+.+.+}, at: [] 
>>> f2fs_direct_IO+0xd1/0x3d0 [f2fs]
>>> [  502.481003] 
>>> [  502.481003] which lock already depends on the new lock.
>>> [  502.481003] 
>>> [  502.481018] 
>>> [  502.481018] the existing dependency chain (in reverse order) is:
>>> [  502.481030] 
>>> [  502.481030] -> #1 (>dio_rwsem){.+.+.+}:
>>> [  502.481054][] lock_acquire+0xd3/0x220
>>> [  502.481071][] down_read+0x51/0xa0
>>> [  502.481089][] f2fs_direct_IO+0xd1/0x3d0 [f2fs]
>>> [  502.481114][] 
>>> generic_file_direct_write+0xa7/0x160
>>> [  502.481133][] 
>>> __generic_file_write_iter+0xbd/0x1e0
>>> [  502.481149][] f2fs_file_write_iter+0xdb/0x100 
>>> [f2fs]
>>> [  502.481173][] __vfs_write+0xc8/0x140
>>> [  502.481190][] vfs_write+0xb5/0x1b0
>>> [  502.481205][] SyS_write+0x49/0xa0
>>> [  502.481220][] 
>>> entry_SYSCALL_64_fastpath+0x23/0xc1
>>> [  502.481236] 
>>> [  502.481236] -> #0 (>s_type->i_mutex_key#18){+.+.+.}:
>>> [  502.481264][] __lock_acquire+0x161c/0x1940
>>> [  502.481280][] lock_acquire+0xd3/0x220
>>> [  502.481296][] down_write+0x5a/0xc0
>>> [  502.481312][] 
>>> do_blockdev_direct_IO+0x1db/0x2310
>>> [  502.481328][] __blockdev_direct_IO+0x3a/0x40
>>> [  502.481344][] f2fs_direct_IO+0x104/0x3d0 [f2fs]
>>> [  502.481368][] 
>>> generic_file_read_iter+0x689/0x7e0
>>> [  502.481384][] __vfs_read+0xc1/0x130
>>> [  502.481399][] vfs_read+0x91/0x140
>>> [  502.481414][] SyS_read+0x49/0xa0
>>> [  502.481429][] 
>>> entry_SYSCALL_64_fastpath+0x23/0xc1
>>> [  502.481445] 
>>> [  502.481445] other info that might help us debug this:
>>> [  502.481445] 
>>> [  502.481459]  Possible unsafe locking scenario:
>>> [  502.481459] 
>>> [  502.481726]CPU0CPU1
>>> [  502.481987]
>>> [  502.482242]   lock(>dio_rwsem);
>>> [  502.482501]
>>> lock(>s_type->i_mutex_key#18);
>>> [  502.482765]lock(>dio_rwsem);
>>> [  502.483025]   lock(>s_type->i_mutex_key#18);
>>
>> Seems we will suffer ABBA deadlock:
>>
>> writer   reader
>> - f2fs_file_write_iter
>>  - down_write(>i_rwsem)
>>  - __generic_file_write_iter
>>   - generic_file_direct_write
>>- f2fs_direct_IO
>>  - generic_file_read_iter
>>   - f2fs_direct_IO
>>   - down_read(>dio_rwsem)
>>- __blockdev_direct_IO
>> - do_blockdev_direct_IO
>>  - down_write(>i_rwsem)
>>  
>> - down_read(>dio_rwsem)
>>
>> What about splitting dio_rwsem to rdio_rwsem/wdio_rwsem for reader/writer to
>> avoid deadlock?
> 
> Hmm, how about inode_trylock in GC?

If we reuse inode->i_rwsem here, we will suffer the same issue when we remove
i_rwsem lock in dio writer or dio reader for better concurrency.

So I think it's better to use separate lock to just fix this issue.

Thanks,

> 
>>
>> Thanks,
>>
>>> [  502.483285] 
>>> [  502.483285]  *** DEADLOCK ***
>>> [  502.483285] 
>>> [  502.484018] 1 lock held by fsstress/10729:
>>> [  502.484262]  #0:  (>dio_rwsem){.+.+.+}, at: [] 
>>> f2fs_direct_IO+0xd1/0x3d0 [f2fs]
>>>
>>> Thanks,
>>>
>>> On Thu, Jul 07, 2016 at 12:49:12PM +0800, Chao Yu wrote:
 From: Chao Yu 

 Datas in file can be operated by GC and DIO simultaneously, so we will
 face race case as below:

 For write case:
 Thread A   Thread B
 - generic_file_direct_write
  - invalidate_inode_pages2_range
  - f2fs_direct_IO
   - do_blockdev_direct_IO
- do_direct_IO
 - get_more_blocks
- f2fs_gc
 - do_garbage_collect
  - gc_data_segment
   - move_data_page

Re: [PATCH] pwm: Create device class for pwm channels

2016-07-11 Thread David Hsu
On Mon, Jul 11, 2016 at 2:39 AM, Thierry Reding
 wrote:
> On Wed, Jun 15, 2016 at 04:52:56PM -0700, David Hsu wrote:
>> On Wed, Jun 15, 2016 at 7:37 AM, Thierry Reding
>>  wrote:
>> > On Tue, Jun 14, 2016 at 07:12:04PM -0700, Greg KH wrote:
>> >> From: David Hsu 
>> >>
>> >> Pwm channels don't send uevents when exported, this change adds the
>> >> channels to a pwm class and set their device type to pwm_channel so
>> >> uevents are sent.
>> >>
>> >> To do this properly, the device names need to change to uniquely
>> >> identify a channel.  This change is from pwmN to pwm-(chip->base):N
>> >>
>> >> Signed-off-by: David Hsu 
>> >> Signed-off-by: Greg Kroah-Hartman 
>> >> ---
>> >>  Documentation/pwm.txt |6 --
>> >>  drivers/pwm/sysfs.c   |   15 ---
>> >>  2 files changed, 16 insertions(+), 5 deletions(-)
>> >>
>> >> Note, this patch came from David with his work on a system that has
>> >> dynamic PWM devices and channels, and we needed some way to tell
>> >> userspace what is going on when they are added or removed.  If anyone
>> >> knows any other way of doing this that does not involve changing the pwm
>> >> names, please let us know.
>> >
>> > Is it truly PWM channels that dynamically appear and disappear? I'd be
>> > interested in how that's achieved, because there are probably other
>> > issues that will manifest if you do that. Do you have a pointer to the
>> > work that David's been undertaking? Generally some more context on the
>> > use-case would be helpful here.
>>
>> Only PWM devices are dynamic, the number of channels exposed by
>> devices do not change after they've been added to the system.
>
> In that case, would it not be enough to use the uevents generated by the
> addition and removal of the PWM chip devices to/from sysfs?

We need channel level granularity to modify permissions for sysfs nodes
that are created when the channels are exported.

>
>> > Also I'd prefer if this avoided using chip->base here, because it exists
>> > purely for legacy purposes and is supposed to go away eventually.
>> >
>> > Thierry
>>
>> Would using dev_name(parent) be an acceptable alternative?
>
> Yes, that sounds like a more sensible choice to me.

Thanks Thierry, I'll send out a v2 shortly.

It also occurred to me that this change could affect apps that have the previous
name hard coded. I can create a link pointing to the new name but wanted to see
if there's a better recommendation or if it's required.

David


>
> Thierry


Re: [PATCH] iommu: arm-smmu: use devm_request_irq and devm_free_irq

2016-07-11 Thread Peng Fan
Hi Robin,
On Mon, Jul 11, 2016 at 11:32:55AM +0100, Robin Murphy wrote:
>On 04/07/16 10:38, Peng Fan wrote:
>> Use devm_request_irq to simplify error handling path,
>> when probe smmu device.
>> 
>> Also devm_{request|free}_irq when init or destroy domain context.
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Will Deacon 
>> Cc: Robin Murphy 
>> ---
>[...]
>> @@ -2050,7 +2046,7 @@ static int arm_smmu_device_remove(struct 
>> platform_device *pdev)
>>  dev_err(dev, "removing device with active domains!\n");
>>  
>>  for (i = 0; i < smmu->num_global_irqs; ++i)
>> -free_irq(smmu->irqs[i], smmu);
>> +devm_free_irq(smmu->dev, smmu->irqs[i], smmu);
>
>There shouldn't be any need for this at all, since the very next thing
>called after drv->remove() is devres_release_all().

Thanks for comments. I'll fix this with a new patch.

Thanks,
Peng.

>
>Robin.
>
>>  
>>  /* Turn the thing off */
>>  writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
>> 
>


Re: [lkp] [ACPI / APEI] a3e2acc5e3: kmsg.BERT:Can't_request_iomem_region<#-#>

2016-07-11 Thread Luck, Tony
Get BIOS version with:

# dmidecode   -t  0

Sent from my iPhone

> On Jul 11, 2016, at 17:54, Ye, Xiaolong  wrote:
> 
>> On Sun, Jul 10, 2016 at 08:28:37PM -0700, Tony Luck wrote:
>> I'm very surprised that there was a BERT table on an Atom machine. More 
>> details about the machine please. Also BIOS version.
> 
> Hi, ying
> 
> Could you tell me what's BERT table? and how to check the BIOS version?
> 
> Thanks,
> Xiaolong
> 
>> 
>> Sent from my iPhone
>> 
>>> On Jul 10, 2016, at 18:43, kernel test robot  wrote:
>>> 
>>> 
>>> FYI, we noticed the following commit:
>>> 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> commit a3e2acc5e37b22b6808a0b8e46887c3577de9c9e ("ACPI / APEI: Add Boot 
>>> Error Record Table (BERT) support")
>>> 
>>> in testcase: locktorture
>>> with following parameters: runtime=300s
>>> 
>>> on test machine: Atom with 8G memory
>>> 
>>> caused below changes:
>>> 
>>> 
>>> [   12.317148] BERT: Can't request iomem region 
>>> .
>>> 
>>> 
>>> 
>>> To reproduce:
>>> 
>>>   git clone 
>>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>>>   cd lkp-tests
>>>   bin/lkp install job.yaml  # job file is attached in this email
>>>   bin/lkp run job.yaml
>>> 
>>> 
>>> 
>>> Thanks,
>>> Xiaolong
>>> 
>>> 
>>> 


Re: [PATCH v2 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit

2016-07-11 Thread Peter Chen
On Mon, Jul 11, 2016 at 03:07:24PM -0700, Stephen Boyd wrote:
> On 10 July 2016 at 22:32, Peter Chen  wrote:
> > On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> >> @@ -40,11 +43,38 @@ struct ci_hdrc_msm {
> >>   struct clk *iface_clk;
> >>   struct clk *fs_clk;
> >>   struct ci_hdrc_platform_data pdata;
> >> + struct reset_controller_dev rcdev;
> >>   bool secondary_phy;
> >>   bool hsic;
> >>   void __iomem *base;
> >>  };
> >>
> >> +static int
> >> +ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
> >> +{
> >> + struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, 
> >> rcdev);
> >> + void __iomem *addr = ci_msm->base;
> >> + u32 val;
> >> +
> >> + if (id)
> >> + addr += HS_PHY_SEC_CTRL;
> >> + else
> >> + addr += HS_PHY_CTRL;
> >> +
> >> + val = readl_relaxed(addr);
> >> + val |= HS_PHY_POR_ASSERT;
> >> + writel(val, addr);
> >> + udelay(12);
> >
> > Does this delay is reference manual defines or experienced value?
> > Do you need to comment it?
> >
> 
> 10us comes from the manual but we add two more from experience. I can
> add a comment to that effect similar to the one above udelay(12) in
> phy-msm-usb.c?

Yes, you can move that comments from there.

-- 

Best Regards,
Peter Chen


Re: [PATCH v2 15/22] usb: chipidea: msm: Mux over secondary phy at the right time

2016-07-11 Thread Peter Chen
On Mon, Jul 11, 2016 at 03:03:37PM -0700, Stephen Boyd wrote:
> On 10 July 2016 at 21:43, Peter Chen  wrote:
> > On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> >> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> >> b/drivers/usb/chipidea/ci_hdrc_msm.c
> >> index 7e870a253f55..7708bee3ff3e 100644
> >> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> >> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> >> @@ -8,29 +8,44 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> -#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >> +#include 
> >>
> >>  #include "ci.h"
> >>
> >>  #define HS_PHY_AHB_MODE  0x0098
> >>
> >> +/* Vendor base starts at 0x200 beyond CI base */
> >> +#define HS_PHY_SEC_CTRL   0x0078
> >> +#define HS_PHY_DIG_CLAMP_ BIT(16)
> >> +
> >
> > Keep alignment
> 
> It's aligned in my editor, tabs vs. spaces problem?
> 

You can always align with tab, I just see it does not align for each
line at both my mutt and web gmail.

-- 

Best Regards,
Peter Chen


Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

2016-07-11 Thread John Stultz
On Wed, Jul 6, 2016 at 1:13 AM, Wei Xu  wrote:
> Hi Arnd, Olof,
>
> On 06/07/2016 08:38, Arnd Bergmann wrote:
>> On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote:
>>> On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson  wrote:
 On Tue, Jul 5, 2016 at 11:55 PM, John Stultz  
 wrote:
> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson  wrote:
>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
>>> This patchset enables the pl031 RTC on the Hi6220 SoC.
>>>
>>> I'd like to submit it to be merged.
>>>
>>> Wei has acked the second patch (modulo a whitespace fix which
>>> I've included in this v3), so it seems like both could go
>>> through the clk tree.
>>>
>>> But Wei also seemed open to pulling in a clk tree branch
>>> as it goes through arm-soc.
>>>
>>> Michael/Stephen: If there's no other objections, could you
>>> queue the first patch and make it avilable via the branch for
>>> Wei, or just take both patches?
>>
>> I happen to dread these kind of patchsets these days. There's added
>> dependencies across trees just because a defined name for the clock
>> number is added to a header file.
>>
>> I much prefer to use numerical clocks for one release, and then once
>> everything is in, switch over to the defines in the DTS.
>>
>> That way there are no dependencies, no need to setup a shared branch
>> for a simple 3-line patch, etc.
>>
>> So, mind respinning the DTS piece?
>
> Huh..

 Sorry if it appeared random, I've complained about it for a while to
 submaintainers.
>>>
>>> No.. I get it, the cross-maintainer shared branch is complex enough to
>>> want to avoid. I figured it would be easier to just take a maintainer
>>> acked patch in via the clk tree, but its not my tree, so I'll leave it
>>> to you maintainers to resolve.
>>
>> The question this raises is why that clock was missed the first time
>> around. I'd suggest whoever owns the clock driver can go through the
>> documentation again and look for others that may have been missed,
>> then send a patch to the driver to add *all* the missing ones for the
>> merge window, and one release later we add the driver depending on
>> previously unknown clocks.
>
> I have picked this patch based on the clk-hi6220-rtc which is based on
> 4.7-rc1 and am planning to send out the pull request which will distinguish
> the clk commits and dts commits.
>
> So should I continue to send out the pull request?

Hey Wei,
   I chatted with Arnd on IRC and from that discussion it sounded like
the pull request including the single patch clk branch will be the way
to go on this one.

Arnd: Let me know if I'm miss-characterizing this. I just wanted to
make sure there wasn't further confusion what the next steps were.

thanks
-john


[PATCH] memblock: include instead of

2016-07-11 Thread Christoph Hellwig
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: Christoph Hellwig 
---
 mm/memblock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index ac12489..5d700e4 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -20,7 +20,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 #include "internal.h"
-- 
2.1.4



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

2016-07-11 Thread Mario Limonciello
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 
---
 drivers/net/usb/r8152.c | 76 +++--
 1 file changed, 74 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0da72d3..2298f26 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Information for net-next */
 #define NETNEXT_VERSION"08"
@@ -460,6 +461,11 @@
 /* SRAM_IMPEDANCE */
 #define RX_DRIVING_MASK0x6000
 
+/* MAC PASSTHRU */
+#define AD_MASK0xfee0
+#define EFUSE  0xcfdb
+#define PASS_THRU_MASK 0x1
+
 enum rtl_register_content {
_1000bps= 0x10,
_100bps = 0x08,
@@ -1036,6 +1042,65 @@ out1:
return ret;
 }
 
+/* Devices containing RTL8153-AD can support a persistent
+ * host system provided MAC address.
+ * Examples of this are Dell TB15 and Dell WD15 docks
+ */
+static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
+{
+   acpi_status status;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   int ret = -EINVAL;
+   u32 ocp_data;
+   unsigned char buf[6];
+
+   /* test for -AD variant of RTL8153 */
+   ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+   if ((ocp_data & AD_MASK) != 0x1000)
+   return -ENODEV;
+
+   /* test for MAC address pass-through bit */
+   ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, EFUSE);
+   if ((ocp_data & PASS_THRU_MASK) != 1)
+   return -ENODEV;
+
+   /* returns _AUXMAC_#AABBCCDDEEFF# */
+   status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );
+   obj = (union acpi_object *)buffer.pointer;
+   if (!ACPI_SUCCESS(status))
+   return -ENODEV;
+   if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid buffer when reading pass-thru MAC addr: "
+  "(%d, %d)\n",
+  obj->type, obj->string.length);
+   goto amacout;
+   }
+   if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0 ||
+   strncmp(obj->string.pointer + 0x15, "#", 1) != 0) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid header when reading pass-thru MAC addr\n");
+   goto amacout;
+   }
+   ret = hex2bin(buf, obj->string.pointer + 9, 6);
+   if (!(ret == 0 && is_valid_ether_addr(buf))) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid MAC when reading pass-thru MAC addr: "
+  "%d, %pM\n", ret, buf);
+   ret = -EINVAL;
+   goto amacout;
+   }
+   memcpy(sa->sa_data, buf, 6);
+   ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
+   netif_info(tp, probe, tp->netdev,
+  "Using pass-thru MAC addr %pM\n", sa->sa_data);
+
+amacout:
+   kfree(obj);
+   return ret;
+}
+
 static int set_ethernet_addr(struct r8152 *tp)
 {
struct net_device *dev = tp->netdev;
@@ -1044,8 +1109,15 @@ static int set_ethernet_addr(struct r8152 *tp)
 
if (tp->version == RTL_VER_01)
ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
-   else
-   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
+   else {
+   /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
+* or system doesn't provide valid _SB.AMAC this will be
+* be expected to non-zero
+*/
+   ret = vendor_mac_passthru_addr_read(tp, );
+   if (ret < 0)
+   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
+   }
 
if (ret < 0) {
netif_err(tp, probe, dev, "Get ether addr fail\n");
-- 
2.7.4



[PATCH] kprobes: include instead of

2016-07-11 Thread Christoph Hellwig
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: Christoph Hellwig 
---
 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 
-- 
2.1.4



RE: Hi, Ingo, would you please help drop the TSC MSR calibration patch

2016-07-11 Thread Chen, Yu C
Hi, 
> -Original Message-
> From: Pan, Jacob jun
> Sent: Tuesday, July 12, 2016 5:19 AM
> To: Ingo Molnar
> Cc: Chen, Yu C; 'Len Brown'; Jacob Pan; H. Peter Anvin; Peter Zijlstra;
> x...@kernel.org; linux-kernel@vger.kernel.org; Pan, Jacob jun
> Subject: Re: Hi, Ingo, would you please help drop the TSC MSR calibration 
> patch
> 
> On Mon, 11 Jul 2016 21:31:04 +0200
> Ingo Molnar  wrote:
> 
> >
> > * Jacob Pan  wrote:
> >
> > > On Mon, 11 Jul 2016 07:59:19 -0700
> > > "Chen, Yu C"  wrote:
> > >
> > > > Currently it is in your x86/timer tree:
> > > >
> > > > commit fc273eeef314cdaf0ac992b400d126f8184a4d1c
> > > > Author: Len Brown 
> > > > Date:   Fri Jun 17 01:22:49 2016 -0400
> > > >
> > > > x86/tsc_msr: Extend to include Intel Core Architecture
> > > >
> > > >
> > > > Previously we found this patch might decrease the performance on
> > > > one of our servers, due to the small gap between using old PIT
> > > > calibration and new MSR calibration method, so we currently would
> > > > like to hold this patch for now, until we got a clear answer from
> > > > our architect. Would you please help revert this patch (the other
> > > > patches are safe and can be merged), sorry for the inconvenience.
> > > >
> > > I modified the subject slightly to be more specific.
> > > Adding lkml and x86 list, and a few more people.
> > > This commit is also affected, won't compile if we revert the one
> > > above.
> > >
> > > 37c528e... x86/tsc_msr: Fix rdmsr(MSR_PLATFORM_INFO) unsafe warning
> > > in KVM guest
> >
> > Ok, I've rebased tip:x86/timers, it now includes the following
> > commits:
> >
> > ff4c86635ee1 x86/tsc: Enumerate BXT tsc_khz via CPUID
> > aa297292d708 x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID
> > 02c0cd2dcf7f x86/tsc_msr: Remove irqoff around MSR-based TSC
> > enumeration 6fcb41cdaee5 x86/tsc_msr: Add Airmont reference clock
> > values 05680e7fa8a4 x86/tsc_msr: Correct Silvermont reference clock
> > values 9e0cae9f6227 x86/tsc_msr: Update comments, expand definitions
> > 14bb4e34860a x86/tsc_msr: Remove debugging messages
> > ba8268330dc1 x86/tsc_msr: Identify Intel-specific code
> > fc5f3ac24720 Revert "x86/tsc: Add missing Cherrytrail frequency to the
> > table"
> >
> > Does that work for you?
> >
> works for me but Yu has to confirm.
> 
Confirmed, thanks!

thanks,
Yu


[PATCH] printk: include instead of

2016-07-11 Thread Christoph Hellwig
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: Christoph Hellwig 
---
 kernel/printk/printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 60cdf63..fac6fd4 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -48,7 +48,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 #define CREATE_TRACE_POINTS
 #include 
-- 
2.1.4



Re: [lkp] [ACPI / APEI] a3e2acc5e3: kmsg.BERT:Can't_request_iomem_region<#-#>

2016-07-11 Thread Ye Xiaolong
On Sun, Jul 10, 2016 at 08:28:37PM -0700, Tony Luck wrote:
>I'm very surprised that there was a BERT table on an Atom machine. More 
>details about the machine please. Also BIOS version.

Hi, ying

Could you tell me what's BERT table? and how to check the BIOS version?

Thanks,
Xiaolong

>
>Sent from my iPhone
>
>> On Jul 10, 2016, at 18:43, kernel test robot  wrote:
>> 
>> 
>> FYI, we noticed the following commit:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> commit a3e2acc5e37b22b6808a0b8e46887c3577de9c9e ("ACPI / APEI: Add Boot 
>> Error Record Table (BERT) support")
>> 
>> in testcase: locktorture
>> with following parameters: runtime=300s
>> 
>> on test machine: Atom with 8G memory
>> 
>> caused below changes:
>> 
>> 
>> [   12.317148] BERT: Can't request iomem region 
>> .
>> 
>> 
>> 
>> To reproduce:
>> 
>>git clone 
>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>>cd lkp-tests
>>bin/lkp install job.yaml  # job file is attached in this email
>>bin/lkp run job.yaml
>> 
>> 
>> 
>> Thanks,
>> Xiaolong
>> 
>> 
>> 


[PATCH] DMA-API-HOWTO: is no more

2016-07-11 Thread Christoph Hellwig
So don't mention it.

Signed-off-by: Christoph Hellwig 
---
 Documentation/DMA-API-HOWTO.txt | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 781024e..494ffac 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -931,10 +931,8 @@ to "Closing".
 
 1) Struct scatterlist requirements.
 
-   Don't invent the architecture specific struct scatterlist; just use
-   . You need to enable
-   CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs
-   (including software IOMMU).
+   You need to enable CONFIG_NEED_SG_DMA_LENGTH if the architecture
+   supports IOMMUs (including software IOMMU).
 
 2) ARCH_DMA_MINALIGN
 
-- 
2.1.4



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

2016-07-11 Thread Al Viro
On Mon, Jul 11, 2016 at 05:15:04PM -0700, Chunwei Chen wrote:
> We need to check i_count again with i_lock held, because iput might re-add
> i_count when lazytime is on. Without this check, we could end up with
> double-free or use-after-free.

Details, please.  Ideally - with a reproducer.  Who is calling that iput()
at that point of generic_shutdown_super() (has to be another thread) and
just what will happen if the same iput() is delayed until *after*
evict_inodes(), all the way into ->put_super().  At which point there's
no promise whatsoever that the data structures used by ->evict_inode()
hadn't been already freed...


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

2016-07-11 Thread Lu Baolu
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?

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 (udev->persist_enabled)
>   status = wait_for_connected(udev, hub, , ,
>   );



Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Dmitry Torokhov
On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
>  wrote:
> > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> >> > There are many AML tables reporting wrong initial lid state, and some of
> >> > them never reports lid state. As a proxy layer acting between, ACPI 
> >> > button
> >> > driver is not able to handle all such cases, but need to re-define the
> >> > usage model of the ACPI lid. That is:
> >> > 1. It's initial state is not reliable;
> >> > 2. There may not be open event;
> >> > 3. Userspace should only take action against the close event which is
> >> >reliable, always sent after a real lid close.
> >> > This patch adds documentation of the usage model.
> >> >
> >> > Link: https://lkml.org/2016/3/7/460
> >> > Link: https://github.com/systemd/systemd/issues/2087
> >> > Signed-off-by: Lv Zheng 
> >> > Cc: Bastien Nocera: 
> >> > Cc: Benjamin Tissoires 
> >> > Cc: linux-in...@vger.kernel.org
> >> > ---
> >> >  Documentation/acpi/acpi-lid.txt |   62 
> >> > +++
> >> >  1 file changed, 62 insertions(+)
> >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> >
> >> > diff --git a/Documentation/acpi/acpi-lid.txt 
> >> > b/Documentation/acpi/acpi-lid.txt
> >> > new file mode 100644
> >> > index 000..7e4f7ed
> >> > --- /dev/null
> >> > +++ b/Documentation/acpi/acpi-lid.txt
> >> > @@ -0,0 +1,62 @@
> >> > +Usage Model of the ACPI Control Method Lid Device
> >> > +
> >> > +Copyright (C) 2016, Intel Corporation
> >> > +Author: Lv Zheng 
> >> > +
> >> > +
> >> > +Abstract:
> >> > +
> >> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
> >> > +control method lid device. To implement this, the AML tables issue
> >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> >> > +changed. The _LID control method for the lid device must be implemented 
> >> > to
> >> > +report the "current" state of the lid as either "opened" or "closed".
> >> > +
> >> > +This document describes the restrictions and the expections of the Linux
> >> > +ACPI lid device driver.
> >> > +
> >> > +
> >> > +1. Restrictions of the returning value of the _LID control method
> >> > +
> >> > +The _LID control method is described to return the "current" lid state.
> >> > +However the word of "current" has ambiguity, many AML tables return the 
> >> > lid
> >> > +state upon the last lid notification instead of returning the lid state
> >> > +upon the last _LID evaluation. There won't be difference when the _LID
> >> > +control method is evaluated during the runtime, the problem is its 
> >> > initial
> >> > +returning value. When the AML tables implement this control method with
> >> > +cached value, the initial returning value is likely not reliable. There 
> >> > are
> >> > +simply so many examples always retuning "closed" as initial lid state.
> >> > +
> >> > +2. Restrictions of the lid state change notifications
> >> > +
> >> > +There are many AML tables never notifying when the lid device state is
> >> > +changed to "opened". But it is ensured that the AML tables always notify
> >> > +"closed" when the lid state is changed to "closed". This is normally 
> >> > used
> >> > +to trigger some system power saving operations on Windows. Since it is
> >> > +fully tested, this notification is reliable for all AML tables.
> >> > +
> >> > +3. Expections for the userspace users of the ACPI lid device driver
> >> > +
> >> > +The userspace programs should stop relying on
> >> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
> >> > only
> >> > +used for the validation purpose.
> >>
> >> I'd say: this file actually calls the _LID method described above. And
> >> given the previous explanation, it is not reliable enough on some
> >> platforms. So it is strongly advised for user-space program to not
> >> solely rely on this file to determine the actual lid state.
> >>
> >> > +
> >> > +New userspace programs should rely on the lid "closed" notification to
> >> > +trigger some power saving operations and may stop taking actions 
> >> > according
> >> > +to the lid "opened" notification. A new input switch event - 
> >> > SW_ACPI_LID is
> >> > +prepared for the new userspace to implement this ACPI control method lid
> >> > +device specific logics.
> >>
> >> That's not entirely what we discussed before (to prevent regressions):
> >> - if the device doesn't have reliable LID switch state, then there
> >> would be the new input event, and so userspace should only rely on
> >> opened notifications.
> >> - if the device has reliable switch information, the new input event
> >> should not be exported and userspace knows that the current input
> >> 

Re: [PATCH] amba: Support clk parents and rates assigned in DT

2016-07-11 Thread Jorge Ramirez

On 07/11/2016 11:08 PM, Stephen Boyd wrote:

Add the call to of_clk_set_defaults() into the amba probe path so
that devices on the amba bus can use the assigned rates and
parents feature of the common clock framework.

Cc: Michael Turquette 
Cc: Jorge Ramirez Ortiz 
Signed-off-by: Stephen Boyd 


Tested-by: Jorge Ramirez Ortiz 


---
  drivers/amba/bus.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index a5b5c87e2114..a56fa2a1e9aa 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 
  
@@ -237,6 +238,10 @@ static int amba_probe(struct device *dev)

int ret;
  
  	do {

+   ret = of_clk_set_defaults(dev->of_node, false);
+   if (ret < 0)
+   break;
+
ret = dev_pm_domain_attach(dev, true);
if (ret == -EPROBE_DEFER)
break;




[PATCH v2] xen_pvscsi: reclaim the ring request when the prepairing failed

2016-07-11 Thread Bin Wu
During scsi command queueing or exception handling, if prepairing
fails, we need to reclaim the failed request. Otherwise, the garbage
request will be pushed into the ring for the backend to work.

Signed-off-by: Bin Wu 
---
 drivers/scsi/xen-scsifront.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 9dc8687..8646db1 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct 
vscsifrnt_info *info)
 
ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
 
-   ring->req_prod_pvt++;
-
ring_req->rqid = (uint16_t)id;
 
return ring_req;
@@ -196,6 +194,8 @@ static void scsifront_do_request(struct vscsifrnt_info 
*info)
struct vscsiif_front_ring *ring = &(info->ring);
int notify;
 
+   ring->req_prod_pvt++;
+
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
if (notify)
notify_remote_via_irq(info->irq);
-- 
2.3.2 (Apple Git-55)




Re: [Xen-devel] [PATCH] xen_pvscsi: reclaim the ring request when mapping data failed

2016-07-11 Thread Bin Wu

On 2016/7/11 17:53, Juergen Gross wrote:

On 11/07/16 11:50, David Vrabel wrote:

On 11/07/16 10:33, Juergen Gross wrote:

On 11/07/16 04:51, Bin Wu wrote:

During scsi command queueing, if mapping data fails, we need to
reclaim the failed request. Otherwise, the garbage request will
be pushed into the ring for the backend to work.

Well spotted. There is another instance of this problem in
scsifront_action_handler(). Would you mind correcting this one, too?

Would it make more sense to advance req_prod_pvt only if the request has
been successfully created?

Yeah, probably as the first action in scsifront_do_request().


Juergen

ok, I will send a new patch : )



David


Signed-off-by: Bin Wu 
---
  drivers/scsi/xen-scsifront.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 9dc8687..655163d 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -565,6 +565,7 @@ static int scsifront_queuecommand(struct Scsi_Host
*shost,
  err = map_data_for_request(info, sc, ring_req, shadow);
  if (err < 0) {
  pr_debug("%s: err %d\n", __func__, err);
+info->ring.req_prod_pvt--;
  scsifront_put_rqid(info, rqid);
  scsifront_return(info);
  spin_unlock_irqrestore(shost->host_lock, flags);


___
Xen-devel mailing list
xen-de...@lists.xen.org
https://lists.xen.org/xen-devel





.






[PATCH v2 1/3] Documentation: dtb: xgene: Add hwmon dts binding documentation

2016-07-11 Thread Hoan Tran
This patch adds the APM X-Gene hwmon device tree node documentation.

Signed-off-by: Hoan Tran 
---
 .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt

diff --git a/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt 
b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
new file mode 100644
index 000..59b3855
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
@@ -0,0 +1,14 @@
+APM X-Gene hwmon driver
+
+APM X-Gene SOC sensors are accessed over the "SLIMpro" mailbox.
+
+Required properties :
+ - compatible : should be "apm,xgene-slimpro-hwmon"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   hwmonslimpro {
+   compatible = "apm,xgene-slimpro-hwmon";
+   mboxes = < 7>;
+   };
-- 
1.9.1



[PATCH v2 2/3] hwmon: xgene: Add hwmon driver

2016-07-11 Thread Hoan Tran
This patch adds hardware temperature and power reading support for
APM X-Gene SoC using the mailbox communication interface.

Signed-off-by: Hoan Tran 
---
 Documentation/hwmon/xgene-hwmon |  30 ++
 drivers/hwmon/Kconfig   |   7 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/xgene-hwmon.c | 772 
 4 files changed, 810 insertions(+)
 create mode 100644 Documentation/hwmon/xgene-hwmon
 create mode 100644 drivers/hwmon/xgene-hwmon.c

diff --git a/Documentation/hwmon/xgene-hwmon b/Documentation/hwmon/xgene-hwmon
new file mode 100644
index 000..6ec50ed
--- /dev/null
+++ b/Documentation/hwmon/xgene-hwmon
@@ -0,0 +1,30 @@
+Kernel driver xgene-hwmon
+
+
+Supported chips:
+ * APM X-Gene SoC
+
+Description
+---
+
+This driver adds hardware temperature and power reading support for
+APM X-Gene SoC using the mailbox communication interface.
+For device tree, it is the standard DT mailbox.
+For ACPI, it is the PCC mailbox.
+
+The following sensors are supported
+
+  * Temperature
+- SoC on-die temperature in milli-degree C
+- Alarm when high/over temperature occurs
+  * Power
+- CPU power in uW
+- IO power in uW
+
+sysfs-Interface
+---
+
+temp0_input - SoC on-die temperature (milli-degree C)
+temp0_critical_alarm - An 1 would indicates on-die temperature exceeded 
threshold
+power0_input - CPU power in (uW)
+power1_input - IO power in (uW)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ff94007..55218c6 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1787,6 +1787,13 @@ config SENSORS_ULTRA45
  This driver provides support for the Ultra45 workstation environmental
  sensors.
 
+config SENSORS_XGENE
+   tristate "APM X-Gene SoC hardware monitoring driver"
+   depends on XGENE_SLIMPRO_MBOX || PCC
+   help
+ If you say yes here you get support for the temperature
+ and power sensors for APM X-Gene SoC.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 2ef5b7c..a2460dd 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -162,6 +162,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
 obj-$(CONFIG_SENSORS_W83L786NG)+= w83l786ng.o
 obj-$(CONFIG_SENSORS_WM831X)   += wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
+obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
 obj-$(CONFIG_PMBUS)+= pmbus/
 
diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
new file mode 100644
index 000..03917e3
--- /dev/null
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -0,0 +1,772 @@
+/*
+ * APM X-Gene SoC Hardware Monitoring Driver
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Author: Loc Ho 
+ * Hoan Tran 
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ * This driver provides the following features:
+ *  - Retrieve CPU total power (uW)
+ *  - Retrieve IO total power (uW)
+ *  - Retrieve SoC temperature (milli-degree C) and alarm
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* SLIMpro message defines */
+#define MSG_TYPE_DBG   0
+#define MSG_TYPE_ERR   7
+#define MSG_TYPE_PWRMGMT   9
+
+#define MSG_TYPE(v)(((v) & 0xF000) >> 28)
+#define MSG_TYPE_SET(v)(((v) << 28) & 0xF000)
+#define MSG_SUBTYPE(v) (((v) & 0x0F00) >> 24)
+#define MSG_SUBTYPE_SET(v) (((v) << 24) & 0x0F00)
+
+#define DBG_SUBTYPE_SENSOR_READ4
+#define SENSOR_RD_MSG  0x04FFE902
+#define SENSOR_RD_EN_ADDR(a)   ((a) & 0x000F)
+#define PMD_PWR_REG0x20
+#define PMD_PWR_MW_REG 0x26
+#define SOC_PWR_REG0x21
+#define SOC_PWR_MW_REG 0x27
+#define SOC_TEMP_REG   0x10
+
+#define TEMP_NEGATIVE_BIT  8
+
+#define PWRMGMT_SUBTYPE_TPC1
+#define TPC_ALARM  2
+#define TPC_GET_ALARM  3
+#define TPC_CMD(v) (((v) & 0x00FF) >> 16)
+#define TPC_CMD_SET(v)  

[PATCH v2 3/3] arm64: dts: apm: Add X-Gene SoC hwmon to device tree

2016-07-11 Thread Hoan Tran
This patch adds DT node to enable hwmon driver for APM X-Gene SoC.

Signed-off-by: Hoan Tran 
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 5 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index c569f76..a5935f5 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -472,6 +472,11 @@
mboxes = < 0>;
};
 
+   hwmonslimpro {
+   compatible = "apm,xgene-slimpro-hwmon";
+   mboxes = < 7>;
+   };
+
serial0: serial@1060 {
device_type = "serial";
compatible = "ns16550";
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 5147d76..f8ea5b5 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -716,6 +716,11 @@
mboxes = < 0>;
};
 
+   hwmonslimpro {
+   compatible = "apm,xgene-slimpro-hwmon";
+   mboxes = < 7>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1



[PATCH v2 0/3] hwmon: xgene: Add support for X-Gene hwmon driver

2016-07-11 Thread Hoan Tran
This patch set adds hardware temperature and power reading support ​for
APM X-Gene SoC using the mailbox communication interface.
For device tree, it is the standard DT mailbox.
For ACPI, it is the PCC mailbox.

For ACPI, tested with this patch[1] which supports PCC subspace 2
[1] http://www.spinics.net/lists/linux-acpi/msg66041.html
 - [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

v2
 - Increase power reading accurateness by using 2 registers
(a register for Watt, another for milli-Watt)
 - Remove power reading for SoC
 - Fix review comments from Guenter

v1
 - Initial

Hoan Tran (3):
  Documentation: dtb: xgene: Add hwmon dts binding documentation
  hwmon: xgene: Add hwmon driver
  arm64: dts: apm: Add X-Gene SoC hwmon to device tree

 .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt  |  14 +
 Documentation/hwmon/xgene-hwmon|  30 +
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi |   5 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   5 +
 drivers/hwmon/Kconfig  |   7 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/xgene-hwmon.c| 772 +
 7 files changed, 834 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
 create mode 100644 Documentation/hwmon/xgene-hwmon
 create mode 100644 drivers/hwmon/xgene-hwmon.c

-- 
1.9.1



[PATCH] media: s5p-mfc remove void function return statement

2016-07-11 Thread Shuah Khan
Remove void function return statement

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index c96421f..b6fde20 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -495,7 +495,6 @@ static void s5p_mfc_handle_error(struct s5p_mfc_dev *dev,
s5p_mfc_hw_call(dev->mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
-   return;
 }
 
 /* Header parsing interrupt handling */
-- 
2.7.4



[PATCH v1 3/3] seccomp: Remove 2-phase API documentation

2016-07-11 Thread Mickaël Salaün
Fixes: 8112c4f140fa ("seccomp: remove 2-phase API")

Signed-off-by: Mickaël Salaün 
Cc: Kees Cook 
Cc: Andy Lutomirski 
Cc: James Morris 
---
 arch/Kconfig | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index d794384a0404..96e434638767 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -336,17 +336,6 @@ config HAVE_ARCH_SECCOMP_FILTER
results in the system call being skipped immediately.
  - seccomp syscall wired up
 
- For best performance, an arch should use seccomp_phase1 and
- seccomp_phase2 directly.  It should call seccomp_phase1 for all
- syscalls if TIF_SECCOMP is set, but seccomp_phase1 does not
- need to be called from a ptrace-safe context.  It must then
- call seccomp_phase2 if seccomp_phase1 returns anything other
- than SECCOMP_PHASE1_OK or SECCOMP_PHASE1_SKIP.
-
- As an additional optimization, an arch may provide seccomp_data
- directly to seccomp_phase1; this avoids multiple calls
- to the syscall_xyz helpers for every syscall.
-
 config SECCOMP_FILTER
def_bool y
depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
-- 
2.8.1



Re: [PATCH] drm/vc4: remove redundant ret status check

2016-07-11 Thread Eric Anholt
Colin King  writes:

> From: Colin Ian King 
>
> At the current point where ret is being checked for non-zero it has
> not changed since it was initialized to zero, hence the check and the
> label unref are redundant and can be removed.

Reviewed-by: Eric Anholt 

I'll put this in my next pull request.


signature.asc
Description: PGP signature


[PATCH] vfs: check i_count under lock in evict_inodes

2016-07-11 Thread Chunwei Chen
We need to check i_count again with i_lock held, because iput might re-add
i_count when lazytime is on. Without this check, we could end up with
double-free or use-after-free.

Cc: Alexander Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-off-by: Chunwei Chen 
---
 fs/inode.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 4ccbc21..10bb020 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -607,7 +607,12 @@ again:
continue;
 
spin_lock(>i_lock);
-   if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
+   /*
+* check i_count again with lock, because iput might re-add
+* it when lazytime is on.
+*/
+   if (atomic_read(>i_count) ||
+   (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE))) {
spin_unlock(>i_lock);
continue;
}
-- 
2.7.4



  1   2   3   4   5   6   7   8   9   >