Re: [PATCH 4.9 00/83] 4.9.1-stable review

2017-01-04 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2017 at 08:50:56PM -0800, Guenter Roeck wrote:
> On 01/04/2017 12:05 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.1 release.
> > There are 83 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Jan  6 20:04:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 148 fail: 1
> Failed builds:
>   avr32:merisc_defconfig
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Failure is due to an avr32 compiler or linker problem. Nothing we can do
> about it. I'll probably drop the avr32 builds in the future unless I find
> a way to avoid the failure.

Oh good, I got worried I broke something there :)

Thanks for testing all of these.

greg k-h


[tip:perf/urgent] perf probe: Fix --funcs to show correct symbols for offline module

2017-01-04 Thread tip-bot for Masami Hiramatsu
Commit-ID:  eebc509b20881b92d62e317b2c073e57c5f200f0
Gitweb: http://git.kernel.org/tip/eebc509b20881b92d62e317b2c073e57c5f200f0
Author: Masami Hiramatsu 
AuthorDate: Wed, 4 Jan 2017 12:29:05 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 4 Jan 2017 11:15:09 -0300

perf probe: Fix --funcs to show correct symbols for offline module

Fix --funcs (-F) option to show correct symbols for offline module.
Since previous perf-probe uses machine__findnew_module_map() for offline
module, even if user passes a module file (with full path) which is for
other architecture, perf-probe always tries to load symbol map for
current kernel module.

This fix uses dso__new_map() to load the map from given binary as same
as a map for user applications.

Signed-off-by: Masami Hiramatsu 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/148350053478.19001.15435255244512631545.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 8f81096..542e647 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -163,7 +163,7 @@ static struct map *kernel_get_module_map(const char *module)
 
/* A file path -- this is an offline module */
if (module && strchr(module, '/'))
-   return machine__findnew_module_map(host_machine, 0, module);
+   return dso__new_map(module);
 
if (!module)
module = "kernel";
@@ -173,6 +173,7 @@ static struct map *kernel_get_module_map(const char *module)
if (strncmp(pos->dso->short_name + 1, module,
pos->dso->short_name_len - 2) == 0 &&
module[pos->dso->short_name_len - 2] == '\0') {
+   map__get(pos);
return pos;
}
}
@@ -188,15 +189,6 @@ struct map *get_target_map(const char *target, bool user)
return kernel_get_module_map(target);
 }
 
-static void put_target_map(struct map *map, bool user)
-{
-   if (map && user) {
-   /* Only the user map needs to be released */
-   map__put(map);
-   }
-}
-
-
 static int convert_exec_to_group(const char *exec, char **result)
 {
char *ptr1, *ptr2, *exec_copy;
@@ -412,7 +404,7 @@ static int find_alternative_probe_point(struct debuginfo 
*dinfo,
}
 
 out:
-   put_target_map(map, uprobes);
+   map__put(map);
return ret;
 
 }
@@ -2869,7 +2861,7 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
}
 
 out:
-   put_target_map(map, pev->uprobes);
+   map__put(map);
free(syms);
return ret;
 
@@ -3362,10 +3354,7 @@ int show_available_funcs(const char *target, struct 
strfilter *_filter,
return ret;
 
/* Get a symbol map */
-   if (user)
-   map = dso__new_map(target);
-   else
-   map = kernel_get_module_map(target);
+   map = get_target_map(target, user);
if (!map) {
pr_err("Failed to get a map for %s\n", (target) ? : "kernel");
return -EINVAL;
@@ -3397,9 +3386,7 @@ int show_available_funcs(const char *target, struct 
strfilter *_filter,
 }
 
 end:
-   if (user) {
-   map__put(map);
-   }
+   map__put(map);
exit_probe_symbol_maps();
 
return ret;


Re: [PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-01-04 Thread Inki Dae


2017년 01월 05일 15:55에 Andrzej Hajda 이(가) 쓴 글:
> On 04.01.2017 15:44, Rob Herring wrote:
>> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>> panel in the TM2 device.
>>>
>>> Signed-off-by: Donghwa Lee 
>>> Signed-off-by: Hyungwon Hwang 
>>> Signed-off-by: Hoegeun Kwon 
>>> ---
>>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>>  drivers/gpu/drm/panel/Makefile |   1 +
>>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>>> +
>>>  4 files changed, 788 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> new file mode 100644
>>> index 000..6879f51
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> @@ -0,0 +1,40 @@
>>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3ha2"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: I/O voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>>> +gpio pin (active high)
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [1]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> + {
>>> +   ...
>>> +
>>> +   panel@0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <_reg>;
>>> +   vci-supply = <_reg>;
>>> +   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>>> +
>>> +   port {
>>> +   panel_in: endpoint {
>>> +   remote-endpoint = <_out>;
>> As I said previously, it makes no sense to have a graph to dsi_out it is 
>> simply the parent node.
> 
> The problem is that exynos_dsi requires presence of endpoint node, when
> it was written the policy was that graphs must be always present.
> DSI reads from this node samsung,burst-clock-frequency and
> samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> remote-endpoint = <_in>;
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> port {
>> dsi_in: endpoint {
>> remote-endpoint = <_out>;
>> };
>> };
>> };
>> };
> 
> However, DSI driver does not use remote-endpoint property, it is here
> only to fulfill of_graph policy.
> So if something like below is acceptable, we can get rid of port node in
> panel:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> };
>> };
> 
> What do you think?
> 
> Other solution is to move problematic properties somewhere else, 

Re: [PATCH 1/1] x86: sanitize argument of clearcpuid command-line option

2017-01-04 Thread Ingo Molnar

* Borislav Petkov  wrote:

> On Wed, Dec 28, 2016 at 02:55:40PM +0100, Lukasz Odzioba wrote:
> > A negative number can be specified in the cmdline which will be used as
> > setup_clear_cpu_cap() argument. With that we can clear/set some bit in
> > memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel
> > to misbehave. This patch adds lower bound check to setup_disablecpuid().
> > 
> > Fixes: ac72e7888a61 ("x86: add generic clearcpuid=... option")
> > 
> > Signed-off-by: Lukasz Odzioba 
> > ---
> > As an example let's change definition of one_hundred variable:
> > 81c4eeec d one_hundred
> > 81d69720 D boot_cpu_data (0x14 is x86_capability offset)
> > 
> > 8*(0x81d69734-0x81c4eeec) => 9257536 -2 because we
> > want to clear the second bit. With clearcpuid=-9257534 we change the
> > definition of one_hundread to 96 which is used among other things
> > as sysfs' max value for swappiness, so we can check the effect like so:
> > # echo 96 >  /proc/sys/vm/swappiness
> > # echo 97 >  /proc/sys/vm/swappiness
> > -bash: echo: write error: Invalid argument
> > ---
> >  arch/x86/kernel/cpu/common.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index dc1697c..9bab7a8 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -1221,7 +1221,7 @@ static __init int setup_disablecpuid(char *arg)
> >  {
> > int bit;
> >  
> > -   if (get_option(, ) && bit < NCAPINTS*32)
> > +   if (get_option(, ) && bit >= 0 && bit < NCAPINTS * 32)
> > setup_clear_cpu_cap(bit);
> > else
> > return 0;
> > -- 
> 
> Yap, that's a good catch!
> 
> Acked-by: Borislav Petkov 
> 
> I even got a splat while experimenting with this:
> 
> 
> [1.234575] BUG: unable to handle kernel paging request at 858bd540
> [1.236535] IP: memcpy_erms+0x6/0x10

Good one, queued it up.

Btw., another (separate) fix would be to keep the kernel's option filtering 
code 
from being passive aggressive:

if (get_option(, ) && bit >= 0 && bit < NCAPINTS * 32)
setup_clear_cpu_cap(bit);
else
return 0;

When we don't accept the value we should at least inform the user (via a printk 
that includes the 'clearcpuid' token in its message) that we totally ignored 
whatever he wanted. Something like:

pr_warn("x86/cpu: Ignoring invalid "clearcpuid=%s' option!\n", arg)

Which would save quite a bit of head scratching and frustration when someone 
has a 
bad enough day to add silly typos to the kernel cmdline.

Thanks,

Ingo


[tip:perf/urgent] perf symbols: Robustify reading of build-id from sysfs

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  7934c98a6e04028eb34c1293bfb5a6b0ab630b66
Gitweb: http://git.kernel.org/tip/7934c98a6e04028eb34c1293bfb5a6b0ab630b66
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 3 Jan 2017 15:19:21 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 16:11:13 -0300

perf symbols: Robustify reading of build-id from sysfs

Markus reported that perf segfaults when reading /sys/kernel/notes from
a kernel linked with GNU gold, due to what looks like a gold bug, so do
some bounds checking to avoid crashing in that case.

Reported-by: Markus Trippelsdorf 
Report-Link: http://lkml.kernel.org/r/20161219161821.GA294@x4
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ryhgs6a6jxvz207j2636w...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 99400b0..adbc6c0 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -537,6 +537,12 @@ int sysfs__read_build_id(const char *filename, void 
*build_id, size_t size)
break;
} else {
int n = namesz + descsz;
+
+   if (n > (int)sizeof(bf)) {
+   n = sizeof(bf);
+   pr_debug("%s: truncating reading of build id in 
sysfs file %s: n_namesz=%u, n_descsz=%u.\n",
+__func__, filename, nhdr.n_namesz, 
nhdr.n_descsz);
+   }
if (read(fd, bf, n) != n)
break;
}


[tip:perf/urgent] tools lib traceevent: Fix prev/next_prio for deadline tasks

2017-01-04 Thread tip-bot for Daniel Bristot de Oliveira
Commit-ID:  074859184d770824f4437dca716bdeb625ae8b1c
Gitweb: http://git.kernel.org/tip/074859184d770824f4437dca716bdeb625ae8b1c
Author: Daniel Bristot de Oliveira 
AuthorDate: Tue, 3 Jan 2017 12:42:42 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 16:11:12 -0300

tools lib traceevent: Fix prev/next_prio for deadline tasks

Currently, the sched:sched_switch tracepoint reports deadline tasks with
priority -1. But when reading the trace via perf script I've got the
following output:

  # ./d & # (d is a deadline task, see [1])
  # perf record -e sched:sched_switch -a sleep 1
  # perf script
  ...
 swapper 0 [000]  2146.962441: sched:sched_switch: swapper/0:0 
[120] R ==> d:2593 [4294967295]
   d  2593 [000]  2146.972472: sched:sched_switch: d:2593 
[4294967295] R ==> g:2590 [4294967295]

The task d reports the wrong priority [4294967295]. This happens because
the "int prio" is stored in an unsigned long long val. Although it is
set as a %lld, as int is shorter than unsigned long long,
trace_seq_printf prints it as a positive number.

The fix is just to cast the val as an int, and print it as a %d,
as in the sched:sched_switch tracepoint's "format".

The output with the fix is:

  # ./d &
  # perf record -e sched:sched_switch -a sleep 1
  # perf script
  ...
 swapper 0 [000]  4306.374037: sched:sched_switch: swapper/0:0 
[120] R ==> d:10941 [-1]
   d 10941 [000]  4306.383823: sched:sched_switch: d:10941 [-1] R 
==> swapper/0:0 [120]

[1] d.c

 ---
  #include 
  #include 
  #include 
  #include 
  #include 

  struct sched_attr {
__u32 size, sched_policy;
__u64 sched_flags;
__s32 sched_nice;
__u32 sched_priority;
__u64 sched_runtime, sched_deadline, sched_period;
  };

  int sched_setattr(pid_t pid, const struct sched_attr *attr, unsigned int 
flags)
  {
return syscall(__NR_sched_setattr, pid, attr, flags);
  }

  int main(void)
  {
struct sched_attr attr = {
.size   = sizeof(attr),
.sched_policy   = SCHED_DEADLINE, /* This creates a 10ms/30ms 
reservation */
.sched_runtime  = 10 * 1000 * 1000,
.sched_period   = attr.sched_deadline = 30 * 1000 * 1000,
};

if (sched_setattr(0, , 0) < 0) {
perror("sched_setattr");
return -1;
}

for(;;);
  }
 ---

Committer notes:

Got the program from the provided URL, http://bristot.me/lkml/d.c,
trimmed it and included in the cset log above, so that we have
everything needed to test it in one place.

Signed-off-by: Daniel Bristot de Oliveira 
Acked-by: Steven Rostedt 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Daniel Bristot de Oliveira 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/866ef75bcebf670ae91c6a96daa63597ba981f0d.1483443552.git.bris...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/plugin_sched_switch.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/traceevent/plugin_sched_switch.c 
b/tools/lib/traceevent/plugin_sched_switch.c
index f1ce600..ec30c2f 100644
--- a/tools/lib/traceevent/plugin_sched_switch.c
+++ b/tools/lib/traceevent/plugin_sched_switch.c
@@ -111,7 +111,7 @@ static int sched_switch_handler(struct trace_seq *s,
trace_seq_printf(s, "%lld ", val);
 
if (pevent_get_field_val(s, event, "prev_prio", record, , 0) == 0)
-   trace_seq_printf(s, "[%lld] ", val);
+   trace_seq_printf(s, "[%d] ", (int) val);
 
if (pevent_get_field_val(s,  event, "prev_state", record, , 0) == 0)
write_state(s, val);
@@ -129,7 +129,7 @@ static int sched_switch_handler(struct trace_seq *s,
trace_seq_printf(s, "%lld", val);
 
if (pevent_get_field_val(s, event, "next_prio", record, , 0) == 0)
-   trace_seq_printf(s, " [%lld]", val);
+   trace_seq_printf(s, " [%d]", (int) val);
 
return 0;
 }


Re: [PATCH 4.9 00/83] 4.9.1-stable review

2017-01-04 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2017 at 08:50:56PM -0800, Guenter Roeck wrote:
> On 01/04/2017 12:05 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.1 release.
> > There are 83 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Jan  6 20:04:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 149 pass: 148 fail: 1
> Failed builds:
>   avr32:merisc_defconfig
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Failure is due to an avr32 compiler or linker problem. Nothing we can do
> about it. I'll probably drop the avr32 builds in the future unless I find
> a way to avoid the failure.

Oh good, I got worried I broke something there :)

Thanks for testing all of these.

greg k-h


[tip:perf/urgent] perf probe: Fix --funcs to show correct symbols for offline module

2017-01-04 Thread tip-bot for Masami Hiramatsu
Commit-ID:  eebc509b20881b92d62e317b2c073e57c5f200f0
Gitweb: http://git.kernel.org/tip/eebc509b20881b92d62e317b2c073e57c5f200f0
Author: Masami Hiramatsu 
AuthorDate: Wed, 4 Jan 2017 12:29:05 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 4 Jan 2017 11:15:09 -0300

perf probe: Fix --funcs to show correct symbols for offline module

Fix --funcs (-F) option to show correct symbols for offline module.
Since previous perf-probe uses machine__findnew_module_map() for offline
module, even if user passes a module file (with full path) which is for
other architecture, perf-probe always tries to load symbol map for
current kernel module.

This fix uses dso__new_map() to load the map from given binary as same
as a map for user applications.

Signed-off-by: Masami Hiramatsu 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/148350053478.19001.15435255244512631545.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 8f81096..542e647 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -163,7 +163,7 @@ static struct map *kernel_get_module_map(const char *module)
 
/* A file path -- this is an offline module */
if (module && strchr(module, '/'))
-   return machine__findnew_module_map(host_machine, 0, module);
+   return dso__new_map(module);
 
if (!module)
module = "kernel";
@@ -173,6 +173,7 @@ static struct map *kernel_get_module_map(const char *module)
if (strncmp(pos->dso->short_name + 1, module,
pos->dso->short_name_len - 2) == 0 &&
module[pos->dso->short_name_len - 2] == '\0') {
+   map__get(pos);
return pos;
}
}
@@ -188,15 +189,6 @@ struct map *get_target_map(const char *target, bool user)
return kernel_get_module_map(target);
 }
 
-static void put_target_map(struct map *map, bool user)
-{
-   if (map && user) {
-   /* Only the user map needs to be released */
-   map__put(map);
-   }
-}
-
-
 static int convert_exec_to_group(const char *exec, char **result)
 {
char *ptr1, *ptr2, *exec_copy;
@@ -412,7 +404,7 @@ static int find_alternative_probe_point(struct debuginfo 
*dinfo,
}
 
 out:
-   put_target_map(map, uprobes);
+   map__put(map);
return ret;
 
 }
@@ -2869,7 +2861,7 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
}
 
 out:
-   put_target_map(map, pev->uprobes);
+   map__put(map);
free(syms);
return ret;
 
@@ -3362,10 +3354,7 @@ int show_available_funcs(const char *target, struct 
strfilter *_filter,
return ret;
 
/* Get a symbol map */
-   if (user)
-   map = dso__new_map(target);
-   else
-   map = kernel_get_module_map(target);
+   map = get_target_map(target, user);
if (!map) {
pr_err("Failed to get a map for %s\n", (target) ? : "kernel");
return -EINVAL;
@@ -3397,9 +3386,7 @@ int show_available_funcs(const char *target, struct 
strfilter *_filter,
 }
 
 end:
-   if (user) {
-   map__put(map);
-   }
+   map__put(map);
exit_probe_symbol_maps();
 
return ret;


Re: [PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-01-04 Thread Inki Dae


2017년 01월 05일 15:55에 Andrzej Hajda 이(가) 쓴 글:
> On 04.01.2017 15:44, Rob Herring wrote:
>> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>> panel in the TM2 device.
>>>
>>> Signed-off-by: Donghwa Lee 
>>> Signed-off-by: Hyungwon Hwang 
>>> Signed-off-by: Hoegeun Kwon 
>>> ---
>>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>>  drivers/gpu/drm/panel/Makefile |   1 +
>>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>>> +
>>>  4 files changed, 788 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> new file mode 100644
>>> index 000..6879f51
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> @@ -0,0 +1,40 @@
>>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3ha2"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: I/O voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>>> +gpio pin (active high)
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [1]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> + {
>>> +   ...
>>> +
>>> +   panel@0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <_reg>;
>>> +   vci-supply = <_reg>;
>>> +   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>>> +
>>> +   port {
>>> +   panel_in: endpoint {
>>> +   remote-endpoint = <_out>;
>> As I said previously, it makes no sense to have a graph to dsi_out it is 
>> simply the parent node.
> 
> The problem is that exynos_dsi requires presence of endpoint node, when
> it was written the policy was that graphs must be always present.
> DSI reads from this node samsung,burst-clock-frequency and
> samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> remote-endpoint = <_in>;
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> port {
>> dsi_in: endpoint {
>> remote-endpoint = <_out>;
>> };
>> };
>> };
>> };
> 
> However, DSI driver does not use remote-endpoint property, it is here
> only to fulfill of_graph policy.
> So if something like below is acceptable, we can get rid of port node in
> panel:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> };
>> };
> 
> What do you think?
> 
> Other solution is to move problematic properties somewhere else, but
> this require change of bindings.
> Anyway I would be glad to remove 

Re: [PATCH 1/1] x86: sanitize argument of clearcpuid command-line option

2017-01-04 Thread Ingo Molnar

* Borislav Petkov  wrote:

> On Wed, Dec 28, 2016 at 02:55:40PM +0100, Lukasz Odzioba wrote:
> > A negative number can be specified in the cmdline which will be used as
> > setup_clear_cpu_cap() argument. With that we can clear/set some bit in
> > memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel
> > to misbehave. This patch adds lower bound check to setup_disablecpuid().
> > 
> > Fixes: ac72e7888a61 ("x86: add generic clearcpuid=... option")
> > 
> > Signed-off-by: Lukasz Odzioba 
> > ---
> > As an example let's change definition of one_hundred variable:
> > 81c4eeec d one_hundred
> > 81d69720 D boot_cpu_data (0x14 is x86_capability offset)
> > 
> > 8*(0x81d69734-0x81c4eeec) => 9257536 -2 because we
> > want to clear the second bit. With clearcpuid=-9257534 we change the
> > definition of one_hundread to 96 which is used among other things
> > as sysfs' max value for swappiness, so we can check the effect like so:
> > # echo 96 >  /proc/sys/vm/swappiness
> > # echo 97 >  /proc/sys/vm/swappiness
> > -bash: echo: write error: Invalid argument
> > ---
> >  arch/x86/kernel/cpu/common.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index dc1697c..9bab7a8 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -1221,7 +1221,7 @@ static __init int setup_disablecpuid(char *arg)
> >  {
> > int bit;
> >  
> > -   if (get_option(, ) && bit < NCAPINTS*32)
> > +   if (get_option(, ) && bit >= 0 && bit < NCAPINTS * 32)
> > setup_clear_cpu_cap(bit);
> > else
> > return 0;
> > -- 
> 
> Yap, that's a good catch!
> 
> Acked-by: Borislav Petkov 
> 
> I even got a splat while experimenting with this:
> 
> 
> [1.234575] BUG: unable to handle kernel paging request at 858bd540
> [1.236535] IP: memcpy_erms+0x6/0x10

Good one, queued it up.

Btw., another (separate) fix would be to keep the kernel's option filtering 
code 
from being passive aggressive:

if (get_option(, ) && bit >= 0 && bit < NCAPINTS * 32)
setup_clear_cpu_cap(bit);
else
return 0;

When we don't accept the value we should at least inform the user (via a printk 
that includes the 'clearcpuid' token in its message) that we totally ignored 
whatever he wanted. Something like:

pr_warn("x86/cpu: Ignoring invalid "clearcpuid=%s' option!\n", arg)

Which would save quite a bit of head scratching and frustration when someone 
has a 
bad enough day to add silly typos to the kernel cmdline.

Thanks,

Ingo


[tip:perf/urgent] perf symbols: Robustify reading of build-id from sysfs

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  7934c98a6e04028eb34c1293bfb5a6b0ab630b66
Gitweb: http://git.kernel.org/tip/7934c98a6e04028eb34c1293bfb5a6b0ab630b66
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 3 Jan 2017 15:19:21 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 16:11:13 -0300

perf symbols: Robustify reading of build-id from sysfs

Markus reported that perf segfaults when reading /sys/kernel/notes from
a kernel linked with GNU gold, due to what looks like a gold bug, so do
some bounds checking to avoid crashing in that case.

Reported-by: Markus Trippelsdorf 
Report-Link: http://lkml.kernel.org/r/20161219161821.GA294@x4
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ryhgs6a6jxvz207j2636w...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 99400b0..adbc6c0 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -537,6 +537,12 @@ int sysfs__read_build_id(const char *filename, void 
*build_id, size_t size)
break;
} else {
int n = namesz + descsz;
+
+   if (n > (int)sizeof(bf)) {
+   n = sizeof(bf);
+   pr_debug("%s: truncating reading of build id in 
sysfs file %s: n_namesz=%u, n_descsz=%u.\n",
+__func__, filename, nhdr.n_namesz, 
nhdr.n_descsz);
+   }
if (read(fd, bf, n) != n)
break;
}


[tip:perf/urgent] tools lib traceevent: Fix prev/next_prio for deadline tasks

2017-01-04 Thread tip-bot for Daniel Bristot de Oliveira
Commit-ID:  074859184d770824f4437dca716bdeb625ae8b1c
Gitweb: http://git.kernel.org/tip/074859184d770824f4437dca716bdeb625ae8b1c
Author: Daniel Bristot de Oliveira 
AuthorDate: Tue, 3 Jan 2017 12:42:42 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 16:11:12 -0300

tools lib traceevent: Fix prev/next_prio for deadline tasks

Currently, the sched:sched_switch tracepoint reports deadline tasks with
priority -1. But when reading the trace via perf script I've got the
following output:

  # ./d & # (d is a deadline task, see [1])
  # perf record -e sched:sched_switch -a sleep 1
  # perf script
  ...
 swapper 0 [000]  2146.962441: sched:sched_switch: swapper/0:0 
[120] R ==> d:2593 [4294967295]
   d  2593 [000]  2146.972472: sched:sched_switch: d:2593 
[4294967295] R ==> g:2590 [4294967295]

The task d reports the wrong priority [4294967295]. This happens because
the "int prio" is stored in an unsigned long long val. Although it is
set as a %lld, as int is shorter than unsigned long long,
trace_seq_printf prints it as a positive number.

The fix is just to cast the val as an int, and print it as a %d,
as in the sched:sched_switch tracepoint's "format".

The output with the fix is:

  # ./d &
  # perf record -e sched:sched_switch -a sleep 1
  # perf script
  ...
 swapper 0 [000]  4306.374037: sched:sched_switch: swapper/0:0 
[120] R ==> d:10941 [-1]
   d 10941 [000]  4306.383823: sched:sched_switch: d:10941 [-1] R 
==> swapper/0:0 [120]

[1] d.c

 ---
  #include 
  #include 
  #include 
  #include 
  #include 

  struct sched_attr {
__u32 size, sched_policy;
__u64 sched_flags;
__s32 sched_nice;
__u32 sched_priority;
__u64 sched_runtime, sched_deadline, sched_period;
  };

  int sched_setattr(pid_t pid, const struct sched_attr *attr, unsigned int 
flags)
  {
return syscall(__NR_sched_setattr, pid, attr, flags);
  }

  int main(void)
  {
struct sched_attr attr = {
.size   = sizeof(attr),
.sched_policy   = SCHED_DEADLINE, /* This creates a 10ms/30ms 
reservation */
.sched_runtime  = 10 * 1000 * 1000,
.sched_period   = attr.sched_deadline = 30 * 1000 * 1000,
};

if (sched_setattr(0, , 0) < 0) {
perror("sched_setattr");
return -1;
}

for(;;);
  }
 ---

Committer notes:

Got the program from the provided URL, http://bristot.me/lkml/d.c,
trimmed it and included in the cset log above, so that we have
everything needed to test it in one place.

Signed-off-by: Daniel Bristot de Oliveira 
Acked-by: Steven Rostedt 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Daniel Bristot de Oliveira 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/866ef75bcebf670ae91c6a96daa63597ba981f0d.1483443552.git.bris...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/plugin_sched_switch.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/traceevent/plugin_sched_switch.c 
b/tools/lib/traceevent/plugin_sched_switch.c
index f1ce600..ec30c2f 100644
--- a/tools/lib/traceevent/plugin_sched_switch.c
+++ b/tools/lib/traceevent/plugin_sched_switch.c
@@ -111,7 +111,7 @@ static int sched_switch_handler(struct trace_seq *s,
trace_seq_printf(s, "%lld ", val);
 
if (pevent_get_field_val(s, event, "prev_prio", record, , 0) == 0)
-   trace_seq_printf(s, "[%lld] ", val);
+   trace_seq_printf(s, "[%d] ", (int) val);
 
if (pevent_get_field_val(s,  event, "prev_state", record, , 0) == 0)
write_state(s, val);
@@ -129,7 +129,7 @@ static int sched_switch_handler(struct trace_seq *s,
trace_seq_printf(s, "%lld", val);
 
if (pevent_get_field_val(s, event, "next_prio", record, , 0) == 0)
-   trace_seq_printf(s, " [%lld]", val);
+   trace_seq_printf(s, " [%d]", (int) val);
 
return 0;
 }


[tip:perf/urgent] perf probe: Fix to probe on gcc generated symbols for offline kernel

2017-01-04 Thread tip-bot for Masami Hiramatsu
Commit-ID:  8a937a25a7e3c19d5fb3f9d92f605cf5fda219d8
Gitweb: http://git.kernel.org/tip/8a937a25a7e3c19d5fb3f9d92f605cf5fda219d8
Author: Masami Hiramatsu 
AuthorDate: Wed, 4 Jan 2017 12:30:19 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 4 Jan 2017 11:44:22 -0300

perf probe: Fix to probe on gcc generated symbols for offline kernel

Fix perf-probe to show probe definition on gcc generated symbols for
offline kernel (including cross-arch kernel image).

gcc sometimes optimizes functions and generate new symbols with suffixes
such as ".constprop.N" or ".isra.N" etc. Since those symbol names are
not recorded in DWARF, we have to find correct generated symbols from
offline ELF binary to probe on it (kallsyms doesn't correct it).  For
online kernel or uprobes we don't need it because those are rebased on
_text, or a section relative address.

E.g. Without this:

  $ perf probe -k build-arm/vmlinux -F __slab_alloc*
  __slab_alloc.constprop.9
  $ perf probe -k build-arm/vmlinux -D __slab_alloc
  p:probe/__slab_alloc __slab_alloc+0

If you put above definition on target machine, it should fail
because there is no __slab_alloc in kallsyms.

With this fix, perf probe shows correct probe definition on
__slab_alloc.constprop.9:

  $ perf probe -k build-arm/vmlinux -D __slab_alloc
  p:probe/__slab_alloc __slab_alloc.constprop.9+0

Signed-off-by: Masami Hiramatsu 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/148350060434.19001.11864836288580083501.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 542e647..4a57c8a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -610,6 +610,51 @@ error:
return ret ? : -ENOENT;
 }
 
+/*
+ * Rename DWARF symbols to ELF symbols -- gcc sometimes optimizes functions
+ * and generate new symbols with suffixes such as .constprop.N or .isra.N
+ * etc. Since those symbols are not recorded in DWARF, we have to find
+ * correct generated symbols from offline ELF binary.
+ * For online kernel or uprobes we don't need this because those are
+ * rebased on _text, or already a section relative address.
+ */
+static int
+post_process_offline_probe_trace_events(struct probe_trace_event *tevs,
+   int ntevs, const char *pathname)
+{
+   struct symbol *sym;
+   struct map *map;
+   unsigned long stext = 0;
+   u64 addr;
+   int i;
+
+   /* Prepare a map for offline binary */
+   map = dso__new_map(pathname);
+   if (!map || get_text_start_address(pathname, ) < 0) {
+   pr_warning("Failed to get ELF symbols for %s\n", pathname);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < ntevs; i++) {
+   addr = tevs[i].point.address + tevs[i].point.offset - stext;
+   sym = map__find_symbol(map, addr);
+   if (!sym)
+   continue;
+   if (!strcmp(sym->name, tevs[i].point.symbol))
+   continue;
+   /* If we have no realname, use symbol for it */
+   if (!tevs[i].point.realname)
+   tevs[i].point.realname = tevs[i].point.symbol;
+   else
+   free(tevs[i].point.symbol);
+   tevs[i].point.symbol = strdup(sym->name);
+   tevs[i].point.offset = addr - sym->start;
+   }
+   map__put(map);
+
+   return 0;
+}
+
 static int add_exec_to_probe_trace_events(struct probe_trace_event *tevs,
  int ntevs, const char *exec)
 {
@@ -671,7 +716,8 @@ post_process_kernel_probe_trace_events(struct 
probe_trace_event *tevs,
 
/* Skip post process if the target is an offline kernel */
if (symbol_conf.ignore_vmlinux_buildid)
-   return 0;
+   return post_process_offline_probe_trace_events(tevs, ntevs,
+   symbol_conf.vmlinux_name);
 
reloc_sym = kernel_get_ref_reloc_sym();
if (!reloc_sym) {


[tip:perf/urgent] perf probe: Fix to probe on gcc generated symbols for offline kernel

2017-01-04 Thread tip-bot for Masami Hiramatsu
Commit-ID:  8a937a25a7e3c19d5fb3f9d92f605cf5fda219d8
Gitweb: http://git.kernel.org/tip/8a937a25a7e3c19d5fb3f9d92f605cf5fda219d8
Author: Masami Hiramatsu 
AuthorDate: Wed, 4 Jan 2017 12:30:19 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 4 Jan 2017 11:44:22 -0300

perf probe: Fix to probe on gcc generated symbols for offline kernel

Fix perf-probe to show probe definition on gcc generated symbols for
offline kernel (including cross-arch kernel image).

gcc sometimes optimizes functions and generate new symbols with suffixes
such as ".constprop.N" or ".isra.N" etc. Since those symbol names are
not recorded in DWARF, we have to find correct generated symbols from
offline ELF binary to probe on it (kallsyms doesn't correct it).  For
online kernel or uprobes we don't need it because those are rebased on
_text, or a section relative address.

E.g. Without this:

  $ perf probe -k build-arm/vmlinux -F __slab_alloc*
  __slab_alloc.constprop.9
  $ perf probe -k build-arm/vmlinux -D __slab_alloc
  p:probe/__slab_alloc __slab_alloc+0

If you put above definition on target machine, it should fail
because there is no __slab_alloc in kallsyms.

With this fix, perf probe shows correct probe definition on
__slab_alloc.constprop.9:

  $ perf probe -k build-arm/vmlinux -D __slab_alloc
  p:probe/__slab_alloc __slab_alloc.constprop.9+0

Signed-off-by: Masami Hiramatsu 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/148350060434.19001.11864836288580083501.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 542e647..4a57c8a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -610,6 +610,51 @@ error:
return ret ? : -ENOENT;
 }
 
+/*
+ * Rename DWARF symbols to ELF symbols -- gcc sometimes optimizes functions
+ * and generate new symbols with suffixes such as .constprop.N or .isra.N
+ * etc. Since those symbols are not recorded in DWARF, we have to find
+ * correct generated symbols from offline ELF binary.
+ * For online kernel or uprobes we don't need this because those are
+ * rebased on _text, or already a section relative address.
+ */
+static int
+post_process_offline_probe_trace_events(struct probe_trace_event *tevs,
+   int ntevs, const char *pathname)
+{
+   struct symbol *sym;
+   struct map *map;
+   unsigned long stext = 0;
+   u64 addr;
+   int i;
+
+   /* Prepare a map for offline binary */
+   map = dso__new_map(pathname);
+   if (!map || get_text_start_address(pathname, ) < 0) {
+   pr_warning("Failed to get ELF symbols for %s\n", pathname);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < ntevs; i++) {
+   addr = tevs[i].point.address + tevs[i].point.offset - stext;
+   sym = map__find_symbol(map, addr);
+   if (!sym)
+   continue;
+   if (!strcmp(sym->name, tevs[i].point.symbol))
+   continue;
+   /* If we have no realname, use symbol for it */
+   if (!tevs[i].point.realname)
+   tevs[i].point.realname = tevs[i].point.symbol;
+   else
+   free(tevs[i].point.symbol);
+   tevs[i].point.symbol = strdup(sym->name);
+   tevs[i].point.offset = addr - sym->start;
+   }
+   map__put(map);
+
+   return 0;
+}
+
 static int add_exec_to_probe_trace_events(struct probe_trace_event *tevs,
  int ntevs, const char *exec)
 {
@@ -671,7 +716,8 @@ post_process_kernel_probe_trace_events(struct 
probe_trace_event *tevs,
 
/* Skip post process if the target is an offline kernel */
if (symbol_conf.ignore_vmlinux_buildid)
-   return 0;
+   return post_process_offline_probe_trace_events(tevs, ntevs,
+   symbol_conf.vmlinux_name);
 
reloc_sym = kernel_get_ref_reloc_sym();
if (!reloc_sym) {


[tip:perf/urgent] perf probe: Fix to get correct modname from elf header

2017-01-04 Thread tip-bot for Masami Hiramatsu
Commit-ID:  1f2ed153b916c95a49a1ca9d7107738664224b7f
Gitweb: http://git.kernel.org/tip/1f2ed153b916c95a49a1ca9d7107738664224b7f
Author: Masami Hiramatsu 
AuthorDate: Tue, 3 Jan 2017 00:20:49 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 2 Jan 2017 14:09:17 -0300

perf probe: Fix to get correct modname from elf header

Since 'perf probe' supports cross-arch probes, it is possible to analyze
different arch kernel image which has different bits-per-long.

In that case, it fails to get the module name because it uses the
MOD_NAME_OFFSET macro based on the host machine bits-per-long, instead
of the target arch bits-per-long.

This fixes above issue by changing modname-offset based on the target
archs bit width. This is ok because linux kernel uses LP64 model on
64bit arch.

E.g. without this (on x86_64, and target module is arm32):

  $ perf probe -m build-arm/fs/configfs/configfs.ko -D configfs_lookup
  p:probe/configfs_lookup :configfs_lookup+0
  ^-Here is an empty module name.

With this fix, you can see correct module name:

  $ perf probe -m build-arm/fs/configfs/configfs.ko -D configfs_lookup
  p:probe/configfs_lookup configfs:configfs_lookup+0

Signed-off-by: Masami Hiramatsu 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/148337043836.6752.383495516397005695.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d281ae2..8f81096 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -268,21 +268,6 @@ static bool kprobe_warn_out_range(const char *symbol, 
unsigned long address)
 }
 
 /*
- * NOTE:
- * '.gnu.linkonce.this_module' section of kernel module elf directly
- * maps to 'struct module' from linux/module.h. This section contains
- * actual module name which will be used by kernel after loading it.
- * But, we cannot use 'struct module' here since linux/module.h is not
- * exposed to user-space. Offset of 'name' has remained same from long
- * time, so hardcoding it here.
- */
-#ifdef __LP64__
-#define MOD_NAME_OFFSET 24
-#else
-#define MOD_NAME_OFFSET 12
-#endif
-
-/*
  * @module can be module name of module file path. In case of path,
  * inspect elf and find out what is actual module name.
  * Caller has to free mod_name after using it.
@@ -296,6 +281,7 @@ static char *find_module_name(const char *module)
Elf_Data *data;
Elf_Scn *sec;
char *mod_name = NULL;
+   int name_offset;
 
fd = open(module, O_RDONLY);
if (fd < 0)
@@ -317,7 +303,21 @@ static char *find_module_name(const char *module)
if (!data || !data->d_buf)
goto ret_err;
 
-   mod_name = strdup((char *)data->d_buf + MOD_NAME_OFFSET);
+   /*
+* NOTE:
+* '.gnu.linkonce.this_module' section of kernel module elf directly
+* maps to 'struct module' from linux/module.h. This section contains
+* actual module name which will be used by kernel after loading it.
+* But, we cannot use 'struct module' here since linux/module.h is not
+* exposed to user-space. Offset of 'name' has remained same from long
+* time, so hardcoding it here.
+*/
+   if (ehdr.e_ident[EI_CLASS] == ELFCLASS32)
+   name_offset = 12;
+   else/* expect ELFCLASS64 by default */
+   name_offset = 24;
+
+   mod_name = strdup((char *)data->d_buf + name_offset);
 
 ret_err:
elf_end(elf);


[tip:perf/urgent] perf tools: Install tools/lib/traceevent plugins with install-bin

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  30a9c6444810429aa2b7cbfbd453ce339baaadbf
Gitweb: http://git.kernel.org/tip/30a9c6444810429aa2b7cbfbd453ce339baaadbf
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 3 Jan 2017 12:03:59 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 16:11:13 -0300

perf tools: Install tools/lib/traceevent plugins with install-bin

Those are binaries as well, so should be installed by:

  make -C tools/perf install-bin'

too.

Cc: Alexander Shishkin 
Cc: Daniel Bristot de Oliveira 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: http://lkml.kernel.org/n/tip-3841b37u05evxrs1igkyu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index e9ec531..4db68ae 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -704,9 +704,9 @@ install-tests: all install-gtk
$(INSTALL) -d -m 755 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests/attr'; \
$(INSTALL) tests/attr/* 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests/attr'
 
-install-bin: install-tools install-tests
+install-bin: install-tools install-tests install-traceevent-plugins
 
-install: install-bin try-install-man install-traceevent-plugins
+install: install-bin try-install-man
 
 install-python_ext:
$(PYTHON_WORD) util/setup.py --quiet install --root='/$(DESTDIR_SQ)'


[tip:perf/urgent] perf probe: Fix to get correct modname from elf header

2017-01-04 Thread tip-bot for Masami Hiramatsu
Commit-ID:  1f2ed153b916c95a49a1ca9d7107738664224b7f
Gitweb: http://git.kernel.org/tip/1f2ed153b916c95a49a1ca9d7107738664224b7f
Author: Masami Hiramatsu 
AuthorDate: Tue, 3 Jan 2017 00:20:49 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 2 Jan 2017 14:09:17 -0300

perf probe: Fix to get correct modname from elf header

Since 'perf probe' supports cross-arch probes, it is possible to analyze
different arch kernel image which has different bits-per-long.

In that case, it fails to get the module name because it uses the
MOD_NAME_OFFSET macro based on the host machine bits-per-long, instead
of the target arch bits-per-long.

This fixes above issue by changing modname-offset based on the target
archs bit width. This is ok because linux kernel uses LP64 model on
64bit arch.

E.g. without this (on x86_64, and target module is arm32):

  $ perf probe -m build-arm/fs/configfs/configfs.ko -D configfs_lookup
  p:probe/configfs_lookup :configfs_lookup+0
  ^-Here is an empty module name.

With this fix, you can see correct module name:

  $ perf probe -m build-arm/fs/configfs/configfs.ko -D configfs_lookup
  p:probe/configfs_lookup configfs:configfs_lookup+0

Signed-off-by: Masami Hiramatsu 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/148337043836.6752.383495516397005695.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d281ae2..8f81096 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -268,21 +268,6 @@ static bool kprobe_warn_out_range(const char *symbol, 
unsigned long address)
 }
 
 /*
- * NOTE:
- * '.gnu.linkonce.this_module' section of kernel module elf directly
- * maps to 'struct module' from linux/module.h. This section contains
- * actual module name which will be used by kernel after loading it.
- * But, we cannot use 'struct module' here since linux/module.h is not
- * exposed to user-space. Offset of 'name' has remained same from long
- * time, so hardcoding it here.
- */
-#ifdef __LP64__
-#define MOD_NAME_OFFSET 24
-#else
-#define MOD_NAME_OFFSET 12
-#endif
-
-/*
  * @module can be module name of module file path. In case of path,
  * inspect elf and find out what is actual module name.
  * Caller has to free mod_name after using it.
@@ -296,6 +281,7 @@ static char *find_module_name(const char *module)
Elf_Data *data;
Elf_Scn *sec;
char *mod_name = NULL;
+   int name_offset;
 
fd = open(module, O_RDONLY);
if (fd < 0)
@@ -317,7 +303,21 @@ static char *find_module_name(const char *module)
if (!data || !data->d_buf)
goto ret_err;
 
-   mod_name = strdup((char *)data->d_buf + MOD_NAME_OFFSET);
+   /*
+* NOTE:
+* '.gnu.linkonce.this_module' section of kernel module elf directly
+* maps to 'struct module' from linux/module.h. This section contains
+* actual module name which will be used by kernel after loading it.
+* But, we cannot use 'struct module' here since linux/module.h is not
+* exposed to user-space. Offset of 'name' has remained same from long
+* time, so hardcoding it here.
+*/
+   if (ehdr.e_ident[EI_CLASS] == ELFCLASS32)
+   name_offset = 12;
+   else/* expect ELFCLASS64 by default */
+   name_offset = 24;
+
+   mod_name = strdup((char *)data->d_buf + name_offset);
 
 ret_err:
elf_end(elf);


[tip:perf/urgent] perf tools: Install tools/lib/traceevent plugins with install-bin

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  30a9c6444810429aa2b7cbfbd453ce339baaadbf
Gitweb: http://git.kernel.org/tip/30a9c6444810429aa2b7cbfbd453ce339baaadbf
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 3 Jan 2017 12:03:59 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 16:11:13 -0300

perf tools: Install tools/lib/traceevent plugins with install-bin

Those are binaries as well, so should be installed by:

  make -C tools/perf install-bin'

too.

Cc: Alexander Shishkin 
Cc: Daniel Bristot de Oliveira 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: http://lkml.kernel.org/n/tip-3841b37u05evxrs1igkyu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index e9ec531..4db68ae 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -704,9 +704,9 @@ install-tests: all install-gtk
$(INSTALL) -d -m 755 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests/attr'; \
$(INSTALL) tests/attr/* 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/tests/attr'
 
-install-bin: install-tools install-tests
+install-bin: install-tools install-tests install-traceevent-plugins
 
-install: install-bin try-install-man install-traceevent-plugins
+install: install-bin try-install-man
 
 install-python_ext:
$(PYTHON_WORD) util/setup.py --quiet install --root='/$(DESTDIR_SQ)'


[tip:perf/urgent] tools lib subcmd: Add OPT_STRING_OPTARG_SET option

2017-01-04 Thread tip-bot for Jiri Olsa
Commit-ID:  b66fb1da5a8cac3f5c3cdbe41937c91efc4e76a4
Gitweb: http://git.kernel.org/tip/b66fb1da5a8cac3f5c3cdbe41937c91efc4e76a4
Author: Jiri Olsa 
AuthorDate: Tue, 3 Jan 2017 09:19:54 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 11:10:38 -0300

tools lib subcmd: Add OPT_STRING_OPTARG_SET option

To allow string options with a default argument and variable set when
the option is used.

Signed-off-by: Jiri Olsa 
Tested-by: Wang Nan 
Cc: David Ahern 
Cc: Josh Poimboeuf 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1483431600-19887-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/subcmd/parse-options.c | 3 +++
 tools/lib/subcmd/parse-options.h | 5 +
 2 files changed, 8 insertions(+)

diff --git a/tools/lib/subcmd/parse-options.c b/tools/lib/subcmd/parse-options.c
index 3284bb1..8aad811 100644
--- a/tools/lib/subcmd/parse-options.c
+++ b/tools/lib/subcmd/parse-options.c
@@ -213,6 +213,9 @@ static int get_value(struct parse_opt_ctx_t *p,
else
err = get_arg(p, opt, flags, (const char **)opt->value);
 
+   if (opt->set)
+   *(bool *)opt->set = true;
+
/* PARSE_OPT_NOEMPTY: Allow NULL but disallow empty string. */
if (opt->flags & PARSE_OPT_NOEMPTY) {
const char *val = *(const char **)opt->value;
diff --git a/tools/lib/subcmd/parse-options.h b/tools/lib/subcmd/parse-options.h
index 8866ac4..11c3be3 100644
--- a/tools/lib/subcmd/parse-options.h
+++ b/tools/lib/subcmd/parse-options.h
@@ -137,6 +137,11 @@ struct option {
{ .type = OPTION_STRING,  .short_name = (s), .long_name = (l), \
  .value = check_vtype(v, const char **), (a), .help = (h), \
  .flags = PARSE_OPT_OPTARG, .defval = (intptr_t)(d) }
+#define OPT_STRING_OPTARG_SET(s, l, v, os, a, h, d) \
+   { .type = OPTION_STRING, .short_name = (s), .long_name = (l), \
+ .value = check_vtype(v, const char **), (a), .help = (h), \
+ .flags = PARSE_OPT_OPTARG, .defval = (intptr_t)(d), \
+ .set = check_vtype(os, bool *)}
 #define OPT_STRING_NOEMPTY(s, l, v, a, h)   { .type = OPTION_STRING,  
.short_name = (s), .long_name = (l), .value = check_vtype(v, const char **), 
(a), .help = (h), .flags = PARSE_OPT_NOEMPTY}
 #define OPT_DATE(s, l, v, h) \
{ .type = OPTION_CALLBACK, .short_name = (s), .long_name = (l), .value 
= (v), .argh = "time", .help = (h), .callback = parse_opt_approxidate_cb }


Re: [PATCH 4.9 00/83] 4.9.1-stable review

2017-01-04 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2017 at 05:41:02PM -0700, Shuah Khan wrote:
> On 01/04/2017 01:05 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.1 release.
> > There are 83 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Jan  6 20:04:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.1-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h


[tip:perf/urgent] perf record: Fix --switch-output documentation and comment

2017-01-04 Thread tip-bot for Jiri Olsa
Commit-ID:  60437ac02f398e0ee0927748d4798dd5534ac90d
Gitweb: http://git.kernel.org/tip/60437ac02f398e0ee0927748d4798dd5534ac90d
Author: Jiri Olsa 
AuthorDate: Tue, 3 Jan 2017 09:19:56 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 11:11:38 -0300

perf record: Fix --switch-output documentation and comment

There's no --signal-trigger option, also adding the code comment into
record man page.

Signed-off-by: Jiri Olsa 
Tested-by: Wang Nan 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1483431600-19887-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-record.txt | 4 
 tools/perf/builtin-record.c  | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 27fc361..5054d91 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -430,6 +430,10 @@ that gets then processed, possibly via a perf script, to 
decide if that
 particular perf.data snapshot should be kept or not.
 
 Implies --timestamp-filename, --no-buildid and --no-buildid-cache.
+The reason for the latter two is to reduce the data file switching
+overhead. You can still switch them on with:
+
+  --switch-output --no-no-buildid  --no-no-buildid-cache
 
 --dry-run::
 Parse options then exit. --dry-run can be used to detect errors in cmdline
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 31cf0ce..4ec10e9 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1636,7 +1636,7 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * overhead. Still generate buildid if they are required
 * explicitly using
 *
-*  perf record --signal-trigger --no-no-buildid \
+*  perf record --switch-output --no-no-buildid \
 *  --no-no-buildid-cache
 *
 * Following code equals to:


Re: [PATCH 4.9 00/83] 4.9.1-stable review

2017-01-04 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2017 at 05:41:02PM -0700, Shuah Khan wrote:
> On 01/04/2017 01:05 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.1 release.
> > There are 83 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Fri Jan  6 20:04:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.1-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h


[tip:perf/urgent] perf record: Fix --switch-output documentation and comment

2017-01-04 Thread tip-bot for Jiri Olsa
Commit-ID:  60437ac02f398e0ee0927748d4798dd5534ac90d
Gitweb: http://git.kernel.org/tip/60437ac02f398e0ee0927748d4798dd5534ac90d
Author: Jiri Olsa 
AuthorDate: Tue, 3 Jan 2017 09:19:56 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 11:11:38 -0300

perf record: Fix --switch-output documentation and comment

There's no --signal-trigger option, also adding the code comment into
record man page.

Signed-off-by: Jiri Olsa 
Tested-by: Wang Nan 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1483431600-19887-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-record.txt | 4 
 tools/perf/builtin-record.c  | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 27fc361..5054d91 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -430,6 +430,10 @@ that gets then processed, possibly via a perf script, to 
decide if that
 particular perf.data snapshot should be kept or not.
 
 Implies --timestamp-filename, --no-buildid and --no-buildid-cache.
+The reason for the latter two is to reduce the data file switching
+overhead. You can still switch them on with:
+
+  --switch-output --no-no-buildid  --no-no-buildid-cache
 
 --dry-run::
 Parse options then exit. --dry-run can be used to detect errors in cmdline
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 31cf0ce..4ec10e9 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1636,7 +1636,7 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
 * overhead. Still generate buildid if they are required
 * explicitly using
 *
-*  perf record --signal-trigger --no-no-buildid \
+*  perf record --switch-output --no-no-buildid \
 *  --no-no-buildid-cache
 *
 * Following code equals to:


[tip:perf/urgent] tools lib subcmd: Add OPT_STRING_OPTARG_SET option

2017-01-04 Thread tip-bot for Jiri Olsa
Commit-ID:  b66fb1da5a8cac3f5c3cdbe41937c91efc4e76a4
Gitweb: http://git.kernel.org/tip/b66fb1da5a8cac3f5c3cdbe41937c91efc4e76a4
Author: Jiri Olsa 
AuthorDate: Tue, 3 Jan 2017 09:19:54 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 11:10:38 -0300

tools lib subcmd: Add OPT_STRING_OPTARG_SET option

To allow string options with a default argument and variable set when
the option is used.

Signed-off-by: Jiri Olsa 
Tested-by: Wang Nan 
Cc: David Ahern 
Cc: Josh Poimboeuf 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1483431600-19887-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/subcmd/parse-options.c | 3 +++
 tools/lib/subcmd/parse-options.h | 5 +
 2 files changed, 8 insertions(+)

diff --git a/tools/lib/subcmd/parse-options.c b/tools/lib/subcmd/parse-options.c
index 3284bb1..8aad811 100644
--- a/tools/lib/subcmd/parse-options.c
+++ b/tools/lib/subcmd/parse-options.c
@@ -213,6 +213,9 @@ static int get_value(struct parse_opt_ctx_t *p,
else
err = get_arg(p, opt, flags, (const char **)opt->value);
 
+   if (opt->set)
+   *(bool *)opt->set = true;
+
/* PARSE_OPT_NOEMPTY: Allow NULL but disallow empty string. */
if (opt->flags & PARSE_OPT_NOEMPTY) {
const char *val = *(const char **)opt->value;
diff --git a/tools/lib/subcmd/parse-options.h b/tools/lib/subcmd/parse-options.h
index 8866ac4..11c3be3 100644
--- a/tools/lib/subcmd/parse-options.h
+++ b/tools/lib/subcmd/parse-options.h
@@ -137,6 +137,11 @@ struct option {
{ .type = OPTION_STRING,  .short_name = (s), .long_name = (l), \
  .value = check_vtype(v, const char **), (a), .help = (h), \
  .flags = PARSE_OPT_OPTARG, .defval = (intptr_t)(d) }
+#define OPT_STRING_OPTARG_SET(s, l, v, os, a, h, d) \
+   { .type = OPTION_STRING, .short_name = (s), .long_name = (l), \
+ .value = check_vtype(v, const char **), (a), .help = (h), \
+ .flags = PARSE_OPT_OPTARG, .defval = (intptr_t)(d), \
+ .set = check_vtype(os, bool *)}
 #define OPT_STRING_NOEMPTY(s, l, v, a, h)   { .type = OPTION_STRING,  
.short_name = (s), .long_name = (l), .value = check_vtype(v, const char **), 
(a), .help = (h), .flags = PARSE_OPT_NOEMPTY}
 #define OPT_DATE(s, l, v, h) \
{ .type = OPTION_CALLBACK, .short_name = (s), .long_name = (l), .value 
= (v), .argh = "time", .help = (h), .callback = parse_opt_approxidate_cb }


[tip:perf/urgent] perf record: Make __record_options static

2017-01-04 Thread tip-bot for Jiri Olsa
Commit-ID:  efd21307119d5a23ac83ae8fd5a39a5c7aeb8493
Gitweb: http://git.kernel.org/tip/efd21307119d5a23ac83ae8fd5a39a5c7aeb8493
Author: Jiri Olsa 
AuthorDate: Tue, 3 Jan 2017 09:19:55 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 11:11:10 -0300

perf record: Make __record_options static

There's no need for this one to be global.

Signed-off-by: Jiri Olsa 
Tested-by: Wang Nan 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1483431600-19887-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 74d6a03..31cf0ce 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1405,7 +1405,7 @@ static bool dry_run;
  * perf_evlist__prepare_workload, etc instead of fork+exec'in 'perf record',
  * using pipes, etc.
  */
-struct option __record_options[] = {
+static struct option __record_options[] = {
OPT_CALLBACK('e', "event", , "event",
 "event selector. use 'perf list' to list available events",
 parse_events_option),


[tip:perf/urgent] perf record: Make __record_options static

2017-01-04 Thread tip-bot for Jiri Olsa
Commit-ID:  efd21307119d5a23ac83ae8fd5a39a5c7aeb8493
Gitweb: http://git.kernel.org/tip/efd21307119d5a23ac83ae8fd5a39a5c7aeb8493
Author: Jiri Olsa 
AuthorDate: Tue, 3 Jan 2017 09:19:55 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 3 Jan 2017 11:11:10 -0300

perf record: Make __record_options static

There's no need for this one to be global.

Signed-off-by: Jiri Olsa 
Tested-by: Wang Nan 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1483431600-19887-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 74d6a03..31cf0ce 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1405,7 +1405,7 @@ static bool dry_run;
  * perf_evlist__prepare_workload, etc instead of fork+exec'in 'perf record',
  * using pipes, etc.
  */
-struct option __record_options[] = {
+static struct option __record_options[] = {
OPT_CALLBACK('e', "event", , "event",
 "event selector. use 'perf list' to list available events",
 parse_events_option),


[scsi 4/4] scsi: ufs: refactor device descriptor reading

2017-01-04 Thread Tomas Winkler
Pull device descriptor reading out of ufs quirk so it
can be used also for other purposes.

Revamp the fixup setup:
1. Rename ufs_device_info to ufs_dev_desc as very similar
name ufs_dev_info is already in use.
2. Make the handlers static as they are not used out of the
ufshdc.c file.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufs.h| 12 
 drivers/scsi/ufs/ufs_quirks.h | 28 ++--
 drivers/scsi/ufs/ufshcd.c | 40 +++-
 3 files changed, 37 insertions(+), 43 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 8e6709a3fb6b..318e4a1f76c9 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -523,4 +523,16 @@ struct ufs_dev_info {
bool is_lu_power_on_wp;
 };
 
+#define MAX_MODEL_LEN 16
+/**
+ * ufs_dev_desc - ufs device details from the device descriptor
+ *
+ * @wmanufacturerid: card details
+ * @model: card model
+ */
+struct ufs_dev_desc {
+   u16 wmanufacturerid;
+   char model[MAX_MODEL_LEN + 1];
+};
+
 #endif /* End of Header */
diff --git a/drivers/scsi/ufs/ufs_quirks.h b/drivers/scsi/ufs/ufs_quirks.h
index 08b799d4efcc..71f73d1d1ad1 100644
--- a/drivers/scsi/ufs/ufs_quirks.h
+++ b/drivers/scsi/ufs/ufs_quirks.h
@@ -21,41 +21,28 @@
 #define UFS_ANY_VENDOR 0x
 #define UFS_ANY_MODEL  "ANY_MODEL"
 
-#define MAX_MODEL_LEN 16
-
 #define UFS_VENDOR_TOSHIBA 0x198
 #define UFS_VENDOR_SAMSUNG 0x1CE
 #define UFS_VENDOR_SKHYNIX 0x1AD
 
 /**
- * ufs_device_info - ufs device details
- * @wmanufacturerid: card details
- * @model: card model
- */
-struct ufs_device_info {
-   u16 wmanufacturerid;
-   char model[MAX_MODEL_LEN + 1];
-};
-
-/**
  * ufs_dev_fix - ufs device quirk info
  * @card: ufs card details
  * @quirk: device quirk
  */
 struct ufs_dev_fix {
-   struct ufs_device_info card;
+   struct ufs_dev_desc card;
unsigned int quirk;
 };
 
 #define END_FIX { { 0 }, 0 }
 
 /* add specific device quirk */
-#define UFS_FIX(_vendor, _model, _quirk) \
-   { \
-   .card.wmanufacturerid = (_vendor),\
-   .card.model = (_model),   \
-   .quirk = (_quirk),\
-   }
+#define UFS_FIX(_vendor, _model, _quirk) { \
+   .card.wmanufacturerid = (_vendor),\
+   .card.model = (_model),\
+   .quirk = (_quirk), \
+}
 
 /*
  * If UFS device is having issue in processing LCC (Line Control
@@ -144,7 +131,4 @@ struct ufs_dev_fix {
  */
 #define UFS_DEVICE_QUIRK_HOST_PA_SAVECONFIGTIME(1 << 8)
 
-struct ufs_hba;
-void ufs_advertise_fixup_device(struct ufs_hba *hba);
-
 #endif /* UFS_QUIRKS_H_ */
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index fdea08f79b7d..53b3ec40a7b0 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5008,8 +5008,8 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
return ret;
 }
 
-static int ufs_get_device_info(struct ufs_hba *hba,
-   struct ufs_device_info *card_data)
+static int ufs_get_device_desc(struct ufs_hba *hba,
+  struct ufs_dev_desc *dev_desc)
 {
int err;
u8 model_index;
@@ -5028,7 +5028,7 @@ static int ufs_get_device_info(struct ufs_hba *hba,
 * getting vendor (manufacturerID) and Bank Index in big endian
 * format
 */
-   card_data->wmanufacturerid = desc_buf[DEVICE_DESC_PARAM_MANF_ID] << 8 |
+   dev_desc->wmanufacturerid = desc_buf[DEVICE_DESC_PARAM_MANF_ID] << 8 |
 desc_buf[DEVICE_DESC_PARAM_MANF_ID + 1];
 
model_index = desc_buf[DEVICE_DESC_PARAM_PRDCT_NAME];
@@ -5042,36 +5042,26 @@ static int ufs_get_device_info(struct ufs_hba *hba,
}
 
str_desc_buf[QUERY_DESC_STRING_MAX_SIZE] = '\0';
-   strlcpy(card_data->model, (str_desc_buf + QUERY_DESC_HDR_SIZE),
+   strlcpy(dev_desc->model, (str_desc_buf + QUERY_DESC_HDR_SIZE),
min_t(u8, str_desc_buf[QUERY_DESC_LENGTH_OFFSET],
  MAX_MODEL_LEN));
 
/* Null terminate the model string */
-   card_data->model[MAX_MODEL_LEN] = '\0';
+   dev_desc->model[MAX_MODEL_LEN] = '\0';
 
 out:
return err;
 }
 
-void ufs_advertise_fixup_device(struct ufs_hba *hba)
+static void ufs_fixup_device_setup(struct ufs_hba *hba,
+  struct ufs_dev_desc *dev_desc)
 {
-   int err;
struct ufs_dev_fix *f;
-   struct ufs_device_info card_data;
-
-   card_data.wmanufacturerid = 0;
-
-   err = ufs_get_device_info(hba, _data);
-   if (err) {
-   dev_err(hba->dev, "%s: Failed getting device info. err = %d\n",
-   __func__, err);
-   return;
-   }
 
for (f = ufs_fixups; f->quirk; f++) {
-   

Re: [GIT PULL] fpga: Updates for 4.10-rc2

2017-01-04 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2017 at 03:53:18PM -0600, Alan Tull wrote:
> On Wed, Jan 4, 2017 at 3:28 PM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Wed, Jan 04, 2017 at 02:00:23PM -0600, Alan Tull wrote:
> >> Hi Greg,
> >>
> >> Please pull these changes for FPGA.
> >>
> >> Thanks!
> >> Alan
> >>
> >> The following changes since commit 
> >> e3d31bda06e43968cd215ae590eb7cda827f01e9:
> >>
> >>   Add linux-next specific files for 20161224 (2017-01-04 10:26:49 -0600)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/atull/linux-fpga.git 
> >> tags/fpga-for-greg-20170104
> >>
> >> for you to fetch changes up to 2dd088da8cce745c008fc7f8b64e1aef33eb37c2:
> >>
> >>   ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300 (2017-01-04 
> >> 10:27:26 -0600)
> >>
> >> 
> >> fpga: Updates for 4.10-rc2
> >>
> >>  * Add scatterlist based fpga programming
> >>  * TS-7300 FPGA manager
> >>  * zynq: Check for errors after completing DMA
> >>  * fix sparse warnings in fpga-mgr and fpga-bridge
> >
> > These are all bugfixes or regression fixes?  Doesn't seem like adding
> > new functionality and a new driver fits that category to me, why add
> > them now?
> >
> > Sorry, I can't take this, if you resend them as patches, I can be more
> > specific...
> >
> > thanks,
> >
> > greg k-h
> 
> Hi Greg,
> 
> Yes, sorry, I'm still learning here.  One patch is a fix (sparse
> errors), the rest are new functionality.

Ok, let's stick to patches then, no git pull requests, it makes things
easier that way for things to be reviewed properly.

> Would it be appropriate to separate these and send you two pull
> requests -  the sparse error fix for 4.10 and the rest (new
> functionality) for 4.11?

why would a sparse warning fix be ok for a -rc kernel?  Is it a real
bug?

Send patches, we can go from there please.

thanks,

greg k-h


[scsi 4/4] scsi: ufs: refactor device descriptor reading

2017-01-04 Thread Tomas Winkler
Pull device descriptor reading out of ufs quirk so it
can be used also for other purposes.

Revamp the fixup setup:
1. Rename ufs_device_info to ufs_dev_desc as very similar
name ufs_dev_info is already in use.
2. Make the handlers static as they are not used out of the
ufshdc.c file.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufs.h| 12 
 drivers/scsi/ufs/ufs_quirks.h | 28 ++--
 drivers/scsi/ufs/ufshcd.c | 40 +++-
 3 files changed, 37 insertions(+), 43 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 8e6709a3fb6b..318e4a1f76c9 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -523,4 +523,16 @@ struct ufs_dev_info {
bool is_lu_power_on_wp;
 };
 
+#define MAX_MODEL_LEN 16
+/**
+ * ufs_dev_desc - ufs device details from the device descriptor
+ *
+ * @wmanufacturerid: card details
+ * @model: card model
+ */
+struct ufs_dev_desc {
+   u16 wmanufacturerid;
+   char model[MAX_MODEL_LEN + 1];
+};
+
 #endif /* End of Header */
diff --git a/drivers/scsi/ufs/ufs_quirks.h b/drivers/scsi/ufs/ufs_quirks.h
index 08b799d4efcc..71f73d1d1ad1 100644
--- a/drivers/scsi/ufs/ufs_quirks.h
+++ b/drivers/scsi/ufs/ufs_quirks.h
@@ -21,41 +21,28 @@
 #define UFS_ANY_VENDOR 0x
 #define UFS_ANY_MODEL  "ANY_MODEL"
 
-#define MAX_MODEL_LEN 16
-
 #define UFS_VENDOR_TOSHIBA 0x198
 #define UFS_VENDOR_SAMSUNG 0x1CE
 #define UFS_VENDOR_SKHYNIX 0x1AD
 
 /**
- * ufs_device_info - ufs device details
- * @wmanufacturerid: card details
- * @model: card model
- */
-struct ufs_device_info {
-   u16 wmanufacturerid;
-   char model[MAX_MODEL_LEN + 1];
-};
-
-/**
  * ufs_dev_fix - ufs device quirk info
  * @card: ufs card details
  * @quirk: device quirk
  */
 struct ufs_dev_fix {
-   struct ufs_device_info card;
+   struct ufs_dev_desc card;
unsigned int quirk;
 };
 
 #define END_FIX { { 0 }, 0 }
 
 /* add specific device quirk */
-#define UFS_FIX(_vendor, _model, _quirk) \
-   { \
-   .card.wmanufacturerid = (_vendor),\
-   .card.model = (_model),   \
-   .quirk = (_quirk),\
-   }
+#define UFS_FIX(_vendor, _model, _quirk) { \
+   .card.wmanufacturerid = (_vendor),\
+   .card.model = (_model),\
+   .quirk = (_quirk), \
+}
 
 /*
  * If UFS device is having issue in processing LCC (Line Control
@@ -144,7 +131,4 @@ struct ufs_dev_fix {
  */
 #define UFS_DEVICE_QUIRK_HOST_PA_SAVECONFIGTIME(1 << 8)
 
-struct ufs_hba;
-void ufs_advertise_fixup_device(struct ufs_hba *hba);
-
 #endif /* UFS_QUIRKS_H_ */
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index fdea08f79b7d..53b3ec40a7b0 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5008,8 +5008,8 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
return ret;
 }
 
-static int ufs_get_device_info(struct ufs_hba *hba,
-   struct ufs_device_info *card_data)
+static int ufs_get_device_desc(struct ufs_hba *hba,
+  struct ufs_dev_desc *dev_desc)
 {
int err;
u8 model_index;
@@ -5028,7 +5028,7 @@ static int ufs_get_device_info(struct ufs_hba *hba,
 * getting vendor (manufacturerID) and Bank Index in big endian
 * format
 */
-   card_data->wmanufacturerid = desc_buf[DEVICE_DESC_PARAM_MANF_ID] << 8 |
+   dev_desc->wmanufacturerid = desc_buf[DEVICE_DESC_PARAM_MANF_ID] << 8 |
 desc_buf[DEVICE_DESC_PARAM_MANF_ID + 1];
 
model_index = desc_buf[DEVICE_DESC_PARAM_PRDCT_NAME];
@@ -5042,36 +5042,26 @@ static int ufs_get_device_info(struct ufs_hba *hba,
}
 
str_desc_buf[QUERY_DESC_STRING_MAX_SIZE] = '\0';
-   strlcpy(card_data->model, (str_desc_buf + QUERY_DESC_HDR_SIZE),
+   strlcpy(dev_desc->model, (str_desc_buf + QUERY_DESC_HDR_SIZE),
min_t(u8, str_desc_buf[QUERY_DESC_LENGTH_OFFSET],
  MAX_MODEL_LEN));
 
/* Null terminate the model string */
-   card_data->model[MAX_MODEL_LEN] = '\0';
+   dev_desc->model[MAX_MODEL_LEN] = '\0';
 
 out:
return err;
 }
 
-void ufs_advertise_fixup_device(struct ufs_hba *hba)
+static void ufs_fixup_device_setup(struct ufs_hba *hba,
+  struct ufs_dev_desc *dev_desc)
 {
-   int err;
struct ufs_dev_fix *f;
-   struct ufs_device_info card_data;
-
-   card_data.wmanufacturerid = 0;
-
-   err = ufs_get_device_info(hba, _data);
-   if (err) {
-   dev_err(hba->dev, "%s: Failed getting device info. err = %d\n",
-   __func__, err);
-   return;
-   }
 
for (f = ufs_fixups; f->quirk; f++) {
-   if 

Re: [GIT PULL] fpga: Updates for 4.10-rc2

2017-01-04 Thread Greg Kroah-Hartman
On Wed, Jan 04, 2017 at 03:53:18PM -0600, Alan Tull wrote:
> On Wed, Jan 4, 2017 at 3:28 PM, Greg Kroah-Hartman
>  wrote:
> > On Wed, Jan 04, 2017 at 02:00:23PM -0600, Alan Tull wrote:
> >> Hi Greg,
> >>
> >> Please pull these changes for FPGA.
> >>
> >> Thanks!
> >> Alan
> >>
> >> The following changes since commit 
> >> e3d31bda06e43968cd215ae590eb7cda827f01e9:
> >>
> >>   Add linux-next specific files for 20161224 (2017-01-04 10:26:49 -0600)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/atull/linux-fpga.git 
> >> tags/fpga-for-greg-20170104
> >>
> >> for you to fetch changes up to 2dd088da8cce745c008fc7f8b64e1aef33eb37c2:
> >>
> >>   ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300 (2017-01-04 
> >> 10:27:26 -0600)
> >>
> >> 
> >> fpga: Updates for 4.10-rc2
> >>
> >>  * Add scatterlist based fpga programming
> >>  * TS-7300 FPGA manager
> >>  * zynq: Check for errors after completing DMA
> >>  * fix sparse warnings in fpga-mgr and fpga-bridge
> >
> > These are all bugfixes or regression fixes?  Doesn't seem like adding
> > new functionality and a new driver fits that category to me, why add
> > them now?
> >
> > Sorry, I can't take this, if you resend them as patches, I can be more
> > specific...
> >
> > thanks,
> >
> > greg k-h
> 
> Hi Greg,
> 
> Yes, sorry, I'm still learning here.  One patch is a fix (sparse
> errors), the rest are new functionality.

Ok, let's stick to patches then, no git pull requests, it makes things
easier that way for things to be reviewed properly.

> Would it be appropriate to separate these and send you two pull
> requests -  the sparse error fix for 4.10 and the rest (new
> functionality) for 4.11?

why would a sparse warning fix be ok for a -rc kernel?  Is it a real
bug?

Send patches, we can go from there please.

thanks,

greg k-h


[tip:perf/urgent] samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  b6f4c66704b875aba9b8c912532323e3cc89824c
Gitweb: http://git.kernel.org/tip/b6f4c66704b875aba9b8c912532323e3cc89824c
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 28 Dec 2016 10:47:13 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 28 Dec 2016 10:47:13 -0300

samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include

Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Joe Stringer 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-3awp0nv8tpnblatojmwjw...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/trace_output_user.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/samples/bpf/trace_output_user.c b/samples/bpf/trace_output_user.c
index f4fa6af..ccca1e3 100644
--- a/samples/bpf/trace_output_user.c
+++ b/samples/bpf/trace_output_user.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


[scsi 1/4] scsi: ufs: ufshcd_query_descriptor_retry should be static

2017-01-04 Thread Tomas Winkler
Fix the following compilation warning:

drivers/scsi/ufs/ufshcd.c:2076:5: warning: no previous prototype for
‘ufshcd_query_descriptor_retry’ [-Wmissing-prototypes]

Also do not export the function, it should not be used out of ufs
context.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 20e5e5fb048c..be3c2900b6bb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2073,9 +2073,11 @@ static int __ufshcd_query_descriptor(struct ufs_hba *hba,
  * The buf_len parameter will contain, on return, the length parameter
  * received on the response.
  */
-int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
-   enum query_opcode opcode, enum desc_idn idn, u8 index,
-   u8 selector, u8 *desc_buf, int *buf_len)
+static int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
+enum query_opcode opcode,
+enum desc_idn idn, u8 index,
+u8 selector,
+u8 *desc_buf, int *buf_len)
 {
int err;
int retries;
@@ -2089,7 +2091,6 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
 
return err;
 }
-EXPORT_SYMBOL(ufshcd_query_descriptor_retry);
 
 /**
  * ufshcd_read_desc_param - read the specified descriptor parameter
-- 
2.7.4



Re: [PATCH 3/3] mfd: cros_ec: Add ACPI GPE handler for LID0 devices

2017-01-04 Thread Lee Jones
On Wed, 04 Jan 2017, Thierry Escande wrote:

> Hi Lee,
> 
> On 04/01/2017 10:06, Lee Jones wrote:
> > On Fri, 16 Dec 2016, Thierry Escande wrote:
> > 
> > > From: Archana Patni 
> > > 
> > > This patch installs an ACPI GPE handler for LID0 ACPI device to indicate
> > > ACPI core that this GPE should stay enabled for lid to work in suspend
> > > to idle path.
> > > 
> > > Signed-off-by: Archana Patni 
> > > Signed-off-by: Thierry Escande 
> > > ---
> > >  drivers/mfd/cros_ec.c | 97 
> > > +--
> > >  1 file changed, 95 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> > > index b8a5080..628718e 100644
> > > --- a/drivers/mfd/cros_ec.c
> > > +++ b/drivers/mfd/cros_ec.c
> > > @@ -17,6 +17,9 @@
> > >   * battery charging and regulator control, firmware update.
> > >   */
> > > 
> > > +#ifdef CONFIG_ACPI
> > > +#include 
> > > +#endif
> > 
> > Please don't place #ifery in C files.
> > 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -29,6 +32,73 @@
> > >  #define CROS_EC_DEV_EC_INDEX 0
> > >  #define CROS_EC_DEV_PD_INDEX 1
> > > 
> > > +#ifdef CONFIG_ACPI
> > 
> > Remove this.
> > 
> > > +#define ACPI_LID_DEVICE  "LID0"
> > > +
> > > +static int ec_wake_gpe = -EINVAL;
> > > +
> > > +/*
> > > + * This handler indicates to ACPI core that this GPE should stay enabled 
> > > for
> > > + * lid to work in suspend to idle path.
> > > + */
> > > +static u32 cros_ec_gpe_handler(acpi_handle gpe_device, u32 gpe_number,
> > > +void *data)
> > > +{
> > > + return ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE;
> > > +}
> > > +
> > > +/*
> > > + * Get ACPI GPE for LID0 device.
> > > + */
> > > +static int cros_ec_get_ec_wake_gpe(struct device *dev)
> > > +{
> If it's ok for you, I'll keep one #ifdef CONFIG_ACPI around the body of this
> function. Otherwise it won't compile if CONFIG_ACPI is not set.

Can you try placing:

if (IS_ENABLED(CONFIG_ACPI))

... before the call to cros_ec_get_ec_wake_gpe() and see if the
compiler will do-the-right-thing please?

> > > + struct acpi_device *cros_acpi_dev;
> > > + struct acpi_device *adev;
> > > + acpi_handle handle;
> > > + acpi_status status;
> > > + int ret;
> > > +
> > > + cros_acpi_dev = ACPI_COMPANION(dev);
> > > +
> > > + if (!cros_acpi_dev || !cros_acpi_dev->parent ||
> > > +!cros_acpi_dev->parent->handle)
> > > + return -EINVAL;
> > > +
> > > + status = acpi_get_handle(cros_acpi_dev->parent->handle, ACPI_LID_DEVICE,
> > > +  );
> > > + if (ACPI_FAILURE(status))
> > > + return -EINVAL;
> > > +
> > > + ret = acpi_bus_get_device(handle, );
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return adev->wakeup.gpe_number;
> > > +}
> > > +
> > > +static int cros_ec_install_handler(struct device *dev)
> > > +{
> > > + acpi_status status;
> > > +
> > > + ec_wake_gpe = cros_ec_get_ec_wake_gpe(dev);
> > > +
> > > + if (ec_wake_gpe < 0)
> > > + return ec_wake_gpe;
> > > +
> > > + status = acpi_install_gpe_handler(NULL, ec_wake_gpe,
> > > +   ACPI_GPE_EDGE_TRIGGERED,
> > > +   _ec_gpe_handler, NULL);
> > > + if (ACPI_FAILURE(status))
> > > + return -ENODEV;
> > > +
> > > + dev_info(dev, "Initialized, GPE = 0x%x\n", ec_wake_gpe);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +#endif
> > > +
> > >  static struct cros_ec_platform ec_p = {
> > >   .ec_name = CROS_EC_DEV_NAME,
> > >   .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_EC_INDEX),
> > > @@ -166,6 +236,10 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> > > 
> > >   dev_info(dev, "Chrome EC device registered\n");
> > > 
> > > +#ifdef CONFIG_ACPI
> > > + cros_ec_install_handler(dev);
> > > +#endif
> > 
> > Here, just do:
> > 
> > if (IS_ENABLED(CONFIG_ACPI))
> > cros_ec_install_handler(dev);
> > 
> > And let the compiler take care of the rest.
> > 
> > >   return 0;
> > > 
> > >  fail_mfd:
> > > @@ -179,6 +253,17 @@ int cros_ec_remove(struct cros_ec_device *ec_dev)
> > >  {
> > >   mfd_remove_devices(ec_dev->dev);
> > > 
> > > +#ifdef CONFIG_ACPI
> > > + if (ec_wake_gpe >= 0) {
> > 
> > if (IS_ENABLED(CONFIG_ACPI) && ec_wake_gpe >= 0) {
> > 
> > > + acpi_status status;
> > > +
> > > + status = acpi_remove_gpe_handler(NULL, ec_wake_gpe,
> > > +  _ec_gpe_handler);
> > > + if (ACPI_FAILURE(status))
> > > + pr_err("failed to remove gpe handler\n");
> > > + }
> > > +#endif
> > > +
> > >   return 0;
> > >  }
> > >  EXPORT_SYMBOL(cros_ec_remove);
> > > @@ -190,8 +275,16 @@ int cros_ec_suspend(struct cros_ec_device *ec_dev)
> > >   int ret;
> > >   u8 sleep_event;
> > > 
> > > - sleep_event = pm_suspend_via_firmware() ? HOST_SLEEP_EVENT_S3_RESUME :
> > > -

[tip:perf/urgent] samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  b6f4c66704b875aba9b8c912532323e3cc89824c
Gitweb: http://git.kernel.org/tip/b6f4c66704b875aba9b8c912532323e3cc89824c
Author: Arnaldo Carvalho de Melo 
AuthorDate: Wed, 28 Dec 2016 10:47:13 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 28 Dec 2016 10:47:13 -0300

samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include

Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Joe Stringer 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-3awp0nv8tpnblatojmwjw...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/trace_output_user.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/samples/bpf/trace_output_user.c b/samples/bpf/trace_output_user.c
index f4fa6af..ccca1e3 100644
--- a/samples/bpf/trace_output_user.c
+++ b/samples/bpf/trace_output_user.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


[scsi 1/4] scsi: ufs: ufshcd_query_descriptor_retry should be static

2017-01-04 Thread Tomas Winkler
Fix the following compilation warning:

drivers/scsi/ufs/ufshcd.c:2076:5: warning: no previous prototype for
‘ufshcd_query_descriptor_retry’ [-Wmissing-prototypes]

Also do not export the function, it should not be used out of ufs
context.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 20e5e5fb048c..be3c2900b6bb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2073,9 +2073,11 @@ static int __ufshcd_query_descriptor(struct ufs_hba *hba,
  * The buf_len parameter will contain, on return, the length parameter
  * received on the response.
  */
-int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
-   enum query_opcode opcode, enum desc_idn idn, u8 index,
-   u8 selector, u8 *desc_buf, int *buf_len)
+static int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
+enum query_opcode opcode,
+enum desc_idn idn, u8 index,
+u8 selector,
+u8 *desc_buf, int *buf_len)
 {
int err;
int retries;
@@ -2089,7 +2091,6 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
 
return err;
 }
-EXPORT_SYMBOL(ufshcd_query_descriptor_retry);
 
 /**
  * ufshcd_read_desc_param - read the specified descriptor parameter
-- 
2.7.4



Re: [PATCH 3/3] mfd: cros_ec: Add ACPI GPE handler for LID0 devices

2017-01-04 Thread Lee Jones
On Wed, 04 Jan 2017, Thierry Escande wrote:

> Hi Lee,
> 
> On 04/01/2017 10:06, Lee Jones wrote:
> > On Fri, 16 Dec 2016, Thierry Escande wrote:
> > 
> > > From: Archana Patni 
> > > 
> > > This patch installs an ACPI GPE handler for LID0 ACPI device to indicate
> > > ACPI core that this GPE should stay enabled for lid to work in suspend
> > > to idle path.
> > > 
> > > Signed-off-by: Archana Patni 
> > > Signed-off-by: Thierry Escande 
> > > ---
> > >  drivers/mfd/cros_ec.c | 97 
> > > +--
> > >  1 file changed, 95 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> > > index b8a5080..628718e 100644
> > > --- a/drivers/mfd/cros_ec.c
> > > +++ b/drivers/mfd/cros_ec.c
> > > @@ -17,6 +17,9 @@
> > >   * battery charging and regulator control, firmware update.
> > >   */
> > > 
> > > +#ifdef CONFIG_ACPI
> > > +#include 
> > > +#endif
> > 
> > Please don't place #ifery in C files.
> > 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -29,6 +32,73 @@
> > >  #define CROS_EC_DEV_EC_INDEX 0
> > >  #define CROS_EC_DEV_PD_INDEX 1
> > > 
> > > +#ifdef CONFIG_ACPI
> > 
> > Remove this.
> > 
> > > +#define ACPI_LID_DEVICE  "LID0"
> > > +
> > > +static int ec_wake_gpe = -EINVAL;
> > > +
> > > +/*
> > > + * This handler indicates to ACPI core that this GPE should stay enabled 
> > > for
> > > + * lid to work in suspend to idle path.
> > > + */
> > > +static u32 cros_ec_gpe_handler(acpi_handle gpe_device, u32 gpe_number,
> > > +void *data)
> > > +{
> > > + return ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE;
> > > +}
> > > +
> > > +/*
> > > + * Get ACPI GPE for LID0 device.
> > > + */
> > > +static int cros_ec_get_ec_wake_gpe(struct device *dev)
> > > +{
> If it's ok for you, I'll keep one #ifdef CONFIG_ACPI around the body of this
> function. Otherwise it won't compile if CONFIG_ACPI is not set.

Can you try placing:

if (IS_ENABLED(CONFIG_ACPI))

... before the call to cros_ec_get_ec_wake_gpe() and see if the
compiler will do-the-right-thing please?

> > > + struct acpi_device *cros_acpi_dev;
> > > + struct acpi_device *adev;
> > > + acpi_handle handle;
> > > + acpi_status status;
> > > + int ret;
> > > +
> > > + cros_acpi_dev = ACPI_COMPANION(dev);
> > > +
> > > + if (!cros_acpi_dev || !cros_acpi_dev->parent ||
> > > +!cros_acpi_dev->parent->handle)
> > > + return -EINVAL;
> > > +
> > > + status = acpi_get_handle(cros_acpi_dev->parent->handle, ACPI_LID_DEVICE,
> > > +  );
> > > + if (ACPI_FAILURE(status))
> > > + return -EINVAL;
> > > +
> > > + ret = acpi_bus_get_device(handle, );
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return adev->wakeup.gpe_number;
> > > +}
> > > +
> > > +static int cros_ec_install_handler(struct device *dev)
> > > +{
> > > + acpi_status status;
> > > +
> > > + ec_wake_gpe = cros_ec_get_ec_wake_gpe(dev);
> > > +
> > > + if (ec_wake_gpe < 0)
> > > + return ec_wake_gpe;
> > > +
> > > + status = acpi_install_gpe_handler(NULL, ec_wake_gpe,
> > > +   ACPI_GPE_EDGE_TRIGGERED,
> > > +   _ec_gpe_handler, NULL);
> > > + if (ACPI_FAILURE(status))
> > > + return -ENODEV;
> > > +
> > > + dev_info(dev, "Initialized, GPE = 0x%x\n", ec_wake_gpe);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +#endif
> > > +
> > >  static struct cros_ec_platform ec_p = {
> > >   .ec_name = CROS_EC_DEV_NAME,
> > >   .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_EC_INDEX),
> > > @@ -166,6 +236,10 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> > > 
> > >   dev_info(dev, "Chrome EC device registered\n");
> > > 
> > > +#ifdef CONFIG_ACPI
> > > + cros_ec_install_handler(dev);
> > > +#endif
> > 
> > Here, just do:
> > 
> > if (IS_ENABLED(CONFIG_ACPI))
> > cros_ec_install_handler(dev);
> > 
> > And let the compiler take care of the rest.
> > 
> > >   return 0;
> > > 
> > >  fail_mfd:
> > > @@ -179,6 +253,17 @@ int cros_ec_remove(struct cros_ec_device *ec_dev)
> > >  {
> > >   mfd_remove_devices(ec_dev->dev);
> > > 
> > > +#ifdef CONFIG_ACPI
> > > + if (ec_wake_gpe >= 0) {
> > 
> > if (IS_ENABLED(CONFIG_ACPI) && ec_wake_gpe >= 0) {
> > 
> > > + acpi_status status;
> > > +
> > > + status = acpi_remove_gpe_handler(NULL, ec_wake_gpe,
> > > +  _ec_gpe_handler);
> > > + if (ACPI_FAILURE(status))
> > > + pr_err("failed to remove gpe handler\n");
> > > + }
> > > +#endif
> > > +
> > >   return 0;
> > >  }
> > >  EXPORT_SYMBOL(cros_ec_remove);
> > > @@ -190,8 +275,16 @@ int cros_ec_suspend(struct cros_ec_device *ec_dev)
> > >   int ret;
> > >   u8 sleep_event;
> > > 
> > > - sleep_event = pm_suspend_via_firmware() ? HOST_SLEEP_EVENT_S3_RESUME :
> > > -   HOST_SLEEP_EVENT_S0IX_RESUME;
> > > + if 

[scsi 3/4] scsi: ufs: ufshcd_get_max_icc_level fix endianity handling

2017-01-04 Thread Tomas Winkler
Reading big endian value from a buffer requires explicit cast.
Fix sparse warning:
drivers/scsi/ufs/ufshcd.c:4825:24: warning: cast to restricted __be16

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 63d7ae2c3be9..fdea08f79b7d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4822,7 +4822,7 @@ static u32 ufshcd_get_max_icc_level(int sup_curr_uA, u32 
start_scan, char *buff)
u16 unit;
 
for (i = start_scan; i >= 0; i--) {
-   data = be16_to_cpu(*((u16 *)(buff + 2*i)));
+   data = be16_to_cpup((__be16 *)[2 * i]);
unit = (data & ATTR_ICC_LVL_UNIT_MASK) >>
ATTR_ICC_LVL_UNIT_OFFSET;
curr_uA = data & ATTR_ICC_LVL_VALUE_MASK;
-- 
2.7.4



[scsi 2/4] scsi: ufs: unexport descritpor reading functions

2017-01-04 Thread Tomas Winkler
Unexport ufshcd_read_device_desc and ufshcd_read_string_desc
there is no really possibility to calling them directly
outside of UFS context.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 9 -
 drivers/scsi/ufs/ufshcd.h | 7 ---
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index be3c2900b6bb..63d7ae2c3be9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2208,11 +2208,10 @@ static inline int ufshcd_read_power_desc(struct ufs_hba 
*hba,
return err;
 }
 
-int ufshcd_read_device_desc(struct ufs_hba *hba, u8 *buf, u32 size)
+static int ufshcd_read_device_desc(struct ufs_hba *hba, u8 *buf, u32 size)
 {
return ufshcd_read_desc(hba, QUERY_DESC_IDN_DEVICE, 0, buf, size);
 }
-EXPORT_SYMBOL(ufshcd_read_device_desc);
 
 /**
  * ufshcd_read_string_desc - read string descriptor
@@ -2224,8 +2223,9 @@ EXPORT_SYMBOL(ufshcd_read_device_desc);
  *
  * Return 0 in case of success, non-zero otherwise
  */
-int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index, u8 *buf,
-   u32 size, bool ascii)
+#define ASCII_STD true
+static int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index,
+  u8 *buf, u32 size, bool ascii)
 {
int err = 0;
 
@@ -2281,7 +2281,6 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, int 
desc_index, u8 *buf,
 out:
return err;
 }
-EXPORT_SYMBOL(ufshcd_read_string_desc);
 
 /**
  * ufshcd_read_unit_desc_param - read the specified unit descriptor parameter
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 08cd26ed2382..00fb82589895 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -713,8 +713,6 @@ static inline int ufshcd_dme_peer_get(struct ufs_hba *hba,
return ufshcd_dme_get_attr(hba, attr_sel, mib_val, DME_PEER);
 }
 
-int ufshcd_read_device_desc(struct ufs_hba *hba, u8 *buf, u32 size);
-
 static inline bool ufshcd_is_hs_mode(struct ufs_pa_layer_attr *pwr_info)
 {
return (pwr_info->pwr_rx == FAST_MODE ||
@@ -723,11 +721,6 @@ static inline bool ufshcd_is_hs_mode(struct 
ufs_pa_layer_attr *pwr_info)
pwr_info->pwr_tx == FASTAUTO_MODE);
 }
 
-#define ASCII_STD true
-
-int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index, u8 *buf,
-   u32 size, bool ascii);
-
 /* Expose Query-Request API */
 int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
enum flag_idn idn, bool *flag_res);
-- 
2.7.4



[tip:perf/urgent] samples/bpf sock_example: Avoid getting ethhdr from two includes

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  ee12996c9d392ec61241ab6c74d257bc2122e0bc
Gitweb: http://git.kernel.org/tip/ee12996c9d392ec61241ab6c74d257bc2122e0bc
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 27 Dec 2016 21:49:17 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 27 Dec 2016 21:49:17 -0300

samples/bpf sock_example: Avoid getting ethhdr from two includes

To avoid the following build failure on Alpine Linux 3.4, that has
clang-3.8 with the bpf target:

HOSTCC  samples/bpf/sock_example.o
  In file included from /usr/include/net/ethernet.h:10:0,
   from /git/linux/samples/bpf/sock_example.h:7,
   from /git/linux/samples/bpf/sock_example.c:30:
  /usr/include/netinet/if_ether.h:96:8: error: redefinition of 'struct
  ethhdr'
   struct ethhdr {
  ^
  In file included from /git/linux/samples/bpf/sock_example.c:26:0:
  ./usr/include/linux/if_ether.h:144:8: note: originally defined here
   struct ethhdr {
  ^
  scripts/Makefile.host:124: recipe for target
  'samples/bpf/sock_example.o' failed
  make[2]: *** [samples/bpf/sock_example.o] Error 1
  /git/linux/Makefile:1658: recipe for target 'samples/bpf/' failed

So include net/if_ether.h for the needs of sock_example.h, using the
same include that sock_example.c uses.

Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Joe Stringer 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-m9avekl1b651qe1r1zd5t...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/sock_example.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/bpf/sock_example.h b/samples/bpf/sock_example.h
index 09f7fe7..d801406 100644
--- a/samples/bpf/sock_example.h
+++ b/samples/bpf/sock_example.h
@@ -4,7 +4,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 


[scsi 3/4] scsi: ufs: ufshcd_get_max_icc_level fix endianity handling

2017-01-04 Thread Tomas Winkler
Reading big endian value from a buffer requires explicit cast.
Fix sparse warning:
drivers/scsi/ufs/ufshcd.c:4825:24: warning: cast to restricted __be16

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 63d7ae2c3be9..fdea08f79b7d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4822,7 +4822,7 @@ static u32 ufshcd_get_max_icc_level(int sup_curr_uA, u32 
start_scan, char *buff)
u16 unit;
 
for (i = start_scan; i >= 0; i--) {
-   data = be16_to_cpu(*((u16 *)(buff + 2*i)));
+   data = be16_to_cpup((__be16 *)[2 * i]);
unit = (data & ATTR_ICC_LVL_UNIT_MASK) >>
ATTR_ICC_LVL_UNIT_OFFSET;
curr_uA = data & ATTR_ICC_LVL_VALUE_MASK;
-- 
2.7.4



[scsi 2/4] scsi: ufs: unexport descritpor reading functions

2017-01-04 Thread Tomas Winkler
Unexport ufshcd_read_device_desc and ufshcd_read_string_desc
there is no really possibility to calling them directly
outside of UFS context.

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 9 -
 drivers/scsi/ufs/ufshcd.h | 7 ---
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index be3c2900b6bb..63d7ae2c3be9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2208,11 +2208,10 @@ static inline int ufshcd_read_power_desc(struct ufs_hba 
*hba,
return err;
 }
 
-int ufshcd_read_device_desc(struct ufs_hba *hba, u8 *buf, u32 size)
+static int ufshcd_read_device_desc(struct ufs_hba *hba, u8 *buf, u32 size)
 {
return ufshcd_read_desc(hba, QUERY_DESC_IDN_DEVICE, 0, buf, size);
 }
-EXPORT_SYMBOL(ufshcd_read_device_desc);
 
 /**
  * ufshcd_read_string_desc - read string descriptor
@@ -2224,8 +2223,9 @@ EXPORT_SYMBOL(ufshcd_read_device_desc);
  *
  * Return 0 in case of success, non-zero otherwise
  */
-int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index, u8 *buf,
-   u32 size, bool ascii)
+#define ASCII_STD true
+static int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index,
+  u8 *buf, u32 size, bool ascii)
 {
int err = 0;
 
@@ -2281,7 +2281,6 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, int 
desc_index, u8 *buf,
 out:
return err;
 }
-EXPORT_SYMBOL(ufshcd_read_string_desc);
 
 /**
  * ufshcd_read_unit_desc_param - read the specified unit descriptor parameter
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 08cd26ed2382..00fb82589895 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -713,8 +713,6 @@ static inline int ufshcd_dme_peer_get(struct ufs_hba *hba,
return ufshcd_dme_get_attr(hba, attr_sel, mib_val, DME_PEER);
 }
 
-int ufshcd_read_device_desc(struct ufs_hba *hba, u8 *buf, u32 size);
-
 static inline bool ufshcd_is_hs_mode(struct ufs_pa_layer_attr *pwr_info)
 {
return (pwr_info->pwr_rx == FAST_MODE ||
@@ -723,11 +721,6 @@ static inline bool ufshcd_is_hs_mode(struct 
ufs_pa_layer_attr *pwr_info)
pwr_info->pwr_tx == FASTAUTO_MODE);
 }
 
-#define ASCII_STD true
-
-int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index, u8 *buf,
-   u32 size, bool ascii);
-
 /* Expose Query-Request API */
 int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
enum flag_idn idn, bool *flag_res);
-- 
2.7.4



[tip:perf/urgent] samples/bpf sock_example: Avoid getting ethhdr from two includes

2017-01-04 Thread tip-bot for Arnaldo Carvalho de Melo
Commit-ID:  ee12996c9d392ec61241ab6c74d257bc2122e0bc
Gitweb: http://git.kernel.org/tip/ee12996c9d392ec61241ab6c74d257bc2122e0bc
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 27 Dec 2016 21:49:17 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 27 Dec 2016 21:49:17 -0300

samples/bpf sock_example: Avoid getting ethhdr from two includes

To avoid the following build failure on Alpine Linux 3.4, that has
clang-3.8 with the bpf target:

HOSTCC  samples/bpf/sock_example.o
  In file included from /usr/include/net/ethernet.h:10:0,
   from /git/linux/samples/bpf/sock_example.h:7,
   from /git/linux/samples/bpf/sock_example.c:30:
  /usr/include/netinet/if_ether.h:96:8: error: redefinition of 'struct
  ethhdr'
   struct ethhdr {
  ^
  In file included from /git/linux/samples/bpf/sock_example.c:26:0:
  ./usr/include/linux/if_ether.h:144:8: note: originally defined here
   struct ethhdr {
  ^
  scripts/Makefile.host:124: recipe for target
  'samples/bpf/sock_example.o' failed
  make[2]: *** [samples/bpf/sock_example.o] Error 1
  /git/linux/Makefile:1658: recipe for target 'samples/bpf/' failed

So include net/if_ether.h for the needs of sock_example.h, using the
same include that sock_example.c uses.

Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Joe Stringer 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-m9avekl1b651qe1r1zd5t...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/sock_example.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/bpf/sock_example.h b/samples/bpf/sock_example.h
index 09f7fe7..d801406 100644
--- a/samples/bpf/sock_example.h
+++ b/samples/bpf/sock_example.h
@@ -4,7 +4,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 


[tip:perf/urgent] perf sched timehist: Show total scheduling time

2017-01-04 Thread tip-bot for Namhyung Kim
Commit-ID:  9396c9cb0d9534ca67bda8a34b2413a2ca1c67e9
Gitweb: http://git.kernel.org/tip/9396c9cb0d9534ca67bda8a34b2413a2ca1c67e9
Author: Namhyung Kim 
AuthorDate: Thu, 22 Dec 2016 15:03:50 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 27 Dec 2016 21:47:57 -0300

perf sched timehist: Show total scheduling time

Show length of analyzed sample time and rate of idle task running.
This also takes care of time range given by --time option.

  $ perf sched timehist -sI | tail
  Samples do not have callchains.
  Idle stats:
  CPU  0 idle for930.316  msec  ( 92.93%)
  CPU  1 idle for963.614  msec  ( 96.25%)
  CPU  2 idle for885.482  msec  ( 88.45%)
  CPU  3 idle for938.635  msec  ( 93.76%)

  Total number of unique tasks: 118
  Total number of context switches: 2337
 Total run time (msec): 3718.048
  Total scheduling time (msec): 1001.131  (x 4)

Suggested-by: David Ahern 
Signed-off-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20161222060350.17655-3-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-sched.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index d53e706..5b134b0 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -209,6 +209,7 @@ struct perf_sched {
u64 skipped_samples;
const char  *time_str;
struct perf_time_interval ptime;
+   struct perf_time_interval hist_time;
 };
 
 /* per thread run time data */
@@ -2460,6 +2461,11 @@ static int timehist_sched_change_event(struct perf_tool 
*tool,
timehist_print_sample(sched, sample, , thread, t);
 
 out:
+   if (sched->hist_time.start == 0 && t >= ptime->start)
+   sched->hist_time.start = t;
+   if (ptime->end == 0 || t <= ptime->end)
+   sched->hist_time.end = t;
+
if (tr) {
/* time of this sched_switch event becomes last time task seen 
*/
tr->last_time = sample->time;
@@ -2624,6 +2630,7 @@ static void timehist_print_summary(struct perf_sched 
*sched,
struct thread *t;
struct thread_runtime *r;
int i;
+   u64 hist_time = sched->hist_time.end - sched->hist_time.start;
 
memset(, 0, sizeof(totals));
 
@@ -2665,7 +2672,7 @@ static void timehist_print_summary(struct perf_sched 
*sched,
totals.sched_count += r->run_stats.n;
printf("CPU %2d idle for ", i);
print_sched_time(r->total_run_time, 6);
-   printf(" msec\n");
+   printf(" msec  (%6.2f%%)\n", 100.0 * r->total_run_time 
/ hist_time);
} else
printf("CPU %2d idle entire time window\n", i);
}
@@ -2701,12 +2708,16 @@ static void timehist_print_summary(struct perf_sched 
*sched,
 
printf("\n"
   "Total number of unique tasks: %" PRIu64 "\n"
-  "Total number of context switches: %" PRIu64 "\n"
-  "   Total run time (msec): ",
+  "Total number of context switches: %" PRIu64 "\n",
   totals.task_count, totals.sched_count);
 
+   printf("   Total run time (msec): ");
print_sched_time(totals.total_run_time, 2);
printf("\n");
+
+   printf("Total scheduling time (msec): ");
+   print_sched_time(hist_time, 2);
+   printf(" (x %d)\n", sched->max_cpu);
 }
 
 typedef int (*sched_handler)(struct perf_tool *tool,


[tip:perf/urgent] perf sched timehist: Show total scheduling time

2017-01-04 Thread tip-bot for Namhyung Kim
Commit-ID:  9396c9cb0d9534ca67bda8a34b2413a2ca1c67e9
Gitweb: http://git.kernel.org/tip/9396c9cb0d9534ca67bda8a34b2413a2ca1c67e9
Author: Namhyung Kim 
AuthorDate: Thu, 22 Dec 2016 15:03:50 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 27 Dec 2016 21:47:57 -0300

perf sched timehist: Show total scheduling time

Show length of analyzed sample time and rate of idle task running.
This also takes care of time range given by --time option.

  $ perf sched timehist -sI | tail
  Samples do not have callchains.
  Idle stats:
  CPU  0 idle for930.316  msec  ( 92.93%)
  CPU  1 idle for963.614  msec  ( 96.25%)
  CPU  2 idle for885.482  msec  ( 88.45%)
  CPU  3 idle for938.635  msec  ( 93.76%)

  Total number of unique tasks: 118
  Total number of context switches: 2337
 Total run time (msec): 3718.048
  Total scheduling time (msec): 1001.131  (x 4)

Suggested-by: David Ahern 
Signed-off-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20161222060350.17655-3-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-sched.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index d53e706..5b134b0 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -209,6 +209,7 @@ struct perf_sched {
u64 skipped_samples;
const char  *time_str;
struct perf_time_interval ptime;
+   struct perf_time_interval hist_time;
 };
 
 /* per thread run time data */
@@ -2460,6 +2461,11 @@ static int timehist_sched_change_event(struct perf_tool 
*tool,
timehist_print_sample(sched, sample, , thread, t);
 
 out:
+   if (sched->hist_time.start == 0 && t >= ptime->start)
+   sched->hist_time.start = t;
+   if (ptime->end == 0 || t <= ptime->end)
+   sched->hist_time.end = t;
+
if (tr) {
/* time of this sched_switch event becomes last time task seen 
*/
tr->last_time = sample->time;
@@ -2624,6 +2630,7 @@ static void timehist_print_summary(struct perf_sched 
*sched,
struct thread *t;
struct thread_runtime *r;
int i;
+   u64 hist_time = sched->hist_time.end - sched->hist_time.start;
 
memset(, 0, sizeof(totals));
 
@@ -2665,7 +2672,7 @@ static void timehist_print_summary(struct perf_sched 
*sched,
totals.sched_count += r->run_stats.n;
printf("CPU %2d idle for ", i);
print_sched_time(r->total_run_time, 6);
-   printf(" msec\n");
+   printf(" msec  (%6.2f%%)\n", 100.0 * r->total_run_time 
/ hist_time);
} else
printf("CPU %2d idle entire time window\n", i);
}
@@ -2701,12 +2708,16 @@ static void timehist_print_summary(struct perf_sched 
*sched,
 
printf("\n"
   "Total number of unique tasks: %" PRIu64 "\n"
-  "Total number of context switches: %" PRIu64 "\n"
-  "   Total run time (msec): ",
+  "Total number of context switches: %" PRIu64 "\n",
   totals.task_count, totals.sched_count);
 
+   printf("   Total run time (msec): ");
print_sched_time(totals.total_run_time, 2);
printf("\n");
+
+   printf("Total scheduling time (msec): ");
+   print_sched_time(hist_time, 2);
+   printf(" (x %d)\n", sched->max_cpu);
 }
 
 typedef int (*sched_handler)(struct perf_tool *tool,


Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

2017-01-04 Thread Archit Taneja

Hi,

Some comments below.

On 01/02/2017 01:54 AM, Peter Senna Tschudin wrote:

Add a driver that create a drm_bridge and a drm_connector for the LVDS
to DP++ display bridge of the GE B850v3.

There are two physical bridges on the video signal pipeline: a
STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
firmware made it complicated for this binding to comprise two device
tree nodes, as the design goal is to configure both bridges based on
the LVDS signal, which leave the driver powerless to control the video
processing pipeline. The two bridges behaves as a single bridge, and
the driver is only needed for telling the host about EDID / HPD, and
for giving the host powers to ack interrupts. The video signal pipeline
is as follows:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
CC: David Airlie 
CC: Thierry Reding 
CC: Thierry Reding 
CC: Archit Taneja 
Reviewed-by: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 384 +
 3 files changed, 396 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..e3e1f3b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.

+config DRM_GE_B850V3_LVDS_DP
+   tristate "GE B850v3 LVDS to DP++ display bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridge of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..886d0fd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
new file mode 100644
index 000..4574f6e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
@@ -0,0 +1,384 @@
+/*
+ * Driver for GE B850v3 DP display bridge


Mentioning LVDS to DP++ here would be nice.


+
+ * Copyright (c) 2016, Collabora Ltd.
+ * Copyright (c) 2016, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope 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 creates a drm_bridge and a drm_connector for the LVDS to DP++
+ * display bridge of the GE B850v3. There are two physical bridges on the video
+ * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). However
+ * the physical bridges are automatically configured by the input video signal,
+ * and the driver has no access to the video processing pipeline. The driver is
+ * only needed to read EDID from the STDP2690 and to handle HPD events from the
+ * STDP4028. The driver communicates with both bridges over i2c. The video
+ * signal pipeline is as follows:
+ *
+ *   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_EDID_REG 0x72
+#define 

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

2017-01-04 Thread Archit Taneja

Hi,

Some comments below.

On 01/02/2017 01:54 AM, Peter Senna Tschudin wrote:

Add a driver that create a drm_bridge and a drm_connector for the LVDS
to DP++ display bridge of the GE B850v3.

There are two physical bridges on the video signal pipeline: a
STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
firmware made it complicated for this binding to comprise two device
tree nodes, as the design goal is to configure both bridges based on
the LVDS signal, which leave the driver powerless to control the video
processing pipeline. The two bridges behaves as a single bridge, and
the driver is only needed for telling the host about EDID / HPD, and
for giving the host powers to ack interrupts. The video signal pipeline
is as follows:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
CC: David Airlie 
CC: Thierry Reding 
CC: Thierry Reding 
CC: Archit Taneja 
Reviewed-by: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 384 +
 3 files changed, 396 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..e3e1f3b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.

+config DRM_GE_B850V3_LVDS_DP
+   tristate "GE B850v3 LVDS to DP++ display bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridge of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..886d0fd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
new file mode 100644
index 000..4574f6e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
@@ -0,0 +1,384 @@
+/*
+ * Driver for GE B850v3 DP display bridge


Mentioning LVDS to DP++ here would be nice.


+
+ * Copyright (c) 2016, Collabora Ltd.
+ * Copyright (c) 2016, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope 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 creates a drm_bridge and a drm_connector for the LVDS to DP++
+ * display bridge of the GE B850v3. There are two physical bridges on the video
+ * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). However
+ * the physical bridges are automatically configured by the input video signal,
+ * and the driver has no access to the video processing pipeline. The driver is
+ * only needed to read EDID from the STDP2690 and to handle HPD events from the
+ * STDP4028. The driver communicates with both bridges over i2c. The video
+ * signal pipeline is as follows:
+ *
+ *   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_EDID_REG 0x72
+#define DEFAULT_EDID_REG_NAME "edid"
+
+#define EDID_EXT_BLOCK_CNT 0x7E
+
+#define STDP4028_IRQ_OUT_CONF_REG 0x02
+#define STDP4028_DPTX_IRQ_EN_REG 0x3C
+#define STDP4028_DPTX_IRQ_STS_REG 0x3D
+#define STDP4028_DPTX_STS_REG 0x3E
+
+#define STDP4028_DPTX_DP_IRQ_EN 0x1000
+
+#define STDP4028_DPTX_HOTPLUG_IRQ_EN 0x0400
+#define 

Re: [PATCH v4] mmc: dw_mmc: force setup bus if active slots exist

2017-01-04 Thread Shawn Lin

On 2017/1/5 15:23, Ziyuan Xu wrote:

It's necessary to setup bus if any slots are present.
- update clock after ctrl reset
- if the host has genpd node, we can guarantee the clock is available
before starting request. Otherwies, the clock register is reset once
power off the pd, and host can't output the active clock during
communication.

fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback")
Reported-by: Randy Li 
Signed-off-by: Ziyuan Xu 

---
Hi guys,

I found a similar issue on rk3399 platform, which has a genpd node for
SD card host. Power off-on pd will reset the registers to a default
value (ie. CLKENA), so that the host can't output the active clock
during communication.



Indeed, Caesar recently introduced all the genpd for rk3399 platform,
so we need to restore them.


So we need to setup bus in rpm resume. It also wraps the update clock
behaviour which I did in V3.

Thanks,
Ziyuan Xu


Changes in v4:
- update commit message
- fix SD host rpm resume can't work

Changes in v3:
- only reset host with active slot.

Changes in v2:
- update the commit message
- use dw_mci_reset instead of dw_mci_ctrl_reset

 drivers/mmc/host/dw_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b44306b..b6053b3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3354,10 +3354,10 @@ int dw_mci_runtime_resume(struct device *dev)

if (!slot)
continue;
-   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
+   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER)
dw_mci_set_ios(slot->mmc, >mmc->ios);
-   dw_mci_setup_bus(slot, true);
-   }
+   /* Force setup bus to guarantee available clock output */
+   dw_mci_setup_bus(slot, true);


So the spamming message about

"Bus speed (slot %d) = %dHz (slot req %dHz, actual %dHZ div = %d)\n"

will always be there, right? So you could append a new patch to shut
up it as I think it's useless no matter for system pm or rpm to print
it.  How about?


}

/* Now that slots are all setup, we can enable card detect */




--
Best Regards
Shawn Lin



Re: [PATCH v4] mmc: dw_mmc: force setup bus if active slots exist

2017-01-04 Thread Shawn Lin

On 2017/1/5 15:23, Ziyuan Xu wrote:

It's necessary to setup bus if any slots are present.
- update clock after ctrl reset
- if the host has genpd node, we can guarantee the clock is available
before starting request. Otherwies, the clock register is reset once
power off the pd, and host can't output the active clock during
communication.

fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback")
Reported-by: Randy Li 
Signed-off-by: Ziyuan Xu 

---
Hi guys,

I found a similar issue on rk3399 platform, which has a genpd node for
SD card host. Power off-on pd will reset the registers to a default
value (ie. CLKENA), so that the host can't output the active clock
during communication.



Indeed, Caesar recently introduced all the genpd for rk3399 platform,
so we need to restore them.


So we need to setup bus in rpm resume. It also wraps the update clock
behaviour which I did in V3.

Thanks,
Ziyuan Xu


Changes in v4:
- update commit message
- fix SD host rpm resume can't work

Changes in v3:
- only reset host with active slot.

Changes in v2:
- update the commit message
- use dw_mci_reset instead of dw_mci_ctrl_reset

 drivers/mmc/host/dw_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b44306b..b6053b3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3354,10 +3354,10 @@ int dw_mci_runtime_resume(struct device *dev)

if (!slot)
continue;
-   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
+   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER)
dw_mci_set_ios(slot->mmc, >mmc->ios);
-   dw_mci_setup_bus(slot, true);
-   }
+   /* Force setup bus to guarantee available clock output */
+   dw_mci_setup_bus(slot, true);


So the spamming message about

"Bus speed (slot %d) = %dHz (slot req %dHz, actual %dHZ div = %d)\n"

will always be there, right? So you could append a new patch to shut
up it as I think it's useless no matter for system pm or rpm to print
it.  How about?


}

/* Now that slots are all setup, we can enable card detect */




--
Best Regards
Shawn Lin



Re: [PATCH v2] hv: retry infinitely on hypercall transient failures

2017-01-04 Thread Greg KH
On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> From: Long Li 
> 
> Hyper-v host guarantees that a hypercall will finish in reasonable time.
> Retry infinitely on transient failures to avoid returning error to upper 
> layer.

Again, never retry "forever", always have a way out, otherwise you will
crash.

And again, why are you making this change?  What problem does it solve?

greg k-h


Re: [PATCH v2] hv: retry infinitely on hypercall transient failures

2017-01-04 Thread Greg KH
On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> From: Long Li 
> 
> Hyper-v host guarantees that a hypercall will finish in reasonable time.
> Retry infinitely on transient failures to avoid returning error to upper 
> layer.

Again, never retry "forever", always have a way out, otherwise you will
crash.

And again, why are you making this change?  What problem does it solve?

greg k-h


Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

2017-01-04 Thread Lee Jones
On Wed, 04 Jan 2017, Bjorn Andersson wrote:

> On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> 
> > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > 
> > > From: Bjorn Andersson 
> > > 
> > > Implement support for initialization of the lm3533 driver core and
> > > probing child devices from Device Tree.
> > > 
> 
> [..]
> 
> > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > >   lm3533_device_bl_init(lm3533);
> > >   lm3533_device_led_init(lm3533);
> > >  
> > > + if (lm3533->dev->of_node) {
> > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > +  lm3533->dev);
> > > + }
> > 
> > I think it's save to call of_platform_populate(), even if !of_node.
> > It will just fail and return an error code, which you are ignoring
> > anyway.
> > 
> 
> I thought so too, but that's apparently how you trigger probing children
> of the root node. So we're stuck with a conditional.

Ah, so this is to protect against the case where DT is present, but a
node for this device is not (or is disabled), so is left unprobed.
Then the bind is initiated via I2C?  Or something else?

> > >  static int lm3533_i2c_probe(struct i2c_client *i2c,
> > >   const struct i2c_device_id *id)
> > >  {
> 
> [..]
> 
> > >  
> > > + if (i2c->dev.of_node) {
> > 
> > I'd prefer this check to be placed in lm3533_pdata_from_of_node().
> > 
> > Just return silently if !dev->of_node.
> > 
> 
> I agree, will update this.
> 
> > > + ret = lm3533_pdata_from_of_node(lm3533->dev);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> > >   return lm3533_device_init(lm3533);
> > >  }
> > >  
> 
> Regards,
> Bjorn

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

2017-01-04 Thread Lee Jones
On Wed, 04 Jan 2017, Bjorn Andersson wrote:

> On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> 
> > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > 
> > > From: Bjorn Andersson 
> > > 
> > > Implement support for initialization of the lm3533 driver core and
> > > probing child devices from Device Tree.
> > > 
> 
> [..]
> 
> > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > >   lm3533_device_bl_init(lm3533);
> > >   lm3533_device_led_init(lm3533);
> > >  
> > > + if (lm3533->dev->of_node) {
> > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > +  lm3533->dev);
> > > + }
> > 
> > I think it's save to call of_platform_populate(), even if !of_node.
> > It will just fail and return an error code, which you are ignoring
> > anyway.
> > 
> 
> I thought so too, but that's apparently how you trigger probing children
> of the root node. So we're stuck with a conditional.

Ah, so this is to protect against the case where DT is present, but a
node for this device is not (or is disabled), so is left unprobed.
Then the bind is initiated via I2C?  Or something else?

> > >  static int lm3533_i2c_probe(struct i2c_client *i2c,
> > >   const struct i2c_device_id *id)
> > >  {
> 
> [..]
> 
> > >  
> > > + if (i2c->dev.of_node) {
> > 
> > I'd prefer this check to be placed in lm3533_pdata_from_of_node().
> > 
> > Just return silently if !dev->of_node.
> > 
> 
> I agree, will update this.
> 
> > > + ret = lm3533_pdata_from_of_node(lm3533->dev);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> > >   return lm3533_device_init(lm3533);
> > >  }
> > >  
> 
> Regards,
> Bjorn

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[v1] scsi: qla2xxx: qla_mr:- Release and Unmap memory regions when an error occurred.

2017-01-04 Thread Arvind Yadav
Free memory regions, if qlafx00_iospace_config is not successful.

Signed-off-by: Arvind Yadav 
---
 drivers/scsi/qla2xxx/qla_mr.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_mr.c b/drivers/scsi/qla2xxx/qla_mr.c
index 02f1de1..2861df8 100644
--- a/drivers/scsi/qla2xxx/qla_mr.c
+++ b/drivers/scsi/qla2xxx/qla_mr.c
@@ -770,7 +770,7 @@
ql_log_pci(ql_log_fatal, ha->pdev, 0x014e,
"Failed to reserve PIO/MMIO regions (%s), aborting.\n",
pci_name(ha->pdev));
-   goto iospace_error_exit;
+   return -ENOMEM;
}
 
/* Use MMIO operations for all accesses. */
@@ -799,13 +799,13 @@
ql_log_pci(ql_log_warn, ha->pdev, 0x0129,
"region #2 not an MMIO resource (%s), aborting\n",
pci_name(ha->pdev));
-   goto iospace_error_exit;
+   goto iounmap_error_exit;
}
if (pci_resource_len(ha->pdev, 2) < BAR2_LEN_FX00) {
ql_log_pci(ql_log_warn, ha->pdev, 0x012a,
"Invalid PCI mem BAR2 region size (%s), aborting\n",
pci_name(ha->pdev));
-   goto iospace_error_exit;
+   goto iounmap_error_exit;
}
 
ha->iobase =
@@ -813,7 +813,7 @@
if (!ha->iobase) {
ql_log_pci(ql_log_fatal, ha->pdev, 0x012b,
"cannot remap MMIO (%s), aborting\n", pci_name(ha->pdev));
-   goto iospace_error_exit;
+   goto iounmap_error_exit;
}
 
/* Determine queue resources */
@@ -825,7 +825,10 @@
 
return 0;
 
+iounmap_error_exit:
+   iounmap(ha->cregbase);
 iospace_error_exit:
+   pci_release_selected_regions(ha->pdev, ha->bars);
return -ENOMEM;
 }
 
-- 
1.9.1



[v1] scsi: qla2xxx: qla_mr:- Release and Unmap memory regions when an error occurred.

2017-01-04 Thread Arvind Yadav
Free memory regions, if qlafx00_iospace_config is not successful.

Signed-off-by: Arvind Yadav 
---
 drivers/scsi/qla2xxx/qla_mr.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_mr.c b/drivers/scsi/qla2xxx/qla_mr.c
index 02f1de1..2861df8 100644
--- a/drivers/scsi/qla2xxx/qla_mr.c
+++ b/drivers/scsi/qla2xxx/qla_mr.c
@@ -770,7 +770,7 @@
ql_log_pci(ql_log_fatal, ha->pdev, 0x014e,
"Failed to reserve PIO/MMIO regions (%s), aborting.\n",
pci_name(ha->pdev));
-   goto iospace_error_exit;
+   return -ENOMEM;
}
 
/* Use MMIO operations for all accesses. */
@@ -799,13 +799,13 @@
ql_log_pci(ql_log_warn, ha->pdev, 0x0129,
"region #2 not an MMIO resource (%s), aborting\n",
pci_name(ha->pdev));
-   goto iospace_error_exit;
+   goto iounmap_error_exit;
}
if (pci_resource_len(ha->pdev, 2) < BAR2_LEN_FX00) {
ql_log_pci(ql_log_warn, ha->pdev, 0x012a,
"Invalid PCI mem BAR2 region size (%s), aborting\n",
pci_name(ha->pdev));
-   goto iospace_error_exit;
+   goto iounmap_error_exit;
}
 
ha->iobase =
@@ -813,7 +813,7 @@
if (!ha->iobase) {
ql_log_pci(ql_log_fatal, ha->pdev, 0x012b,
"cannot remap MMIO (%s), aborting\n", pci_name(ha->pdev));
-   goto iospace_error_exit;
+   goto iounmap_error_exit;
}
 
/* Determine queue resources */
@@ -825,7 +825,10 @@
 
return 0;
 
+iounmap_error_exit:
+   iounmap(ha->cregbase);
 iospace_error_exit:
+   pci_release_selected_regions(ha->pdev, ha->bars);
return -ENOMEM;
 }
 
-- 
1.9.1



Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()

2017-01-04 Thread Ingo Molnar

* Nicolai Stange  wrote:

> Matt Fleming  writes:
> 
> > On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote:
> >> So, after memblock is gone, allocations should be done through the "normal"
> >> page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
> >> it from efi_arch_mem_reserve() and from efi_free_boot_services() as well.
> >> 
> >> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying 
> >> image data")
> >> Signed-off-by: Nicolai Stange 
> 
> > Could you also modify efi_fake_memmap() to use your new
> > efi_memmap_alloc() function for consistency
> 
> Sure.
> 
> I'm planning to submit another set of patches addressing the (bounded)
> memmap leaking in anything calling efi_memmap_unmap() though. In the
> course of doing so, the memmap allocation sites will get touched anyway:
> I'll have to store some information about how the memmap's memory has
> been obtained.

Will that patch be intrusive?

If yes then we'll need to keep this a separate urgent patch to fix the v4.9 
regression that Dan Williams reported. I can apply the fix to efi/urgent and 
get 
it to Linus straight away if you guys agree.

Thanks,

Ingo


Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()

2017-01-04 Thread Ingo Molnar

* Nicolai Stange  wrote:

> Matt Fleming  writes:
> 
> > On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote:
> >> So, after memblock is gone, allocations should be done through the "normal"
> >> page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
> >> it from efi_arch_mem_reserve() and from efi_free_boot_services() as well.
> >> 
> >> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying 
> >> image data")
> >> Signed-off-by: Nicolai Stange 
> 
> > Could you also modify efi_fake_memmap() to use your new
> > efi_memmap_alloc() function for consistency
> 
> Sure.
> 
> I'm planning to submit another set of patches addressing the (bounded)
> memmap leaking in anything calling efi_memmap_unmap() though. In the
> course of doing so, the memmap allocation sites will get touched anyway:
> I'll have to store some information about how the memmap's memory has
> been obtained.

Will that patch be intrusive?

If yes then we'll need to keep this a separate urgent patch to fix the v4.9 
regression that Dan Williams reported. I can apply the fix to efi/urgent and 
get 
it to Linus straight away if you guys agree.

Thanks,

Ingo


Re: [PATCH 1/2] mfd: micon: Add Buffalo Kurobox Pro, Terastation II Pro/Live driver

2017-01-04 Thread Lee Jones
On Wed, 04 Jan 2017, Florian Fainelli wrote:

> Le 01/04/17 à 03:22, Lee Jones a écrit :
> > On Wed, 28 Dec 2016, Florian Fainelli wrote:
> > 
> >> This driver is currently only used to reboot the devices, but the
> >> microcontroller hanging off UART1 on the Buffalo Kurobox Pro and
> >> Terastation II Pro/Live is capable of a lot more than that, which we
> >> will support in subsequent patches. For now, just add the reboot
> >> functionality to make the kernel reboot correctly.
> > 
> > This is not an MFD driver.  You have written a UART driver.
> > 
> > Please relocate it to drivers/char/tty/serial.
> 
> Not that simple, and as explained in the cover letter the UART attached
> micro controller can do a lot more than just reboot the machine, but

That's fine.  This is precisely why we have MFD.  But the core (MFD)
driver should only conduct set-up of shared resources, registration of
child devices and maybe some shared functionality required by >1 child
device.  All child device (i.e. UART) capability should be handled by
the child drivers.

> someone else is working on the driver, so this patch series can be ignored.

Okay.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 1/2] mfd: micon: Add Buffalo Kurobox Pro, Terastation II Pro/Live driver

2017-01-04 Thread Lee Jones
On Wed, 04 Jan 2017, Florian Fainelli wrote:

> Le 01/04/17 à 03:22, Lee Jones a écrit :
> > On Wed, 28 Dec 2016, Florian Fainelli wrote:
> > 
> >> This driver is currently only used to reboot the devices, but the
> >> microcontroller hanging off UART1 on the Buffalo Kurobox Pro and
> >> Terastation II Pro/Live is capable of a lot more than that, which we
> >> will support in subsequent patches. For now, just add the reboot
> >> functionality to make the kernel reboot correctly.
> > 
> > This is not an MFD driver.  You have written a UART driver.
> > 
> > Please relocate it to drivers/char/tty/serial.
> 
> Not that simple, and as explained in the cover letter the UART attached
> micro controller can do a lot more than just reboot the machine, but

That's fine.  This is precisely why we have MFD.  But the core (MFD)
driver should only conduct set-up of shared resources, registration of
child devices and maybe some shared functionality required by >1 child
device.  All child device (i.e. UART) capability should be handled by
the child drivers.

> someone else is working on the driver, so this patch series can be ignored.

Okay.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v6 5/5] soc: zte: pm_domains: Add support for zx296718

2017-01-04 Thread Shawn Guo
On Wed, Jan 04, 2017 at 07:48:14PM +0800, Baoyou Xie wrote:
> This patch introduces the power domain driver of zx296718
> which belongs to zte's zx2967 family.
> 
> Signed-off-by: Baoyou Xie 
> Reviewed-by: Jun Nie 
> ---
>  drivers/soc/zte/Makefile  |   1 +
>  drivers/soc/zte/zx296718_pm_domains.c | 181 
> ++
>  2 files changed, 182 insertions(+)
>  create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
> 
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> index 8a37f2f..96b7cd4 100644
> --- a/drivers/soc/zte/Makefile
> +++ b/drivers/soc/zte/Makefile
> @@ -2,3 +2,4 @@
>  # ZTE SOC drivers
>  #
>  obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
> diff --git a/drivers/soc/zte/zx296718_pm_domains.c 
> b/drivers/soc/zte/zx296718_pm_domains.c
> new file mode 100644
> index 000..52003ee
> --- /dev/null
> +++ b/drivers/soc/zte/zx296718_pm_domains.c
> @@ -0,0 +1,181 @@
> +/*
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie 
> + * License terms: GNU General Public License (GPL) version 2
> + */

Please have a newline between licence declaration and headers to improve
the readability.  Same for zx2967_pm_domains.c.

> +#include 
> +#include "zx2967_pm_domains.h"
> +
> +static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
> + [REG_CLKEN] = 0x18,
> + [REG_ISOEN] = 0x1c,
> + [REG_RSTEN] = 0x20,
> + [REG_PWREN] = 0x24,
> + [REG_ACK_SYNC] = 0x28,
> +};
> +
> +enum {
> + PCU_DM_VOU = 0,
> + PCU_DM_SAPPU,
> + PCU_DM_VDE,
> + PCU_DM_VCE,
> + PCU_DM_HDE,
> + PCU_DM_VIU,
> + PCU_DM_USB20,
> + PCU_DM_USB21,
> + PCU_DM_USB30,
> + PCU_DM_HSIC,
> + PCU_DM_GMAC,
> + PCU_DM_TS,
> +};

I think we can save this enum completely by defining those
DM_ZX296718_xxx constants in zte,pm_domains.h in the same order of this
enum (hardware bit position order), so that DM_ZX296718_xxx can directly
be used as .bit field of struct zx2967_pm_domain.

#define DM_ZX296718_VOU 0
#define DM_ZX296718_SAPPU   1
#define DM_ZX296718_VDE 2  /* g1v6 */
#define DM_ZX296718_VCE 3  /* h1v6 */
#define DM_ZX296718_HDE 4  /* g2v2 */
#define DM_ZX296718_VIU 5
#define DM_ZX296718_USB20   6
#define DM_ZX296718_USB21   7
#define DM_ZX296718_USB30   8
#define DM_ZX296718_HSIC9
#define DM_ZX296718_GMAC10
#define DM_ZX296718_TS  11

> +
> +static struct zx2967_pm_domain vou_domain = {
> + .dm = {
> + .name   = "vou_domain",
> + },
> + .bit = PCU_DM_VOU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain sappu_domain = {
> + .dm = {
> + .name   = "sappu_domain",
> + },
> + .bit = PCU_DM_SAPPU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain vde_domain = {
> + .dm = {
> + .name   = "vde_domain",
> + },
> + .bit = PCU_DM_VDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain vce_domain = {
> + .dm = {
> + .name   = "vce_domain",
> + },
> + .bit = PCU_DM_VCE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain hde_domain = {
> + .dm = {
> + .name   = "hde_domain",
> + },
> + .bit = PCU_DM_HDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain viu_domain = {
> + .dm = {
> + .name   = "viu_domain",
> + },
> + .bit = PCU_DM_VIU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb20_domain = {
> + .dm = {
> + .name   = "usb20_domain",
> + },
> + .bit = PCU_DM_USB20,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb21_domain = {
> + .dm = {
> + .name   = "usb21_domain",
> + },
> + .bit = PCU_DM_USB21,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb30_domain = {
> + .dm = {
> + .name   = "usb30_domain",
> + },
> + .bit = PCU_DM_USB30,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain hsic_domain = {
> + .dm = {
> + .name   = "hsic_domain",
> + },
> + .bit = PCU_DM_HSIC,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain gmac_domain = {
> + .dm = {
> + .name   = "gmac_domain",
> + 

Re: [PATCH v6 5/5] soc: zte: pm_domains: Add support for zx296718

2017-01-04 Thread Shawn Guo
On Wed, Jan 04, 2017 at 07:48:14PM +0800, Baoyou Xie wrote:
> This patch introduces the power domain driver of zx296718
> which belongs to zte's zx2967 family.
> 
> Signed-off-by: Baoyou Xie 
> Reviewed-by: Jun Nie 
> ---
>  drivers/soc/zte/Makefile  |   1 +
>  drivers/soc/zte/zx296718_pm_domains.c | 181 
> ++
>  2 files changed, 182 insertions(+)
>  create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
> 
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> index 8a37f2f..96b7cd4 100644
> --- a/drivers/soc/zte/Makefile
> +++ b/drivers/soc/zte/Makefile
> @@ -2,3 +2,4 @@
>  # ZTE SOC drivers
>  #
>  obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
> diff --git a/drivers/soc/zte/zx296718_pm_domains.c 
> b/drivers/soc/zte/zx296718_pm_domains.c
> new file mode 100644
> index 000..52003ee
> --- /dev/null
> +++ b/drivers/soc/zte/zx296718_pm_domains.c
> @@ -0,0 +1,181 @@
> +/*
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie 
> + * License terms: GNU General Public License (GPL) version 2
> + */

Please have a newline between licence declaration and headers to improve
the readability.  Same for zx2967_pm_domains.c.

> +#include 
> +#include "zx2967_pm_domains.h"
> +
> +static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
> + [REG_CLKEN] = 0x18,
> + [REG_ISOEN] = 0x1c,
> + [REG_RSTEN] = 0x20,
> + [REG_PWREN] = 0x24,
> + [REG_ACK_SYNC] = 0x28,
> +};
> +
> +enum {
> + PCU_DM_VOU = 0,
> + PCU_DM_SAPPU,
> + PCU_DM_VDE,
> + PCU_DM_VCE,
> + PCU_DM_HDE,
> + PCU_DM_VIU,
> + PCU_DM_USB20,
> + PCU_DM_USB21,
> + PCU_DM_USB30,
> + PCU_DM_HSIC,
> + PCU_DM_GMAC,
> + PCU_DM_TS,
> +};

I think we can save this enum completely by defining those
DM_ZX296718_xxx constants in zte,pm_domains.h in the same order of this
enum (hardware bit position order), so that DM_ZX296718_xxx can directly
be used as .bit field of struct zx2967_pm_domain.

#define DM_ZX296718_VOU 0
#define DM_ZX296718_SAPPU   1
#define DM_ZX296718_VDE 2  /* g1v6 */
#define DM_ZX296718_VCE 3  /* h1v6 */
#define DM_ZX296718_HDE 4  /* g2v2 */
#define DM_ZX296718_VIU 5
#define DM_ZX296718_USB20   6
#define DM_ZX296718_USB21   7
#define DM_ZX296718_USB30   8
#define DM_ZX296718_HSIC9
#define DM_ZX296718_GMAC10
#define DM_ZX296718_TS  11

> +
> +static struct zx2967_pm_domain vou_domain = {
> + .dm = {
> + .name   = "vou_domain",
> + },
> + .bit = PCU_DM_VOU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain sappu_domain = {
> + .dm = {
> + .name   = "sappu_domain",
> + },
> + .bit = PCU_DM_SAPPU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain vde_domain = {
> + .dm = {
> + .name   = "vde_domain",
> + },
> + .bit = PCU_DM_VDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain vce_domain = {
> + .dm = {
> + .name   = "vce_domain",
> + },
> + .bit = PCU_DM_VCE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain hde_domain = {
> + .dm = {
> + .name   = "hde_domain",
> + },
> + .bit = PCU_DM_HDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain viu_domain = {
> + .dm = {
> + .name   = "viu_domain",
> + },
> + .bit = PCU_DM_VIU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb20_domain = {
> + .dm = {
> + .name   = "usb20_domain",
> + },
> + .bit = PCU_DM_USB20,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb21_domain = {
> + .dm = {
> + .name   = "usb21_domain",
> + },
> + .bit = PCU_DM_USB21,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb30_domain = {
> + .dm = {
> + .name   = "usb30_domain",
> + },
> + .bit = PCU_DM_USB30,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain hsic_domain = {
> + .dm = {
> + .name   = "hsic_domain",
> + },
> + .bit = PCU_DM_HSIC,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain gmac_domain = {
> + .dm = {
> + .name   = "gmac_domain",
> + },
> + .bit = PCU_DM_GMAC,
> + .polarity = PWREN,
> + 

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

2017-01-04 Thread Ingo Molnar

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

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual, news about it:
> 
> Has two new targets, debian:experimental-x-mipsel and
> debian:experimental-x-arm64.
> 
> Those use debian's multi-arch packages allowing cross building more than with
> the other crossbuild containers.
> 
> This still doesn't generate a full featured tool, as there are some buggy
> multi-arch packages, such as the devel packages for perl, gtk2, etc.
> 
> The following changes since commit 3705b97505bcbf6440f38119c0e7d6058f585b54:
> 
>   Merge tag 'perf-urgent-for-mingo-20161222' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2016-12-23 20:23:29 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-4.10-20170104
> 
> for you to fetch changes up to 8a937a25a7e3c19d5fb3f9d92f605cf5fda219d8:
> 
>   perf probe: Fix to probe on gcc generated symbols for offline kernel 
> (2017-01-04 11:44:22 -0300)
> 
> 
> perf/urgent fixes and one improvement:
> 
> Fixes:
> 
> - Fix prev/next_prio formatting for deadline tasks in libtraceevent (Daniel 
> Bristot de Oliveira)
> 
> - Robustify reading of build-ids from /sys/kernel/note (Arnaldo Carvalho de 
> Melo)
> 
> - Fix building some sample/bpf in Alpine Linux 3.4 (Arnaldo Carvalho de Melo)
> 
> - Fix 'make install-bin' to install libtraceevent plugins (Arnaldo Carvalho 
> de Melo)
> 
> - Fix 'perf record --switch-output' documentation and comment (Jiri Olsa)
> 
> - 'perf probe' fixes for cross arch probing (Masami Hiramatsu)
> 
> Improvement:
> 
> - Show total scheduling time in 'perf sched timehist' (Namhyumg Kim)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Arnaldo Carvalho de Melo (4):
>   samples/bpf sock_example: Avoid getting ethhdr from two includes
>   samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include
>   perf tools: Install tools/lib/traceevent plugins with install-bin
>   perf symbols: Robustify reading of build-id from sysfs
> 
> Daniel Bristot de Oliveira (1):
>   tools lib traceevent: Fix prev/next_prio for deadline tasks
> 
> Jiri Olsa (3):
>   tools lib subcmd: Add OPT_STRING_OPTARG_SET option
>   perf record: Make __record_options static
>   perf record: Fix --switch-output documentation and comment
> 
> Masami Hiramatsu (3):
>   perf probe: Fix to get correct modname from elf header
>   perf probe: Fix --funcs to show correct symbols for offline module
>   perf probe: Fix to probe on gcc generated symbols for offline kernel
> 
> Namhyung Kim (1):
>   perf sched timehist: Show total scheduling time
> 
>  samples/bpf/sock_example.h |   2 +-
>  samples/bpf/trace_output_user.c|   1 -
>  tools/lib/subcmd/parse-options.c   |   3 +
>  tools/lib/subcmd/parse-options.h   |   5 ++
>  tools/lib/traceevent/plugin_sched_switch.c |   4 +-
>  tools/perf/Documentation/perf-record.txt   |   4 ++
>  tools/perf/Makefile.perf   |   4 +-
>  tools/perf/builtin-record.c|   4 +-
>  tools/perf/builtin-sched.c |  17 -
>  tools/perf/util/probe-event.c  | 105 
> +++--
>  tools/perf/util/symbol-elf.c   |   6 ++
>  11 files changed, 108 insertions(+), 47 deletions(-)

Pulled, thanks a lot Arnaldo!

JFYI, I noticed these new warnings in the build log, we should probably take 
care 
of these out of sync headers eventually:

 Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
 Warning: arch/x86/include/uapi/asm/vmx.h differs from kernel
 Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel
 Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel

... but it's not a showstopper.

Thanks,

Ingo


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

2017-01-04 Thread Ingo Molnar

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual, news about it:
> 
> Has two new targets, debian:experimental-x-mipsel and
> debian:experimental-x-arm64.
> 
> Those use debian's multi-arch packages allowing cross building more than with
> the other crossbuild containers.
> 
> This still doesn't generate a full featured tool, as there are some buggy
> multi-arch packages, such as the devel packages for perl, gtk2, etc.
> 
> The following changes since commit 3705b97505bcbf6440f38119c0e7d6058f585b54:
> 
>   Merge tag 'perf-urgent-for-mingo-20161222' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2016-12-23 20:23:29 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo-4.10-20170104
> 
> for you to fetch changes up to 8a937a25a7e3c19d5fb3f9d92f605cf5fda219d8:
> 
>   perf probe: Fix to probe on gcc generated symbols for offline kernel 
> (2017-01-04 11:44:22 -0300)
> 
> 
> perf/urgent fixes and one improvement:
> 
> Fixes:
> 
> - Fix prev/next_prio formatting for deadline tasks in libtraceevent (Daniel 
> Bristot de Oliveira)
> 
> - Robustify reading of build-ids from /sys/kernel/note (Arnaldo Carvalho de 
> Melo)
> 
> - Fix building some sample/bpf in Alpine Linux 3.4 (Arnaldo Carvalho de Melo)
> 
> - Fix 'make install-bin' to install libtraceevent plugins (Arnaldo Carvalho 
> de Melo)
> 
> - Fix 'perf record --switch-output' documentation and comment (Jiri Olsa)
> 
> - 'perf probe' fixes for cross arch probing (Masami Hiramatsu)
> 
> Improvement:
> 
> - Show total scheduling time in 'perf sched timehist' (Namhyumg Kim)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Arnaldo Carvalho de Melo (4):
>   samples/bpf sock_example: Avoid getting ethhdr from two includes
>   samples/bpf trace_output_user: Remove duplicate sys/ioctl.h include
>   perf tools: Install tools/lib/traceevent plugins with install-bin
>   perf symbols: Robustify reading of build-id from sysfs
> 
> Daniel Bristot de Oliveira (1):
>   tools lib traceevent: Fix prev/next_prio for deadline tasks
> 
> Jiri Olsa (3):
>   tools lib subcmd: Add OPT_STRING_OPTARG_SET option
>   perf record: Make __record_options static
>   perf record: Fix --switch-output documentation and comment
> 
> Masami Hiramatsu (3):
>   perf probe: Fix to get correct modname from elf header
>   perf probe: Fix --funcs to show correct symbols for offline module
>   perf probe: Fix to probe on gcc generated symbols for offline kernel
> 
> Namhyung Kim (1):
>   perf sched timehist: Show total scheduling time
> 
>  samples/bpf/sock_example.h |   2 +-
>  samples/bpf/trace_output_user.c|   1 -
>  tools/lib/subcmd/parse-options.c   |   3 +
>  tools/lib/subcmd/parse-options.h   |   5 ++
>  tools/lib/traceevent/plugin_sched_switch.c |   4 +-
>  tools/perf/Documentation/perf-record.txt   |   4 ++
>  tools/perf/Makefile.perf   |   4 +-
>  tools/perf/builtin-record.c|   4 +-
>  tools/perf/builtin-sched.c |  17 -
>  tools/perf/util/probe-event.c  | 105 
> +++--
>  tools/perf/util/symbol-elf.c   |   6 ++
>  11 files changed, 108 insertions(+), 47 deletions(-)

Pulled, thanks a lot Arnaldo!

JFYI, I noticed these new warnings in the build log, we should probably take 
care 
of these out of sync headers eventually:

 Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
 Warning: arch/x86/include/uapi/asm/vmx.h differs from kernel
 Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel
 Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel

... but it's not a showstopper.

Thanks,

Ingo


[PATCH] staging: wilc1000: Connect to highest RSSI value for required SSID

2017-01-04 Thread Aditya Shankar
Connect to the highest rssi with the required SSID in the shadow
table if the connection criteria is based only on the SSID.
For the first matching SSID, an index to the table is saved.
Later the index is updated if matching SSID has a higher
RSSI value than the last saved index.

However if decision is made based on BSSID, there is only one match
in the table and corresponding index is used.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index c1a24f7..32206b8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -665,6 +665,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
 {
s32 s32Error = 0;
u32 i;
+   u32 sel_bssi_idx = last_scanned_cnt + 1;
u8 u8security = NO_ENCRYPT;
enum AUTHTYPE tenuAuth_type = ANY;
 
@@ -688,18 +689,25 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
memcmp(last_scanned_shadow[i].ssid,
   sme->ssid,
   sme->ssid_len) == 0) {
-   if (!sme->bssid)
-   break;
-   else
+   if (!sme->bssid) {
+   if (sel_bssi_idx == (last_scanned_cnt + 1))
+   sel_bssi_idx = i;
+   else if (last_scanned_shadow[i].rssi >
+last_scanned_shadow[sel_bssi_idx].rssi)
+   sel_bssi_idx = i;
+   } else {
if (memcmp(last_scanned_shadow[i].bssid,
   sme->bssid,
-  ETH_ALEN) == 0)
+  ETH_ALEN) == 0){
+   sel_bssi_idx = i;
break;
+   }
+   }
}
}
 
-   if (i < last_scanned_cnt) {
-   pstrNetworkInfo = _scanned_shadow[i];
+   if (sel_bssi_idx < last_scanned_cnt) {
+   pstrNetworkInfo = _scanned_shadow[sel_bssi_idx];
} else {
s32Error = -ENOENT;
wilc_connecting = 0;
-- 
2.7.4



[PATCH] staging: wilc1000: Connect to highest RSSI value for required SSID

2017-01-04 Thread Aditya Shankar
Connect to the highest rssi with the required SSID in the shadow
table if the connection criteria is based only on the SSID.
For the first matching SSID, an index to the table is saved.
Later the index is updated if matching SSID has a higher
RSSI value than the last saved index.

However if decision is made based on BSSID, there is only one match
in the table and corresponding index is used.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index c1a24f7..32206b8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -665,6 +665,7 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
 {
s32 s32Error = 0;
u32 i;
+   u32 sel_bssi_idx = last_scanned_cnt + 1;
u8 u8security = NO_ENCRYPT;
enum AUTHTYPE tenuAuth_type = ANY;
 
@@ -688,18 +689,25 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
memcmp(last_scanned_shadow[i].ssid,
   sme->ssid,
   sme->ssid_len) == 0) {
-   if (!sme->bssid)
-   break;
-   else
+   if (!sme->bssid) {
+   if (sel_bssi_idx == (last_scanned_cnt + 1))
+   sel_bssi_idx = i;
+   else if (last_scanned_shadow[i].rssi >
+last_scanned_shadow[sel_bssi_idx].rssi)
+   sel_bssi_idx = i;
+   } else {
if (memcmp(last_scanned_shadow[i].bssid,
   sme->bssid,
-  ETH_ALEN) == 0)
+  ETH_ALEN) == 0){
+   sel_bssi_idx = i;
break;
+   }
+   }
}
}
 
-   if (i < last_scanned_cnt) {
-   pstrNetworkInfo = _scanned_shadow[i];
+   if (sel_bssi_idx < last_scanned_cnt) {
+   pstrNetworkInfo = _scanned_shadow[sel_bssi_idx];
} else {
s32Error = -ENOENT;
wilc_connecting = 0;
-- 
2.7.4



[PATCH] mailbox: constify mbox_chan_ops structures

2017-01-04 Thread Bhumika Goyal
Check for mbox_chan_ops structures that are only stored in the ops field
of a mbox_controller structure. This field is of type const struct
mbox_chan_ops *, so mbox_chan_ops structures having this property can be
declared as const.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
struct mbox_chan_ops i@p = {...};

@ok1@
identifier r1.i;
struct hi6220_mbox mbox;
struct slimpro_mbox ctx;
position p;
@@
(
mbox.controller.ops=@p
|
ctx.mb_ctrl.ops=@p
)

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct mbox_chan_ops i;

File size details:

   textdata bss dec hex filename
   2310 248   02558 9fe drivers/mailbox/hi6220-mailbox.o
   2366 192   02558 9fe drivers/mailbox/hi6220-mailbox.o

   1500 248   01748 6d4 mailbox/mailbox-xgene-slimpro.o
   1556 192   01748 6d4 mailbox/mailbox-xgene-slimpro.o

Signed-off-by: Bhumika Goyal 
---
 drivers/mailbox/hi6220-mailbox.c| 2 +-
 drivers/mailbox/mailbox-xgene-slimpro.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
index 613722d..519376d 100644
--- a/drivers/mailbox/hi6220-mailbox.c
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -221,7 +221,7 @@ static void hi6220_mbox_shutdown(struct mbox_chan *chan)
mbox->irq_map_chan[mchan->ack_irq] = NULL;
 }
 
-static struct mbox_chan_ops hi6220_mbox_ops = {
+static const struct mbox_chan_ops hi6220_mbox_ops = {
.send_data= hi6220_mbox_send_data,
.startup  = hi6220_mbox_startup,
.shutdown = hi6220_mbox_shutdown,
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
b/drivers/mailbox/mailbox-xgene-slimpro.c
index dd2afbc..a704016 100644
--- a/drivers/mailbox/mailbox-xgene-slimpro.c
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -174,7 +174,7 @@ static void slimpro_mbox_shutdown(struct mbox_chan *chan)
devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
 }
 
-static struct mbox_chan_ops slimpro_mbox_ops = {
+static const struct mbox_chan_ops slimpro_mbox_ops = {
.send_data = slimpro_mbox_send_data,
.startup = slimpro_mbox_startup,
.shutdown = slimpro_mbox_shutdown,
-- 
1.9.1



[PATCH] mailbox: constify mbox_chan_ops structures

2017-01-04 Thread Bhumika Goyal
Check for mbox_chan_ops structures that are only stored in the ops field
of a mbox_controller structure. This field is of type const struct
mbox_chan_ops *, so mbox_chan_ops structures having this property can be
declared as const.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
struct mbox_chan_ops i@p = {...};

@ok1@
identifier r1.i;
struct hi6220_mbox mbox;
struct slimpro_mbox ctx;
position p;
@@
(
mbox.controller.ops=@p
|
ctx.mb_ctrl.ops=@p
)

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct mbox_chan_ops i;

File size details:

   textdata bss dec hex filename
   2310 248   02558 9fe drivers/mailbox/hi6220-mailbox.o
   2366 192   02558 9fe drivers/mailbox/hi6220-mailbox.o

   1500 248   01748 6d4 mailbox/mailbox-xgene-slimpro.o
   1556 192   01748 6d4 mailbox/mailbox-xgene-slimpro.o

Signed-off-by: Bhumika Goyal 
---
 drivers/mailbox/hi6220-mailbox.c| 2 +-
 drivers/mailbox/mailbox-xgene-slimpro.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
index 613722d..519376d 100644
--- a/drivers/mailbox/hi6220-mailbox.c
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -221,7 +221,7 @@ static void hi6220_mbox_shutdown(struct mbox_chan *chan)
mbox->irq_map_chan[mchan->ack_irq] = NULL;
 }
 
-static struct mbox_chan_ops hi6220_mbox_ops = {
+static const struct mbox_chan_ops hi6220_mbox_ops = {
.send_data= hi6220_mbox_send_data,
.startup  = hi6220_mbox_startup,
.shutdown = hi6220_mbox_shutdown,
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
b/drivers/mailbox/mailbox-xgene-slimpro.c
index dd2afbc..a704016 100644
--- a/drivers/mailbox/mailbox-xgene-slimpro.c
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -174,7 +174,7 @@ static void slimpro_mbox_shutdown(struct mbox_chan *chan)
devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
 }
 
-static struct mbox_chan_ops slimpro_mbox_ops = {
+static const struct mbox_chan_ops slimpro_mbox_ops = {
.send_data = slimpro_mbox_send_data,
.startup = slimpro_mbox_startup,
.shutdown = slimpro_mbox_shutdown,
-- 
1.9.1



Re: [PATCH] mmc: dw_mmc: Fix some coding style

2017-01-04 Thread Ziyuan



On 01/05/2017 02:32 AM, Joe Perches wrote:

On Wed, 2017-01-04 at 20:52 +0800, Ziyuan Xu wrote:

Let's fix the warnings from checkpatch.pl:

- line over 80 characters;
- block comments should align the * on each Lines;
- statements not starting on a tabstop.

Signed-off-by: Ziyuan Xu 
---

  drivers/mmc/host/dw_mmc.c | 33 +
  1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c

[]

@@ -94,7 +94,8 @@ struct idmac_desc {
  
  	__le32		des1;	/* Buffer sizes */

  #define IDMAC_SET_BUFFER1_SIZE(d, s) \
-   ((d)->des1 = ((d)->des1 & cpu_to_le32(0x03ffe000)) | (cpu_to_le32((s) & 
0x1fff)))
+   ((d)->des1 = ((d)->des1 & cpu_to_le32(0x03ffe000)) | \
+(cpu_to_le32((s) & 0x1fff)))

Please look to improve code rather than just shut up
the brainless checkpatch script.

If this is really valuable, it'd probably be better as
an inline function, or as it's only used once, just
as direct code in that one place.


Fine, I get it. Thanks for the advice.:-)



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html








Re: [PATCH] mmc: dw_mmc: Fix some coding style

2017-01-04 Thread Ziyuan



On 01/05/2017 02:32 AM, Joe Perches wrote:

On Wed, 2017-01-04 at 20:52 +0800, Ziyuan Xu wrote:

Let's fix the warnings from checkpatch.pl:

- line over 80 characters;
- block comments should align the * on each Lines;
- statements not starting on a tabstop.

Signed-off-by: Ziyuan Xu 
---

  drivers/mmc/host/dw_mmc.c | 33 +
  1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c

[]

@@ -94,7 +94,8 @@ struct idmac_desc {
  
  	__le32		des1;	/* Buffer sizes */

  #define IDMAC_SET_BUFFER1_SIZE(d, s) \
-   ((d)->des1 = ((d)->des1 & cpu_to_le32(0x03ffe000)) | (cpu_to_le32((s) & 
0x1fff)))
+   ((d)->des1 = ((d)->des1 & cpu_to_le32(0x03ffe000)) | \
+(cpu_to_le32((s) & 0x1fff)))

Please look to improve code rather than just shut up
the brainless checkpatch script.

If this is really valuable, it'd probably be better as
an inline function, or as it's only used once, just
as direct code in that one place.


Fine, I get it. Thanks for the advice.:-)



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html








Re: Doubt about push_dl_task() / find_lock_later_rq()

2017-01-04 Thread luca abeni
On Wed, 4 Jan 2017 15:49:35 +0100
luca abeni  wrote:

> Hi all,
> 
> trying to debug a reclaiming issue discovered by Daniel, I find myself
> confused by the push logic... Maybe I am misunderstanding something
> very obvious, so I ask here:
> 
> - push_dl_task() selects a task to be pushed, and then searches for a
>   runqueue to push the task to by calling find_lock_later_rq()
> - if I understand well, find_lock_later_rq() checks all the candidate
>   runqueues for pushing, and then compares the deadline of the task
>   with "dl.earliest_dl.curr" of the candidate runqueue, to check if
>   pushing the task there makes sense or not
> - now, my understanding is that in order to implement gEDF task T must
>   be pushed on CPU C if the deadline of T is smaller than the earliest
>   deadline of tasks on C... That is to say, the deadline of T must be
>   smaller than the deadline of the task that is currently executing on
>   C... No?
> - But as far as I understand "dl.earliest_dl.curr" is the earliest
>   deadline of _pushable_ tasks that are on the remote runqueue...

So, after re-reading the code I now see that my understanding here was
wrong: "dl.earliest_dl.curr" is really supposed to be the deadline of
the earliest deadline task on the runqueue... So, if I do not play
with affinities it should be the deadline of the task that is currently
executing on that CPU.
So, everything is fine.


I was confused by the fact that in some cases I saw
rq->dl.earliest_dl.curr != rq->curr->dl.deadline

I still do not understand how this can happen (I am not changing tasks
affinities), and I am investigating this.


Thanks,
Luca

> That
>   is to say, "earliest_dl.curr" does not consider the deadline of the
>   task currently executing on the remote runqueue
> - So, it seems to me that tasks are sometimes pushed to other
> runqueues even if they have a deadline that is not smaller than the
> deadline of the task executing on the "target" runqueue (so, a task
> is pushed but not immediately scheduled for execution). Is this
> correct? What is the logic behind this behaviour?
> I would be tempted to say that the correct check is not
>   dl_time_before(task->dl.deadline,
> later_rq->dl.earliest_dl.curr) (as it is now in
> find_lock_later_rq()), but dl_time_before(task->dl.deadline,
> later_rq->curr->dl.deadline) This, in my view, would migrate a task
> only when it is going to preempt the current of the remote runqueue.
> What am I missing?
> 
> 
>   Thanks,
>   Luca


Re: Doubt about push_dl_task() / find_lock_later_rq()

2017-01-04 Thread luca abeni
On Wed, 4 Jan 2017 15:49:35 +0100
luca abeni  wrote:

> Hi all,
> 
> trying to debug a reclaiming issue discovered by Daniel, I find myself
> confused by the push logic... Maybe I am misunderstanding something
> very obvious, so I ask here:
> 
> - push_dl_task() selects a task to be pushed, and then searches for a
>   runqueue to push the task to by calling find_lock_later_rq()
> - if I understand well, find_lock_later_rq() checks all the candidate
>   runqueues for pushing, and then compares the deadline of the task
>   with "dl.earliest_dl.curr" of the candidate runqueue, to check if
>   pushing the task there makes sense or not
> - now, my understanding is that in order to implement gEDF task T must
>   be pushed on CPU C if the deadline of T is smaller than the earliest
>   deadline of tasks on C... That is to say, the deadline of T must be
>   smaller than the deadline of the task that is currently executing on
>   C... No?
> - But as far as I understand "dl.earliest_dl.curr" is the earliest
>   deadline of _pushable_ tasks that are on the remote runqueue...

So, after re-reading the code I now see that my understanding here was
wrong: "dl.earliest_dl.curr" is really supposed to be the deadline of
the earliest deadline task on the runqueue... So, if I do not play
with affinities it should be the deadline of the task that is currently
executing on that CPU.
So, everything is fine.


I was confused by the fact that in some cases I saw
rq->dl.earliest_dl.curr != rq->curr->dl.deadline

I still do not understand how this can happen (I am not changing tasks
affinities), and I am investigating this.


Thanks,
Luca

> That
>   is to say, "earliest_dl.curr" does not consider the deadline of the
>   task currently executing on the remote runqueue
> - So, it seems to me that tasks are sometimes pushed to other
> runqueues even if they have a deadline that is not smaller than the
> deadline of the task executing on the "target" runqueue (so, a task
> is pushed but not immediately scheduled for execution). Is this
> correct? What is the logic behind this behaviour?
> I would be tempted to say that the correct check is not
>   dl_time_before(task->dl.deadline,
> later_rq->dl.earliest_dl.curr) (as it is now in
> find_lock_later_rq()), but dl_time_before(task->dl.deadline,
> later_rq->curr->dl.deadline) This, in my view, would migrate a task
> only when it is going to preempt the current of the remote runqueue.
> What am I missing?
> 
> 
>   Thanks,
>   Luca


Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

2017-01-04 Thread zhangyi (F)

On 2017/1/5 7:35, Theodore Ts'o wrote:
> 
> So how exactly how did we get into this state?  When we read the inode
> into memory, if i_nlink is zero, we declare the file system as
> corrupted immediately.
> 
> So I assume this is happening the on-disk i_links_count (which is read
> into inode->i_nlink) was too low.  So I think the way we should be
> handling this is in unlink and rename, before we let i_nlink drop to
> zero, we need to check to see if there are other dcache entries
> pointing at the inode.  If so, we need to call ext4_error(), and in
> the errors=continue case, return EFSCORRUPTED (aka EUCLEAN).
> 

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3662,6 +3662,11 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
}

if (new.inode) {
+   if (new.inode->i_nlink == 0) {
+   ext4_warning_inode(new.inode, "Removing file '%.*s' 
with no links",
+  new.dentry->d_name.len, 
new.dentry->d_name.name);
+   set_nlink(new.inode, 1);
+   }
ext4_dec_count(handle, new.inode);
new.inode->i_ctime = ext4_current_time(new.inode);
}

Because the filesystem have many errors, and the reason of i_nlink becomes zero 
is unknown,
the on-disk i_links_count was too low may be one reason.  I think we can add 
i_nlink check in
ext4_rename just like ext4_unlink did, it can avoid inversion under any case.







Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

2017-01-04 Thread zhangyi (F)

On 2017/1/5 7:35, Theodore Ts'o wrote:
> 
> So how exactly how did we get into this state?  When we read the inode
> into memory, if i_nlink is zero, we declare the file system as
> corrupted immediately.
> 
> So I assume this is happening the on-disk i_links_count (which is read
> into inode->i_nlink) was too low.  So I think the way we should be
> handling this is in unlink and rename, before we let i_nlink drop to
> zero, we need to check to see if there are other dcache entries
> pointing at the inode.  If so, we need to call ext4_error(), and in
> the errors=continue case, return EFSCORRUPTED (aka EUCLEAN).
> 

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3662,6 +3662,11 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
}

if (new.inode) {
+   if (new.inode->i_nlink == 0) {
+   ext4_warning_inode(new.inode, "Removing file '%.*s' 
with no links",
+  new.dentry->d_name.len, 
new.dentry->d_name.name);
+   set_nlink(new.inode, 1);
+   }
ext4_dec_count(handle, new.inode);
new.inode->i_ctime = ext4_current_time(new.inode);
}

Because the filesystem have many errors, and the reason of i_nlink becomes zero 
is unknown,
the on-disk i_links_count was too low may be one reason.  I think we can add 
i_nlink check in
ext4_rename just like ext4_unlink did, it can avoid inversion under any case.







Re: [RFC PATCH] ext4: convert swap_inode_data() over to use swap() on most of the fields

2017-01-04 Thread Jan Kara
On Wed 04-01-17 15:21:28, Jeff Layton wrote:
> On Wed, 2017-01-04 at 16:43 +0100, Jan Kara wrote:
> > On Tue 20-12-16 10:55:41, Jeff Layton wrote:
> > > 
> > > For some odd reason, it forces a byte-by-byte copy of each field. A
> > > plain old swap() on most of these fields would be more efficient. We
> > > do need to retain one memswap however as that field is an array.
> > > 
> > > Signed-off-by: Jeff Layton 
> > 
> > Looks good to me. You can add:
> > 
> > Reviewed-by: Jan Kara 
> > 
> > Honza
> > 
> 
> Thanks. Yeah, it's certainly nothing critical -- just something I
> noticed while looking at the i_version rework. Seems like it might be
> good to let soak in next for v4.11?

Yeah, it is definitely 4.11 material. I believe he'll pick up the patch to
his tree once he starts accumulating patches for the next merge window.

Honza
-- 
Jan Kara 
SUSE Labs, CR


Re: [RFC PATCH] ext4: convert swap_inode_data() over to use swap() on most of the fields

2017-01-04 Thread Jan Kara
On Wed 04-01-17 15:21:28, Jeff Layton wrote:
> On Wed, 2017-01-04 at 16:43 +0100, Jan Kara wrote:
> > On Tue 20-12-16 10:55:41, Jeff Layton wrote:
> > > 
> > > For some odd reason, it forces a byte-by-byte copy of each field. A
> > > plain old swap() on most of these fields would be more efficient. We
> > > do need to retain one memswap however as that field is an array.
> > > 
> > > Signed-off-by: Jeff Layton 
> > 
> > Looks good to me. You can add:
> > 
> > Reviewed-by: Jan Kara 
> > 
> > Honza
> > 
> 
> Thanks. Yeah, it's certainly nothing critical -- just something I
> noticed while looking at the i_version rework. Seems like it might be
> good to let soak in next for v4.11?

Yeah, it is definitely 4.11 material. I believe he'll pick up the patch to
his tree once he starts accumulating patches for the next merge window.

Honza
-- 
Jan Kara 
SUSE Labs, CR


Re: [PATCH v4 02/11] pwm: imx: remove ipg clock and enable per clock when required

2017-01-04 Thread Lukasz Majewski
Hi Boris,

> On Thu,  5 Jan 2017 00:36:45 +0100
> Lukasz Majewski  wrote:
> 
> > From: Boris Brezillon 
> 
> Can you keep Sascha as the author of this patch?

But the patch differs from the original one - and that change was sent
by you - so I assume that you made the modifications.

Apparently there are two authors and we only have one "Author"
field :-) so I took the patch as it was sent by you.

Is the rest of the series correct?

Best regards,
Łukasz Majewski

> 
> > 
> > The use of the ipg clock was introduced with commit 7b27c160c681
> > ("pwm: i.MX: fix clock lookup").
> > In the commit message it was claimed that the ipg clock is enabled
> > for register accesses. This is true for the ->config() callback,
> > but not for the ->set_enable() callback. Given that the ipg clock
> > is not consistently enabled for all register accesses we can assume
> > that either it is not required at all or that the current code does
> > not work. Remove the ipg clock code for now so that it's no longer
> > in the way of refactoring the driver.
> > 
> > In the other hand, the imx7 IP requires the peripheral clock to be
> > enabled before accessing its registers. Since ->config() can be
> > called when the PWM is disabled (in which case, the peripheral
> > clock is also disabled), we need to surround the imx->config() with
> > clk_prepare_enable(per_clk)/clk_disable_unprepare(per_clk) calls.
> > 
> > Note that the imx7 IP was working fine so far because the ipg clock
> > was actually pointing to the peripheral clock, which guaranteed
> > peripheral clock activation even when ->config() was called when
> > the PWM was disabled.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Boris Brezillon 
> > Cc: Philipp Zabel 
> > ---
> > Changes in v4:
> > - Enable per clk before calling imx->config()
> > 
> > Changes in v3:
> > - New patch
> > ---
> >  drivers/pwm/pwm-imx.c | 12 ++--
> >  1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index d600fd5..b1d1e50 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -49,7 +49,6 @@
> >  
> >  struct imx_chip {
> > struct clk  *clk_per;
> > -   struct clk  *clk_ipg;
> >  
> > void __iomem*mmio_base;
> >  
> > @@ -206,13 +205,13 @@ static int imx_pwm_config(struct pwm_chip
> > *chip, struct imx_chip *imx = to_imx_chip(chip);
> > int ret;
> >  
> > -   ret = clk_prepare_enable(imx->clk_ipg);
> > +   ret = clk_prepare_enable(imx->clk_per);
> > if (ret)
> > return ret;
> >  
> > ret = imx->config(chip, pwm, duty_ns, period_ns);
> >  
> > -   clk_disable_unprepare(imx->clk_ipg);
> > +   clk_disable_unprepare(imx->clk_per);
> >  
> > return ret;
> >  }
> > @@ -293,13 +292,6 @@ static int imx_pwm_probe(struct
> > platform_device *pdev) return PTR_ERR(imx->clk_per);
> > }
> >  
> > -   imx->clk_ipg = devm_clk_get(>dev, "ipg");
> > -   if (IS_ERR(imx->clk_ipg)) {
> > -   dev_err(>dev, "getting ipg clock failed with
> > %ld\n",
> > -   PTR_ERR(imx->clk_ipg));
> > -   return PTR_ERR(imx->clk_ipg);
> > -   }
> > -
> > imx->chip.ops = _pwm_ops;
> > imx->chip.dev = >dev;
> > imx->chip.base = -1;
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


Re: [PATCH v4 02/11] pwm: imx: remove ipg clock and enable per clock when required

2017-01-04 Thread Lukasz Majewski
Hi Boris,

> On Thu,  5 Jan 2017 00:36:45 +0100
> Lukasz Majewski  wrote:
> 
> > From: Boris Brezillon 
> 
> Can you keep Sascha as the author of this patch?

But the patch differs from the original one - and that change was sent
by you - so I assume that you made the modifications.

Apparently there are two authors and we only have one "Author"
field :-) so I took the patch as it was sent by you.

Is the rest of the series correct?

Best regards,
Łukasz Majewski

> 
> > 
> > The use of the ipg clock was introduced with commit 7b27c160c681
> > ("pwm: i.MX: fix clock lookup").
> > In the commit message it was claimed that the ipg clock is enabled
> > for register accesses. This is true for the ->config() callback,
> > but not for the ->set_enable() callback. Given that the ipg clock
> > is not consistently enabled for all register accesses we can assume
> > that either it is not required at all or that the current code does
> > not work. Remove the ipg clock code for now so that it's no longer
> > in the way of refactoring the driver.
> > 
> > In the other hand, the imx7 IP requires the peripheral clock to be
> > enabled before accessing its registers. Since ->config() can be
> > called when the PWM is disabled (in which case, the peripheral
> > clock is also disabled), we need to surround the imx->config() with
> > clk_prepare_enable(per_clk)/clk_disable_unprepare(per_clk) calls.
> > 
> > Note that the imx7 IP was working fine so far because the ipg clock
> > was actually pointing to the peripheral clock, which guaranteed
> > peripheral clock activation even when ->config() was called when
> > the PWM was disabled.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Boris Brezillon 
> > Cc: Philipp Zabel 
> > ---
> > Changes in v4:
> > - Enable per clk before calling imx->config()
> > 
> > Changes in v3:
> > - New patch
> > ---
> >  drivers/pwm/pwm-imx.c | 12 ++--
> >  1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index d600fd5..b1d1e50 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -49,7 +49,6 @@
> >  
> >  struct imx_chip {
> > struct clk  *clk_per;
> > -   struct clk  *clk_ipg;
> >  
> > void __iomem*mmio_base;
> >  
> > @@ -206,13 +205,13 @@ static int imx_pwm_config(struct pwm_chip
> > *chip, struct imx_chip *imx = to_imx_chip(chip);
> > int ret;
> >  
> > -   ret = clk_prepare_enable(imx->clk_ipg);
> > +   ret = clk_prepare_enable(imx->clk_per);
> > if (ret)
> > return ret;
> >  
> > ret = imx->config(chip, pwm, duty_ns, period_ns);
> >  
> > -   clk_disable_unprepare(imx->clk_ipg);
> > +   clk_disable_unprepare(imx->clk_per);
> >  
> > return ret;
> >  }
> > @@ -293,13 +292,6 @@ static int imx_pwm_probe(struct
> > platform_device *pdev) return PTR_ERR(imx->clk_per);
> > }
> >  
> > -   imx->clk_ipg = devm_clk_get(>dev, "ipg");
> > -   if (IS_ERR(imx->clk_ipg)) {
> > -   dev_err(>dev, "getting ipg clock failed with
> > %ld\n",
> > -   PTR_ERR(imx->clk_ipg));
> > -   return PTR_ERR(imx->clk_ipg);
> > -   }
> > -
> > imx->chip.ops = _pwm_ops;
> > imx->chip.dev = >dev;
> > imx->chip.base = -1;
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


[PATCH v4] mmc: dw_mmc: force setup bus if active slots exist

2017-01-04 Thread Ziyuan Xu
It's necessary to setup bus if any slots are present.
- update clock after ctrl reset
- if the host has genpd node, we can guarantee the clock is available
before starting request. Otherwies, the clock register is reset once
power off the pd, and host can't output the active clock during
communication.

fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback")
Reported-by: Randy Li 
Signed-off-by: Ziyuan Xu 

---
Hi guys,

I found a similar issue on rk3399 platform, which has a genpd node for
SD card host. Power off-on pd will reset the registers to a default
value (ie. CLKENA), so that the host can't output the active clock
during communication.

So we need to setup bus in rpm resume. It also wraps the update clock
behaviour which I did in V3.

Thanks,
Ziyuan Xu


Changes in v4:
- update commit message
- fix SD host rpm resume can't work

Changes in v3:
- only reset host with active slot.

Changes in v2:
- update the commit message
- use dw_mci_reset instead of dw_mci_ctrl_reset

 drivers/mmc/host/dw_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b44306b..b6053b3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3354,10 +3354,10 @@ int dw_mci_runtime_resume(struct device *dev)
 
if (!slot)
continue;
-   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
+   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER)
dw_mci_set_ios(slot->mmc, >mmc->ios);
-   dw_mci_setup_bus(slot, true);
-   }
+   /* Force setup bus to guarantee available clock output */
+   dw_mci_setup_bus(slot, true);
}
 
/* Now that slots are all setup, we can enable card detect */
-- 
2.7.4




[PATCH v4] mmc: dw_mmc: force setup bus if active slots exist

2017-01-04 Thread Ziyuan Xu
It's necessary to setup bus if any slots are present.
- update clock after ctrl reset
- if the host has genpd node, we can guarantee the clock is available
before starting request. Otherwies, the clock register is reset once
power off the pd, and host can't output the active clock during
communication.

fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback")
Reported-by: Randy Li 
Signed-off-by: Ziyuan Xu 

---
Hi guys,

I found a similar issue on rk3399 platform, which has a genpd node for
SD card host. Power off-on pd will reset the registers to a default
value (ie. CLKENA), so that the host can't output the active clock
during communication.

So we need to setup bus in rpm resume. It also wraps the update clock
behaviour which I did in V3.

Thanks,
Ziyuan Xu


Changes in v4:
- update commit message
- fix SD host rpm resume can't work

Changes in v3:
- only reset host with active slot.

Changes in v2:
- update the commit message
- use dw_mci_reset instead of dw_mci_ctrl_reset

 drivers/mmc/host/dw_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b44306b..b6053b3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3354,10 +3354,10 @@ int dw_mci_runtime_resume(struct device *dev)
 
if (!slot)
continue;
-   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
+   if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER)
dw_mci_set_ios(slot->mmc, >mmc->ios);
-   dw_mci_setup_bus(slot, true);
-   }
+   /* Force setup bus to guarantee available clock output */
+   dw_mci_setup_bus(slot, true);
}
 
/* Now that slots are all setup, we can enable card detect */
-- 
2.7.4




Re: [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs

2017-01-04 Thread Chen-Yu Tsai
On Wed, Jan 4, 2017 at 7:56 PM, Lee Jones  wrote:
> On Wed, 04 Jan 2017, Lee Jones wrote:
>
>> On Mon, 02 Jan 2017, Quentin Schulz wrote:
>>
>> > This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
>> > AXP221 and AXP223 MFD.
>> >
>> > Signed-off-by: Quentin Schulz 
>> > ---
>> >  drivers/mfd/axp20x.c | 9 +
>> >  1 file changed, 9 insertions(+)
>>
>> Applied, thanks.
>
> Whoops, wrong key combo!  Should have been:
>
> For my own reference:
>   Acked-for-MFD-by: Lee Jones 

Acked-by: Chen-Yu Tsai 

>
>> > diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> > index a33db5e..31a84d81 100644
>> > --- a/drivers/mfd/axp20x.c
>> > +++ b/drivers/mfd/axp20x.c
>> > @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
>> > }, {
>> > .name   = "axp20x-regulator",
>> > }, {
>> > +   .name   = "axp20x-adc",
>> > +   .of_compatible  = "x-powers,axp209-adc",
>> > +   }, {
>> > .name   = "axp20x-ac-power-supply",
>> > .of_compatible  = "x-powers,axp202-ac-power-supply",
>> > .num_resources  = ARRAY_SIZE(axp20x_ac_power_supply_resources),
>> > @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
>> > }, {
>> > .name   = "axp20x-regulator",
>> > }, {
>> > +   .name   = "axp20x-adc",
>> > +   .of_compatible  = "x-powers,axp221-adc"
>> > +   }, {
>> > .name   = "axp20x-usb-power-supply",
>> > .of_compatible  = "x-powers,axp221-usb-power-supply",
>> > .num_resources  = 
>> > ARRAY_SIZE(axp22x_usb_power_supply_resources),
>> > @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
>> > .num_resources  = ARRAY_SIZE(axp22x_pek_resources),
>> > .resources  = axp22x_pek_resources,
>> > }, {
>> > +   .name   = "axp20x-adc",
>> > +   .of_compatible  = "x-powers,axp221-adc"
>> > +   }, {
>> > .name   = "axp20x-regulator",
>> > }, {
>> > .name   = "axp20x-usb-power-supply",
>>
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 04/22] mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs

2017-01-04 Thread Chen-Yu Tsai
On Wed, Jan 4, 2017 at 7:56 PM, Lee Jones  wrote:
> On Wed, 04 Jan 2017, Lee Jones wrote:
>
>> On Mon, 02 Jan 2017, Quentin Schulz wrote:
>>
>> > This adds the AXP20X/AXP22x ADCs driver to the mfd cells of the AXP209,
>> > AXP221 and AXP223 MFD.
>> >
>> > Signed-off-by: Quentin Schulz 
>> > ---
>> >  drivers/mfd/axp20x.c | 9 +
>> >  1 file changed, 9 insertions(+)
>>
>> Applied, thanks.
>
> Whoops, wrong key combo!  Should have been:
>
> For my own reference:
>   Acked-for-MFD-by: Lee Jones 

Acked-by: Chen-Yu Tsai 

>
>> > diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> > index a33db5e..31a84d81 100644
>> > --- a/drivers/mfd/axp20x.c
>> > +++ b/drivers/mfd/axp20x.c
>> > @@ -582,6 +582,9 @@ static struct mfd_cell axp20x_cells[] = {
>> > }, {
>> > .name   = "axp20x-regulator",
>> > }, {
>> > +   .name   = "axp20x-adc",
>> > +   .of_compatible  = "x-powers,axp209-adc",
>> > +   }, {
>> > .name   = "axp20x-ac-power-supply",
>> > .of_compatible  = "x-powers,axp202-ac-power-supply",
>> > .num_resources  = ARRAY_SIZE(axp20x_ac_power_supply_resources),
>> > @@ -602,6 +605,9 @@ static struct mfd_cell axp221_cells[] = {
>> > }, {
>> > .name   = "axp20x-regulator",
>> > }, {
>> > +   .name   = "axp20x-adc",
>> > +   .of_compatible  = "x-powers,axp221-adc"
>> > +   }, {
>> > .name   = "axp20x-usb-power-supply",
>> > .of_compatible  = "x-powers,axp221-usb-power-supply",
>> > .num_resources  = 
>> > ARRAY_SIZE(axp22x_usb_power_supply_resources),
>> > @@ -615,6 +621,9 @@ static struct mfd_cell axp223_cells[] = {
>> > .num_resources  = ARRAY_SIZE(axp22x_pek_resources),
>> > .resources  = axp22x_pek_resources,
>> > }, {
>> > +   .name   = "axp20x-adc",
>> > +   .of_compatible  = "x-powers,axp221-adc"
>> > +   }, {
>> > .name   = "axp20x-regulator",
>> > }, {
>> > .name   = "axp20x-usb-power-supply",
>>
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v4 02/11] pwm: imx: remove ipg clock and enable per clock when required

2017-01-04 Thread Boris Brezillon
On Thu,  5 Jan 2017 00:36:45 +0100
Lukasz Majewski  wrote:

> From: Boris Brezillon 

Can you keep Sascha as the author of this patch?

> 
> The use of the ipg clock was introduced with commit 7b27c160c681
> ("pwm: i.MX: fix clock lookup").
> In the commit message it was claimed that the ipg clock is enabled for
> register accesses. This is true for the ->config() callback, but not
> for the ->set_enable() callback. Given that the ipg clock is not
> consistently enabled for all register accesses we can assume that either
> it is not required at all or that the current code does not work.
> Remove the ipg clock code for now so that it's no longer in the way of
> refactoring the driver.
> 
> In the other hand, the imx7 IP requires the peripheral clock to be
> enabled before accessing its registers. Since ->config() can be called
> when the PWM is disabled (in which case, the peripheral clock is also
> disabled), we need to surround the imx->config() with
> clk_prepare_enable(per_clk)/clk_disable_unprepare(per_clk) calls.
> 
> Note that the imx7 IP was working fine so far because the ipg clock was
> actually pointing to the peripheral clock, which guaranteed peripheral
> clock activation even when ->config() was called when the PWM was
> disabled.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Boris Brezillon 
> Cc: Philipp Zabel 
> ---
> Changes in v4:
> - Enable per clk before calling imx->config()
> 
> Changes in v3:
> - New patch
> ---
>  drivers/pwm/pwm-imx.c | 12 ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> index d600fd5..b1d1e50 100644
> --- a/drivers/pwm/pwm-imx.c
> +++ b/drivers/pwm/pwm-imx.c
> @@ -49,7 +49,6 @@
>  
>  struct imx_chip {
>   struct clk  *clk_per;
> - struct clk  *clk_ipg;
>  
>   void __iomem*mmio_base;
>  
> @@ -206,13 +205,13 @@ static int imx_pwm_config(struct pwm_chip *chip,
>   struct imx_chip *imx = to_imx_chip(chip);
>   int ret;
>  
> - ret = clk_prepare_enable(imx->clk_ipg);
> + ret = clk_prepare_enable(imx->clk_per);
>   if (ret)
>   return ret;
>  
>   ret = imx->config(chip, pwm, duty_ns, period_ns);
>  
> - clk_disable_unprepare(imx->clk_ipg);
> + clk_disable_unprepare(imx->clk_per);
>  
>   return ret;
>  }
> @@ -293,13 +292,6 @@ static int imx_pwm_probe(struct platform_device *pdev)
>   return PTR_ERR(imx->clk_per);
>   }
>  
> - imx->clk_ipg = devm_clk_get(>dev, "ipg");
> - if (IS_ERR(imx->clk_ipg)) {
> - dev_err(>dev, "getting ipg clock failed with %ld\n",
> - PTR_ERR(imx->clk_ipg));
> - return PTR_ERR(imx->clk_ipg);
> - }
> -
>   imx->chip.ops = _pwm_ops;
>   imx->chip.dev = >dev;
>   imx->chip.base = -1;



Re: [PATCH v4 02/11] pwm: imx: remove ipg clock and enable per clock when required

2017-01-04 Thread Boris Brezillon
On Thu,  5 Jan 2017 00:36:45 +0100
Lukasz Majewski  wrote:

> From: Boris Brezillon 

Can you keep Sascha as the author of this patch?

> 
> The use of the ipg clock was introduced with commit 7b27c160c681
> ("pwm: i.MX: fix clock lookup").
> In the commit message it was claimed that the ipg clock is enabled for
> register accesses. This is true for the ->config() callback, but not
> for the ->set_enable() callback. Given that the ipg clock is not
> consistently enabled for all register accesses we can assume that either
> it is not required at all or that the current code does not work.
> Remove the ipg clock code for now so that it's no longer in the way of
> refactoring the driver.
> 
> In the other hand, the imx7 IP requires the peripheral clock to be
> enabled before accessing its registers. Since ->config() can be called
> when the PWM is disabled (in which case, the peripheral clock is also
> disabled), we need to surround the imx->config() with
> clk_prepare_enable(per_clk)/clk_disable_unprepare(per_clk) calls.
> 
> Note that the imx7 IP was working fine so far because the ipg clock was
> actually pointing to the peripheral clock, which guaranteed peripheral
> clock activation even when ->config() was called when the PWM was
> disabled.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Boris Brezillon 
> Cc: Philipp Zabel 
> ---
> Changes in v4:
> - Enable per clk before calling imx->config()
> 
> Changes in v3:
> - New patch
> ---
>  drivers/pwm/pwm-imx.c | 12 ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> index d600fd5..b1d1e50 100644
> --- a/drivers/pwm/pwm-imx.c
> +++ b/drivers/pwm/pwm-imx.c
> @@ -49,7 +49,6 @@
>  
>  struct imx_chip {
>   struct clk  *clk_per;
> - struct clk  *clk_ipg;
>  
>   void __iomem*mmio_base;
>  
> @@ -206,13 +205,13 @@ static int imx_pwm_config(struct pwm_chip *chip,
>   struct imx_chip *imx = to_imx_chip(chip);
>   int ret;
>  
> - ret = clk_prepare_enable(imx->clk_ipg);
> + ret = clk_prepare_enable(imx->clk_per);
>   if (ret)
>   return ret;
>  
>   ret = imx->config(chip, pwm, duty_ns, period_ns);
>  
> - clk_disable_unprepare(imx->clk_ipg);
> + clk_disable_unprepare(imx->clk_per);
>  
>   return ret;
>  }
> @@ -293,13 +292,6 @@ static int imx_pwm_probe(struct platform_device *pdev)
>   return PTR_ERR(imx->clk_per);
>   }
>  
> - imx->clk_ipg = devm_clk_get(>dev, "ipg");
> - if (IS_ERR(imx->clk_ipg)) {
> - dev_err(>dev, "getting ipg clock failed with %ld\n",
> - PTR_ERR(imx->clk_ipg));
> - return PTR_ERR(imx->clk_ipg);
> - }
> -
>   imx->chip.ops = _pwm_ops;
>   imx->chip.dev = >dev;
>   imx->chip.base = -1;



Re: [PATCH 05/22] ARM: dtsi: axp209: add AXP209 ADC subnode

2017-01-04 Thread Chen-Yu Tsai
On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
 wrote:
> X-Powers AXP209 PMIC has multiple ADCs, each one exposing data from the
> different power supplies connected to the PMIC.
>
> This adds the ADC subnode for AXP20X PMIC.
>
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/boot/dts/axp209.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
> index 675bb0f..2a4e8ee 100644
> --- a/arch/arm/boot/dts/axp209.dtsi
> +++ b/arch/arm/boot/dts/axp209.dtsi
> @@ -53,6 +53,11 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> +   axp209_adc: axp209_adc {

Node name should be generic. Please change it to "adc".

ChenYu

> +   compatible = "x-powers,axp209-adc";
> +   #io-channel-cells = <1>;
> +   };
> +
> axp_gpio: gpio {
> compatible = "x-powers,axp209-gpio";
> gpio-controller;
> --
> 2.9.3
>


Re: [PATCH 05/22] ARM: dtsi: axp209: add AXP209 ADC subnode

2017-01-04 Thread Chen-Yu Tsai
On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
 wrote:
> X-Powers AXP209 PMIC has multiple ADCs, each one exposing data from the
> different power supplies connected to the PMIC.
>
> This adds the ADC subnode for AXP20X PMIC.
>
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/boot/dts/axp209.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
> index 675bb0f..2a4e8ee 100644
> --- a/arch/arm/boot/dts/axp209.dtsi
> +++ b/arch/arm/boot/dts/axp209.dtsi
> @@ -53,6 +53,11 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> +   axp209_adc: axp209_adc {

Node name should be generic. Please change it to "adc".

ChenYu

> +   compatible = "x-powers,axp209-adc";
> +   #io-channel-cells = <1>;
> +   };
> +
> axp_gpio: gpio {
> compatible = "x-powers,axp209-gpio";
> gpio-controller;
> --
> 2.9.3
>


Re: [PATCH v6 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family

2017-01-04 Thread Shawn Guo
On Wed, Jan 04, 2017 at 07:48:13PM +0800, Baoyou Xie wrote:
> The ARMv8 zx2967 family (296718, 296716 etc) uses different value
> for controlling the power domain on/off registers, Choose the
> value depending on the compatible.
> 
> Multiple domains are prepared for the family, this patch prepares
> the common functions.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/soc/Kconfig |   1 +
>  drivers/soc/Makefile|   1 +
>  drivers/soc/zte/Kconfig |  13 
>  drivers/soc/zte/Makefile|   4 +
>  drivers/soc/zte/zx2967_pm_domains.c | 142 
> 
>  drivers/soc/zte/zx2967_pm_domains.h |  44 +++
>  6 files changed, 205 insertions(+)
>  create mode 100644 drivers/soc/zte/Kconfig
>  create mode 100644 drivers/soc/zte/Makefile
>  create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
>  create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f31bceb..f09023f 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
>  source "drivers/soc/ti/Kconfig"
>  source "drivers/soc/ux500/Kconfig"
>  source "drivers/soc/versatile/Kconfig"
> +source "drivers/soc/zte/Kconfig"
>  
>  endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 50c23d0..05eae52 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA)+= tegra/
>  obj-$(CONFIG_SOC_TI) += ti/
>  obj-$(CONFIG_ARCH_U8500) += ux500/
>  obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> +obj-$(CONFIG_ARCH_ZX)+= zte/
> diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
> new file mode 100644
> index 000..20bde38
> --- /dev/null
> +++ b/drivers/soc/zte/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# ZTE SoC drivers
> +#
> +menuconfig SOC_ZTE
> + bool "ZTE SoC driver support"
> +
> +if SOC_ZTE
> +
> +config ZX2967_PM_DOMAINS
> + bool "ZX2967 PM domains"
> + depends on PM_GENERIC_DOMAINS
> +
> +endif
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> new file mode 100644
> index 000..8a37f2f
> --- /dev/null
> +++ b/drivers/soc/zte/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# ZTE SOC drivers
> +#
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> diff --git a/drivers/soc/zte/zx2967_pm_domains.c 
> b/drivers/soc/zte/zx2967_pm_domains.c
> new file mode 100644
> index 000..f190a62
> --- /dev/null
> +++ b/drivers/soc/zte/zx2967_pm_domains.c
> @@ -0,0 +1,142 @@
> +/*
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie 
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "zx2967_pm_domains.h"
> +
> +#define PCU_DM_CLKEN(zpd)((zpd)->reg_offset[REG_CLKEN])
> +#define PCU_DM_ISOEN(zpd)((zpd)->reg_offset[REG_ISOEN])
> +#define PCU_DM_RSTEN(zpd)((zpd)->reg_offset[REG_RSTEN])
> +#define PCU_DM_PWREN(zpd)((zpd)->reg_offset[REG_PWREN])
> +#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
> +
> +static void __iomem *pcubase;
> +
> +int zx2967_power_on(struct generic_pm_domain *domain)

The function is now used only in this file, so it can be static.

> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
> + if (zpd->polarity == PWREN)
> + val |= BIT(zpd->bit);
> + else
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
> +
> + do {
> + udelay(1);
> + val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
> +& BIT(zpd->bit);
> + } while (--loop && !val);
> +
> + if (!loop) {
> + pr_err("Error: %s %s fail\n", __func__, domain->name);
> + return -EIO;
> + }
> +
> + val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + pr_debug("poweron %s\n", domain->name);
> +
> + return 0;
> +}
> +
> +int zx2967_power_off(struct generic_pm_domain *domain)

Ditto

Shawn

> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + 

Re: [PATCH v6 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family

2017-01-04 Thread Shawn Guo
On Wed, Jan 04, 2017 at 07:48:13PM +0800, Baoyou Xie wrote:
> The ARMv8 zx2967 family (296718, 296716 etc) uses different value
> for controlling the power domain on/off registers, Choose the
> value depending on the compatible.
> 
> Multiple domains are prepared for the family, this patch prepares
> the common functions.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/soc/Kconfig |   1 +
>  drivers/soc/Makefile|   1 +
>  drivers/soc/zte/Kconfig |  13 
>  drivers/soc/zte/Makefile|   4 +
>  drivers/soc/zte/zx2967_pm_domains.c | 142 
> 
>  drivers/soc/zte/zx2967_pm_domains.h |  44 +++
>  6 files changed, 205 insertions(+)
>  create mode 100644 drivers/soc/zte/Kconfig
>  create mode 100644 drivers/soc/zte/Makefile
>  create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
>  create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f31bceb..f09023f 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
>  source "drivers/soc/ti/Kconfig"
>  source "drivers/soc/ux500/Kconfig"
>  source "drivers/soc/versatile/Kconfig"
> +source "drivers/soc/zte/Kconfig"
>  
>  endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 50c23d0..05eae52 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA)+= tegra/
>  obj-$(CONFIG_SOC_TI) += ti/
>  obj-$(CONFIG_ARCH_U8500) += ux500/
>  obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> +obj-$(CONFIG_ARCH_ZX)+= zte/
> diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
> new file mode 100644
> index 000..20bde38
> --- /dev/null
> +++ b/drivers/soc/zte/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# ZTE SoC drivers
> +#
> +menuconfig SOC_ZTE
> + bool "ZTE SoC driver support"
> +
> +if SOC_ZTE
> +
> +config ZX2967_PM_DOMAINS
> + bool "ZX2967 PM domains"
> + depends on PM_GENERIC_DOMAINS
> +
> +endif
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> new file mode 100644
> index 000..8a37f2f
> --- /dev/null
> +++ b/drivers/soc/zte/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# ZTE SOC drivers
> +#
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> diff --git a/drivers/soc/zte/zx2967_pm_domains.c 
> b/drivers/soc/zte/zx2967_pm_domains.c
> new file mode 100644
> index 000..f190a62
> --- /dev/null
> +++ b/drivers/soc/zte/zx2967_pm_domains.c
> @@ -0,0 +1,142 @@
> +/*
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie 
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "zx2967_pm_domains.h"
> +
> +#define PCU_DM_CLKEN(zpd)((zpd)->reg_offset[REG_CLKEN])
> +#define PCU_DM_ISOEN(zpd)((zpd)->reg_offset[REG_ISOEN])
> +#define PCU_DM_RSTEN(zpd)((zpd)->reg_offset[REG_RSTEN])
> +#define PCU_DM_PWREN(zpd)((zpd)->reg_offset[REG_PWREN])
> +#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
> +
> +static void __iomem *pcubase;
> +
> +int zx2967_power_on(struct generic_pm_domain *domain)

The function is now used only in this file, so it can be static.

> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
> + if (zpd->polarity == PWREN)
> + val |= BIT(zpd->bit);
> + else
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
> +
> + do {
> + udelay(1);
> + val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
> +& BIT(zpd->bit);
> + } while (--loop && !val);
> +
> + if (!loop) {
> + pr_err("Error: %s %s fail\n", __func__, domain->name);
> + return -EIO;
> + }
> +
> + val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + pr_debug("poweron %s\n", domain->name);
> +
> + return 0;
> +}
> +
> +int zx2967_power_off(struct generic_pm_domain *domain)

Ditto

Shawn

> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + 

Re: [PATCH] serial: 8250_lpss: Release Quark MSI vectors on exit

2017-01-04 Thread Jan Kiszka
On 2017-01-05 06:25, Christoph Hellwig wrote:
> On Wed, Jan 04, 2017 at 11:46:58PM +0100, Jan Kiszka wrote:
>>> I NAKed already third patch related to PCI managed resources (couple
>>> of those regarding to pci_irq_* API)/
>>>
>>
>> Ah, there are resources that are managed without being allocated
>> explicitly that way. Hmm, not very intuitive. Are MSI / MSI-X vectors
>> the only such cases?
> 
> MSI/MSI-X resources are not managed that way and an explicit call to
> pci_free_irq_vectors is required from the API standpoint.  It might not
> actually free memory in many cases, but it still is a symmetric API.
> 

Andy is referring to the following:
- pcim_enable_device registers pci_devres with the devres subsystem
- on device release, devres_release_all is invoked, and that calls
  pcim_release
- the latter will invoke pci_disable_msi and pci_disable_msix if any of
  them is enabled

The user will still call the same pci_msi_enable, pci_alloc_irq_vectors
etc., but they are now "magically" managed with pcim_enable_device being
used. Same for pci_request_region.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH v6 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-01-04 Thread Andrzej Hajda
On 05.01.2017 07:45, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Hoegeun Kwon 
> Tested-by: Chanwoo Choi 

Reviewed-by: Andrzej Hajda 

Regards
Andrzej




Re: [PATCH v6 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-01-04 Thread Andrzej Hajda
On 05.01.2017 07:45, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Hoegeun Kwon 
> Tested-by: Chanwoo Choi 

Reviewed-by: Andrzej Hajda 

Regards
Andrzej




Re: [PATCH] serial: 8250_lpss: Release Quark MSI vectors on exit

2017-01-04 Thread Jan Kiszka
On 2017-01-05 06:25, Christoph Hellwig wrote:
> On Wed, Jan 04, 2017 at 11:46:58PM +0100, Jan Kiszka wrote:
>>> I NAKed already third patch related to PCI managed resources (couple
>>> of those regarding to pci_irq_* API)/
>>>
>>
>> Ah, there are resources that are managed without being allocated
>> explicitly that way. Hmm, not very intuitive. Are MSI / MSI-X vectors
>> the only such cases?
> 
> MSI/MSI-X resources are not managed that way and an explicit call to
> pci_free_irq_vectors is required from the API standpoint.  It might not
> actually free memory in many cases, but it still is a symmetric API.
> 

Andy is referring to the following:
- pcim_enable_device registers pci_devres with the devres subsystem
- on device release, devres_release_all is invoked, and that calls
  pcim_release
- the latter will invoke pci_disable_msi and pci_disable_msix if any of
  them is enabled

The user will still call the same pci_msi_enable, pci_alloc_irq_vectors
etc., but they are now "magically" managed with pcim_enable_device being
used. Same for pci_request_region.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-01-04 Thread Andrzej Hajda
On 04.01.2017 15:44, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee 
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>  drivers/gpu/drm/panel/Makefile |   1 +
>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>> +
>>  4 files changed, 788 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> new file mode 100644
>> index 000..6879f51
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> @@ -0,0 +1,40 @@
>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>> +
>> +Required properties:
>> +  - compatible: "samsung,s6e3ha2"
>> +  - reg: the virtual channel number of a DSI peripheral
>> +  - vdd3-supply: I/O voltage supply
>> +  - vci-supply: voltage supply for analog circuits
>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>> +gpio pin (active high)
>> +
>> +The device node can contain one 'port' child node with one child
>> +'endpoint' node, according to the bindings defined in [1]. This
>> +node should describe panel's video bus.
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> + {
>> +...
>> +
>> +panel@0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <_reg>;
>> +vci-supply = <_reg>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>> +
>> +port {
>> +panel_in: endpoint {
>> +remote-endpoint = <_out>;
> As I said previously, it makes no sense to have a graph to dsi_out it is 
> simply the parent node.

The problem is that exynos_dsi requires presence of endpoint node, when
it was written the policy was that graphs must be always present.
DSI reads from this node samsung,burst-clock-frequency and
samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:

> dsi_0: dsi@11C8 {
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>  
> port@1 {
> reg = <1>;
>
> dsi_out: endpoint {
> remote-endpoint = <_in>;
> samsung,burst-clock-frequency
> = <5>;
> samsung,esc-clock-frequency =
> <2000>;
> };
> };
> };
> 
> panel@0 {
> ...
> port {
> dsi_in: endpoint {
> remote-endpoint = <_out>;
> };
> };
> };
> };

However, DSI driver does not use remote-endpoint property, it is here
only to fulfill of_graph policy.
So if something like below is acceptable, we can get rid of port node in
panel:

> dsi_0: dsi@11C8 {
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>  
> port@1 {
> reg = <1>;
>
> dsi_out: endpoint {
> samsung,burst-clock-frequency
> = <5>;
> samsung,esc-clock-frequency =
> <2000>;
> };
> };
> };
> 
> panel@0 {
> ...
> };
> };

What do you think?

Other solution is to move problematic properties somewhere else, but
this require change of bindings.
Anyway I would be glad to remove port nodes in other samsung panels:
s6e8aa0, ld9040.

Regards
Andrzej



Re: [PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-01-04 Thread Andrzej Hajda
On 04.01.2017 15:44, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee 
>> Signed-off-by: Hyungwon Hwang 
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>  drivers/gpu/drm/panel/Makefile |   1 +
>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>> +
>>  4 files changed, 788 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> new file mode 100644
>> index 000..6879f51
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>> @@ -0,0 +1,40 @@
>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>> +
>> +Required properties:
>> +  - compatible: "samsung,s6e3ha2"
>> +  - reg: the virtual channel number of a DSI peripheral
>> +  - vdd3-supply: I/O voltage supply
>> +  - vci-supply: voltage supply for analog circuits
>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>> +gpio pin (active high)
>> +
>> +The device node can contain one 'port' child node with one child
>> +'endpoint' node, according to the bindings defined in [1]. This
>> +node should describe panel's video bus.
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> + {
>> +...
>> +
>> +panel@0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <_reg>;
>> +vci-supply = <_reg>;
>> +reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>> +
>> +port {
>> +panel_in: endpoint {
>> +remote-endpoint = <_out>;
> As I said previously, it makes no sense to have a graph to dsi_out it is 
> simply the parent node.

The problem is that exynos_dsi requires presence of endpoint node, when
it was written the policy was that graphs must be always present.
DSI reads from this node samsung,burst-clock-frequency and
samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:

> dsi_0: dsi@11C8 {
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>  
> port@1 {
> reg = <1>;
>
> dsi_out: endpoint {
> remote-endpoint = <_in>;
> samsung,burst-clock-frequency
> = <5>;
> samsung,esc-clock-frequency =
> <2000>;
> };
> };
> };
> 
> panel@0 {
> ...
> port {
> dsi_in: endpoint {
> remote-endpoint = <_out>;
> };
> };
> };
> };

However, DSI driver does not use remote-endpoint property, it is here
only to fulfill of_graph policy.
So if something like below is acceptable, we can get rid of port node in
panel:

> dsi_0: dsi@11C8 {
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>  
> port@1 {
> reg = <1>;
>
> dsi_out: endpoint {
> samsung,burst-clock-frequency
> = <5>;
> samsung,esc-clock-frequency =
> <2000>;
> };
> };
> };
> 
> panel@0 {
> ...
> };
> };

What do you think?

Other solution is to move problematic properties somewhere else, but
this require change of bindings.
Anyway I would be glad to remove port nodes in other samsung panels:
s6e8aa0, ld9040.

Regards
Andrzej



[PATCH v11 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

2017-01-04 Thread Peter Chen
Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
2.7.4



[PATCH v11 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

2017-01-04 Thread Peter Chen
Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
2.7.4



Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

2017-01-04 Thread Minchan Kim
Hi,

On Thu, Jan 05, 2017 at 09:33:55AM +0800, Huang, Ying wrote:
> Hi, Minchan,
> 
> Minchan Kim  writes:
> [snip]
> >
> > The patchset has used several techniqueus to reduce lock contention, for 
> > example,
> > batching alloc/free, fine-grained lock and cluster distribution to avoid 
> > cache
> > false-sharing. Each items has different complexity and benefits so could you
> > show the number for each step of pathchset? It would be better to include 
> > the
> > nubmer in each description. It helps how the patch is important when we 
> > consider
> > complexitiy of the patch.
> 
> Here is the test data.

Thanks!

> 
> We test the vm-scalability swap-w-seq test case with 32 processes on a
> Xeon E5 v3 system.  The swap device used is a RAM simulated PMEM
> (persistent memory) device.  To test the sequential swapping out, the
> test case created 32 processes, which sequentially allocate and write to
> the anonymous pages until the RAM and part of the swap device is used
> up.
> 
> The patchset is rebased on v4.9-rc8.  So the baseline performance is as
> follow,
> 
>   "vmstat.swap.so": 1428002,

What does it mean? vmstat.pswpout?

>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>  13.94,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>  13.75,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.swapcache_free.__remove_mapping.shrink_page_list":
>  7.05,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.page_swapcount.try_to_free_swap.swap_writepage":
>  7.03,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.__swap_duplicate.swap_duplicate.try_to_unmap_one.rmap_walk_anon":
>  7.02,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>  6.83,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.page_check_address_transhuge.page_referenced_one.rmap_walk_anon.rmap_walk":
>  0.81,

Numbers mean overhead percentage reported by perf?

> 
> >> Patch 1 is a clean up patch.
> >
> > Could it be separated patch?
> >
> >> Patch 2 creates a lock per cluster, this gives us a more fine graind lock
> >> that can be used for accessing swap_map, and not lock the whole
> >> swap device
> 
> After patch 2, the result is as follow,
> 
>   "vmstat.swap.so": 1481704,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>  27.53,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>  27.01,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.free_pcppages_bulk.drain_pages_zone.drain_pages.drain_local_pages":
>  1.03,
> 
> The swap out throughput is at the same level, but the lock contention on
> swap_info_struct->lock is eliminated.
> 
> >> Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
> >> the rate that we have to contende for the radix tree.
> >
> 
> After patch 3,
> 
>   "vmstat.swap.so": 2050097,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>  43.27,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_vma.handle_mm_fault":
>  4.84,
> 
> The swap out throughput is improved about ~43% compared with baseline.
> The lock contention on swap cache radix tree lock is eliminated.
> swap_info_struct->lock in get_swap_page() becomes the most heavy
> contended lock.

The numbers are great! Please include those into each patchset.
And I ask one more thing I said earlier about patch 2.

""
I hope you make three steps to review easier. You can create some functions like
swap_map_lock and cluster_lock which are wrapper functions just hold swap_lock.
It doesn't change anything performance pov but it clearly shows what kinds of 
lock
we should use in specific context.

Then, you can introduce more fine-graind lock in next patch and apply it into
those wrapper functions.
 
And last patch, you can adjust cluster distribution to avoid false-sharing.
And the description should include how it's bad in testing so it's worth.
""

It makes review more easier, I believe.

> 
> >
> >> Patch 4 eliminates unnecessary page allocation for read ahead.
> >
> > Could it be separated patch?
> >
> >> Patch 5-9 create a per cpu cache of the swap slots, so we don't have
> >> to contend on the swap device to get a swap slot or to release
> >> a swap slot.  And we allocate and release the swap slots
> >> in batches for better efficiency.
> 
> After patch 9,
> 
>   "vmstat.swap.so": 4170746,
>   
> 

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

2017-01-04 Thread Huang, Ying
Minchan Kim  writes:

> Hi,
>
> On Thu, Jan 05, 2017 at 09:33:55AM +0800, Huang, Ying wrote:
>> Hi, Minchan,
>> 
>> Minchan Kim  writes:
>> [snip]
>> >
>> > The patchset has used several techniqueus to reduce lock contention, for 
>> > example,
>> > batching alloc/free, fine-grained lock and cluster distribution to avoid 
>> > cache
>> > false-sharing. Each items has different complexity and benefits so could 
>> > you
>> > show the number for each step of pathchset? It would be better to include 
>> > the
>> > nubmer in each description. It helps how the patch is important when we 
>> > consider
>> > complexitiy of the patch.
>> 
>> Here is the test data.
>
> Thanks!
>
>> 
>> We test the vm-scalability swap-w-seq test case with 32 processes on a
>> Xeon E5 v3 system.  The swap device used is a RAM simulated PMEM
>> (persistent memory) device.  To test the sequential swapping out, the
>> test case created 32 processes, which sequentially allocate and write to
>> the anonymous pages until the RAM and part of the swap device is used
>> up.
>> 
>> The patchset is rebased on v4.9-rc8.  So the baseline performance is as
>> follow,
>> 
>>   "vmstat.swap.so": 1428002,
>
> What does it mean? vmstat.pswpout?

This is the average of swap.so column of /usr/bin/vmstat output.  We run
/usr/bin/vmstat with,

/usr/bin/vmstat -n 1

>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>>  13.94,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>> 13.75,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.swapcache_free.__remove_mapping.shrink_page_list":
>>  7.05,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.page_swapcount.try_to_free_swap.swap_writepage":
>>  7.03,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.__swap_duplicate.swap_duplicate.try_to_unmap_one.rmap_walk_anon":
>>  7.02,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>>  6.83,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.page_check_address_transhuge.page_referenced_one.rmap_walk_anon.rmap_walk":
>>  0.81,
>
> Numbers mean overhead percentage reported by perf?

Yes.
 
>> >> Patch 1 is a clean up patch.
>> >
>> > Could it be separated patch?
>> >
>> >> Patch 2 creates a lock per cluster, this gives us a more fine graind lock
>> >> that can be used for accessing swap_map, and not lock the whole
>> >> swap device
>> 
>> After patch 2, the result is as follow,
>> 
>>   "vmstat.swap.so": 1481704,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>>  27.53,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>> 27.01,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.free_pcppages_bulk.drain_pages_zone.drain_pages.drain_local_pages":
>>  1.03,
>> 
>> The swap out throughput is at the same level, but the lock contention on
>> swap_info_struct->lock is eliminated.
>> 
>> >> Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
>> >> the rate that we have to contende for the radix tree.
>> >
>> 
>> After patch 3,
>> 
>>   "vmstat.swap.so": 2050097,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>>  43.27,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_vma.handle_mm_fault":
>>  4.84,
>> 
>> The swap out throughput is improved about ~43% compared with baseline.
>> The lock contention on swap cache radix tree lock is eliminated.
>> swap_info_struct->lock in get_swap_page() becomes the most heavy
>> contended lock.
>
> The numbers are great! Please include those into each patchset.
> And I ask one more thing I said earlier about patch 2.
>
> ""
> I hope you make three steps to review easier. You can create some functions 
> like
> swap_map_lock and cluster_lock which are wrapper functions just hold 
> swap_lock.
> It doesn't change anything performance pov but it clearly shows what kinds of 
> lock
> we should use in specific context.
>
> Then, you can introduce more fine-graind lock in next patch and apply it into
> those wrapper functions.
>  
> And last patch, you can adjust cluster distribution to avoid false-sharing.
> And the description should include how it's bad in testing so it's worth.
> ""
>
> It makes review more easier, I believe.

Sorry, personally, I don't like this way to organize the patchset.  So
unless more people have this requirement, I still want to keep the
current way.

Best Regards,
Huang, Ying

>> 
>> >
>> >> Patch 4 eliminates 

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

2017-01-04 Thread Minchan Kim
Hi,

On Thu, Jan 05, 2017 at 09:33:55AM +0800, Huang, Ying wrote:
> Hi, Minchan,
> 
> Minchan Kim  writes:
> [snip]
> >
> > The patchset has used several techniqueus to reduce lock contention, for 
> > example,
> > batching alloc/free, fine-grained lock and cluster distribution to avoid 
> > cache
> > false-sharing. Each items has different complexity and benefits so could you
> > show the number for each step of pathchset? It would be better to include 
> > the
> > nubmer in each description. It helps how the patch is important when we 
> > consider
> > complexitiy of the patch.
> 
> Here is the test data.

Thanks!

> 
> We test the vm-scalability swap-w-seq test case with 32 processes on a
> Xeon E5 v3 system.  The swap device used is a RAM simulated PMEM
> (persistent memory) device.  To test the sequential swapping out, the
> test case created 32 processes, which sequentially allocate and write to
> the anonymous pages until the RAM and part of the swap device is used
> up.
> 
> The patchset is rebased on v4.9-rc8.  So the baseline performance is as
> follow,
> 
>   "vmstat.swap.so": 1428002,

What does it mean? vmstat.pswpout?

>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>  13.94,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>  13.75,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.swapcache_free.__remove_mapping.shrink_page_list":
>  7.05,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.page_swapcount.try_to_free_swap.swap_writepage":
>  7.03,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.__swap_duplicate.swap_duplicate.try_to_unmap_one.rmap_walk_anon":
>  7.02,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>  6.83,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.page_check_address_transhuge.page_referenced_one.rmap_walk_anon.rmap_walk":
>  0.81,

Numbers mean overhead percentage reported by perf?

> 
> >> Patch 1 is a clean up patch.
> >
> > Could it be separated patch?
> >
> >> Patch 2 creates a lock per cluster, this gives us a more fine graind lock
> >> that can be used for accessing swap_map, and not lock the whole
> >> swap device
> 
> After patch 2, the result is as follow,
> 
>   "vmstat.swap.so": 1481704,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>  27.53,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>  27.01,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.free_pcppages_bulk.drain_pages_zone.drain_pages.drain_local_pages":
>  1.03,
> 
> The swap out throughput is at the same level, but the lock contention on
> swap_info_struct->lock is eliminated.
> 
> >> Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
> >> the rate that we have to contende for the radix tree.
> >
> 
> After patch 3,
> 
>   "vmstat.swap.so": 2050097,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>  43.27,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_vma.handle_mm_fault":
>  4.84,
> 
> The swap out throughput is improved about ~43% compared with baseline.
> The lock contention on swap cache radix tree lock is eliminated.
> swap_info_struct->lock in get_swap_page() becomes the most heavy
> contended lock.

The numbers are great! Please include those into each patchset.
And I ask one more thing I said earlier about patch 2.

""
I hope you make three steps to review easier. You can create some functions like
swap_map_lock and cluster_lock which are wrapper functions just hold swap_lock.
It doesn't change anything performance pov but it clearly shows what kinds of 
lock
we should use in specific context.

Then, you can introduce more fine-graind lock in next patch and apply it into
those wrapper functions.
 
And last patch, you can adjust cluster distribution to avoid false-sharing.
And the description should include how it's bad in testing so it's worth.
""

It makes review more easier, I believe.

> 
> >
> >> Patch 4 eliminates unnecessary page allocation for read ahead.
> >
> > Could it be separated patch?
> >
> >> Patch 5-9 create a per cpu cache of the swap slots, so we don't have
> >> to contend on the swap device to get a swap slot or to release
> >> a swap slot.  And we allocate and release the swap slots
> >> in batches for better efficiency.
> 
> After patch 9,
> 
>   "vmstat.swap.so": 4170746,
>   
> 

Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations

2017-01-04 Thread Huang, Ying
Minchan Kim  writes:

> Hi,
>
> On Thu, Jan 05, 2017 at 09:33:55AM +0800, Huang, Ying wrote:
>> Hi, Minchan,
>> 
>> Minchan Kim  writes:
>> [snip]
>> >
>> > The patchset has used several techniqueus to reduce lock contention, for 
>> > example,
>> > batching alloc/free, fine-grained lock and cluster distribution to avoid 
>> > cache
>> > false-sharing. Each items has different complexity and benefits so could 
>> > you
>> > show the number for each step of pathchset? It would be better to include 
>> > the
>> > nubmer in each description. It helps how the patch is important when we 
>> > consider
>> > complexitiy of the patch.
>> 
>> Here is the test data.
>
> Thanks!
>
>> 
>> We test the vm-scalability swap-w-seq test case with 32 processes on a
>> Xeon E5 v3 system.  The swap device used is a RAM simulated PMEM
>> (persistent memory) device.  To test the sequential swapping out, the
>> test case created 32 processes, which sequentially allocate and write to
>> the anonymous pages until the RAM and part of the swap device is used
>> up.
>> 
>> The patchset is rebased on v4.9-rc8.  So the baseline performance is as
>> follow,
>> 
>>   "vmstat.swap.so": 1428002,
>
> What does it mean? vmstat.pswpout?

This is the average of swap.so column of /usr/bin/vmstat output.  We run
/usr/bin/vmstat with,

/usr/bin/vmstat -n 1

>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>>  13.94,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>> 13.75,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.swapcache_free.__remove_mapping.shrink_page_list":
>>  7.05,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swap_info_get.page_swapcount.try_to_free_swap.swap_writepage":
>>  7.03,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.__swap_duplicate.swap_duplicate.try_to_unmap_one.rmap_walk_anon":
>>  7.02,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>>  6.83,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.page_check_address_transhuge.page_referenced_one.rmap_walk_anon.rmap_walk":
>>  0.81,
>
> Numbers mean overhead percentage reported by perf?

Yes.
 
>> >> Patch 1 is a clean up patch.
>> >
>> > Could it be separated patch?
>> >
>> >> Patch 2 creates a lock per cluster, this gives us a more fine graind lock
>> >> that can be used for accessing swap_map, and not lock the whole
>> >> swap device
>> 
>> After patch 2, the result is as follow,
>> 
>>   "vmstat.swap.so": 1481704,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.__add_to_swap_cache.add_to_swap_cache.add_to_swap.shrink_page_list":
>>  27.53,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__remove_mapping.shrink_page_list.shrink_inactive_list.shrink_node_memcg":
>> 27.01,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.free_pcppages_bulk.drain_pages_zone.drain_pages.drain_local_pages":
>>  1.03,
>> 
>> The swap out throughput is at the same level, but the lock contention on
>> swap_info_struct->lock is eliminated.
>> 
>> >> Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
>> >> the rate that we have to contende for the radix tree.
>> >
>> 
>> After patch 3,
>> 
>>   "vmstat.swap.so": 2050097,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_swap_page.add_to_swap.shrink_page_list.shrink_inactive_list":
>>  43.27,
>>   
>> "perf-profile.calltrace.cycles-pp._raw_spin_lock.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_vma.handle_mm_fault":
>>  4.84,
>> 
>> The swap out throughput is improved about ~43% compared with baseline.
>> The lock contention on swap cache radix tree lock is eliminated.
>> swap_info_struct->lock in get_swap_page() becomes the most heavy
>> contended lock.
>
> The numbers are great! Please include those into each patchset.
> And I ask one more thing I said earlier about patch 2.
>
> ""
> I hope you make three steps to review easier. You can create some functions 
> like
> swap_map_lock and cluster_lock which are wrapper functions just hold 
> swap_lock.
> It doesn't change anything performance pov but it clearly shows what kinds of 
> lock
> we should use in specific context.
>
> Then, you can introduce more fine-graind lock in next patch and apply it into
> those wrapper functions.
>  
> And last patch, you can adjust cluster distribution to avoid false-sharing.
> And the description should include how it's bad in testing so it's worth.
> ""
>
> It makes review more easier, I believe.

Sorry, personally, I don't like this way to organize the patchset.  So
unless more people have this requirement, I still want to keep the
current way.

Best Regards,
Huang, Ying

>> 
>> >
>> >> Patch 4 eliminates unnecessary page allocation for read ahead.
>> >

Re: [PATCH v6 1/5] dt-bindings: zte: documents zx2967 power domain driver bindings

2017-01-04 Thread Shawn Guo
On Wed, Jan 04, 2017 at 07:48:10PM +0800, Baoyou Xie wrote:
> This patch documents devicetree tree bindings for the ZTE zx2967

'devicetree' is good enough, and the 'tree' after it is redundant.

> power domain driver.

DT bindings is to describe hardware block not software, so the word like
'driver' is not appropriate.  So please drop it from here and the patch
subject.

> 
> Signed-off-by: Baoyou Xie 
> ---
>  Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt | 17 
> +
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt 
> b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> new file mode 100644
> index 000..1476318
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> @@ -0,0 +1,17 @@
> +* ZTE 2967 SoC Power Domains

ZTE ZX2967 family.  And this is a bindings document for PCU, IMO.  And
do we know the full name of abbreviation 'PCU'?  Power Control Unit?

> +
> +2967 processors include support for multiple power domains which are used

ZX2967 family

> +to gate power to one or more peripherals on the processor.
> +
> +Required Properties:
> +- compatible: should be one of the following.
> +* zte,zx296718-pcu - for zx296718 board's power domain.

Drop 'board's'.

> +- reg: physical base address of the controller and length of memory mapped
> +region.
> +
> +Example:
> +
> + pcu_domain: pcu@0x00117000 {

The unit-address in node name shouldn't have 0x and leading zeros.

pcu_domain: pcu@117000 {

Shawn

> + compatible = "zte,zx296718-pcu";
> + reg = <0x00117000 0x1000>;
> + };
> -- 
> 2.7.4
> 


Re: [PATCH v6 2/5] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture

2017-01-04 Thread Shawn Guo
On Wed, Jan 04, 2017 at 07:48:11PM +0800, Baoyou Xie wrote:
> Add the ZTE SoC drivers as maintained by ARM ZTE
> architecture maintainers, as they're parts of the core IP.
> 
> By the way, this patch adds the maintainer for ARM
> ZTE architecture to Baoyou Xie.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  MAINTAINERS | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ad199da..2593296 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1975,12 +1975,17 @@ F:arch/arm/mach-pxa/include/mach/z2.h
>  
>  ARM/ZTE ARCHITECTURE
>  M:   Jun Nie 
> +M:   Baoyou Xie 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
>  F:   arch/arm/mach-zx/
>  F:   drivers/clk/zte/
> +F:   drivers/soc/zte/
> +F:   drivers/thermal/zx*

This line is about thermal support, and shouldn't be added in this
patch series.

Shawn

>  F:   Documentation/devicetree/bindings/arm/zte.txt
>  F:   Documentation/devicetree/bindings/clock/zx296702-clk.txt
> +F:   Documentation/devicetree/bindings/soc/zte/
> +F:   include/dt-bindings/soc/zx*.h
>  
>  ARM/ZYNQ ARCHITECTURE
>  M:   Michal Simek 
> -- 
> 2.7.4
> 


  1   2   3   4   5   6   7   8   9   10   >