Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Heiner Kallweit]

Am 29.03.2016 um 23:43 schrieb Pavel Machek:
> Hi!
> 
>>> First, please Cc me on RGB color support.
>>>
 Add generic support for RGB Color LED's.

 Basic idea is to use enum led_brightness also for the hue and saturation
 color components.This allows to implement the color extension w/o
 changes to struct led_classdev.

 Select LEDS_RGB to enable building drivers using the RGB extension.

 Flag LED_SET_HUE_SAT allows to specify that hue / saturation
 should be overridden even if the provided values are zero.

 Some examples for writing values to /sys/class/leds//brightness:
 (now also hex notation can be used)

 255 -> set full brightness and keep existing color if set
 0 -> switch LED off but keep existing color so that it can be restored
  if the LED is switched on again later
 0x100 -> switch LED off and set also hue and saturation to 0
 0x00 -> set full brightness, full saturation and set hue to 0
 (red)
>>>
>>> Umm, that's rather strange interface -- and three values in single sysfs
>>> file is actually forbidden.
>>>
>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>> we already have supported in the tree. (At least nokia N900 and Sony
>>> motion controller already contain supported three-color LEDs).
>>>
>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>> they are treated as three different LEDs. (Which makes some sense, you
>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>> for green, for example). It would be good to have some kind of
>>> grouping, so that userspace can tell "these 3 leds are actually
>>> combined into one light".
>>>
>> At first thanks for the review comments.
>> Treating the three physical LEDs of a RGB LED as separate LED devices
>> might have been implemented due to the lack of alternatives.
> 
> To be fair... they _are_ separate LED devices. In N900 case, you can
> even see light comming from slightly different places if you look closely.
> 
I mainly work with encapsulated USB HID LED devices like Thingm blink(1).
Due to the diffuse plastic cover you don't see the individual LEDs on the chip.

>> With one trigger controlling the red LED and another controlling the green
>> LED we may end up with a yellow light. Not sure whether this is what
>> we want.
> 
> Well, it should be understandable for most people.
> 
>> One driver for this extension was the idea of triggers using color
>> to visualize states etc.
>> Therefore it's not only about userspace controlling the color.
>> As a trigger is bound to a led_classdev we need a led_classdev
>> representing a RGB LED device.
>>
>> And ok: If required the sysfs interface can be splitted into separate
>> attributes for hue, saturation, and (existing) brightness.
> 
> Required.
> 
> Ok, so:
> 
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
> 
> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> and it is what hardware implements. (But we'd need to do gamma
> correction).
> 
HSV has the charme that the current monochrome V-only is a subset.
Therefore the current API can be used also with color LEDs.
However there might be good reasons for using RGB too.

> c) My hardware has "acceleration engine", LED is independend from
> CPU. That's rather big deal. Does yours? It seems to be quite common,
> at least in cellphones.
> 
Devices like blink(1) support storing and re-playing patterns, fading etc.

> Ideally, I'd like to have "triggers", but different ones. As in: if
> charging, do yellow " .xX" pattern. If fully charged, do green steady
> light. If message is waiting, do blue " x x" pattern. If none of
> above, do slow white blinking. (Plus priorities of events). But that's
> quite different from existing support...)
> 
I think for this a separate layer would be helpful.
Your primary intention is to e.g. display "charging" on the RGB LED
device. Most likely you don't want to split yellow into its red + green
component and then write to the respective (sub-)LEDs.
Also just think of the case that later you might decide that orange
is nicer than yellow.

>   Pavel
> 

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Heiner Kallweit]

Am 29.03.2016 um 23:43 schrieb Pavel Machek:
> Hi!
> 
>>> First, please Cc me on RGB color support.
>>>
 Add generic support for RGB Color LED's.

 Basic idea is to use enum led_brightness also for the hue and saturation
 color components.This allows to implement the color extension w/o
 changes to struct led_classdev.

 Select LEDS_RGB to enable building drivers using the RGB extension.

 Flag LED_SET_HUE_SAT allows to specify that hue / saturation
 should be overridden even if the provided values are zero.

 Some examples for writing values to /sys/class/leds//brightness:
 (now also hex notation can be used)

 255 -> set full brightness and keep existing color if set
 0 -> switch LED off but keep existing color so that it can be restored
  if the LED is switched on again later
 0x100 -> switch LED off and set also hue and saturation to 0
 0x00 -> set full brightness, full saturation and set hue to 0
 (red)
>>>
>>> Umm, that's rather strange interface -- and three values in single sysfs
>>> file is actually forbidden.
>>>
>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>> we already have supported in the tree. (At least nokia N900 and Sony
>>> motion controller already contain supported three-color LEDs).
>>>
>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>> they are treated as three different LEDs. (Which makes some sense, you
>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>> for green, for example). It would be good to have some kind of
>>> grouping, so that userspace can tell "these 3 leds are actually
>>> combined into one light".
>>>
>> At first thanks for the review comments.
>> Treating the three physical LEDs of a RGB LED as separate LED devices
>> might have been implemented due to the lack of alternatives.
> 
> To be fair... they _are_ separate LED devices. In N900 case, you can
> even see light comming from slightly different places if you look closely.
> 
I mainly work with encapsulated USB HID LED devices like Thingm blink(1).
Due to the diffuse plastic cover you don't see the individual LEDs on the chip.

>> With one trigger controlling the red LED and another controlling the green
>> LED we may end up with a yellow light. Not sure whether this is what
>> we want.
> 
> Well, it should be understandable for most people.
> 
>> One driver for this extension was the idea of triggers using color
>> to visualize states etc.
>> Therefore it's not only about userspace controlling the color.
>> As a trigger is bound to a led_classdev we need a led_classdev
>> representing a RGB LED device.
>>
>> And ok: If required the sysfs interface can be splitted into separate
>> attributes for hue, saturation, and (existing) brightness.
> 
> Required.
> 
> Ok, so:
> 
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
> 
> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> and it is what hardware implements. (But we'd need to do gamma
> correction).
> 
HSV has the charme that the current monochrome V-only is a subset.
Therefore the current API can be used also with color LEDs.
However there might be good reasons for using RGB too.

> c) My hardware has "acceleration engine", LED is independend from
> CPU. That's rather big deal. Does yours? It seems to be quite common,
> at least in cellphones.
> 
Devices like blink(1) support storing and re-playing patterns, fading etc.

> Ideally, I'd like to have "triggers", but different ones. As in: if
> charging, do yellow " .xX" pattern. If fully charged, do green steady
> light. If message is waiting, do blue " x x" pattern. If none of
> above, do slow white blinking. (Plus priorities of events). But that's
> quite different from existing support...)
> 
I think for this a separate layer would be helpful.
Your primary intention is to e.g. display "charging" on the RGB LED
device. Most likely you don't want to split yellow into its red + green
component and then write to the respective (sub-)LEDs.
Also just think of the case that later you might decide that orange
is nicer than yellow.

>   Pavel
> 

[lkp] [mm] 39a1aa8e19: will-it-scale.per_process_ops +5.2% improvement

[kernel test robot]

FYI, we noticed that will-it-scale.per_process_ops +5.2% improvement with your 
commit.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 39a1aa8e194ab67983de3b9d0b204ccee12e689a ("mm: deduplicate memory 
overcommitment code")


=
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
  
gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/ivb42/malloc1/will-it-scale

commit: 
  ea606cf5d8df370e7932460dfd960b21f20e7c6d
  39a1aa8e194ab67983de3b9d0b204ccee12e689a

ea606cf5d8df370e 39a1aa8e194ab67983de3b9d0b 
 -- 
 %stddev %change %stddev
 \  |\  
101461 ±  0%  +5.2% 106703 ±  0%  will-it-scale.per_process_ops
  0.10 ±  0% +31.8%   0.13 ±  0%  will-it-scale.scalability
  6966 ±  8%  -9.9%   6278 ± 10%  meminfo.AnonHugePages
  62767556 ± 10% -24.3%   47486848 ±  7%  cpuidle.C3-IVT.time
232686 ±  5% -18.4% 189919 ±  9%  cpuidle.C3-IVT.usage
   6823970 ±  3%  -8.9%6214309 ±  4%  cpuidle.C6-IVT.usage
 66703 ±  0% +12.2%  74872 ±  2%  numa-vmstat.node0.numa_other
  37441585 ±  0% +26.4%   47319887 ±  0%  numa-vmstat.node1.numa_hit
  37417000 ±  0% +26.4%   47303041 ±  0%  numa-vmstat.node1.numa_local
 24584 ±  0% -31.5%  16845 ± 11%  numa-vmstat.node1.numa_other
  6.15 ± 31% +36.2%   8.37 ± 15%  sched_debug.cpu.cpu_load[4].stddev
 20260 ±  6% +13.4%  22965 ±  5%  sched_debug.cpu.nr_switches.min
  4450 ±  9% +16.5%   5183 ±  8%  sched_debug.cpu.ttwu_local.max
920.59 ± 10% +15.0%   1058 ±  7%  sched_debug.cpu.ttwu_local.stddev
  2.59e+08 ±  0% +13.9%   2.95e+08 ±  0%  numa-numastat.node0.local_node
  2.59e+08 ±  0% +13.9%   2.95e+08 ±  0%  numa-numastat.node0.numa_hit
 10.25 ±119%  +75378.0%   7736 ± 19%  numa-numastat.node0.other_node
 1.097e+08 ±  0% +28.0%  1.404e+08 ±  0%  numa-numastat.node1.local_node
 1.097e+08 ±  0% +28.0%  1.404e+08 ±  0%  numa-numastat.node1.numa_hit
  9285 ±  0% -83.1%   1568 ± 98%  numa-numastat.node1.other_node
 3.687e+08 ±  0% +18.1%  4.354e+08 ±  0%  proc-vmstat.numa_hit
 3.687e+08 ±  0% +18.1%  4.354e+08 ±  0%  proc-vmstat.numa_local
  52281716 ±  0% +11.1%   58060959 ±  1%  proc-vmstat.pgalloc_dma32
 3.943e+08 ±  0% +16.7%  4.603e+08 ±  0%  proc-vmstat.pgalloc_normal
 1.854e+08 ±  0% +18.0%  2.187e+08 ±  0%  proc-vmstat.pgfault
 4.465e+08 ±  0% +16.1%  5.183e+08 ±  0%  proc-vmstat.pgfree
  0.00 ± -1%  +Inf%   2.36 ± 12%  
perf-profile.cycles-pp.__split_vma.isra.36.do_munmap.vm_munmap.sys_munmap.entry_SYSCALL_64_fastpath
  2.38 ±  8%-100.0%   0.00 ± -1%  
perf-profile.cycles-pp.__split_vma.isra.37.do_munmap.vm_munmap.sys_munmap.entry_SYSCALL_64_fastpath
  4.37 ± 31% +32.9%   5.80 ± 15%  
perf-profile.cycles-pp.call_cpuidle.cpu_startup_entry.rest_init.start_kernel.x86_64_start_reservations
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.cpu_startup_entry.rest_init.start_kernel.x86_64_start_reservations.x86_64_start_kernel
  4.37 ± 31% +32.9%   5.80 ± 15%  
perf-profile.cycles-pp.cpuidle_enter.call_cpuidle.cpu_startup_entry.rest_init.start_kernel
  4.08 ± 34% +39.8%   5.70 ± 15%  
perf-profile.cycles-pp.cpuidle_enter_state.cpuidle_enter.call_cpuidle.cpu_startup_entry.rest_init
  0.89 ±  6% +16.3%   1.04 ±  5%  
perf-profile.cycles-pp.perf_event_aux.part.46.perf_event_mmap.mmap_region.do_mmap.vm_mmap_pgoff
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.rest_init.start_kernel.x86_64_start_reservations.x86_64_start_kernel
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.start_kernel.x86_64_start_reservations.x86_64_start_kernel
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.x86_64_start_kernel
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.x86_64_start_reservations.x86_64_start_kernel


ivb42: Ivytown Ivy Bridge-EP
Memory: 64G



  will-it-scale.scalability

   0.14 ++----O-+
  0.135 ++   O  OOO |
|  OO  O O  |
   0.13 OO  O OO    |
  0.125 ++O |
|   |
   0.12 ++  |
  0.115 ++  |
   0.11 ++  |
  

[lkp] [mm] 39a1aa8e19: will-it-scale.per_process_ops +5.2% improvement

[kernel test robot]

FYI, we noticed that will-it-scale.per_process_ops +5.2% improvement with your 
commit.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 39a1aa8e194ab67983de3b9d0b204ccee12e689a ("mm: deduplicate memory 
overcommitment code")


=
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
  
gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/ivb42/malloc1/will-it-scale

commit: 
  ea606cf5d8df370e7932460dfd960b21f20e7c6d
  39a1aa8e194ab67983de3b9d0b204ccee12e689a

ea606cf5d8df370e 39a1aa8e194ab67983de3b9d0b 
 -- 
 %stddev %change %stddev
 \  |\  
101461 ±  0%  +5.2% 106703 ±  0%  will-it-scale.per_process_ops
  0.10 ±  0% +31.8%   0.13 ±  0%  will-it-scale.scalability
  6966 ±  8%  -9.9%   6278 ± 10%  meminfo.AnonHugePages
  62767556 ± 10% -24.3%   47486848 ±  7%  cpuidle.C3-IVT.time
232686 ±  5% -18.4% 189919 ±  9%  cpuidle.C3-IVT.usage
   6823970 ±  3%  -8.9%6214309 ±  4%  cpuidle.C6-IVT.usage
 66703 ±  0% +12.2%  74872 ±  2%  numa-vmstat.node0.numa_other
  37441585 ±  0% +26.4%   47319887 ±  0%  numa-vmstat.node1.numa_hit
  37417000 ±  0% +26.4%   47303041 ±  0%  numa-vmstat.node1.numa_local
 24584 ±  0% -31.5%  16845 ± 11%  numa-vmstat.node1.numa_other
  6.15 ± 31% +36.2%   8.37 ± 15%  sched_debug.cpu.cpu_load[4].stddev
 20260 ±  6% +13.4%  22965 ±  5%  sched_debug.cpu.nr_switches.min
  4450 ±  9% +16.5%   5183 ±  8%  sched_debug.cpu.ttwu_local.max
920.59 ± 10% +15.0%   1058 ±  7%  sched_debug.cpu.ttwu_local.stddev
  2.59e+08 ±  0% +13.9%   2.95e+08 ±  0%  numa-numastat.node0.local_node
  2.59e+08 ±  0% +13.9%   2.95e+08 ±  0%  numa-numastat.node0.numa_hit
 10.25 ±119%  +75378.0%   7736 ± 19%  numa-numastat.node0.other_node
 1.097e+08 ±  0% +28.0%  1.404e+08 ±  0%  numa-numastat.node1.local_node
 1.097e+08 ±  0% +28.0%  1.404e+08 ±  0%  numa-numastat.node1.numa_hit
  9285 ±  0% -83.1%   1568 ± 98%  numa-numastat.node1.other_node
 3.687e+08 ±  0% +18.1%  4.354e+08 ±  0%  proc-vmstat.numa_hit
 3.687e+08 ±  0% +18.1%  4.354e+08 ±  0%  proc-vmstat.numa_local
  52281716 ±  0% +11.1%   58060959 ±  1%  proc-vmstat.pgalloc_dma32
 3.943e+08 ±  0% +16.7%  4.603e+08 ±  0%  proc-vmstat.pgalloc_normal
 1.854e+08 ±  0% +18.0%  2.187e+08 ±  0%  proc-vmstat.pgfault
 4.465e+08 ±  0% +16.1%  5.183e+08 ±  0%  proc-vmstat.pgfree
  0.00 ± -1%  +Inf%   2.36 ± 12%  
perf-profile.cycles-pp.__split_vma.isra.36.do_munmap.vm_munmap.sys_munmap.entry_SYSCALL_64_fastpath
  2.38 ±  8%-100.0%   0.00 ± -1%  
perf-profile.cycles-pp.__split_vma.isra.37.do_munmap.vm_munmap.sys_munmap.entry_SYSCALL_64_fastpath
  4.37 ± 31% +32.9%   5.80 ± 15%  
perf-profile.cycles-pp.call_cpuidle.cpu_startup_entry.rest_init.start_kernel.x86_64_start_reservations
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.cpu_startup_entry.rest_init.start_kernel.x86_64_start_reservations.x86_64_start_kernel
  4.37 ± 31% +32.9%   5.80 ± 15%  
perf-profile.cycles-pp.cpuidle_enter.call_cpuidle.cpu_startup_entry.rest_init.start_kernel
  4.08 ± 34% +39.8%   5.70 ± 15%  
perf-profile.cycles-pp.cpuidle_enter_state.cpuidle_enter.call_cpuidle.cpu_startup_entry.rest_init
  0.89 ±  6% +16.3%   1.04 ±  5%  
perf-profile.cycles-pp.perf_event_aux.part.46.perf_event_mmap.mmap_region.do_mmap.vm_mmap_pgoff
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.rest_init.start_kernel.x86_64_start_reservations.x86_64_start_kernel
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.start_kernel.x86_64_start_reservations.x86_64_start_kernel
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.x86_64_start_kernel
  4.52 ± 28% +29.4%   5.85 ± 14%  
perf-profile.cycles-pp.x86_64_start_reservations.x86_64_start_kernel


ivb42: Ivytown Ivy Bridge-EP
Memory: 64G



  will-it-scale.scalability

   0.14 ++----O-+
  0.135 ++   O  OOO |
|  OO  O O  |
   0.13 OO  O OO    |
  0.125 ++O |
|   |
   0.12 ++  |
  0.115 ++  |
   0.11 ++  |
  

[lkp] [drm/i915] 946ec703e5: No primary change, piglit.time.elapsed_time -59.2% improvement

[kernel test robot]

linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/linux-headers.cgz"
repeat_to: 2
kernel: 
"/pkg/linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/vmlinuz-4.5.0-rc7-01401-g946ec70"
dequeue_time: 2016-03-30 07:50:42.174878631 +08:00
job_state: finished
loadavg: 1.03 0.42 0.15 1/127 678
start_time: '1459295492'
end_time: '1459295548'
version: "/lkp/lkp/.src-20160329-212132"
2016-03-30 07:51:32 piglit run igt -t igt/kms_cursor_crc/cursor-128-onscreen 
/tmp/lkp/piglit-results
2016-03-30 07:52:28 piglit summary console /tmp/lkp/piglit-results/results.json

[lkp] [drm/i915] 946ec703e5: No primary change, piglit.time.elapsed_time -59.2% improvement

[kernel test robot]

linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/linux-headers.cgz"
repeat_to: 2
kernel: 
"/pkg/linux/x86_64-rhel/gcc-4.9/946ec703e5cf439a503a218345afa74e35aaf950/vmlinuz-4.5.0-rc7-01401-g946ec70"
dequeue_time: 2016-03-30 07:50:42.174878631 +08:00
job_state: finished
loadavg: 1.03 0.42 0.15 1/127 678
start_time: '1459295492'
end_time: '1459295548'
version: "/lkp/lkp/.src-20160329-212132"
2016-03-30 07:51:32 piglit run igt -t igt/kms_cursor_crc/cursor-128-onscreen 
/tmp/lkp/piglit-results
2016-03-30 07:52:28 piglit summary console /tmp/lkp/piglit-results/results.json

[PATCH] tpm: remove redundant code from self-test functions

[Jarkko Sakkinen]

Self-test functions construct PCR read calls by ad hoc, which is only a
waste space. Use instead tpm_pcr_read_dev (renamed as tpm1_pcr_read() by
this commit) in tpm_do_selftest and tpm2_pcr_read() in
tpm2_do_selftest() functions in order to remove the duplicate code.

Patch can be tested easily tested by running the a kernel with this
patch compiled in since self-test is done when the a device driver
initializes.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-interface.c | 14 +-
 drivers/char/tpm/tpm2-cmd.c  | 14 ++
 2 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 5397b64..0c8140f 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2004 IBM Corporation
- * Copyright (C) 2014 Intel Corporation
+ * Copyright (C) 2014, 2016 Intel Corporation
  *
  * Authors:
  * Leendert van Doorn 
@@ -666,7 +666,7 @@ static struct tpm_input_header pcrread_header = {
.ordinal = TPM_ORDINAL_PCRREAD
 };
 
-int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
+int tpm1_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
 {
int rc;
struct tpm_cmd_t cmd;
@@ -676,7 +676,7 @@ int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 
*res_buf)
rc = tpm_transmit_cmd(chip, , READ_PCR_RESULT_SIZE,
  "attempting to read a pcr value");
 
-   if (rc == 0)
+   if (rc == 0 && res_buf)
memcpy(res_buf, cmd.params.pcrread_out.pcr_result,
   TPM_DIGEST_SIZE);
return rc;
@@ -728,7 +728,7 @@ int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf)
if (chip->flags & TPM_CHIP_FLAG_TPM2)
rc = tpm2_pcr_read(chip, pcr_idx, res_buf);
else
-   rc = tpm_pcr_read_dev(chip, pcr_idx, res_buf);
+   rc = tpm1_pcr_read(chip, pcr_idx, res_buf);
tpm_put_ops(chip);
return rc;
 }
@@ -793,7 +793,6 @@ int tpm_do_selftest(struct tpm_chip *chip)
unsigned int loops;
unsigned int delay_msec = 100;
unsigned long duration;
-   struct tpm_cmd_t cmd;
 
duration = tpm_calc_ordinal_duration(chip, TPM_ORD_CONTINUE_SELFTEST);
 
@@ -808,9 +807,7 @@ int tpm_do_selftest(struct tpm_chip *chip)
 
do {
/* Attempt to read a PCR value */
-   cmd.header.in = pcrread_header;
-   cmd.params.pcrread_in.pcr_idx = cpu_to_be32(0);
-   rc = tpm_transmit(chip, (u8 *) , READ_PCR_RESULT_SIZE);
+   rc = tpm1_pcr_read(chip, 0, NULL);
/* Some buggy TPMs will not respond to tpm_tis_ready() for
 * around 300ms while the self test is ongoing, keep trying
 * until the self test duration expires. */
@@ -825,7 +822,6 @@ int tpm_do_selftest(struct tpm_chip *chip)
if (rc < TPM_HEADER_SIZE)
return -EFAULT;
 
-   rc = be32_to_cpu(cmd.header.out.return_code);
if (rc == TPM_ERR_DISABLED || rc == TPM_ERR_DEACTIVATED) {
dev_info(>dev,
 "TPM is disabled/deactivated (0x%X)\n", rc);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 5fc0e7c..afe8d47 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -284,7 +284,7 @@ int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 
*res_buf)
 
rc = tpm_transmit_cmd(chip, , sizeof(cmd),
  "attempting to read a pcr value");
-   if (rc == 0) {
+   if (rc == 0 && res_buf) {
buf = cmd.params.pcrread_out.digest;
memcpy(res_buf, buf, TPM_DIGEST_SIZE);
}
@@ -861,7 +861,6 @@ int tpm2_do_selftest(struct tpm_chip *chip)
unsigned int loops;
unsigned int delay_msec = 100;
unsigned long duration;
-   struct tpm2_cmd cmd;
int i;
 
duration = tpm2_calc_ordinal_duration(chip, TPM2_CC_SELF_TEST);
@@ -874,19 +873,10 @@ int tpm2_do_selftest(struct tpm_chip *chip)
 
for (i = 0; i < loops; i++) {
/* Attempt to read a PCR value */
-   cmd.header.in = tpm2_pcrread_header;
-   cmd.params.pcrread_in.pcr_selects_cnt = cpu_to_be32(1);
-   cmd.params.pcrread_in.hash_alg = cpu_to_be16(TPM2_ALG_SHA1);
-   cmd.params.pcrread_in.pcr_select_size = TPM2_PCR_SELECT_MIN;
-   cmd.params.pcrread_in.pcr_select[0] = 0x01;
-   cmd.params.pcrread_in.pcr_select[1] = 0x00;
-   cmd.params.pcrread_in.pcr_select[2] = 0x00;
-
-   rc = tpm_transmit_cmd(chip, (u8 *) , sizeof(cmd), NULL);
+   rc = tpm2_pcr_read(chip, 0, NULL);
if (rc < 0)
break;

[PATCH] tpm: remove redundant code from self-test functions

[Jarkko Sakkinen]

Self-test functions construct PCR read calls by ad hoc, which is only a
waste space. Use instead tpm_pcr_read_dev (renamed as tpm1_pcr_read() by
this commit) in tpm_do_selftest and tpm2_pcr_read() in
tpm2_do_selftest() functions in order to remove the duplicate code.

Patch can be tested easily tested by running the a kernel with this
patch compiled in since self-test is done when the a device driver
initializes.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-interface.c | 14 +-
 drivers/char/tpm/tpm2-cmd.c  | 14 ++
 2 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 5397b64..0c8140f 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2004 IBM Corporation
- * Copyright (C) 2014 Intel Corporation
+ * Copyright (C) 2014, 2016 Intel Corporation
  *
  * Authors:
  * Leendert van Doorn 
@@ -666,7 +666,7 @@ static struct tpm_input_header pcrread_header = {
.ordinal = TPM_ORDINAL_PCRREAD
 };
 
-int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
+int tpm1_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
 {
int rc;
struct tpm_cmd_t cmd;
@@ -676,7 +676,7 @@ int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 
*res_buf)
rc = tpm_transmit_cmd(chip, , READ_PCR_RESULT_SIZE,
  "attempting to read a pcr value");
 
-   if (rc == 0)
+   if (rc == 0 && res_buf)
memcpy(res_buf, cmd.params.pcrread_out.pcr_result,
   TPM_DIGEST_SIZE);
return rc;
@@ -728,7 +728,7 @@ int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf)
if (chip->flags & TPM_CHIP_FLAG_TPM2)
rc = tpm2_pcr_read(chip, pcr_idx, res_buf);
else
-   rc = tpm_pcr_read_dev(chip, pcr_idx, res_buf);
+   rc = tpm1_pcr_read(chip, pcr_idx, res_buf);
tpm_put_ops(chip);
return rc;
 }
@@ -793,7 +793,6 @@ int tpm_do_selftest(struct tpm_chip *chip)
unsigned int loops;
unsigned int delay_msec = 100;
unsigned long duration;
-   struct tpm_cmd_t cmd;
 
duration = tpm_calc_ordinal_duration(chip, TPM_ORD_CONTINUE_SELFTEST);
 
@@ -808,9 +807,7 @@ int tpm_do_selftest(struct tpm_chip *chip)
 
do {
/* Attempt to read a PCR value */
-   cmd.header.in = pcrread_header;
-   cmd.params.pcrread_in.pcr_idx = cpu_to_be32(0);
-   rc = tpm_transmit(chip, (u8 *) , READ_PCR_RESULT_SIZE);
+   rc = tpm1_pcr_read(chip, 0, NULL);
/* Some buggy TPMs will not respond to tpm_tis_ready() for
 * around 300ms while the self test is ongoing, keep trying
 * until the self test duration expires. */
@@ -825,7 +822,6 @@ int tpm_do_selftest(struct tpm_chip *chip)
if (rc < TPM_HEADER_SIZE)
return -EFAULT;
 
-   rc = be32_to_cpu(cmd.header.out.return_code);
if (rc == TPM_ERR_DISABLED || rc == TPM_ERR_DEACTIVATED) {
dev_info(>dev,
 "TPM is disabled/deactivated (0x%X)\n", rc);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 5fc0e7c..afe8d47 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -284,7 +284,7 @@ int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 
*res_buf)
 
rc = tpm_transmit_cmd(chip, , sizeof(cmd),
  "attempting to read a pcr value");
-   if (rc == 0) {
+   if (rc == 0 && res_buf) {
buf = cmd.params.pcrread_out.digest;
memcpy(res_buf, buf, TPM_DIGEST_SIZE);
}
@@ -861,7 +861,6 @@ int tpm2_do_selftest(struct tpm_chip *chip)
unsigned int loops;
unsigned int delay_msec = 100;
unsigned long duration;
-   struct tpm2_cmd cmd;
int i;
 
duration = tpm2_calc_ordinal_duration(chip, TPM2_CC_SELF_TEST);
@@ -874,19 +873,10 @@ int tpm2_do_selftest(struct tpm_chip *chip)
 
for (i = 0; i < loops; i++) {
/* Attempt to read a PCR value */
-   cmd.header.in = tpm2_pcrread_header;
-   cmd.params.pcrread_in.pcr_selects_cnt = cpu_to_be32(1);
-   cmd.params.pcrread_in.hash_alg = cpu_to_be16(TPM2_ALG_SHA1);
-   cmd.params.pcrread_in.pcr_select_size = TPM2_PCR_SELECT_MIN;
-   cmd.params.pcrread_in.pcr_select[0] = 0x01;
-   cmd.params.pcrread_in.pcr_select[1] = 0x00;
-   cmd.params.pcrread_in.pcr_select[2] = 0x00;
-
-   rc = tpm_transmit_cmd(chip, (u8 *) , sizeof(cmd), NULL);
+   rc = tpm2_pcr_read(chip, 0, NULL);
if (rc < 0)
break;
 
-   rc = 

Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data

[Viresh Kumar]

On 30-03-16, 04:00, Rafael J. Wysocki wrote:
> +static int sugov_init(struct cpufreq_policy *policy)
> +{
> + struct sugov_policy *sg_policy;
> + struct sugov_tunables *tunables;
> + unsigned int lat;
> + int ret = 0;
> +
> + /* State should be equivalent to EXIT */
> + if (policy->governor_data)
> + return -EBUSY;
> +
> + sg_policy = sugov_policy_alloc(policy);
> + if (!sg_policy)
> + return -ENOMEM;
> +
> + mutex_lock(_tunables_lock);
> +
> + if (global_tunables) {
> + if (WARN_ON(have_governor_per_policy())) {
> + ret = -EINVAL;
> + goto free_sg_policy;
> + }
> + policy->governor_data = sg_policy;
> + sg_policy->tunables = global_tunables;
> +
> + gov_attr_set_get(_tunables->attr_set, 
> _policy->tunables_hook);
> + goto out;
> + }
> +
> + tunables = sugov_tunables_alloc(sg_policy);
> + if (!tunables) {
> + ret = -ENOMEM;
> + goto free_sg_policy;
> + }
> +
> + tunables->rate_limit_us = LATENCY_MULTIPLIER;
> + lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
> + if (lat)
> + tunables->rate_limit_us *= lat;
> +
> + policy->governor_data = sg_policy;
> + sg_policy->tunables = tunables;
> +
> + ret = kobject_init_and_add(>attr_set.kobj, 
> _tunables_ktype,
> +get_governor_parent_kobj(policy), "%s",
> +schedutil_gov.name);
> + if (ret)
> + goto fail;
> +
> + out:
> + mutex_unlock(_tunables_lock);
> +
> + cpufreq_enable_fast_switch(policy);
> + return 0;
> +
> + fail:
> + policy->governor_data = NULL;
> + sugov_tunables_free(tunables);
> +
> + free_sg_policy:
> + mutex_unlock(_tunables_lock);
> +
> + sugov_policy_free(sg_policy);
> + pr_err("cpufreq: schedutil governor initialization failed (error 
> %d)\n", ret);
> + return ret;
> +}

The current version of this looks good to me and takes care of all the issues I
raised earlier. Thanks.

> +static int sugov_limits(struct cpufreq_policy *policy)
> +{
> + struct sugov_policy *sg_policy = policy->governor_data;
> +
> + if (!policy->fast_switch_enabled) {
> + mutex_lock(_policy->work_lock);
> +
> + if (policy->max < policy->cur)
> + __cpufreq_driver_target(policy, policy->max,
> + CPUFREQ_RELATION_H);
> + else if (policy->min > policy->cur)
> + __cpufreq_driver_target(policy, policy->min,
> + CPUFREQ_RELATION_L);
> +
> + mutex_unlock(_policy->work_lock);
> + }
> +
> + sg_policy->need_freq_update = true;

I am wondering why we need to do this for !fast_switch_enabled case?

> + return 0;
> +}

Apart from that:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data

[Viresh Kumar]

On 30-03-16, 04:00, Rafael J. Wysocki wrote:
> +static int sugov_init(struct cpufreq_policy *policy)
> +{
> + struct sugov_policy *sg_policy;
> + struct sugov_tunables *tunables;
> + unsigned int lat;
> + int ret = 0;
> +
> + /* State should be equivalent to EXIT */
> + if (policy->governor_data)
> + return -EBUSY;
> +
> + sg_policy = sugov_policy_alloc(policy);
> + if (!sg_policy)
> + return -ENOMEM;
> +
> + mutex_lock(_tunables_lock);
> +
> + if (global_tunables) {
> + if (WARN_ON(have_governor_per_policy())) {
> + ret = -EINVAL;
> + goto free_sg_policy;
> + }
> + policy->governor_data = sg_policy;
> + sg_policy->tunables = global_tunables;
> +
> + gov_attr_set_get(_tunables->attr_set, 
> _policy->tunables_hook);
> + goto out;
> + }
> +
> + tunables = sugov_tunables_alloc(sg_policy);
> + if (!tunables) {
> + ret = -ENOMEM;
> + goto free_sg_policy;
> + }
> +
> + tunables->rate_limit_us = LATENCY_MULTIPLIER;
> + lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
> + if (lat)
> + tunables->rate_limit_us *= lat;
> +
> + policy->governor_data = sg_policy;
> + sg_policy->tunables = tunables;
> +
> + ret = kobject_init_and_add(>attr_set.kobj, 
> _tunables_ktype,
> +get_governor_parent_kobj(policy), "%s",
> +schedutil_gov.name);
> + if (ret)
> + goto fail;
> +
> + out:
> + mutex_unlock(_tunables_lock);
> +
> + cpufreq_enable_fast_switch(policy);
> + return 0;
> +
> + fail:
> + policy->governor_data = NULL;
> + sugov_tunables_free(tunables);
> +
> + free_sg_policy:
> + mutex_unlock(_tunables_lock);
> +
> + sugov_policy_free(sg_policy);
> + pr_err("cpufreq: schedutil governor initialization failed (error 
> %d)\n", ret);
> + return ret;
> +}

The current version of this looks good to me and takes care of all the issues I
raised earlier. Thanks.

> +static int sugov_limits(struct cpufreq_policy *policy)
> +{
> + struct sugov_policy *sg_policy = policy->governor_data;
> +
> + if (!policy->fast_switch_enabled) {
> + mutex_lock(_policy->work_lock);
> +
> + if (policy->max < policy->cur)
> + __cpufreq_driver_target(policy, policy->max,
> + CPUFREQ_RELATION_H);
> + else if (policy->min > policy->cur)
> + __cpufreq_driver_target(policy, policy->min,
> + CPUFREQ_RELATION_L);
> +
> + mutex_unlock(_policy->work_lock);
> + }
> +
> + sg_policy->need_freq_update = true;

I am wondering why we need to do this for !fast_switch_enabled case?

> + return 0;
> +}

Apart from that:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 06/16] wcn36xx: Fetch private sta data from sta entry instead of from vif

[Kalle Valo]

Bjorn Andersson  writes:

>> All error/warnings (new ones prefixed by >>):
>> 
>>drivers/net/wireless/ath/wcn36xx/main.c: In function 'wcn36xx_set_key':
>> >> drivers/net/wireless/ath/wcn36xx/main.c:389:9: error: implicit 
>> >> declaration of function 'wcn36xx_sta_to_priv' 
>> >> [-Werror=implicit-function-declaration]
>>  struct wcn36xx_sta *sta_priv = wcn36xx_sta_to_priv(sta);
>> ^
>> >> drivers/net/wireless/ath/wcn36xx/main.c:389:33: warning: initialization 
>> >> makes pointer from integer without a cast
>>  struct wcn36xx_sta *sta_priv = wcn36xx_sta_to_priv(sta);
>> ^
>>cc1: some warnings being treated as errors
>
> This should have been reordered with patch 7, that introduces this
> helper function. Do you want me to resend, or can you apply the patches
> out of order?

It's better that you resend the whole patchset as v2.

-- 
Kalle Valo

Re: [PATCH 06/16] wcn36xx: Fetch private sta data from sta entry instead of from vif

[Kalle Valo]

Bjorn Andersson  writes:

>> All error/warnings (new ones prefixed by >>):
>> 
>>drivers/net/wireless/ath/wcn36xx/main.c: In function 'wcn36xx_set_key':
>> >> drivers/net/wireless/ath/wcn36xx/main.c:389:9: error: implicit 
>> >> declaration of function 'wcn36xx_sta_to_priv' 
>> >> [-Werror=implicit-function-declaration]
>>  struct wcn36xx_sta *sta_priv = wcn36xx_sta_to_priv(sta);
>> ^
>> >> drivers/net/wireless/ath/wcn36xx/main.c:389:33: warning: initialization 
>> >> makes pointer from integer without a cast
>>  struct wcn36xx_sta *sta_priv = wcn36xx_sta_to_priv(sta);
>> ^
>>cc1: some warnings being treated as errors
>
> This should have been reordered with patch 7, that introduces this
> helper function. Do you want me to resend, or can you apply the patches
> out of order?

It's better that you resend the whole patchset as v2.

-- 
Kalle Valo

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

[Phil Reid]

On 30/03/2016 1:01 PM, Yong Li wrote:

Or another method is using the below to convert the u8 to u16:
cpu_to_le16(get_unaligned((u16 *) val)), compared with the
i2c_smbus_write_byte_data method, which one is better?




G'day Yong,

I'd go with the cpu_to_le16(get_unaligned((u16 *) val))



--
Regards
Phil Reid

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

[Phil Reid]

On 30/03/2016 1:01 PM, Yong Li wrote:

Or another method is using the below to convert the u8 to u16:
cpu_to_le16(get_unaligned((u16 *) val)), compared with the
i2c_smbus_write_byte_data method, which one is better?




G'day Yong,

I'd go with the cpu_to_le16(get_unaligned((u16 *) val))



--
Regards
Phil Reid

Re: [GIT PULL] bcm2835 clk changes for 4.6 maybe

[Eric Anholt]

Stephen Boyd  writes:

> On 03/17, Eric Anholt wrote:
>> This is late, so feel free to drop it, but I figured I'd send it to
>> you in case you were still open to merges.  I've pounded on it a bit
>> today (modesets to all sorts of resolutions on HDMI, used it for
>> testing the DPI panel support that I'm hoping to have for 4.7, and did
>> a whole lot of browsing of clk_summary as I debugged DPI), and kbuild
>> test robot came back clean, so I'm pretty happy with it.
>> 
>> The following changes since commit 4d3ac6662452060721599a3392bc2f524af984cb:
>> 
>>   clk: bcm2835: fix check of error code returned by devm_ioremap_resource() 
>> (2016-03-15 18:14:11 -0700)
>> 
>> are available in the git repository at:
>> 
>>   g...@github.com:anholt/linux.git tags/bcm2835-clk-next-2016-03-17
>
> Please make sure to use a proper URL here. I don't have access to
> g...@github.com, but I can fetch this from
> git://github.com/anholt/linux.git. The tag and the contents match
> so I'm fairly confident all is well.

Yeah, it should have been https://github.com/anholt/linux -- sorry about
that!


signature.asc
Description: PGP signature

Re: [GIT PULL] bcm2835 clk changes for 4.6 maybe

[Eric Anholt]

Stephen Boyd  writes:

> On 03/17, Eric Anholt wrote:
>> This is late, so feel free to drop it, but I figured I'd send it to
>> you in case you were still open to merges.  I've pounded on it a bit
>> today (modesets to all sorts of resolutions on HDMI, used it for
>> testing the DPI panel support that I'm hoping to have for 4.7, and did
>> a whole lot of browsing of clk_summary as I debugged DPI), and kbuild
>> test robot came back clean, so I'm pretty happy with it.
>> 
>> The following changes since commit 4d3ac6662452060721599a3392bc2f524af984cb:
>> 
>>   clk: bcm2835: fix check of error code returned by devm_ioremap_resource() 
>> (2016-03-15 18:14:11 -0700)
>> 
>> are available in the git repository at:
>> 
>>   g...@github.com:anholt/linux.git tags/bcm2835-clk-next-2016-03-17
>
> Please make sure to use a proper URL here. I don't have access to
> g...@github.com, but I can fetch this from
> git://github.com/anholt/linux.git. The tag and the contents match
> so I'm fairly confident all is well.

Yeah, it should have been https://github.com/anholt/linux -- sorry about
that!


signature.asc
Description: PGP signature

Re: [Update][PATCH v7 6/7] cpufreq: Support for fast frequency switching

[Viresh Kumar]

On 30-03-16, 03:47, Rafael J. Wysocki wrote:
> Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
> @@ -843,6 +883,7 @@ static int acpi_cpufreq_cpu_exit(struct
>   pr_debug("acpi_cpufreq_cpu_exit\n");
>  
>   if (data) {
> + policy->fast_switch_possible = false;

Is this done just for keeping code symmetric or is there a logical advantage
of this? Just for my understanding, not saying that it is wrong.

Otherwise, it looks good

Acked-by: Viresh Kumar 

-- 
viresh

Re: [Update][PATCH v7 6/7] cpufreq: Support for fast frequency switching

[Viresh Kumar]

On 30-03-16, 03:47, Rafael J. Wysocki wrote:
> Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
> @@ -843,6 +883,7 @@ static int acpi_cpufreq_cpu_exit(struct
>   pr_debug("acpi_cpufreq_cpu_exit\n");
>  
>   if (data) {
> + policy->fast_switch_possible = false;

Is this done just for keeping code symmetric or is there a logical advantage
of this? Just for my understanding, not saying that it is wrong.

Otherwise, it looks good

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 0/6] MIPS seccomp_bpf self test and fixups

[Kees Cook]

On Tue, Mar 29, 2016 at 1:35 AM, Matt Redfearn  wrote:
> These patches imporve seccomp support on MIPS.
>
> Firstly support is added for building the seccomp_bpf self test for
> MIPS. The
> initial results of these tests were:
>
> 32bit kernel O32 userspace before: 48 / 48 pass
> 64bit kernel O32 userspace before: 47 / 48 pass
>  Failures: TRAP.Handler
> 64bit kernel N32 userspace before: 44 / 48 pass
>  Failures: global.mode_strict_support, TRAP.handler,
> TRACE_syscall.syscall_redirected, TRACE_syscall.syscall_dropped
> 64bit kernel N64 userspace before: 46 / 48 pass
>  Failures: TRACE_syscall.syscall_redirected,
> TRACE_syscall.syscall_dropped
>
> The subsequent patches fix issues that were causing the above tests to
> fail. With
> these fixes, the results are:
> 32bit kernel O32 userspace after: 48 / 48
> 64bit kernel O32 userspace after: 48 / 48
> 64bit kernel N32 userspace after: 48 / 48
> 64bit kernel N64 userspace after: 48 / 48
>
> Thanks,
> Matt
>
> Changes in v2:
> - Tested on additional platforms
> - Replace __NR_syscall which isn't defined for N32 / N64 ABIs
>
> Matt Redfearn (6):
>   selftests/seccomp: add MIPS self-test support
>   MIPS: Support sending SIG_SYS to 32bit userspace from 64bit kernel
>   MIPS: scall: Handle seccomp filters which redirect syscalls
>   seccomp: Get compat syscalls from asm-generic header
>   MIPS: seccomp: Support compat with both O32 and N32
>   secomp: Constify mode1 syscall whitelist
>
>  arch/mips/include/asm/seccomp.h   | 47 
> +++
>  arch/mips/kernel/scall32-o32.S| 11 +++
>  arch/mips/kernel/scall64-64.S |  3 +-
>  arch/mips/kernel/scall64-n32.S| 14 +---
>  arch/mips/kernel/scall64-o32.S| 14 +---
>  arch/mips/kernel/signal32.c   |  6 
>  include/asm-generic/seccomp.h | 14 
>  kernel/seccomp.c  | 13 ++--
>  tools/testing/selftests/seccomp/seccomp_bpf.c | 30 +++--
>  9 files changed, 101 insertions(+), 51 deletions(-)

Thanks for digging into this! Consider all the seccomp pieces:

Acked-by: Kees Cook 

Probably best to carry it all in the MIPS tree, but if you want to me
take pieces of it into my seccomp tree, I can do that. Up to you. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 0/6] MIPS seccomp_bpf self test and fixups

[Kees Cook]

On Tue, Mar 29, 2016 at 1:35 AM, Matt Redfearn  wrote:
> These patches imporve seccomp support on MIPS.
>
> Firstly support is added for building the seccomp_bpf self test for
> MIPS. The
> initial results of these tests were:
>
> 32bit kernel O32 userspace before: 48 / 48 pass
> 64bit kernel O32 userspace before: 47 / 48 pass
>  Failures: TRAP.Handler
> 64bit kernel N32 userspace before: 44 / 48 pass
>  Failures: global.mode_strict_support, TRAP.handler,
> TRACE_syscall.syscall_redirected, TRACE_syscall.syscall_dropped
> 64bit kernel N64 userspace before: 46 / 48 pass
>  Failures: TRACE_syscall.syscall_redirected,
> TRACE_syscall.syscall_dropped
>
> The subsequent patches fix issues that were causing the above tests to
> fail. With
> these fixes, the results are:
> 32bit kernel O32 userspace after: 48 / 48
> 64bit kernel O32 userspace after: 48 / 48
> 64bit kernel N32 userspace after: 48 / 48
> 64bit kernel N64 userspace after: 48 / 48
>
> Thanks,
> Matt
>
> Changes in v2:
> - Tested on additional platforms
> - Replace __NR_syscall which isn't defined for N32 / N64 ABIs
>
> Matt Redfearn (6):
>   selftests/seccomp: add MIPS self-test support
>   MIPS: Support sending SIG_SYS to 32bit userspace from 64bit kernel
>   MIPS: scall: Handle seccomp filters which redirect syscalls
>   seccomp: Get compat syscalls from asm-generic header
>   MIPS: seccomp: Support compat with both O32 and N32
>   secomp: Constify mode1 syscall whitelist
>
>  arch/mips/include/asm/seccomp.h   | 47 
> +++
>  arch/mips/kernel/scall32-o32.S| 11 +++
>  arch/mips/kernel/scall64-64.S |  3 +-
>  arch/mips/kernel/scall64-n32.S| 14 +---
>  arch/mips/kernel/scall64-o32.S| 14 +---
>  arch/mips/kernel/signal32.c   |  6 
>  include/asm-generic/seccomp.h | 14 
>  kernel/seccomp.c  | 13 ++--
>  tools/testing/selftests/seccomp/seccomp_bpf.c | 30 +++--
>  9 files changed, 101 insertions(+), 51 deletions(-)

Thanks for digging into this! Consider all the seccomp pieces:

Acked-by: Kees Cook 

Probably best to carry it all in the MIPS tree, but if you want to me
take pieces of it into my seccomp tree, I can do that. Up to you. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

[Yong Li]

Or another method is using the below to convert the u8 to u16:
cpu_to_le16(get_unaligned((u16 *) val)), compared with the
i2c_smbus_write_byte_data method, which one is better?

Thanks,
Yong

2016-03-30 10:43 GMT+08:00 Yong Li :
> If use the get_unaligned, below is the code example, but we cannot detect if
> it is big endian or little endian. I would like to use the same write logic
> as PCA957X_TYPE: use the i2c_smbus_write_byte_data API to write two times.
> How do you think about it?
>
> if (big_endian)
> value = get_unaligned_be16(buf);
> else
> value = get_unaligned_le16(buf);
>
> Thanks,
> Yong Li
> 2016-03-30 0:33 GMT+08:00 Phil Reid :
>>
>> On 29/03/2016 10:39 PM, Alexander Stein wrote:
>>>
>>> You missed CC'ing Phil (Added for this post)
>>>
>>> On Tuesday 29 March 2016 20:53:58, Yong Li wrote:

 Thanks for your comment, I think I can change it to val[0] | (val[1]
 << 8), is it okay ?
>>>
>>>
>>> Mh, currently there is only one caller (device_pca953x_init) which passes
>>> only
>>> 0, 0 or 0xff, 0xff, so endianess is irrelevant. But to be future proof
>>> this
>>> should be done in an endian-safe manner. Though cpu_to_le16p does not
>>> work,
>>> due to same alignment problem as casting to u16*.
>>>
>>
>> I think get_unaligned((u16 *) val) should do the job.
>> There's also get_unaligned_le* get_unaligned_be*
>>
>> --
>> Regards
>> Phil Reid
>>

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

[Yong Li]

Or another method is using the below to convert the u8 to u16:
cpu_to_le16(get_unaligned((u16 *) val)), compared with the
i2c_smbus_write_byte_data method, which one is better?

Thanks,
Yong

2016-03-30 10:43 GMT+08:00 Yong Li :
> If use the get_unaligned, below is the code example, but we cannot detect if
> it is big endian or little endian. I would like to use the same write logic
> as PCA957X_TYPE: use the i2c_smbus_write_byte_data API to write two times.
> How do you think about it?
>
> if (big_endian)
> value = get_unaligned_be16(buf);
> else
> value = get_unaligned_le16(buf);
>
> Thanks,
> Yong Li
> 2016-03-30 0:33 GMT+08:00 Phil Reid :
>>
>> On 29/03/2016 10:39 PM, Alexander Stein wrote:
>>>
>>> You missed CC'ing Phil (Added for this post)
>>>
>>> On Tuesday 29 March 2016 20:53:58, Yong Li wrote:

 Thanks for your comment, I think I can change it to val[0] | (val[1]
 << 8), is it okay ?
>>>
>>>
>>> Mh, currently there is only one caller (device_pca953x_init) which passes
>>> only
>>> 0, 0 or 0xff, 0xff, so endianess is irrelevant. But to be future proof
>>> this
>>> should be done in an endian-safe manner. Though cpu_to_le16p does not
>>> work,
>>> due to same alignment problem as casting to u16*.
>>>
>>
>> I think get_unaligned((u16 *) val) should do the job.
>> There's also get_unaligned_le* get_unaligned_be*
>>
>> --
>> Regards
>> Phil Reid
>>

[lkp] [x86/mm] 729ed6fc97: BUG: spinlock bad magic on CPU#0, v86d/194

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/pcid
commit 729ed6fc971182a09c0869dbf8007ae5e538a04a ("x86/mm: Hold a spinlock when 
propagating TLB flushes")

As below, the log "BUG: spinlock bad magic on CPU#0, v86d/194" showed with your 
commit.

[7.316403] hgafb: probe of hgafb.0 failed with error -22
[7.317378] usbcore: registered new interface driver udlfb
[7.318226] usbcore: registered new interface driver smscufx
[7.320013] BUG: spinlock bad magic on CPU#0, v86d/194
[7.320767]  lock: 0x88000f763310, .magic: , .owner: /-1, 
.owner_cpu: 0
[7.321958] CPU: 0 PID: 194 Comm: v86d Not tainted 4.5.0-rc2-00215-g729ed6f 
#1
[7.323088]  88000f763310 88000f773b00 815c7dcb 

[7.324263]  88000f773b20 81101808 88000f763310 

[7.325484]  88000f773b50 81101a9f 88000f763000 
88000f763308
[7.326688] Call Trace:
[7.327230]  [] dump_stack+0x4b/0x70
[7.328015]  [] spin_dump+0x78/0xc0
[7.338512]  [] do_raw_spin_lock+0x1af/0x1e0
[7.339391]  [] _raw_spin_lock+0x15/0x20
[7.340204]  [] propagate_tlb_flush+0x2c/0x70
[7.341166]  [] flush_tlb_mm_range+0x3e/0x120
[7.342037]  [] move_page_tables+0x264/0x630
[7.342903]  [] shift_arg_pages+0xc6/0x1a0
[7.343729]  [] setup_arg_pages+0x26f/0x280
[7.344579]  [] load_elf_binary+0x44b/0x1210
[7.345447]  [] ? load_misc_binary+0x2df/0x410
[7.346329]  [] ? put_arg_page+0x7f/0x90
[7.347154]  [] ? copy_strings+0x148/0x3c0
[7.348099]  [] search_binary_handler+0x5a/0xf0
[7.348995]  [] do_execveat_common+0x627/0x800
[7.349980]  [] do_execve+0x2c/0x30
[7.363803]  [] call_usermodehelper_exec_async+0xf0/0x140
[7.364811]  [] ? umh_complete+0x40/0x40
[7.365627]  [] ret_from_fork+0x3f/0x70
[7.366462]  [] ? umh_complete+0x40/0x40
[7.368685] v86d (194) used greatest stack depth: 13480 bytes left
[7.436720] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[7.437735] uvesafb: vbe_init() failed with -22


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-randconfig-s5-03250643/gcc-5/729ed6fc971182a09c0869dbf8007ae5e538a04a/vmlinuz-4.5.0-rc2-00215-g729ed6f
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-61/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-s5-03250643-729ed6fc971182a09c0869dbf8007ae5e538a04a-20160325-54284-f93eiu-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-s5-03250643 
branch=linux-devel/devel-spot-201603250547 
commit=729ed6fc971182a09c0869dbf8007ae5e538a04a 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03250643/gcc-5/729ed6fc971182a09c0869dbf8007ae5e538a04a/vmlinuz-4.5.0-rc2-00215-g729ed6f
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-s5-03250643/gcc-5/729ed6fc971182a09c0869dbf8007ae5e538a04a/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-kbuild-yocto-x86_64-61::dhcp drbd.minor_count=8'  -initrd 
/fs/sdh1/initrd-vm-kbuild-yocto-x86_64-61 -m 320 -smp 1 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/sdh1/disk0-vm-kbuild-yocto-x86_64-61,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-61 -serial 
file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-61 -daemonize -display none 
-monitor null 




Thanks,
Xiaolong Ye
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y

[lkp] [x86/mm] 729ed6fc97: BUG: spinlock bad magic on CPU#0, v86d/194

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/pcid
commit 729ed6fc971182a09c0869dbf8007ae5e538a04a ("x86/mm: Hold a spinlock when 
propagating TLB flushes")

As below, the log "BUG: spinlock bad magic on CPU#0, v86d/194" showed with your 
commit.

[7.316403] hgafb: probe of hgafb.0 failed with error -22
[7.317378] usbcore: registered new interface driver udlfb
[7.318226] usbcore: registered new interface driver smscufx
[7.320013] BUG: spinlock bad magic on CPU#0, v86d/194
[7.320767]  lock: 0x88000f763310, .magic: , .owner: /-1, 
.owner_cpu: 0
[7.321958] CPU: 0 PID: 194 Comm: v86d Not tainted 4.5.0-rc2-00215-g729ed6f 
#1
[7.323088]  88000f763310 88000f773b00 815c7dcb 

[7.324263]  88000f773b20 81101808 88000f763310 

[7.325484]  88000f773b50 81101a9f 88000f763000 
88000f763308
[7.326688] Call Trace:
[7.327230]  [] dump_stack+0x4b/0x70
[7.328015]  [] spin_dump+0x78/0xc0
[7.338512]  [] do_raw_spin_lock+0x1af/0x1e0
[7.339391]  [] _raw_spin_lock+0x15/0x20
[7.340204]  [] propagate_tlb_flush+0x2c/0x70
[7.341166]  [] flush_tlb_mm_range+0x3e/0x120
[7.342037]  [] move_page_tables+0x264/0x630
[7.342903]  [] shift_arg_pages+0xc6/0x1a0
[7.343729]  [] setup_arg_pages+0x26f/0x280
[7.344579]  [] load_elf_binary+0x44b/0x1210
[7.345447]  [] ? load_misc_binary+0x2df/0x410
[7.346329]  [] ? put_arg_page+0x7f/0x90
[7.347154]  [] ? copy_strings+0x148/0x3c0
[7.348099]  [] search_binary_handler+0x5a/0xf0
[7.348995]  [] do_execveat_common+0x627/0x800
[7.349980]  [] do_execve+0x2c/0x30
[7.363803]  [] call_usermodehelper_exec_async+0xf0/0x140
[7.364811]  [] ? umh_complete+0x40/0x40
[7.365627]  [] ret_from_fork+0x3f/0x70
[7.366462]  [] ? umh_complete+0x40/0x40
[7.368685] v86d (194) used greatest stack depth: 13480 bytes left
[7.436720] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[7.437735] uvesafb: vbe_init() failed with -22


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-randconfig-s5-03250643/gcc-5/729ed6fc971182a09c0869dbf8007ae5e538a04a/vmlinuz-4.5.0-rc2-00215-g729ed6f
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-61/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-s5-03250643-729ed6fc971182a09c0869dbf8007ae5e538a04a-20160325-54284-f93eiu-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-s5-03250643 
branch=linux-devel/devel-spot-201603250547 
commit=729ed6fc971182a09c0869dbf8007ae5e538a04a 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03250643/gcc-5/729ed6fc971182a09c0869dbf8007ae5e538a04a/vmlinuz-4.5.0-rc2-00215-g729ed6f
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-s5-03250643/gcc-5/729ed6fc971182a09c0869dbf8007ae5e538a04a/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-kbuild-yocto-x86_64-61::dhcp drbd.minor_count=8'  -initrd 
/fs/sdh1/initrd-vm-kbuild-yocto-x86_64-61 -m 320 -smp 1 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/sdh1/disk0-vm-kbuild-yocto-x86_64-61,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-61 -serial 
file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-61 -daemonize -display none 
-monitor null 




Thanks,
Xiaolong Ye
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y

[PATCH] mm/highmem: simplify is_highmem()

[Chanho Min]

The is_highmem() is can be simplified by use of is_highmem_idx().
This patch removes redundant code and will make it easier to maintain
if the zone policy is changed or a new zone is added.

Signed-off-by: Chanho Min 
---
 include/linux/mmzone.h |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..9ac90c3 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -817,10 +817,7 @@ static inline int is_highmem_idx(enum zone_type idx)
 static inline int is_highmem(struct zone *zone)
 {
 #ifdef CONFIG_HIGHMEM
-   int zone_off = (char *)zone - (char *)zone->zone_pgdat->node_zones;
-   return zone_off == ZONE_HIGHMEM * sizeof(*zone) ||
-  (zone_off == ZONE_MOVABLE * sizeof(*zone) &&
-   zone_movable_is_highmem());
+   return is_highmem_idx(zone_idx(zone));
 #else
return 0;
 #endif
-- 
1.7.9.5

[PATCH] mm/highmem: simplify is_highmem()

[Chanho Min]

The is_highmem() is can be simplified by use of is_highmem_idx().
This patch removes redundant code and will make it easier to maintain
if the zone policy is changed or a new zone is added.

Signed-off-by: Chanho Min 
---
 include/linux/mmzone.h |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..9ac90c3 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -817,10 +817,7 @@ static inline int is_highmem_idx(enum zone_type idx)
 static inline int is_highmem(struct zone *zone)
 {
 #ifdef CONFIG_HIGHMEM
-   int zone_off = (char *)zone - (char *)zone->zone_pgdat->node_zones;
-   return zone_off == ZONE_HIGHMEM * sizeof(*zone) ||
-  (zone_off == ZONE_MOVABLE * sizeof(*zone) &&
-   zone_movable_is_highmem());
+   return is_highmem_idx(zone_idx(zone));
 #else
return 0;
 #endif
-- 
1.7.9.5

[PATCH] cpufreq: acpi: policy->driver_data can't be NULL in ->exit()

[Viresh Kumar]

Its always set by ->init() and so it will always be there in ->exit().
There is no need to have a special check for just that.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/acpi-cpufreq.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index eb2196f9d7fa..e20cbb1317cc 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -847,13 +847,11 @@ static int acpi_cpufreq_cpu_exit(struct cpufreq_policy 
*policy)
 
pr_debug("acpi_cpufreq_cpu_exit\n");
 
-   if (data) {
-   policy->driver_data = NULL;
-   acpi_processor_unregister_performance(data->acpi_perf_cpu);
-   free_cpumask_var(data->freqdomain_cpus);
-   kfree(policy->freq_table);
-   kfree(data);
-   }
+   policy->driver_data = NULL;
+   acpi_processor_unregister_performance(data->acpi_perf_cpu);
+   free_cpumask_var(data->freqdomain_cpus);
+   kfree(policy->freq_table);
+   kfree(data);
 
return 0;
 }
-- 
2.7.1.410.g6faf27b

[PATCH] cpufreq: acpi: policy->driver_data can't be NULL in ->exit()

[Viresh Kumar]

Its always set by ->init() and so it will always be there in ->exit().
There is no need to have a special check for just that.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/acpi-cpufreq.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index eb2196f9d7fa..e20cbb1317cc 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -847,13 +847,11 @@ static int acpi_cpufreq_cpu_exit(struct cpufreq_policy 
*policy)
 
pr_debug("acpi_cpufreq_cpu_exit\n");
 
-   if (data) {
-   policy->driver_data = NULL;
-   acpi_processor_unregister_performance(data->acpi_perf_cpu);
-   free_cpumask_var(data->freqdomain_cpus);
-   kfree(policy->freq_table);
-   kfree(data);
-   }
+   policy->driver_data = NULL;
+   acpi_processor_unregister_performance(data->acpi_perf_cpu);
+   free_cpumask_var(data->freqdomain_cpus);
+   kfree(policy->freq_table);
+   kfree(data);
 
return 0;
 }
-- 
2.7.1.410.g6faf27b

Re: [PATCH 2/2] mfd: remove dependency on HAS_IOMEM

[Krzysztof Kozlowski]

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring  wrote:
> Lots of drivers select MFD_SYSCON which depends on HAS_IOMEM and causes
> this kbuild warning if HAS_IOMEM is not enabled:
>
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && 
> DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP 
> && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
> VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && 
> VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) 
> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>
> Now that we have ioremap/iounmap variants for !HAS_IOMEM, remove this
> dependency from MFD to fix this warning.
>
> Cc: Arnd Bergmann 
> Cc: Lee Jones 
> Signed-off-by: Rob Herring 
> ---
>  drivers/mfd/Kconfig | 2 --
>  1 file changed, 2 deletions(-)

Tested-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 2/2] mfd: remove dependency on HAS_IOMEM

[Krzysztof Kozlowski]

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring  wrote:
> Lots of drivers select MFD_SYSCON which depends on HAS_IOMEM and causes
> this kbuild warning if HAS_IOMEM is not enabled:
>
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && 
> DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP 
> && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
> VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && 
> VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) 
> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>
> Now that we have ioremap/iounmap variants for !HAS_IOMEM, remove this
> dependency from MFD to fix this warning.
>
> Cc: Arnd Bergmann 
> Cc: Lee Jones 
> Signed-off-by: Rob Herring 
> ---
>  drivers/mfd/Kconfig | 2 --
>  1 file changed, 2 deletions(-)

Tested-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v2 1/5] block, dax: pass blk_dax_ctl through to drivers

[kbuild test robot]

Hi Dan,

[auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
[also build test ERROR on v4.6-rc1 next-20160329]
[cannot apply to xfs/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Vishal-Verma/dax-handling-of-media-errors/20160330-100409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
libnvdimm-for-next
config: s390-default_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All error/warnings (new ones prefixed by >>):

   drivers/s390/block/dcssblk.c: In function 'dcssblk_direct_access':
>> drivers/s390/block/dcssblk.c:36:13: error: storage class specified for 
>> parameter 'dcssblk_segments'
static char dcssblk_segments[DCSSBLK_PARM_LEN] = "\0";
^
>> drivers/s390/block/dcssblk.c:36:1: error: parameter 'dcssblk_segments' is 
>> initialized
static char dcssblk_segments[DCSSBLK_PARM_LEN] = "\0";
^
>> drivers/s390/block/dcssblk.c:38:12: error: storage class specified for 
>> parameter 'dcssblk_major'
static int dcssblk_major;
   ^
>> drivers/s390/block/dcssblk.c:39:45: error: storage class specified for 
>> parameter 'dcssblk_devops'
static const struct block_device_operations dcssblk_devops = {
^
>> drivers/s390/block/dcssblk.c:39:21: error: parameter 'dcssblk_devops' is 
>> initialized
static const struct block_device_operations dcssblk_devops = {
^
>> drivers/s390/block/dcssblk.c:46:1: warning: empty declaration
struct dcssblk_dev_info {
^
   drivers/s390/block/dcssblk.c:62:1: warning: empty declaration
struct segment_info {
^
>> drivers/s390/block/dcssblk.c:70:16: error: storage class specified for 
>> parameter 'dcssblk_add_store'
static ssize_t dcssblk_add_store(struct device * dev, struct 
device_attribute *attr, const char * buf,
   ^
>> drivers/s390/block/dcssblk.c:72:16: error: storage class specified for 
>> parameter 'dcssblk_remove_store'
static ssize_t dcssblk_remove_store(struct device * dev, struct 
device_attribute *attr, const char * buf,
   ^
   In file included from include/linux/genhd.h:63:0,
from include/linux/blkdev.h:9,
from drivers/s390/block/dcssblk.c:16:
>> include/linux/device.h:575:26: error: storage class specified for parameter 
>> 'dev_attr_add'
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
 ^
>> drivers/s390/block/dcssblk.c:75:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(add, S_IWUSR, NULL, dcssblk_add_store);
   ^
>> include/linux/device.h:575:9: error: parameter 'dev_attr_add' is initialized
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
^
>> drivers/s390/block/dcssblk.c:75:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(add, S_IWUSR, NULL, dcssblk_add_store);
   ^
>> include/linux/device.h:575:26: error: storage class specified for parameter 
>> 'dev_attr_remove'
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
 ^
   drivers/s390/block/dcssblk.c:76:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(remove, S_IWUSR, NULL, dcssblk_remove_store);
   ^
>> include/linux/device.h:575:9: error: parameter 'dev_attr_remove' is 
>> initialized
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
^
   drivers/s390/block/dcssblk.c:76:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(remove, S_IWUSR, NULL, dcssblk_remove_store);
   ^
>> drivers/s390/block/dcssblk.c:78:23: error: storage class specified for 
>> parameter 'dcssblk_root_dev'
static struct device *dcssblk_root_dev;
  ^
   In file included from include/linux/module.h:9:0,
from drivers/s390/block/dcssblk.c:10:
>> drivers/s390/block/dcssblk.c:80:18: error: storage class specified for 
>> parameter 'dcssblk_devices'
static LIST_HEAD(dcssblk_devices);
 ^
   include/linux/list.h:23:19: note: in definition of macro 'LIST_HEAD'
 struct list_head name = LIST_HEAD_INIT(name)
  ^
>> include/linux/list.h:23:9: error: parameter 'dcssblk_devices' is initialized
 struct list_head name = LIST_HEAD_INIT(name)
^

Re: [PATCH v2 1/5] block, dax: pass blk_dax_ctl through to drivers

[kbuild test robot]

Hi Dan,

[auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
[also build test ERROR on v4.6-rc1 next-20160329]
[cannot apply to xfs/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Vishal-Verma/dax-handling-of-media-errors/20160330-100409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
libnvdimm-for-next
config: s390-default_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All error/warnings (new ones prefixed by >>):

   drivers/s390/block/dcssblk.c: In function 'dcssblk_direct_access':
>> drivers/s390/block/dcssblk.c:36:13: error: storage class specified for 
>> parameter 'dcssblk_segments'
static char dcssblk_segments[DCSSBLK_PARM_LEN] = "\0";
^
>> drivers/s390/block/dcssblk.c:36:1: error: parameter 'dcssblk_segments' is 
>> initialized
static char dcssblk_segments[DCSSBLK_PARM_LEN] = "\0";
^
>> drivers/s390/block/dcssblk.c:38:12: error: storage class specified for 
>> parameter 'dcssblk_major'
static int dcssblk_major;
   ^
>> drivers/s390/block/dcssblk.c:39:45: error: storage class specified for 
>> parameter 'dcssblk_devops'
static const struct block_device_operations dcssblk_devops = {
^
>> drivers/s390/block/dcssblk.c:39:21: error: parameter 'dcssblk_devops' is 
>> initialized
static const struct block_device_operations dcssblk_devops = {
^
>> drivers/s390/block/dcssblk.c:46:1: warning: empty declaration
struct dcssblk_dev_info {
^
   drivers/s390/block/dcssblk.c:62:1: warning: empty declaration
struct segment_info {
^
>> drivers/s390/block/dcssblk.c:70:16: error: storage class specified for 
>> parameter 'dcssblk_add_store'
static ssize_t dcssblk_add_store(struct device * dev, struct 
device_attribute *attr, const char * buf,
   ^
>> drivers/s390/block/dcssblk.c:72:16: error: storage class specified for 
>> parameter 'dcssblk_remove_store'
static ssize_t dcssblk_remove_store(struct device * dev, struct 
device_attribute *attr, const char * buf,
   ^
   In file included from include/linux/genhd.h:63:0,
from include/linux/blkdev.h:9,
from drivers/s390/block/dcssblk.c:16:
>> include/linux/device.h:575:26: error: storage class specified for parameter 
>> 'dev_attr_add'
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
 ^
>> drivers/s390/block/dcssblk.c:75:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(add, S_IWUSR, NULL, dcssblk_add_store);
   ^
>> include/linux/device.h:575:9: error: parameter 'dev_attr_add' is initialized
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
^
>> drivers/s390/block/dcssblk.c:75:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(add, S_IWUSR, NULL, dcssblk_add_store);
   ^
>> include/linux/device.h:575:26: error: storage class specified for parameter 
>> 'dev_attr_remove'
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
 ^
   drivers/s390/block/dcssblk.c:76:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(remove, S_IWUSR, NULL, dcssblk_remove_store);
   ^
>> include/linux/device.h:575:9: error: parameter 'dev_attr_remove' is 
>> initialized
 struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
^
   drivers/s390/block/dcssblk.c:76:8: note: in expansion of macro 'DEVICE_ATTR'
static DEVICE_ATTR(remove, S_IWUSR, NULL, dcssblk_remove_store);
   ^
>> drivers/s390/block/dcssblk.c:78:23: error: storage class specified for 
>> parameter 'dcssblk_root_dev'
static struct device *dcssblk_root_dev;
  ^
   In file included from include/linux/module.h:9:0,
from drivers/s390/block/dcssblk.c:10:
>> drivers/s390/block/dcssblk.c:80:18: error: storage class specified for 
>> parameter 'dcssblk_devices'
static LIST_HEAD(dcssblk_devices);
 ^
   include/linux/list.h:23:19: note: in definition of macro 'LIST_HEAD'
 struct list_head name = LIST_HEAD_INIT(name)
  ^
>> include/linux/list.h:23:9: error: parameter 'dcssblk_devices' is initialized
 struct list_head name = LIST_HEAD_INIT(name)
^

Re: [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Krzysztof Kozlowski]

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring  wrote:
> Drivers shouldn't have to care about HAS_IOMEM to compile and having to
> causes a Kconfig mess:
>
> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) 
> selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && 
> DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP 
> && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
> VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && 
> VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) 
> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>
> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
> needs. This fixes build errors for UM allyesconfig:
>
> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' 
> [-Werror=implicit-function-declaration]
>  iounmap(base);
>
> Reported-by: Fengguang Wu 
> Cc: Arnd Bergmann 
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  include/asm-generic/io.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Some time ago I posted patches adding the dependency, but that path
looks like a better approach:

Tested-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Krzysztof Kozlowski]

On Wed, Mar 30, 2016 at 3:23 AM, Rob Herring  wrote:
> Drivers shouldn't have to care about HAS_IOMEM to compile and having to
> causes a Kconfig mess:
>
> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) 
> selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && 
> DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP 
> && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
> VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && 
> VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) 
> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>
> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
> needs. This fixes build errors for UM allyesconfig:
>
> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' 
> [-Werror=implicit-function-declaration]
>  iounmap(base);
>
> Reported-by: Fengguang Wu 
> Cc: Arnd Bergmann 
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  include/asm-generic/io.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Some time ago I posted patches adding the dependency, but that path
looks like a better approach:

Tested-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 1/8] phy: Fix phy-hi6220-usb dependencies

[Krzysztof Kozlowski]

On Sat, Mar 26, 2016 at 7:40 AM, Richard Weinberger  wrote:
> This driver needs io memory.
>
> Fixes the following Kconfig warning:
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && 
> DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP 
> && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
> VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && 
> VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) 
> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>
> And this build error:
> drivers/mfd/syscon.c: In function ‘of_syscon_register’:
> drivers/mfd/syscon.c:67:2: error: implicit declaration of function ‘ioremap’ 
> [-Werror=implicit-function-declaration]
>   base = ioremap(res.start, resource_size());
>   ^
> drivers/mfd/syscon.c:67:7: warning: assignment makes pointer from integer 
> without a cast [enabled by default]
>   base = ioremap(res.start, resource_size());
>^
> drivers/mfd/syscon.c:109:2: error: implicit declaration of function ‘iounmap’ 
> [-Werror=implicit-function-declaration]
>   iounmap(base);
>
> Cc: Kishon Vijay Abraham I 
> Cc: Geert Uytterhoeven 
> Fixes: d896910f3 ("phy: Restrict phy-hi6220-usb to HiSilicon arm64")
> Signed-off-by: Richard Weinberger 

Waiting with this from 3rd March...
https://www.spinics.net/lists/linux-usb/msg137114.html
(and resent on 15th https://lkml.org/lkml/2016/3/16/408)
...but indeed recent Rob's work is a better solution.

BR,
Krzysztof

Re: [PATCH 1/8] phy: Fix phy-hi6220-usb dependencies

[Krzysztof Kozlowski]

On Sat, Mar 26, 2016 at 7:40 AM, Richard Weinberger  wrote:
> This driver needs io memory.
>
> Fixes the following Kconfig warning:
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && 
> DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP 
> && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
> VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && 
> VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) 
> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>
> And this build error:
> drivers/mfd/syscon.c: In function ‘of_syscon_register’:
> drivers/mfd/syscon.c:67:2: error: implicit declaration of function ‘ioremap’ 
> [-Werror=implicit-function-declaration]
>   base = ioremap(res.start, resource_size());
>   ^
> drivers/mfd/syscon.c:67:7: warning: assignment makes pointer from integer 
> without a cast [enabled by default]
>   base = ioremap(res.start, resource_size());
>^
> drivers/mfd/syscon.c:109:2: error: implicit declaration of function ‘iounmap’ 
> [-Werror=implicit-function-declaration]
>   iounmap(base);
>
> Cc: Kishon Vijay Abraham I 
> Cc: Geert Uytterhoeven 
> Fixes: d896910f3 ("phy: Restrict phy-hi6220-usb to HiSilicon arm64")
> Signed-off-by: Richard Weinberger 

Waiting with this from 3rd March...
https://www.spinics.net/lists/linux-usb/msg137114.html
(and resent on 15th https://lkml.org/lkml/2016/3/16/408)
...but indeed recent Rob's work is a better solution.

BR,
Krzysztof

[PATCH v2] sched/fair: Initiate a new task's util avg to a bounded value

[Yuyang Du]

Hi Peter,

It looks like this patch is left last year. I fixed a bug - it
did not init task group's entities.

And I started this new thread to attend to it.

Please refer to the link for the previous version and some data experimented:

http://article.gmane.org/gmane.linux.kernel/2117689

Would you please give it a look?

Thanks,
Yuyang

---
Subject: [PATCH v2] sched/fair: Initiate a new task's util avg to a bounded
 value

A new task's util_avg is set to full utilization of a CPU (100%
time running). This accelerates a new task's utilization ramp-up,
useful to boost its execution in early time. However, it may result
in (insanely) high utilization for a transient time period when a
flood of tasks are spawned. Importantly, it violates the
"fundamentally bounded" CPU utilization, and its side effect is
negative if we don't take any measure to bound it.

This patch proposes an algorithm to address this issue. It has
two methods to approach a sensible initial util_avg:

(1) An expected (or average) util_avg based on its cfs_rq's util_avg:

util_avg = cfs_rq->util_avg / (cfs_rq->load_avg + 1) * se.load.weight

(2) A trajectory of how successive new tasks' util develops, which
gives 1/2 of the left utilization budget to a new task such that
the additional util is noticeably large (when overall util is low) or
unnoticeably small (when overall util is high enough). In the meantime,
the aggregate utilization is well bounded:

util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n

where n denotes the nth task.

If util_avg is larger than util_avg_cap, then the effective util is
clamped to the util_avg_cap.

Reported-by: Andrey Ryabinin 
Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |  2 ++
 kernel/sched/fair.c  | 57 ++--
 kernel/sched/sched.h |  1 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0b21e7a..49180f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2413,6 +2413,8 @@ void wake_up_new_task(struct task_struct *p)
 */
set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0));
 #endif
+   /* Post initialize new task's util average when its cfs_rq is set */
+   post_init_entity_util_avg(>se);
 
rq = __task_rq_lock(p);
activate_task(rq, p, 0);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 303d639..3f56c3a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -682,17 +682,69 @@ void init_entity_runnable_average(struct sched_entity *se)
sa->period_contrib = 1023;
sa->load_avg = scale_load_down(se->load.weight);
sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
-   sa->util_avg = scale_load_down(SCHED_LOAD_SCALE);
-   sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
+   /*
+* At this point, util_avg won't be used in select_task_rq_fair anyway
+*/
+   sa->util_avg = 0;
+   sa->util_sum = 0;
/* when this task enqueue'ed, it will contribute to its cfs_rq's 
load_avg */
 }
 
+/*
+ * With new tasks being created, their initial util_avgs are extrapolated
+ * based on the cfs_rq's current util_avg:
+ *
+ * util_avg = cfs_rq->util_avg / (cfs_rq->load_avg + 1) * se.load.weight
+ *
+ * However, in many cases, the above util_avg does not give a desired
+ * value. Moreover, the sum of the util_avgs may be divergent, such
+ * as when the series is a harmonic series.
+ *
+ * To solve this problem, we also cap the util_avg of successive tasks to
+ * only 1/2 of the left utilization budget:
+ *
+ * util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n
+ *
+ * where n denotes the nth task.
+ *
+ * For example, a simplest series from the beginning would be like:
+ *
+ *  task  util_avg: 512, 256, 128,  64,  32,   16,8, ...
+ * cfs_rq util_avg: 512, 768, 896, 960, 992, 1008, 1016, ...
+ *
+ * Finally, that extrapolated util_avg is clamped to the cap (util_avg_cap)
+ * if util_avg > util_avg_cap.
+ */
+void post_init_entity_util_avg(struct sched_entity *se)
+{
+   struct cfs_rq *cfs_rq = cfs_rq_of(se);
+   struct sched_avg *sa = >avg;
+   long cap = (long)(scale_load_down(SCHED_LOAD_SCALE) - 
cfs_rq->avg.util_avg) / 2;
+
+   if (cap > 0) {
+   if (cfs_rq->avg.util_avg != 0) {
+   sa->util_avg = cfs_rq->avg.util_avg * se->load.weight;
+   sa->util_avg /=  (cfs_rq->avg.load_avg + 1);
+
+   if (sa->util_avg > cap)
+   sa->util_avg = cap;
+   }
+   else {
+   sa->util_avg = cap;
+   }
+   sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
+   }
+}
+
 static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq);
 static inline unsigned long cfs_rq_load_avg(struct cfs_rq *cfs_rq);
 #else
 void init_entity_runnable_average(struct sched_entity 

[PATCH v2] sched/fair: Initiate a new task's util avg to a bounded value

[Yuyang Du]

Hi Peter,

It looks like this patch is left last year. I fixed a bug - it
did not init task group's entities.

And I started this new thread to attend to it.

Please refer to the link for the previous version and some data experimented:

http://article.gmane.org/gmane.linux.kernel/2117689

Would you please give it a look?

Thanks,
Yuyang

---
Subject: [PATCH v2] sched/fair: Initiate a new task's util avg to a bounded
 value

A new task's util_avg is set to full utilization of a CPU (100%
time running). This accelerates a new task's utilization ramp-up,
useful to boost its execution in early time. However, it may result
in (insanely) high utilization for a transient time period when a
flood of tasks are spawned. Importantly, it violates the
"fundamentally bounded" CPU utilization, and its side effect is
negative if we don't take any measure to bound it.

This patch proposes an algorithm to address this issue. It has
two methods to approach a sensible initial util_avg:

(1) An expected (or average) util_avg based on its cfs_rq's util_avg:

util_avg = cfs_rq->util_avg / (cfs_rq->load_avg + 1) * se.load.weight

(2) A trajectory of how successive new tasks' util develops, which
gives 1/2 of the left utilization budget to a new task such that
the additional util is noticeably large (when overall util is low) or
unnoticeably small (when overall util is high enough). In the meantime,
the aggregate utilization is well bounded:

util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n

where n denotes the nth task.

If util_avg is larger than util_avg_cap, then the effective util is
clamped to the util_avg_cap.

Reported-by: Andrey Ryabinin 
Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |  2 ++
 kernel/sched/fair.c  | 57 ++--
 kernel/sched/sched.h |  1 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0b21e7a..49180f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2413,6 +2413,8 @@ void wake_up_new_task(struct task_struct *p)
 */
set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0));
 #endif
+   /* Post initialize new task's util average when its cfs_rq is set */
+   post_init_entity_util_avg(>se);
 
rq = __task_rq_lock(p);
activate_task(rq, p, 0);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 303d639..3f56c3a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -682,17 +682,69 @@ void init_entity_runnable_average(struct sched_entity *se)
sa->period_contrib = 1023;
sa->load_avg = scale_load_down(se->load.weight);
sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
-   sa->util_avg = scale_load_down(SCHED_LOAD_SCALE);
-   sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
+   /*
+* At this point, util_avg won't be used in select_task_rq_fair anyway
+*/
+   sa->util_avg = 0;
+   sa->util_sum = 0;
/* when this task enqueue'ed, it will contribute to its cfs_rq's 
load_avg */
 }
 
+/*
+ * With new tasks being created, their initial util_avgs are extrapolated
+ * based on the cfs_rq's current util_avg:
+ *
+ * util_avg = cfs_rq->util_avg / (cfs_rq->load_avg + 1) * se.load.weight
+ *
+ * However, in many cases, the above util_avg does not give a desired
+ * value. Moreover, the sum of the util_avgs may be divergent, such
+ * as when the series is a harmonic series.
+ *
+ * To solve this problem, we also cap the util_avg of successive tasks to
+ * only 1/2 of the left utilization budget:
+ *
+ * util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n
+ *
+ * where n denotes the nth task.
+ *
+ * For example, a simplest series from the beginning would be like:
+ *
+ *  task  util_avg: 512, 256, 128,  64,  32,   16,8, ...
+ * cfs_rq util_avg: 512, 768, 896, 960, 992, 1008, 1016, ...
+ *
+ * Finally, that extrapolated util_avg is clamped to the cap (util_avg_cap)
+ * if util_avg > util_avg_cap.
+ */
+void post_init_entity_util_avg(struct sched_entity *se)
+{
+   struct cfs_rq *cfs_rq = cfs_rq_of(se);
+   struct sched_avg *sa = >avg;
+   long cap = (long)(scale_load_down(SCHED_LOAD_SCALE) - 
cfs_rq->avg.util_avg) / 2;
+
+   if (cap > 0) {
+   if (cfs_rq->avg.util_avg != 0) {
+   sa->util_avg = cfs_rq->avg.util_avg * se->load.weight;
+   sa->util_avg /=  (cfs_rq->avg.load_avg + 1);
+
+   if (sa->util_avg > cap)
+   sa->util_avg = cap;
+   }
+   else {
+   sa->util_avg = cap;
+   }
+   sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
+   }
+}
+
 static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq);
 static inline unsigned long cfs_rq_load_avg(struct cfs_rq *cfs_rq);
 #else
 void init_entity_runnable_average(struct sched_entity *se)
 {
 }
+void 

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

[Viresh Kumar]

On 29-03-16, 14:58, Rafael J. Wysocki wrote:
> On Monday, March 28, 2016 02:33:33 PM Viresh Kumar wrote:
> > Its gonna be same for all policies sharing tunables ..
> 
> The value will be the same, but the cacheline won't.

Fair enough. So this information is replicated for each policy for performance
benefits. Would it make sense to add a comment for that? Its not obvious today
why we are keeping this per-policy.

> > > +static ssize_t rate_limit_us_store(struct gov_attr_set *attr_set, const 
> > > char *buf,
> > > +size_t count)
> > > +{
> > > + struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
> > > + struct sugov_policy *sg_policy;
> > > + unsigned int rate_limit_us;
> > > + int ret;
> > > +
> > > + ret = sscanf(buf, "%u", _limit_us);
> > > + if (ret != 1)
> > > + return -EINVAL;
> > > +
> > > + tunables->rate_limit_us = rate_limit_us;
> > > +
> > > + list_for_each_entry(sg_policy, _set->policy_list, tunables_hook)
> > > + sg_policy->freq_update_delay_ns = rate_limit_us * NSEC_PER_USEC;
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
> > 
> > Why not reuse gov_attr_rw() ?
> 
> Would it work?

Why wouldn't it? I had a look again at that and I couldn't find a reason for it
to not work. Probably I missed something.

> > > + ret = kobject_init_and_add(>attr_set.kobj, 
> > > _tunables_ktype,
> > > +get_governor_parent_kobj(policy), "%s",
> > > +schedutil_gov.name);
> > > + if (!ret)
> > > + goto out;
> > > +
> > > + /* Failure, so roll back. */
> > > + policy->governor_data = NULL;
> > > + sugov_tunables_free(tunables);
> > > +
> > > + free_sg_policy:
> > > + pr_err("cpufreq: schedutil governor initialization failed (error 
> > > %d)\n", ret);
> > > + sugov_policy_free(sg_policy);
> > 
> > I didn't like the way we have mixed success and failure path here, just to 
> > save
> > a single line of code (unlock).
> 
> I don't follow, sorry.  Yes, I can do unlock/return instead of the "goto out",
> but then the goto label is still needed.

Sorry for not being clear earlier, but this what I was suggesting it to look 
like:

---
static int sugov_init(struct cpufreq_policy *policy)
{
   struct sugov_policy *sg_policy;
   struct sugov_tunables *tunables;
   unsigned int lat;
   int ret = 0;

   /* State should be equivalent to EXIT */
   if (policy->governor_data)
   return -EBUSY;

   sg_policy = sugov_policy_alloc(policy);
   if (!sg_policy)
   return -ENOMEM;

   mutex_lock(_tunables_lock);

   if (global_tunables) {
   if (WARN_ON(have_governor_per_policy())) {
   ret = -EINVAL;
   goto free_sg_policy;
   }
   policy->governor_data = sg_policy;
   sg_policy->tunables = global_tunables;

   gov_attr_set_get(_tunables->attr_set, 
_policy->tunables_hook);

   mutex_unlock(_tunables_lock);
   return 0;
   }

   tunables = sugov_tunables_alloc(sg_policy);
   if (!tunables) {
   ret = -ENOMEM;
   goto free_sg_policy;
   }

   tunables->rate_limit_us = LATENCY_MULTIPLIER;
   lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
   if (lat)
   tunables->rate_limit_us *= lat;

   if (!have_governor_per_policy())
   global_tunables = tunables;

   policy->governor_data = sg_policy;
   sg_policy->tunables = tunables;

   ret = kobject_init_and_add(>attr_set.kobj, 
_tunables_ktype,
  get_governor_parent_kobj(policy), "%s",
  schedutil_gov.name);
   if (!ret) {
   mutex_unlock(_tunables_lock);
   return 0;
   }

   /* Failure, so roll back. */
   policy->governor_data = NULL;
   sugov_tunables_free(tunables);

 free_sg_policy:
   mutex_unlock(_tunables_lock);

   pr_err("cpufreq: schedutil governor initialization failed (error %d)\n", 
ret);
   sugov_policy_free(sg_policy);

   return ret;

---

> > Over that it does things, that aren't symmetric anymore. For example, we 
> > have
> > called sugov_policy_alloc() without locks
> 
> Are you sure?

Yes.

> > and are freeing it from within locks.
> 
> Both are under global_tunables_lock.

No, sugov_policy_alloc() isn't called from within locks.

> > > +static int __init sugov_module_init(void)
> > > +{
> > > + return cpufreq_register_governor(_gov);
> > > +}
> > > +
> > > +static void __exit sugov_module_exit(void)
> > > +{
> > > + cpufreq_unregister_governor(_gov);
> > > +}
> > > +
> > > +MODULE_AUTHOR("Rafael J. Wysocki ");
> > > +MODULE_DESCRIPTION("Utilization-based CPU frequency selection");
> > > +MODULE_LICENSE("GPL");
> > 
> > Maybe a MODULE_ALIAS as 

Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data

[Viresh Kumar]

On 29-03-16, 14:58, Rafael J. Wysocki wrote:
> On Monday, March 28, 2016 02:33:33 PM Viresh Kumar wrote:
> > Its gonna be same for all policies sharing tunables ..
> 
> The value will be the same, but the cacheline won't.

Fair enough. So this information is replicated for each policy for performance
benefits. Would it make sense to add a comment for that? Its not obvious today
why we are keeping this per-policy.

> > > +static ssize_t rate_limit_us_store(struct gov_attr_set *attr_set, const 
> > > char *buf,
> > > +size_t count)
> > > +{
> > > + struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
> > > + struct sugov_policy *sg_policy;
> > > + unsigned int rate_limit_us;
> > > + int ret;
> > > +
> > > + ret = sscanf(buf, "%u", _limit_us);
> > > + if (ret != 1)
> > > + return -EINVAL;
> > > +
> > > + tunables->rate_limit_us = rate_limit_us;
> > > +
> > > + list_for_each_entry(sg_policy, _set->policy_list, tunables_hook)
> > > + sg_policy->freq_update_delay_ns = rate_limit_us * NSEC_PER_USEC;
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
> > 
> > Why not reuse gov_attr_rw() ?
> 
> Would it work?

Why wouldn't it? I had a look again at that and I couldn't find a reason for it
to not work. Probably I missed something.

> > > + ret = kobject_init_and_add(>attr_set.kobj, 
> > > _tunables_ktype,
> > > +get_governor_parent_kobj(policy), "%s",
> > > +schedutil_gov.name);
> > > + if (!ret)
> > > + goto out;
> > > +
> > > + /* Failure, so roll back. */
> > > + policy->governor_data = NULL;
> > > + sugov_tunables_free(tunables);
> > > +
> > > + free_sg_policy:
> > > + pr_err("cpufreq: schedutil governor initialization failed (error 
> > > %d)\n", ret);
> > > + sugov_policy_free(sg_policy);
> > 
> > I didn't like the way we have mixed success and failure path here, just to 
> > save
> > a single line of code (unlock).
> 
> I don't follow, sorry.  Yes, I can do unlock/return instead of the "goto out",
> but then the goto label is still needed.

Sorry for not being clear earlier, but this what I was suggesting it to look 
like:

---
static int sugov_init(struct cpufreq_policy *policy)
{
   struct sugov_policy *sg_policy;
   struct sugov_tunables *tunables;
   unsigned int lat;
   int ret = 0;

   /* State should be equivalent to EXIT */
   if (policy->governor_data)
   return -EBUSY;

   sg_policy = sugov_policy_alloc(policy);
   if (!sg_policy)
   return -ENOMEM;

   mutex_lock(_tunables_lock);

   if (global_tunables) {
   if (WARN_ON(have_governor_per_policy())) {
   ret = -EINVAL;
   goto free_sg_policy;
   }
   policy->governor_data = sg_policy;
   sg_policy->tunables = global_tunables;

   gov_attr_set_get(_tunables->attr_set, 
_policy->tunables_hook);

   mutex_unlock(_tunables_lock);
   return 0;
   }

   tunables = sugov_tunables_alloc(sg_policy);
   if (!tunables) {
   ret = -ENOMEM;
   goto free_sg_policy;
   }

   tunables->rate_limit_us = LATENCY_MULTIPLIER;
   lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
   if (lat)
   tunables->rate_limit_us *= lat;

   if (!have_governor_per_policy())
   global_tunables = tunables;

   policy->governor_data = sg_policy;
   sg_policy->tunables = tunables;

   ret = kobject_init_and_add(>attr_set.kobj, 
_tunables_ktype,
  get_governor_parent_kobj(policy), "%s",
  schedutil_gov.name);
   if (!ret) {
   mutex_unlock(_tunables_lock);
   return 0;
   }

   /* Failure, so roll back. */
   policy->governor_data = NULL;
   sugov_tunables_free(tunables);

 free_sg_policy:
   mutex_unlock(_tunables_lock);

   pr_err("cpufreq: schedutil governor initialization failed (error %d)\n", 
ret);
   sugov_policy_free(sg_policy);

   return ret;

---

> > Over that it does things, that aren't symmetric anymore. For example, we 
> > have
> > called sugov_policy_alloc() without locks
> 
> Are you sure?

Yes.

> > and are freeing it from within locks.
> 
> Both are under global_tunables_lock.

No, sugov_policy_alloc() isn't called from within locks.

> > > +static int __init sugov_module_init(void)
> > > +{
> > > + return cpufreq_register_governor(_gov);
> > > +}
> > > +
> > > +static void __exit sugov_module_exit(void)
> > > +{
> > > + cpufreq_unregister_governor(_gov);
> > > +}
> > > +
> > > +MODULE_AUTHOR("Rafael J. Wysocki ");
> > > +MODULE_DESCRIPTION("Utilization-based CPU frequency selection");
> > > +MODULE_LICENSE("GPL");
> > 
> > Maybe a MODULE_ALIAS as well ?
> 
> Sorry, I don't 

Re: [PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

[Krzysztof Kozlowski]

On 30.03.2016 11:19, Andy Yan wrote:
> Add device tree bindings document for reboot-mode driver.
> 
> Signed-off-by: Andy Yan 
> Acked-by: Rob Herring 
> 
> ---
> 
> Changes in v7:
> - fix some spelling mistakes
> - declare that the mode magic should be none-zero value
> 
> Changes in v6:
> - fix a typo with "property"
> - describe property "mask" more clear
> 
> Changes in v5:
> - delete a unnecessary blank line in syscon-reboot-mode.txt
> - rename mode-fastoboot to mode-bootloader in syscon-reboot-mode.txt
> - rename macro BOOT_LOADER to BOOT_BL_DOWNLOAD, which gives a more clear mean
> 
> Changes in v4:
> - remove mode-maskrom
> - rename mode-fastboot to mode-bootloader to keep compatible with the exiting 
> Android device
> 
> Changes in v3:
> - descirbe all reboot mode as properity instead of subnode
> 
> Changes in v2: None
> Changes in v1: None
> 
>  .../bindings/power/reset/reboot-mode.txt   | 25 
>  .../bindings/power/reset/syscon-reboot-mode.txt| 35 
> ++
>  2 files changed, 60 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>  create mode 100644 
> Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

Re: [PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

[Krzysztof Kozlowski]

On 30.03.2016 11:19, Andy Yan wrote:
> Add device tree bindings document for reboot-mode driver.
> 
> Signed-off-by: Andy Yan 
> Acked-by: Rob Herring 
> 
> ---
> 
> Changes in v7:
> - fix some spelling mistakes
> - declare that the mode magic should be none-zero value
> 
> Changes in v6:
> - fix a typo with "property"
> - describe property "mask" more clear
> 
> Changes in v5:
> - delete a unnecessary blank line in syscon-reboot-mode.txt
> - rename mode-fastoboot to mode-bootloader in syscon-reboot-mode.txt
> - rename macro BOOT_LOADER to BOOT_BL_DOWNLOAD, which gives a more clear mean
> 
> Changes in v4:
> - remove mode-maskrom
> - rename mode-fastboot to mode-bootloader to keep compatible with the exiting 
> Android device
> 
> Changes in v3:
> - descirbe all reboot mode as properity instead of subnode
> 
> Changes in v2: None
> Changes in v1: None
> 
>  .../bindings/power/reset/reboot-mode.txt   | 25 
>  .../bindings/power/reset/syscon-reboot-mode.txt| 35 
> ++
>  2 files changed, 60 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>  create mode 100644 
> Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt

Reviewed-by: Krzysztof Kozlowski 



Best regards,

Krzysztof

Re: [PATCH v7 2/4] power: reset: add reboot mode driver

[Krzysztof Kozlowski]

On 30.03.2016 11:20, Andy Yan wrote:
> This driver parses the reboot commands like "reboot bootloader"
> and "reboot recovery" to get a boot mode described in the
> device tree , then call the write interfae to store the boot
> mode in some place like special register or sram, which can
> be read by the bootloader after system reboot, then the bootloader
> can take different action according to the mode stored.
> 
> This is commonly used on Android based devices, in order to
> reboot the device into fastboot or recovery mode.
> 
> Reviewed-by: Matthias Brugger 
> Reviewed-by: Moritz Fischer 
> Tested-by: John Stultz 
> Acked-by: John Stultz 
> Signed-off-by: Andy Yan 
> 
> ---
> 
> Changes in v7:
> - address some suggestions from Krzysztof, make syscon-reboot-mode driver 
> data self-contained.
> 

Thanks for changes, few comments below.

(...)

> diff --git a/drivers/power/reset/reboot-mode.c 
> b/drivers/power/reset/reboot-mode.c
> new file mode 100644
> index 000..ae6f931
> --- /dev/null
> +++ b/drivers/power/reset/reboot-mode.c
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "reboot-mode.h"
> +
> +#define PREFIX "mode-"
> +
> +struct mode_info {
> + const char *mode;
> + unsigned int magic;
> + struct list_head list;
> +};
> +
> +struct reboot_mode_driver {
> + struct device *dev;
> + struct list_head head;
> + int (*write)(struct device *dev, int magic);
> + struct notifier_block reboot_notifier;
> +};
> +
> +static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
> +  const char *cmd)
> +{
> + const char *normal = "normal";
> + int magic = 0;
> + struct mode_info *info;
> +
> + if (!cmd)
> + cmd = normal;
> +
> + list_for_each_entry(info, >head, list) {
> + if (!strcmp(info->mode, cmd)) {
> + magic = info->magic;
> + break;
> + }
> + }
> +
> + return magic;
> +}
> +
> +static int reboot_mode_notify(struct notifier_block *this,
> +   unsigned long mode, void *cmd)
> +{
> + struct reboot_mode_driver *reboot;
> + int magic;
> +
> + reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
> + magic = get_reboot_mode_magic(reboot, cmd);
> + if (magic)
> + reboot->write(reboot->dev, magic);
> +
> + return NOTIFY_DONE;
> +}
> +
> +int reboot_mode_register(struct device *dev, int (*write)(struct device *, 
> int))
> +{
> + struct reboot_mode_driver *reboot;
> + struct mode_info *info;
> + struct property *prop;
> + struct device_node *np;
> + size_t len = strlen(PREFIX);
> + int ret;
> +
> + reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
> + if (!reboot)
> + return -ENOMEM;
> +
> + reboot->dev = dev;
> + reboot->write = write;
> + INIT_LIST_HEAD(>head);
> +
> + np = of_node_get(dev->of_node);
> + for_each_property_of_node(np, prop) {
> + if (len > strlen(prop->name) || strncmp(prop->name, PREFIX, 
> len))
> + continue;
> +
> + info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> + if (!info)

Clean up needed: of_node_put() and kfree_const() for items stored on the
list from previous iterations.

> + return -ENOMEM;
> +
> + info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
> + if (of_property_read_u32(np, prop->name, >magic)) {
> + dev_err(dev, "reboot mode %s without magic number\n",
> + info->mode);
> + devm_kfree(dev, info);
> + continue;
> + }
> + list_add_tail(>list, >head);
> + }
> + of_node_put(np);

If you of_node_put() here, there is no sense in getting it before. I
mentioned of_node_get() only because I am not sure about life-cycle of
nodes in case of DT overlays and you are storing the pointer to string
from DT.

The doubts I have are concerning only the case of freeing nodes from
overlay.

I don't know if of_node_get() is needed but of_node_get()+of_node_put()
seems useless.

> +
> + reboot->reboot_notifier.notifier_call = reboot_mode_notify;
> + ret = register_reboot_notifier(>reboot_notifier);
> + if (ret)
> + dev_err(dev, "can't register reboot notifier\n");
> +
> + return ret;
> +}
> 

Re: [PATCH v7 2/4] power: reset: add reboot mode driver

[Krzysztof Kozlowski]

On 30.03.2016 11:20, Andy Yan wrote:
> This driver parses the reboot commands like "reboot bootloader"
> and "reboot recovery" to get a boot mode described in the
> device tree , then call the write interfae to store the boot
> mode in some place like special register or sram, which can
> be read by the bootloader after system reboot, then the bootloader
> can take different action according to the mode stored.
> 
> This is commonly used on Android based devices, in order to
> reboot the device into fastboot or recovery mode.
> 
> Reviewed-by: Matthias Brugger 
> Reviewed-by: Moritz Fischer 
> Tested-by: John Stultz 
> Acked-by: John Stultz 
> Signed-off-by: Andy Yan 
> 
> ---
> 
> Changes in v7:
> - address some suggestions from Krzysztof, make syscon-reboot-mode driver 
> data self-contained.
> 

Thanks for changes, few comments below.

(...)

> diff --git a/drivers/power/reset/reboot-mode.c 
> b/drivers/power/reset/reboot-mode.c
> new file mode 100644
> index 000..ae6f931
> --- /dev/null
> +++ b/drivers/power/reset/reboot-mode.c
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "reboot-mode.h"
> +
> +#define PREFIX "mode-"
> +
> +struct mode_info {
> + const char *mode;
> + unsigned int magic;
> + struct list_head list;
> +};
> +
> +struct reboot_mode_driver {
> + struct device *dev;
> + struct list_head head;
> + int (*write)(struct device *dev, int magic);
> + struct notifier_block reboot_notifier;
> +};
> +
> +static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
> +  const char *cmd)
> +{
> + const char *normal = "normal";
> + int magic = 0;
> + struct mode_info *info;
> +
> + if (!cmd)
> + cmd = normal;
> +
> + list_for_each_entry(info, >head, list) {
> + if (!strcmp(info->mode, cmd)) {
> + magic = info->magic;
> + break;
> + }
> + }
> +
> + return magic;
> +}
> +
> +static int reboot_mode_notify(struct notifier_block *this,
> +   unsigned long mode, void *cmd)
> +{
> + struct reboot_mode_driver *reboot;
> + int magic;
> +
> + reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
> + magic = get_reboot_mode_magic(reboot, cmd);
> + if (magic)
> + reboot->write(reboot->dev, magic);
> +
> + return NOTIFY_DONE;
> +}
> +
> +int reboot_mode_register(struct device *dev, int (*write)(struct device *, 
> int))
> +{
> + struct reboot_mode_driver *reboot;
> + struct mode_info *info;
> + struct property *prop;
> + struct device_node *np;
> + size_t len = strlen(PREFIX);
> + int ret;
> +
> + reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
> + if (!reboot)
> + return -ENOMEM;
> +
> + reboot->dev = dev;
> + reboot->write = write;
> + INIT_LIST_HEAD(>head);
> +
> + np = of_node_get(dev->of_node);
> + for_each_property_of_node(np, prop) {
> + if (len > strlen(prop->name) || strncmp(prop->name, PREFIX, 
> len))
> + continue;
> +
> + info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> + if (!info)

Clean up needed: of_node_put() and kfree_const() for items stored on the
list from previous iterations.

> + return -ENOMEM;
> +
> + info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
> + if (of_property_read_u32(np, prop->name, >magic)) {
> + dev_err(dev, "reboot mode %s without magic number\n",
> + info->mode);
> + devm_kfree(dev, info);
> + continue;
> + }
> + list_add_tail(>list, >head);
> + }
> + of_node_put(np);

If you of_node_put() here, there is no sense in getting it before. I
mentioned of_node_get() only because I am not sure about life-cycle of
nodes in case of DT overlays and you are storing the pointer to string
from DT.

The doubts I have are concerning only the case of freeing nodes from
overlay.

I don't know if of_node_get() is needed but of_node_get()+of_node_put()
seems useless.

> +
> + reboot->reboot_notifier.notifier_call = reboot_mode_notify;
> + ret = register_reboot_notifier(>reboot_notifier);
> + if (ret)
> + dev_err(dev, "can't register reboot notifier\n");
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(reboot_mode_register);
> +
> +MODULE_AUTHOR("Andy Yan  +MODULE_DESCRIPTION("System reboot mode driver");
> 

Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210

[Wei Ni]

Hi Thierry & Stephen,
The driver patches in this series were taken by Eduardo, so do know who can take
these tow dts patches 13 and 14?

Thanks.
Wei.

On 2016年03月29日 23:16, Eduardo Valentin wrote:
> On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote:
>> Adds soctherm node for Tegra210, and add cpu,
>> gpu, mem, pllx as thermal-zones. Set critical
>> trip temperatures for them.
>>
>> Signed-off-by: Wei Ni 
> 
> Acked-by: Eduardo Valentin 
> 

Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210

[Wei Ni]

Hi Thierry & Stephen,
The driver patches in this series were taken by Eduardo, so do know who can take
these tow dts patches 13 and 14?

Thanks.
Wei.

On 2016年03月29日 23:16, Eduardo Valentin wrote:
> On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote:
>> Adds soctherm node for Tegra210, and add cpu,
>> gpu, mem, pllx as thermal-zones. Set critical
>> trip temperatures for them.
>>
>> Signed-off-by: Wei Ni 
> 
> Acked-by: Eduardo Valentin 
> 

Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

[Viresh Kumar]

On 29-03-16, 21:45, Arnd Bergmann wrote:
> Regarding new platforms, I'd hope that we could manage to define an extension
> to the oppv2 binding that marks a machine as compatible with opp, so we can

The extension of oppv2 binding or compatible string is for platforms that really
need extend oppv2 (like ST, which already have a new compatible string). I am
not sure if we should be putting that into the Machine's compatible area, as I
though it is something internal to OPP layer or their driver.

But we can see that when we handle it.

-- 
viresh

Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

[Viresh Kumar]

On 29-03-16, 21:45, Arnd Bergmann wrote:
> Regarding new platforms, I'd hope that we could manage to define an extension
> to the oppv2 binding that marks a machine as compatible with opp, so we can

The extension of oppv2 binding or compatible string is for platforms that really
need extend oppv2 (like ST, which already have a new compatible string). I am
not sure if we should be putting that into the Machine's compatible area, as I
though it is something internal to OPP layer or their driver.

But we can see that when we handle it.

-- 
viresh

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[kbuild test robot]

Hi Vishal,

[auto build test WARNING on linux-nvdimm/libnvdimm-for-next]
[also build test WARNING on v4.6-rc1 next-20160329]
[cannot apply to xfs/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Vishal-Verma/dax-handling-of-media-errors/20160330-100409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
libnvdimm-for-next
config: x86_64-randconfig-i0-03300245 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   fs/ext4/indirect.c: In function 'ext4_ind_direct_IO':
>> fs/ext4/indirect.c:719:11: warning: 'ret_saved' may be used uninitialized in 
>> this function [-Wmaybe-uninitialized]
  ssize_t ret_saved = 0;
  ^

vim +/ret_saved +719 fs/ext4/indirect.c

   703  smp_mb();
   704  if (unlikely(ext4_test_inode_state(inode,
   705  
EXT4_STATE_DIOREAD_LOCK))) {
   706  inode_dio_end(inode);
   707  goto locked;
   708  }
   709  if (IS_DAX(inode))
   710  ret = dax_do_io(iocb, inode, iter, offset,
   711  ext4_dio_get_block, NULL, 0);
   712  else
   713  ret = __blockdev_direct_IO(iocb, inode,
   714 inode->i_sb->s_bdev, 
iter,
   715 offset, 
ext4_dio_get_block,
   716 NULL, NULL, 0);
   717  inode_dio_end(inode);
   718  } else {
 > 719  ssize_t ret_saved = 0;
   720  
   721  locked:
   722  if (IS_DAX(inode)) {
   723  ret = dax_do_io(iocb, inode, iter, offset,
   724  ext4_dio_get_block, NULL, 
DIO_LOCKING);
   725  if (ret == -EIO && iov_iter_rw(iter) == WRITE)
   726  ret_saved = ret;
   727  else

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


.config.gz
Description: Binary data

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

[kbuild test robot]

Hi Vishal,

[auto build test WARNING on linux-nvdimm/libnvdimm-for-next]
[also build test WARNING on v4.6-rc1 next-20160329]
[cannot apply to xfs/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Vishal-Verma/dax-handling-of-media-errors/20160330-100409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
libnvdimm-for-next
config: x86_64-randconfig-i0-03300245 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   fs/ext4/indirect.c: In function 'ext4_ind_direct_IO':
>> fs/ext4/indirect.c:719:11: warning: 'ret_saved' may be used uninitialized in 
>> this function [-Wmaybe-uninitialized]
  ssize_t ret_saved = 0;
  ^

vim +/ret_saved +719 fs/ext4/indirect.c

   703  smp_mb();
   704  if (unlikely(ext4_test_inode_state(inode,
   705  
EXT4_STATE_DIOREAD_LOCK))) {
   706  inode_dio_end(inode);
   707  goto locked;
   708  }
   709  if (IS_DAX(inode))
   710  ret = dax_do_io(iocb, inode, iter, offset,
   711  ext4_dio_get_block, NULL, 0);
   712  else
   713  ret = __blockdev_direct_IO(iocb, inode,
   714 inode->i_sb->s_bdev, 
iter,
   715 offset, 
ext4_dio_get_block,
   716 NULL, NULL, 0);
   717  inode_dio_end(inode);
   718  } else {
 > 719  ssize_t ret_saved = 0;
   720  
   721  locked:
   722  if (IS_DAX(inode)) {
   723  ret = dax_do_io(iocb, inode, iter, offset,
   724  ext4_dio_get_block, NULL, 
DIO_LOCKING);
   725  if (ret == -EIO && iov_iter_rw(iter) == WRITE)
   726  ret_saved = ret;
   727  else

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


.config.gz
Description: Binary data

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

[Tadeusz Struk]

Hi,
On 03/29/2016 06:49 PM, kbuild test robot wrote:
> Hi Tadeusz,
> 
> [auto build test ERROR on v4.6-rc1]
> [also build test ERROR on next-20160329]
> [cannot apply to crypto/master]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-algif-add-akcipher/20160330-090754
> config: i386-randconfig-i1-03292045 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All error/warnings (new ones prefixed by >>):

The patches have been generated against cryptodev-2.6 rebased on top of 4.6-rc1.
It should work with crypto as soon as Herbert will rebase his repo.
Thanks,
-- 
TS

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

[Tadeusz Struk]

Hi,
On 03/29/2016 06:49 PM, kbuild test robot wrote:
> Hi Tadeusz,
> 
> [auto build test ERROR on v4.6-rc1]
> [also build test ERROR on next-20160329]
> [cannot apply to crypto/master]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-algif-add-akcipher/20160330-090754
> config: i386-randconfig-i1-03292045 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All error/warnings (new ones prefixed by >>):

The patches have been generated against cryptodev-2.6 rebased on top of 4.6-rc1.
It should work with crypto as soon as Herbert will rebase his repo.
Thanks,
-- 
TS

Re: [PATCH v3 0/4] thermal: hisilicon: enable power allocator for Hi6220

[Leo Yan]

On Tue, Mar 29, 2016 at 08:45:59AM -0700, Eduardo Valentin wrote:
> On Tue, Mar 29, 2016 at 07:27:11PM +0800, Leo Yan wrote:
> > Hi6220 has octa-core so it has quite high power consumption when run
> > benchmark and introduces high temperature for SoC. So need enable
> > thermal governor to control temperature and also cannot hurt much for
> > performance after impose cooling operations on CPU.
> > 
> > This patch series is to enable power allocator for Hi6220. Patch 1 is to
> > change "hysteresis" as optional property for trip points, so when enable
> > power allocator governor we can ignore this property.
> > 
> > During profiling also found two issues for thermal sensor's driver. The
> > power allocator just uses only one sensor, so patch 2 is to fix sensor
> > driver to let it can initialize driver successfully with only enabling
> > one sensor; patch 3 is to dismiss warning of IRQ imbalance enabling.
> > 
> > After profiling on Hikey, the power model has been simplized with only
> > dynamic coefficient, and now it's convienence to pass it from CPU node.
> > So patch 4 and 5 bind sensor and pass power model parameters.
> > 
> > This patch series have been tested on 96boards Hikey.
> 
> Applied patches 1 and 2 in my fixes branch. Patches 3 and 4 need to go
> via the hisi platform tree. You may add my
> 
> Acked-by: Eduardo Valentin 
> 
> on patches 3 and 4 if you want.

Thanks, Eduardo.

Hi Wei,

Could you help pick up patches 3/4 for enabling thermal in dts?

Thanks,
Leo Yan

Re: [PATCH v3 0/4] thermal: hisilicon: enable power allocator for Hi6220

[Leo Yan]

On Tue, Mar 29, 2016 at 08:45:59AM -0700, Eduardo Valentin wrote:
> On Tue, Mar 29, 2016 at 07:27:11PM +0800, Leo Yan wrote:
> > Hi6220 has octa-core so it has quite high power consumption when run
> > benchmark and introduces high temperature for SoC. So need enable
> > thermal governor to control temperature and also cannot hurt much for
> > performance after impose cooling operations on CPU.
> > 
> > This patch series is to enable power allocator for Hi6220. Patch 1 is to
> > change "hysteresis" as optional property for trip points, so when enable
> > power allocator governor we can ignore this property.
> > 
> > During profiling also found two issues for thermal sensor's driver. The
> > power allocator just uses only one sensor, so patch 2 is to fix sensor
> > driver to let it can initialize driver successfully with only enabling
> > one sensor; patch 3 is to dismiss warning of IRQ imbalance enabling.
> > 
> > After profiling on Hikey, the power model has been simplized with only
> > dynamic coefficient, and now it's convienence to pass it from CPU node.
> > So patch 4 and 5 bind sensor and pass power model parameters.
> > 
> > This patch series have been tested on 96boards Hikey.
> 
> Applied patches 1 and 2 in my fixes branch. Patches 3 and 4 need to go
> via the hisi platform tree. You may add my
> 
> Acked-by: Eduardo Valentin 
> 
> on patches 3 and 4 if you want.

Thanks, Eduardo.

Hi Wei,

Could you help pick up patches 3/4 for enabling thermal in dts?

Thanks,
Leo Yan

RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 29, 2016 5:49 PM
> To: Jun Li 
> Cc: Peter Chen ; Felipe Balbi ;
> Greg KH ; Sebastian Reichel ;
> Dmitry Eremin-Solenikov ; David Woodhouse
> ; Peter Chen ; Alan Stern
> ; r.bald...@samsung.com; Yoshihiro Shimoda
> ; Lee Jones ; Mark
> Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML  ker...@vger.kernel.org>
> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 29 March 2016 at 16:45, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> >> Sent: Monday, March 28, 2016 2:52 PM
> >> To: Peter Chen 
> >> Cc: Felipe Balbi ; Greg KH
> >> ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; Peter Chen ; Alan
> >> Stern ; r.bald...@samsung.com; Yoshihiro
> >> Shimoda ; Lee Jones
> >> ; Mark Brown ; Charles
> >> Keepax ;
> >> patc...@opensource.wolfsonmicro.com;
> >> Linux PM list ; USB
> >> ;
> >> device-mainlin...@lists.linuxfoundation.org; LKML  >> ker...@vger.kernel.org>
> >> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 25 March 2016 at 15:09, Peter Chen  wrote:
> >> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb charger, which is pending testing. Moreover there may be other
> >> >> potential users will use it in future.
> >> >>
> >> >
> >> > I am afraid I still not find the user (udc driver) for this
> >> > framework, I would like to see how udc driver block the enumeration
> >> > until the charger detection has finished, or am I missing something?
> >>
> >> It is not for udc driver but for power users who want to negotiate
> >> with USB subsystem.
> >>
> >
> > Seems you don't want to guarantee charger type detection is done
> > before gadget connection(pullup DP), right?
> > I see you call usb_charger_detect_type() in each gadget usb state
> changes.
> 
> I am not sure I get your point correctly, please correct me if I
> misunderstand you.
> We need to check the charger type at every event comes from the usb gadget
> state changes or the extcon device state changes, which means a new
> charger plugin or pullup.
> 

According to usb charger spec, my understanding is you can't do real charger
detection procedure *after* gadget _connection_(pullup DP), also I don't
think it's necessary to check charger type at every event from usb gadget.
Something in gadget driver you can utilize is only vbus detection, and
report diff current by diff usb state if it's a SDP.

> >
> > Li Jun
> >> >
> >> > --
> >> > Best Regards,
> >> > Peter Chen
> >>
> >>
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> >> in the body of a message to majord...@vger.kernel.org More majordomo
> >> info at http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> --
> Baolin.wang
> Best Regards

Re: [PATCH v2 2/2] ASoC: codecs: add support for TAS5720 digital amplifier

[Andreas Dannenberg]

Hi Mark,
thanks for taking time reviewing the driver. Some comments below...

On Mon, Mar 28, 2016 at 08:01:43PM +0100, Mark Brown wrote:
> On Mon, Mar 21, 2016 at 12:08:27PM -0500, Andreas Dannenberg wrote:
> 
> > +static int tas5720_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
> > + unsigned int freq, int dir)
> > +{
> > +   /*
> > +* Nothing to configure here for TAS5720. It's a simple codec slave.
> > +* However we need to keep this function in here otherwise the ASoC
> > +* platform driver will throw an ENOTSUPP at us when trying to play
> > +* audio.
> > +*/
> > +
> > +   return 0;
> > +}
> 
> Remove empty funnctions, -ENOTSUPP is expected behaviour for anything
> that isn't explicitly supported by a driver.

Ok will double-check. Very early during my driver development I was not
able to play audio through aplay if this function was not provided. I
don't recall what specific Kernel version that was but it may have been
something like 4.1.

> 
> > +   if (unlikely(!tx_mask)) {
> 
> unlikely() is for optimising hot paths, just write the logic clearly
> unless there's a reason for it.

Got it. This was plagiarized from a similar driver but I agree this
is not a performance critical loop or something.

> > +static irqreturn_t tas5720_irq_handler(int irq, void *_dev)
> > +{
> > +   /*
> > +* Immediately disable TAS5720 FAULTZ interrupts inside the low-level
> > +* handler to prevent the system getting saturated or even overrun
> > +* by interrupt requests. Normally the fact that we create a threaded
> > +* interrupt with IRQF_ONESHOT should take care of this as by design
> > +* it masks interrupts while the thread is processed however testing
> > +* has shown that at the high frequency the FAULTZ signal triggers
> > +* (every 300us!) occasionally the system would lock up even with a
> > +* threaded handler that's completely empty until the Kernel breaks the
> > +* cycle, disables that interrupt, and reports a "nobody cared" error.
> > +*
> > +* Disabling the interrupt here combined with a deferred re-enabling
> > +* after the thread has run not only prevents this lock condition but
> > +* also helps to rate-limit the processing of FAULTZ interrupts.
> > +*/
> > +   disable_irq_nosync(irq);
> 
> No, this is completely broken.  Whatever is going on in your system with
> the interrupt core you need to address that at the appropriate level not
> by putting a nonsensical bodge in here.  The interrupt is disabled while
> the threaded handler is running, if that's not having the desired effect
> then whatever causes that needs to be fixed.

Good feedback, I needed some outside guidance here. Definitely will dig
into this again but I'll be on vacation for a bit starting tomorrow so I
won't get to it right away.

As explained in the code comment even with a boiled-down test code that
has an empty threaded handler the system would come to a grinding halt
when bombarded with interrupts every 300us which I found odd but not
completely unexpected (from my MCU background POV that is). And while
digging I had seen that the interrupts do get disabled just like you
mention during threaded handling to operate in a more graceful manner.
But I wasn't sure at this point if the additional (high priority, I
suppose) overhead of creating/starting the thread (even an empty one)
every 300us was just too much for my poor single-core SoC to handle so
my assumption was that it never got cycles to process stuff other than
interrupts, and disabling interrupts in the low-level handler fixed just
that. But I'm going to spend some extra cycles trying to re-digest the
realtime behavior of my particular SoC/setup to understand why exactly
this is happening.

> 
> > +static int tas5720_dapm_post_event(struct snd_soc_dapm_widget *w,
> > +  struct snd_kcontrol *kcontrol, int event)
> > +{
> > +   struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
> > +   int ret;
> > +
> > +   switch (event) {
> > +   case SND_SOC_DAPM_POST_PMU:
> > +   /*
> > +* Check if the codec is still powered up in which case exit
> > +* right away also skipping the shutdown-to-active wait time.
> > +*/
> > +   ret = snd_soc_test_bits(codec, TAS5720_POWER_CTRL_REG,
> > +   TAS5720_SDZ, 0);
> 
> I don't understand this.  Why on earth would we be calling the PMU
> handler if the widget was not previously powered? 
> 
> > +   /*
> > +* Take TAS5720 out of shutdown mode in preparation for widget
> > +* power up.
> > +*/
> > +   ret = snd_soc_update_bits(codec, TAS5720_POWER_CTRL_REG,
> > + TAS5720_SDZ, TAS5720_SDZ);
> > +   if (ret < 0) {
> > +   dev_err(codec->dev, "error waking codec: %d\n", ret);
> > +   return ret;

RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 29, 2016 5:49 PM
> To: Jun Li 
> Cc: Peter Chen ; Felipe Balbi ;
> Greg KH ; Sebastian Reichel ;
> Dmitry Eremin-Solenikov ; David Woodhouse
> ; Peter Chen ; Alan Stern
> ; r.bald...@samsung.com; Yoshihiro Shimoda
> ; Lee Jones ; Mark
> Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML  ker...@vger.kernel.org>
> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 29 March 2016 at 16:45, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> >> Sent: Monday, March 28, 2016 2:52 PM
> >> To: Peter Chen 
> >> Cc: Felipe Balbi ; Greg KH
> >> ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; Peter Chen ; Alan
> >> Stern ; r.bald...@samsung.com; Yoshihiro
> >> Shimoda ; Lee Jones
> >> ; Mark Brown ; Charles
> >> Keepax ;
> >> patc...@opensource.wolfsonmicro.com;
> >> Linux PM list ; USB
> >> ;
> >> device-mainlin...@lists.linuxfoundation.org; LKML  >> ker...@vger.kernel.org>
> >> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 25 March 2016 at 15:09, Peter Chen  wrote:
> >> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb charger, which is pending testing. Moreover there may be other
> >> >> potential users will use it in future.
> >> >>
> >> >
> >> > I am afraid I still not find the user (udc driver) for this
> >> > framework, I would like to see how udc driver block the enumeration
> >> > until the charger detection has finished, or am I missing something?
> >>
> >> It is not for udc driver but for power users who want to negotiate
> >> with USB subsystem.
> >>
> >
> > Seems you don't want to guarantee charger type detection is done
> > before gadget connection(pullup DP), right?
> > I see you call usb_charger_detect_type() in each gadget usb state
> changes.
> 
> I am not sure I get your point correctly, please correct me if I
> misunderstand you.
> We need to check the charger type at every event comes from the usb gadget
> state changes or the extcon device state changes, which means a new
> charger plugin or pullup.
> 

According to usb charger spec, my understanding is you can't do real charger
detection procedure *after* gadget _connection_(pullup DP), also I don't
think it's necessary to check charger type at every event from usb gadget.
Something in gadget driver you can utilize is only vbus detection, and
report diff current by diff usb state if it's a SDP.

> >
> > Li Jun
> >> >
> >> > --
> >> > Best Regards,
> >> > Peter Chen
> >>
> >>
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> >> in the body of a message to majord...@vger.kernel.org More majordomo
> >> info at http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> --
> Baolin.wang
> Best Regards

Re: [PATCH v2 2/2] ASoC: codecs: add support for TAS5720 digital amplifier

[Andreas Dannenberg]

Hi Mark,
thanks for taking time reviewing the driver. Some comments below...

On Mon, Mar 28, 2016 at 08:01:43PM +0100, Mark Brown wrote:
> On Mon, Mar 21, 2016 at 12:08:27PM -0500, Andreas Dannenberg wrote:
> 
> > +static int tas5720_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
> > + unsigned int freq, int dir)
> > +{
> > +   /*
> > +* Nothing to configure here for TAS5720. It's a simple codec slave.
> > +* However we need to keep this function in here otherwise the ASoC
> > +* platform driver will throw an ENOTSUPP at us when trying to play
> > +* audio.
> > +*/
> > +
> > +   return 0;
> > +}
> 
> Remove empty funnctions, -ENOTSUPP is expected behaviour for anything
> that isn't explicitly supported by a driver.

Ok will double-check. Very early during my driver development I was not
able to play audio through aplay if this function was not provided. I
don't recall what specific Kernel version that was but it may have been
something like 4.1.

> 
> > +   if (unlikely(!tx_mask)) {
> 
> unlikely() is for optimising hot paths, just write the logic clearly
> unless there's a reason for it.

Got it. This was plagiarized from a similar driver but I agree this
is not a performance critical loop or something.

> > +static irqreturn_t tas5720_irq_handler(int irq, void *_dev)
> > +{
> > +   /*
> > +* Immediately disable TAS5720 FAULTZ interrupts inside the low-level
> > +* handler to prevent the system getting saturated or even overrun
> > +* by interrupt requests. Normally the fact that we create a threaded
> > +* interrupt with IRQF_ONESHOT should take care of this as by design
> > +* it masks interrupts while the thread is processed however testing
> > +* has shown that at the high frequency the FAULTZ signal triggers
> > +* (every 300us!) occasionally the system would lock up even with a
> > +* threaded handler that's completely empty until the Kernel breaks the
> > +* cycle, disables that interrupt, and reports a "nobody cared" error.
> > +*
> > +* Disabling the interrupt here combined with a deferred re-enabling
> > +* after the thread has run not only prevents this lock condition but
> > +* also helps to rate-limit the processing of FAULTZ interrupts.
> > +*/
> > +   disable_irq_nosync(irq);
> 
> No, this is completely broken.  Whatever is going on in your system with
> the interrupt core you need to address that at the appropriate level not
> by putting a nonsensical bodge in here.  The interrupt is disabled while
> the threaded handler is running, if that's not having the desired effect
> then whatever causes that needs to be fixed.

Good feedback, I needed some outside guidance here. Definitely will dig
into this again but I'll be on vacation for a bit starting tomorrow so I
won't get to it right away.

As explained in the code comment even with a boiled-down test code that
has an empty threaded handler the system would come to a grinding halt
when bombarded with interrupts every 300us which I found odd but not
completely unexpected (from my MCU background POV that is). And while
digging I had seen that the interrupts do get disabled just like you
mention during threaded handling to operate in a more graceful manner.
But I wasn't sure at this point if the additional (high priority, I
suppose) overhead of creating/starting the thread (even an empty one)
every 300us was just too much for my poor single-core SoC to handle so
my assumption was that it never got cycles to process stuff other than
interrupts, and disabling interrupts in the low-level handler fixed just
that. But I'm going to spend some extra cycles trying to re-digest the
realtime behavior of my particular SoC/setup to understand why exactly
this is happening.

> 
> > +static int tas5720_dapm_post_event(struct snd_soc_dapm_widget *w,
> > +  struct snd_kcontrol *kcontrol, int event)
> > +{
> > +   struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
> > +   int ret;
> > +
> > +   switch (event) {
> > +   case SND_SOC_DAPM_POST_PMU:
> > +   /*
> > +* Check if the codec is still powered up in which case exit
> > +* right away also skipping the shutdown-to-active wait time.
> > +*/
> > +   ret = snd_soc_test_bits(codec, TAS5720_POWER_CTRL_REG,
> > +   TAS5720_SDZ, 0);
> 
> I don't understand this.  Why on earth would we be calling the PMU
> handler if the widget was not previously powered? 
> 
> > +   /*
> > +* Take TAS5720 out of shutdown mode in preparation for widget
> > +* power up.
> > +*/
> > +   ret = snd_soc_update_bits(codec, TAS5720_POWER_CTRL_REG,
> > + TAS5720_SDZ, TAS5720_SDZ);
> > +   if (ret < 0) {
> > +   dev_err(codec->dev, "error waking codec: %d\n", ret);
> > +   return ret;

Re: [PATCH v2] thermal: add sysfs_notify on some attributes

[Srikar Srimath Tirumala]

On 03/28/2016 06:35 PM, Eduardo Valentin wrote:

On Tue, Mar 15, 2016 at 11:08:00PM +, Pandruvada, Srinivas wrote:

On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote:

Add a sysfs_notify on thermal_zone*/temp and cooling_device*/
cur_state whenever any trip is triggered or cur state is changed.

This change allows usermode apps to register themselves to get
notified, when certain thermal conditions occur and reduce their
workload. This workload throttling allows usermode to react before
hardware clocks are throttled and keep some critical apps running
reliably longer.

I think we need a combination of proposal in
https://patchwork.kernel.org/patch/7876351/ and this.

For example this patch notifies that some trip is violated, but that is
not enough for user space application to take any action. Some trips
violations user space may not care as this may be a transient one. The
patch from Eduardo address that by providing trip, temperature and last
temperature information. But that patch only address hot trips. I
understand why Eduardo doesn't want to be notified for passive trips as
there will be too many.



Yeah, my original intention was to avoid flooding userland, specially
through a pipe like the sysfs netlink, which is in use to deal with
other stuff.



How about if the number of notifications were to be reduced like in v3 
of this patch? Or is the consensus not to use sysfs_notify or uevents at 
all?



So IMO we need some mechanism to turn off notification and decide what
notification will result in user space notifications.
On some x86 systems we have 10+ passive/active trips, this will results
in too many notifications. We may be in thermally sensitive zone, where
more code excecution is more heat.



Exactly, that has direct impact not only on the process waiting for
thermal notifications, but also on other process listening to sysfs.


We may have some mask of trips for which will result in notifications.
By default no notifications, unless some user space requests.



The complexity of such communication (or even the current status of
sysfs ABI) starts to reach limit of such channel. We may definitely
consider other means, such as /dev interface, just like IIO does.



I agree with your point about the overhead of generating these events 
and thought maybe the problem could be partially addressed by reducing 
the number of notifications being sent. So with that in mind I created a 
V3 of the patches which does this. Please do take a look at it when you 
get a chance.



During last LPC we discussed about using IIO for temperature threshold
notifications and I submitted multiple changes for that. Looks like we
also care of trip point changes. So I think we need more comprehensive
mechanism to address this.

May be we should have thermal mini summit during LPC again and decide a
comprehensive plan to address all asynchronous thermal notifications.



I have created a wiki for LPC 2016
http://wiki.linuxplumbersconf.org/2016:thermal

Overall I believe we need to solve the (temperature) sensing in a more
structured way within the kernel. We have three subsystem that allow
performing temperature sensing. They are different in design and
concept, but still solve similar problems.



I went through the LPC presentation/patches and had a couple of questions.

The thermal iio device seems perfectly suited for sending large amounts 
of thermal data from the kernel framework to user space. Are there a lot 
of platforms where thermal throttling happens in user space? If so, Is 
this an indication that passive thermal throttling is going into the 
user space some time in the future?


Our use cases don't really require too many notifications. But there 
seem to be other use cases out there that require lot more thermal info 
from the kernel. Just trying to understand what those are and what needs 
to be done to arrive at a solution that benefits all.



I would still prefer to get this better architectured.

Of course, we do not need to wait until LPC to start drafting this.

Again, please lets generate enough quorum to run the micro conf.

BR,

Eduardo Valentin



Much appreciate your comments and inputs.
Best Regards
Srikar

Re: [PATCH v2] thermal: add sysfs_notify on some attributes

[Srikar Srimath Tirumala]

On 03/28/2016 06:35 PM, Eduardo Valentin wrote:

On Tue, Mar 15, 2016 at 11:08:00PM +, Pandruvada, Srinivas wrote:

On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote:

Add a sysfs_notify on thermal_zone*/temp and cooling_device*/
cur_state whenever any trip is triggered or cur state is changed.

This change allows usermode apps to register themselves to get
notified, when certain thermal conditions occur and reduce their
workload. This workload throttling allows usermode to react before
hardware clocks are throttled and keep some critical apps running
reliably longer.

I think we need a combination of proposal in
https://patchwork.kernel.org/patch/7876351/ and this.

For example this patch notifies that some trip is violated, but that is
not enough for user space application to take any action. Some trips
violations user space may not care as this may be a transient one. The
patch from Eduardo address that by providing trip, temperature and last
temperature information. But that patch only address hot trips. I
understand why Eduardo doesn't want to be notified for passive trips as
there will be too many.



Yeah, my original intention was to avoid flooding userland, specially
through a pipe like the sysfs netlink, which is in use to deal with
other stuff.



How about if the number of notifications were to be reduced like in v3 
of this patch? Or is the consensus not to use sysfs_notify or uevents at 
all?



So IMO we need some mechanism to turn off notification and decide what
notification will result in user space notifications.
On some x86 systems we have 10+ passive/active trips, this will results
in too many notifications. We may be in thermally sensitive zone, where
more code excecution is more heat.



Exactly, that has direct impact not only on the process waiting for
thermal notifications, but also on other process listening to sysfs.


We may have some mask of trips for which will result in notifications.
By default no notifications, unless some user space requests.



The complexity of such communication (or even the current status of
sysfs ABI) starts to reach limit of such channel. We may definitely
consider other means, such as /dev interface, just like IIO does.



I agree with your point about the overhead of generating these events 
and thought maybe the problem could be partially addressed by reducing 
the number of notifications being sent. So with that in mind I created a 
V3 of the patches which does this. Please do take a look at it when you 
get a chance.



During last LPC we discussed about using IIO for temperature threshold
notifications and I submitted multiple changes for that. Looks like we
also care of trip point changes. So I think we need more comprehensive
mechanism to address this.

May be we should have thermal mini summit during LPC again and decide a
comprehensive plan to address all asynchronous thermal notifications.



I have created a wiki for LPC 2016
http://wiki.linuxplumbersconf.org/2016:thermal

Overall I believe we need to solve the (temperature) sensing in a more
structured way within the kernel. We have three subsystem that allow
performing temperature sensing. They are different in design and
concept, but still solve similar problems.



I went through the LPC presentation/patches and had a couple of questions.

The thermal iio device seems perfectly suited for sending large amounts 
of thermal data from the kernel framework to user space. Are there a lot 
of platforms where thermal throttling happens in user space? If so, Is 
this an indication that passive thermal throttling is going into the 
user space some time in the future?


Our use cases don't really require too many notifications. But there 
seem to be other use cases out there that require lot more thermal info 
from the kernel. Just trying to understand what those are and what needs 
to be done to arrive at a solution that benefits all.



I would still prefer to get this better architectured.

Of course, we do not need to wait until LPC to start drafting this.

Again, please lets generate enough quorum to run the micro conf.

BR,

Eduardo Valentin



Much appreciate your comments and inputs.
Best Regards
Srikar

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

[kbuild test robot]

Hi Tadeusz,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160329]
[cannot apply to crypto/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-algif-add-akcipher/20160330-090754
config: x86_64-allyesdebian (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   crypto/built-in.o: In function `alg_setkey':
>> af_alg.c:(.text+0x36513): undefined reference to `key_type_asymmetric'

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


.config.gz
Description: Binary data

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

[kbuild test robot]

Hi Tadeusz,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160329]
[cannot apply to crypto/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-algif-add-akcipher/20160330-090754
config: x86_64-allyesdebian (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   crypto/built-in.o: In function `alg_setkey':
>> af_alg.c:(.text+0x36513): undefined reference to `key_type_asymmetric'

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


.config.gz
Description: Binary data

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

[Yong Li]

If use the get_unaligned, below is the code example, but we cannot
detect if it is big endian or little endian. I would like to use the
same write logic as PCA957X_TYPE: use the i2c_smbus_write_byte_data
API to write two times. How do you think about it?

if (big_endian)
value = get_unaligned_be16(buf);
else
value = get_unaligned_le16(buf);

Thanks,
Yong Li

2016-03-30 0:33 GMT+08:00 Phil Reid :
> On 29/03/2016 10:39 PM, Alexander Stein wrote:
>>
>> You missed CC'ing Phil (Added for this post)
>>
>> On Tuesday 29 March 2016 20:53:58, Yong Li wrote:
>>>
>>> Thanks for your comment, I think I can change it to val[0] | (val[1]
>>> << 8), is it okay ?
>>
>>
>> Mh, currently there is only one caller (device_pca953x_init) which passes
>> only
>> 0, 0 or 0xff, 0xff, so endianess is irrelevant. But to be future proof
>> this
>> should be done in an endian-safe manner. Though cpu_to_le16p does not
>> work,
>> due to same alignment problem as casting to u16*.
>>
>
> I think get_unaligned((u16 *) val) should do the job.
> There's also get_unaligned_le* get_unaligned_be*
>
> --
> Regards
> Phil Reid
>

Re: [PATCH] gpio: pca953x: Use correct u16 value for register word write

[Yong Li]

If use the get_unaligned, below is the code example, but we cannot
detect if it is big endian or little endian. I would like to use the
same write logic as PCA957X_TYPE: use the i2c_smbus_write_byte_data
API to write two times. How do you think about it?

if (big_endian)
value = get_unaligned_be16(buf);
else
value = get_unaligned_le16(buf);

Thanks,
Yong Li

2016-03-30 0:33 GMT+08:00 Phil Reid :
> On 29/03/2016 10:39 PM, Alexander Stein wrote:
>>
>> You missed CC'ing Phil (Added for this post)
>>
>> On Tuesday 29 March 2016 20:53:58, Yong Li wrote:
>>>
>>> Thanks for your comment, I think I can change it to val[0] | (val[1]
>>> << 8), is it okay ?
>>
>>
>> Mh, currently there is only one caller (device_pca953x_init) which passes
>> only
>> 0, 0 or 0xff, 0xff, so endianess is irrelevant. But to be future proof
>> this
>> should be done in an endian-safe manner. Though cpu_to_le16p does not
>> work,
>> due to same alignment problem as casting to u16*.
>>
>
> I think get_unaligned((u16 *) val) should do the job.
> There's also get_unaligned_le* get_unaligned_be*
>
> --
> Regards
> Phil Reid
>

Re: [GIT PULL] Ceph fixes for -rc7

[NeilBrown]

On Wed, Mar 30 2016, Yan, Zheng wrote:

> On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown  wrote:
>> On Fri, Mar 25 2016, Ilya Dryomov wrote:
>>
>>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown  wrote:
 On Sun, Mar 06 2016, Sage Weil wrote:

> Hi Linus,
>
> Please pull the following Ceph patch from
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git 
> for-linus
>
> This is a final commit we missed to align the protocol compatibility with
> the feature bits.  It decodes a few extra fields in two different messages
> and reports EIO when they are used (not yet supported).
>
> Thanks!
> sage
>
>
> 
> Yan, Zheng (1):
>   ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support

 Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have
 exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and
 CEPH_FEATURE_CRUSH_TUNABLES5)??
>>>
>>> Yes, that was the point of getting it merged into -rc7.
>>
>> I did wonder if that might be the case.
>>
>>>
 Because when I backported this patch (and many others) to some ancient
 enterprise kernel, it caused mounts to fail.  If it really is meant to
 be the same value, then I must have some other backported issue to find
 and fix.
>>>
>>> It has to be backported in concert with changes that add support for
>>> the other two bits.
>>
>> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments
>> for different core code.
>>
>>>  How did mount fail?
>>
>> "can't read superblock".
>> dmesg contains
>>
>> [   50.822479] libceph: client144098 fsid 
>> 2b73bc29-3e78-490a-8fc6-21da1bf901ba
>> [   50.823746] libceph: mon0 192.168.1.122:6789 session established
>> [   51.635312] ceph: problem parsing mds trace -5
>> [   51.635317] ceph: mds parse_reply err -5
>> [   51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1)
>>
>> then a hex dump of header:, front: footer:
>>
>> Maybe my MDS is causing the problem?  It is based on v10.0.5 which
>> contains
>>
>> #define CEPH_FEATURE_CRUSH_TUNABLES5(1ULL<<58) /* chooseleaf stable mode 
>> */
>> // duplicated since it was introduced at the same time as 
>> CEPH_FEATURE_CRUSH_TUN
>> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING   (1ULL<<58) /* New, v7 
>> encoding */
>>
>> in ceph_features.h  i.e. two features using bit 58, but not
>> FS_FILE_LAYOUT_V2
>>
>> Should I expect Linux 4.5 to work with ceph 10.0.5 ??
>
> Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade
> to ceph 10.1.0
>

Ahhh..  I do wonder at the point of feature flags if they don't let you
run any client with any server...
Is there a compatability matrix published somewhere?
If I have to stay with 10.0.5 (I don't know yet), it is safe to use
Linux-4.4 code?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [GIT PULL] Ceph fixes for -rc7

[NeilBrown]

On Wed, Mar 30 2016, Yan, Zheng wrote:

> On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown  wrote:
>> On Fri, Mar 25 2016, Ilya Dryomov wrote:
>>
>>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown  wrote:
 On Sun, Mar 06 2016, Sage Weil wrote:

> Hi Linus,
>
> Please pull the following Ceph patch from
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git 
> for-linus
>
> This is a final commit we missed to align the protocol compatibility with
> the feature bits.  It decodes a few extra fields in two different messages
> and reports EIO when they are used (not yet supported).
>
> Thanks!
> sage
>
>
> 
> Yan, Zheng (1):
>   ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support

 Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have
 exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and
 CEPH_FEATURE_CRUSH_TUNABLES5)??
>>>
>>> Yes, that was the point of getting it merged into -rc7.
>>
>> I did wonder if that might be the case.
>>
>>>
 Because when I backported this patch (and many others) to some ancient
 enterprise kernel, it caused mounts to fail.  If it really is meant to
 be the same value, then I must have some other backported issue to find
 and fix.
>>>
>>> It has to be backported in concert with changes that add support for
>>> the other two bits.
>>
>> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments
>> for different core code.
>>
>>>  How did mount fail?
>>
>> "can't read superblock".
>> dmesg contains
>>
>> [   50.822479] libceph: client144098 fsid 
>> 2b73bc29-3e78-490a-8fc6-21da1bf901ba
>> [   50.823746] libceph: mon0 192.168.1.122:6789 session established
>> [   51.635312] ceph: problem parsing mds trace -5
>> [   51.635317] ceph: mds parse_reply err -5
>> [   51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1)
>>
>> then a hex dump of header:, front: footer:
>>
>> Maybe my MDS is causing the problem?  It is based on v10.0.5 which
>> contains
>>
>> #define CEPH_FEATURE_CRUSH_TUNABLES5(1ULL<<58) /* chooseleaf stable mode 
>> */
>> // duplicated since it was introduced at the same time as 
>> CEPH_FEATURE_CRUSH_TUN
>> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING   (1ULL<<58) /* New, v7 
>> encoding */
>>
>> in ceph_features.h  i.e. two features using bit 58, but not
>> FS_FILE_LAYOUT_V2
>>
>> Should I expect Linux 4.5 to work with ceph 10.0.5 ??
>
> Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade
> to ceph 10.1.0
>

Ahhh..  I do wonder at the point of feature flags if they don't let you
run any client with any server...
Is there a compatability matrix published somewhere?
If I have to stay with 10.0.5 (I don't know yet), it is safe to use
Linux-4.4 code?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

[Wangnan (F)]

On 2016/3/30 10:28, Wangnan (F) wrote:



On 2016/3/29 22:04, Peter Zijlstra wrote:

On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote:

Could you maybe write a perf/tests thingy for this so that _some_
userspace exists that exercises this new code?



  int perf_output_begin(struct perf_output_handle *handle,
struct perf_event *event, unsigned int size)
  {
+if (unlikely(is_write_backward(event)))
+return __perf_output_begin(handle, event, size, true);
  return __perf_output_begin(handle, event, size, false);
  }

Would something like:

int perf_output_begin(...)
{
if (unlikely(is_write_backward(event))
return perf_output_begin_backward(...);
return perf_output_begin_forward(...);
}

make sense; I'm not sure how much is still using this, but it seems
somewhat excessive to inline two copies of that thing into a single
function.


perf_output_begin is useful:

$ grep perf_output_begin ./kernel -r
./kernel/events/ring_buffer.c: * See perf_output_begin().
./kernel/events/ring_buffer.c:int perf_output_begin(struct 
perf_output_handle *handle,
./kernel/events/ring_buffer.c: * perf_output_begin() only checks 
rb->paused, therefore
./kernel/events/core.c:if (perf_output_begin(, event, 
header.size))
./kernel/events/core.c:ret = perf_output_begin(, event, 
read_event.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
se->event_id.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);


Events like PERF_RECORD_MMAP2 uses this function, so we still need to 
consider its overhead.


So I will use your first suggestion.



Sorry. Your second suggestion seems also good:

My implementation makes a big perf_output_begin(), but introduces only 
one load and one branch.


Your first suggestion introduces one load, one branch and one function call.

Your second suggestion introduces one load, and at least one (and at 
most three) branches.


I need some benchmarking result.

Thank you.

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

[Wangnan (F)]

On 2016/3/30 10:28, Wangnan (F) wrote:



On 2016/3/29 22:04, Peter Zijlstra wrote:

On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote:

Could you maybe write a perf/tests thingy for this so that _some_
userspace exists that exercises this new code?



  int perf_output_begin(struct perf_output_handle *handle,
struct perf_event *event, unsigned int size)
  {
+if (unlikely(is_write_backward(event)))
+return __perf_output_begin(handle, event, size, true);
  return __perf_output_begin(handle, event, size, false);
  }

Would something like:

int perf_output_begin(...)
{
if (unlikely(is_write_backward(event))
return perf_output_begin_backward(...);
return perf_output_begin_forward(...);
}

make sense; I'm not sure how much is still using this, but it seems
somewhat excessive to inline two copies of that thing into a single
function.


perf_output_begin is useful:

$ grep perf_output_begin ./kernel -r
./kernel/events/ring_buffer.c: * See perf_output_begin().
./kernel/events/ring_buffer.c:int perf_output_begin(struct 
perf_output_handle *handle,
./kernel/events/ring_buffer.c: * perf_output_begin() only checks 
rb->paused, therefore
./kernel/events/core.c:if (perf_output_begin(, event, 
header.size))
./kernel/events/core.c:ret = perf_output_begin(, event, 
read_event.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
se->event_id.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);


Events like PERF_RECORD_MMAP2 uses this function, so we still need to 
consider its overhead.


So I will use your first suggestion.



Sorry. Your second suggestion seems also good:

My implementation makes a big perf_output_begin(), but introduces only 
one load and one branch.


Your first suggestion introduces one load, one branch and one function call.

Your second suggestion introduces one load, and at least one (and at 
most three) branches.


I need some benchmarking result.

Thank you.

Re: [PATCH] perf jit: genelf makes assumptions about endian

[Michael Ellerman]

On Tue, 2016-03-29 at 17:59 +1100, Anton Blanchard wrote:

> Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
> incorrectly assumed that PowerPC is big endian only.
> 
> Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking
> for __BYTE_ORDER == __BIG_ENDIAN.
> 
> The PowerPC checks were also incorrect, they do not match what gcc
> emits. We should first look for __powerpc64__, then __powerpc__.
> 
> Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
> Signed-off-by: Anton Blanchard 

The diff's a little hard to read because you're pulling the endian logic out,
if I remove that I get something like:

>  #elif defined(__i386__)
>  #define GEN_ELF_ARCH EM_386
>  #define GEN_ELF_CLASSELFCLASS32
> -#elif defined(__ppcle__)
> -#define GEN_ELF_ARCH EM_PPC
> -#define GEN_ELF_CLASSELFCLASS64
> -#elif defined(__powerpc__)
> -#define GEN_ELF_ARCH EM_PPC64
> -#define GEN_ELF_CLASSELFCLASS64
> -#elif defined(__powerpcle__)
> +#elif defined(__powerpc64__)
>  #define GEN_ELF_ARCH EM_PPC64
>  #define GEN_ELF_CLASSELFCLASS64
> +#elif defined(__powerpc__)
> +#define GEN_ELF_ARCH EM_PPC
> +#define GEN_ELF_CLASSELFCLASS32
>  #else
>  #error "unsupported architecture"
>  #endif

Which looks correct to me.

And the consolidation of the endian logic is "obviously correct", so:

Acked-by: Michael Ellerman 

cheers

Re: [PATCH] perf jit: genelf makes assumptions about endian

[Michael Ellerman]

On Tue, 2016-03-29 at 17:59 +1100, Anton Blanchard wrote:

> Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
> incorrectly assumed that PowerPC is big endian only.
> 
> Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking
> for __BYTE_ORDER == __BIG_ENDIAN.
> 
> The PowerPC checks were also incorrect, they do not match what gcc
> emits. We should first look for __powerpc64__, then __powerpc__.
> 
> Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
> Signed-off-by: Anton Blanchard 

The diff's a little hard to read because you're pulling the endian logic out,
if I remove that I get something like:

>  #elif defined(__i386__)
>  #define GEN_ELF_ARCH EM_386
>  #define GEN_ELF_CLASSELFCLASS32
> -#elif defined(__ppcle__)
> -#define GEN_ELF_ARCH EM_PPC
> -#define GEN_ELF_CLASSELFCLASS64
> -#elif defined(__powerpc__)
> -#define GEN_ELF_ARCH EM_PPC64
> -#define GEN_ELF_CLASSELFCLASS64
> -#elif defined(__powerpcle__)
> +#elif defined(__powerpc64__)
>  #define GEN_ELF_ARCH EM_PPC64
>  #define GEN_ELF_CLASSELFCLASS64
> +#elif defined(__powerpc__)
> +#define GEN_ELF_ARCH EM_PPC
> +#define GEN_ELF_CLASSELFCLASS32
>  #else
>  #error "unsupported architecture"
>  #endif

Which looks correct to me.

And the consolidation of the endian logic is "obviously correct", so:

Acked-by: Michael Ellerman 

cheers

Re: [GIT PULL] Ceph fixes for -rc7

[Yan, Zheng]

On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown  wrote:
> On Fri, Mar 25 2016, Ilya Dryomov wrote:
>
>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown  wrote:
>>> On Sun, Mar 06 2016, Sage Weil wrote:
>>>
 Hi Linus,

 Please pull the following Ceph patch from

   git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git 
 for-linus

 This is a final commit we missed to align the protocol compatibility with
 the feature bits.  It decodes a few extra fields in two different messages
 and reports EIO when they are used (not yet supported).

 Thanks!
 sage


 
 Yan, Zheng (1):
   ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support
>>>
>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have
>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and
>>> CEPH_FEATURE_CRUSH_TUNABLES5)??
>>
>> Yes, that was the point of getting it merged into -rc7.
>
> I did wonder if that might be the case.
>
>>
>>> Because when I backported this patch (and many others) to some ancient
>>> enterprise kernel, it caused mounts to fail.  If it really is meant to
>>> be the same value, then I must have some other backported issue to find
>>> and fix.
>>
>> It has to be backported in concert with changes that add support for
>> the other two bits.
>
> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments
> for different core code.
>
>>  How did mount fail?
>
> "can't read superblock".
> dmesg contains
>
> [   50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba
> [   50.823746] libceph: mon0 192.168.1.122:6789 session established
> [   51.635312] ceph: problem parsing mds trace -5
> [   51.635317] ceph: mds parse_reply err -5
> [   51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1)
>
> then a hex dump of header:, front: footer:
>
> Maybe my MDS is causing the problem?  It is based on v10.0.5 which
> contains
>
> #define CEPH_FEATURE_CRUSH_TUNABLES5(1ULL<<58) /* chooseleaf stable mode 
> */
> // duplicated since it was introduced at the same time as 
> CEPH_FEATURE_CRUSH_TUN
> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING   (1ULL<<58) /* New, v7 encoding 
> */
>
> in ceph_features.h  i.e. two features using bit 58, but not
> FS_FILE_LAYOUT_V2
>
> Should I expect Linux 4.5 to work with ceph 10.0.5 ??

Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade
to ceph 10.1.0

Regards
Yan, Zheng

>
> Thanks,
> NeilBrown

Re: [PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

['Dmitry Torokhov']

Hi Duson,

On Wed, Mar 30, 2016 at 10:02:02AM +0800, DusonLin wrote:
> Only ABS_DISTANCE is not enough for upper OS  to distiguish hover event
> be triggered from object form faraway to and close touchpad surface or from
> object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help
> it.
> 
>  Object_at_faraway   object_at_hover_area  
> object_touch_touchpad
>   BTN_TOUCH 0  01
> BTN_TOOL_FINGER 0  11
>ABS_DISTANCE 0  10
> 
> Signed-off by: Duson Lin 
> ---
> drivers/input/mouse/elan_i2c_core.c |   14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 2f58985..9392a8c 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -4,7 +4,7 @@
>   * Copyright (c) 2013 ELAN Microelectronics Corp.
>   *
>   * Author: 林政維 (Duson Lin) 
> - * Version: 1.6.0
> + * Version: 1.6.1
>   *
>   * Based on cyapa driver:
>   * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
> @@ -845,23 +845,27 @@ static void elan_report_absolute(struct elan_tp_data 
> *data, u8 *packet)
> {
>   struct input_dev *input = data->input;
>   u8 *finger_data = [ETP_FINGER_DATA_OFFSET];
> -   int i;
> +  int i, valid_count = 0;

This appears all whitespace-damaged.

>   u8 tp_info = packet[ETP_TOUCH_INFO_OFFSET];
>   u8 hover_info = packet[ETP_HOVER_INFO_OFFSET];
>   bool contact_valid, hover_event;
> 
> -   hover_event = hover_info & 0x40;
> +  hover_event = (hover_info & 0x40);

We do not need parentheses here.

>   for (i = 0; i < ETP_MAX_FINGERS; i++) {
>   contact_valid = tp_info & (1U << (3 + i));
>   elan_report_contact(data, i, contact_valid, finger_data);
> 
> -   if (contact_valid)
> +  if (contact_valid) {
>   finger_data += ETP_FINGER_DATA_LEN;
> +  valid_count++;
> +  }
>   }
> 
>input_report_key(input, BTN_LEFT, tp_info & 0x01);
> +  input_report_key(input, BTN_TOOL_FINGER,
> +  ((hover_event != 0) | (valid_count > 0)));

You do not want to use "bitwise or" here.

>   input_report_abs(input, ABS_DISTANCE, hover_event != 0);
> -   input_mt_report_pointer_emulation(input, true);
> +  input_mt_report_pointer_emulation(input, false);

I wonder if we should teach input_mt_report_pointer_emulation() to
handle hover properly.

Thanks.

-- 
Dmitry

Re: [GIT PULL] Ceph fixes for -rc7

[Yan, Zheng]

On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown  wrote:
> On Fri, Mar 25 2016, Ilya Dryomov wrote:
>
>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown  wrote:
>>> On Sun, Mar 06 2016, Sage Weil wrote:
>>>
 Hi Linus,

 Please pull the following Ceph patch from

   git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git 
 for-linus

 This is a final commit we missed to align the protocol compatibility with
 the feature bits.  It decodes a few extra fields in two different messages
 and reports EIO when they are used (not yet supported).

 Thanks!
 sage


 
 Yan, Zheng (1):
   ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support
>>>
>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have
>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and
>>> CEPH_FEATURE_CRUSH_TUNABLES5)??
>>
>> Yes, that was the point of getting it merged into -rc7.
>
> I did wonder if that might be the case.
>
>>
>>> Because when I backported this patch (and many others) to some ancient
>>> enterprise kernel, it caused mounts to fail.  If it really is meant to
>>> be the same value, then I must have some other backported issue to find
>>> and fix.
>>
>> It has to be backported in concert with changes that add support for
>> the other two bits.
>
> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments
> for different core code.
>
>>  How did mount fail?
>
> "can't read superblock".
> dmesg contains
>
> [   50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba
> [   50.823746] libceph: mon0 192.168.1.122:6789 session established
> [   51.635312] ceph: problem parsing mds trace -5
> [   51.635317] ceph: mds parse_reply err -5
> [   51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1)
>
> then a hex dump of header:, front: footer:
>
> Maybe my MDS is causing the problem?  It is based on v10.0.5 which
> contains
>
> #define CEPH_FEATURE_CRUSH_TUNABLES5(1ULL<<58) /* chooseleaf stable mode 
> */
> // duplicated since it was introduced at the same time as 
> CEPH_FEATURE_CRUSH_TUN
> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING   (1ULL<<58) /* New, v7 encoding 
> */
>
> in ceph_features.h  i.e. two features using bit 58, but not
> FS_FILE_LAYOUT_V2
>
> Should I expect Linux 4.5 to work with ceph 10.0.5 ??

Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade
to ceph 10.1.0

Regards
Yan, Zheng

>
> Thanks,
> NeilBrown

Re: [PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

['Dmitry Torokhov']

Hi Duson,

On Wed, Mar 30, 2016 at 10:02:02AM +0800, DusonLin wrote:
> Only ABS_DISTANCE is not enough for upper OS  to distiguish hover event
> be triggered from object form faraway to and close touchpad surface or from
> object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help
> it.
> 
>  Object_at_faraway   object_at_hover_area  
> object_touch_touchpad
>   BTN_TOUCH 0  01
> BTN_TOOL_FINGER 0  11
>ABS_DISTANCE 0  10
> 
> Signed-off by: Duson Lin 
> ---
> drivers/input/mouse/elan_i2c_core.c |   14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 2f58985..9392a8c 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -4,7 +4,7 @@
>   * Copyright (c) 2013 ELAN Microelectronics Corp.
>   *
>   * Author: 林政維 (Duson Lin) 
> - * Version: 1.6.0
> + * Version: 1.6.1
>   *
>   * Based on cyapa driver:
>   * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
> @@ -845,23 +845,27 @@ static void elan_report_absolute(struct elan_tp_data 
> *data, u8 *packet)
> {
>   struct input_dev *input = data->input;
>   u8 *finger_data = [ETP_FINGER_DATA_OFFSET];
> -   int i;
> +  int i, valid_count = 0;

This appears all whitespace-damaged.

>   u8 tp_info = packet[ETP_TOUCH_INFO_OFFSET];
>   u8 hover_info = packet[ETP_HOVER_INFO_OFFSET];
>   bool contact_valid, hover_event;
> 
> -   hover_event = hover_info & 0x40;
> +  hover_event = (hover_info & 0x40);

We do not need parentheses here.

>   for (i = 0; i < ETP_MAX_FINGERS; i++) {
>   contact_valid = tp_info & (1U << (3 + i));
>   elan_report_contact(data, i, contact_valid, finger_data);
> 
> -   if (contact_valid)
> +  if (contact_valid) {
>   finger_data += ETP_FINGER_DATA_LEN;
> +  valid_count++;
> +  }
>   }
> 
>input_report_key(input, BTN_LEFT, tp_info & 0x01);
> +  input_report_key(input, BTN_TOOL_FINGER,
> +  ((hover_event != 0) | (valid_count > 0)));

You do not want to use "bitwise or" here.

>   input_report_abs(input, ABS_DISTANCE, hover_event != 0);
> -   input_mt_report_pointer_emulation(input, true);
> +  input_mt_report_pointer_emulation(input, false);

I wonder if we should teach input_mt_report_pointer_emulation() to
handle hover properly.

Thanks.

-- 
Dmitry

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

[Wangnan (F)]

On 2016/3/29 22:04, Peter Zijlstra wrote:

On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote:

Could you maybe write a perf/tests thingy for this so that _some_
userspace exists that exercises this new code?



  int perf_output_begin(struct perf_output_handle *handle,
  struct perf_event *event, unsigned int size)
  {
+   if (unlikely(is_write_backward(event)))
+   return __perf_output_begin(handle, event, size, true);
return __perf_output_begin(handle, event, size, false);
  }

Would something like:

int perf_output_begin(...)
{
if (unlikely(is_write_backward(event))
return perf_output_begin_backward(...);
return perf_output_begin_forward(...);
}

make sense; I'm not sure how much is still using this, but it seems
somewhat excessive to inline two copies of that thing into a single
function.


perf_output_begin is useful:

$ grep perf_output_begin ./kernel -r
./kernel/events/ring_buffer.c: * See perf_output_begin().
./kernel/events/ring_buffer.c:int perf_output_begin(struct 
perf_output_handle *handle,
./kernel/events/ring_buffer.c: * perf_output_begin() only checks 
rb->paused, therefore
./kernel/events/core.c:if (perf_output_begin(, event, 
header.size))
./kernel/events/core.c:ret = perf_output_begin(, event, 
read_event.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
se->event_id.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);


Events like PERF_RECORD_MMAP2 uses this function, so we still need to 
consider its overhead.


So I will use your first suggestion.

Thank you.

Re: [PATCH 4/4] perf core: Add backward attribute to perf event

[Wangnan (F)]

On 2016/3/29 22:04, Peter Zijlstra wrote:

On Mon, Mar 28, 2016 at 06:41:32AM +, Wang Nan wrote:

Could you maybe write a perf/tests thingy for this so that _some_
userspace exists that exercises this new code?



  int perf_output_begin(struct perf_output_handle *handle,
  struct perf_event *event, unsigned int size)
  {
+   if (unlikely(is_write_backward(event)))
+   return __perf_output_begin(handle, event, size, true);
return __perf_output_begin(handle, event, size, false);
  }

Would something like:

int perf_output_begin(...)
{
if (unlikely(is_write_backward(event))
return perf_output_begin_backward(...);
return perf_output_begin_forward(...);
}

make sense; I'm not sure how much is still using this, but it seems
somewhat excessive to inline two copies of that thing into a single
function.


perf_output_begin is useful:

$ grep perf_output_begin ./kernel -r
./kernel/events/ring_buffer.c: * See perf_output_begin().
./kernel/events/ring_buffer.c:int perf_output_begin(struct 
perf_output_handle *handle,
./kernel/events/ring_buffer.c: * perf_output_begin() only checks 
rb->paused, therefore
./kernel/events/core.c:if (perf_output_begin(, event, 
header.size))
./kernel/events/core.c:ret = perf_output_begin(, event, 
read_event.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
se->event_id.header.size);

./kernel/events/core.c:ret = perf_output_begin(, event,
./kernel/events/core.c:ret = perf_output_begin(, event, 
rec.header.size);


Events like PERF_RECORD_MMAP2 uses this function, so we still need to 
consider its overhead.


So I will use your first suggestion.

Thank you.

Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

[Shaohua Li]

On Wed, Mar 30, 2016 at 09:39:35AM +0800, Ming Lei wrote:
> On Wed, Mar 30, 2016 at 12:42 AM, Shaohua Li  wrote:
> > bio_alloc_bioset() allocates bvecs from bvec_slabs which can only
> > allocate maximum 256 bvec (eg, 1M for 4k pages). We can't bump
> > BLK_DEF_MAX_SECTORS to exceed this value otherwise bio_alloc_bioset will
> > fail.
> >
> > In the future, we can extend the size either bvec_slabs array is
> > expanded or the upcoming multipage bvec is added if pages are
> > contiguous. This one is suitable for stable.
> >
> > Fixes: d2be537c3ba (block: bump BLK_DEF_MAX_SECTORS to 2560)
> > Reported-by: Sebastian Roesner 
> > Cc: sta...@vger.kernel.org (4.2+)
> > Cc: Ming Lei 
> > Reviewed-by: Jeff Moyer 
> > Signed-off-by: Shaohua Li 
> > ---
> >  include/linux/blkdev.h | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index 7e5d7e0..da64325 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/linux/blkdev.h
> > @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, 
> > fmode_t has_write_perm);
> >  enum blk_default_limits {
> > BLK_MAX_SEGMENTS= 128,
> > BLK_SAFE_MAX_SECTORS= 255,
> > -   BLK_DEF_MAX_SECTORS = 2560,
> > +   /*
> > +* if you change this, please also change bvec_alloc and 
> > BIO_MAX_PAGES.
> > +* Otherwise bio_alloc_bioset will break.
> > +*/
> > +   BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
> 
> Thinking about it further, it isn't good to change the default max
> sectors because
> the patch affects REQ_PC bios too, which don't have the 1Mbytes limit at all.

what breaks setting REQ_PC to 1M limit? I can understand bigger limit might help
big raid array performance, but REQ_PC isn't the case.

> So suggest to just change bcache's queue max sector limit to 1M, that means
> we shouldn't encourage bcache's usage of bypassing bio_add_page().

Don't think this is a good idea. This is a limitation of block core,
block core should make sure the limitation doesn't break, not the
driver. On the other hand, are you going to fix all drivers? drivers can
set arbitrary max sector limit.

Thanks,
Shaohua

Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

[Shaohua Li]

On Wed, Mar 30, 2016 at 09:39:35AM +0800, Ming Lei wrote:
> On Wed, Mar 30, 2016 at 12:42 AM, Shaohua Li  wrote:
> > bio_alloc_bioset() allocates bvecs from bvec_slabs which can only
> > allocate maximum 256 bvec (eg, 1M for 4k pages). We can't bump
> > BLK_DEF_MAX_SECTORS to exceed this value otherwise bio_alloc_bioset will
> > fail.
> >
> > In the future, we can extend the size either bvec_slabs array is
> > expanded or the upcoming multipage bvec is added if pages are
> > contiguous. This one is suitable for stable.
> >
> > Fixes: d2be537c3ba (block: bump BLK_DEF_MAX_SECTORS to 2560)
> > Reported-by: Sebastian Roesner 
> > Cc: sta...@vger.kernel.org (4.2+)
> > Cc: Ming Lei 
> > Reviewed-by: Jeff Moyer 
> > Signed-off-by: Shaohua Li 
> > ---
> >  include/linux/blkdev.h | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index 7e5d7e0..da64325 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/linux/blkdev.h
> > @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, 
> > fmode_t has_write_perm);
> >  enum blk_default_limits {
> > BLK_MAX_SEGMENTS= 128,
> > BLK_SAFE_MAX_SECTORS= 255,
> > -   BLK_DEF_MAX_SECTORS = 2560,
> > +   /*
> > +* if you change this, please also change bvec_alloc and 
> > BIO_MAX_PAGES.
> > +* Otherwise bio_alloc_bioset will break.
> > +*/
> > +   BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
> 
> Thinking about it further, it isn't good to change the default max
> sectors because
> the patch affects REQ_PC bios too, which don't have the 1Mbytes limit at all.

what breaks setting REQ_PC to 1M limit? I can understand bigger limit might help
big raid array performance, but REQ_PC isn't the case.

> So suggest to just change bcache's queue max sector limit to 1M, that means
> we shouldn't encourage bcache's usage of bypassing bio_add_page().

Don't think this is a good idea. This is a limitation of block core,
block core should make sure the limitation doesn't break, not the
driver. On the other hand, are you going to fix all drivers? drivers can
set arbitrary max sector limit.

Thanks,
Shaohua

[PATCH v7 4/4] ARM64: dts: rockchip: add syscon-reboot-mode DT node

[Andy Yan]

Add syscon-reboot-mode driver DT node for rk3368 platform

Tested-by: Caesar Wang 
Signed-off-by: Andy Yan 

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- descirbe all reboot mode as property instead of subnode

Changes in v2:
- make this node as a subnode of pmugrf

Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 122777b..df062ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -554,8 +555,17 @@
};
 
pmugrf: syscon@ff738000 {
-   compatible = "rockchip,rk3368-pmugrf", "syscon";
+   compatible = "rockchip,rk3368-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xff738000 0x0 0x1000>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x200>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
cru: clock-controller@ff76 {
-- 
1.9.1

[PATCH v7 4/4] ARM64: dts: rockchip: add syscon-reboot-mode DT node

[Andy Yan]

Add syscon-reboot-mode driver DT node for rk3368 platform

Tested-by: Caesar Wang 
Signed-off-by: Andy Yan 

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- descirbe all reboot mode as property instead of subnode

Changes in v2:
- make this node as a subnode of pmugrf

Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 122777b..df062ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -554,8 +555,17 @@
};
 
pmugrf: syscon@ff738000 {
-   compatible = "rockchip,rk3368-pmugrf", "syscon";
+   compatible = "rockchip,rk3368-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xff738000 0x0 0x1000>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x200>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
cru: clock-controller@ff76 {
-- 
1.9.1

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

[kbuild test robot]

Hi Tadeusz,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160329]
[cannot apply to crypto/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-algif-add-akcipher/20160330-090754
config: arm-at91_dt_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from crypto/af_alg.c:26:0:
   include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to 
>> incomplete type
 return key->payload.data[asym_key_ids];
   ^
   crypto/af_alg.c: In function 'alg_setkey_id':
   crypto/af_alg.c:217:2: error: implicit declaration of function 'request_key' 
[-Werror=implicit-function-declaration]
 keyring = request_key(_type_asymmetric, key_name, NULL);
 ^
   crypto/af_alg.c:217:10: warning: assignment makes pointer from integer 
without a cast
 keyring = request_key(_type_asymmetric, key_name, NULL);
 ^
>> crypto/af_alg.c:223:16: error: dereferencing pointer to incomplete type
 pkey = keyring->payload.data[asym_crypto];
   ^
   cc1: some warnings being treated as errors

vim +74 include/keys/asymmetric-type.h

7901c1a8 David Howells 2014-09-16  68   
size_t len_1,
7901c1a8 David Howells 2014-09-16  69   
const void *val_2,
7901c1a8 David Howells 2014-09-16  70   
size_t len_2);
146aa8b1 David Howells 2015-10-21  71  static inline
146aa8b1 David Howells 2015-10-21  72  const struct asymmetric_key_ids 
*asymmetric_key_ids(const struct key *key)
146aa8b1 David Howells 2015-10-21  73  {
146aa8b1 David Howells 2015-10-21 @74   return key->payload.data[asym_key_ids];
146aa8b1 David Howells 2015-10-21  75  }
7901c1a8 David Howells 2014-09-16  76  
7901c1a8 David Howells 2014-09-16  77  /*

:: The code at line 74 was first introduced by commit
:: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific 
data with the payload data

:: TO: David Howells <dhowe...@redhat.com>
:: CC: David Howells <dhowe...@redhat.com>

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


.config.gz
Description: Binary data

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

[kbuild test robot]

Hi Tadeusz,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160329]
[cannot apply to crypto/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-algif-add-akcipher/20160330-090754
config: arm-at91_dt_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from crypto/af_alg.c:26:0:
   include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to 
>> incomplete type
 return key->payload.data[asym_key_ids];
   ^
   crypto/af_alg.c: In function 'alg_setkey_id':
   crypto/af_alg.c:217:2: error: implicit declaration of function 'request_key' 
[-Werror=implicit-function-declaration]
 keyring = request_key(_type_asymmetric, key_name, NULL);
 ^
   crypto/af_alg.c:217:10: warning: assignment makes pointer from integer 
without a cast
 keyring = request_key(_type_asymmetric, key_name, NULL);
 ^
>> crypto/af_alg.c:223:16: error: dereferencing pointer to incomplete type
 pkey = keyring->payload.data[asym_crypto];
   ^
   cc1: some warnings being treated as errors

vim +74 include/keys/asymmetric-type.h

7901c1a8 David Howells 2014-09-16  68   
size_t len_1,
7901c1a8 David Howells 2014-09-16  69   
const void *val_2,
7901c1a8 David Howells 2014-09-16  70   
size_t len_2);
146aa8b1 David Howells 2015-10-21  71  static inline
146aa8b1 David Howells 2015-10-21  72  const struct asymmetric_key_ids 
*asymmetric_key_ids(const struct key *key)
146aa8b1 David Howells 2015-10-21  73  {
146aa8b1 David Howells 2015-10-21 @74   return key->payload.data[asym_key_ids];
146aa8b1 David Howells 2015-10-21  75  }
7901c1a8 David Howells 2014-09-16  76  
7901c1a8 David Howells 2014-09-16  77  /*

:: The code at line 74 was first introduced by commit
:: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific 
data with the payload data

:: TO: David Howells 
:: CC: David Howells 

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


.config.gz
Description: Binary data

[PATCH v7 3/4] ARM: dts: rockchip: add syscon-reboot-mode DT node

[Andy Yan]

Rockchip platform use a SYSCON mapped register store
the reboot mode magic value for bootloader to use when
system reboot. So add syscon-reboot-mode driver DT node
for rk3xxx/rk3036/rk3288 based platform

Reviewed-by: Matthias Brugger 
Signed-off-by: Andy Yan 

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- descirbe all reboot mode as property instead of subnode
- add rk3036 support

Changes in v2:
- make this node as a subnode of PMU

Changes in v1:
- correct the maskrom magic number
- use macro defined in rockchip_boot-mode.h for reboot-mode DT node

 arch/arm/boot/dts/rk3036.dtsi| 11 ++-
 arch/arm/boot/dts/rk3288.dtsi| 10 ++
 arch/arm/boot/dts/rk3xxx.dtsi| 12 +++-
 include/dt-bindings/soc/rockchip_boot-mode.h | 15 +++
 4 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/soc/rockchip_boot-mode.h

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index b9567c1..4011c2e 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -261,8 +262,16 @@
};
 
grf: syscon@20008000 {
-   compatible = "rockchip,rk3036-grf", "syscon";
+   compatible = "rockchip,rk3036-grf", "syscon", "simple-mfd";
reg = <0x20008000 0x1000>;
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x1d8>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
acodec: acodec-ana@2003 {
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 8ac49f3..9aa7d73 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -713,6 +714,15 @@
clocks = < ACLK_GPU>;
};
};
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x94>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
sgrf: syscon@ff74 {
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 99eeea7..f8f661f 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -43,6 +43,7 @@
 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -243,8 +244,17 @@
};
 
pmu: pmu@20004000 {
-   compatible = "rockchip,rk3066-pmu", "syscon";
+   compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
reg = <0x20004000 0x100>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x40>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
grf: grf@20008000 {
diff --git a/include/dt-bindings/soc/rockchip_boot-mode.h 
b/include/dt-bindings/soc/rockchip_boot-mode.h
new file mode 100644
index 000..ae7c867
--- /dev/null
+++ b/include/dt-bindings/soc/rockchip_boot-mode.h
@@ -0,0 +1,15 @@
+#ifndef __ROCKCHIP_BOOT_MODE_H
+#define __ROCKCHIP_BOOT_MODE_H
+
+/*high 24 bits is tag, low 8 bits is type*/
+#define REBOOT_FLAG0x5242C300
+/* normal boot */
+#define BOOT_NORMAL(REBOOT_FLAG + 0)
+/* enter bootloader rockusb mode */
+#define BOOT_BL_DOWNLOAD   (REBOOT_FLAG + 1)
+/* enter recovery */
+#define BOOT_RECOVERY  (REBOOT_FLAG + 3)
+ /* enter fastboot mode */
+#define BOOT_FASTBOOT  (REBOOT_FLAG + 9)
+
+#endif
-- 
1.9.1

[PATCH v7 3/4] ARM: dts: rockchip: add syscon-reboot-mode DT node

[Andy Yan]

Rockchip platform use a SYSCON mapped register store
the reboot mode magic value for bootloader to use when
system reboot. So add syscon-reboot-mode driver DT node
for rk3xxx/rk3036/rk3288 based platform

Reviewed-by: Matthias Brugger 
Signed-off-by: Andy Yan 

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- descirbe all reboot mode as property instead of subnode
- add rk3036 support

Changes in v2:
- make this node as a subnode of PMU

Changes in v1:
- correct the maskrom magic number
- use macro defined in rockchip_boot-mode.h for reboot-mode DT node

 arch/arm/boot/dts/rk3036.dtsi| 11 ++-
 arch/arm/boot/dts/rk3288.dtsi| 10 ++
 arch/arm/boot/dts/rk3xxx.dtsi| 12 +++-
 include/dt-bindings/soc/rockchip_boot-mode.h | 15 +++
 4 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/soc/rockchip_boot-mode.h

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index b9567c1..4011c2e 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -261,8 +262,16 @@
};
 
grf: syscon@20008000 {
-   compatible = "rockchip,rk3036-grf", "syscon";
+   compatible = "rockchip,rk3036-grf", "syscon", "simple-mfd";
reg = <0x20008000 0x1000>;
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x1d8>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
acodec: acodec-ana@2003 {
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 8ac49f3..9aa7d73 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -713,6 +714,15 @@
clocks = < ACLK_GPU>;
};
};
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x94>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
sgrf: syscon@ff74 {
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 99eeea7..f8f661f 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -43,6 +43,7 @@
 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -243,8 +244,17 @@
};
 
pmu: pmu@20004000 {
-   compatible = "rockchip,rk3066-pmu", "syscon";
+   compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
reg = <0x20004000 0x100>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x40>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
};
 
grf: grf@20008000 {
diff --git a/include/dt-bindings/soc/rockchip_boot-mode.h 
b/include/dt-bindings/soc/rockchip_boot-mode.h
new file mode 100644
index 000..ae7c867
--- /dev/null
+++ b/include/dt-bindings/soc/rockchip_boot-mode.h
@@ -0,0 +1,15 @@
+#ifndef __ROCKCHIP_BOOT_MODE_H
+#define __ROCKCHIP_BOOT_MODE_H
+
+/*high 24 bits is tag, low 8 bits is type*/
+#define REBOOT_FLAG0x5242C300
+/* normal boot */
+#define BOOT_NORMAL(REBOOT_FLAG + 0)
+/* enter bootloader rockusb mode */
+#define BOOT_BL_DOWNLOAD   (REBOOT_FLAG + 1)
+/* enter recovery */
+#define BOOT_RECOVERY  (REBOOT_FLAG + 3)
+ /* enter fastboot mode */
+#define BOOT_FASTBOOT  (REBOOT_FLAG + 9)
+
+#endif
-- 
1.9.1

[PATCH v7 2/4] power: reset: add reboot mode driver

[Andy Yan]

This driver parses the reboot commands like "reboot bootloader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some place like special register or sram, which can
be read by the bootloader after system reboot, then the bootloader
can take different action according to the mode stored.

This is commonly used on Android based devices, in order to
reboot the device into fastboot or recovery mode.

Reviewed-by: Matthias Brugger 
Reviewed-by: Moritz Fischer 
Tested-by: John Stultz 
Acked-by: John Stultz 
Signed-off-by: Andy Yan 

---

Changes in v7:
- address some suggestions from Krzysztof, make syscon-reboot-mode driver data 
self-contained.

Changes in v6: None
Changes in v5:
- use two blank space under help in Kconfig
- use unsigned int instead of int for member magic in struct mode_info

Changes in v4:
- make this driver depends on OF to avoid kbuild test error

Changes in v3:
- scan multi properities
- add mask value for some platform which only use some bits of the register
  to store boot mode magic value

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot

 drivers/power/reset/Kconfig  |  13 
 drivers/power/reset/Makefile |   2 +
 drivers/power/reset/reboot-mode.c| 115 +++
 drivers/power/reset/reboot-mode.h|   6 ++
 drivers/power/reset/syscon-reboot-mode.c |  86 +++
 5 files changed, 222 insertions(+)
 create mode 100644 drivers/power/reset/reboot-mode.c
 create mode 100644 drivers/power/reset/reboot-mode.h
 create mode 100644 drivers/power/reset/syscon-reboot-mode.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..cf50630 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -173,5 +173,18 @@ config POWER_RESET_ZX
help
  Reboot support for ZTE SoCs.
 
+config REBOOT_MODE
+   tristate
+
+config SYSCON_REBOOT_MODE
+   bool "Generic SYSCON regmap reboot mode driver"
+   depends on OF
+   select REBOOT_MODE
+   help
+ Say y here will enable reboot mode driver. This will
+ get reboot mode arguments and store it in SYSCON mapped
+ register, then the bootloader can read it to take different
+ action according to the mode.
+
 endif
 
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 096fa67..a63865b 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -20,3 +20,5 @@ obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
 obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
 obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
 obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
+obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
+obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
new file mode 100644
index 000..ae6f931
--- /dev/null
+++ b/drivers/power/reset/reboot-mode.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "reboot-mode.h"
+
+#define PREFIX "mode-"
+
+struct mode_info {
+   const char *mode;
+   unsigned int magic;
+   struct list_head list;
+};
+
+struct reboot_mode_driver {
+   struct device *dev;
+   struct list_head head;
+   int (*write)(struct device *dev, int magic);
+   struct notifier_block reboot_notifier;
+};
+
+static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
+const char *cmd)
+{
+   const char *normal = "normal";
+   int magic = 0;
+   struct mode_info *info;
+
+   if (!cmd)
+   cmd = normal;
+
+   list_for_each_entry(info, >head, list) {
+   if (!strcmp(info->mode, cmd)) {
+   magic = info->magic;
+   break;
+   }
+   }
+
+   return magic;
+}
+
+static int reboot_mode_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   struct reboot_mode_driver *reboot;
+   int magic;
+
+   reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
+   magic = get_reboot_mode_magic(reboot, cmd);
+   if (magic)
+   reboot->write(reboot->dev, 

[PATCH v7 2/4] power: reset: add reboot mode driver

[Andy Yan]

This driver parses the reboot commands like "reboot bootloader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some place like special register or sram, which can
be read by the bootloader after system reboot, then the bootloader
can take different action according to the mode stored.

This is commonly used on Android based devices, in order to
reboot the device into fastboot or recovery mode.

Reviewed-by: Matthias Brugger 
Reviewed-by: Moritz Fischer 
Tested-by: John Stultz 
Acked-by: John Stultz 
Signed-off-by: Andy Yan 

---

Changes in v7:
- address some suggestions from Krzysztof, make syscon-reboot-mode driver data 
self-contained.

Changes in v6: None
Changes in v5:
- use two blank space under help in Kconfig
- use unsigned int instead of int for member magic in struct mode_info

Changes in v4:
- make this driver depends on OF to avoid kbuild test error

Changes in v3:
- scan multi properities
- add mask value for some platform which only use some bits of the register
  to store boot mode magic value

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot

 drivers/power/reset/Kconfig  |  13 
 drivers/power/reset/Makefile |   2 +
 drivers/power/reset/reboot-mode.c| 115 +++
 drivers/power/reset/reboot-mode.h|   6 ++
 drivers/power/reset/syscon-reboot-mode.c |  86 +++
 5 files changed, 222 insertions(+)
 create mode 100644 drivers/power/reset/reboot-mode.c
 create mode 100644 drivers/power/reset/reboot-mode.h
 create mode 100644 drivers/power/reset/syscon-reboot-mode.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..cf50630 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -173,5 +173,18 @@ config POWER_RESET_ZX
help
  Reboot support for ZTE SoCs.
 
+config REBOOT_MODE
+   tristate
+
+config SYSCON_REBOOT_MODE
+   bool "Generic SYSCON regmap reboot mode driver"
+   depends on OF
+   select REBOOT_MODE
+   help
+ Say y here will enable reboot mode driver. This will
+ get reboot mode arguments and store it in SYSCON mapped
+ register, then the bootloader can read it to take different
+ action according to the mode.
+
 endif
 
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 096fa67..a63865b 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -20,3 +20,5 @@ obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
 obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
 obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
 obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
+obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
+obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
new file mode 100644
index 000..ae6f931
--- /dev/null
+++ b/drivers/power/reset/reboot-mode.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "reboot-mode.h"
+
+#define PREFIX "mode-"
+
+struct mode_info {
+   const char *mode;
+   unsigned int magic;
+   struct list_head list;
+};
+
+struct reboot_mode_driver {
+   struct device *dev;
+   struct list_head head;
+   int (*write)(struct device *dev, int magic);
+   struct notifier_block reboot_notifier;
+};
+
+static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
+const char *cmd)
+{
+   const char *normal = "normal";
+   int magic = 0;
+   struct mode_info *info;
+
+   if (!cmd)
+   cmd = normal;
+
+   list_for_each_entry(info, >head, list) {
+   if (!strcmp(info->mode, cmd)) {
+   magic = info->magic;
+   break;
+   }
+   }
+
+   return magic;
+}
+
+static int reboot_mode_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   struct reboot_mode_driver *reboot;
+   int magic;
+
+   reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
+   magic = get_reboot_mode_magic(reboot, cmd);
+   if (magic)
+   reboot->write(reboot->dev, magic);
+
+   return NOTIFY_DONE;
+}
+
+int reboot_mode_register(struct device *dev, int (*write)(struct device *, 

[PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

[Andy Yan]

Add device tree bindings document for reboot-mode driver.

Signed-off-by: Andy Yan 
Acked-by: Rob Herring 

---

Changes in v7:
- fix some spelling mistakes
- declare that the mode magic should be none-zero value

Changes in v6:
- fix a typo with "property"
- describe property "mask" more clear

Changes in v5:
- delete a unnecessary blank line in syscon-reboot-mode.txt
- rename mode-fastoboot to mode-bootloader in syscon-reboot-mode.txt
- rename macro BOOT_LOADER to BOOT_BL_DOWNLOAD, which gives a more clear mean

Changes in v4:
- remove mode-maskrom
- rename mode-fastboot to mode-bootloader to keep compatible with the exiting 
Android device

Changes in v3:
- descirbe all reboot mode as properity instead of subnode

Changes in v2: None
Changes in v1: None

 .../bindings/power/reset/reboot-mode.txt   | 25 
 .../bindings/power/reset/syscon-reboot-mode.txt| 35 ++
 2 files changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/reboot-mode.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt

diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt 
b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
new file mode 100644
index 000..de34f27
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
@@ -0,0 +1,25 @@
+Generic reboot mode core map driver
+
+This driver get reboot mode arguments and call the write
+interface to store the magic value in special register
+or ram. Then the bootloader can read it and take different
+action according to the argument stored.
+
+All mode properties are vendor specific, it is a indication to tell
+the bootloader what to do when the system reboots, and should be named
+as mode-xxx =  (xxx is mode name, magic should be a none-zero value).
+
+For example modes common on Android platform:
+- mode-normal: Normal reboot mode, system reboot with command "reboot".
+- mode-recovery: Android Recovery mode, it is a mode to format the device or 
update a new image.
+- mode-bootloader: Android fastboot mode, it's a mode to re-flash partitions 
on the Android based device.
+- mode-loader: A bootloader mode, it's a mode used to download image on 
Rockchip platform,
+  usually used in development.
+
+Example:
+   reboot-mode {
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   }
diff --git 
a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt 
b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
new file mode 100644
index 000..f7ce1d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
@@ -0,0 +1,35 @@
+SYSCON reboot mode driver
+
+This driver gets reboot mode magic value form reboot-mode driver
+and stores it in a SYSCON mapped register. Then the bootloader
+can read it and take different action according to the magic
+value stored.
+
+This DT node should be represented as a sub-node of a "syscon", "simple-mfd"
+node.
+
+Required properties:
+- compatible: should be "syscon-reboot-mode"
+- offset: offset in the register map for the storage register (in bytes)
+
+Optional property:
+- mask: bits mask of the bits in the register to store the reboot mode magic 
value,
+  default set to 0x if missing.
+
+The rest of the properties should follow the generic reboot-mode description
+found in reboot-mode.txt
+
+Example:
+   pmu: pmu@20004000 {
+   compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
+   reg = <0x20004000 0x100>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x40>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
+   };
-- 
1.9.1

[PATCH v7 1/4] dt-bindings: power: reset: add document for reboot-mode driver

[Andy Yan]

Add device tree bindings document for reboot-mode driver.

Signed-off-by: Andy Yan 
Acked-by: Rob Herring 

---

Changes in v7:
- fix some spelling mistakes
- declare that the mode magic should be none-zero value

Changes in v6:
- fix a typo with "property"
- describe property "mask" more clear

Changes in v5:
- delete a unnecessary blank line in syscon-reboot-mode.txt
- rename mode-fastoboot to mode-bootloader in syscon-reboot-mode.txt
- rename macro BOOT_LOADER to BOOT_BL_DOWNLOAD, which gives a more clear mean

Changes in v4:
- remove mode-maskrom
- rename mode-fastboot to mode-bootloader to keep compatible with the exiting 
Android device

Changes in v3:
- descirbe all reboot mode as properity instead of subnode

Changes in v2: None
Changes in v1: None

 .../bindings/power/reset/reboot-mode.txt   | 25 
 .../bindings/power/reset/syscon-reboot-mode.txt| 35 ++
 2 files changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/reboot-mode.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt

diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt 
b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
new file mode 100644
index 000..de34f27
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
@@ -0,0 +1,25 @@
+Generic reboot mode core map driver
+
+This driver get reboot mode arguments and call the write
+interface to store the magic value in special register
+or ram. Then the bootloader can read it and take different
+action according to the argument stored.
+
+All mode properties are vendor specific, it is a indication to tell
+the bootloader what to do when the system reboots, and should be named
+as mode-xxx =  (xxx is mode name, magic should be a none-zero value).
+
+For example modes common on Android platform:
+- mode-normal: Normal reboot mode, system reboot with command "reboot".
+- mode-recovery: Android Recovery mode, it is a mode to format the device or 
update a new image.
+- mode-bootloader: Android fastboot mode, it's a mode to re-flash partitions 
on the Android based device.
+- mode-loader: A bootloader mode, it's a mode used to download image on 
Rockchip platform,
+  usually used in development.
+
+Example:
+   reboot-mode {
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   }
diff --git 
a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt 
b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
new file mode 100644
index 000..f7ce1d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
@@ -0,0 +1,35 @@
+SYSCON reboot mode driver
+
+This driver gets reboot mode magic value form reboot-mode driver
+and stores it in a SYSCON mapped register. Then the bootloader
+can read it and take different action according to the magic
+value stored.
+
+This DT node should be represented as a sub-node of a "syscon", "simple-mfd"
+node.
+
+Required properties:
+- compatible: should be "syscon-reboot-mode"
+- offset: offset in the register map for the storage register (in bytes)
+
+Optional property:
+- mask: bits mask of the bits in the register to store the reboot mode magic 
value,
+  default set to 0x if missing.
+
+The rest of the properties should follow the generic reboot-mode description
+found in reboot-mode.txt
+
+Example:
+   pmu: pmu@20004000 {
+   compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
+   reg = <0x20004000 0x100>;
+
+   reboot-mode {
+   compatible = "syscon-reboot-mode";
+   offset = <0x40>;
+   mode-normal = ;
+   mode-recovery = ;
+   mode-bootloader = ;
+   mode-loader = ;
+   };
+   };
-- 
1.9.1

[PATCH v7 0/4] add reboot mode driver

[Andy Yan]

This driver parses the reboot commands like "reboot bootloader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the corresponding  write interfae
to store the boot mode in some place like special register
or ram, which can be read by the bootloader after system
reboot.

This is commonly done on Android based devices, in order to
reboot the device into fastboot or recovery mode.


Changes in v7:
- fix some spelling mistakes
- declare that the mode magic should be none-zero value
- address some suggestions from Krzysztof, make syscon-reboot-mode driver data 
self-contained.

Changes in v6:
- fix a typo with "property"
- describe property "mask" more clear

Changes in v5:
- delete a unnecessary blank line in syscon-reboot-mode.txt
- rename mode-fastoboot to mode-bootloader in syscon-reboot-mode.txt
- rename macro BOOT_LOADER to BOOT_BL_DOWNLOAD, which gives a more clear mean
- use two blank space under help in Kconfig
- use unsigned int instead of int for member magic in struct mode_info

Changes in v4:
- remove mode-maskrom
- rename mode-fastboot to mode-bootloader to keep compatible with the exiting 
Android device
- make this driver depends on OF to avoid kbuild test error

Changes in v3:
- descirbe all reboot mode as properity instead of subnode
- scan multi properities
- add mask value for some platform which only use some bits of the register
  to store boot mode magic value
- descirbe all reboot mode as property instead of subnode
- add rk3036 support
- descirbe all reboot mode as property instead of subnode

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver
- make this node as a subnode of PMU
- make this node as a subnode of pmugrf

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot
- correct the maskrom magic number
- use macro defined in rockchip_boot-mode.h for reboot-mode DT node

Andy Yan (4):
  dt-bindings: power: reset: add document for reboot-mode driver
  power: reset: add reboot mode driver
  ARM: dts: rockchip: add syscon-reboot-mode DT node
  ARM64: dts: rockchip: add syscon-reboot-mode DT node

 .../bindings/power/reset/reboot-mode.txt   |  25 +
 .../bindings/power/reset/syscon-reboot-mode.txt|  35 +++
 arch/arm/boot/dts/rk3036.dtsi  |  11 +-
 arch/arm/boot/dts/rk3288.dtsi  |  10 ++
 arch/arm/boot/dts/rk3xxx.dtsi  |  12 ++-
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  12 ++-
 drivers/power/reset/Kconfig|  13 +++
 drivers/power/reset/Makefile   |   2 +
 drivers/power/reset/reboot-mode.c  | 115 +
 drivers/power/reset/reboot-mode.h  |   6 ++
 drivers/power/reset/syscon-reboot-mode.c   |  86 +++
 include/dt-bindings/soc/rockchip_boot-mode.h   |  15 +++
 12 files changed, 339 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/reboot-mode.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
 create mode 100644 drivers/power/reset/reboot-mode.c
 create mode 100644 drivers/power/reset/reboot-mode.h
 create mode 100644 drivers/power/reset/syscon-reboot-mode.c
 create mode 100644 include/dt-bindings/soc/rockchip_boot-mode.h

-- 
1.9.1

[PATCH v7 0/4] add reboot mode driver

[Andy Yan]

This driver parses the reboot commands like "reboot bootloader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the corresponding  write interfae
to store the boot mode in some place like special register
or ram, which can be read by the bootloader after system
reboot.

This is commonly done on Android based devices, in order to
reboot the device into fastboot or recovery mode.


Changes in v7:
- fix some spelling mistakes
- declare that the mode magic should be none-zero value
- address some suggestions from Krzysztof, make syscon-reboot-mode driver data 
self-contained.

Changes in v6:
- fix a typo with "property"
- describe property "mask" more clear

Changes in v5:
- delete a unnecessary blank line in syscon-reboot-mode.txt
- rename mode-fastoboot to mode-bootloader in syscon-reboot-mode.txt
- rename macro BOOT_LOADER to BOOT_BL_DOWNLOAD, which gives a more clear mean
- use two blank space under help in Kconfig
- use unsigned int instead of int for member magic in struct mode_info

Changes in v4:
- remove mode-maskrom
- rename mode-fastboot to mode-bootloader to keep compatible with the exiting 
Android device
- make this driver depends on OF to avoid kbuild test error

Changes in v3:
- descirbe all reboot mode as properity instead of subnode
- scan multi properities
- add mask value for some platform which only use some bits of the register
  to store boot mode magic value
- descirbe all reboot mode as property instead of subnode
- add rk3036 support
- descirbe all reboot mode as property instead of subnode

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver
- make this node as a subnode of PMU
- make this node as a subnode of pmugrf

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot
- correct the maskrom magic number
- use macro defined in rockchip_boot-mode.h for reboot-mode DT node

Andy Yan (4):
  dt-bindings: power: reset: add document for reboot-mode driver
  power: reset: add reboot mode driver
  ARM: dts: rockchip: add syscon-reboot-mode DT node
  ARM64: dts: rockchip: add syscon-reboot-mode DT node

 .../bindings/power/reset/reboot-mode.txt   |  25 +
 .../bindings/power/reset/syscon-reboot-mode.txt|  35 +++
 arch/arm/boot/dts/rk3036.dtsi  |  11 +-
 arch/arm/boot/dts/rk3288.dtsi  |  10 ++
 arch/arm/boot/dts/rk3xxx.dtsi  |  12 ++-
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  12 ++-
 drivers/power/reset/Kconfig|  13 +++
 drivers/power/reset/Makefile   |   2 +
 drivers/power/reset/reboot-mode.c  | 115 +
 drivers/power/reset/reboot-mode.h  |   6 ++
 drivers/power/reset/syscon-reboot-mode.c   |  86 +++
 include/dt-bindings/soc/rockchip_boot-mode.h   |  15 +++
 12 files changed, 339 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/reboot-mode.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
 create mode 100644 drivers/power/reset/reboot-mode.c
 create mode 100644 drivers/power/reset/reboot-mode.h
 create mode 100644 drivers/power/reset/syscon-reboot-mode.c
 create mode 100644 include/dt-bindings/soc/rockchip_boot-mode.h

-- 
1.9.1

Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class

[Namhyung Kim]

On March 30, 2016 8:28:21 AM GMT+09:00, Taeung Song  
wrote:
>Hi, Arnaldo and Namhyung
>
>On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu:
>>> This infrastructure code was designed for
>>> upcoming features of perf-config.
>>>
>>> That collect config key-value pairs from user and
>>> system config files (i.e. user wide ~/.perfconfig
>>> and system wide $(sysconfdir)/perfconfig)
>>> to manage perf's configs.
>>>
>>> Cc: Namhyung Kim 
>>> Cc: Jiri Olsa 
>>> Signed-off-by: Taeung Song 
>>
>> Waiting for ack.
>
>Namhyung,
>The difference between v3 and v4 for this patch as below.
>(fill perf_config_set__delete() in collect_config() for state of error)
>
>Can you review this patch, again ?

Acked-by: Namhyung Kim 

Thanks
Namhyung


>diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>index 725015f..2cfafff 100644
>--- a/tools/perf/util/config.c
>+++ b/tools/perf/util/config.c
>@@ -705,14 +706,15 @@ static int set_value(struct perf_config_item 
>*config_item, const char *value)
>  }
>
>  static int collect_config(const char *var, const char *value,
>-  void *section_list)
>+  void *perf_config_set)
>  {
>  int ret = -1;
>  char *ptr, *key;
>  char *section_name, *name;
>  struct perf_config_section *section = NULL;
>  struct perf_config_item *config_item = NULL;
>-struct list_head *sections = section_list;
>+struct perf_config_set *perf_configs = perf_config_set;
>+struct list_head *sections = _configs->sections;
>
>  key = ptr = strdup(var);
>  if (!key) {
>@@ -743,7 +745,8 @@ static int collect_config(const char *var, const 
>char *value,
>
>  out_free:
>  free(key);
>-return ret;
>+perf_config_set__delete(perf_configs);
>+return -1;
>  }
>
>  static struct perf_config_set *perf_config_set__init(struct 
>perf_config_set *perf_configs)
>@@ -777,7 +780,7 @@ struct perf_config_set *perf_config_set__new(void)
>  return NULL;
>
>  perf_config_set__init(perf_configs);
>-perf_config(collect_config, _configs->sections);
>+perf_config(collect_config, perf_configs);
>
>  return perf_configs;
>  }
>
>
>Thanks,
>Taeung
>
>
>>> ---
>>>   tools/perf/util/config.c | 171
>+++
>>>   tools/perf/util/config.h |  26 +++
>>>   2 files changed, 197 insertions(+)
>>>   create mode 100644 tools/perf/util/config.h
>>>
>>> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>>> index 4e72763..2dbf47c 100644
>>> --- a/tools/perf/util/config.c
>>> +++ b/tools/perf/util/config.c
>>> @@ -13,6 +13,7 @@
>>>   #include 
>>>   #include "util/hist.h"  /* perf_hist_config */
>>>   #include "util/llvm-utils.h"   /* perf_llvm_config */
>>> +#include "config.h"
>>>
>>>   #define MAXNAME (256)
>>>
>>> @@ -506,6 +507,176 @@ out:
>>> return ret;
>>>   }
>>>
>>> +static struct perf_config_section *find_section(struct list_head
>*sections,
>>> +   const char *section_name)
>>> +{
>>> +   struct perf_config_section *section;
>>> +
>>> +   list_for_each_entry(section, sections, list)
>>> +   if (!strcmp(section->name, section_name))
>>> +   return section;
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +static struct perf_config_item *find_config_item(const char *name,
>>> +struct perf_config_section 
>>> *section)
>>> +{
>>> +   struct perf_config_item *config_item;
>>> +
>>> +   list_for_each_entry(config_item, >config_items, list)
>>> +   if (!strcmp(config_item->name, name))
>>> +   return config_item;
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +static void find_config(struct list_head *sections,
>>> +   struct perf_config_section **section,
>>> +   struct perf_config_item **config_item,
>>> +   const char *section_name, const char *name)
>>> +{
>>> +   *section = find_section(sections, section_name);
>>> +
>>> +   if (*section != NULL)
>>> +   *config_item = find_config_item(name, *section);
>>> +   else
>>> +   *config_item = NULL;
>>> +}
>>> +
>>> +static struct perf_config_section *add_section(struct list_head
>*sections,
>>> +  const char *section_name)
>>> +{
>>> +   struct perf_config_section *section = zalloc(sizeof(*section));
>>> +
>>> +   if (!section)
>>> +   return NULL;
>>> +
>>> +   INIT_LIST_HEAD(>config_items);
>>> +   section->name = strdup(section_name);
>>> +   if (!section->name) {
>>> +   pr_err("%s: strdup failed\n", __func__);
>>> +   free(section);
>>> +   return NULL;
>>> +   }
>>> +
>>> +   

Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class

[Namhyung Kim]

On March 30, 2016 8:28:21 AM GMT+09:00, Taeung Song  
wrote:
>Hi, Arnaldo and Namhyung
>
>On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu:
>>> This infrastructure code was designed for
>>> upcoming features of perf-config.
>>>
>>> That collect config key-value pairs from user and
>>> system config files (i.e. user wide ~/.perfconfig
>>> and system wide $(sysconfdir)/perfconfig)
>>> to manage perf's configs.
>>>
>>> Cc: Namhyung Kim 
>>> Cc: Jiri Olsa 
>>> Signed-off-by: Taeung Song 
>>
>> Waiting for ack.
>
>Namhyung,
>The difference between v3 and v4 for this patch as below.
>(fill perf_config_set__delete() in collect_config() for state of error)
>
>Can you review this patch, again ?

Acked-by: Namhyung Kim 

Thanks
Namhyung


>diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>index 725015f..2cfafff 100644
>--- a/tools/perf/util/config.c
>+++ b/tools/perf/util/config.c
>@@ -705,14 +706,15 @@ static int set_value(struct perf_config_item 
>*config_item, const char *value)
>  }
>
>  static int collect_config(const char *var, const char *value,
>-  void *section_list)
>+  void *perf_config_set)
>  {
>  int ret = -1;
>  char *ptr, *key;
>  char *section_name, *name;
>  struct perf_config_section *section = NULL;
>  struct perf_config_item *config_item = NULL;
>-struct list_head *sections = section_list;
>+struct perf_config_set *perf_configs = perf_config_set;
>+struct list_head *sections = _configs->sections;
>
>  key = ptr = strdup(var);
>  if (!key) {
>@@ -743,7 +745,8 @@ static int collect_config(const char *var, const 
>char *value,
>
>  out_free:
>  free(key);
>-return ret;
>+perf_config_set__delete(perf_configs);
>+return -1;
>  }
>
>  static struct perf_config_set *perf_config_set__init(struct 
>perf_config_set *perf_configs)
>@@ -777,7 +780,7 @@ struct perf_config_set *perf_config_set__new(void)
>  return NULL;
>
>  perf_config_set__init(perf_configs);
>-perf_config(collect_config, _configs->sections);
>+perf_config(collect_config, perf_configs);
>
>  return perf_configs;
>  }
>
>
>Thanks,
>Taeung
>
>
>>> ---
>>>   tools/perf/util/config.c | 171
>+++
>>>   tools/perf/util/config.h |  26 +++
>>>   2 files changed, 197 insertions(+)
>>>   create mode 100644 tools/perf/util/config.h
>>>
>>> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>>> index 4e72763..2dbf47c 100644
>>> --- a/tools/perf/util/config.c
>>> +++ b/tools/perf/util/config.c
>>> @@ -13,6 +13,7 @@
>>>   #include 
>>>   #include "util/hist.h"  /* perf_hist_config */
>>>   #include "util/llvm-utils.h"   /* perf_llvm_config */
>>> +#include "config.h"
>>>
>>>   #define MAXNAME (256)
>>>
>>> @@ -506,6 +507,176 @@ out:
>>> return ret;
>>>   }
>>>
>>> +static struct perf_config_section *find_section(struct list_head
>*sections,
>>> +   const char *section_name)
>>> +{
>>> +   struct perf_config_section *section;
>>> +
>>> +   list_for_each_entry(section, sections, list)
>>> +   if (!strcmp(section->name, section_name))
>>> +   return section;
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +static struct perf_config_item *find_config_item(const char *name,
>>> +struct perf_config_section 
>>> *section)
>>> +{
>>> +   struct perf_config_item *config_item;
>>> +
>>> +   list_for_each_entry(config_item, >config_items, list)
>>> +   if (!strcmp(config_item->name, name))
>>> +   return config_item;
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +static void find_config(struct list_head *sections,
>>> +   struct perf_config_section **section,
>>> +   struct perf_config_item **config_item,
>>> +   const char *section_name, const char *name)
>>> +{
>>> +   *section = find_section(sections, section_name);
>>> +
>>> +   if (*section != NULL)
>>> +   *config_item = find_config_item(name, *section);
>>> +   else
>>> +   *config_item = NULL;
>>> +}
>>> +
>>> +static struct perf_config_section *add_section(struct list_head
>*sections,
>>> +  const char *section_name)
>>> +{
>>> +   struct perf_config_section *section = zalloc(sizeof(*section));
>>> +
>>> +   if (!section)
>>> +   return NULL;
>>> +
>>> +   INIT_LIST_HEAD(>config_items);
>>> +   section->name = strdup(section_name);
>>> +   if (!section->name) {
>>> +   pr_err("%s: strdup failed\n", __func__);
>>> +   free(section);
>>> +   return NULL;
>>> +   }
>>> +
>>> +   list_add_tail(>list, sections);
>>> +   return section;
>>> +}
>>> +
>>> +static struct perf_config_item 

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Peter Chen]

On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote:
> On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
> 
> > > > I am afraid I still not find the user (udc driver) for this framework, 
> > > > I would
> > > > like to see how udc driver block the enumeration until the charger 
> > > > detection
> > > > has finished, or am I missing something?
> 
> > > It is not for udc driver but for power users who want to negotiate
> > > with USB subsystem.
> 
> > Then, where is the code the test user to decide what kinds of USB charger
> > (SDP, CDP, DCP) is connecting now?
> 
> Even without detection of CDP and DCP we have configurability within SDP
> - there's the 2.5mA suspended limit, the 100mA default limit and the
> higher 500mA limit which can be negotiated.

Well, things may be a little complicated.

- First, how to design get_charger_type for each udc driver?
Since the charger detection process affects dp/dm signal, it can't be done
during the enumeration or after that. So, the detection process can be only
done after vbus has detected and before udc pull up dp.

Then, when the get_charger_type do real charger detection? My suggestion is,
if the charger type is unknown, we do real one, else, we just return the
stored type value.

- Second, When to notify charger IC to charger:
For SDP and CDP, it needs to notify charger IC after set configuration
has finished.
For DCP (and ACA, I am not sure), can notify charger IC after charger
detection has finished or later.

So, when we get charger is present, we need to notify charger IC at once
for DCP (and ACA); But for SDP and CDP, we need to let the gadget
composite core to notify charger IC after set configuration has finished,
like the patch 2/4 does.

- Third, since composite driver covers 500mA (and more for CDP) after set
configuration and 2mA after suspend, and vbus handler covers connect
and disconnect. I can't see any reasons we need to notify gadget state
for power driver, do we really need to have usb_charger_plug_by_gadget?

-- 
Best Regards,
eter Chen

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Peter Chen]

On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote:
> On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
> 
> > > > I am afraid I still not find the user (udc driver) for this framework, 
> > > > I would
> > > > like to see how udc driver block the enumeration until the charger 
> > > > detection
> > > > has finished, or am I missing something?
> 
> > > It is not for udc driver but for power users who want to negotiate
> > > with USB subsystem.
> 
> > Then, where is the code the test user to decide what kinds of USB charger
> > (SDP, CDP, DCP) is connecting now?
> 
> Even without detection of CDP and DCP we have configurability within SDP
> - there's the 2.5mA suspended limit, the 100mA default limit and the
> higher 500mA limit which can be negotiated.

Well, things may be a little complicated.

- First, how to design get_charger_type for each udc driver?
Since the charger detection process affects dp/dm signal, it can't be done
during the enumeration or after that. So, the detection process can be only
done after vbus has detected and before udc pull up dp.

Then, when the get_charger_type do real charger detection? My suggestion is,
if the charger type is unknown, we do real one, else, we just return the
stored type value.

- Second, When to notify charger IC to charger:
For SDP and CDP, it needs to notify charger IC after set configuration
has finished.
For DCP (and ACA, I am not sure), can notify charger IC after charger
detection has finished or later.

So, when we get charger is present, we need to notify charger IC at once
for DCP (and ACA); But for SDP and CDP, we need to let the gadget
composite core to notify charger IC after set configuration has finished,
like the patch 2/4 does.

- Third, since composite driver covers 500mA (and more for CDP) after set
configuration and 2mA after suspend, and vbus handler covers connect
and disconnect. I can't see any reasons we need to notify gadget state
for power driver, do we really need to have usb_charger_plug_by_gadget?

-- 
Best Regards,
eter Chen

[PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

[DusonLin]

Only ABS_DISTANCE is not enough for upper OS  to distiguish hover event
be triggered from object form faraway to and close touchpad surface or from
object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help
it.

 Object_at_faraway   object_at_hover_area  object_touch_touchpad
  BTN_TOUCH 0  01
BTN_TOOL_FINGER 0  11
   ABS_DISTANCE 0  10

Signed-off by: Duson Lin 
---
drivers/input/mouse/elan_i2c_core.c |   14 +-
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 2f58985..9392a8c 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -4,7 +4,7 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.6.0
+ * Version: 1.6.1
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
@@ -845,23 +845,27 @@ static void elan_report_absolute(struct elan_tp_data 
*data, u8 *packet)
{
  struct input_dev *input = data->input;
  u8 *finger_data = [ETP_FINGER_DATA_OFFSET];
-   int i;
+  int i, valid_count = 0;
  u8 tp_info = packet[ETP_TOUCH_INFO_OFFSET];
  u8 hover_info = packet[ETP_HOVER_INFO_OFFSET];
  bool contact_valid, hover_event;

-   hover_event = hover_info & 0x40;
+  hover_event = (hover_info & 0x40);
  for (i = 0; i < ETP_MAX_FINGERS; i++) {
  contact_valid = tp_info & (1U << (3 + i));
  elan_report_contact(data, i, contact_valid, finger_data);

-   if (contact_valid)
+  if (contact_valid) {
  finger_data += ETP_FINGER_DATA_LEN;
+  valid_count++;
+  }
  }

   input_report_key(input, BTN_LEFT, tp_info & 0x01);
+  input_report_key(input, BTN_TOOL_FINGER,
+  ((hover_event != 0) | (valid_count > 0)));
  input_report_abs(input, ABS_DISTANCE, hover_event != 0);
-   input_mt_report_pointer_emulation(input, true);
+  input_mt_report_pointer_emulation(input, false);
  input_sync(input);
}

-- 
1.7.9.5

[PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

[DusonLin]

Only ABS_DISTANCE is not enough for upper OS  to distiguish hover event
be triggered from object form faraway to and close touchpad surface or from
object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help
it.

 Object_at_faraway   object_at_hover_area  object_touch_touchpad
  BTN_TOUCH 0  01
BTN_TOOL_FINGER 0  11
   ABS_DISTANCE 0  10

Signed-off by: Duson Lin 
---
drivers/input/mouse/elan_i2c_core.c |   14 +-
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 2f58985..9392a8c 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -4,7 +4,7 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.6.0
+ * Version: 1.6.1
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
@@ -845,23 +845,27 @@ static void elan_report_absolute(struct elan_tp_data 
*data, u8 *packet)
{
  struct input_dev *input = data->input;
  u8 *finger_data = [ETP_FINGER_DATA_OFFSET];
-   int i;
+  int i, valid_count = 0;
  u8 tp_info = packet[ETP_TOUCH_INFO_OFFSET];
  u8 hover_info = packet[ETP_HOVER_INFO_OFFSET];
  bool contact_valid, hover_event;

-   hover_event = hover_info & 0x40;
+  hover_event = (hover_info & 0x40);
  for (i = 0; i < ETP_MAX_FINGERS; i++) {
  contact_valid = tp_info & (1U << (3 + i));
  elan_report_contact(data, i, contact_valid, finger_data);

-   if (contact_valid)
+  if (contact_valid) {
  finger_data += ETP_FINGER_DATA_LEN;
+  valid_count++;
+  }
  }

   input_report_key(input, BTN_LEFT, tp_info & 0x01);
+  input_report_key(input, BTN_TOOL_FINGER,
+  ((hover_event != 0) | (valid_count > 0)));
  input_report_abs(input, ABS_DISTANCE, hover_event != 0);
-   input_mt_report_pointer_emulation(input, true);
+  input_mt_report_pointer_emulation(input, false);
  input_sync(input);
}

-- 
1.7.9.5

[PATCH v2 0/5] dax: handling of media errors

[Vishal Verma]

Until now, dax has been disabled if media errors were found on
any device. This series attempts to address that.

The first three patches from Dan re-enable dax even when media
errors are present.

The fourth patch from Matthew removes the
zeroout path from dax entirely, making zeroout operations always
go through the driver (The motivation is that if a backing device
has media errors, and we create a sparse file on it, we don't
want the initial zeroing to happen via dax, we want to give the
block driver a chance to clear the errors).

One pending item is addressing clear_pmem usages in dax.c. clear_pmem is
'unsafe' as it attempts to simply memcpy, and does not go through the driver.
We have a few options of solving this:
 1. Remove all usages of clear_pmem that are not sector-aligned. For the
ones that are aligned, replace them with a bio submission that goes
through the driver to clear errors.
 2. Export from the block layer, either an API to zero sub-sector ranges,
or in general, clear errors in a range. The dax attempts to clear_pmem
can then use either of these and not be hit be media errors.

I'll send out a v3 with a crack at option 1, but I wanted to get these
changes (especially the ones in xfs) out for review.

The fifth patch changes all the callers of dax_do_io to check for
EIO, and fallback to direct_IO as needed. This forces the IO to
go through the block driver, and can attempt to clear the error.


v2:
 - Use blockdev_issue_zeroout in xfs instead of sb_issue_zeroout (Christoph)
 - Un-wrapper-ize dax_do_io and leave the fallback to direct_IO to callers
   (Christoph)
 - Rebase to v4.6-rc1 (fixup a couple of conflicts in ext4 and xfs)


Dan Williams (3):
  block, dax: pass blk_dax_ctl through to drivers
  dax: fallback from pmd to pte on error
  dax: enable dax in the presence of known media errors (badblocks)

Vishal Verma (2):
  dax: use sb_issue_zerout instead of calling dax_clear_sectors
  dax: handle media errors in dax_do_io

 arch/powerpc/sysdev/axonram.c | 10 +-
 block/ioctl.c |  9 -
 drivers/block/brd.c   |  9 +
 drivers/nvdimm/pmem.c | 17 +
 drivers/s390/block/dcssblk.c  | 12 ++--
 fs/block_dev.c| 19 +++
 fs/dax.c  | 36 ++--
 fs/ext2/inode.c   | 29 ++---
 fs/ext4/indirect.c| 18 +-
 fs/ext4/inode.c   | 21 ++---
 fs/xfs/xfs_aops.c | 14 --
 fs/xfs/xfs_bmap_util.c| 15 ---
 include/linux/blkdev.h|  3 +--
 include/linux/dax.h   |  1 -
 14 files changed, 108 insertions(+), 105 deletions(-)

-- 
2.5.5

[PATCH v2 3/5] dax: enable dax in the presence of known media errors (badblocks)

[Vishal Verma]

From: Dan Williams 

1/ If a mapping overlaps a bad sector fail the request.

2/ Do not opportunistically report more dax-capable capacity than is
   requested when errors present.

[vishal: fix a conflict with system RAM collision patches]
Signed-off-by: Dan Williams 
---
 block/ioctl.c | 9 -
 drivers/nvdimm/pmem.c | 8 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index d8996bb..cd7f392 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -423,15 +423,6 @@ bool blkdev_dax_capable(struct block_device *bdev)
|| (bdev->bd_part->nr_sects % (PAGE_SIZE / 512)))
return false;
 
-   /*
-* If the device has known bad blocks, force all I/O through the
-* driver / page cache.
-*
-* TODO: support finer grained dax error handling
-*/
-   if (disk->bb && disk->bb->count)
-   return false;
-
return true;
 }
 #endif
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index da10554..eac5f93 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -174,9 +174,17 @@ static long pmem_direct_access(struct block_device *bdev,
struct pmem_device *pmem = bdev->bd_disk->private_data;
resource_size_t offset = sector * 512 + pmem->data_offset;
 
+   if (unlikely(is_bad_pmem(>bb, sector, dax->size)))
+   return -EIO;
dax->addr = pmem->virt_addr + offset;
dax->pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
 
+   /*
+* If badblocks are present, limit known good range to the
+* requested range.
+*/
+   if (unlikely(pmem->bb.count))
+   return dax->size;
return pmem->size - pmem->pfn_pad - offset;
 }
 
-- 
2.5.5

[PATCH v2 0/5] dax: handling of media errors

[Vishal Verma]

Until now, dax has been disabled if media errors were found on
any device. This series attempts to address that.

The first three patches from Dan re-enable dax even when media
errors are present.

The fourth patch from Matthew removes the
zeroout path from dax entirely, making zeroout operations always
go through the driver (The motivation is that if a backing device
has media errors, and we create a sparse file on it, we don't
want the initial zeroing to happen via dax, we want to give the
block driver a chance to clear the errors).

One pending item is addressing clear_pmem usages in dax.c. clear_pmem is
'unsafe' as it attempts to simply memcpy, and does not go through the driver.
We have a few options of solving this:
 1. Remove all usages of clear_pmem that are not sector-aligned. For the
ones that are aligned, replace them with a bio submission that goes
through the driver to clear errors.
 2. Export from the block layer, either an API to zero sub-sector ranges,
or in general, clear errors in a range. The dax attempts to clear_pmem
can then use either of these and not be hit be media errors.

I'll send out a v3 with a crack at option 1, but I wanted to get these
changes (especially the ones in xfs) out for review.

The fifth patch changes all the callers of dax_do_io to check for
EIO, and fallback to direct_IO as needed. This forces the IO to
go through the block driver, and can attempt to clear the error.


v2:
 - Use blockdev_issue_zeroout in xfs instead of sb_issue_zeroout (Christoph)
 - Un-wrapper-ize dax_do_io and leave the fallback to direct_IO to callers
   (Christoph)
 - Rebase to v4.6-rc1 (fixup a couple of conflicts in ext4 and xfs)


Dan Williams (3):
  block, dax: pass blk_dax_ctl through to drivers
  dax: fallback from pmd to pte on error
  dax: enable dax in the presence of known media errors (badblocks)

Vishal Verma (2):
  dax: use sb_issue_zerout instead of calling dax_clear_sectors
  dax: handle media errors in dax_do_io

 arch/powerpc/sysdev/axonram.c | 10 +-
 block/ioctl.c |  9 -
 drivers/block/brd.c   |  9 +
 drivers/nvdimm/pmem.c | 17 +
 drivers/s390/block/dcssblk.c  | 12 ++--
 fs/block_dev.c| 19 +++
 fs/dax.c  | 36 ++--
 fs/ext2/inode.c   | 29 ++---
 fs/ext4/indirect.c| 18 +-
 fs/ext4/inode.c   | 21 ++---
 fs/xfs/xfs_aops.c | 14 --
 fs/xfs/xfs_bmap_util.c| 15 ---
 include/linux/blkdev.h|  3 +--
 include/linux/dax.h   |  1 -
 14 files changed, 108 insertions(+), 105 deletions(-)

-- 
2.5.5

[PATCH v2 3/5] dax: enable dax in the presence of known media errors (badblocks)

[Vishal Verma]

From: Dan Williams 

1/ If a mapping overlaps a bad sector fail the request.

2/ Do not opportunistically report more dax-capable capacity than is
   requested when errors present.

[vishal: fix a conflict with system RAM collision patches]
Signed-off-by: Dan Williams 
---
 block/ioctl.c | 9 -
 drivers/nvdimm/pmem.c | 8 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index d8996bb..cd7f392 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -423,15 +423,6 @@ bool blkdev_dax_capable(struct block_device *bdev)
|| (bdev->bd_part->nr_sects % (PAGE_SIZE / 512)))
return false;
 
-   /*
-* If the device has known bad blocks, force all I/O through the
-* driver / page cache.
-*
-* TODO: support finer grained dax error handling
-*/
-   if (disk->bb && disk->bb->count)
-   return false;
-
return true;
 }
 #endif
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index da10554..eac5f93 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -174,9 +174,17 @@ static long pmem_direct_access(struct block_device *bdev,
struct pmem_device *pmem = bdev->bd_disk->private_data;
resource_size_t offset = sector * 512 + pmem->data_offset;
 
+   if (unlikely(is_bad_pmem(>bb, sector, dax->size)))
+   return -EIO;
dax->addr = pmem->virt_addr + offset;
dax->pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
 
+   /*
+* If badblocks are present, limit known good range to the
+* requested range.
+*/
+   if (unlikely(pmem->bb.count))
+   return dax->size;
return pmem->size - pmem->pfn_pad - offset;
 }
 
-- 
2.5.5