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

[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

[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

[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:
>>> +
>>> +&dsi {
>>> +   ...
>>> +
>>> +   panel@0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <&ldo27_reg>;
>>> +   vci-supply = <&ldo28_reg>;
>>> +   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>>> +
>>> +   port {
>>> +   panel_in: endpoint {
>>> +   remote-endpoint = <&dsi_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 = <&dsi_in>;
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> port {
>> dsi_in: endpoint {
>> remote-endpoint = <&dsi_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 bi

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

[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(&arg, &bit) && bit < NCAPINTS*32)
> > +   if (get_option(&arg, &bit) && 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(&arg, &bit) && 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

[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

[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, &attr, 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, &val, 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, &val, 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, &val, 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

[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, &stext) < 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

[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

[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)'

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

[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

[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

[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

[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", &record.evlist, "event",
 "event selector. use 'perf list' to list available events",
 parse_events_option),

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

[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, &card_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 (((f->car

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

[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

[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

[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

[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,
> > > +  &handle);
> > > + if (ACPI_FAILURE(status))
> > > + return -EINVAL;
> > > +
> > > + ret = acpi_bus_get_device(handle, &adev);
> > > + 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,
> > > +   &cros_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,
> > > +  &cros_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;
> 

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

[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 *)&buff[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

[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

[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

[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, &al, 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(&totals, 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

[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 STDP4028_DPTX_LIN

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

[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, &slot->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

[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

[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.

[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()

[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

[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

[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

[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

[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 = &last_scanned_shadow[i];
+   if (sel_bssi_idx < last_scanned_cnt) {
+   pstrNetworkInfo = &last_scanned_shadow[sel_bssi_idx];
} else {
s32Error = -ENOENT;
wilc_connecting = 0;
-- 
2.7.4

[PATCH] mailbox: constify mbox_chan_ops structures

[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=&i@p
|
ctx.mb_ctrl.ops=&i@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

[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()

[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

[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

[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

[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(&pdev->dev, "ipg");
> > -   if (IS_ERR(imx->clk_ipg)) {
> > -   dev_err(&pdev->dev, "getting ipg clock failed with
> > %ld\n",
> > -   PTR_ERR(imx->clk_ipg));
> > -   return PTR_ERR(imx->clk_ipg);
> > -   }
> > -
> > imx->chip.ops = &imx_pwm_ops;
> > imx->chip.dev = &pdev->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

[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, &slot->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

[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

[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(&pdev->dev, "ipg");
> - if (IS_ERR(imx->clk_ipg)) {
> - dev_err(&pdev->dev, "getting ipg clock failed with %ld\n",
> - PTR_ERR(imx->clk_ipg));
> - return PTR_ERR(imx->clk_ipg);
> - }
> -
>   imx->chip.ops = &imx_pwm_ops;
>   imx->chip.dev = &pdev->dev;
>   imx->chip.base = -1;

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

[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

[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);
> +
> + val

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

[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

[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

[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:
>> +
>> +&dsi {
>> +...
>> +
>> +panel@0 {
>> +compatible = "samsung,s6e3ha2";
>> +reg = <0>;
>> +vdd3-supply = <&ldo27_reg>;
>> +vci-supply = <&ldo28_reg>;
>> +reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> +enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> +te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>> +
>> +port {
>> +panel_in: endpoint {
>> +remote-endpoint = <&dsi_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 = <&dsi_in>;
> samsung,burst-clock-frequency
> = <5>;
> samsung,esc-clock-frequency =
> <2000>;
> };
> };
> };
> 
> panel@0 {
> ...
> port {
> dsi_in: endpoint {
> remote-endpoint = <&dsi_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

[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.
+
+&usbotg1 {
+   vbus-supply = <®_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = <&clks IMX6SX_CLK_CKO>;
+   reset-gpios = <&gpio4 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 = <&clks IMX6SX_CLK_IPG>;
+   reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
2.7.4

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

[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,
>   
> "perf-profile.calltrace.cycles-pp._raw_spin_lock.swapcache_free_entries.free_swap_slot.free_swap_and_cache.unmap_p

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

[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

[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

[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
> 

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

[Hoegeun Kwon]

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 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 4 files changed, 789 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..da4c291
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+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)
+
+Example:
+
+&dsi {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x

[PATCH v6 1/4] drm/exynos: mic: Add mode_set callback function

[Hoegeun Kwon]

Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0b..a0f459c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;
 
-   ret = of_get_videomode(remote_node,
-   &mic->vm, 0);
-   if (ret) {
-   DRM_ERROR("mic: failed to get videomode");
-   goto exit;
-   }
-
break;
default:
DRM_ERROR("mic: Unknown endpoint from MIC");
@@ -329,6 +322,24 @@ static void mic_post_disable(struct drm_bridge *bridge)
mutex_unlock(&mic_mutex);
 }
 
+static void mic_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct exynos_mic *mic = bridge->driver_private;
+
+   mutex_lock(&mic_mutex);
+
+   drm_display_mode_to_videomode(mode, &mic->vm);
+
+   if (!mic->i80_mode)
+   mic_set_porch_timing(mic);
+   mic_set_img_size(mic);
+   mic_set_output_timing(mic);
+
+   mutex_unlock(&mic_mutex);
+}
+
 static void mic_pre_enable(struct drm_bridge *bridge)
 {
struct exynos_mic *mic = bridge->driver_private;
@@ -355,10 +366,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
goto turn_off_clks;
}
 
-   if (!mic->i80_mode)
-   mic_set_porch_timing(mic);
-   mic_set_img_size(mic);
-   mic_set_output_timing(mic);
mic_set_reg_on(mic, 1);
mic->enabled = 1;
mutex_unlock(&mic_mutex);
@@ -377,6 +384,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
 static const struct drm_bridge_funcs mic_bridge_funcs = {
.disable = mic_disable,
.post_disable = mic_post_disable,
+   .mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
.enable = mic_enable,
 };
-- 
1.9.1

[PATCH v6 4/4] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 5b9451d..0a6291f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -309,6 +309,16 @@
};
};
};
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <&ldo27_reg>;
+   vci-supply = <&ldo28_reg>;
+   reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 &hsi2c_0 {
-- 
1.9.1

[PATCH v6 2/4] drm/exynos: mic: Fix parse_dt function

[Hoegeun Kwon]

The OF graph is not necessary because the panel is a child of
dsi. therefore, the parse_dt function of dsi does not need to
check the remote_node connected to the panel. and the whole
parse_dt function should be refactored later.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0f459c..2aa61c5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -269,28 +269,9 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;
 
-   switch (i) {
-   case ENDPOINT_DECON_NODE:
-   /* decon node */
-   if (of_get_child_by_name(remote_node,
-   "i80-if-timings"))
-   mic->i80_mode = 1;
-
-   break;
-   case ENDPOINT_DSI_NODE:
-   /* panel node */
-   remote_node = get_remote_node(remote_node, 1);
-   if (!remote_node) {
-   ret = -EPIPE;
-   goto exit;
-   }
-   nodes[j++] = remote_node;
-
-   break;
-   default:
-   DRM_ERROR("mic: Unknown endpoint from MIC");
-   break;
-   }
+   if (i == ENDPOINT_DECON_NODE &&
+   of_get_child_by_name(remote_node, "i80-if-timings"))
+   mic->i80_mode = 1;
}
 
 exit:
-- 
1.9.1

[PATCH v6 0/4] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to [1]?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Hoegeun Kwon (3):
  drm/exynos: mic: Add mode_set callback function
  drm/exynos: mic: Fix parse_dt function
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  10 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  55 +-
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 6 files changed, 821 insertions(+), 33 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

Re: linux-next: bad rebase of the rdma-leon tree

[Leon Romanovsky]

On Thu, Jan 05, 2017 at 09:34:53AM +1100, Stephen Rothwell wrote:
> Hi Leon,
>
> In rebasing the rdma-leon tree, you have cherry-picked several patches
> that were in the net-next tree:
>
> Commit 8e4881aa == 90af6fea  net: mdio: add mdio45_ethtool_ksettings_get
> Commit e938ed15 == 9aee5260  net: sfc: falcon: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 41a65f70 == fae73a50  net: dec: de2104x: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 6711a87a == acbf8e3c  net: dec: uli526x: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 453e5f3d == edffccbc  net: dec: winbond-840: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 90222550 == 8c2863a7  net: dlink: dl2k: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 88c513d4 == c9abb356  net: dlink: sundance: use new api 
> ethtool_{get|set}_link_ksettings
> Commit fd90095d == ba141e8e  net: emulex: benet: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 9da12b64 == 4c8dff9c  net: faraday: ftmac100: use new api 
> ethtool_{get|set}_link_ksettings
> Commit 0a0a8d6b == 98192246  net: fealnx: use new api 
> ethtool_{get|set}_link_ksettings
>
> (The first SHA1s above are in the net-next tree.)

Thanks Stephen,
I'm sorry for the mess that I produced in last days with my branches.
It seems that I did git rebase instead of git reset.
>
> --
> Cheers,
> Stephen Rothwell


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] phy: sun4i-usb: Replace the deprecated extcon API

[Chen-Yu Tsai]

On Fri, Dec 30, 2016 at 12:11 PM, Chanwoo Choi  wrote:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
>
> Cc: Kishon Vijay Abraham I 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Signed-off-by: Chanwoo Choi 

Acked-by: Chen-Yu Tsai 

> ---
>  drivers/phy/phy-sun4i-usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index bf28a0fdd569..eae171e18043 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -534,7 +534,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
> mutex_unlock(&phy0->mutex);
>
> if (id_notify) {
> -   extcon_set_cable_state_(data->extcon, EXTCON_USB_HOST,
> +   extcon_set_state_sync(data->extcon, EXTCON_USB_HOST,
> !id_det);
> /* When leaving host mode force end the session here */
> if (force_session_end && id_det == 1) {
> @@ -547,7 +547,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
> }
>
> if (vbus_notify)
> -   extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
> +   extcon_set_state_sync(data->extcon, EXTCON_USB, vbus_det);
>
> if (sun4i_usb_phy0_poll(data))
> queue_delayed_work(system_wq, &data->detect, POLL_TIME);
> --
> 1.9.1
>

Re: [PATCH v3 2/5] ia64: reuse append_elf_note() and final_note() functions

[Dave Young]

On 01/02/17 at 07:44pm, Hari Bathini wrote:
> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under CONFIG_CRASH_CORE
> Also, define Elf_Word and use it instead of generic u32 or the more
> specific Elf64_Word.
> 
> Signed-off-by: Hari Bathini 
> ---
> 
> Changes from v2:
> * Added a definition for Elf_Word.
> * Used IA64 version of append_elf_note() and final_note() functions.
> 
> 
>  arch/ia64/kernel/crash.c   |   22 --
>  include/linux/crash_core.h |4 
>  include/linux/elf.h|2 ++
>  kernel/crash_core.c|   34 ++
>  kernel/kexec_core.c|   28 
>  5 files changed, 20 insertions(+), 70 deletions(-)
> 
> diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
> index 2955f35..75859a0 100644
> --- a/arch/ia64/kernel/crash.c
> +++ b/arch/ia64/kernel/crash.c
> @@ -27,28 +27,6 @@ static int kdump_freeze_monarch;
>  static int kdump_on_init = 1;
>  static int kdump_on_fatal_mca = 1;
>  
> -static inline Elf64_Word
> -*append_elf_note(Elf64_Word *buf, char *name, unsigned type, void *data,
> - size_t data_len)
> -{
> - struct elf_note *note = (struct elf_note *)buf;
> - note->n_namesz = strlen(name) + 1;
> - note->n_descsz = data_len;
> - note->n_type   = type;
> - buf += (sizeof(*note) + 3)/4;
> - memcpy(buf, name, note->n_namesz);
> - buf += (note->n_namesz + 3)/4;
> - memcpy(buf, data, data_len);
> - buf += (data_len + 3)/4;
> - return buf;
> -}
> -
> -static void
> -final_note(void *buf)
> -{
> - memset(buf, 0, sizeof(struct elf_note));
> -}
> -
>  extern void ia64_dump_cpu_regs(void *);
>  
>  static DEFINE_PER_CPU(struct elf_prstatus, elf_prstatus);
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 18d0f94..541a197 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -55,6 +55,10 @@ extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
>  extern size_t vmcoreinfo_size;
>  extern size_t vmcoreinfo_max_size;
>  
> +Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
> +   void *data, size_t data_len);
> +void final_note(Elf_Word *buf);
> +
>  int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
>   unsigned long long *crash_size, unsigned long long *crash_base);
>  int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
> diff --git a/include/linux/elf.h b/include/linux/elf.h
> index 20fa8d8..ba069e8 100644
> --- a/include/linux/elf.h
> +++ b/include/linux/elf.h
> @@ -29,6 +29,7 @@ extern Elf32_Dyn _DYNAMIC [];
>  #define elf_note elf32_note
>  #define elf_addr_t   Elf32_Off
>  #define Elf_Half Elf32_Half
> +#define Elf_Word Elf32_Word
>  
>  #else
>  
> @@ -39,6 +40,7 @@ extern Elf64_Dyn _DYNAMIC [];
>  #define elf_note elf64_note
>  #define elf_addr_t   Elf64_Off
>  #define Elf_Half Elf64_Half
> +#define Elf_Word Elf64_Word
>  
>  #endif
>  
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 212c705..3ac172c 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -291,32 +291,26 @@ int __init parse_crashkernel_low(char *cmdline,
>   "crashkernel=", suffix_tbl[SUFFIX_LOW]);
>  }
>  
> -static u32 *append_elf_note(u32 *buf, char *name, unsigned int type,
> - void *data, size_t data_len)
> +Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
> +   void *data, size_t data_len)
>  {
> - struct elf_note note;
> -
> - note.n_namesz = strlen(name) + 1;
> - note.n_descsz = data_len;
> - note.n_type   = type;
> - memcpy(buf, ¬e, sizeof(note));
> - buf += (sizeof(note) + 3)/4;
> - memcpy(buf, name, note.n_namesz);
> - buf += (note.n_namesz + 3)/4;
> - memcpy(buf, data, note.n_descsz);
> - buf += (note.n_descsz + 3)/4;
> + struct elf_note *note = (struct elf_note *)buf;
> +
> + note->n_namesz = strlen(name) + 1;
> + note->n_descsz = data_len;
> + note->n_type   = type;
> + buf += (sizeof(*note) + 3)/4;
> + memcpy(buf, name, note->n_namesz);
> + buf += (note->n_namesz + 3)/4;
> + memcpy(buf, data, data_len);
> + buf += (data_len + 3)/4;
>  
>   return buf;
>  }
>  
> -static void final_note(u32 *buf)
> +void final_note(Elf_Word *buf)
>  {
> - struct elf_note note;
> -
> - note.n_namesz = 0;
> - note.n_descsz = 0;
> - note.n_type   = 0;
> - memcpy(buf, ¬e, sizeof(note));
> + memset(buf, 0, sizeof(struct elf_note));
>  }
>  
>  static void update_vmcoreinfo_note(void)
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 2179a16..263d764 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -990,34 +990,6 @@ int crash_shrink_memory(unsigned long new_size)
>   return re

Re: [PATCH V2 3/5] Documetation: binding: modify the exynos5440 pcie binding

[pankaj.dubey]

Hi Jaehoon,

On Wednesday 04 January 2017 06:04 PM, Jaehoon Chung wrote:
> According to using PHY framework, updates the exynos5440-pcie binding.
> For maintaining backward compatibility, leaves the current dt-binding.
> (It should be deprecated.)
> 
> Recommends to use the Phy Framework and "config" property to follow
> the designware-pcie binding.
> If you use the old way, can see "mssing *config* reg space" message.
> Because the getting configuration space address from range is old way.
> 
> NOTE: When use the "config" property, first name of 'reg-names' must be
> set to "elbi". Otherwise driver can't maintain the backward capability.
> 
> Signed-off-by: Jaehoon Chung 
> ---
> Changelog on V2:
> - Describes more commit message
> - Fixes the typos
> - Adds the new example for using PHY framework
> - Deprecated the old dt-binding description
> - Removes 'phy-names'
> 
>  .../bindings/pci/samsung,exynos5440-pcie.txt   | 29 
> ++
>  1 file changed, 29 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt 
> b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> index 4f9d23d..1d0af0e 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -7,8 +7,19 @@ Required properties:
>  - compatible: "samsung,exynos5440-pcie"
>  - reg: base addresses and lengths of the pcie controller,
>   the phy controller, additional register for the phy controller.
> + (Registers for the phy controller are DEPRECATED.
> +  Use the PHY framework.)
> +- reg-names : First name should be set to "elbi".
> + And use the "config" instead of getting the confgiruation address space
> + from "ranges".
> + NOTE: When use the "config" property, reg-names must be set.
>  - interrupts: A list of interrupt outputs for level interrupt,
>   pulse interrupt, special interrupt.
> +- phys: From PHY binding. Phandle for the Generic PHY.
> + Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt
> +
> +Other common properties refer to
> + Documentation/devicetree/binding/pci/designware-pcie.txt
>  
>  Example:
>  
> @@ -54,6 +65,24 @@ SoC specific DT Entry:
>   num-lanes = <4>;
>   };
>  
> +With using PHY framework:
> + pcie_phy0: pcie-phy@27 {
> + ...
> + reg = <0x27 0x1000>, <0x271000 0x40>;
> + regn-names = "phy", "block";

typo: %s/regn-names/reg-names/

> + ...
> + };
> +
> + pcie@29 {
> + ...
> + reg = <0x29 0x1000>, <0x4000 0x1000>;
> + reg-names = "elbi", "config";
> + phys = <&pcie_phy0>;
> + ranges = <0x8100 0 0  0x60001000 0 0x0001
> +   0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
> + ...
> + };
> +
>  Board specific DT Entry:
>  
>   pcie@29 {
> 

Other than above one typo rest is looking fine.
Once you address it, feel free to add

Reviewed-by: Pankaj Dubey 

Thanks,
Pankaj Dubey

Re: [PATCH v4] IB/umem: Release pid in error and ODP flow

[Leon Romanovsky]

On Thu, Jan 05, 2017 at 03:00:05PM +0800, Kenneth Lee wrote:
> 1. Release pid before enter odp flow
> 2. Release pid when fail to allocate memory
>
> Fixes: 87773dd56d54 ("IB: ib_umem_release() should decrement mm->pinned_vm 
> from ib_umem_get")
> Fixes: 8ada2c1c0c1d ("IB/core: Add support for on demand paging regions")
> Signed-off-by: Kenneth Lee 
> Reviewed-by: Haggai Eran 

Thanks a lot for resending.
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH 15/22] mfd: axp20x: add CHRG_CTRL1 to writeable regs for AXP20X/AXP22X

[Chen-Yu Tsai]

On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
 wrote:
> The CHR_CTRL1 register is made of 7 read-write bits with one being used
> to set the target voltage for battery charging.

The description is incorrect.

All 8 bits are read-write:

  - The highest bit enables the charger module
  - Bits [6:5] set the target voltage
  - Bits [4:3] set when the charge cycle ends, based on percentage
of charge current
  - Bits [2:0] set the charge current

Feel free to use the above in the commit message.

>
> This adds the CHRG_CTRL1 register to the list of writeable registers for
> AXP20X and AXP22X PMICs.

You might want to add up to CHRG_CTRL3 for the AXP22x and CHRG_CTRL2
for the AXP20x. These control additional aspects of the charger.

AXP20X_CHRG_BAK_CTRL controls the charger for the RTC battery. You
could add this now, or let the person doing the RTC battery driver
add it.

Regards
ChenYu

>
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/mfd/axp20x.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 65c57d0..19bdba3 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -66,6 +66,7 @@ static const struct regmap_access_table 
> axp152_volatile_table = {
>  static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> +   regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
>  };
> @@ -94,6 +95,7 @@ static const struct regmap_access_table 
> axp20x_volatile_table = {
>  static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> +   regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
>  };
>
> --
> 2.9.3
>

Re: [PATCH v3 0/2] ALSA: Fix usb-audio races

[Takashi Iwai]

On Wed, 04 Jan 2017 23:37:45 +0100,
Ioan-Adrian Ratiu wrote:
> 
> Changes since v2:
> * Fixed snd_usb_*lock_shutdown imbalance caused by an early return
> in snd_usb_pcm_prepare()
> 
> Ioan-Adrian Ratiu (2):
>   ALSA: usb-audio: Fix irq/process data synchronization
>   ALSA: usb-audio: test EP_FLAG_RUNNING at urb completion

Thanks, applied both patches now.


Takashi

[PATCH v4] IB/umem: Release pid in error and ODP flow

[Kenneth Lee]

1. Release pid before enter odp flow
2. Release pid when fail to allocate memory

Fixes: 87773dd56d54 ("IB: ib_umem_release() should decrement mm->pinned_vm from 
ib_umem_get")
Fixes: 8ada2c1c0c1d ("IB/core: Add support for on demand paging regions")
Signed-off-by: Kenneth Lee 
Reviewed-by: Haggai Eran 
---
Change from v1 to v2:
  Correcting the patch title and description  
Change from v2 to v3:
  Update the title and add "Fixes" fields in the description  
Change from v3 to v4:
  Keep the Fixes tag at the end of the description

 drivers/infiniband/core/umem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 1e62a5f0cb28..4609b921f899 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -134,6 +134,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, 
unsigned long addr,
 IB_ACCESS_REMOTE_ATOMIC | IB_ACCESS_MW_BIND));
 
if (access & IB_ACCESS_ON_DEMAND) {
+   put_pid(umem->pid);
ret = ib_umem_odp_get(context, umem);
if (ret) {
kfree(umem);
@@ -149,6 +150,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, 
unsigned long addr,
 
page_list = (struct page **) __get_free_page(GFP_KERNEL);
if (!page_list) {
+   put_pid(umem->pid);
kfree(umem);
return ERR_PTR(-ENOMEM);
}
-- 
1.9.1

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

[kbuild test robot]

Hi Eric,

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

url:
https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64-and-IOVA-reserved-regions/20170105-132853
config: i386-randconfig-x003-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/irq/irqdomain.c: In function 'irq_domain_is_msi_remap':
>> kernel/irq/irqdomain.c:289:17: error: 'struct irq_domain' has no member 
>> named 'parent'
 for (; h; h = h->parent) {
^~

vim +289 kernel/irq/irqdomain.c

   283   * @domain: domain pointer
   284   */
   285  static bool irq_domain_is_msi_remap(struct irq_domain *domain)
   286  {
   287  struct irq_domain *h = domain;
   288  
 > 289  for (; h; h = h->parent) {
   290  if (h->flags & IRQ_DOMAIN_FLAG_MSI_REMAP)
   291  return true;
   292  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v2 1/1] regulator: fixed: add suspend pm routines for pinctrl

[Peter Chen]

At some systems, the pinctrl setting will be lost or needs to
set as "sleep" state to save power consumption. So, we need to
configure pinctrl as "sleep" state when system enters suspend,
and as "default" state after system resumes. In this way, the
pinctrl value can be recovered as "default" state after resuming.

Signed-off-by: Peter Chen 
---

Changes for v2:
- Fixed build error reported by Kbuild robot, the header file
  was not added.

 drivers/regulator/fixed.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index a43b0e8..4a9e6da 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct fixed_voltage_data {
struct regulator_desc desc;
@@ -245,11 +246,32 @@ static const struct of_device_id fixed_of_match[] = {
 MODULE_DEVICE_TABLE(of, fixed_of_match);
 #endif
 
+#ifdef CONFIG_PM_SLEEP
+static int reg_fixed_voltage_suspend(struct device *dev)
+{
+   pinctrl_pm_select_sleep_state(dev);
+
+   return 0;
+}
+static int reg_fixed_voltage_resume(struct device *dev)
+{
+   pinctrl_pm_select_default_state(dev);
+
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops reg_fixed_voltage_pm_ops = {
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(reg_fixed_voltage_suspend,
+   reg_fixed_voltage_resume)
+};
+
 static struct platform_driver regulator_fixed_voltage_driver = {
.probe  = reg_fixed_voltage_probe,
.driver = {
.name   = "reg-fixed-voltage",
.of_match_table = of_match_ptr(fixed_of_match),
+   .pm = ®_fixed_voltage_pm_ops,
},
 };
 
-- 
2.7.4

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

[Minchan Kim]

Hi Huang,

On Tue, Jan 03, 2017 at 01:43:43PM +0800, Huang, Ying wrote:
> Hi, Minchan,
> 
> Minchan Kim  writes:
> 
> > Hi Jan,
> >
> > On Mon, Jan 02, 2017 at 04:48:41PM +0100, Jan Kara wrote:
> >> Hi,
> >> 
> >> On Tue 27-12-16 16:45:03, Minchan Kim wrote:
> >> > > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
> >> > > the rate that we have to contende for the radix tree.
> >> > 
> >> > To me, it's rather hacky. I think it might be common problem for page 
> >> > cache
> >> > so can we think another generalized way like range_lock? Ccing Jan.
> >> 
> >> I agree on the hackyness of the patch and that page cache would suffer with
> >> the same contention (although the files are usually smaller than swap so it
> >> would not be that visible I guess). But I don't see how range lock would
> >> help here - we need to serialize modifications of the tree structure itself
> >> and that is difficult to achieve with the range lock. So what you would
> >> need is either a different data structure for tracking swap cache entries
> >> or a finer grained locking of the radix tree.
> >
> > Thanks for the comment, Jan.
> >
> > I think there are more general options. One is to shrink batching pages like
> > Mel and Tim had approached.
> >
> > https://patchwork.kernel.org/patch/9008421/
> > https://patchwork.kernel.org/patch/9322793/
> 
> This helps to reduce the lock contention on radix tree of swap cache.
> But splitting swap cache has much better performance.  So we switched
> from that solution to current solution.
> 
> > Or concurrent page cache by peter.
> >
> > https://www.kernel.org/doc/ols/2007/ols2007v2-pages-311-318.pdf
> 
> I think this is good, it helps swap and file cache.  But I don't know
> whether other people want to go this way and how much effort will be
> needed.
> 
> In contrast, splitting swap cache is quite simple, for implementation
> and review.  And the effect is good.

I think general approach is better but I don't want to be a a party pooper
if every people are okay with this. I just wanted to point out we need to
consider more general approach and I did my best.

Decision depends on you guys.

Thanks.

Re: [PATCH 07/22] dt-bindings: power: supply: add AXP20X/AXP22X AC power supply

[Chen-Yu Tsai]

Hi Quentin,

On Wed, Jan 4, 2017 at 9:14 PM, Rob Herring  wrote:
> On Mon, Jan 02, 2017 at 05:37:07PM +0100, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs have an AC entry to supply power to
>> the board. They have a few registers dedicated to the status of the AC
>> power supply.
>>
>> This adds the DT binding documentation for the AC power supply for
>> AXP20X and AXP22X PMICs.
>>
>> Signed-off-by: Quentin Schulz 
>> ---
>>  .../bindings/power/supply/axp20x_ac_power.txt  | 28 
>> ++
>>  1 file changed, 28 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power/supply/axp20x_ac_power.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/power/supply/axp20x_ac_power.txt 
>> b/Documentation/devicetree/bindings/power/supply/axp20x_ac_power.txt
>> new file mode 100644
>> index 000..16d0de4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_ac_power.txt
>> @@ -0,0 +1,28 @@
>> +AXP20X and AXP22X PMICs' AC power supply
>> +
>> +Required Properties:
>> + - compatible: One of:
>> + "x-powers,axp202-ac-power-supply"
>> + "x-powers,axp221-ac-power-supply"
>> +
>> +More Required Properties for AXP20X PMICs:
>> + - io-channels: phandles to ACIN voltage and current ADC channels
>> + - io-channel-names = "acin_v", "acin_i";
>> +
>> +This node is a subnode of the axp20x PMIC.
>> +
>> +The AXP20X can read the current current and voltage supplied by AC by
>> +reading ADC channels from the AXP20X ADC.
>> +
>> +The AXP22X is only able to tell if an AC power supply is present and
>> +usable.
>> +
>> +Example:
>> +
>> +&axp209 {
>> + ac_power_supply: ac_power_supply {
>
> power-supply {
>
>> + compatible = "x-powers,axp202-ac-power-supply";
>> + io-channels = <&axp209_adc 0>, <&axp209_adc 1>;
>
> Is this assignment fixed? If so, then it doesn't need to be in DT.

Is there any case that we actually need to use the IIO channels
from the device tree? Seems to me its limited to the other AXP
sub-devices.

If so you could use struct iio_map to map the channels to other
devices by name. See axp288_adc for an example.

Regards
ChenYu

>> + io-channel-names = "acin_v", "acin_i";
>> + };
>> +};
>> --
>> 2.9.3
>>

Re: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table()

[Paul E. McKenney]

On Thu, Jan 05, 2017 at 01:24:14AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Linus reported that commit 174cc7187e6f "ACPICA: Tables: Back port
> acpi_get_table_with_size() and early_acpi_os_unmap_memory() from
> Linux kernel" added a new warning on his desktop system:
> 
>  ACPI Warning: Table 9fe6c0a0, Validation count is zero before 
> decrement
> 
> which turns out to come from the acpi_put_table() in
> detect_intel_iommu().
> 
> This happens if the DMAR table is not present in which case NULL is
> passed to acpi_put_table() which doesn't check against that and
> attempts to handle it regardless.
> 
> For this reason, check the pointer passed to acpi_put_table()
> before invoking it.
> 
> Reported-by: Linus Torvalds  
> Fixes: 6b11d1d67713 ("ACPI / osl: Remove 
> acpi_get_table_with_size()/early_acpi_os_unmap_memory() users")
> Signed-off-by: Rafael J. Wysocki 

Much better!

Tested-by: Paul E. McKenney 

> ---
>  drivers/iommu/dmar.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/iommu/dmar.c
> ===
> --- linux-pm.orig/drivers/iommu/dmar.c
> +++ linux-pm/drivers/iommu/dmar.c
> @@ -903,8 +903,10 @@ int __init detect_intel_iommu(void)
>   x86_init.iommu.iommu_init = intel_iommu_init;
>  #endif
> 
> - acpi_put_table(dmar_tbl);
> - dmar_tbl = NULL;
> + if (dmar_tbl) {
> + acpi_put_table(dmar_tbl);
> + dmar_tbl = NULL;
> + }
>   up_write(&dmar_global_lock);
> 
>   return ret ? 1 : -ENODEV;
> 

Re: [PATCH v3 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

[Dave Young]

Hi, Hari

On 01/02/17 at 07:43pm, Hari Bathini wrote:
> Traditionally, kdump is used to save vmcore in case of a crash. Some
> architectures like powerpc can save vmcore using architecture specific
> support instead of kexec/kdump mechanism. Such architecture specific
> support also needs to reserve memory, to be used by dump capture kernel.
> crashkernel parameter can be a reused, for memory reservation, by such
> architecture specific infrastructure.
> 
> But currently, code related to vmcoreinfo and parsing of crashkernel
> parameter is built under CONFIG_KEXEC_CORE. This patch introduces
> CONFIG_CRASH_CORE and moves the above mentioned code under this config,
> allowing code reuse without dependency on CONFIG_KEXEC. There is no
> functional change with this patch.
> 
> Signed-off-by: Hari Bathini 
> ---
> 
> Changes from v2:
> * Used CONFIG_CRASH_CORE instead of CONFIG_KEXEC_CORE at
>   appropriate places in printk and ksysfs.
> 
> 
>  arch/Kconfig   |4 
>  include/linux/crash_core.h |   65 ++
>  include/linux/kexec.h  |   57 --
>  include/linux/printk.h |4 
>  kernel/Makefile|1 
>  kernel/crash_core.c|  445 
> 
>  kernel/kexec_core.c|  404 
>  kernel/ksysfs.c|8 +
>  kernel/printk/printk.c |6 -
>  9 files changed, 531 insertions(+), 463 deletions(-)
>  create mode 100644 include/linux/crash_core.h
>  create mode 100644 kernel/crash_core.c
> 

[snip]

>  #ifndef CONFIG_TINY_RCU
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 8b26964..d0dfebd 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -32,7 +32,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -951,7 +951,7 @@ const struct file_operations kmsg_fops = {
>   .release = devkmsg_release,
>  };
>  
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_CORE
>  /*
>   * This appends the listed symbols to /proc/vmcore
>   *
> @@ -960,7 +960,7 @@ const struct file_operations kmsg_fops = {
>   * symbols are specifically used so that utilities can access and extract the
>   * dmesg log from a vmcore file after a crash.
>   */
> -void log_buf_kexec_setup(void)
> +void log_buf_crash_setup(void)

I can not think of any better name about the CONFIG_CRASH_CORE though I
feel it is not excellent so personally I can live with it.

But for this function name log_buf_crash_setup is too general, I can not get
what it is doing from the name, how about change it to log_buf_vmcoreinfo_setup

>  {
>   VMCOREINFO_SYMBOL(log_buf);
>   VMCOREINFO_SYMBOL(log_buf_len);
> 

Thanks
Dave

[PATCH v11 0/8] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
power sequence instances will be added at postcore_initcall, the match
criteria is compatible string first, if the compatible string is not
matched between dts and library, it will try to use generic power sequence.
 
The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence instance is needed, for more power sequences
are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
driver).

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v11:
- Fix warning: (USB) selects POWER_SEQUENCE which has unmet direct dependencies 
(OF)
- Delete redundant copyright statement.
- Change pr_warn to pr_debug at wrseq_find_available_instance
- Refine kerneldoc
- %s/ENONET/ENOENT 
- Allocate pwrseq list node before than carry out power sequence on 
- Add mutex_lock/mutex_lock for pwrseq node browse at 
pwrseq_find_available_instance
- Add pwrseq_suspend/resume for API both single instance and list 
- Add .pwrseq_suspend/resume for pwrseq_generic.c
- Add pwrseq_suspend_list and pwrseq_resume_list for USB hub suspend
  and resume routine

Changes for v10:
- Improve the kernel-doc for power sequence core, including exported APIs and
  main structure. [Patch 2/8]
- Change Kconfig, and let the user choose power sequence. [Patch 2/8]
- Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
  be intended to export currently. [Patch 2/8]
- Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]

Changes for v9:
- Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
- Rebase to v4.9-rc1

Changes for v8:
- Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
  preallocate instances problem which the number of instance is decided at
  compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
- Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
  match method. [Patch 2/8]
- Add Maciej S. Szmigiero's tested-by. [Patch 7/8]

Changes for v7:
- Create kinds of power sequence instance at postcore_initcall, and match
  the instance with node using compatible string, the beneit of this is
  the host driver doesn't need to consider which pwrseq instance needs
  to be used, and pwrseq core will match it, however, it eats some memories
  if less power sequence instances are used. [Patch 2/8]
- Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 
2/8]
- Fix the comments Vaibhav Hiremath adds for error path for clock and do not
  use device_node for parameters at pwrseq_on. [Patch 2/8]
- Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
- Tested three pwrseq instances together using both specific compatible string 
and
  generic libraries.

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
  at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
  add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe

Joshua Clayton (2):
  ARM: dts: imx6qdl: Enable usb node children with 
  ARM: dts: imx6q-evi: Fix onboard hub reset line

Peter Che

Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy

[pankaj.dubey]

Hi Jaehoon,

On Wednesday 04 January 2017 06:04 PM, Jaehoon Chung wrote:
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
> 
> Currently, there is an exynos5440 case to support the pcie.
> So this driver is based on Exynos5440 PCIe.
> In future, will support the Other exynos SoCs likes exynos5433, exynos7.
> 
> Signed-off-by: Jaehoon Chung 
> ---
> Changelog on V2:
> - Not include the codes relevant to pci-exynos.
> - Remove the getting child node.
> 

Reviewed-by: Pankaj Dubey 

Thanks,
Pankaj Dubey

Re: [PATCH 16/22] mfd: axp20x: add V_OFF to writeable regs for AXP20X and AXP22X

[Chen-Yu Tsai]

On Wed, Jan 4, 2017 at 7:57 PM, Lee Jones  wrote:
> On Mon, 02 Jan 2017, Quentin Schulz wrote:
>
>> The V_OFF register has its first 3 read-write bits for the minimal
>> voltage (Voff) of the battery before the system is automatically shut
>> down due to the power being too low.
>>
>> This adds V_OFF register to the writeable registers of AXP20X and AXP22X
>> PMICs.
>>
>> Signed-off-by: Quentin Schulz 
>> ---
>>  drivers/mfd/axp20x.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> 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 19bdba3..7f0f05f 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -65,7 +65,7 @@ static const struct regmap_access_table 
>> axp152_volatile_table = {
>>
>>  static const struct regmap_range axp20x_writeable_ranges[] = {
>>   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
>> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
>>   regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
>>   regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
>>   regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
>> @@ -94,7 +94,7 @@ static const struct regmap_access_table 
>> axp20x_volatile_table = {
>>  /* AXP22x ranges are shared with the AXP809, as they cover the same range */
>>  static const struct regmap_range axp22x_writeable_ranges[] = {
>>   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>> - regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
>> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_V_OFF),
>>   regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL1),
>>   regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
>>  };
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/1] spi: imx: support to set watermark level via DTS

[Jiada Wang]

Previously watermark level is configured to fifosize/2,
DMA mode can be used only when transfer length can be divided
by 'watermark level * bpw', which makes DMA mode not practical.

This patch adds new DTS property 'dma-wml', user can configure
DMA watermark level, by specify 'dma-wml' in corresponding ecspi
node.

Signed-off-by: Jiada Wang 
---
 Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt |  2 ++
 drivers/spi/spi-imx.c  | 12 ++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt 
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 8bc95e2..1e9345f 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -19,6 +19,7 @@ See the clock consumer binding,
 - dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
 - dma-names: DMA request names should include "tx" and "rx" if present.
+- dma-wml: Specifies DMA watermark level
 
 Obsolete properties:
 - fsl,spi-num-chipselects : Contains the number of the chipselect
@@ -35,4 +36,5 @@ ecspi@7001 {
   <&gpio3 25 0>; /* GPIO3_25 */
dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
dma-names = "rx", "tx";
+dma-wml = <16>;
 };
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index deb782f..5c0ce19 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -929,8 +929,6 @@ static int spi_imx_sdma_init(struct device *dev, struct 
spi_imx_data *spi_imx,
if (of_machine_is_compatible("fsl,imx6dl"))
return 0;
 
-   spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
-
/* Prepare for TX DMA: */
master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
if (IS_ERR(master->dma_tx)) {
@@ -1155,6 +1153,7 @@ static int spi_imx_probe(struct platform_device *pdev)
struct spi_imx_data *spi_imx;
struct resource *res;
int i, ret, irq;
+   u32 wml;
 
if (!np && !mxc_platform_info) {
dev_err(&pdev->dev, "can't get the platform data\n");
@@ -1177,6 +1176,15 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->devtype_data = of_id ? of_id->data :
(struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
 
+   if (of_property_read_u32(np, "dma-wml", &wml) == 0) {
+   if (wml > spi_imx_get_fifosize(spi_imx) || wml == 0) {
+   dev_warn(&pdev->dev, "mis-configured dma-wml\n");
+   spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
+   } else
+   spi_imx->wml = wml;
+   } else
+   spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
+
if (mxc_platform_info) {
master->num_chipselect = mxc_platform_info->num_chipselect;
master->cs_gpios = devm_kzalloc(&master->dev,
-- 
2.9.3

[PATCH v11 4/8] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. It will do power on sequence at hub's
probe for all devices under this hub (includes root hub).
At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
Reviewed-by: Vaibhav Hiremath 
---
 drivers/usb/Kconfig|  1 +
 drivers/usb/core/hub.c | 48 
 drivers/usb/core/hub.h |  1 +
 3 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..706f261 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -40,6 +40,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+   select POWER_SEQUENCE
select NLS  # for UTF-8 strings
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1fa5c0f..cec2fad 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1645,6 +1646,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   of_pwrseq_off_list(&hub->pwrseq_on_list);
mutex_lock(&usb_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1672,12 +1674,41 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(&hub->kref, hub_release);
 }
 
+#ifdef CONFIG_OF
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   struct device *parent;
+   struct usb_device *hdev = hub->hdev;
+   struct device_node *np;
+   int ret;
+
+   if (hdev->parent)
+   parent = &hdev->dev;
+   else
+   parent = bus_to_hcd(hdev->bus)->self.controller;
+
+   for_each_child_of_node(parent->of_node, np) {
+   ret = of_pwrseq_on_list(np, &hub->pwrseq_on_list);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+#else
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+#endif
+
 static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
*id)
 {
struct usb_host_interface *desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1782,6 +1813,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
INIT_DELAYED_WORK(&hub->leds, led_work);
INIT_DELAYED_WORK(&hub->init_work, NULL);
INIT_WORK(&hub->events, hub_event);
+   INIT_LIST_HEAD(&hub->pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
 
@@ -1795,11 +1827,14 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_of_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
@@ -3613,14 +3648,19 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
 
/* stop hub_wq and related activity */
hub_quiesce(hub, HUB_SUSPEND);
-   return 0;
+   return pwrseq_suspend_list(&hub->pwrseq_on_list);
 }
 
 static int hub_resume(struct usb_interface *intf)
 {
struct usb_hub *hub = usb_get_intfdata(intf);
+   int ret;
 
dev_dbg(&intf->dev, "%s\n", __func__);
+   ret = pwrseq_resume_list(&hub->pwrseq_on_list);
+   if (ret)
+   return ret;
+
hub_activate(hub, HUB_RESUME);
return 0;
 }
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..cd86f91 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
-- 
2.7.4

[PATCH v11 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

From: Peter Chen 

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
Tested-by Joshua Clayton 
---
 drivers/usb/chipidea/core.c | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3dbb4a2..fdffc67 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -928,6 +928,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+   /*
+* At device tree, we have no device node for chipidea core,
+* the glue layer's node is the parent node for host and udc
+* device. But in related driver, the parent device is chipidea
+* core. So, in order to let the common driver get parent's node,
+* we let the core's device node equals glue layer's node.
+*/
+   if (dev->parent && dev->parent->of_node)
+   dev->of_node = dev->parent->of_node;
+
if (ci->platdata->phy) {
ci->phy = ci->platdata->phy;
} else if (ci->platdata->usb_phy) {
@@ -938,11 +948,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci->phy) == -ENOSYS &&
-   PTR_ERR(ci->usb_phy) == -ENXIO)
-   return -ENXIO;
+   PTR_ERR(ci->usb_phy) == -ENXIO) {
+   ret = -ENXIO;
+   goto clear_of_node;
+   }
 
-   if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy))
-   return -EPROBE_DEFER;
+   if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) {
+   ret = -EPROBE_DEFER;
+   goto clear_of_node;
+   }
 
if (IS_ERR(ci->phy))
ci->phy = NULL;
@@ -953,7 +967,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ret = ci_usb_phy_init(ci);
if (ret) {
dev_err(dev, "unable to init phy: %d\n", ret);
-   return ret;
+   goto clear_of_node;
}
 
ci->hw_bank.phys = res->start;
@@ -1059,6 +1073,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci_role_destroy(ci);
 deinit_phy:
ci_usb_phy_exit(ci);
+clear_of_node:
+   dev->of_node = NULL;
 
return ret;
 }
@@ -1077,6 +1093,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
ci_extcon_unregister(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
+   ci->dev->of_node = NULL;
ci_usb_phy_exit(ci);
 
return 0;
-- 
2.7.4

[PATCH v11 2/8] power: add power sequence library

[Peter Chen]

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices. The pwrseq
librares always need to allocate extra instance for compatible
string match.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover other controls in
future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence is needed, else call of_pwrseq_on_list
/of_pwrseq_off_list instead (eg, USB hub driver).

For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
Tested-by Joshua Clayton 
Reviewed-by: Matthias Kaehlcke 
Tested-by: Matthias Kaehlcke 
---
 MAINTAINERS   |   9 +
 drivers/power/Kconfig |   1 +
 drivers/power/Makefile|   1 +
 drivers/power/pwrseq/Kconfig  |  20 ++
 drivers/power/pwrseq/Makefile |   2 +
 drivers/power/pwrseq/core.c   | 335 ++
 drivers/power/pwrseq/pwrseq_generic.c | 224 +++
 include/linux/power/pwrseq.h  |  81 
 8 files changed, 673 insertions(+)
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9..ae2aa25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9828,6 +9828,15 @@ F:   include/linux/pm_*
 F: include/linux/powercap.h
 F: drivers/powercap/
 
+POWER SEQUENCE LIBRARY
+M: Peter Chen 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/pwrseq/
+F: drivers/power/pwrseq/
+F: include/linux/power/pwrseq.h
+
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
 M: Sebastian Reichel 
 L: linux...@vger.kernel.org
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 63454b5..c1bb046 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -1,3 +1,4 @@
 source "drivers/power/avs/Kconfig"
 source "drivers/power/reset/Kconfig"
 source "drivers/power/supply/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ff35c71..7db8035 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_POWER_RESET)  += reset/
 obj-$(CONFIG_POWER_SUPPLY) += supply/
+obj-$(CONFIG_POWER_SEQUENCE)   += pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 000..c6b3569
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+menuconfig POWER_SEQUENCE
+   bool "Power sequence control"
+   help
+  It is used for drivers which needs to do power sequence
+  (eg, turn on clock, toggle reset gpio) before the related
+  devices can be found by hardware, eg, USB bus.
+
+if POWER_SEQUENCE
+
+config PWRSEQ_GENERIC
+   bool "Generic power sequence control"
+   depends on OF
+   help
+  This is the generic power sequence control library, and is
+  supposed to support common power sequence usage.
+endif
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 000..3d19e62
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,335 @@
+/*
+ * core.c  power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See t

[PATCH v11 6/8] ARM: dts: imx6qdl: Enable usb node children with

[Peter Chen]

From: Joshua Clayton 

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a  attribute

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..e6725f1 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -936,6 +936,8 @@
 
usbh1: usb@02184200 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184200 0x200>;
interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -950,6 +952,8 @@
 
usbh2: usb@02184400 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184400 0x200>;
interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USBOH3>;
@@ -963,6 +967,8 @@
 
usbh3: usb@02184600 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184600 0x200>;
interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_USBOH3>;
-- 
2.7.4

[PATCH v11 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
 &usb1 {
@@ -21,8 +25,12 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
 
-   hub: genesys@1 {
+   genesys: hub@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+   clocks = <&clks IMX6SX_CLK_CKO>;
+   reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
};
 }
-- 
2.7.4

[PATCH v11 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen 
Signed-off-by: Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index c96c91d..a173de2 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include 
+
 / {
aliases {
backlight = &backlight;
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = <&gpio7 12 0>;
-   };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -188,7 +179,7 @@
 
pinctrl_usbh: usbhgrp {
fsl,pins = <
-   MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
+   MX6QDL_PAD_GPIO_17__GPIO7_IO12  0x1b0b0
MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
>;
};
@@ -259,9 +250,16 @@
 &usbh1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh>;
-   vbus-supply = <®_usb_h1_vbus>;
-   clocks = <&clks IMX6QDL_CLK_CKO>;
status = "okay";
+
+   usb2415: hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   clocks = <&clks IMX6QDL_CLK_CKO>;
+   reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
 &usdhc3 {
-- 
2.7.4

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

[Binoy Jayan]

Hi Herbert,

On 2 January 2017 at 12:23, Herbert Xu  wrote:
> On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote:
>
> Right.  The actual number of underlying tfms that do the work
> won't change compared to the status quo.  We're just structuring
> it such that if the overall scheme is supported by the hardware
> then we can feed more than one sector at a time to it.

I was thinking of continuing to have the iv generation algorithms as template
ciphers instead of regular 'skcipher' as it is easier to inherit the parameters
from the underlying cipher (e.g. aes) like cra_blocksize, cra_alignmask,
ivsize, chunksize etc.

Usually, the underlying cipher for the template ciphers are instantiated
in the following function:

skcipher_instance:skcipher_alg:init()

Since the number of such cipher instances depend on the key count, which is
not known at the time of creation of the cipher (it's passed to as an argument
to the setkey api), the creation of those have to be delayed until the setkey
operation of the template cipher. But as Mark pointed out, the users of this
cipher may get confused if the creation of the underlying cipher fails while
trying to do a 'setkey' on the template cipher. I was wondering if I can create
a single instance of the cipher and assign it to tfms[0] and allocate the
remaining instances when the setkey operation is called later with the encoded
key_count so that errors during cipher creation are uncovered earlier.

Thanks,
Binoy

[PATCH 1/2] ACPI: processor_perflib: Simplify code and stop using CPUFREQ_START

[Viresh Kumar]

acpi_processor_ppc_notifier() can live without using CPUFREQ_START
(which is gonna be removed soon). Simplify it a bit.

Signed-off-by: Viresh Kumar 
---
Rebased over: https://marc.info/?l=linux-kernel&m=148359167516831&w=2

 drivers/acpi/processor_perflib.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index f0b4a981b8d3..1ceea1143a1c 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -75,14 +75,12 @@ static int acpi_processor_ppc_notifier(struct 
notifier_block *nb,
struct acpi_processor *pr;
unsigned int ppc = 0;
 
-   if (event == CPUFREQ_START && ignore_ppc <= 0) {
-   ignore_ppc = 0;
-   return 0;
-   }
-
if (ignore_ppc)
return 0;
 
+   if (ignore_ppc < 0)
+   ignore_ppc = 0;
+
if (event != CPUFREQ_ADJUST)
return 0;
 
-- 
2.7.1.410.g6faf27b

Re: [PATCH V2 1/5] Documetation: samsung-phy: add the exynos-pcie-phy binding

[pankaj.dubey]

Hi,

On Thursday 05 January 2017 09:46 AM, Alim Akhtar wrote:
> Hi Jaehoon,
> 
> On 01/04/2017 06:04 PM, Jaehoon Chung wrote:
>> Adds the exynos-pcie-phy binding for Exynos PCIe PHY.
>> This is for using generic PHY framework.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>> Changelog on V2:
>> - Remove the child node.
>> - Add 2nd address to the parent reg prop.
>>
>>  Documentation/devicetree/bindings/phy/samsung-phy.txt | 17
>> +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 9872ba8..ab80bfe 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -191,3 +191,20 @@ Example:
>>  usbdrdphy0 = &usb3_phy0;
>>  usbdrdphy1 = &usb3_phy1;
>>  };
>> +
>> +Samsung Exynos SoC series PCIe PHY controller
>> +--
>> +Required properties:
>> +- compatible : Should be set to "samsung,exynos5440-pcie-phy"
>> +- #phy-cells : Must be zero
>> +- reg : a register used by phy driver.
>> +- First is for phy register, second is for block register.
>> +- reg-names : Must be set to "phy" and "block".
>> +
> In general PHY uses a "reference clock" to work, if that is true for
> 5440 also, will you consider adding an (may be) optional clock
> properties as well?
> 

Yes, right, second clock, referred as "bus_clk" in pcie node should
actually refer to "phy" clock. From Exynos5433 DT patch also you are
mapping it to CLK_PCLK_PCIE_PHY which is a phy clk. This is same in
Exynos7 as well. So better we have clocks property defined in pcie-phy
binding. What do you say?

>From Exynos5440 UM, PCIe-Phy needs 250 MHz, clock and second clock used
as "bus_clk" is providing 250 MHz, so this can be moved in phy driver.


Thanks,
Pankaj Dubey

[PATCH 2/2] cpufreq: Remove CPUFREQ_START notifier event

[Viresh Kumar]

Its not used anymore, remove it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 3 ---
 drivers/cpufreq/ppc_cbe_cpufreq_pmi.c | 3 ---
 include/linux/cpufreq.h   | 1 -
 3 files changed, 7 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 53268bebdf1e..408479540566 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1246,9 +1246,6 @@ static int cpufreq_online(unsigned int cpu)
write_unlock_irqrestore(&cpufreq_driver_lock, flags);
}
 
-   blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
-CPUFREQ_START, policy);
-
ret = cpufreq_init_policy(policy);
if (ret) {
pr_err("%s: Failed to initialize policy for cpu: %d (%d)\n",
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c 
b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
index dc112481a408..eeaa92251512 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
@@ -100,9 +100,6 @@ static int pmi_notifier(struct notifier_block *nb,
/* Should this really be called for CPUFREQ_ADJUST and CPUFREQ_NOTIFY
 * policy events?)
 */
-   if (event == CPUFREQ_START)
-   return 0;
-
node = cbe_cpu_to_node(policy->cpu);
 
pr_debug("got notified, event=%lu, node=%u\n", event, node);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 0183986b3ba6..61009c0b82c8 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -415,7 +415,6 @@ static inline void cpufreq_resume(void) {}
 /* Policy Notifiers  */
 #define CPUFREQ_ADJUST (0)
 #define CPUFREQ_NOTIFY (1)
-#define CPUFREQ_START  (2)
 
 #ifdef CONFIG_CPU_FREQ
 int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list);
-- 
2.7.1.410.g6faf27b

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

[Minchan Kim]

On Wed, Jan 04, 2017 at 11:19:39AM +0100, Michal Hocko wrote:
> From: Michal Hocko 
> 
> mm_vmscan_lru_isolate currently prints only whether the LRU we isolate
> from is file or anonymous but we do not know which LRU this is.
> 
> It is useful to know whether the list is active or inactive, since we
> are using the same function to isolate pages from both of them and it's
> hard to distinguish otherwise.
> 
> Chaneges since v1
> - drop LRU_ prefix from names and use lowercase as per Vlastimil
> - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil
> 
> Acked-by: Hillf Danton 
> Acked-by: Mel Gorman 
> Signed-off-by: Michal Hocko 

> ---
>  include/trace/events/mmflags.h |  8 
>  include/trace/events/vmscan.h  | 12 ++--
>  mm/vmscan.c|  2 +-
>  3 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
> index aa4caa6914a9..6172afa2fd82 100644
> --- a/include/trace/events/mmflags.h
> +++ b/include/trace/events/mmflags.h
> @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY,   "softdirty" 
> )   \
>   IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem"))\
>   EMe(ZONE_MOVABLE,"Movable")
>  
> +#define LRU_NAMES\
> + EM (LRU_INACTIVE_ANON, "inactive_anon") \
> + EM (LRU_ACTIVE_ANON, "active_anon") \
> + EM (LRU_INACTIVE_FILE, "inactive_file") \
> + EM (LRU_ACTIVE_FILE, "active_file") \
> + EMe(LRU_UNEVICTABLE, "unevictable")
> +
>  /*
>   * First define the enums in the above macros to be exported to userspace
>   * via TRACE_DEFINE_ENUM().
> @@ -253,6 +260,7 @@ COMPACTION_STATUS
>  COMPACTION_PRIORITY
>  COMPACTION_FEEDBACK
>  ZONE_TYPE
> +LRU_NAMES
>  
>  /*
>   * Now redefine the EM() and EMe() macros to map the enums to the strings
> diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
> index 36c999f806bf..7ec59e0432c4 100644
> --- a/include/trace/events/vmscan.h
> +++ b/include/trace/events/vmscan.h
> @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate,
>   unsigned long nr_skipped,
>   unsigned long nr_taken,
>   isolate_mode_t isolate_mode,
> - int file),
> + int lru),

It may break trace-vmscan-postprocess.pl. Other than that,

Acked-by: Minchan Kim 

[PATCH v11 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton 

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 7c7c1a8..79a0bd5 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
reg = <0x1000 0x4000>;
};
 
-   reg_usbh1_vbus: regulator-usbhubreset {
-   compatible = "regulator-fixed";
-   regulator-name = "usbh1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_usbh1_hubreset>;
-   gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
-   };
-
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
@@ -207,12 +195,18 @@
 };
 
 &usbh1 {
-   vbus-supply = <®_usbh1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh1>;
dr_mode = "host";
disable-over-current;
status = "okay";
+
+   usb2415host: hub@1 {
+   compatible = "usb424,2513";
+   reg = <1>;
+   reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
 &usbotg {
@@ -468,11 +462,6 @@
MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
/* usbh1_b OC */
MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-   >;
-   };
-
-   pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-   fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
>;
};
-- 
2.7.4

Re: [PATCH v6 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()

[Hanjun Guo]

On 2017/1/4 22:34, Lorenzo Pieralisi wrote:

On Mon, Jan 02, 2017 at 09:31:34PM +0800, Hanjun Guo wrote:

We are missing req_id's comment for iort_dev_find_its_id(),
add it back.


"Add missing req_id parameter to the iort_dev_find_its_id() function
kernel-doc comment."


Signed-off-by: Hanjun Guo 
Tested-by: Majun 
Tested-by: Xinwei Kong 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
---
 drivers/acpi/arm64/iort.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 46e2d82..174e983 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -446,6 +446,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
 /**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
+ * @req_id: Device's Requster ID


s/Requster/Requester

We can send it upstream independently along with some other patches
in this series but I will have a look at the whole series first.


Do you mean go to 4.10-rcx?

Thanks
Hanjun

Re: [PATCH 06/22] ARM: dtsi: axp22x: add AXP22X ADC subnode

[Chen-Yu Tsai]

On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
 wrote:
> X-Powers AXP22X PMIC has multiple ADCs, each one exposing data from the
> different power supplies connected to the PMIC.
>
> This adds the ADC subnode for AXP22X PMIC.
>
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/boot/dts/axp22x.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
> index 458b668..a2c4401 100644
> --- a/arch/arm/boot/dts/axp22x.dtsi
> +++ b/arch/arm/boot/dts/axp22x.dtsi
> @@ -52,6 +52,11 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> +   axp221_adc: axp221_adc {

Same as the last patch. Please change to "adc".

ChenYu

> +   compatible = "x-powers,axp221-adc";
> +   #io-channel-cells = <1>;
> +   };
> +
> regulators {
> /* Default work frequency for buck regulators */
> x-powers,dcdc-freq = <3000>;
> --
> 2.9.3
>

Re: [PATCH 03/22] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs

[Chen-Yu Tsai]

On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds support for most of AXP20X and AXP22X ADCs.
>
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/iio/adc/Kconfig  |  10 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/axp20x_adc.c | 490 
> +++
>  include/linux/mfd/axp20x.h   |   4 +
>  4 files changed, 505 insertions(+)
>  create mode 100644 drivers/iio/adc/axp20x_adc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 38bc319..5c5b51f 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -154,6 +154,16 @@ config AT91_SAMA5D2_ADC
>   To compile this driver as a module, choose M here: the module will 
> be
>   called at91-sama5d2_adc.
>
> +config AXP20X_ADC
> +   tristate "X-Powers AXP20X and AXP22X ADC driver"
> +   depends on MFD_AXP20X
> +   help
> + Say yes here to have support for X-Powers power management IC (PMIC)
> + AXP20X and AXP22X ADC devices.
> +
> + To compile this driver as a module, choose M here: the module will 
> be
> + called axp20x_adc.
> +
>  config AXP288_ADC
> tristate "X-Powers AXP288 ADC driver"
> depends on MFD_AXP20X
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index d36c4be..f5c28a5 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
>  obj-$(CONFIG_AD799X) += ad799x.o
>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
>  obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
> +obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
>  obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> new file mode 100644
> index 000..8df972a
> --- /dev/null
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -0,0 +1,490 @@
> +/* ADC driver for AXP20X and AXP22X PMICs
> + *
> + * Copyright (c) 2016 Free Electrons NextThing Co.
> + * Quentin Schulz 
> + *
> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define AXP20X_ADC_EN1_MASKGENMASK(7, 0)
> +
> +#define AXP20X_ADC_EN2_MASK(GENMASK(3, 2) | BIT(7))
> +#define AXP22X_ADC_EN1_MASK(GENMASK(7, 5) | BIT(0))
> +#define AXP20X_ADC_EN2_TEMP_ADCBIT(7)
> +#define AXP20X_ADC_EN2_GPIO0_ADC   BIT(3)
> +#define AXP20X_ADC_EN2_GPIO1_ADC   BIT(2)

The latter 3 individual bits aren't used anywhere.
Please remove them for now.

> +
> +#define AXP20X_GPIO10_IN_RANGE_GPIO0   BIT(0)
> +#define AXP20X_GPIO10_IN_RANGE_GPIO1   BIT(1)
> +#define AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(x)((x) & BIT(0))
> +#define AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(x)(((x) & BIT(0)) << 1)
> +
> +#define AXP20X_ADC_RATE_MASK   (3 << 6)
> +#define AXP20X_ADC_RATE_25HZ   (0 << 6)
> +#define AXP20X_ADC_RATE_50HZ   BIT(6)

Please be consistent with the format.

> +#define AXP20X_ADC_RATE_100HZ  (2 << 6)
> +#define AXP20X_ADC_RATE_200HZ  (3 << 6)
> +
> +#define AXP22X_ADC_RATE_100HZ  (0 << 6)
> +#define AXP22X_ADC_RATE_200HZ  BIT(6)
> +#define AXP22X_ADC_RATE_400HZ  (2 << 6)
> +#define AXP22X_ADC_RATE_800HZ  (3 << 6)

These are power-of-2 multiples of some base rate. May I suggest
a formula macro instead. Either way, you seem to be using only
one value. Will this be made configurable in the future?

> +
> +#define AXP20X_ADC_CHANNEL(_channel, _name, _type, _reg)   \
> +   {   \
> +   .type = _type,  \
> +   .indexed = 1,   \
> +   .channel = _channel,\
> +   .address = _reg,\
> +   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
> + BIT(IIO_CHAN_INFO_SCALE), \
> +   .datasheet_name = _name,\
> +   }
> +
> +#define AXP20X_ADC_CHANNEL_OFFSET(_channel, _name, _type, _reg) \
> +   {   \
> +

Re: [PATCH] nvmem: core: Allow ignoring length when reading a cell

[Vivek Gautam]

Hi Srinivas,

On Tue, Dec 20, 2016 at 3:17 AM, Stephen Boyd  wrote:
> On 12/19, Vivek Gautam wrote:
>> nvmem_cell_read() API fills in the argument 'len' with
>> the number of bytes read from the cell. Many users don't
>> care about this length value. So allow users to pass a
>> NULL pointer to this len field.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>
> Reviewed-by: Stephen Boyd 

Can you please pick this patch as well, adding Stephen's 'Reviewed-by' tag.


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

Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint

[Minchan Kim]

On Wed, Jan 04, 2017 at 02:52:47PM +0100, Michal Hocko wrote:
> With fixed triggered by Vlastimil it should be like this.
> ---
> From b3a1480b54bf10924a9cd09c6d8b274fc81ca4ad Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Tue, 27 Dec 2016 13:18:20 +0100
> Subject: [PATCH] mm, vmscan: add active list aging tracepoint
> 
> Our reclaim process has several tracepoints to tell us more about how
> things are progressing. We are, however, missing a tracepoint to track
> active list aging. Introduce mm_vmscan_lru_shrink_active which reports
> the number of
>   - nr_taken is number of isolated pages from the active list
>   - nr_referenced pages which tells us that we are hitting referenced
> pages which are deactivated. If this is a large part of the
> reported nr_deactivated pages then we might be hitting into
> the active list too early because they might be still part of
> the working set. This might help to debug performance issues.
>   - nr_active pages which tells us how many pages are kept on the
> active list - mostly exec file backed pages. A high number can
> indicate that we might be trashing on executables.
> 
> Changes since v1
> - report nr_taken pages as per Minchan
> - report nr_activated as per Minchan
> - do not report nr_freed pages because that would add a tiny overhead to
>   free_hot_cold_page_list which is a hot path
> - do not report nr_unevictable because we can report this number via a
>   different and more generic tracepoint in putback_lru_page
> - fix move_active_pages_to_lru to report proper page count when we hit
>   into large pages
> - drop nr_scanned because this can be obtained from
>   trace_mm_vmscan_lru_isolate as per Minchan
> 
> Acked-by: Hillf Danton 
> Acked-by: Mel Gorman 
> Signed-off-by: Michal Hocko 

Acked-by: Minchan Kim 

Thanks.

Re: [PATCH zram] extend zero pages to same element pages

[Minchan Kim]

Hello,

To me, it's a good idea although I didn't look at code in detail. :)

Could you resend it as formal patch?
Please include description, number that how we can save memory in your
workload and you name for Signed-off-by.
As well, please Cc sergey.senozhat...@gmail.com and a...@linux-foundation.org
next time.

Thanks!

On Wed, Jan 04, 2017 at 02:20:05PM +0800, zhouxianr...@huawei.com wrote:
> From: z00281421 
> 
> 
> Signed-off-by: z00281421 
> ---
>  drivers/block/zram/zram_drv.c |   67 
> ++---
>  drivers/block/zram/zram_drv.h |   11 ---
>  2 files changed, 49 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 15f58ab..c3af69a 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -94,6 +94,17 @@ static void zram_clear_flag(struct zram_meta *meta, u32 
> index,
>   meta->table[index].value &= ~BIT(flag);
>  }
>  
> +static inline void zram_set_element(struct zram_meta *meta, u32 index,
> + unsigned long element)
> +{
> + meta->table[index].element = element;
> +}
> +
> +static inline void zram_clear_element(struct zram_meta *meta, u32 index)
> +{
> + meta->table[index].element = 0;
> +}
> +
>  static size_t zram_get_obj_size(struct zram_meta *meta, u32 index)
>  {
>   return meta->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
> @@ -158,31 +169,31 @@ static inline void update_used_max(struct zram *zram,
>   } while (old_max != cur_max);
>  }
>  
> -static bool page_zero_filled(void *ptr)
> +static bool page_same_filled(void *ptr)
>  {
>   unsigned int pos;
>   unsigned long *page;
>  
>   page = (unsigned long *)ptr;
>  
> - for (pos = 0; pos != PAGE_SIZE / sizeof(*page); pos++) {
> - if (page[pos])
> + for (pos = PAGE_SIZE / sizeof(unsigned long) - 1; pos > 0; pos--) {
> + if (page[pos] != page[pos - 1])
>   return false;
>   }
>  
>   return true;
>  }
>  
> -static void handle_zero_page(struct bio_vec *bvec)
> +static void handle_same_page(struct bio_vec *bvec, unsigned long element)
>  {
>   struct page *page = bvec->bv_page;
>   void *user_mem;
>  
>   user_mem = kmap_atomic(page);
>   if (is_partial_io(bvec))
> - memset(user_mem + bvec->bv_offset, 0, bvec->bv_len);
> + memset(user_mem + bvec->bv_offset, (char)element, bvec->bv_len);
>   else
> - clear_page(user_mem);
> + memset(user_mem, (char)element, PAGE_SIZE);
>   kunmap_atomic(user_mem);
>  
>   flush_dcache_page(page);
> @@ -431,7 +442,7 @@ static ssize_t mm_stat_show(struct device *dev,
>   mem_used << PAGE_SHIFT,
>   zram->limit_pages << PAGE_SHIFT,
>   max_used << PAGE_SHIFT,
> - (u64)atomic64_read(&zram->stats.zero_pages),
> + (u64)atomic64_read(&zram->stats.same_pages),
>   pool_stats.pages_compacted);
>   up_read(&zram->init_lock);
>  
> @@ -464,7 +475,7 @@ static ssize_t debug_stat_show(struct device *dev,
>  ZRAM_ATTR_RO(failed_writes);
>  ZRAM_ATTR_RO(invalid_io);
>  ZRAM_ATTR_RO(notify_free);
> -ZRAM_ATTR_RO(zero_pages);
> +ZRAM_ATTR_RO(same_pages);
>  ZRAM_ATTR_RO(compr_data_size);
>  
>  static inline bool zram_meta_get(struct zram *zram)
> @@ -538,18 +549,20 @@ static void zram_free_page(struct zram *zram, size_t 
> index)
>   struct zram_meta *meta = zram->meta;
>   unsigned long handle = meta->table[index].handle;
>  
> - if (unlikely(!handle)) {
> - /*
> -  * No memory is allocated for zero filled pages.
> -  * Simply clear zero page flag.
> -  */
> - if (zram_test_flag(meta, index, ZRAM_ZERO)) {
> - zram_clear_flag(meta, index, ZRAM_ZERO);
> - atomic64_dec(&zram->stats.zero_pages);
> - }
> + /*
> +  * No memory is allocated for same element filled pages.
> +  * Simply clear same page flag.
> +  */
> + if (zram_test_flag(meta, index, ZRAM_SAME)) {
> + zram_clear_flag(meta, index, ZRAM_SAME);
> + zram_clear_element(meta, index);
> + atomic64_dec(&zram->stats.same_pages);
>   return;
>   }
>  
> + if (!handle)
> + return;
> +
>   zs_free(meta->mem_pool, handle);
>  
>   atomic64_sub(zram_get_obj_size(meta, index),
> @@ -572,9 +585,9 @@ static int zram_decompress_page(struct zram *zram, char 
> *mem, u32 index)
>   handle = meta->table[index].handle;
>   size = zram_get_obj_size(meta, index);
>  
> - if (!handle || zram_test_flag(meta, index, ZRAM_ZERO)) {
> + if (!handle || zram_test_flag(meta, index, ZRAM_SAME)) {
>   bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
> - clear_page(mem);
> + memset(mem

RE: [PATCH 7/7] misc: intel-ish-client: add intel ishtp clients driver

[Xu, Even]

Hi, Greg,

Thanks for your review and suggestion, I will rework my patch based on your 
suggestion and then submit again.

Best Regards,
Even Xu

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Thursday, January 5, 2017 3:41 AM
To: Srinivas Pandruvada 
Cc: Xu, Even ; ji...@kernel.org; 
benjamin.tissoi...@redhat.com; a...@arndb.de; Shevchenko, Andriy 
; linux-in...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/7] misc: intel-ish-client: add intel ishtp clients driver

On Wed, Jan 04, 2017 at 10:41:26AM -0800, Srinivas Pandruvada wrote:
> On Wed, 2017-01-04 at 18:18 +0100, Greg KH wrote:
> > On Wed, Jan 04, 2017 at 09:11:34AM -0800, Srinivas Pandruvada wrote:
> > > 
> > > On Wed, 2017-01-04 at 14:03 +0100, Greg KH wrote:
> > > > 
> > > > On Fri, Dec 23, 2016 at 09:22:29AM +0800, Even Xu wrote
> > > > > 
> [...]
> 
> > debug should not require a char device node, use debugfs, that is 
> > what it is there for.
> > 
> > For "calibration", why not use configfs or even sysfs?
> 
> We will check on this. There is some legacy with the deployed user 
> space tools.

Um, you do know that's not a good reason/excuse at all to take incorrect kernel 
code, right?  Please don't use that as any kind of excuse.

> > > Basically the ISH provided a standalone low power processor to 
> > > developers and manufacturers  to do download some custom 
> > > algorithms for sensors, which may not be compliant to USB HID 
> > > sensor specifications (mostly for IOT space). In that case the 
> > > user space for those can communicate using misc driver interface, 
> > > without adding new kernel drivers.
> > 
> > So you hide it behind a char device node?  That's not very 
> > descriptive or easy to understand :)
> We added several new sensors to IIO and in process of adding new 
> sensors to standardize ABI for sensors defined in HID sensor spec.
> 
> Customers can develop and download some algorithm which uses output of 
> several sensors and come up with some fusion sensor to detect some 
> activity. Either some kernel driver needs to read this and pass this 
> event to user space or directly let the user space communicate with 
> the firmware using character device.
> Is there any better way to handle this?
> 
> We want customers to use upstream kernel without out of tree kernel 
> drivers.

Why are you somehow claiming this is an either/or kind of situation?
What out-of-tree kernel modules are there?  Why can't they just be merged if 
they are somewhere?

Having an interface to add new types of "functionality" is great, and fine, but 
why you think a char device node is that type of api is confusing to me when I 
already pointed out an number of other potential solutions.  Have you tried 
them out and found they do not work?  If so, great, please explain what is 
lacking and we can go from there.

If not, please do some basic research first before trying to claim that a char 
device is the only possible solution.

You have run this code through the internal Intel kernel developer review 
process on their mailing list, correct?  What did they say about your current 
design?  If not, why have you not taken advantage of this resource?

thanks,

greg k-h

[PATCH] mm: Respect FOLL_FORCE/FOLL_COW for thp

[Keno Fischer]

In 19be0eaff ("mm: remove gup_flags FOLL_WRITE games from __get_user_pages()"),
the mm code was changed from unsetting FOLL_WRITE after a COW was resolved to
setting the (newly introduced) FOLL_COW instead. Simultaneously, the check in
gup.c was updated to still allow writes with FOLL_FORCE set if FOLL_COW had
also been set. However, a similar check in huge_memory.c was forgotten. As a
result, remote memory writes to ro regions of memory backed by transparent huge
pages cause an infinite loop in the kernel (handle_mm_fault sets FOLL_COW and
returns 0 causing a retry, but follow_trans_huge_pmd bails out immidiately
because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is true. While in this
state, the process is stil SIGKILLable, but little else works (e.g. no ptrace
attach, no other signals). This is easily reproduced with the following
code (assuming thp are set to always):

```
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define TEST_SIZE 5 * 1024 * 1024

int main(void) {
  int status;
  pid_t child;
  int fd = open("/proc/self/mem", O_RDWR);
  void *addr =
  mmap(NULL, TEST_SIZE, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
  assert(addr != MAP_FAILED);
  pid_t parent_pid = getpid();
  if ((child = fork()) == 0) {
void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
   MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
assert(addr2 != MAP_FAILED);
memset(addr2, 'a', TEST_SIZE);
pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
return 0;
  }
  assert(child == waitpid(child, &status, 0));
  assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
  return 0;
}
```

Fix this by updating the instances in huge_memory.c analogously to
the update in gup.c in the original commit. The same pattern existed in
follow_devmap_pmd, so I have changed that location as well. However,
I do not have a test case that for that code path.

Signed-off-by: Keno Fischer 
---
 mm/huge_memory.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 10eedbf..84497a8 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -773,6 +773,16 @@ static void touch_pmd(struct vm_area_struct *vma, unsigned 
long addr,
update_mmu_cache_pmd(vma, addr, pmd);
 }
 
+/*
+ * FOLL_FORCE can write to even unwritable pmd's, but only
+ * after we've gone through a COW cycle and they are dirty.
+ */
+static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags)
+{
+   return pmd_write(pmd) ||
+   ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+}
+
 struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
pmd_t *pmd, int flags)
 {
@@ -783,7 +793,7 @@ struct page *follow_devmap_pmd(struct vm_area_struct *vma, 
unsigned long addr,
 
assert_spin_locked(pmd_lockptr(mm, pmd));
 
-   if (flags & FOLL_WRITE && !pmd_write(*pmd))
+   if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
return NULL;
 
if (pmd_present(*pmd) && pmd_devmap(*pmd))
@@ -1137,7 +1147,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct 
*vma,
 
assert_spin_locked(pmd_lockptr(mm, pmd));
 
-   if (flags & FOLL_WRITE && !pmd_write(*pmd))
+   if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
goto out;
 
/* Avoid dumping huge zero page */
-- 
2.9.3

Re: [PATCH] scsi: qedi: return via va_end to match corresponding va_start

[Martin K. Petersen]

> "Colin" == Colin King  writes:

Colin> Although on most systems va_end is a no-op, it is good practice
Colin> to use va_end on the function return path, especially since the
Colin> va_start documenation states:

Colin>   "Each invocation of va_start() must be matched by a
Colin>   corresponding
Colin>invocation of va_end() in the same function."

Applied to 4.11/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

RE: [RFC PATCH] usb: dwc3: add support for OTG driver compilation

[Manish Narani]

Hi Felipe,


> From: Felipe Balbi [mailto:ba...@kernel.org]
> Sent: Wednesday, January 04, 2017 7:01 PM
> Hi,
>
> Manish Narani  writes:
> > This patch adds support for OTG driver compilation and object file
> > creation
> >
> > Signed-off-by: Manish Narani 
> > ---
> >  drivers/usb/dwc3/Makefile | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> > index ffca340..2d269ad 100644
> > --- a/drivers/usb/dwc3/Makefile
> > +++ b/drivers/usb/dwc3/Makefile
> > @@ -17,6 +17,10 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET)
> $(CONFIG_USB_DWC3_DUAL_ROLE)),)
> > dwc3-y  += gadget.o ep0.o
> >  endif
> >
> > +ifneq ($(CONFIG_USB_DWC3_DUAL_ROLE),)
> > +   dwc3-y  += otg.o
> > +endif
>
> you just broke compilation

Should I add new USB_DWC3_OTG macro in Kconfig?


Thanks,
Manish


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

Re: [PATCH 4.4 00/60] 4.4.40-stable review

[Guenter Roeck]

On 01/04/2017 12:46 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.40 release.
There are 60 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:06:51 UTC 2017.
Anything received after that time might be too late.


Build results:
total: 149 pass: 149 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

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

[Christoph Hellwig]

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.

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

[Christoph Hellwig]

On Wed, Jan 04, 2017 at 08:36:51PM +0100, Jan Kiszka wrote:
> No one seems to do this magically in the background, so we have to do
> the job in the exit handler that corresponds to the board setup handler.
> 
> Fixes: 60a9244a5d14 ("serial: 8250_lpss: enable MSI for Intel Quark")
> Signed-off-by: Jan Kiszka 

Looks good.   I already pointed out to Andy that we need this anyway.

Reviewed-by: Christoph Hellwig 

Re: Question regarding power button of Dell XPS13

[Daniel J Blueman]

On Monday, December 26, 2016 at 6:30:05 AM UTC+8, Linus Torvalds wrote:
> On Fri, Dec 23, 2016 at 4:36 AM, Paul Menzel  wrote:
> >
> > I heard that you both have a Dell XPS13. I got the “revision” 9360, and
> > installed Debian Stretch/testing on it with Linux 4.8.15 and Linux 4.9-rc8.
> >
> > When pressing the power button the GNOME dialog, asking what to do (restart,
> > power off, …) doesn’t appear.
>
> Hmm. I don't recall ever seeing such a dialog. But I don't run Debian.
>
> For me it works like all power buttons on my laptops have worked
> lately - it suspends the machine.
>
> Of course, so does just closing the lid.
>
> The only "bug" I've seen in this area is the design bug of the XPS13
> where there is no visible indication of the suspend state (ie the
> traditional slowly pulsing LED showing that it's all nice and
> suspended). But that seems to be intentional, if stupid. I think it's
> the only real beef I have with the XPS13.

I find the 9360 to be a solid laptop (my XPS 15 9550 would fail to
resume from suspend 15% of the time), but did any of you guys run into
bit-depth colour issues [1] on the Skylake/9350 with USB-C to HDMI
adapters?

Dan

[1] https://bugs.freedesktop.org/show_bug.cgi?id=99137
-- 
Daniel J Blueman