[lkp] [sched/fair] f54c5d4e28: hackbench.throughput 10.6% improvement

[kernel test robot]

FYI, we noticed a 10.6% improvement of hackbench.throughput due to commit:

commit f54c5d4e28da93ffb92c40f84f6f6e6db41d652e ("sched/fair: Do not decay new 
task load on first enqueue")
https://github.com/0day-ci/linux 
Matt-Fleming/sched-fair-Do-not-decay-new-task-load-on-first-enqueue/20160924-014929

in testcase: hackbench
on test machine: 32 threads Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz with 32G 
memory
with following parameters:

cpuset.mems: 0-$((nr_node-1))
cpuset.cpus: 0-$((nr_cpu-1))
nr_threads: 1600%
mode: threads
ipc: pipe
cpufreq_governor: performance

Hackbench is both a benchmark and a stress test for the Linux kernel scheduler.


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.

Details are as below:
-->


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml  # job file is attached in this email
bin/lkp run job.yaml

=
compiler/cpufreq_governor/cpuset.cpus/cpuset.mems/ipc/kconfig/mode/nr_threads/rootfs/tbox_group/testcase:
  
gcc-6/performance/0-$((nr_cpu-1))/0-$((nr_node-1))/pipe/x86_64-kexec/threads/1600%/debian-x86_64-2016-08-31.cgz/lkp-snb01/hackbench

commit: 
  c1fad9ef7e ("objtool: Add do_task_dead() to global noreturn list")
  f54c5d4e28 ("sched/fair: Do not decay new task load on first enqueue")

c1fad9ef7ed14aad f54c5d4e28da93ffb92c40f84f 
 -- 
 %stddev %change %stddev
 \  |\  
248098 ±  1% +10.6% 274415 ±  0%  hackbench.throughput
 8.706e+08 ±  1% +21.7%   1.06e+09 ±  0%  
hackbench.time.involuntary_context_switches
   1674142 ±  1% +10.2%1844981 ±  0%  hackbench.time.minor_page_faults
  1547 ±  1%  +9.7%   1696 ±  0%  hackbench.time.user_time
 2.287e+09 ±  2% -11.8%  2.017e+09 ±  0%  
hackbench.time.voluntary_context_switches
   5198633 ±  9% -24.8%3908585 ± 17%  
interrupts.CAL:Function_call_interrupts
217794 ±  2% -14.7% 185716 ±  1%  meminfo.KernelStack
105989 ±  8% -20.7%  84099 ± 14%  numa-meminfo.node1.KernelStack
   1237200 ±  0% -15.9%1040658 ±  2%  softirqs.RCU
540161 ±  4% -53.0% 254100 ±  0%  softirqs.SCHED
  1569 ±  2% +11.6%   1751 ±  2%  vmstat.procs.r
290364 ±  7% -67.9%  93107 ±  1%  vmstat.system.in
  1.34 ±  2% +88.1%   2.52 ±  0%  turbostat.CPU%c1
  2.61 ±  4% -34.3%   1.71 ±  1%  turbostat.CPU%c6
  0.19 ± 14% +61.3%   0.30 ± 19%  turbostat.Pkg%pc6
  35103736 ±  5% -65.8%   11992857 ±  1%  cpuidle.C1.usage
197809 ±  3%+189.3% 572238 ±  0%  cpuidle.C2.usage
  57732567 ± 10% -92.4%4375330 ± 24%  cpuidle.POLL.time
185806 ±  5% -66.1%  63025 ±  1%  cpuidle.POLL.usage
  17524006 ±  2% +11.3%   19495992 ±  2%  numa-numastat.node0.local_node
  17524039 ±  2% +11.3%   19496020 ±  2%  numa-numastat.node0.numa_hit
  15305415 ±  6% +25.0%   19128452 ±  2%  numa-numastat.node1.local_node
  15305434 ±  6% +25.0%   19128469 ±  2%  numa-numastat.node1.numa_hit
   8687240 ±  9% +15.3%   10019684 ±  3%  numa-vmstat.node0.numa_hit
   8687217 ±  9% +15.3%   10019664 ±  3%  numa-vmstat.node0.numa_local
   8239375 ±  3% +19.6%9854917 ±  2%  numa-vmstat.node1.numa_hit
   8239361 ±  3% +19.6%9854904 ±  2%  numa-vmstat.node1.numa_local
217952 ±  1% -14.9% 185402 ±  0%  proc-vmstat.nr_kernel_stack
  32832102 ±  2% +17.6%   38626359 ±  0%  proc-vmstat.numa_hit
  32832049 ±  2% +17.6%   38626314 ±  0%  proc-vmstat.numa_local
  36089336 ±  2% +16.9%   42180382 ±  0%  proc-vmstat.pgalloc_normal
   2547440 ±  1% -11.6%2252216 ±  0%  proc-vmstat.pgfault
  36004406 ±  2% +16.9%   42080130 ±  0%  proc-vmstat.pgfree
741.00 ± 11% -28.9% 526.50 ± 11%  slabinfo.bdev_cache.active_objs
741.00 ± 11% -28.9% 526.50 ± 11%  slabinfo.bdev_cache.num_objs
858.00 ± 10% -28.5% 613.25 ± 10%  
slabinfo.file_lock_cache.active_objs
858.00 ± 10% -28.5% 613.25 ± 10%  slabinfo.file_lock_cache.num_objs
 23908 ±  2%  -8.5%  21874 ±  4%  slabinfo.kmalloc-192.active_objs
 24087 ±  2%  -8.5%  22049 ±  4%  slabinfo.kmalloc-192.num_objs
 33276 ±  3% -11.0%  29622 ±  3%  slabinfo.kmalloc-256.active_objs
 33566 ±  3% -10.8%  29930 ±  3%  slabinfo.kmalloc-256.num_objs
 14696 ±  2% -14.8%  12527 ±  1%  slabinfo.task_struct.active_objs
  1724 ±  2% 

[lkp] [sched/fair] f54c5d4e28: hackbench.throughput 10.6% improvement

[kernel test robot]

FYI, we noticed a 10.6% improvement of hackbench.throughput due to commit:

commit f54c5d4e28da93ffb92c40f84f6f6e6db41d652e ("sched/fair: Do not decay new 
task load on first enqueue")
https://github.com/0day-ci/linux 
Matt-Fleming/sched-fair-Do-not-decay-new-task-load-on-first-enqueue/20160924-014929

in testcase: hackbench
on test machine: 32 threads Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz with 32G 
memory
with following parameters:

cpuset.mems: 0-$((nr_node-1))
cpuset.cpus: 0-$((nr_cpu-1))
nr_threads: 1600%
mode: threads
ipc: pipe
cpufreq_governor: performance

Hackbench is both a benchmark and a stress test for the Linux kernel scheduler.


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.

Details are as below:
-->


To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml  # job file is attached in this email
bin/lkp run job.yaml

=
compiler/cpufreq_governor/cpuset.cpus/cpuset.mems/ipc/kconfig/mode/nr_threads/rootfs/tbox_group/testcase:
  
gcc-6/performance/0-$((nr_cpu-1))/0-$((nr_node-1))/pipe/x86_64-kexec/threads/1600%/debian-x86_64-2016-08-31.cgz/lkp-snb01/hackbench

commit: 
  c1fad9ef7e ("objtool: Add do_task_dead() to global noreturn list")
  f54c5d4e28 ("sched/fair: Do not decay new task load on first enqueue")

c1fad9ef7ed14aad f54c5d4e28da93ffb92c40f84f 
 -- 
 %stddev %change %stddev
 \  |\  
248098 ±  1% +10.6% 274415 ±  0%  hackbench.throughput
 8.706e+08 ±  1% +21.7%   1.06e+09 ±  0%  
hackbench.time.involuntary_context_switches
   1674142 ±  1% +10.2%1844981 ±  0%  hackbench.time.minor_page_faults
  1547 ±  1%  +9.7%   1696 ±  0%  hackbench.time.user_time
 2.287e+09 ±  2% -11.8%  2.017e+09 ±  0%  
hackbench.time.voluntary_context_switches
   5198633 ±  9% -24.8%3908585 ± 17%  
interrupts.CAL:Function_call_interrupts
217794 ±  2% -14.7% 185716 ±  1%  meminfo.KernelStack
105989 ±  8% -20.7%  84099 ± 14%  numa-meminfo.node1.KernelStack
   1237200 ±  0% -15.9%1040658 ±  2%  softirqs.RCU
540161 ±  4% -53.0% 254100 ±  0%  softirqs.SCHED
  1569 ±  2% +11.6%   1751 ±  2%  vmstat.procs.r
290364 ±  7% -67.9%  93107 ±  1%  vmstat.system.in
  1.34 ±  2% +88.1%   2.52 ±  0%  turbostat.CPU%c1
  2.61 ±  4% -34.3%   1.71 ±  1%  turbostat.CPU%c6
  0.19 ± 14% +61.3%   0.30 ± 19%  turbostat.Pkg%pc6
  35103736 ±  5% -65.8%   11992857 ±  1%  cpuidle.C1.usage
197809 ±  3%+189.3% 572238 ±  0%  cpuidle.C2.usage
  57732567 ± 10% -92.4%4375330 ± 24%  cpuidle.POLL.time
185806 ±  5% -66.1%  63025 ±  1%  cpuidle.POLL.usage
  17524006 ±  2% +11.3%   19495992 ±  2%  numa-numastat.node0.local_node
  17524039 ±  2% +11.3%   19496020 ±  2%  numa-numastat.node0.numa_hit
  15305415 ±  6% +25.0%   19128452 ±  2%  numa-numastat.node1.local_node
  15305434 ±  6% +25.0%   19128469 ±  2%  numa-numastat.node1.numa_hit
   8687240 ±  9% +15.3%   10019684 ±  3%  numa-vmstat.node0.numa_hit
   8687217 ±  9% +15.3%   10019664 ±  3%  numa-vmstat.node0.numa_local
   8239375 ±  3% +19.6%9854917 ±  2%  numa-vmstat.node1.numa_hit
   8239361 ±  3% +19.6%9854904 ±  2%  numa-vmstat.node1.numa_local
217952 ±  1% -14.9% 185402 ±  0%  proc-vmstat.nr_kernel_stack
  32832102 ±  2% +17.6%   38626359 ±  0%  proc-vmstat.numa_hit
  32832049 ±  2% +17.6%   38626314 ±  0%  proc-vmstat.numa_local
  36089336 ±  2% +16.9%   42180382 ±  0%  proc-vmstat.pgalloc_normal
   2547440 ±  1% -11.6%2252216 ±  0%  proc-vmstat.pgfault
  36004406 ±  2% +16.9%   42080130 ±  0%  proc-vmstat.pgfree
741.00 ± 11% -28.9% 526.50 ± 11%  slabinfo.bdev_cache.active_objs
741.00 ± 11% -28.9% 526.50 ± 11%  slabinfo.bdev_cache.num_objs
858.00 ± 10% -28.5% 613.25 ± 10%  
slabinfo.file_lock_cache.active_objs
858.00 ± 10% -28.5% 613.25 ± 10%  slabinfo.file_lock_cache.num_objs
 23908 ±  2%  -8.5%  21874 ±  4%  slabinfo.kmalloc-192.active_objs
 24087 ±  2%  -8.5%  22049 ±  4%  slabinfo.kmalloc-192.num_objs
 33276 ±  3% -11.0%  29622 ±  3%  slabinfo.kmalloc-256.active_objs
 33566 ±  3% -10.8%  29930 ±  3%  slabinfo.kmalloc-256.num_objs
 14696 ±  2% -14.8%  12527 ±  1%  slabinfo.task_struct.active_objs
  1724 ±  2% 

[lkp] [inotify] 1109954e99: BUG kmalloc-512 (Not tainted): Freepointer corrupt

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Nikolay-Borisov/inotify-Convert-to-using-per-namespace-limits/20161007-184900
commit 1109954e99c57a13814a9c1ebb3f01c53b48091f ("inotify: Convert to using 
per-namespace limits")

in testcase: trinity
with following parameters:

runtime: 300s


Trinity is a linux system call fuzz tester.


on test machine: qemu-system-x86_64 -enable-kvm -cpu IvyBridge -m 360M

caused below changes:


++++
|| 
3477d168ba | 1109954e99 |
++++
| boot_successes | 
19 | 5  |
| boot_failures  | 
11 | 29 |
| invoked_oom-killer:gfp_mask=0x | 
8  | 3  |
| Mem-Info   | 
8  | 3  |
| BUG:kernel_reboot-without-warning_in_test_stage| 
1  | 3  |
| Kernel_panic-not_syncing:VFS:Unable_to_mount_root_fs_on_unknown-block(#,#) | 
2  | 2  |
| calltrace:prepare_namespace| 
2  | 2  |
| BUG_kmalloc-#(Not_tainted):Freepointer_corrupt | 
0  | 18 |
| INFO:Allocated_in_setup_userns_sysctls_age=#cpu=#pid=  | 
0  | 18 |
| INFO:Freed_in_qlist_free_all_age=#cpu=#pid=| 
0  | 15 |
| INFO:Slab#objects=#used=#fp=#flags=| 
0  | 14 |
| INFO:Object#@offset=#fp=   | 
0  | 18 |
| calltrace:SyS_lgetxattr| 
0  | 1  |
| RIP:__kmalloc  | 
0  | 1  |
| calltrace:virtio_pci_driver_init   | 
0  | 4  |
| Kernel_panic-not_syncing:softlockup:hung_tasks | 
0  | 4  |
| calltrace:SyS_clone| 
0  | 11 |
| calltrace:SyS_listxattr| 
0  | 1  |
| BUG_kmalloc-#(Tainted:G_B):Freepointer_corrupt | 
0  | 2  |
| INFO:Slab#objects=#used=#fp=0x(null)flags= | 
0  | 4  |
| RIP:memcmp | 
0  | 1  |
| RIP:unwind_get_return_address  | 
0  | 1  |
| RIP:_raw_spin_unlock_irqrestore| 
0  | 1  |
| calltrace:SyS_add_key  | 
0  | 1  |
| calltrace:SyS_fchownat | 
0  | 1  |
| calltrace:SyS_chown| 
0  | 1  |
| calltrace:SyS_chown16  | 
0  | 1  |
| calltrace:SyS_setfsgid | 
0  | 1  |
| calltrace:SyS_setfsgid16   | 
0  | 1  |
| calltrace:SyS_fgetxattr| 
0  | 1  |
| calltrace:SyS_setgid   | 
0  | 1  |
++++



[   35.734332] VFS: Warning: trinity-c0 using old stat() call. Recompile your 
binary.
[   35.757516] VFS: Warning: trinity-c2 using old stat() call. Recompile your 
binary.
[   39.409080] 
=
[   39.46] BUG kmalloc-512 (Not tainted): Freepointer corrupt
[   39.414680] 
-
[   39.414680] 
[   39.417417] Disabling lock debugging due to kernel taint
[   39.418853] INFO: Allocated in setup_userns_sysctls+0x43/0xac age=25 cpu=0 
pid=1716
[   39.431035] INFO: Freed in qlist_free_all+0x7e/0xca age=36 cpu=0 pid=1719
[   39.448221] INFO: Slab 0xea2e0a00 objects=9 used=7 
fp=0x88000b829b08 flags=0x40004081
[   39.450623] INFO: Object 

[lkp] [inotify] 1109954e99: BUG kmalloc-512 (Not tainted): Freepointer corrupt

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Nikolay-Borisov/inotify-Convert-to-using-per-namespace-limits/20161007-184900
commit 1109954e99c57a13814a9c1ebb3f01c53b48091f ("inotify: Convert to using 
per-namespace limits")

in testcase: trinity
with following parameters:

runtime: 300s


Trinity is a linux system call fuzz tester.


on test machine: qemu-system-x86_64 -enable-kvm -cpu IvyBridge -m 360M

caused below changes:


++++
|| 
3477d168ba | 1109954e99 |
++++
| boot_successes | 
19 | 5  |
| boot_failures  | 
11 | 29 |
| invoked_oom-killer:gfp_mask=0x | 
8  | 3  |
| Mem-Info   | 
8  | 3  |
| BUG:kernel_reboot-without-warning_in_test_stage| 
1  | 3  |
| Kernel_panic-not_syncing:VFS:Unable_to_mount_root_fs_on_unknown-block(#,#) | 
2  | 2  |
| calltrace:prepare_namespace| 
2  | 2  |
| BUG_kmalloc-#(Not_tainted):Freepointer_corrupt | 
0  | 18 |
| INFO:Allocated_in_setup_userns_sysctls_age=#cpu=#pid=  | 
0  | 18 |
| INFO:Freed_in_qlist_free_all_age=#cpu=#pid=| 
0  | 15 |
| INFO:Slab#objects=#used=#fp=#flags=| 
0  | 14 |
| INFO:Object#@offset=#fp=   | 
0  | 18 |
| calltrace:SyS_lgetxattr| 
0  | 1  |
| RIP:__kmalloc  | 
0  | 1  |
| calltrace:virtio_pci_driver_init   | 
0  | 4  |
| Kernel_panic-not_syncing:softlockup:hung_tasks | 
0  | 4  |
| calltrace:SyS_clone| 
0  | 11 |
| calltrace:SyS_listxattr| 
0  | 1  |
| BUG_kmalloc-#(Tainted:G_B):Freepointer_corrupt | 
0  | 2  |
| INFO:Slab#objects=#used=#fp=0x(null)flags= | 
0  | 4  |
| RIP:memcmp | 
0  | 1  |
| RIP:unwind_get_return_address  | 
0  | 1  |
| RIP:_raw_spin_unlock_irqrestore| 
0  | 1  |
| calltrace:SyS_add_key  | 
0  | 1  |
| calltrace:SyS_fchownat | 
0  | 1  |
| calltrace:SyS_chown| 
0  | 1  |
| calltrace:SyS_chown16  | 
0  | 1  |
| calltrace:SyS_setfsgid | 
0  | 1  |
| calltrace:SyS_setfsgid16   | 
0  | 1  |
| calltrace:SyS_fgetxattr| 
0  | 1  |
| calltrace:SyS_setgid   | 
0  | 1  |
++++



[   35.734332] VFS: Warning: trinity-c0 using old stat() call. Recompile your 
binary.
[   35.757516] VFS: Warning: trinity-c2 using old stat() call. Recompile your 
binary.
[   39.409080] 
=
[   39.46] BUG kmalloc-512 (Not tainted): Freepointer corrupt
[   39.414680] 
-
[   39.414680] 
[   39.417417] Disabling lock debugging due to kernel taint
[   39.418853] INFO: Allocated in setup_userns_sysctls+0x43/0xac age=25 cpu=0 
pid=1716
[   39.431035] INFO: Freed in qlist_free_all+0x7e/0xca age=36 cpu=0 pid=1719
[   39.448221] INFO: Slab 0xea2e0a00 objects=9 used=7 
fp=0x88000b829b08 flags=0x40004081
[   39.450623] INFO: Object 

[PATCH 3/3] staging: ks7010: Replace header files

[Sabitha George]

This patch replaces inclusion of asm/atomic.h with linux/atomic.h and
asm/io.h with linux/io.h to fix checkpatch warning in ks_wlan.h

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_wlan.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index c2cc288..5851714 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -25,13 +25,13 @@
 #include/* struct net_device_stats,  struct sk_buff 
*/
 #include 
 #include 
-#include /* struct atmic_t   
*/
+#include   /* struct atomic_t */
 #include/* struct timer_list */
 #include 
 #include   /* struct completion */
 #include 
 
-#include 
+#include 
 
 #include "ks7010_sdio.h"
 
-- 
1.9.1

[PATCH 2/3] staging: ks7010: use netdev_* instead of printk()

[Sabitha George]

Fixes checkpatch warning on printk usage in ks_hostif.c

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_hostif.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index b4d422b..3cee668 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -476,8 +476,7 @@ void hostif_data_indication(struct ks_wlan_private *priv)
skb->dev->last_rx = jiffies;
netif_rx(skb);
} else {
-   printk(KERN_WARNING
-  "ks_wlan: Memory squeeze, dropping packet.\n");
+   netdev_warn(priv->net_dev, "ks_wlan: Memory squeeze, 
dropping packet.\n");
priv->nstats.rx_dropped++;
}
break;
@@ -511,8 +510,7 @@ void hostif_data_indication(struct ks_wlan_private *priv)
skb->dev->last_rx = jiffies;
netif_rx(skb);
} else {
-   printk(KERN_WARNING
-  "ks_wlan: Memory squeeze, dropping packet.\n");
+   netdev_warn(priv->net_dev, "ks_wlan: Memory squeeze, 
dropping packet.\n");
priv->nstats.rx_dropped++;
}
break;
@@ -560,10 +558,11 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
dev->dev_addr[5] = priv->eth_addr[5];
dev->dev_addr[6] = 0x00;
dev->dev_addr[7] = 0x00;
-   printk(KERN_INFO
-  "ks_wlan: MAC ADDRESS = %02x:%02x:%02x:%02x:%02x:%02x\n",
-  priv->eth_addr[0], priv->eth_addr[1], priv->eth_addr[2],
-  priv->eth_addr[3], priv->eth_addr[4], priv->eth_addr[5]);
+   netdev_info(dev,
+   "ks_wlan: MAC ADDRESS = 
%02x:%02x:%02x:%02x:%02x:%02x\n",
+   priv->eth_addr[0], priv->eth_addr[1],
+priv->eth_addr[2], priv->eth_addr[3],
+priv->eth_addr[4], priv->eth_addr[5]);
break;
case DOT11_PRODUCT_VERSION:
/* firmware version */
@@ -571,8 +570,8 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
priv->version_size = priv->rx_size;
memcpy(priv->firmware_version, priv->rxp, priv->rx_size);
priv->firmware_version[priv->rx_size] = '\0';
-   printk(KERN_INFO "ks_wlan: firmware ver. = %s\n",
-  priv->firmware_version);
+   netdev_info(dev, "ks_wlan: firmware ver. = %s\n",
+   priv->firmware_version);
hostif_sme_enqueue(priv, SME_GET_PRODUCT_VERSION);
/* wake_up_interruptible_all(>confirm_wait); */
complete(>confirm_wait);
@@ -592,12 +591,12 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
} else if (priv->eeprom_sum.type == 1) {
if (priv->eeprom_sum.result == 0) {
priv->eeprom_checksum = EEPROM_NG;
-   printk("LOCAL_EEPROM_SUM NG\n");
+   netdev_info(dev, "LOCAL_EEPROM_SUM NG\n");
} else if (priv->eeprom_sum.result == 1) {
priv->eeprom_checksum = EEPROM_OK;
}
} else {
-   printk("LOCAL_EEPROM_SUM error!\n");
+   netdev_err(dev, "LOCAL_EEPROM_SUM error!\n");
}
break;
default:
@@ -894,7 +893,7 @@ void hostif_stop_confirm(struct ks_wlan_private *priv)
netif_carrier_off(netdev);
tmp = FORCE_DISCONNECT & priv->connect_status;
priv->connect_status = tmp | DISCONNECT_STATUS;
-   printk("IWEVENT: disconnect\n");
+   netdev_info(netdev, "IWEVENT: disconnect\n");
 
wrqu0.data.length = 0;
wrqu0.data.flags = 0;
@@ -904,7 +903,7 @@ void hostif_stop_confirm(struct ks_wlan_private *priv)
&& (old_status & CONNECT_STATUS_MASK) == CONNECT_STATUS) {
eth_zero_addr(wrqu0.ap_addr.sa_data);
DPRINTK(3, "IWEVENT: disconnect\n");
-   printk("IWEVENT: disconnect\n");
+   netdev_info(netdev, "IWEVENT: disconnect\n");
DPRINTK(3, "disconnect :: scan_ind_count=%d\n",
priv->scan_ind_count);
wireless_send_event(netdev, SIOCGIWAP, , NULL);
@@ -1110,7 +1109,7 @@ void hostif_event_check(struct ks_wlan_private *priv)
case 

[PATCH 3/3] staging: ks7010: Replace header files

[Sabitha George]

This patch replaces inclusion of asm/atomic.h with linux/atomic.h and
asm/io.h with linux/io.h to fix checkpatch warning in ks_wlan.h

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_wlan.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index c2cc288..5851714 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -25,13 +25,13 @@
 #include/* struct net_device_stats,  struct sk_buff 
*/
 #include 
 #include 
-#include /* struct atmic_t   
*/
+#include   /* struct atomic_t */
 #include/* struct timer_list */
 #include 
 #include   /* struct completion */
 #include 
 
-#include 
+#include 
 
 #include "ks7010_sdio.h"
 
-- 
1.9.1

[PATCH 2/3] staging: ks7010: use netdev_* instead of printk()

[Sabitha George]

Fixes checkpatch warning on printk usage in ks_hostif.c

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_hostif.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index b4d422b..3cee668 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -476,8 +476,7 @@ void hostif_data_indication(struct ks_wlan_private *priv)
skb->dev->last_rx = jiffies;
netif_rx(skb);
} else {
-   printk(KERN_WARNING
-  "ks_wlan: Memory squeeze, dropping packet.\n");
+   netdev_warn(priv->net_dev, "ks_wlan: Memory squeeze, 
dropping packet.\n");
priv->nstats.rx_dropped++;
}
break;
@@ -511,8 +510,7 @@ void hostif_data_indication(struct ks_wlan_private *priv)
skb->dev->last_rx = jiffies;
netif_rx(skb);
} else {
-   printk(KERN_WARNING
-  "ks_wlan: Memory squeeze, dropping packet.\n");
+   netdev_warn(priv->net_dev, "ks_wlan: Memory squeeze, 
dropping packet.\n");
priv->nstats.rx_dropped++;
}
break;
@@ -560,10 +558,11 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
dev->dev_addr[5] = priv->eth_addr[5];
dev->dev_addr[6] = 0x00;
dev->dev_addr[7] = 0x00;
-   printk(KERN_INFO
-  "ks_wlan: MAC ADDRESS = %02x:%02x:%02x:%02x:%02x:%02x\n",
-  priv->eth_addr[0], priv->eth_addr[1], priv->eth_addr[2],
-  priv->eth_addr[3], priv->eth_addr[4], priv->eth_addr[5]);
+   netdev_info(dev,
+   "ks_wlan: MAC ADDRESS = 
%02x:%02x:%02x:%02x:%02x:%02x\n",
+   priv->eth_addr[0], priv->eth_addr[1],
+priv->eth_addr[2], priv->eth_addr[3],
+priv->eth_addr[4], priv->eth_addr[5]);
break;
case DOT11_PRODUCT_VERSION:
/* firmware version */
@@ -571,8 +570,8 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
priv->version_size = priv->rx_size;
memcpy(priv->firmware_version, priv->rxp, priv->rx_size);
priv->firmware_version[priv->rx_size] = '\0';
-   printk(KERN_INFO "ks_wlan: firmware ver. = %s\n",
-  priv->firmware_version);
+   netdev_info(dev, "ks_wlan: firmware ver. = %s\n",
+   priv->firmware_version);
hostif_sme_enqueue(priv, SME_GET_PRODUCT_VERSION);
/* wake_up_interruptible_all(>confirm_wait); */
complete(>confirm_wait);
@@ -592,12 +591,12 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
} else if (priv->eeprom_sum.type == 1) {
if (priv->eeprom_sum.result == 0) {
priv->eeprom_checksum = EEPROM_NG;
-   printk("LOCAL_EEPROM_SUM NG\n");
+   netdev_info(dev, "LOCAL_EEPROM_SUM NG\n");
} else if (priv->eeprom_sum.result == 1) {
priv->eeprom_checksum = EEPROM_OK;
}
} else {
-   printk("LOCAL_EEPROM_SUM error!\n");
+   netdev_err(dev, "LOCAL_EEPROM_SUM error!\n");
}
break;
default:
@@ -894,7 +893,7 @@ void hostif_stop_confirm(struct ks_wlan_private *priv)
netif_carrier_off(netdev);
tmp = FORCE_DISCONNECT & priv->connect_status;
priv->connect_status = tmp | DISCONNECT_STATUS;
-   printk("IWEVENT: disconnect\n");
+   netdev_info(netdev, "IWEVENT: disconnect\n");
 
wrqu0.data.length = 0;
wrqu0.data.flags = 0;
@@ -904,7 +903,7 @@ void hostif_stop_confirm(struct ks_wlan_private *priv)
&& (old_status & CONNECT_STATUS_MASK) == CONNECT_STATUS) {
eth_zero_addr(wrqu0.ap_addr.sa_data);
DPRINTK(3, "IWEVENT: disconnect\n");
-   printk("IWEVENT: disconnect\n");
+   netdev_info(netdev, "IWEVENT: disconnect\n");
DPRINTK(3, "disconnect :: scan_ind_count=%d\n",
priv->scan_ind_count);
wireless_send_event(netdev, SIOCGIWAP, , NULL);
@@ -1110,7 +1109,7 @@ void hostif_event_check(struct ks_wlan_private *priv)
case HIF_AP_SET_CONF:
default:

[PATCH 1/3] staging:ks7010: use __packed instead of __attribute__((packed))

[Sabitha George]

This patch fixes the below checkpatch warning in ks_hostif.c:
 __packed is preferred over __attribute__((packed))

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_hostif.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index c57ca58..b4d422b 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1942,12 +1942,12 @@ void hostif_sme_set_wep(struct ks_wlan_private *priv, 
int type)
 struct wpa_suite_t {
unsigned short size;
unsigned char suite[4][CIPHER_ID_LEN];
-} __attribute__ ((packed));
+} __packed;
 
 struct rsn_mode_t {
uint32_t rsn_mode;
uint16_t rsn_capability;
-} __attribute__ ((packed));
+} __packed;
 
 static
 void hostif_sme_set_rsn(struct ks_wlan_private *priv, int type)
@@ -2427,8 +2427,8 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
struct {
uint8_t bssid[ETH_ALEN];
uint8_t pmkid[IW_PMKID_LEN];
-   } __attribute__ ((packed)) list[PMK_LIST_MAX];
-   } __attribute__ ((packed)) pmkcache;
+   } __packed list[PMK_LIST_MAX];
+   } __packed pmkcache;
struct pmk_t *pmk;
struct list_head *ptr;
int i;
-- 
1.9.1

[PATCH 1/3] staging:ks7010: use __packed instead of __attribute__((packed))

[Sabitha George]

This patch fixes the below checkpatch warning in ks_hostif.c:
 __packed is preferred over __attribute__((packed))

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_hostif.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index c57ca58..b4d422b 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1942,12 +1942,12 @@ void hostif_sme_set_wep(struct ks_wlan_private *priv, 
int type)
 struct wpa_suite_t {
unsigned short size;
unsigned char suite[4][CIPHER_ID_LEN];
-} __attribute__ ((packed));
+} __packed;
 
 struct rsn_mode_t {
uint32_t rsn_mode;
uint16_t rsn_capability;
-} __attribute__ ((packed));
+} __packed;
 
 static
 void hostif_sme_set_rsn(struct ks_wlan_private *priv, int type)
@@ -2427,8 +2427,8 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
struct {
uint8_t bssid[ETH_ALEN];
uint8_t pmkid[IW_PMKID_LEN];
-   } __attribute__ ((packed)) list[PMK_LIST_MAX];
-   } __attribute__ ((packed)) pmkcache;
+   } __packed list[PMK_LIST_MAX];
+   } __packed pmkcache;
struct pmk_t *pmk;
struct list_head *ptr;
int i;
-- 
1.9.1

[PATCH v8 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..af5dd35
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,24 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number.
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.10.0

[PATCH v8 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..af5dd35
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,24 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number.
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.10.0

[PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds
that wrap every second. The driver converts these to a full-range
32-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |  10 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 231 
 include/linux/cpuhotplug.h  |   1 +
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5677886..95dd78b 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -407,6 +407,16 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   select CLKSRC_MMIO
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index fd9d6df..cf87f40 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..4f3ef69
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,231 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT  12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT   26
+#define PIT_IRQ_MASK   0x3f
+#define PIT_PRIO_MASK  0xf
+
+#define REG_PITEN  0x00
+#define REG_THROT  0x10
+#define REG_COUNT  0x14
+#define REG_BUSPD  0x18
+#define REG_SECHI  0x20
+#define REG_SECLO  0x24
+#define REG_NSEC   0x28
+
+struct jcore_pit {
+   struct clock_event_device   ced;
+   __iomem void*base;
+   unsigned long   periodic_delta;
+   unsignedcpu;
+   u32 enable_val;
+};
+
+static __iomem void*jcore_pit_base;
+struct jcore_pit __percpu  *jcore_pit_percpu;
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   u32 seclo, nsec, seclo0;
+   __iomem void *base = jcore_pit_base;
+
+   seclo = readl(base + REG_SECLO);
+   do {
+   seclo0 = seclo;
+   nsec  = readl(base + REG_NSEC);
+   seclo = readl(base + REG_SECLO);
+   } while (seclo0 != seclo);
+
+   return seclo * NSEC_PER_SEC + nsec;
+}
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   return jcore_sched_clock_read();
+}
+
+static int jcore_pit_disable(struct jcore_pit *pit)
+{
+   writel(0, pit->base + REG_PITEN);
+   return 0;
+}
+
+static int jcore_pit_set(unsigned long delta, struct 

[PATCH v8 0/2] J-Core timer support

[Rich Felker]

Resubmitted with the (incorrect) workaround for rcu_sched stalls
removed, since the problem was found in the interrupt controller
driver; a separate patch will be submitted for it.

Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  24 +++
 drivers/clocksource/Kconfig|  10 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 231 +
 include/linux/cpuhotplug.h |   1 +
 5 files changed, 267 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.10.0

[PATCH v8 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds
that wrap every second. The driver converts these to a full-range
32-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |  10 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 231 
 include/linux/cpuhotplug.h  |   1 +
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5677886..95dd78b 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -407,6 +407,16 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   select CLKSRC_MMIO
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index fd9d6df..cf87f40 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..4f3ef69
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,231 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT  12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT   26
+#define PIT_IRQ_MASK   0x3f
+#define PIT_PRIO_MASK  0xf
+
+#define REG_PITEN  0x00
+#define REG_THROT  0x10
+#define REG_COUNT  0x14
+#define REG_BUSPD  0x18
+#define REG_SECHI  0x20
+#define REG_SECLO  0x24
+#define REG_NSEC   0x28
+
+struct jcore_pit {
+   struct clock_event_device   ced;
+   __iomem void*base;
+   unsigned long   periodic_delta;
+   unsignedcpu;
+   u32 enable_val;
+};
+
+static __iomem void*jcore_pit_base;
+struct jcore_pit __percpu  *jcore_pit_percpu;
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   u32 seclo, nsec, seclo0;
+   __iomem void *base = jcore_pit_base;
+
+   seclo = readl(base + REG_SECLO);
+   do {
+   seclo0 = seclo;
+   nsec  = readl(base + REG_NSEC);
+   seclo = readl(base + REG_SECLO);
+   } while (seclo0 != seclo);
+
+   return seclo * NSEC_PER_SEC + nsec;
+}
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   return jcore_sched_clock_read();
+}
+
+static int jcore_pit_disable(struct jcore_pit *pit)
+{
+   writel(0, pit->base + REG_PITEN);
+   return 0;
+}
+
+static int jcore_pit_set(unsigned long delta, struct jcore_pit *pit)
+{
+   

[PATCH v8 0/2] J-Core timer support

[Rich Felker]

Resubmitted with the (incorrect) workaround for rcu_sched stalls
removed, since the problem was found in the interrupt controller
driver; a separate patch will be submitted for it.

Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  24 +++
 drivers/clocksource/Kconfig|  10 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 231 +
 include/linux/cpuhotplug.h |   1 +
 5 files changed, 267 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.10.0

Re: PEACE BE WITH YOU,

[contact]

Subject: Can I Trust You In This5 Days Project ?

Email ( dr.kpyj1...@gmail.com   )

Dear Friend

My name is  ATTORNEY KONO PETER , I really do not mean to waste your time. 
Considering the fact that this is a £36,000,000.00 British Pounds.deal shear 
rate 50/50 % and it's bank to bank wire trasaction within Five workind days.
 
I carefully contact you due to many Internet frauds nowadays.but i put my faith 
in God because all things in life is by risk but don't let me down now or 
after, This is Mr.Plaviashakunthala Lobo and his family was involved in plan 
crash 22nd of May 2010 in List of passengers on Air India Express flight that 
crash  32.Plaviashakunthala Lobo 33. Venishanikola Lobo
34. Vishalfloid Lobo (child) and all family died without any inheritance or 
next of kin so i want you to work together with me been an attorney so this is 
Mr.Plaviashakunthala Lobo account details.
 
Bank name:   Bank of Africa
Bank Address:Cotonou Benin Republic
Account name:Plavia shakunthala Lobo 
Account Number:  1103-8022-1351
Account Balance: £36,000,000.00 British Pounds (GBP)
Date of deposit: 19th December, 2009
Account officer : Bashirudeen  Hussam

I was with Mr.Plaviashakunthala Lobo as a legal witness when this money was 
deposited as fixed deposit in 2009. Since his demise, I have visited this bank 
three times. Contact the bank and ask for the confirmation of his involvement 
in the plane crash.check the website:  
http://www.thehindu.com/news/national/list-of-passengers-on-air-india-express-flight/article435569.ece
 
Thanks
ATTORNEY  KONO PETER  
--
Disclaimer: This message transmitted with it are confidential and privileged. 
If you have received it in error, please notify the sender by return e-mail and 
delete this message from your system. If you are not the intended recipient you 
are hereby notified that any dissemination, copy or disclosure of this e-mail 
is strictly prohibited.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: PEACE BE WITH YOU,

[contact]

Subject: Can I Trust You In This5 Days Project ?

Email ( dr.kpyj1...@gmail.com   )

Dear Friend

My name is  ATTORNEY KONO PETER , I really do not mean to waste your time. 
Considering the fact that this is a £36,000,000.00 British Pounds.deal shear 
rate 50/50 % and it's bank to bank wire trasaction within Five workind days.
 
I carefully contact you due to many Internet frauds nowadays.but i put my faith 
in God because all things in life is by risk but don't let me down now or 
after, This is Mr.Plaviashakunthala Lobo and his family was involved in plan 
crash 22nd of May 2010 in List of passengers on Air India Express flight that 
crash  32.Plaviashakunthala Lobo 33. Venishanikola Lobo
34. Vishalfloid Lobo (child) and all family died without any inheritance or 
next of kin so i want you to work together with me been an attorney so this is 
Mr.Plaviashakunthala Lobo account details.
 
Bank name:   Bank of Africa
Bank Address:Cotonou Benin Republic
Account name:Plavia shakunthala Lobo 
Account Number:  1103-8022-1351
Account Balance: £36,000,000.00 British Pounds (GBP)
Date of deposit: 19th December, 2009
Account officer : Bashirudeen  Hussam

I was with Mr.Plaviashakunthala Lobo as a legal witness when this money was 
deposited as fixed deposit in 2009. Since his demise, I have visited this bank 
three times. Contact the bank and ask for the confirmation of his involvement 
in the plane crash.check the website:  
http://www.thehindu.com/news/national/list-of-passengers-on-air-india-express-flight/article435569.ece
 
Thanks
ATTORNEY  KONO PETER  
--
Disclaimer: This message transmitted with it are confidential and privileged. 
If you have received it in error, please notify the sender by return e-mail and 
delete this message from your system. If you are not the intended recipient you 
are hereby notified that any dissemination, copy or disclosure of this e-mail 
is strictly prohibited.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Resend PATCH] SCSI: scan: fix use-after-free

[Ming Lei]

This patch fixes one use-after-free report[1] by KASAN.

In __scsi_scan_target(), when a type 31 device is probed,
SCSI_SCAN_TARGET_PRESENT is returned and the target will be
scanned again.

Inside the following scsi_report_lun_scan(), one new scsi_device
instance is allocated, and scsi_probe_and_add_lun() is called
again to probe the target and still see type 31 device, finally
__scsi_remove_device() is called to remove & free the device at
the end of scsi_probe_and_add_lun(), so cause use-after-free in
scsi_report_lun_scan().

And the following SCSI log can be observed:

scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
scsi 0:0:2:0: scsi scan: REPORT LUN scan
scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr 
88007b44a104

This patch fixes the issue by moving the putting reference at
the end of scsi_report_lun_scan().

[1] KASAN report
==
[3.274597] PM: Adding info for serio:serio1
[3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at 
addr 880254d8c304
[3.275653] Read of size 4 by task kworker/u10:0/27
[3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
[3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[3.276797] Workqueue: events_unbound async_run_entry_fn
[3.277083]  880254d8c380 880259a37870 94bbc6c1 
880078402d80
[3.277532]  880254d8bb80 880259a37898 9459fec1 
880259a37930
[3.277989]  880254d8bb80 880078402d80 880259a37920 
945a0165
[3.278436] Call Trace:
[3.278528]  [] dump_stack+0x65/0x84
[3.278797]  [] kasan_object_err+0x21/0x70
[3.279063] device: 'psaux': device_add
[3.279616]  [] kasan_report_error+0x205/0x500
[3.279651] PM: Adding info for No Bus:psaux
[3.280202]  [] ? kfree_const+0x22/0x30
[3.280486]  [] ? kobject_release+0x119/0x370
[3.280805]  [] __asan_report_load4_noabort+0x43/0x50
[3.281170]  [] ? __scsi_scan_target+0xd87/0xdf0
[3.281506]  [] __scsi_scan_target+0xd87/0xdf0
[3.281848]  [] ? scsi_add_device+0x30/0x30
[3.282156]  [] ? 
pm_runtime_autosuspend_expiration+0x60/0x60
[3.282570]  [] ? _raw_spin_lock+0x17/0x40
[3.282880]  [] scsi_scan_channel+0x105/0x160
[3.283200]  [] scsi_scan_host_selected+0x212/0x2f0
[3.283563]  [] do_scsi_scan_host+0x1bc/0x250
[3.283882]  [] do_scan_async+0x41/0x450
[3.284173]  [] async_run_entry_fn+0xfe/0x610
[3.284492]  [] ? pwq_dec_nr_in_flight+0x124/0x2a0
[3.284876]  [] ? preempt_count_add+0x130/0x160
[3.285207]  [] process_one_work+0x544/0x12d0
[3.285526]  [] worker_thread+0xd9/0x12f0
[3.285844]  [] ? process_one_work+0x12d0/0x12d0
[3.286182]  [] kthread+0x1c5/0x260
[3.286443]  [] ? __switch_to+0x88d/0x1430
[3.286745]  [] ? kthread_worker_fn+0x5a0/0x5a0
[3.287085]  [] ret_from_fork+0x1f/0x40
[3.287368]  [] ? kthread_worker_fn+0x5a0/0x5a0
[3.287697] Object at 880254d8bb80, in cache kmalloc-2048 size: 2048
[3.288064] Allocated:
[3.288147] PID = 27
[3.288218]  [] save_stack_trace+0x2b/0x50
[3.288531]  [] save_stack+0x46/0xd0
[3.288806]  [] kasan_kmalloc+0xad/0xe0
[3.289098]  [] __kmalloc+0x13e/0x250
[3.289378]  [] scsi_alloc_sdev+0xea/0xcf0
[3.289701]  [] __scsi_scan_target+0xa06/0xdf0
[3.290034]  [] scsi_scan_channel+0x105/0x160
[3.290362]  [] scsi_scan_host_selected+0x212/0x2f0
[3.290724]  [] do_scsi_scan_host+0x1bc/0x250
[3.291055]  [] do_scan_async+0x41/0x450
[3.291354]  [] async_run_entry_fn+0xfe/0x610
[3.291695]  [] process_one_work+0x544/0x12d0
[3.292022]  [] worker_thread+0xd9/0x12f0
[3.292325]  [] kthread+0x1c5/0x260
[3.292594]  [] ret_from_fork+0x1f/0x40
[3.292886] Freed:
[3.292945] PID = 27
[3.293016]  [] save_stack_trace+0x2b/0x50
[3.293327]  [] save_stack+0x46/0xd0
[3.293600]  [] kasan_slab_free+0x71/0xb0
[3.293916]  [] kfree+0xa2/0x1f0
[3.294168]  [] 
scsi_device_dev_release_usercontext+0x50a/0x730
[3.294598]  [] execute_in_process_context+0xda/0x130
[3.294974]  [] scsi_device_dev_release+0x1c/0x20
[3.295322]  [] device_release+0x76/0x1e0
[3.295626]  [] kobject_release+0x107/0x370
[3.295942]  [] kobject_put+0x4e/0xa0
[3.296222]  [] put_device+0x17/0x20
[3.296497]  [] scsi_device_put+0x7c/0xa0
[3.296801]  [] 

[Resend PATCH] SCSI: scan: fix use-after-free

[Ming Lei]

This patch fixes one use-after-free report[1] by KASAN.

In __scsi_scan_target(), when a type 31 device is probed,
SCSI_SCAN_TARGET_PRESENT is returned and the target will be
scanned again.

Inside the following scsi_report_lun_scan(), one new scsi_device
instance is allocated, and scsi_probe_and_add_lun() is called
again to probe the target and still see type 31 device, finally
__scsi_remove_device() is called to remove & free the device at
the end of scsi_probe_and_add_lun(), so cause use-after-free in
scsi_report_lun_scan().

And the following SCSI log can be observed:

scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
scsi 0:0:2:0: scsi scan: REPORT LUN scan
scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr 
88007b44a104

This patch fixes the issue by moving the putting reference at
the end of scsi_report_lun_scan().

[1] KASAN report
==
[3.274597] PM: Adding info for serio:serio1
[3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at 
addr 880254d8c304
[3.275653] Read of size 4 by task kworker/u10:0/27
[3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
[3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[3.276797] Workqueue: events_unbound async_run_entry_fn
[3.277083]  880254d8c380 880259a37870 94bbc6c1 
880078402d80
[3.277532]  880254d8bb80 880259a37898 9459fec1 
880259a37930
[3.277989]  880254d8bb80 880078402d80 880259a37920 
945a0165
[3.278436] Call Trace:
[3.278528]  [] dump_stack+0x65/0x84
[3.278797]  [] kasan_object_err+0x21/0x70
[3.279063] device: 'psaux': device_add
[3.279616]  [] kasan_report_error+0x205/0x500
[3.279651] PM: Adding info for No Bus:psaux
[3.280202]  [] ? kfree_const+0x22/0x30
[3.280486]  [] ? kobject_release+0x119/0x370
[3.280805]  [] __asan_report_load4_noabort+0x43/0x50
[3.281170]  [] ? __scsi_scan_target+0xd87/0xdf0
[3.281506]  [] __scsi_scan_target+0xd87/0xdf0
[3.281848]  [] ? scsi_add_device+0x30/0x30
[3.282156]  [] ? 
pm_runtime_autosuspend_expiration+0x60/0x60
[3.282570]  [] ? _raw_spin_lock+0x17/0x40
[3.282880]  [] scsi_scan_channel+0x105/0x160
[3.283200]  [] scsi_scan_host_selected+0x212/0x2f0
[3.283563]  [] do_scsi_scan_host+0x1bc/0x250
[3.283882]  [] do_scan_async+0x41/0x450
[3.284173]  [] async_run_entry_fn+0xfe/0x610
[3.284492]  [] ? pwq_dec_nr_in_flight+0x124/0x2a0
[3.284876]  [] ? preempt_count_add+0x130/0x160
[3.285207]  [] process_one_work+0x544/0x12d0
[3.285526]  [] worker_thread+0xd9/0x12f0
[3.285844]  [] ? process_one_work+0x12d0/0x12d0
[3.286182]  [] kthread+0x1c5/0x260
[3.286443]  [] ? __switch_to+0x88d/0x1430
[3.286745]  [] ? kthread_worker_fn+0x5a0/0x5a0
[3.287085]  [] ret_from_fork+0x1f/0x40
[3.287368]  [] ? kthread_worker_fn+0x5a0/0x5a0
[3.287697] Object at 880254d8bb80, in cache kmalloc-2048 size: 2048
[3.288064] Allocated:
[3.288147] PID = 27
[3.288218]  [] save_stack_trace+0x2b/0x50
[3.288531]  [] save_stack+0x46/0xd0
[3.288806]  [] kasan_kmalloc+0xad/0xe0
[3.289098]  [] __kmalloc+0x13e/0x250
[3.289378]  [] scsi_alloc_sdev+0xea/0xcf0
[3.289701]  [] __scsi_scan_target+0xa06/0xdf0
[3.290034]  [] scsi_scan_channel+0x105/0x160
[3.290362]  [] scsi_scan_host_selected+0x212/0x2f0
[3.290724]  [] do_scsi_scan_host+0x1bc/0x250
[3.291055]  [] do_scan_async+0x41/0x450
[3.291354]  [] async_run_entry_fn+0xfe/0x610
[3.291695]  [] process_one_work+0x544/0x12d0
[3.292022]  [] worker_thread+0xd9/0x12f0
[3.292325]  [] kthread+0x1c5/0x260
[3.292594]  [] ret_from_fork+0x1f/0x40
[3.292886] Freed:
[3.292945] PID = 27
[3.293016]  [] save_stack_trace+0x2b/0x50
[3.293327]  [] save_stack+0x46/0xd0
[3.293600]  [] kasan_slab_free+0x71/0xb0
[3.293916]  [] kfree+0xa2/0x1f0
[3.294168]  [] 
scsi_device_dev_release_usercontext+0x50a/0x730
[3.294598]  [] execute_in_process_context+0xda/0x130
[3.294974]  [] scsi_device_dev_release+0x1c/0x20
[3.295322]  [] device_release+0x76/0x1e0
[3.295626]  [] kobject_release+0x107/0x370
[3.295942]  [] kobject_put+0x4e/0xa0
[3.296222]  [] put_device+0x17/0x20
[3.296497]  [] scsi_device_put+0x7c/0xa0
[3.296801]  [] 

Re: [PATCH v2 03/46] mtd: Don't unconditionally unregister reboot notifier

[Brian Norris]

I realize I didn't comment on the latest copy of this patch, so copying
my questions here:

On Wed, Sep 21, 2016 at 11:45:12AM +0200, Daniel Walter wrote:
> From: Richard Weinberger 
> 
> del_mtd_device() is allowed to fail.
> i.e. when the MTD is busy.
> Unregister the reboot notifier only when we're really
> about to delete the MTD.
> 
> Signed-off-by: Richard Weinberger 
> ---
>  drivers/mtd/mtdcore.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index e3936b8..36e5fb0 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -654,17 +654,22 @@ int mtd_device_unregister(struct mtd_info *master)
>  {
>   int err;
>  
> - if (master->_reboot)
> - unregister_reboot_notifier(>reboot_notifier);
> -
>   err = del_mtd_partitions(master);
>   if (err)
>   return err;
>  
>   if (!device_is_registered(>dev))
> - return 0;
> + goto unregister;
>  
> - return del_mtd_device(master);
> + err = del_mtd_device(master);
> + if (err)
> + return err;
> +
> +unregister:
> + if (master->_reboot)
> + unregister_reboot_notifier(>reboot_notifier);

Is there any kind of race issue with unregistering the notifier *after*
we've deleted the device? I had intentionally unregistered first,
because I didn't want any chance of the driver/module and/or data
structures being freed before we call the notifier.

I can't think of any particular issue yet, but I wanted to ask.

Brian

> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(mtd_device_unregister);
>  
> -- 
> 2.8.3
> 

Re: [PATCH v2 03/46] mtd: Don't unconditionally unregister reboot notifier

[Brian Norris]

I realize I didn't comment on the latest copy of this patch, so copying
my questions here:

On Wed, Sep 21, 2016 at 11:45:12AM +0200, Daniel Walter wrote:
> From: Richard Weinberger 
> 
> del_mtd_device() is allowed to fail.
> i.e. when the MTD is busy.
> Unregister the reboot notifier only when we're really
> about to delete the MTD.
> 
> Signed-off-by: Richard Weinberger 
> ---
>  drivers/mtd/mtdcore.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index e3936b8..36e5fb0 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -654,17 +654,22 @@ int mtd_device_unregister(struct mtd_info *master)
>  {
>   int err;
>  
> - if (master->_reboot)
> - unregister_reboot_notifier(>reboot_notifier);
> -
>   err = del_mtd_partitions(master);
>   if (err)
>   return err;
>  
>   if (!device_is_registered(>dev))
> - return 0;
> + goto unregister;
>  
> - return del_mtd_device(master);
> + err = del_mtd_device(master);
> + if (err)
> + return err;
> +
> +unregister:
> + if (master->_reboot)
> + unregister_reboot_notifier(>reboot_notifier);

Is there any kind of race issue with unregistering the notifier *after*
we've deleted the device? I had intentionally unregistered first,
because I didn't want any chance of the driver/module and/or data
structures being freed before we call the notifier.

I can't think of any particular issue yet, but I wanted to ask.

Brian

> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(mtd_device_unregister);
>  
> -- 
> 2.8.3
> 

[GIT PULL] MTD updates for 4.9-rc1

[Brian Norris]

Hi Linus,

I've not been very active this cycle, so these are mostly from Boris,
for the NAND flash subsystem.

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20161008

for you to fetch changes up to 69db4aa44fdd8befc2eccd1313d841c5128c385c:

  Merge tag '4.9/mtd-pairing-scheme' of github.com:linux-nand/linux (2016-10-08 
20:56:54 -0700)


MTD updates for 4.9-rc1

NAND:

 * Add the infrastructure to automate NAND timings configuration
 * Provide a generic DT property to maximize ECC strength
 * Some refactoring in the core bad block table handling, to help with
   improving some of the logic in error cases.
 * Minor cleanups and fixes

MTD:

 * Add APIs for handling page pairing; this is necessary for reliably
   supporting MLC and TLC NAND flash, where paired-page disturbance affects
   reliability. Upper layers (e.g., UBI) should make use of these in the near
   future.


Andrey Smirnov (4):
  Kconfig: nand: Make MTD_NAND_FSL_ELBC depend on FSL_SOC
  Kconfig: nand: Remove redundant dependency on MTD_NAND
  mtd: nand: Error out if cmd_ctrl() is missing
  mtd: nand: Get rid of needless 'goto'

Boris Brezillon (11):
  mtd: introduce the mtd_pairing_scheme concept
  mtd: nand: timings: Fix tADL_min for ONFI 4.0 chips
  mtd: nand: timings: Reorder tRR_min def in mode 0
  mtd: nand_bbt: Move BBT block selection logic out of write_bbt()
  mtd: nand: automate NAND timings selection
  mtd: nand: Add an option to maximize the ECC strength
  mtd: nand: Support maximizing ECC when using software BCH
  mtd: nand: sunxi: Support ECC maximization
  mtd: nand: Fix nand_command_lp() for 8bits opcodes
  mtd: nand: mxc: Test CONFIG_OF instead of CONFIG_OF_MTD
  mtd: Kill the OF_MTD Kconfig option

Brian Norris (4):
  mtd: nand: sh_flctl: handle dma_submit() errors
  Merge tag 'for-4.9' of github.com:linux-nand/linux
  mtd: nand: fix trivial spelling error
  Merge tag '4.9/mtd-pairing-scheme' of github.com:linux-nand/linux

Han Xu (1):
  mtd: nand: gpmi: get correct free oob space

Harvey Hunt (1):
  MAINTAINERS: Add maintainer entry for Ingenic JZ4780 NAND driver

Karl Beldan (1):
  mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

Krzysztof Kozlowski (1):
  mtd: nand: s3c2410: Register cpufreq notifier only on S3C24xx

Kyle Roeschley (1):
  mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Marc Gonzalez (1):
  mtd: nand: import nand_hw_control_init()

Ray Jui (1):
  mtd: brcmnand: iProc big endian and ONFI support

Richard Weinberger (2):
  mtd: nand: Provide nand_cleanup() function to free NAND related resources
  mtdpart: Propagate _get/put_device()

Roger Quadros (2):
  mtd: nand: omap2: Don't call dma_release_channel() if dma_request_chan() 
failed
  mtd: nand: Allow MTD_NAND_OMAP2 to be usable on Keystone devices

Sascha Hauer (9):
  mtd: nand: remove unnecessary 'extern' from function declarations
  mtd: nand: Create a NAND reset function
  mtd: nand: Introduce nand_data_interface
  mtd: nand: convert ONFI mode into data interface
  mtd: nand: Add function to convert ONFI mode to data_interface
  mtd: nand: Expose data interface for ONFI mode 0
  mtd: nand: sunxi: switch from manual to automated timing config
  mtd: nand: mxc: implement onfi get/set features
  mtd: nand: mxc: Add timing setup for v2 controllers

 Documentation/devicetree/bindings/mtd/nand.txt |   9 +
 MAINTAINERS|   6 +
 drivers/mtd/mtdcore.c  | 104 ++
 drivers/mtd/mtdpart.c  |  19 +
 drivers/mtd/nand/Kconfig   |  12 +-
 drivers/mtd/nand/bf5xx_nand.c  |   3 +-
 drivers/mtd/nand/brcmnand/brcmnand.c   |  15 +-
 drivers/mtd/nand/brcmnand/brcmnand.h   |  13 +-
 drivers/mtd/nand/brcmnand/iproc_nand.c |  18 +-
 drivers/mtd/nand/davinci_nand.c|   3 +
 drivers/mtd/nand/docg4.c   |   3 +-
 drivers/mtd/nand/fsl_elbc_nand.c   |   3 +-
 drivers/mtd/nand/fsl_ifc_nand.c|   3 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |   3 +-
 drivers/mtd/nand/jz4780_nand.c |   3 +-
 drivers/mtd/nand/mxc_nand.c| 137 ++-
 drivers/mtd/nand/nand_base.c   | 260 --
 drivers/mtd/nand/nand_bbt.c| 161 ++---
 drivers/mtd/nand/nand_timings.c| 470 ++---
 drivers/mtd/nand/ndfc.c|   3 +-
 drivers/mtd/nand/omap2.c   |   2

[GIT PULL] MTD updates for 4.9-rc1

[Brian Norris]

Hi Linus,

I've not been very active this cycle, so these are mostly from Boris,
for the NAND flash subsystem.

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20161008

for you to fetch changes up to 69db4aa44fdd8befc2eccd1313d841c5128c385c:

  Merge tag '4.9/mtd-pairing-scheme' of github.com:linux-nand/linux (2016-10-08 
20:56:54 -0700)


MTD updates for 4.9-rc1

NAND:

 * Add the infrastructure to automate NAND timings configuration
 * Provide a generic DT property to maximize ECC strength
 * Some refactoring in the core bad block table handling, to help with
   improving some of the logic in error cases.
 * Minor cleanups and fixes

MTD:

 * Add APIs for handling page pairing; this is necessary for reliably
   supporting MLC and TLC NAND flash, where paired-page disturbance affects
   reliability. Upper layers (e.g., UBI) should make use of these in the near
   future.


Andrey Smirnov (4):
  Kconfig: nand: Make MTD_NAND_FSL_ELBC depend on FSL_SOC
  Kconfig: nand: Remove redundant dependency on MTD_NAND
  mtd: nand: Error out if cmd_ctrl() is missing
  mtd: nand: Get rid of needless 'goto'

Boris Brezillon (11):
  mtd: introduce the mtd_pairing_scheme concept
  mtd: nand: timings: Fix tADL_min for ONFI 4.0 chips
  mtd: nand: timings: Reorder tRR_min def in mode 0
  mtd: nand_bbt: Move BBT block selection logic out of write_bbt()
  mtd: nand: automate NAND timings selection
  mtd: nand: Add an option to maximize the ECC strength
  mtd: nand: Support maximizing ECC when using software BCH
  mtd: nand: sunxi: Support ECC maximization
  mtd: nand: Fix nand_command_lp() for 8bits opcodes
  mtd: nand: mxc: Test CONFIG_OF instead of CONFIG_OF_MTD
  mtd: Kill the OF_MTD Kconfig option

Brian Norris (4):
  mtd: nand: sh_flctl: handle dma_submit() errors
  Merge tag 'for-4.9' of github.com:linux-nand/linux
  mtd: nand: fix trivial spelling error
  Merge tag '4.9/mtd-pairing-scheme' of github.com:linux-nand/linux

Han Xu (1):
  mtd: nand: gpmi: get correct free oob space

Harvey Hunt (1):
  MAINTAINERS: Add maintainer entry for Ingenic JZ4780 NAND driver

Karl Beldan (1):
  mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

Krzysztof Kozlowski (1):
  mtd: nand: s3c2410: Register cpufreq notifier only on S3C24xx

Kyle Roeschley (1):
  mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Marc Gonzalez (1):
  mtd: nand: import nand_hw_control_init()

Ray Jui (1):
  mtd: brcmnand: iProc big endian and ONFI support

Richard Weinberger (2):
  mtd: nand: Provide nand_cleanup() function to free NAND related resources
  mtdpart: Propagate _get/put_device()

Roger Quadros (2):
  mtd: nand: omap2: Don't call dma_release_channel() if dma_request_chan() 
failed
  mtd: nand: Allow MTD_NAND_OMAP2 to be usable on Keystone devices

Sascha Hauer (9):
  mtd: nand: remove unnecessary 'extern' from function declarations
  mtd: nand: Create a NAND reset function
  mtd: nand: Introduce nand_data_interface
  mtd: nand: convert ONFI mode into data interface
  mtd: nand: Add function to convert ONFI mode to data_interface
  mtd: nand: Expose data interface for ONFI mode 0
  mtd: nand: sunxi: switch from manual to automated timing config
  mtd: nand: mxc: implement onfi get/set features
  mtd: nand: mxc: Add timing setup for v2 controllers

 Documentation/devicetree/bindings/mtd/nand.txt |   9 +
 MAINTAINERS|   6 +
 drivers/mtd/mtdcore.c  | 104 ++
 drivers/mtd/mtdpart.c  |  19 +
 drivers/mtd/nand/Kconfig   |  12 +-
 drivers/mtd/nand/bf5xx_nand.c  |   3 +-
 drivers/mtd/nand/brcmnand/brcmnand.c   |  15 +-
 drivers/mtd/nand/brcmnand/brcmnand.h   |  13 +-
 drivers/mtd/nand/brcmnand/iproc_nand.c |  18 +-
 drivers/mtd/nand/davinci_nand.c|   3 +
 drivers/mtd/nand/docg4.c   |   3 +-
 drivers/mtd/nand/fsl_elbc_nand.c   |   3 +-
 drivers/mtd/nand/fsl_ifc_nand.c|   3 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |   3 +-
 drivers/mtd/nand/jz4780_nand.c |   3 +-
 drivers/mtd/nand/mxc_nand.c| 137 ++-
 drivers/mtd/nand/nand_base.c   | 260 --
 drivers/mtd/nand/nand_bbt.c| 161 ++---
 drivers/mtd/nand/nand_timings.c| 470 ++---
 drivers/mtd/nand/ndfc.c|   3 +-
 drivers/mtd/nand/omap2.c   |   2

[mm, kasan] 80a9201a59: INFO: rcu_sched stall on CPU (84741 ticks this GP) idle=140000000000000 (t=100000 jiffies q=1)

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit 80a9201a5965f4715d5c09790862e0df84ce0614
Author: Alexander Potapenko 
AuthorDate: Thu Jul 28 15:49:07 2016 -0700
Commit: Linus Torvalds 
CommitDate: Thu Jul 28 16:07:41 2016 -0700

mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB

For KASAN builds:
 - switch SLUB allocator to using stackdepot instead of storing the
   allocation/deallocation stacks in the objects;
 - change the freelist hook so that parts of the freelist can be put
   into the quarantine.

[aryabi...@virtuozzo.com: fixes]
  Link: 
http://lkml.kernel.org/r/1468601423-28676-1-git-send-email-aryabi...@virtuozzo.com
Link: 
http://lkml.kernel.org/r/1468347165-41906-3-git-send-email-gli...@google.com
Signed-off-by: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Christoph Lameter 
Cc: Dmitry Vyukov 
Cc: Steven Rostedt (Red Hat) 
Cc: Joonsoo Kim 
Cc: Kostya Serebryany 
Cc: Andrey Ryabinin 
Cc: Kuthonuzo Luruo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

+++++
|| 
c146a2b98e | 80a9201a59 | a61bc9c9af |
+++++
| boot_successes | 
655| 86 | 9  |
| boot_failures  | 
0  | 139| 16 |
| INFO:rcu_sched_stall_on_CPU(#ticks_this_GP)idle=#(t=#jiffies_q=#)  | 
0  | 139| 10 |
| calltrace:mark_rodata_ro   | 
0  | 139| 14 |
| Kernel_panic-not_syncing:VFS:Unable_to_mount_root_fs_on_unknown-block(#,#) | 
0  | 0  | 2  |
| calltrace:prepare_namespace| 
0  | 0  | 2  |
| WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page| 
0  | 0  | 6  |
+++++

[   14.024541] Write protecting the kernel read-only data: 18432k
[   14.030857] Freeing unused kernel memory: 1936K (88000e81c000 - 
88000ea0)
[   14.043192] Freeing unused kernel memory: 248K (88000efc2000 - 
88000f00)
[  114.005845] INFO: rcu_sched stall on CPU (84741 ticks this GP) 
idle=140 (t=10 jiffies q=1)
[  114.009928] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-05999-g80a9201 #1
[  114.011362] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  114.013154]   acc40db8 abfc7274 
acc40df8
[  114.014763]  abae00ec 0001  

[  114.016378]  0019dcf1a68b acc40f18 ace7e488 
acc40e18
[  114.017988] Call Trace:
[  114.018504][] dump_stack+0x19/0x1b
[  114.019739]  [] check_cpu_stall+0xc0/0x124
[  114.021041]  [] rcu_check_callbacks+0x50/0xa0
[  114.022263]  [] update_process_times+0x2e/0x52
[  114.023503]  [] tick_sched_handle+0x66/0x6d
[  114.024813]  [] tick_sched_timer+0x3d/0x78
[  114.025977]  [] __hrtimer_run_queues+0x252/0x45b
[  114.027461]  [] ? tick_sched_handle+0x6d/0x6d
[  114.028793]  [] ? hrtimer_start_range_ns+0x315/0x315
[  114.030130]  [] ? kvm_clock_get_cycles+0x9/0xb
[  114.031367]  [] ? ktime_get_update_offsets_now+0xf1/0x184
[  114.032784]  [] hrtimer_interrupt+0x8c/0x189
[  114.033983]  [] local_apic_timer_interrupt+0x42/0x44
[  114.035337]  [] smp_apic_timer_interrupt+0x55/0x66
[  114.036636]  [] apic_timer_interrupt+0x7d/0x90
[  114.037864][] ? note_page+0x2b/0x7af
[  114.039125]  [] ? note_page+0xce/0x7af
[  114.040219]  [] ptdump_walk_pgd_level_core+0x343/0x483
[  114.041583]  [] ? note_page+0x7af/0x7af
[  114.042577]  [] ptdump_walk_pgd_level_checkwx+0x17/0x2f
[  114.043639]  [] mark_rodata_ro+0x14b/0x152
[  114.044545]  [] kernel_init+0x29/0x100
[  114.045393]  [] ret_from_fork+0x1f/0x40
[  114.046252]  [] ? rest_init+0xce/0xce
[  118.107577] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[  118.113902] rcu-torture: rtc: addea720 ver: 1 tfle: 0 rta: 1 rtaf: 0 
rtf: 0 rtmbe: 0 

[mm, kasan] 80a9201a59: INFO: rcu_sched stall on CPU (84741 ticks this GP) idle=140000000000000 (t=100000 jiffies q=1)

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit 80a9201a5965f4715d5c09790862e0df84ce0614
Author: Alexander Potapenko 
AuthorDate: Thu Jul 28 15:49:07 2016 -0700
Commit: Linus Torvalds 
CommitDate: Thu Jul 28 16:07:41 2016 -0700

mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB

For KASAN builds:
 - switch SLUB allocator to using stackdepot instead of storing the
   allocation/deallocation stacks in the objects;
 - change the freelist hook so that parts of the freelist can be put
   into the quarantine.

[aryabi...@virtuozzo.com: fixes]
  Link: 
http://lkml.kernel.org/r/1468601423-28676-1-git-send-email-aryabi...@virtuozzo.com
Link: 
http://lkml.kernel.org/r/1468347165-41906-3-git-send-email-gli...@google.com
Signed-off-by: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Christoph Lameter 
Cc: Dmitry Vyukov 
Cc: Steven Rostedt (Red Hat) 
Cc: Joonsoo Kim 
Cc: Kostya Serebryany 
Cc: Andrey Ryabinin 
Cc: Kuthonuzo Luruo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

+++++
|| 
c146a2b98e | 80a9201a59 | a61bc9c9af |
+++++
| boot_successes | 
655| 86 | 9  |
| boot_failures  | 
0  | 139| 16 |
| INFO:rcu_sched_stall_on_CPU(#ticks_this_GP)idle=#(t=#jiffies_q=#)  | 
0  | 139| 10 |
| calltrace:mark_rodata_ro   | 
0  | 139| 14 |
| Kernel_panic-not_syncing:VFS:Unable_to_mount_root_fs_on_unknown-block(#,#) | 
0  | 0  | 2  |
| calltrace:prepare_namespace| 
0  | 0  | 2  |
| WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page| 
0  | 0  | 6  |
+++++

[   14.024541] Write protecting the kernel read-only data: 18432k
[   14.030857] Freeing unused kernel memory: 1936K (88000e81c000 - 
88000ea0)
[   14.043192] Freeing unused kernel memory: 248K (88000efc2000 - 
88000f00)
[  114.005845] INFO: rcu_sched stall on CPU (84741 ticks this GP) 
idle=140 (t=10 jiffies q=1)
[  114.009928] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-05999-g80a9201 #1
[  114.011362] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  114.013154]   acc40db8 abfc7274 
acc40df8
[  114.014763]  abae00ec 0001  

[  114.016378]  0019dcf1a68b acc40f18 ace7e488 
acc40e18
[  114.017988] Call Trace:
[  114.018504][] dump_stack+0x19/0x1b
[  114.019739]  [] check_cpu_stall+0xc0/0x124
[  114.021041]  [] rcu_check_callbacks+0x50/0xa0
[  114.022263]  [] update_process_times+0x2e/0x52
[  114.023503]  [] tick_sched_handle+0x66/0x6d
[  114.024813]  [] tick_sched_timer+0x3d/0x78
[  114.025977]  [] __hrtimer_run_queues+0x252/0x45b
[  114.027461]  [] ? tick_sched_handle+0x6d/0x6d
[  114.028793]  [] ? hrtimer_start_range_ns+0x315/0x315
[  114.030130]  [] ? kvm_clock_get_cycles+0x9/0xb
[  114.031367]  [] ? ktime_get_update_offsets_now+0xf1/0x184
[  114.032784]  [] hrtimer_interrupt+0x8c/0x189
[  114.033983]  [] local_apic_timer_interrupt+0x42/0x44
[  114.035337]  [] smp_apic_timer_interrupt+0x55/0x66
[  114.036636]  [] apic_timer_interrupt+0x7d/0x90
[  114.037864][] ? note_page+0x2b/0x7af
[  114.039125]  [] ? note_page+0xce/0x7af
[  114.040219]  [] ptdump_walk_pgd_level_core+0x343/0x483
[  114.041583]  [] ? note_page+0x7af/0x7af
[  114.042577]  [] ptdump_walk_pgd_level_checkwx+0x17/0x2f
[  114.043639]  [] mark_rodata_ro+0x14b/0x152
[  114.044545]  [] kernel_init+0x29/0x100
[  114.045393]  [] ret_from_fork+0x1f/0x40
[  114.046252]  [] ? rest_init+0xce/0xce
[  118.107577] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[  118.113902] rcu-torture: rtc: addea720 ver: 1 tfle: 0 rta: 1 rtaf: 0 
rtf: 0 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 1 barrier: 0/0:0 cbflood: 1

git bisect start v4.8 v4.7 --
git bisect  bad e6e7214fbbdab1f90254af68e0927bdb24708d22  # 07:46  9-  
9  Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad 

Re: [PATCH v3] mtd: introduce the mtd_pairing_scheme concept

[Brian Norris]

On Thu, Sep 15, 2016 at 05:05:29PM +0200, Boris Brezillon wrote:
> MLC and TLC NAND devices are using NAND cells exposing more than one bit,
> but instead of attaching all the bits in a given cell to a single NAND
> page, each bit is usually attached to a different page. This concept is
> called 'page pairing', and has significant impacts on the flash storage
> usage.
> The main problem showed by these devices is that interrupting a page
> program operation may not only corrupt the page we are programming
> but also the page it is paired with, hence the need to expose to MTD
> users the pairing scheme information.
> 
> The pairing APIs allows one to query pairing information attached to a
> given page (here called wunit), or the other way around (the wunit
> pointed by pairing information).
> It also provides several helpers to help the conversion between absolute
> offsets and wunits, and query the number of pairing groups.
> 
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Brian Norris 
> ---
> Hi Brian,
> 
> Here is a new version addressing your comments.
> If you're okay with this version, you can directly pull the
> 4.9/mtd-pairing-scheme tag [1] into your tree (it's based on 4.8-rc1).

I never found where '[1]' was pointing, but I did pull
4.9/mtd-pairing-scheme from github.com:linux-nand/linux into
linux-mtd.git.

Thanks,
Brian

> Changes since v2:
> - fix documentation
> - make API consistent by returning error codes and adding bounds
>   checking everywhere
> - drop NAND pairing scheme patches (will be resubmitted after
>   this patch has been merged)
> 
> Changes since v1:
> - document the paring scheme concepts and the associate structures and
>   helpers
> - rework the dist3 and dist6 implementation according to George
>   comments
> - introduce the mtd_set_pairing_scheme() helper to avoid directly
>   manipulating the mtd->pairing field
> - drop the patch assigning dist6 pairing scheme to the H27UCG8T2ATR
>   NAND (in the light of George comment I'm not longer sure this scheme
>   is suitable for this NAND, and I can't test it)
> 
>  drivers/mtd/mtdcore.c   | 104 ++
>  drivers/mtd/mtdpart.c   |   1 +
>  include/linux/mtd/mtd.h | 107 
> 
>  3 files changed, 212 insertions(+)

Re: [PATCH v3] mtd: introduce the mtd_pairing_scheme concept

[Brian Norris]

On Thu, Sep 15, 2016 at 05:05:29PM +0200, Boris Brezillon wrote:
> MLC and TLC NAND devices are using NAND cells exposing more than one bit,
> but instead of attaching all the bits in a given cell to a single NAND
> page, each bit is usually attached to a different page. This concept is
> called 'page pairing', and has significant impacts on the flash storage
> usage.
> The main problem showed by these devices is that interrupting a page
> program operation may not only corrupt the page we are programming
> but also the page it is paired with, hence the need to expose to MTD
> users the pairing scheme information.
> 
> The pairing APIs allows one to query pairing information attached to a
> given page (here called wunit), or the other way around (the wunit
> pointed by pairing information).
> It also provides several helpers to help the conversion between absolute
> offsets and wunits, and query the number of pairing groups.
> 
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Brian Norris 
> ---
> Hi Brian,
> 
> Here is a new version addressing your comments.
> If you're okay with this version, you can directly pull the
> 4.9/mtd-pairing-scheme tag [1] into your tree (it's based on 4.8-rc1).

I never found where '[1]' was pointing, but I did pull
4.9/mtd-pairing-scheme from github.com:linux-nand/linux into
linux-mtd.git.

Thanks,
Brian

> Changes since v2:
> - fix documentation
> - make API consistent by returning error codes and adding bounds
>   checking everywhere
> - drop NAND pairing scheme patches (will be resubmitted after
>   this patch has been merged)
> 
> Changes since v1:
> - document the paring scheme concepts and the associate structures and
>   helpers
> - rework the dist3 and dist6 implementation according to George
>   comments
> - introduce the mtd_set_pairing_scheme() helper to avoid directly
>   manipulating the mtd->pairing field
> - drop the patch assigning dist6 pairing scheme to the H27UCG8T2ATR
>   NAND (in the light of George comment I'm not longer sure this scheme
>   is suitable for this NAND, and I can't test it)
> 
>  drivers/mtd/mtdcore.c   | 104 ++
>  drivers/mtd/mtdpart.c   |   1 +
>  include/linux/mtd/mtd.h | 107 
> 
>  3 files changed, 212 insertions(+)

Re: [PATCH] MAINTAINERS: Add ARM64-specific ACPI maintainers entry

[Hanjun Guo]

On 10/05/2016 07:25 PM, Lorenzo Pieralisi wrote:

The ARM64 architecture defines ARM64 specific ACPI bindings to
configure and set-up arch specific components. To simplify
code reviews/updates and streamline the maintainership structure
supporting the arch specific code, a new arm64 directory was created in
/drivers/acpi, to contain ACPI code that is specific to ARM64
architecture.

Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
the newly created subdirectory and respective code content.

Lorenzo Pieralisi will be in charge of submitting and managing
the pull requests on behalf of all maintainers listed.

Signed-off-by: Lorenzo Pieralisi 
Cc: Hanjun Guo 
Cc: Sudeep Holla 
Cc: "Rafael J. Wysocki" 
Link: http://lkml.kernel.org/r/1603704.egivtcc...@vostro.rjw.lan


Acked-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH] MAINTAINERS: Add ARM64-specific ACPI maintainers entry

[Hanjun Guo]

On 10/05/2016 07:25 PM, Lorenzo Pieralisi wrote:

The ARM64 architecture defines ARM64 specific ACPI bindings to
configure and set-up arch specific components. To simplify
code reviews/updates and streamline the maintainership structure
supporting the arch specific code, a new arm64 directory was created in
/drivers/acpi, to contain ACPI code that is specific to ARM64
architecture.

Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
the newly created subdirectory and respective code content.

Lorenzo Pieralisi will be in charge of submitting and managing
the pull requests on behalf of all maintainers listed.

Signed-off-by: Lorenzo Pieralisi 
Cc: Hanjun Guo 
Cc: Sudeep Holla 
Cc: "Rafael J. Wysocki" 
Link: http://lkml.kernel.org/r/1603704.egivtcc...@vostro.rjw.lan


Acked-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency

[Joel Fernandes]

On Thu, Sep 29, 2016 at 1:18 AM, Chris Wilson  wrote:
> On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
>> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
>> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
>> awfully bad for STB. And the ftrace log also shows __free_vmap_area
>> contributes most latency now. I noticed that Joel mentioned the same
>> issue[1] on x86 platform and gave two solutions, but it seems no patch
>> is sent out for this purpose.
>>
>> This patch adopts Joel's first solution, but I use 16MB per core
>> rather than 8MB per core for the number of lazy_max_pages. After this
>> patch, the preemptoff tracer reports a max 6455us latency, reduced to
>> 1/4 of original result.
>
> My understanding is that
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e78c516..3f7c6d6969ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
>  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> int sync, int force_flush)
>  {
> -   static DEFINE_SPINLOCK(purge_lock);
> struct llist_node *valist;
> struct vmap_area *va;
> struct vmap_area *n_va;
> @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, 
> unsigned long *end,
>  * should not expect such behaviour. This just simplifies locking for
>  * the case that isn't actually used at the moment anyway.
>  */
> -   if (!sync && !force_flush) {
> -   if (!spin_trylock(_lock))
> -   return;
> -   } else
> -   spin_lock(_lock);
> -
> if (sync)
> purge_fragmented_blocks_allcpus();
>
> @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, 
> unsigned long *end,
> __free_vmap_area(va);
> spin_unlock(_area_lock);
> }
> -   spin_unlock(_lock);
>  }
>
[..]
> should now be safe. That should significantly reduce the preempt-disabled
> section, I think.

I believe that the purge_lock is supposed to prevent concurrent purges
from happening.

For the case where if you have another concurrent overflow happen in
alloc_vmap_area() between the spin_unlock and purge :

spin_unlock(_area_lock);
if (!purged)
   purge_vmap_area_lazy();

Then the 2 purges would happen at the same time and could subtract
vmap_lazy_nr twice.

I had proposed to change it to mutex in [1]. How do you feel about
that? Let me know your suggestions, thanks. I am also Ok with reducing
the lazy_max_pages value.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1603.2/04803.html

Regards,
Joel

Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency

[Joel Fernandes]

On Thu, Sep 29, 2016 at 1:18 AM, Chris Wilson  wrote:
> On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
>> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
>> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
>> awfully bad for STB. And the ftrace log also shows __free_vmap_area
>> contributes most latency now. I noticed that Joel mentioned the same
>> issue[1] on x86 platform and gave two solutions, but it seems no patch
>> is sent out for this purpose.
>>
>> This patch adopts Joel's first solution, but I use 16MB per core
>> rather than 8MB per core for the number of lazy_max_pages. After this
>> patch, the preemptoff tracer reports a max 6455us latency, reduced to
>> 1/4 of original result.
>
> My understanding is that
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e78c516..3f7c6d6969ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
>  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> int sync, int force_flush)
>  {
> -   static DEFINE_SPINLOCK(purge_lock);
> struct llist_node *valist;
> struct vmap_area *va;
> struct vmap_area *n_va;
> @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, 
> unsigned long *end,
>  * should not expect such behaviour. This just simplifies locking for
>  * the case that isn't actually used at the moment anyway.
>  */
> -   if (!sync && !force_flush) {
> -   if (!spin_trylock(_lock))
> -   return;
> -   } else
> -   spin_lock(_lock);
> -
> if (sync)
> purge_fragmented_blocks_allcpus();
>
> @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, 
> unsigned long *end,
> __free_vmap_area(va);
> spin_unlock(_area_lock);
> }
> -   spin_unlock(_lock);
>  }
>
[..]
> should now be safe. That should significantly reduce the preempt-disabled
> section, I think.

I believe that the purge_lock is supposed to prevent concurrent purges
from happening.

For the case where if you have another concurrent overflow happen in
alloc_vmap_area() between the spin_unlock and purge :

spin_unlock(_area_lock);
if (!purged)
   purge_vmap_area_lazy();

Then the 2 purges would happen at the same time and could subtract
vmap_lazy_nr twice.

I had proposed to change it to mutex in [1]. How do you feel about
that? Let me know your suggestions, thanks. I am also Ok with reducing
the lazy_max_pages value.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1603.2/04803.html

Regards,
Joel

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

[Wanpeng Li]

2016-09-29 3:37 GMT+08:00 Matt Fleming :
> On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote:
>>
>> Which suggests we do something like the below (not compile tested or
>> anything, also I ran out of tea again).
>
> I'm away on FTO right now. I can test this when I return on Friday.
>
> Funnily enough, I now remember that I already sent a fix for the
> missing update_rq_clock() in post_init_entity_util_avg(), but didn't
> apply it when chasing this hackbench regression (oops),
>
>   https://lkml.kernel.org/r/20160921133813.31976-3-m...@codeblueprint.co.uk

The difference between this patch and Peterz's is your patch have a
delta since activate_task()->enqueue_task() does do update_rq_clock(),
so why don't have the delta will cause low cpu machines (4 or 8) to
regress against your another reply in this thread?

Regards,
Wanpeng Li

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

[Wanpeng Li]

2016-09-29 3:37 GMT+08:00 Matt Fleming :
> On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote:
>>
>> Which suggests we do something like the below (not compile tested or
>> anything, also I ran out of tea again).
>
> I'm away on FTO right now. I can test this when I return on Friday.
>
> Funnily enough, I now remember that I already sent a fix for the
> missing update_rq_clock() in post_init_entity_util_avg(), but didn't
> apply it when chasing this hackbench regression (oops),
>
>   https://lkml.kernel.org/r/20160921133813.31976-3-m...@codeblueprint.co.uk

The difference between this patch and Peterz's is your patch have a
delta since activate_task()->enqueue_task() does do update_rq_clock(),
so why don't have the delta will cause low cpu machines (4 or 8) to
regress against your another reply in this thread?

Regards,
Wanpeng Li

[driver core] bea5b158ff: BUG: unable to handle kernel NULL pointer dereference at 00000008

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
AuthorDate: Thu Aug 11 10:20:58 2016 -0500
Commit: Greg Kroah-Hartman 
CommitDate: Wed Aug 31 15:13:55 2016 +0200

driver core: add test of driver remove calls during probe

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 

+--++++
|  | cebf8fd169 | bea5b158ff | 
22341813e4 |
+--++++
| boot_successes   | 66 | 2  | 0
  |
| boot_failures| 0  | 25 | 13   
  |
| calltrace:init   | 0  | 25 | 13   
  |
| Oops | 0  | 25 | 13   
  |
| EIP_is_at_cmos_alarm_irq_enable  | 0  | 10 |  
  |
| calltrace:rtc_timer_do_work  | 0  | 10 |  
  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 25 | 13   
  |
| BUG:unable_to_handle_kernel  | 0  | 24 | 13   
  |
| EIP_is_at_kobject_get| 0  | 14 | 10   
  |
| WARNING:at_lib/kobject.c:#kobject_get| 0  | 1  | 3
  |
| WARNING:at_include/linux/kref.h:#kobject_get | 0  | 1  | 3
  |
| EIP_is_at_kernfs_link_sibling| 0  | 1  |  
  |
| EIP_is_at_rb_next| 0  | 0  | 3
  |
| calltrace:SyS_getdents64 | 0  | 0  | 3
  |
+--++++

[   13.513705] hub 1-0:1.0: 1 port detected
[   13.516309] kobject (8f92f8b4): tried to init an initialized object, 
something is seriously wrong.
[   13.518358] CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-rc4-3-gbea5b15 
#1
[   13.520014] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   13.522207]  8f92f8b4 8f92f8b4 80031d20 88bb56c9 80031d3c 88bb7dd3 898316d4 
8f92f8b4
[   13.524132]  8f92f868 899b8c6c 8f92f8ac 80031d4c 88d83cce 8f92f868 8f92f8ac 
80031d58
[   13.526087]  88d844bb 8f92f868 80031d84 88ef3c1d  89863eac  
8004f760
[   13.527980] Call Trace:
[   13.528540]  [<88bb56c9>] dump_stack+0x16/0x1d
[   13.529544]  [<88bb7dd3>] kobject_init+0x73/0x80
[   13.530602]  [<88d83cce>] device_initialize+0x1e/0xe0
[   13.531889]  [<88d844bb>] device_register+0xb/0x20
[   13.532997]  [<88ef3c1d>] usb_add_gadget_udc_release+0x8d/0x270
[   13.534333]  [<88ef3e9a>] usb_add_gadget_udc+0xa/0x10
[   13.535465]  [<88ef775e>] dummy_udc_probe+0x14e/0x1a0
[   13.536623]  [<88d89781>] platform_drv_probe+0x31/0x90
[   13.537830]  [<88d875aa>] ? driver_sysfs_add+0x6a/0x90
[   13.539014]  [<88d87e3a>] driver_probe_device+0x12a/0x490
[   13.540228]  [<88cbc39b>] ? acpi_driver_match_device+0x36/0x50
[   13.541658]  [<88d88307>] __device_attach_driver+0x77/0x110
[   13.542946]  [<8949712d>] ? klist_next+0x6d/0x10c
[   13.544053]  [<88d88290>] ? __driver_attach+0xf0/0xf0
[   13.545180]  [<88d864f7>] bus_for_each_drv+0x47/0x80
[   13.549626]  [<88d87b85>] __device_attach+0xb5/0x130
[   13.550493]  [<88d88290>] ? __driver_attach+0xf0/0xf0
[   13.551517]  [<88d883cd>] device_initial_probe+0xd/0x10
[   13.552485]  [<88d86787>] bus_probe_device+0x77/0x80
[   13.553298]  [<88d8417e>] device_add+0x34e/0x5a0
[   13.554025]  [<88bc4840>] ? kvasprintf_const+0x40/0x90
[   13.554860]  [<88bb7d1b>] ? kobject_set_name_vargs+0x6b/0x90
[   13.555770]  [<88d89e6c>] platform_device_add+0xfc/0x280
[   13.556640]  [<89ad0b84>] init+0x20b/0x2ec
[   13.557317]  [<89ad0979>] ? usb_udc_init+0x3f/0x3f
[   13.558154]  [<89a96c1d>] do_one_initcall+0x7c/0xfb
[   13.558947]  [<89a96d5e>] ? kernel_init_freeable+0xc2/0x15e
[   13.559851]  [<89a96d81>] kernel_init_freeable+0xe5/0x15e
[   13.560726]  [<894974fb>] kernel_init+0xb/0x100
[   13.561705]  [<888c727c>] ? schedule_tail+0xc/0x50
[   13.562786]  [<894a1942>] ret_from_kernel_thread+0xe/0x24
[   13.563993]  

[driver core] bea5b158ff: BUG: unable to handle kernel NULL pointer dereference at 00000008

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
AuthorDate: Thu Aug 11 10:20:58 2016 -0500
Commit: Greg Kroah-Hartman 
CommitDate: Wed Aug 31 15:13:55 2016 +0200

driver core: add test of driver remove calls during probe

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 

+--++++
|  | cebf8fd169 | bea5b158ff | 
22341813e4 |
+--++++
| boot_successes   | 66 | 2  | 0
  |
| boot_failures| 0  | 25 | 13   
  |
| calltrace:init   | 0  | 25 | 13   
  |
| Oops | 0  | 25 | 13   
  |
| EIP_is_at_cmos_alarm_irq_enable  | 0  | 10 |  
  |
| calltrace:rtc_timer_do_work  | 0  | 10 |  
  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 25 | 13   
  |
| BUG:unable_to_handle_kernel  | 0  | 24 | 13   
  |
| EIP_is_at_kobject_get| 0  | 14 | 10   
  |
| WARNING:at_lib/kobject.c:#kobject_get| 0  | 1  | 3
  |
| WARNING:at_include/linux/kref.h:#kobject_get | 0  | 1  | 3
  |
| EIP_is_at_kernfs_link_sibling| 0  | 1  |  
  |
| EIP_is_at_rb_next| 0  | 0  | 3
  |
| calltrace:SyS_getdents64 | 0  | 0  | 3
  |
+--++++

[   13.513705] hub 1-0:1.0: 1 port detected
[   13.516309] kobject (8f92f8b4): tried to init an initialized object, 
something is seriously wrong.
[   13.518358] CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-rc4-3-gbea5b15 
#1
[   13.520014] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   13.522207]  8f92f8b4 8f92f8b4 80031d20 88bb56c9 80031d3c 88bb7dd3 898316d4 
8f92f8b4
[   13.524132]  8f92f868 899b8c6c 8f92f8ac 80031d4c 88d83cce 8f92f868 8f92f8ac 
80031d58
[   13.526087]  88d844bb 8f92f868 80031d84 88ef3c1d  89863eac  
8004f760
[   13.527980] Call Trace:
[   13.528540]  [<88bb56c9>] dump_stack+0x16/0x1d
[   13.529544]  [<88bb7dd3>] kobject_init+0x73/0x80
[   13.530602]  [<88d83cce>] device_initialize+0x1e/0xe0
[   13.531889]  [<88d844bb>] device_register+0xb/0x20
[   13.532997]  [<88ef3c1d>] usb_add_gadget_udc_release+0x8d/0x270
[   13.534333]  [<88ef3e9a>] usb_add_gadget_udc+0xa/0x10
[   13.535465]  [<88ef775e>] dummy_udc_probe+0x14e/0x1a0
[   13.536623]  [<88d89781>] platform_drv_probe+0x31/0x90
[   13.537830]  [<88d875aa>] ? driver_sysfs_add+0x6a/0x90
[   13.539014]  [<88d87e3a>] driver_probe_device+0x12a/0x490
[   13.540228]  [<88cbc39b>] ? acpi_driver_match_device+0x36/0x50
[   13.541658]  [<88d88307>] __device_attach_driver+0x77/0x110
[   13.542946]  [<8949712d>] ? klist_next+0x6d/0x10c
[   13.544053]  [<88d88290>] ? __driver_attach+0xf0/0xf0
[   13.545180]  [<88d864f7>] bus_for_each_drv+0x47/0x80
[   13.549626]  [<88d87b85>] __device_attach+0xb5/0x130
[   13.550493]  [<88d88290>] ? __driver_attach+0xf0/0xf0
[   13.551517]  [<88d883cd>] device_initial_probe+0xd/0x10
[   13.552485]  [<88d86787>] bus_probe_device+0x77/0x80
[   13.553298]  [<88d8417e>] device_add+0x34e/0x5a0
[   13.554025]  [<88bc4840>] ? kvasprintf_const+0x40/0x90
[   13.554860]  [<88bb7d1b>] ? kobject_set_name_vargs+0x6b/0x90
[   13.555770]  [<88d89e6c>] platform_device_add+0xfc/0x280
[   13.556640]  [<89ad0b84>] init+0x20b/0x2ec
[   13.557317]  [<89ad0979>] ? usb_udc_init+0x3f/0x3f
[   13.558154]  [<89a96c1d>] do_one_initcall+0x7c/0xfb
[   13.558947]  [<89a96d5e>] ? kernel_init_freeable+0xc2/0x15e
[   13.559851]  [<89a96d81>] kernel_init_freeable+0xe5/0x15e
[   13.560726]  [<894974fb>] kernel_init+0xb/0x100
[   13.561705]  [<888c727c>] ? schedule_tail+0xc/0x50
[   13.562786]  [<894a1942>] ret_from_kernel_thread+0xe/0x24
[   13.563993]  [<894974f0>] ? rest_init+0x110/0x110
[   13.566155] usbip_core: USB/IP Core v1.0.0
[   13.567699] i8042: PNP: PS/2 Controller 

RE: [PATCH v6 3/3] pci:add support aer/pme interrupts with none MSI/MSI-X/INTx mode

[Po Liu]

Hi Rob,

Best regards,
Liu Po

>  -Original Message-
>  From: Rob Herring [mailto:r...@kernel.org]
>  Sent: Sunday, October 09, 2016 4:50 AM
>  To: Po Liu
>  Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>  linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Bjorn Helgaas;
>  Shawn Guo; Marc Zyngier; Roy Zang; Mingkai Hu; Stuart Yoder; Leo Li;
>  Arnd Bergmann; M.H. Lian; Murali Karicheri
>  Subject: Re: [PATCH v6 3/3] pci:add support aer/pme interrupts with none
>  MSI/MSI-X/INTx mode
>  
>  On Fri, Sep 30, 2016 at 05:11:37PM +0800, Po Liu wrote:
>  > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
>  > When chip support the aer/pme interrupts with none MSI/MSI-X/INTx
>  > mode, maybe there is interrupt line for aer pme etc. Search the
>  > interrupt number in the fdt file. Then fixup the dev->irq with it.
>  
>  Again, explain why you are breaking compatibility. Will an old dtb using
>  "intr" still work with this change? It should normally. There are some
>  exceptions, but you need to say what they are.
>  
Ok, understand.

>  >
>  > Signed-off-by: Po Liu 
>  > ---
>  > changes for v6:
>  >- modify bindings for "aer""pme";
>  >- changing to the hood method to implement the aer pme interrupt;
>  >- add pme interrupt in the same way;
>  >
>  >  .../devicetree/bindings/pci/layerscape-pci.txt | 13 +--
>  >  arch/arm/kernel/bios32.c   | 43
>  ++
>  >  arch/arm64/kernel/pci.c| 43
>  ++
>  >  drivers/pci/pcie/portdrv_core.c| 31
>  +++-
>  >  include/linux/pci.h|  1 +
>  >  5 files changed, 126 insertions(+), 5 deletions(-)
>  >
>  > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > index 41e9f55..51ed49e 100644
>  > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > @@ -18,8 +18,12 @@ Required properties:
>  >  - reg: base addresses and lengths of the PCIe controller
>  >  - interrupts: A list of interrupt outputs of the controller. Must
>  contain an
>  >entry for each entry in the interrupt-names property.
>  > -- interrupt-names: Must include the following entries:
>  > -  "intr": The interrupt that is asserted for controller interrupts
>  > +- interrupt-names: It could include the following entries:
>  
>  "Could" is not strong enough. Every valid combination of interrupts
>  should correspond to a specific compatible string. A given version of
>  h/w either has these interrupts or not.

Ok, will change to 'must'.

>  
>  > +  "aer": Asserted for aer interrupt when chip support the aer
>  interrupt with
>  > +   none MSI/MSI-X/INTx mode,but there is interrupt line for
>  aer.
>  > +  "pme": Asserted for pme interrupt when chip support the pme
>  interrupt with
>  > +   none MSI/MSI-X/INTx mode,but there is interrupt line for
>  pme.
>  > +  ..
>  >  - fsl,pcie-scfg: Must include two entries.
>  >The first entry must be a link to the SCFG device node
>  >The second entry must be '0' or '1' based on physical PCIe
>  controller index.

RE: [PATCH v6 3/3] pci:add support aer/pme interrupts with none MSI/MSI-X/INTx mode

[Po Liu]

Hi Rob,

Best regards,
Liu Po

>  -Original Message-
>  From: Rob Herring [mailto:r...@kernel.org]
>  Sent: Sunday, October 09, 2016 4:50 AM
>  To: Po Liu
>  Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>  linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Bjorn Helgaas;
>  Shawn Guo; Marc Zyngier; Roy Zang; Mingkai Hu; Stuart Yoder; Leo Li;
>  Arnd Bergmann; M.H. Lian; Murali Karicheri
>  Subject: Re: [PATCH v6 3/3] pci:add support aer/pme interrupts with none
>  MSI/MSI-X/INTx mode
>  
>  On Fri, Sep 30, 2016 at 05:11:37PM +0800, Po Liu wrote:
>  > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
>  > When chip support the aer/pme interrupts with none MSI/MSI-X/INTx
>  > mode, maybe there is interrupt line for aer pme etc. Search the
>  > interrupt number in the fdt file. Then fixup the dev->irq with it.
>  
>  Again, explain why you are breaking compatibility. Will an old dtb using
>  "intr" still work with this change? It should normally. There are some
>  exceptions, but you need to say what they are.
>  
Ok, understand.

>  >
>  > Signed-off-by: Po Liu 
>  > ---
>  > changes for v6:
>  >- modify bindings for "aer""pme";
>  >- changing to the hood method to implement the aer pme interrupt;
>  >- add pme interrupt in the same way;
>  >
>  >  .../devicetree/bindings/pci/layerscape-pci.txt | 13 +--
>  >  arch/arm/kernel/bios32.c   | 43
>  ++
>  >  arch/arm64/kernel/pci.c| 43
>  ++
>  >  drivers/pci/pcie/portdrv_core.c| 31
>  +++-
>  >  include/linux/pci.h|  1 +
>  >  5 files changed, 126 insertions(+), 5 deletions(-)
>  >
>  > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > index 41e9f55..51ed49e 100644
>  > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > @@ -18,8 +18,12 @@ Required properties:
>  >  - reg: base addresses and lengths of the PCIe controller
>  >  - interrupts: A list of interrupt outputs of the controller. Must
>  contain an
>  >entry for each entry in the interrupt-names property.
>  > -- interrupt-names: Must include the following entries:
>  > -  "intr": The interrupt that is asserted for controller interrupts
>  > +- interrupt-names: It could include the following entries:
>  
>  "Could" is not strong enough. Every valid combination of interrupts
>  should correspond to a specific compatible string. A given version of
>  h/w either has these interrupts or not.

Ok, will change to 'must'.

>  
>  > +  "aer": Asserted for aer interrupt when chip support the aer
>  interrupt with
>  > +   none MSI/MSI-X/INTx mode,but there is interrupt line for
>  aer.
>  > +  "pme": Asserted for pme interrupt when chip support the pme
>  interrupt with
>  > +   none MSI/MSI-X/INTx mode,but there is interrupt line for
>  pme.
>  > +  ..
>  >  - fsl,pcie-scfg: Must include two entries.
>  >The first entry must be a link to the SCFG device node
>  >The second entry must be '0' or '1' based on physical PCIe
>  controller index.

[PATCH v2 1/2] ls1043ardb: add qe node to ls1043ardb

[Zhao Qiang]

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- use "fsl,ucc-hdlc" directly

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4084631..a6a39fc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -124,6 +124,22 @@
};
 };
 
+ {
+   ucc_hdlc: ucc@2000 {
+   compatible = "fsl,ucc-hdlc";
+   rx-clock-name = "clk8";
+   tx-clock-name = "clk9";
+   fsl,rx-sync-clock = "rsync_pin";
+   fsl,tx-sync-clock = "tsync_pin";
+   fsl,tx-timeslot-mask = <0xfffe>;
+   fsl,rx-timeslot-mask = <0xfffe>;
+   fsl,tdm-framer-type = "e1";
+   fsl,tdm-id = <0>;
+   fsl,siram-entry-id = <0>;
+   fsl,tdm-interface;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..f6b6775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -388,6 +388,72 @@
#interrupt-cells = <2>;
};
 
+   uqe: uqe@240 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "qe";
+   compatible = "fsl,qe", "simple-bus";
+   ranges = <0x0 0x0 0x240 0x4>;
+   reg = <0x0 0x240 0x0 0x480>;
+   brg-frequency = <1>;
+   bus-frequency = <2>;
+
+   fsl,qe-num-riscs = <1>;
+   fsl,qe-num-snums = <28>;
+
+   qeic: qeic@80 {
+   compatible = "fsl,qe-ic";
+   reg = <0x80 0x80>;
+   #address-cells = <0>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   interrupts = <0 77 0x04 0 77 0x04>;
+   };
+
+   si1: si@700 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,ls1043-qe-si",
+   "fsl,t1040-qe-si";
+   reg = <0x700 0x80>;
+   };
+
+   siram1: siram@1000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,ls1043-qe-siram",
+   "fsl,t1040-qe-siram";
+   reg = <0x1000 0x800>;
+   };
+
+   ucc@2000 {
+   cell-index = <1>;
+   reg = <0x2000 0x200>;
+   interrupts = <32>;
+   interrupt-parent = <>;
+   };
+
+   ucc@2200 {
+   cell-index = <3>;
+   reg = <0x2200 0x200>;
+   interrupts = <34>;
+   interrupt-parent = <>;
+   };
+
+   muram@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,qe-muram", "fsl,cpm-muram";
+   ranges = <0x0 0x1 0x6000>;
+
+   data-only@0 {
+   compatible = "fsl,qe-muram-data",
+   "fsl,cpm-muram-data";
+   reg = <0x0 0x6000>;
+   };
+   };
+   };
+
lpuart0: serial@295 {
compatible = "fsl,ls1021a-lpuart";
reg = <0x0 0x295 0x0 0x1000>;
-- 
2.1.0.27.g96db324

[PATCH v2 1/2] ls1043ardb: add qe node to ls1043ardb

[Zhao Qiang]

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- use "fsl,ucc-hdlc" directly

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4084631..a6a39fc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -124,6 +124,22 @@
};
 };
 
+ {
+   ucc_hdlc: ucc@2000 {
+   compatible = "fsl,ucc-hdlc";
+   rx-clock-name = "clk8";
+   tx-clock-name = "clk9";
+   fsl,rx-sync-clock = "rsync_pin";
+   fsl,tx-sync-clock = "tsync_pin";
+   fsl,tx-timeslot-mask = <0xfffe>;
+   fsl,rx-timeslot-mask = <0xfffe>;
+   fsl,tdm-framer-type = "e1";
+   fsl,tdm-id = <0>;
+   fsl,siram-entry-id = <0>;
+   fsl,tdm-interface;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..f6b6775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -388,6 +388,72 @@
#interrupt-cells = <2>;
};
 
+   uqe: uqe@240 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   device_type = "qe";
+   compatible = "fsl,qe", "simple-bus";
+   ranges = <0x0 0x0 0x240 0x4>;
+   reg = <0x0 0x240 0x0 0x480>;
+   brg-frequency = <1>;
+   bus-frequency = <2>;
+
+   fsl,qe-num-riscs = <1>;
+   fsl,qe-num-snums = <28>;
+
+   qeic: qeic@80 {
+   compatible = "fsl,qe-ic";
+   reg = <0x80 0x80>;
+   #address-cells = <0>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   interrupts = <0 77 0x04 0 77 0x04>;
+   };
+
+   si1: si@700 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,ls1043-qe-si",
+   "fsl,t1040-qe-si";
+   reg = <0x700 0x80>;
+   };
+
+   siram1: siram@1000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,ls1043-qe-siram",
+   "fsl,t1040-qe-siram";
+   reg = <0x1000 0x800>;
+   };
+
+   ucc@2000 {
+   cell-index = <1>;
+   reg = <0x2000 0x200>;
+   interrupts = <32>;
+   interrupt-parent = <>;
+   };
+
+   ucc@2200 {
+   cell-index = <3>;
+   reg = <0x2200 0x200>;
+   interrupts = <34>;
+   interrupt-parent = <>;
+   };
+
+   muram@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,qe-muram", "fsl,cpm-muram";
+   ranges = <0x0 0x1 0x6000>;
+
+   data-only@0 {
+   compatible = "fsl,qe-muram-data",
+   "fsl,cpm-muram-data";
+   reg = <0x0 0x6000>;
+   };
+   };
+   };
+
lpuart0: serial@295 {
compatible = "fsl,ls1021a-lpuart";
reg = <0x0 0x295 0x0 0x1000>;
-- 
2.1.0.27.g96db324

Re: [PATCH 3/3] dt-bindings: oxnas: Update Pinctrl and GPIO for OX820 Support

[Rob Herring]

On Tue, Oct 04, 2016 at 03:41:48PM +0200, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/gpio/gpio_oxnas.txt   | 2 +-
>  Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt 
> b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> index 928ed4f..9665147 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> @@ -3,7 +3,7 @@
>  Please refer to gpio.txt for generic information regarding GPIO bindings.
>  
>  Required properties:
> - - compatible: "oxsemi,ox810se-gpio"
> + - compatible: "oxsemi,ox810se-gpio" or "oxsemi,ox820-gpio"

It is preferred to have one per line, but it's fine unless you respin 
the series.

Acked-by: Rob Herring 

Re: [PATCH 3/3] dt-bindings: oxnas: Update Pinctrl and GPIO for OX820 Support

[Rob Herring]

On Tue, Oct 04, 2016 at 03:41:48PM +0200, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/gpio/gpio_oxnas.txt   | 2 +-
>  Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt 
> b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> index 928ed4f..9665147 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
> @@ -3,7 +3,7 @@
>  Please refer to gpio.txt for generic information regarding GPIO bindings.
>  
>  Required properties:
> - - compatible: "oxsemi,ox810se-gpio"
> + - compatible: "oxsemi,ox810se-gpio" or "oxsemi,ox820-gpio"

It is preferred to have one per line, but it's fine unless you respin 
the series.

Acked-by: Rob Herring 

drivers/net/ethernet/qualcomm/emac/emac.c:727:3: error: implicit declaration of function 'iounmap'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b66484cd74706fa8681d051840fe4b18a3da40ff
commit: 54e19bc74f3380d414681762ceed9f7245bc6a6e net: qcom/emac: do not use 
devm on internal phy pdev
date:   10 days ago
config: um-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 54e19bc74f3380d414681762ceed9f7245bc6a6e
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/qualcomm/emac/emac.c: In function 'emac_remove':
>> drivers/net/ethernet/qualcomm/emac/emac.c:727:3: error: implicit declaration 
>> of function 'iounmap' [-Werror=implicit-function-declaration]
  iounmap(adpt->phy.digital);
  ^~~
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:test_and_set_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/workqueue.h:queue_work
   Cyclomatic Complexity 1 include/linux/workqueue.h:schedule_work
   Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/asm-generic/io.h:__raw_readl
   Cyclomatic Complexity 1 include/asm-generic/io.h:__raw_writel
   Cyclomatic Complexity 1 include/asm-generic/io.h:readl
   Cyclomatic Complexity 1 include/asm-generic/io.h:writel
   Cyclomatic Complexity 1 include/linux/dma-mapping.h:get_dma_ops
   Cyclomatic Complexity 3 include/linux/dma-mapping.h:dma_supported
   Cyclomatic Complexity 4 include/linux/dma-mapping.h:dma_set_mask
   Cyclomatic Complexity 2 include/linux/dma-mapping.h:dma_set_coherent_mask
   Cyclomatic Complexity 2 include/linux/dma-mapping.h:dma_set_mask_and_coherent
   Cyclomatic Complexity 1 include/linux/netdevice.h:napi_disable_pending
   Cyclomatic Complexity 3 include/linux/netdevice.h:napi_schedule_prep
   Cyclomatic Complexity 1 include/linux/netdevice.h:napi_complete
   Cyclomatic Complexity 1 include/linux/netdevice.h:netdev_priv
   Cyclomatic Complexity 1 include/linux/netdevice.h:netif_running
   Cyclomatic Complexity 1 include/linux/etherdevice.h:eth_random_addr
   Cyclomatic Complexity 1 include/linux/etherdevice.h:eth_hw_addr_random
   Cyclomatic Complexity 1 include/linux/etherdevice.h:ether_addr_copy
   Cyclomatic Complexity 1 include/linux/clk.h:clk_prepare
   Cyclomatic Complexity 1 include/linux/clk.h:clk_unprepare
   Cyclomatic Complexity 1 include/linux/clk.h:devm_clk_get
   Cyclomatic Complexity 1 include/linux/clk.h:clk_enable
   Cyclomatic Complexity 1 include/linux/clk.h:clk_disable
   Cyclomatic Complexity 1 include/linux/clk.h:clk_set_rate
   Cyclomatic Complexity 3 include/linux/clk.h:clk_prepare_enable
   Cyclomatic Complexity 1 include/linux/clk.h:clk_disable_unprepare
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_tx_timeout
   Cyclomatic Complexity 3 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_get_stats64
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_init_adapter
   Cyclomatic Complexity 7 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_phase2_init
   Cyclomatic Complexity 2 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_teardown
   Cyclomatic Complexity 2 drivers/net/ethernet/qualcomm/emac/emac.c:emac_remove
   Cyclomatic Complexity 3 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_get
   Cyclomatic Complexity 5 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_phase1_init
   Cyclomatic Complexity 2 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_napi_rtx
   Cyclomatic Complexity 3 drivers/net/ethernet/qualcomm/emac/emac.c:emac_ioctl
   Cyclomatic Complexity 2 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_rx_mode_set
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_start_xmit
   Cyclomatic Complexity 1 drivers/net/ethernet/qualcomm/emac/emac.c:emac_close
   Cyclomatic Complexity 3 drivers/net/ethernet/qualcomm/emac/emac.c:emac_open
   Cyclomatic Complexity 5 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_probe_resources
   Cyclomatic Complexity 11 drivers/net/ethernet/qualcomm/emac/emac.c:emac_probe
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_reg_update32
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_reinit_locked
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_work_thread
   Cyclomatic Complexity 3 

drivers/net/ethernet/qualcomm/emac/emac.c:727:3: error: implicit declaration of function 'iounmap'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b66484cd74706fa8681d051840fe4b18a3da40ff
commit: 54e19bc74f3380d414681762ceed9f7245bc6a6e net: qcom/emac: do not use 
devm on internal phy pdev
date:   10 days ago
config: um-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 54e19bc74f3380d414681762ceed9f7245bc6a6e
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/qualcomm/emac/emac.c: In function 'emac_remove':
>> drivers/net/ethernet/qualcomm/emac/emac.c:727:3: error: implicit declaration 
>> of function 'iounmap' [-Werror=implicit-function-declaration]
  iounmap(adpt->phy.digital);
  ^~~
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:test_and_set_bit
   Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/workqueue.h:queue_work
   Cyclomatic Complexity 1 include/linux/workqueue.h:schedule_work
   Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/asm-generic/io.h:__raw_readl
   Cyclomatic Complexity 1 include/asm-generic/io.h:__raw_writel
   Cyclomatic Complexity 1 include/asm-generic/io.h:readl
   Cyclomatic Complexity 1 include/asm-generic/io.h:writel
   Cyclomatic Complexity 1 include/linux/dma-mapping.h:get_dma_ops
   Cyclomatic Complexity 3 include/linux/dma-mapping.h:dma_supported
   Cyclomatic Complexity 4 include/linux/dma-mapping.h:dma_set_mask
   Cyclomatic Complexity 2 include/linux/dma-mapping.h:dma_set_coherent_mask
   Cyclomatic Complexity 2 include/linux/dma-mapping.h:dma_set_mask_and_coherent
   Cyclomatic Complexity 1 include/linux/netdevice.h:napi_disable_pending
   Cyclomatic Complexity 3 include/linux/netdevice.h:napi_schedule_prep
   Cyclomatic Complexity 1 include/linux/netdevice.h:napi_complete
   Cyclomatic Complexity 1 include/linux/netdevice.h:netdev_priv
   Cyclomatic Complexity 1 include/linux/netdevice.h:netif_running
   Cyclomatic Complexity 1 include/linux/etherdevice.h:eth_random_addr
   Cyclomatic Complexity 1 include/linux/etherdevice.h:eth_hw_addr_random
   Cyclomatic Complexity 1 include/linux/etherdevice.h:ether_addr_copy
   Cyclomatic Complexity 1 include/linux/clk.h:clk_prepare
   Cyclomatic Complexity 1 include/linux/clk.h:clk_unprepare
   Cyclomatic Complexity 1 include/linux/clk.h:devm_clk_get
   Cyclomatic Complexity 1 include/linux/clk.h:clk_enable
   Cyclomatic Complexity 1 include/linux/clk.h:clk_disable
   Cyclomatic Complexity 1 include/linux/clk.h:clk_set_rate
   Cyclomatic Complexity 3 include/linux/clk.h:clk_prepare_enable
   Cyclomatic Complexity 1 include/linux/clk.h:clk_disable_unprepare
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_tx_timeout
   Cyclomatic Complexity 3 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_get_stats64
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_init_adapter
   Cyclomatic Complexity 7 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_phase2_init
   Cyclomatic Complexity 2 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_teardown
   Cyclomatic Complexity 2 drivers/net/ethernet/qualcomm/emac/emac.c:emac_remove
   Cyclomatic Complexity 3 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_get
   Cyclomatic Complexity 5 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_clks_phase1_init
   Cyclomatic Complexity 2 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_napi_rtx
   Cyclomatic Complexity 3 drivers/net/ethernet/qualcomm/emac/emac.c:emac_ioctl
   Cyclomatic Complexity 2 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_rx_mode_set
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_start_xmit
   Cyclomatic Complexity 1 drivers/net/ethernet/qualcomm/emac/emac.c:emac_close
   Cyclomatic Complexity 3 drivers/net/ethernet/qualcomm/emac/emac.c:emac_open
   Cyclomatic Complexity 5 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_probe_resources
   Cyclomatic Complexity 11 drivers/net/ethernet/qualcomm/emac/emac.c:emac_probe
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_reg_update32
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_reinit_locked
   Cyclomatic Complexity 1 
drivers/net/ethernet/qualcomm/emac/emac.c:emac_work_thread
   Cyclomatic Complexity 3 

[PATCH v2 2/2] ls1043ardb: add ds26522 node to dts

[Zhao Qiang]

add ds26522 node to fsl-ls1043a-rdb.dts

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- na

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index a6a39fc..7f93bcc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -122,6 +122,22 @@
reg = <0>;
spi-max-frequency = <100>; /* input clock */
};
+
+   slic@2 {
+   compatible = "maxim,ds26522";
+   reg = <2>;
+   spi-max-frequency = <200>;
+   fsl,spi-cs-sck-delay = <100>;
+   fsl,spi-sck-cs-delay = <50>;
+   };
+
+   slic@3 {
+   compatible = "maxim,ds26522";
+   reg = <3>;
+   spi-max-frequency = <200>;
+   fsl,spi-cs-sck-delay = <100>;
+   fsl,spi-sck-cs-delay = <50>;
+   };
 };
 
  {
-- 
2.1.0.27.g96db324

[PATCH v2 2/2] ls1043ardb: add ds26522 node to dts

[Zhao Qiang]

add ds26522 node to fsl-ls1043a-rdb.dts

Signed-off-by: Zhao Qiang 
---
Changes for v2:
- na

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index a6a39fc..7f93bcc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -122,6 +122,22 @@
reg = <0>;
spi-max-frequency = <100>; /* input clock */
};
+
+   slic@2 {
+   compatible = "maxim,ds26522";
+   reg = <2>;
+   spi-max-frequency = <200>;
+   fsl,spi-cs-sck-delay = <100>;
+   fsl,spi-sck-cs-delay = <50>;
+   };
+
+   slic@3 {
+   compatible = "maxim,ds26522";
+   reg = <3>;
+   spi-max-frequency = <200>;
+   fsl,spi-cs-sck-delay = <100>;
+   fsl,spi-sck-cs-delay = <50>;
+   };
 };
 
  {
-- 
2.1.0.27.g96db324

Re: [PATCH] crypto: caam: add support for iMX6UL

[Rob Herring]

On Tue, Oct 04, 2016 at 09:32:59AM -0400, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
> 
> Signed-off-by: Marcus Folkesson 
> ---
>  .../devicetree/bindings/crypto/fsl-sec4.txt| 20 +

Acked-by: Rob Herring 

>  drivers/crypto/caam/ctrl.c | 35 
> --
>  2 files changed, 40 insertions(+), 15 deletions(-)

Re: [PATCH] crypto: caam: add support for iMX6UL

[Rob Herring]

On Tue, Oct 04, 2016 at 09:32:59AM -0400, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
> 
> Signed-off-by: Marcus Folkesson 
> ---
>  .../devicetree/bindings/crypto/fsl-sec4.txt| 20 +

Acked-by: Rob Herring 

>  drivers/crypto/caam/ctrl.c | 35 
> --
>  2 files changed, 40 insertions(+), 15 deletions(-)

Re: [PATCH RFC 1/3] tpm_crb: expand struct crb_control_area to struct crb_regs

[Jason Gunthorpe]

On Sun, Oct 09, 2016 at 03:15:09AM +0300, Jarkko Sakkinen wrote:
> + ctrl = crb_map_res(dev, priv, _res, buf->control_address,
> +sizeof(struct crb_regs) -
> +offsetof(struct crb_regs, ctrl_req));
> + if (IS_ERR(ctrl))
> + return PTR_ERR(ctrl);
> +
> + /* The control area always overrlaps IO memory mapped from the ACPI
> +  * object with CRB start only devices. Thus, this is perfectly safe.
> +  */
> + priv->regs = (void *)((unsigned long)ctrl -
> + offsetof(struct crb_regs, ctrl_req));

Hum. No, this makes bad assumptions about the structure of iomapping.

The map itself needs to be done with the adjustment:

ctrl = crb_map_res(dev, priv, _res, buf->control_address -
offsetof(struct crb_regs, ctrl_req),
sizeof(struct crb_regs));

.. and nothing actually proves that control_address follows anything
in the driver, so this seems like a terrifying blind assumption, but
everything about the iomap in this ACPI binding seems totally bonkers
so that is in good company I guess.

.. and the comment says this only holds for 'crb start only' devices,
but the code doesn't actually act differently based on what sort of
device we have..

Your commit message also seems to imply the new registers are only on
newer hardware, but nothing seems to check for that before acessing
them?  Confusing.

Jason

Re: [PATCH RFC 1/3] tpm_crb: expand struct crb_control_area to struct crb_regs

[Jason Gunthorpe]

On Sun, Oct 09, 2016 at 03:15:09AM +0300, Jarkko Sakkinen wrote:
> + ctrl = crb_map_res(dev, priv, _res, buf->control_address,
> +sizeof(struct crb_regs) -
> +offsetof(struct crb_regs, ctrl_req));
> + if (IS_ERR(ctrl))
> + return PTR_ERR(ctrl);
> +
> + /* The control area always overrlaps IO memory mapped from the ACPI
> +  * object with CRB start only devices. Thus, this is perfectly safe.
> +  */
> + priv->regs = (void *)((unsigned long)ctrl -
> + offsetof(struct crb_regs, ctrl_req));

Hum. No, this makes bad assumptions about the structure of iomapping.

The map itself needs to be done with the adjustment:

ctrl = crb_map_res(dev, priv, _res, buf->control_address -
offsetof(struct crb_regs, ctrl_req),
sizeof(struct crb_regs));

.. and nothing actually proves that control_address follows anything
in the driver, so this seems like a terrifying blind assumption, but
everything about the iomap in this ACPI binding seems totally bonkers
so that is in good company I guess.

.. and the comment says this only holds for 'crb start only' devices,
but the code doesn't actually act differently based on what sort of
device we have..

Your commit message also seems to imply the new registers are only on
newer hardware, but nothing seems to check for that before acessing
them?  Confusing.

Jason

Re: [PATCH v2 1/3] devicetree: bindings: scsi: hisi_sas add hip07 support

[Rob Herring]

On Tue, Oct 04, 2016 at 07:11:09PM +0800, John Garry wrote:
> Add support for hip07 chipset to hisi_sas controller.
> 
> Chipset hip07 has v2 hw.
> 
> Signed-off-by: John Garry 
> Signed-off-by: Xiang Chen 
> ---
>  Documentation/devicetree/bindings/scsi/hisilicon-sas.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2 1/3] devicetree: bindings: scsi: hisi_sas add hip07 support

[Rob Herring]

On Tue, Oct 04, 2016 at 07:11:09PM +0800, John Garry wrote:
> Add support for hip07 chipset to hisi_sas controller.
> 
> Chipset hip07 has v2 hw.
> 
> Signed-off-by: John Garry 
> Signed-off-by: Xiang Chen 
> ---
>  Documentation/devicetree/bindings/scsi/hisilicon-sas.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH] usb: xhci: add support for performing fake doorbell

[Rob Herring]

On Sat, Oct 01, 2016 at 11:58:10PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Broadcom's Northstar XHCI controllers seem to need a special start
> procedure to work correctly. There isn't any official documentation on
> this, the problem is that controller doesn't detect any connected
> devices with default setup. Moreover connecting USB device to controller
> that doesn't run properly can cause SoC's watchdog issues.
> 
> A workaround that was successfully tested on multiple devices is to
> perform a fake doorbell. This patch adds code for doing that and a DT
> binding enabling it.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt |  2 +
>  drivers/usb/host/xhci-plat.c   |  6 +++
>  drivers/usb/host/xhci.c| 63 
> --
>  drivers/usb/host/xhci.h|  1 +
>  4 files changed, 69 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 966885c..ce01b7f 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -26,6 +26,8 @@ Required properties:
>  Optional properties:
>- clocks: reference to a clock
>- usb3-lpm-capable: determines if platform is USB3 LPM capable
> +  - usb3-fake-doorbell: determines if controller requires a fake doorbell 
> when
> + starting it

You should use Northstar XHCI compatible string to enable this. Then the 
DT doesn't need updating.

Rob

Re: [PATCH v3] drm: tilcdc: add a da850-specific compatible string

[Rob Herring]

On Mon, Oct 03, 2016 at 05:45:19PM +0200, Bartosz Golaszewski wrote:
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
> 
> Suggested-by: Sekhar Nori 
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - added the new compatible to the bindings documentation
> 
> v2 -> v3:
> - made the documentation more detailed
> 
>  Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 6 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH] usb: xhci: add support for performing fake doorbell

[Rob Herring]

On Sat, Oct 01, 2016 at 11:58:10PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Broadcom's Northstar XHCI controllers seem to need a special start
> procedure to work correctly. There isn't any official documentation on
> this, the problem is that controller doesn't detect any connected
> devices with default setup. Moreover connecting USB device to controller
> that doesn't run properly can cause SoC's watchdog issues.
> 
> A workaround that was successfully tested on multiple devices is to
> perform a fake doorbell. This patch adds code for doing that and a DT
> binding enabling it.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt |  2 +
>  drivers/usb/host/xhci-plat.c   |  6 +++
>  drivers/usb/host/xhci.c| 63 
> --
>  drivers/usb/host/xhci.h|  1 +
>  4 files changed, 69 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 966885c..ce01b7f 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -26,6 +26,8 @@ Required properties:
>  Optional properties:
>- clocks: reference to a clock
>- usb3-lpm-capable: determines if platform is USB3 LPM capable
> +  - usb3-fake-doorbell: determines if controller requires a fake doorbell 
> when
> + starting it

You should use Northstar XHCI compatible string to enable this. Then the 
DT doesn't need updating.

Rob

Re: [PATCH v3] drm: tilcdc: add a da850-specific compatible string

[Rob Herring]

On Mon, Oct 03, 2016 at 05:45:19PM +0200, Bartosz Golaszewski wrote:
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
> 
> Suggested-by: Sekhar Nori 
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - added the new compatible to the bindings documentation
> 
> v2 -> v3:
> - made the documentation more detailed
> 
>  Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 6 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 1/8] PM / OPP: Reword binding supporting multiple regulators per device

[Rob Herring]

On Tue, Oct 04, 2016 at 05:26:43PM +0530, Viresh Kumar wrote:
> On certain platforms (like TI), DVFS for a single device (CPU) requires
> configuring multiple power supplies.
> 
> The OPP bindings already contains binding and example to explain this
> case, but it isn't sufficient. For example, there is no way for the code
> parsing these bindings to know which voltage values belong to which
> power supply. Also its not possible to know the order in which the
> supplies need to be configured while switching OPPs.
> 
> This patch tries to clarify on those details and does some minor changes
> as well.
> 
> Note that the bindings do not specify the order in which the regulators
> need to be programmed and the order in which the entries are added for
> the supplies.
> 
> The user of the bindings (like the kernel) shall know these details
> already and the DT is responsible to supply only the readings for the
> regulators.
> 
> Cc: Mark Brown 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 1/8] PM / OPP: Reword binding supporting multiple regulators per device

[Rob Herring]

On Tue, Oct 04, 2016 at 05:26:43PM +0530, Viresh Kumar wrote:
> On certain platforms (like TI), DVFS for a single device (CPU) requires
> configuring multiple power supplies.
> 
> The OPP bindings already contains binding and example to explain this
> case, but it isn't sufficient. For example, there is no way for the code
> parsing these bindings to know which voltage values belong to which
> power supply. Also its not possible to know the order in which the
> supplies need to be configured while switching OPPs.
> 
> This patch tries to clarify on those details and does some minor changes
> as well.
> 
> Note that the bindings do not specify the order in which the regulators
> need to be programmed and the order in which the entries are added for
> the supplies.
> 
> The user of the bindings (like the kernel) shall know these details
> already and the DT is responsible to supply only the readings for the
> regulators.
> 
> Cc: Mark Brown 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

[Rob Herring]

On Thu, Oct 06, 2016 at 08:47:13AM +0200, Robert Jarzmik wrote:
> Robert Jarzmik  writes:
> 
> > Mark Rutland  writes:
> >
> >> On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
> >>> Mark Rutland  writes:
> >>> 
> >>> reg-u16-align4 tells that a specific hardware doesn't support 16 bit 
> >>> writes not
> >>> being 32 bits aligned, or said differently that a "store" 16 bits wide on 
> >>> an
> >>> address of the format 4*n + 2 deserves a special handling in the driver, 
> >>> while a
> >>> store 16 bits wide on an address of the format 4*n can follow the simple 
> >>> casual
> >>> case.
> >>
> >> If I've understood correctly, effectively the low 2 address lines to the
> >> device are hard-wired to zero, e.g. a 16-bit access to 4*n + 2 would go
> >> to 4*n + 0 on the device? Or is the failure case distinct from that?
> > It is distinct.
> >
> > The "awful truth" is that an FPGA lies between the system bus and the
> > smc91c111. And this FPGA cannot handle correctly the 4*n + 2 u16 writes.
> >
> >> Do we have other platforms where similar is true? e.g. u8 accesses
> >> requiring 16-bit alignment?
> >
> > Not really, ie. not with a alignement requirement.
> >
> > But there are of course these ones are handled by reg-io-width and the
> > SMC_USE_xxx_BITS flags as far as I understand it. These cases are when a
> > platform declares SMC91X_USE_16BIT or SMC91X_USE_32BIT, but not 
> > SMC91X_USE_8BIT,
> > which would make me think of :
> >  - CONFIG_SH_SH4202_MICRODEV,
> >  - CONFIG_M32R
> >  - several omap1 boards
> >  - 1 sa1100 board
> >  - several MMP and realview boards
> >
> > With all these platforms, each u8 access is replaced with a u16 access and a
> > mask / shift + mask.
> 
> Or so what should I call this entry if reg-u16-align4 is not a good candidate 
> ?

This seems broken in a very platform specific way, so perhaps something 
named based on the platform.

Rob

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

[Rob Herring]

On Thu, Oct 06, 2016 at 08:47:13AM +0200, Robert Jarzmik wrote:
> Robert Jarzmik  writes:
> 
> > Mark Rutland  writes:
> >
> >> On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
> >>> Mark Rutland  writes:
> >>> 
> >>> reg-u16-align4 tells that a specific hardware doesn't support 16 bit 
> >>> writes not
> >>> being 32 bits aligned, or said differently that a "store" 16 bits wide on 
> >>> an
> >>> address of the format 4*n + 2 deserves a special handling in the driver, 
> >>> while a
> >>> store 16 bits wide on an address of the format 4*n can follow the simple 
> >>> casual
> >>> case.
> >>
> >> If I've understood correctly, effectively the low 2 address lines to the
> >> device are hard-wired to zero, e.g. a 16-bit access to 4*n + 2 would go
> >> to 4*n + 0 on the device? Or is the failure case distinct from that?
> > It is distinct.
> >
> > The "awful truth" is that an FPGA lies between the system bus and the
> > smc91c111. And this FPGA cannot handle correctly the 4*n + 2 u16 writes.
> >
> >> Do we have other platforms where similar is true? e.g. u8 accesses
> >> requiring 16-bit alignment?
> >
> > Not really, ie. not with a alignement requirement.
> >
> > But there are of course these ones are handled by reg-io-width and the
> > SMC_USE_xxx_BITS flags as far as I understand it. These cases are when a
> > platform declares SMC91X_USE_16BIT or SMC91X_USE_32BIT, but not 
> > SMC91X_USE_8BIT,
> > which would make me think of :
> >  - CONFIG_SH_SH4202_MICRODEV,
> >  - CONFIG_M32R
> >  - several omap1 boards
> >  - 1 sa1100 board
> >  - several MMP and realview boards
> >
> > With all these platforms, each u8 access is replaced with a u16 access and a
> > mask / shift + mask.
> 
> Or so what should I call this entry if reg-u16-align4 is not a good candidate 
> ?

This seems broken in a very platform specific way, so perhaps something 
named based on the platform.

Rob

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

On Sat, Oct 08, 2016 at 07:03:30PM +0200, Thomas Gleixner wrote:
> On Sat, 8 Oct 2016, Rich Felker wrote:
> > On Sat, Oct 08, 2016 at 01:32:06PM +0200, Thomas Gleixner wrote:
> > > CPU spins and waits for an interrupt to happen
> > > 
> > > 
> > >   -0 [000] d...   150.841530: rcu_dyntick: End 0 1
> > > 
> > > Dropping out of the spin about the time we expect the PIT interrupt to
> > > fire. And an interrupt is the reason why we drop out because the 'need
> > > resched' flag is not set and we end up in:
> > 
> > OK, I missed that.
> > 
> > >   -0 [000] d.s.   150.841724: tick_irq_enter: update 
> > > jiffies via irq
> > > 
> > > which is called from irq_enter()
> > > 
> > >   -0 [000] d.s.   150.841918: tick_do_update_jiffies64: 
> > > finished do_timer(1)
> > >   -0 [000] d.s.   150.842348: tick_do_update_jiffies64: 
> > > finished updating jiffies
> > > 
> > > 
> > > So here we would expect:
> > > 
> > >irq_handler_entry: irq=16 name=jcore_pit
> > >...
> > >irq_handler_exit .
> > >
> > > 
> > > or any other interrupt being invoked. But we see this here:
> > 
> > According to the trace the 'irq' is soft ('s'). I couldn't find the
> > code path from the idle loop to softirq but so maybe this is a bug. Is
> > it possible that in some cases the arch irq entry does not get
> > identified as a hard irq or traced and then the subsequent tick code
> > thinks it's running in a softirq and behaves differently? I could add
> > more tracing around irq entry.
> 
> No.
> 
> irq_enter()
>   if (is_idle_task(current) && !in_interrupt()) {
>   local_bh_disable();
>   tick_irq_enter();
>   local_bh_enable();
>   }
>   __irq_enter()
>   preempt_count_add(HARDIRQ_OFFSET);
> 
> So the 's' comes from local_bh_disable() and the code does not behave
> special because of that. It's just always that way. Look at all the other
> instances of tick_irq_enter() which do not show that issue.

Thank you -- that was really confusing me. Now that I know there's
actually a hardirq handling I know where to look for the problem.

> > >   -0 [000] d...   150.842603: __tick_nohz_idle_enter: 
> > > can stop idle tick
> > > 
> > > And that's just wrong. 
> > 
> > Can you explain?
> 
> Because you drop out the idle spin due to an interrupt, but no interrupt is
> handled according to the trace. You just go back to sleep and the trace is
> full of this behaviour.

Found the problem. IRQD_IRQ_INPROGRESS is causing the interrupt to be
ignored if the same interrupt is being handled on the other cpu.
Modifying the jcore aic driver to call handle_percpu_irq rather than
handle_simple_irq when the irq was registered as percpu solves the
problem, but I'm actually concerned that handle_simple_irq would also
be wrong in the case of non-percpu irqs if they could be delivered on
either core -- if another irq arrives after the driver is finished
checking for new device status, but before the IRQD_IRQ_INPROGRESS
flag is removed, it seems handle_simple_irq loses the irq. This is not
a problem for the current hardware since non-percpu irqs always arrive
on cpu0, but I'd rather improve the driver to properly handle possible
future hardware that allows irq delivery on any core.

> > > Both CPUs have the same interrupt number for their per cpu PIT interrupt.
> > > 
> > > IIRC you said earlier when the percpu interrupt discussion happened, that
> > > your per cpu PITs have distinct interrupt numbers, but that does not seem
> > > the case here.
> > 
> > No, I said the opposite. They use the same irq number but they're each
> > wired to their own cpu, and there's no way for them to fire on the
> > wrong cpu.
> 
> Your patch does:
> 
> > +   err = request_irq(pit_irq, jcore_timer_interrupt,
> > + IRQF_TIMER | IRQF_PERCPU,
> > + "jcore_pit", jcore_pit_percpu);
> 
> which is the wrong thing to do. You need request_percpu_irq() here, but of
> course with the irq chip you are using, which has every callback as a noop,
> it does not matter at all. So that's not an issue and not the reason for
> this wreckage.

Mentioning this was helpful to get me looking at the right things
tracking from the irq entry point to where the irq was lost/dropped,
so thanks for bringing it up. request_irq ends up working fine still
because IRQF_PERCPU causes __setup_irq to mark the irqdesc/irq_data as
percpu, so that my handle function can treat it differently. Here's
the patch that has it working:

diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
index 5e5e3bb..b53a8a5 100644
--- a/drivers/irqchip/irq-jcore-aic.c
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -25,12 +25,20 @@
 
 static struct irq_chip jcore_aic;
 
+static void handle_jcore_irq(struct irq_desc *desc)
+{
+   if (irq_is_percpu(irq_desc_get_irq(desc)))
+   handle_percpu_irq(desc);
+   

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

[Rob Herring]

On Mon, Oct 03, 2016 at 05:42:29PM +0100, Mark Rutland wrote:
> On Mon, Oct 03, 2016 at 05:09:13PM +0100, Russell King - ARM Linux wrote:
> > Please note that the binding doc for smsc,lan91c111.txt is slightly wrong
> > on two counts:
> > 
> > 1) compatible property:
> > 
> > compatible = "smsc,lan91c111";
> > 
> > vs the code:
> > 
> > static const struct of_device_id smc91x_match[] = {
> > { .compatible = "smsc,lan91c94", },
> > { .compatible = "smsc,lan91c111", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, smc91x_match);
> > 
> > So the binding document needs to mention that smsc,lan91c94 is a valid
> > compatible for this device.
> 
> Yes, it should.
> 
> > 2) reg-io-width property:
> > 
> > - reg-io-width : Mask of sizes (in bytes) of the IO accesses that
> >   are supported on the device.  Valid value for SMSC LAN91c111 are
> >   1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
> >   16-bit access only.
>  
> > Moreover, look at the property name vs the binding description.  It's
> > property name says it's a width, but the description says it's a mask
> > of sizes - these really aren't the same thing.  Once you start
> > specifying these other legal masks, it makes a nonsense of the "width"
> > part of the name.  It's too late to try and fix this now though.
> 
> Indeed, as-is this is nonsense. :(
> 
> The best we can do here is to add a big fat notice regarding the
> misnaming; adding a new property is only giong to cause more confusion.

Just fix the text here removing the mask part. This is a common property 
and not a mask. The rest saying 1, 2, 4 being valid is correct. There 
are no occurences using this as a mask in kernel dts files either.

> 
> > The binding document really needs to get fixed - I'll try to cook up a
> > patch during this week to correct these points, but it probably needs
> > coordination if others are going to be changing this as well.
> 
> Thanks for handling both of these.
> 
> Given the historical rate of change of the binding document, I suspect
> the stuff for pxa platforms is going to be the only potential conflict.
> 
> Either all of that can go via the DT tree (independent of any new code),
> or we can ack the whole lot and it can all go via the net tree in one
> go.
> 
> Thanks,
> Mark.

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

[Rob Herring]

On Mon, Oct 03, 2016 at 05:42:29PM +0100, Mark Rutland wrote:
> On Mon, Oct 03, 2016 at 05:09:13PM +0100, Russell King - ARM Linux wrote:
> > Please note that the binding doc for smsc,lan91c111.txt is slightly wrong
> > on two counts:
> > 
> > 1) compatible property:
> > 
> > compatible = "smsc,lan91c111";
> > 
> > vs the code:
> > 
> > static const struct of_device_id smc91x_match[] = {
> > { .compatible = "smsc,lan91c94", },
> > { .compatible = "smsc,lan91c111", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, smc91x_match);
> > 
> > So the binding document needs to mention that smsc,lan91c94 is a valid
> > compatible for this device.
> 
> Yes, it should.
> 
> > 2) reg-io-width property:
> > 
> > - reg-io-width : Mask of sizes (in bytes) of the IO accesses that
> >   are supported on the device.  Valid value for SMSC LAN91c111 are
> >   1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
> >   16-bit access only.
>  
> > Moreover, look at the property name vs the binding description.  It's
> > property name says it's a width, but the description says it's a mask
> > of sizes - these really aren't the same thing.  Once you start
> > specifying these other legal masks, it makes a nonsense of the "width"
> > part of the name.  It's too late to try and fix this now though.
> 
> Indeed, as-is this is nonsense. :(
> 
> The best we can do here is to add a big fat notice regarding the
> misnaming; adding a new property is only giong to cause more confusion.

Just fix the text here removing the mask part. This is a common property 
and not a mask. The rest saying 1, 2, 4 being valid is correct. There 
are no occurences using this as a mask in kernel dts files either.

> 
> > The binding document really needs to get fixed - I'll try to cook up a
> > patch during this week to correct these points, but it probably needs
> > coordination if others are going to be changing this as well.
> 
> Thanks for handling both of these.
> 
> Given the historical rate of change of the binding document, I suspect
> the stuff for pxa platforms is going to be the only potential conflict.
> 
> Either all of that can go via the DT tree (independent of any new code),
> or we can ack the whole lot and it can all go via the net tree in one
> go.
> 
> Thanks,
> Mark.

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

On Sat, Oct 08, 2016 at 07:03:30PM +0200, Thomas Gleixner wrote:
> On Sat, 8 Oct 2016, Rich Felker wrote:
> > On Sat, Oct 08, 2016 at 01:32:06PM +0200, Thomas Gleixner wrote:
> > > CPU spins and waits for an interrupt to happen
> > > 
> > > 
> > >   -0 [000] d...   150.841530: rcu_dyntick: End 0 1
> > > 
> > > Dropping out of the spin about the time we expect the PIT interrupt to
> > > fire. And an interrupt is the reason why we drop out because the 'need
> > > resched' flag is not set and we end up in:
> > 
> > OK, I missed that.
> > 
> > >   -0 [000] d.s.   150.841724: tick_irq_enter: update 
> > > jiffies via irq
> > > 
> > > which is called from irq_enter()
> > > 
> > >   -0 [000] d.s.   150.841918: tick_do_update_jiffies64: 
> > > finished do_timer(1)
> > >   -0 [000] d.s.   150.842348: tick_do_update_jiffies64: 
> > > finished updating jiffies
> > > 
> > > 
> > > So here we would expect:
> > > 
> > >irq_handler_entry: irq=16 name=jcore_pit
> > >...
> > >irq_handler_exit .
> > >
> > > 
> > > or any other interrupt being invoked. But we see this here:
> > 
> > According to the trace the 'irq' is soft ('s'). I couldn't find the
> > code path from the idle loop to softirq but so maybe this is a bug. Is
> > it possible that in some cases the arch irq entry does not get
> > identified as a hard irq or traced and then the subsequent tick code
> > thinks it's running in a softirq and behaves differently? I could add
> > more tracing around irq entry.
> 
> No.
> 
> irq_enter()
>   if (is_idle_task(current) && !in_interrupt()) {
>   local_bh_disable();
>   tick_irq_enter();
>   local_bh_enable();
>   }
>   __irq_enter()
>   preempt_count_add(HARDIRQ_OFFSET);
> 
> So the 's' comes from local_bh_disable() and the code does not behave
> special because of that. It's just always that way. Look at all the other
> instances of tick_irq_enter() which do not show that issue.

Thank you -- that was really confusing me. Now that I know there's
actually a hardirq handling I know where to look for the problem.

> > >   -0 [000] d...   150.842603: __tick_nohz_idle_enter: 
> > > can stop idle tick
> > > 
> > > And that's just wrong. 
> > 
> > Can you explain?
> 
> Because you drop out the idle spin due to an interrupt, but no interrupt is
> handled according to the trace. You just go back to sleep and the trace is
> full of this behaviour.

Found the problem. IRQD_IRQ_INPROGRESS is causing the interrupt to be
ignored if the same interrupt is being handled on the other cpu.
Modifying the jcore aic driver to call handle_percpu_irq rather than
handle_simple_irq when the irq was registered as percpu solves the
problem, but I'm actually concerned that handle_simple_irq would also
be wrong in the case of non-percpu irqs if they could be delivered on
either core -- if another irq arrives after the driver is finished
checking for new device status, but before the IRQD_IRQ_INPROGRESS
flag is removed, it seems handle_simple_irq loses the irq. This is not
a problem for the current hardware since non-percpu irqs always arrive
on cpu0, but I'd rather improve the driver to properly handle possible
future hardware that allows irq delivery on any core.

> > > Both CPUs have the same interrupt number for their per cpu PIT interrupt.
> > > 
> > > IIRC you said earlier when the percpu interrupt discussion happened, that
> > > your per cpu PITs have distinct interrupt numbers, but that does not seem
> > > the case here.
> > 
> > No, I said the opposite. They use the same irq number but they're each
> > wired to their own cpu, and there's no way for them to fire on the
> > wrong cpu.
> 
> Your patch does:
> 
> > +   err = request_irq(pit_irq, jcore_timer_interrupt,
> > + IRQF_TIMER | IRQF_PERCPU,
> > + "jcore_pit", jcore_pit_percpu);
> 
> which is the wrong thing to do. You need request_percpu_irq() here, but of
> course with the irq chip you are using, which has every callback as a noop,
> it does not matter at all. So that's not an issue and not the reason for
> this wreckage.

Mentioning this was helpful to get me looking at the right things
tracking from the irq entry point to where the irq was lost/dropped,
so thanks for bringing it up. request_irq ends up working fine still
because IRQF_PERCPU causes __setup_irq to mark the irqdesc/irq_data as
percpu, so that my handle function can treat it differently. Here's
the patch that has it working:

diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
index 5e5e3bb..b53a8a5 100644
--- a/drivers/irqchip/irq-jcore-aic.c
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -25,12 +25,20 @@
 
 static struct irq_chip jcore_aic;
 
+static void handle_jcore_irq(struct irq_desc *desc)
+{
+   if (irq_is_percpu(irq_desc_get_irq(desc)))
+   handle_percpu_irq(desc);
+   

Re: [PATCH v4 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding

[Rob Herring]

On Tue, Oct 04, 2016 at 05:29:20PM +0200, Peter Rosin wrote:
> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
> 
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/display/panel/sharp,lq150x1lg11.txt   | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt

Acked-by: Rob Herring 

Re: [PATCH v4 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding

[Rob Herring]

On Tue, Oct 04, 2016 at 05:29:20PM +0200, Peter Rosin wrote:
> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
> 
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/display/panel/sharp,lq150x1lg11.txt   | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt

Acked-by: Rob Herring 

Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

[Rob Herring]

On Tue, Sep 27, 2016 at 05:48:45PM +0200, Neil Armstrong wrote:
> Since the I2C sx150x GPIO expander driver uses platform_data to manage
> the pins configurations, rewrite the driver as a pinctrl driver using
> pinconf to get/set pin configurations from DT or debugfs.
> 
> The pinctrl driver is functionnally equivalent as the gpio-only driver
> and can use DT for pinconf. The platform_data confirmation is dropped.
> 
> This patchset removed the gpio-only driver and selects the Pinctrl driver
> config instead. This patchset also migrates the gpio dt-bindings to pinctrl
> and add the pinctrl optional properties.
> 
> The driver was tested with a SX1509 device on a BeagleBone black with
> interrupt support and on an X86_64 machine over an I2C to USB converter.
> 
> Signed-off-by: Neil Armstrong 
> ---
> This is a fixed version that builds and runs on non-OF platforms and on
> arm based OF. The GPIO version is removed and the bindings are also moved
> to the pinctrl bindings.
> 
> One remaining question, should i2c_driver remove be implemented ?
> It would be quite hard to implement due to the interrupt controller.
> 
> Changes since v1 at 
> http://lkml.kernel.org/r/1473166599-29266-1-git-send-email-narmstr...@baylibre.com:
>  - Fix Kconfig descriptions on pinctrl and gpio
>  - Fix Kconfig dependency
>  - Remove oscio support for non-789 devices
>  - correct typo in dt bindings
>  - remove probe reset for non-789 devices
> 
> Changes since RFC at 
> http://lkml.kernel.org/r/1472130692-14404-1-git-send-email-narmstr...@baylibre.com:
>  - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
>  - No more rely on OF_GPIO config
>  - Moved and enhanced bindings to pinctrl bindings
>  - Removed gpio-sx150x.c
>  - Temporary select PINCTRL_SX150X when GPIO_SX150X
>  - Temporary mark GPIO_SX150X as deprecated
> 
> 
>  .../gpio-sx150x.txt => pinctrl/pinctrl-sx150x.txt} |   46 +-

Acked-by: Rob Herring 

>  drivers/gpio/Kconfig   |   13 +-
>  drivers/gpio/Makefile  |1 -
>  drivers/pinctrl/Kconfig|   14 +
>  drivers/pinctrl/Makefile   |1 +
>  .../gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} | 1179 
> 
>  6 files changed, 782 insertions(+), 472 deletions(-)
>  rename Documentation/devicetree/bindings/{gpio/gpio-sx150x.txt => 
> pinctrl/pinctrl-sx150x.txt} (40%)
>  rename drivers/{gpio/gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} (24%)

Re: [PATCH 05/12] ASoC: sun4i-codec: Add support for A31 playback through headphone output

[Rob Herring]

On Mon, Oct 03, 2016 at 07:07:57PM +0800, Chen-Yu Tsai wrote:
> The A31 has a similar codec to the A10/A20. The PCM parts are very
> similar, with just different register offsets. The analog paths are
> very different. There are more inputs and outputs.
> 
> The quirks structure is expanded to include different register offsets
> and separate callbacks for creating the ASoC card. Also the DMA burst
> length is increased to 8. While the A10 DMA engine supports bursts of
> 1, 4 and 8, the A31 engine only supports 1 and 8.
> 
> This patch adds support for the basic playback path of the A31 codec,
> from the DAC to the headphones. Headphone detection, microphone,
> signaling, other inputs/outputs and capture will be added later.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/sound/sun4i-codec.txt  |   6 +-

Acked-by: Rob Herring 

>  sound/soc/sunxi/sun4i-codec.c  | 396 
> +
>  2 files changed, 334 insertions(+), 68 deletions(-)

Re: [PATCH 10/12] ASoC: sun4i-codec: Add support for A31 board level audio routing

[Rob Herring]

On Mon, Oct 03, 2016 at 07:08:02PM +0800, Chen-Yu Tsai wrote:
> The A31 SoC's codec has various inputs, outputs and microphone bias
> supplies. These can be routed on the board in different ways, such as:
> 
>   - Microphones all use the MBIAS main microphone supply or one mic may
> use the HBIAS supply, which supports headset detection and buttons.
> 
>   - Line Out may be routed to an audio jack, or an onboard speaker amp
> with power controls.
> 
> Add support for specifying the audio routes in the device tree.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/sound/sun4i-codec.txt  | 35 
> ++

Acked-by: Rob Herring 

>  sound/soc/sunxi/sun4i-codec.c  | 21 +++--
>  2 files changed, 54 insertions(+), 2 deletions(-)

Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

[Rob Herring]

On Tue, Sep 27, 2016 at 05:48:45PM +0200, Neil Armstrong wrote:
> Since the I2C sx150x GPIO expander driver uses platform_data to manage
> the pins configurations, rewrite the driver as a pinctrl driver using
> pinconf to get/set pin configurations from DT or debugfs.
> 
> The pinctrl driver is functionnally equivalent as the gpio-only driver
> and can use DT for pinconf. The platform_data confirmation is dropped.
> 
> This patchset removed the gpio-only driver and selects the Pinctrl driver
> config instead. This patchset also migrates the gpio dt-bindings to pinctrl
> and add the pinctrl optional properties.
> 
> The driver was tested with a SX1509 device on a BeagleBone black with
> interrupt support and on an X86_64 machine over an I2C to USB converter.
> 
> Signed-off-by: Neil Armstrong 
> ---
> This is a fixed version that builds and runs on non-OF platforms and on
> arm based OF. The GPIO version is removed and the bindings are also moved
> to the pinctrl bindings.
> 
> One remaining question, should i2c_driver remove be implemented ?
> It would be quite hard to implement due to the interrupt controller.
> 
> Changes since v1 at 
> http://lkml.kernel.org/r/1473166599-29266-1-git-send-email-narmstr...@baylibre.com:
>  - Fix Kconfig descriptions on pinctrl and gpio
>  - Fix Kconfig dependency
>  - Remove oscio support for non-789 devices
>  - correct typo in dt bindings
>  - remove probe reset for non-789 devices
> 
> Changes since RFC at 
> http://lkml.kernel.org/r/1472130692-14404-1-git-send-email-narmstr...@baylibre.com:
>  - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
>  - No more rely on OF_GPIO config
>  - Moved and enhanced bindings to pinctrl bindings
>  - Removed gpio-sx150x.c
>  - Temporary select PINCTRL_SX150X when GPIO_SX150X
>  - Temporary mark GPIO_SX150X as deprecated
> 
> 
>  .../gpio-sx150x.txt => pinctrl/pinctrl-sx150x.txt} |   46 +-

Acked-by: Rob Herring 

>  drivers/gpio/Kconfig   |   13 +-
>  drivers/gpio/Makefile  |1 -
>  drivers/pinctrl/Kconfig|   14 +
>  drivers/pinctrl/Makefile   |1 +
>  .../gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} | 1179 
> 
>  6 files changed, 782 insertions(+), 472 deletions(-)
>  rename Documentation/devicetree/bindings/{gpio/gpio-sx150x.txt => 
> pinctrl/pinctrl-sx150x.txt} (40%)
>  rename drivers/{gpio/gpio-sx150x.c => pinctrl/pinctrl-sx150x.c} (24%)

Re: [PATCH 05/12] ASoC: sun4i-codec: Add support for A31 playback through headphone output

[Rob Herring]

On Mon, Oct 03, 2016 at 07:07:57PM +0800, Chen-Yu Tsai wrote:
> The A31 has a similar codec to the A10/A20. The PCM parts are very
> similar, with just different register offsets. The analog paths are
> very different. There are more inputs and outputs.
> 
> The quirks structure is expanded to include different register offsets
> and separate callbacks for creating the ASoC card. Also the DMA burst
> length is increased to 8. While the A10 DMA engine supports bursts of
> 1, 4 and 8, the A31 engine only supports 1 and 8.
> 
> This patch adds support for the basic playback path of the A31 codec,
> from the DAC to the headphones. Headphone detection, microphone,
> signaling, other inputs/outputs and capture will be added later.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/sound/sun4i-codec.txt  |   6 +-

Acked-by: Rob Herring 

>  sound/soc/sunxi/sun4i-codec.c  | 396 
> +
>  2 files changed, 334 insertions(+), 68 deletions(-)

Re: [PATCH 10/12] ASoC: sun4i-codec: Add support for A31 board level audio routing

[Rob Herring]

On Mon, Oct 03, 2016 at 07:08:02PM +0800, Chen-Yu Tsai wrote:
> The A31 SoC's codec has various inputs, outputs and microphone bias
> supplies. These can be routed on the board in different ways, such as:
> 
>   - Microphones all use the MBIAS main microphone supply or one mic may
> use the HBIAS supply, which supports headset detection and buttons.
> 
>   - Line Out may be routed to an audio jack, or an onboard speaker amp
> with power controls.
> 
> Add support for specifying the audio routes in the device tree.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/sound/sun4i-codec.txt  | 35 
> ++

Acked-by: Rob Herring 

>  sound/soc/sunxi/sun4i-codec.c  | 21 +++--
>  2 files changed, 54 insertions(+), 2 deletions(-)

Re: [PATCH 3/3] bindings: add compatible "fsl, ls1043-ucc-hdlc" to bindings

[Rob Herring]

On Wed, Sep 28, 2016 at 11:40:38AM +0800, Zhao Qiang wrote:
> Signed-off-by: Zhao Qiang 
> ---
>  Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt 
> b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> index 03c7416..325e3e2 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> @@ -45,7 +45,7 @@ Example:
>  * HDLC
>  
>  Currently defined compatibles:
> -- fsl,ucc-hdlc
> +- "fsl,ucc-hdlc", "fsl,ls1043-ucc-hdlc"

What's the relationship of these 2 compatibles? Both should be specified 
for LS1043 or ...? The former only applies to certain SoCs? Rework this 
text to answer these questions.

Rob

Re: [PATCH 3/3] bindings: add compatible "fsl, ls1043-ucc-hdlc" to bindings

[Rob Herring]

On Wed, Sep 28, 2016 at 11:40:38AM +0800, Zhao Qiang wrote:
> Signed-off-by: Zhao Qiang 
> ---
>  Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt 
> b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> index 03c7416..325e3e2 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> @@ -45,7 +45,7 @@ Example:
>  * HDLC
>  
>  Currently defined compatibles:
> -- fsl,ucc-hdlc
> +- "fsl,ucc-hdlc", "fsl,ls1043-ucc-hdlc"

What's the relationship of these 2 compatibles? Both should be specified 
for LS1043 or ...? The former only applies to certain SoCs? Rework this 
text to answer these questions.

Rob

Fwd: [PATCH V3 00/11] block-throttle: add .high limit

[Kyle Sanderson]

Re-sending as plain-text as the Gmail Android App is still
historically broken...

-- Forwarded message --
From: Kyle Sanderson 
Date: Wed, Oct 5, 2016 at 7:09 AM
Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit
To: Tejun Heo 
Cc: jmo...@redhat.com, Paolo Valente ,
linux-kernel@vger.kernel.org, Mark Brown ,
linux-bl...@vger.kernel.org, Shaohua Li , Jens Axboe
, Linus Walleij , Vivek Goyal
, kernel-t...@fb.com, Ulf Hansson



Obviously not to compound against this, however it has been proven for
years that CFQ will lock significantly under contention, and other
schedulers, such as BFQ attempt to provide fairness which is
absolutely the desired  outcome from using a machine. The networking
space is a little wrecked in the sense there's a plethora of qdiscs
that don't necessarily need to exist; but are legacy. This limitation
does not exist in this realm as there are no specific tunables.

There is no reason that in 2016 a user-space application can steal all
of the I/O from a disk, completely locking the machine when BFQ has
essentially solved this years ago. I've been a moderately happy user
of BFQ for quite sometime now. There aren't tens, or hundreds of us,
but thousands through the custom kernels that are spun, and the
distros that helped support BFQ.

How is this even a discussion when hard numbers, and trying any
reproduction case easily reproduce the issues that CFQ causes. Reading
this thread, and many others only grows not only my disappointment,
but whenever someone launches kterm or scrot and their machine
freezes, leaves a selective few individuals completely responsible for
this. Help those users, help yourself, help Linux.


On 4 Oct 2016 1:29 pm, "Tejun Heo"  wrote:
>
> Hello, Paolo.
>
> On Tue, Oct 04, 2016 at 09:29:48PM +0200, Paolo Valente wrote:
> > > Hmm... I think we already discussed this but here's a really simple
> > > case.  There are three unknown workloads A, B and C and we want to
> > > give A certain best-effort guarantees (let's say around 80% of the
> > > underlying device) whether A is sharing the device with B or C.
> >
> > That's the same example that you proposed me in our previous
> > discussion.  For this example I showed you, with many boring numbers,
> > that with BFQ you get the most accurate distribution of the resource.
>
> Yes, it is about the same example and what I understood was that
> "accurate distribution of the resources" holds as long as the
> randomness is incidental (ie. due to layout on the filesystem and so
> on) with the slice expiration mechanism offsetting the actually random
> workloads.
>
> > If you have enough stamina, I can repeat them again.  To save your
>
> I'll go back to the thread and re-read them.
>
> > patience, here is a very brief summary.  In a concrete use case, the
> > unknown workloads turn into something like this: there will be a first
> > time interval during which A happens to be, say, sequential, B happens
> > to be, say, random and C happens to be, say, quasi-sequential.  Then
> > there will be a next time interval during which their characteristics
> > change, and so on.  It is easy (but boring, I acknowledge it) to show
> > that, for each of these time intervals BFQ provides the best possible
> > service in terms of fairness, bandwidth distribution, stability and so
> > on.  Why?  Because of the elastic bandwidth-time scheduling of BFQ
> > that we already discussed, and because BFQ is naturally accurate in
> > redistributing aggregate throughput proportionally, when needed.
>
> Yeah, that's what I remember and for workload above certain level of
> randomness its time consumption is mapped to bw, right?
>
> > > I get that bfq can be a good compromise on most desktop workloads and
> > > behave reasonably well for some server workloads with the slice
> > > expiration mechanism but it really isn't an IO resource partitioning
> > > mechanism.
> >
> > Right.  My argument is that BFQ enables you to give to each client the
> > bandwidth and low-latency guarantees you want.  And this IMO is way
> > better than partitioning a resource and then getting unavoidable
> > unfairness and high latency.
>
> But that statement only holds while bw is the main thing to guarantee,
> no?  The level of isolation that we're looking for here is fairly
> strict adherence to sub/few-milliseconds in terms of high percentile
> scheduling latency while within the configured bw/iops limits, not
> "overall this device is being used pretty well".
>
> Thanks.
>
> --
> tejun

Fwd: [PATCH V3 00/11] block-throttle: add .high limit

[Kyle Sanderson]

Re-sending as plain-text as the Gmail Android App is still
historically broken...

-- Forwarded message --
From: Kyle Sanderson 
Date: Wed, Oct 5, 2016 at 7:09 AM
Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit
To: Tejun Heo 
Cc: jmo...@redhat.com, Paolo Valente ,
linux-kernel@vger.kernel.org, Mark Brown ,
linux-bl...@vger.kernel.org, Shaohua Li , Jens Axboe
, Linus Walleij , Vivek Goyal
, kernel-t...@fb.com, Ulf Hansson



Obviously not to compound against this, however it has been proven for
years that CFQ will lock significantly under contention, and other
schedulers, such as BFQ attempt to provide fairness which is
absolutely the desired  outcome from using a machine. The networking
space is a little wrecked in the sense there's a plethora of qdiscs
that don't necessarily need to exist; but are legacy. This limitation
does not exist in this realm as there are no specific tunables.

There is no reason that in 2016 a user-space application can steal all
of the I/O from a disk, completely locking the machine when BFQ has
essentially solved this years ago. I've been a moderately happy user
of BFQ for quite sometime now. There aren't tens, or hundreds of us,
but thousands through the custom kernels that are spun, and the
distros that helped support BFQ.

How is this even a discussion when hard numbers, and trying any
reproduction case easily reproduce the issues that CFQ causes. Reading
this thread, and many others only grows not only my disappointment,
but whenever someone launches kterm or scrot and their machine
freezes, leaves a selective few individuals completely responsible for
this. Help those users, help yourself, help Linux.


On 4 Oct 2016 1:29 pm, "Tejun Heo"  wrote:
>
> Hello, Paolo.
>
> On Tue, Oct 04, 2016 at 09:29:48PM +0200, Paolo Valente wrote:
> > > Hmm... I think we already discussed this but here's a really simple
> > > case.  There are three unknown workloads A, B and C and we want to
> > > give A certain best-effort guarantees (let's say around 80% of the
> > > underlying device) whether A is sharing the device with B or C.
> >
> > That's the same example that you proposed me in our previous
> > discussion.  For this example I showed you, with many boring numbers,
> > that with BFQ you get the most accurate distribution of the resource.
>
> Yes, it is about the same example and what I understood was that
> "accurate distribution of the resources" holds as long as the
> randomness is incidental (ie. due to layout on the filesystem and so
> on) with the slice expiration mechanism offsetting the actually random
> workloads.
>
> > If you have enough stamina, I can repeat them again.  To save your
>
> I'll go back to the thread and re-read them.
>
> > patience, here is a very brief summary.  In a concrete use case, the
> > unknown workloads turn into something like this: there will be a first
> > time interval during which A happens to be, say, sequential, B happens
> > to be, say, random and C happens to be, say, quasi-sequential.  Then
> > there will be a next time interval during which their characteristics
> > change, and so on.  It is easy (but boring, I acknowledge it) to show
> > that, for each of these time intervals BFQ provides the best possible
> > service in terms of fairness, bandwidth distribution, stability and so
> > on.  Why?  Because of the elastic bandwidth-time scheduling of BFQ
> > that we already discussed, and because BFQ is naturally accurate in
> > redistributing aggregate throughput proportionally, when needed.
>
> Yeah, that's what I remember and for workload above certain level of
> randomness its time consumption is mapped to bw, right?
>
> > > I get that bfq can be a good compromise on most desktop workloads and
> > > behave reasonably well for some server workloads with the slice
> > > expiration mechanism but it really isn't an IO resource partitioning
> > > mechanism.
> >
> > Right.  My argument is that BFQ enables you to give to each client the
> > bandwidth and low-latency guarantees you want.  And this IMO is way
> > better than partitioning a resource and then getting unavoidable
> > unfairness and high latency.
>
> But that statement only holds while bw is the main thing to guarantee,
> no?  The level of isolation that we're looking for here is fairly
> strict adherence to sub/few-milliseconds in terms of high percentile
> scheduling latency while within the configured bw/iops limits, not
> "overall this device is being used pretty well".
>
> Thanks.
>
> --
> tejun

perf TUI fails with "failed to process type: 64"

[Anton Blanchard]

Hi,

Updating to mainline as of last night, I started seeing the following
error when running the perf report TUI:

0x46068 [0x8]: failed to process type: 68

This event is just PERF_RECORD_FINISHED_ROUND:

0x46068 [0x8]: event: 68
.
. ... raw event: size 8 bytes
.  :  44 00 00 00 00 00 08 00  D...

0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND

Which of course is not our error. It took me a while to find the real
culprit:

 14c00-14c00 g exc_virt_0x4c00_system_call

A zero length symbol, which __symbol__inc_addr_samples() barfs on:

if (addr < sym->start || addr >= sym->end) {
...
return -ERANGE;

Seems like we have 3 bugs here:

1. Output the real source of the error instead of PERF_RECORD_FINISHED_ROUND

2. Don't exit the TUI if we find a sample on a zero length symbol

3. Why do we have zero length symbols in the first place? Does the recent
   ppc64 exception clean up have something to do with it?

Anton

perf TUI fails with "failed to process type: 64"

[Anton Blanchard]

Hi,

Updating to mainline as of last night, I started seeing the following
error when running the perf report TUI:

0x46068 [0x8]: failed to process type: 68

This event is just PERF_RECORD_FINISHED_ROUND:

0x46068 [0x8]: event: 68
.
. ... raw event: size 8 bytes
.  :  44 00 00 00 00 00 08 00  D...

0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND

Which of course is not our error. It took me a while to find the real
culprit:

 14c00-14c00 g exc_virt_0x4c00_system_call

A zero length symbol, which __symbol__inc_addr_samples() barfs on:

if (addr < sym->start || addr >= sym->end) {
...
return -ERANGE;

Seems like we have 3 bugs here:

1. Output the real source of the error instead of PERF_RECORD_FINISHED_ROUND

2. Don't exit the TUI if we find a sample on a zero length symbol

3. Why do we have zero length symbols in the first place? Does the recent
   ppc64 exception clean up have something to do with it?

Anton

[PATCH RFC 3/3] tpm_crb: request and relinquish locality 0

[Jarkko Sakkinen]

Request and relinquish locality for the driver use in order to be
a better citizen in a multi locality environment like with TXT as
it uses locality 2.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index ffd3a6c..9e07cf3 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -34,6 +34,15 @@ enum crb_defaults {
CRB_ACPI_START_INDEX = 1,
 };
 
+enum crb_loc_ctrl {
+   CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
+   CRB_LOC_CTRL_RELINQUISH = BIT(1),
+};
+
+enum crb_loc_state {
+   CRB_LOC_STATE_LOC_ASSIGNED  = BIT(1),
+};
+
 enum crb_ctrl_req {
CRB_CTRL_REQ_CMD_READY  = BIT(0),
CRB_CTRL_REQ_GO_IDLE= BIT(1),
@@ -98,12 +107,8 @@ struct crb_priv {
  * @dev:  crb device
  * @priv: crb private data
  *
- * Write CRB_CTRL_REQ_GO_IDLE to TPM_CRB_CTRL_REQ
- * The device should respond within TIMEOUT_C by clearing the bit.
- * Anyhow, we do not wait here as a consequent CMD_READY request
- * will be handled correctly even if idle was not completed.
- *
- * The function does nothing for devices with ACPI-start method.
+ * Put device to the idle state and relinquish locality. The function does
+ * nothing for devices with the ACPI-start method.
  *
  * Return: 0 always
  */
@@ -112,6 +117,7 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
+   iowrite32(CRB_LOC_CTRL_RELINQUISH, >regs->loc_ctrl);
iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs->ctrl_req);
/* we don't really care when this settles */
 
@@ -143,11 +149,8 @@ static bool crb_wait_for_reg_32(u32 __iomem *reg, u32 
mask, u32 value,
  * @dev:  crb device
  * @priv: crb private data
  *
- * Write CRB_CTRL_REQ_CMD_READY to TPM_CRB_CTRL_REQ
- * and poll till the device acknowledge it by clearing the bit.
- * The device should respond within TIMEOUT_C.
- *
- * The function does nothing for devices with ACPI-start method
+ * Try to wake up the device and request locality. The function does nothing
+ * for devices with the ACPI-start method.
  *
  * Return: 0 on success -ETIME on timeout;
  */
@@ -162,7 +165,16 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
 CRB_CTRL_REQ_CMD_READY /* mask */,
 0, /* value */
 TPM2_TIMEOUT_C)) {
-   dev_warn(dev, "cmdReady timed out\n");
+   dev_warn(dev, "TPM_CRB_CTRL_REQ_x.cmdReady timed out\n");
+   return -ETIME;
+   }
+
+   iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, >regs->loc_ctrl);
+   if (!crb_wait_for_reg_32(>regs->loc_state,
+CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
+CRB_LOC_STATE_LOC_ASSIGNED, /* value */
+TPM2_TIMEOUT_C)) {
+   dev_warn(dev, "TPM_LOC_STATE_x.requestAccess timed out\n");
return -ETIME;
}
 
-- 
2.7.4

[PATCH RFC 1/3] tpm_crb: expand struct crb_control_area to struct crb_regs

[Jarkko Sakkinen]

In order to allow to use locality 0, expand the data structure to expose
all of the CRB registers. The address is calculated from the control
area address in order to retain backwards compatibility to ACPI start
based hardware (pre-Skylake).

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 82 --
 1 file changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 65040d7..3d021e6 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -52,18 +52,26 @@ enum crb_cancel {
CRB_CANCEL_INVOKE   = BIT(0),
 };
 
-struct crb_control_area {
-   u32 req;
-   u32 sts;
-   u32 cancel;
-   u32 start;
-   u32 int_enable;
-   u32 int_sts;
-   u32 cmd_size;
-   u32 cmd_pa_low;
-   u32 cmd_pa_high;
-   u32 rsp_size;
-   u64 rsp_pa;
+struct crb_regs {
+   u32 loc_state;
+   u32 reserved1;
+   u32 loc_ctrl;
+   u32 loc_sts;
+   u8 reserved2[32];
+   u64 intf_id;
+   u64 ctrl_ext;
+   /* the control area */
+   u32 ctrl_req;
+   u32 ctrl_sts;
+   u32 ctrl_cancel;
+   u32 ctrl_start;
+   u32 ctrl_int_enable;
+   u32 ctrl_int_sts;
+   u32 ctrl_cmd_size;
+   u32 ctrl_cmd_pa_low;
+   u32 ctrl_cmd_pa_high;
+   u32 ctrl_rsp_size;
+   u64 ctrl_rsp_pa;
 } __packed;
 
 enum crb_status {
@@ -78,7 +86,7 @@ enum crb_flags {
 struct crb_priv {
unsigned int flags;
void __iomem *iobase;
-   struct crb_control_area __iomem *cca;
+   struct crb_regs __iomem *regs;
u8 __iomem *cmd;
u8 __iomem *rsp;
u32 cmd_size;
@@ -104,7 +112,7 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
-   iowrite32(CRB_CTRL_REQ_GO_IDLE, >cca->req);
+   iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs->ctrl_req);
/* we don't really care when this settles */
 
return 0;
@@ -128,16 +136,18 @@ static int __maybe_unused crb_cmd_ready(struct device 
*dev,
struct crb_priv *priv)
 {
ktime_t stop, start;
+   u32 req;
 
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
-   iowrite32(CRB_CTRL_REQ_CMD_READY, >cca->req);
+   iowrite32(CRB_CTRL_REQ_CMD_READY, >regs->ctrl_req);
 
start = ktime_get();
stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
do {
-   if (!(ioread32(>cca->req) & CRB_CTRL_REQ_CMD_READY)) {
+   req = ioread32(>regs->ctrl_req);
+   if (!(req & CRB_CTRL_REQ_CMD_READY)) {
dev_dbg(dev, "cmdReady in %lld usecs\n",
ktime_to_us(ktime_sub(ktime_get(), start)));
return 0;
@@ -145,7 +155,7 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
usleep_range(50, 100);
} while (ktime_before(ktime_get(), stop));
 
-   if (ioread32(>cca->req) & CRB_CTRL_REQ_CMD_READY) {
+   if (ioread32(>regs->ctrl_req) & CRB_CTRL_REQ_CMD_READY) {
dev_warn(dev, "cmdReady timed out\n");
return -ETIME;
}
@@ -158,7 +168,7 @@ static u8 crb_status(struct tpm_chip *chip)
struct crb_priv *priv = dev_get_drvdata(>dev);
u8 sts = 0;
 
-   if ((ioread32(>cca->start) & CRB_START_INVOKE) !=
+   if ((ioread32(>regs->ctrl_start) & CRB_START_INVOKE) !=
CRB_START_INVOKE)
sts |= CRB_DRV_STS_COMPLETE;
 
@@ -174,7 +184,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t 
count)
if (count < 6)
return -EIO;
 
-   if (ioread32(>cca->sts) & CRB_CTRL_STS_ERROR)
+   if (ioread32(>regs->ctrl_sts) & CRB_CTRL_STS_ERROR)
return -EIO;
 
memcpy_fromio(buf, priv->rsp, 6);
@@ -213,7 +223,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t 
len)
/* Zero the cancel register so that the next command will not get
 * canceled.
 */
-   iowrite32(0, >cca->cancel);
+   iowrite32(0, >regs->ctrl_cancel);
 
if (len > priv->cmd_size) {
dev_err(>dev, "invalid command count value %zd %d\n",
@@ -227,7 +237,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t 
len)
wmb();
 
if (priv->flags & CRB_FL_CRB_START)
-   iowrite32(CRB_START_INVOKE, >cca->start);
+   iowrite32(CRB_START_INVOKE, >regs->ctrl_start);
 
if (priv->flags & CRB_FL_ACPI_START)
rc = crb_do_acpi_start(chip);
@@ -239,7 +249,7 @@ static void crb_cancel(struct tpm_chip *chip)
 {
struct crb_priv *priv = dev_get_drvdata(>dev);
 
-   iowrite32(CRB_CANCEL_INVOKE, >cca->cancel);
+   iowrite32(CRB_CANCEL_INVOKE, >regs->ctrl_cancel);
 
if 

[PATCH RFC 3/3] tpm_crb: request and relinquish locality 0

[Jarkko Sakkinen]

Request and relinquish locality for the driver use in order to be
a better citizen in a multi locality environment like with TXT as
it uses locality 2.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index ffd3a6c..9e07cf3 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -34,6 +34,15 @@ enum crb_defaults {
CRB_ACPI_START_INDEX = 1,
 };
 
+enum crb_loc_ctrl {
+   CRB_LOC_CTRL_REQUEST_ACCESS = BIT(0),
+   CRB_LOC_CTRL_RELINQUISH = BIT(1),
+};
+
+enum crb_loc_state {
+   CRB_LOC_STATE_LOC_ASSIGNED  = BIT(1),
+};
+
 enum crb_ctrl_req {
CRB_CTRL_REQ_CMD_READY  = BIT(0),
CRB_CTRL_REQ_GO_IDLE= BIT(1),
@@ -98,12 +107,8 @@ struct crb_priv {
  * @dev:  crb device
  * @priv: crb private data
  *
- * Write CRB_CTRL_REQ_GO_IDLE to TPM_CRB_CTRL_REQ
- * The device should respond within TIMEOUT_C by clearing the bit.
- * Anyhow, we do not wait here as a consequent CMD_READY request
- * will be handled correctly even if idle was not completed.
- *
- * The function does nothing for devices with ACPI-start method.
+ * Put device to the idle state and relinquish locality. The function does
+ * nothing for devices with the ACPI-start method.
  *
  * Return: 0 always
  */
@@ -112,6 +117,7 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
+   iowrite32(CRB_LOC_CTRL_RELINQUISH, >regs->loc_ctrl);
iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs->ctrl_req);
/* we don't really care when this settles */
 
@@ -143,11 +149,8 @@ static bool crb_wait_for_reg_32(u32 __iomem *reg, u32 
mask, u32 value,
  * @dev:  crb device
  * @priv: crb private data
  *
- * Write CRB_CTRL_REQ_CMD_READY to TPM_CRB_CTRL_REQ
- * and poll till the device acknowledge it by clearing the bit.
- * The device should respond within TIMEOUT_C.
- *
- * The function does nothing for devices with ACPI-start method
+ * Try to wake up the device and request locality. The function does nothing
+ * for devices with the ACPI-start method.
  *
  * Return: 0 on success -ETIME on timeout;
  */
@@ -162,7 +165,16 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
 CRB_CTRL_REQ_CMD_READY /* mask */,
 0, /* value */
 TPM2_TIMEOUT_C)) {
-   dev_warn(dev, "cmdReady timed out\n");
+   dev_warn(dev, "TPM_CRB_CTRL_REQ_x.cmdReady timed out\n");
+   return -ETIME;
+   }
+
+   iowrite32(CRB_LOC_CTRL_REQUEST_ACCESS, >regs->loc_ctrl);
+   if (!crb_wait_for_reg_32(>regs->loc_state,
+CRB_LOC_STATE_LOC_ASSIGNED, /* mask */
+CRB_LOC_STATE_LOC_ASSIGNED, /* value */
+TPM2_TIMEOUT_C)) {
+   dev_warn(dev, "TPM_LOC_STATE_x.requestAccess timed out\n");
return -ETIME;
}
 
-- 
2.7.4

[PATCH RFC 1/3] tpm_crb: expand struct crb_control_area to struct crb_regs

[Jarkko Sakkinen]

In order to allow to use locality 0, expand the data structure to expose
all of the CRB registers. The address is calculated from the control
area address in order to retain backwards compatibility to ACPI start
based hardware (pre-Skylake).

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 82 --
 1 file changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 65040d7..3d021e6 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -52,18 +52,26 @@ enum crb_cancel {
CRB_CANCEL_INVOKE   = BIT(0),
 };
 
-struct crb_control_area {
-   u32 req;
-   u32 sts;
-   u32 cancel;
-   u32 start;
-   u32 int_enable;
-   u32 int_sts;
-   u32 cmd_size;
-   u32 cmd_pa_low;
-   u32 cmd_pa_high;
-   u32 rsp_size;
-   u64 rsp_pa;
+struct crb_regs {
+   u32 loc_state;
+   u32 reserved1;
+   u32 loc_ctrl;
+   u32 loc_sts;
+   u8 reserved2[32];
+   u64 intf_id;
+   u64 ctrl_ext;
+   /* the control area */
+   u32 ctrl_req;
+   u32 ctrl_sts;
+   u32 ctrl_cancel;
+   u32 ctrl_start;
+   u32 ctrl_int_enable;
+   u32 ctrl_int_sts;
+   u32 ctrl_cmd_size;
+   u32 ctrl_cmd_pa_low;
+   u32 ctrl_cmd_pa_high;
+   u32 ctrl_rsp_size;
+   u64 ctrl_rsp_pa;
 } __packed;
 
 enum crb_status {
@@ -78,7 +86,7 @@ enum crb_flags {
 struct crb_priv {
unsigned int flags;
void __iomem *iobase;
-   struct crb_control_area __iomem *cca;
+   struct crb_regs __iomem *regs;
u8 __iomem *cmd;
u8 __iomem *rsp;
u32 cmd_size;
@@ -104,7 +112,7 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
-   iowrite32(CRB_CTRL_REQ_GO_IDLE, >cca->req);
+   iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs->ctrl_req);
/* we don't really care when this settles */
 
return 0;
@@ -128,16 +136,18 @@ static int __maybe_unused crb_cmd_ready(struct device 
*dev,
struct crb_priv *priv)
 {
ktime_t stop, start;
+   u32 req;
 
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
-   iowrite32(CRB_CTRL_REQ_CMD_READY, >cca->req);
+   iowrite32(CRB_CTRL_REQ_CMD_READY, >regs->ctrl_req);
 
start = ktime_get();
stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
do {
-   if (!(ioread32(>cca->req) & CRB_CTRL_REQ_CMD_READY)) {
+   req = ioread32(>regs->ctrl_req);
+   if (!(req & CRB_CTRL_REQ_CMD_READY)) {
dev_dbg(dev, "cmdReady in %lld usecs\n",
ktime_to_us(ktime_sub(ktime_get(), start)));
return 0;
@@ -145,7 +155,7 @@ static int __maybe_unused crb_cmd_ready(struct device *dev,
usleep_range(50, 100);
} while (ktime_before(ktime_get(), stop));
 
-   if (ioread32(>cca->req) & CRB_CTRL_REQ_CMD_READY) {
+   if (ioread32(>regs->ctrl_req) & CRB_CTRL_REQ_CMD_READY) {
dev_warn(dev, "cmdReady timed out\n");
return -ETIME;
}
@@ -158,7 +168,7 @@ static u8 crb_status(struct tpm_chip *chip)
struct crb_priv *priv = dev_get_drvdata(>dev);
u8 sts = 0;
 
-   if ((ioread32(>cca->start) & CRB_START_INVOKE) !=
+   if ((ioread32(>regs->ctrl_start) & CRB_START_INVOKE) !=
CRB_START_INVOKE)
sts |= CRB_DRV_STS_COMPLETE;
 
@@ -174,7 +184,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t 
count)
if (count < 6)
return -EIO;
 
-   if (ioread32(>cca->sts) & CRB_CTRL_STS_ERROR)
+   if (ioread32(>regs->ctrl_sts) & CRB_CTRL_STS_ERROR)
return -EIO;
 
memcpy_fromio(buf, priv->rsp, 6);
@@ -213,7 +223,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t 
len)
/* Zero the cancel register so that the next command will not get
 * canceled.
 */
-   iowrite32(0, >cca->cancel);
+   iowrite32(0, >regs->ctrl_cancel);
 
if (len > priv->cmd_size) {
dev_err(>dev, "invalid command count value %zd %d\n",
@@ -227,7 +237,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t 
len)
wmb();
 
if (priv->flags & CRB_FL_CRB_START)
-   iowrite32(CRB_START_INVOKE, >cca->start);
+   iowrite32(CRB_START_INVOKE, >regs->ctrl_start);
 
if (priv->flags & CRB_FL_ACPI_START)
rc = crb_do_acpi_start(chip);
@@ -239,7 +249,7 @@ static void crb_cancel(struct tpm_chip *chip)
 {
struct crb_priv *priv = dev_get_drvdata(>dev);
 
-   iowrite32(CRB_CANCEL_INVOKE, >cca->cancel);
+   iowrite32(CRB_CANCEL_INVOKE, >regs->ctrl_cancel);
 
if ((priv->flags & 

[PATCH RFC 0/3] Locality support for the CRB driver

[Jarkko Sakkinen]

Request and relinquish locality 0 so that the CRB driver is a good
citizen in a multi locality environment like TXT.

Jarkko Sakkinen (3):
  tpm_crb: expand struct crb_control_area to struct crb_regs
  tpm_crb: encapsulate crb_wait_for_reg_32
  tpm_crb: request and relinquish locality 0

 drivers/char/tpm/tpm_crb.c | 148 -
 1 file changed, 92 insertions(+), 56 deletions(-)

-- 
2.7.4

[PATCH RFC 2/3] tpm_crb: encapsulate crb_wait_for_reg_32

[Jarkko Sakkinen]

Encapsulated crb_wait_for_reg32() so that state changes in other CRB
registers than CTRL_REQ_X can be waited.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 40 +++-
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 3d021e6..ffd3a6c 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -118,6 +118,25 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
return 0;
 }
 
+static bool crb_wait_for_reg_32(u32 __iomem *reg, u32 mask, u32 value,
+   unsigned long timeout)
+{
+   ktime_t start;
+   ktime_t stop;
+
+   start = ktime_get();
+   stop = ktime_add(start, ms_to_ktime(timeout));
+
+   do {
+   if ((ioread32(reg) & mask) == value)
+   return true;
+
+   usleep_range(50, 100);
+   } while (ktime_before(ktime_get(), stop));
+
+   return false;
+}
+
 /**
  * crb_cmd_ready - request tpm crb device to enter ready state
  *
@@ -135,27 +154,14 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
 static int __maybe_unused crb_cmd_ready(struct device *dev,
struct crb_priv *priv)
 {
-   ktime_t stop, start;
-   u32 req;
-
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
iowrite32(CRB_CTRL_REQ_CMD_READY, >regs->ctrl_req);
-
-   start = ktime_get();
-   stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
-   do {
-   req = ioread32(>regs->ctrl_req);
-   if (!(req & CRB_CTRL_REQ_CMD_READY)) {
-   dev_dbg(dev, "cmdReady in %lld usecs\n",
-   ktime_to_us(ktime_sub(ktime_get(), start)));
-   return 0;
-   }
-   usleep_range(50, 100);
-   } while (ktime_before(ktime_get(), stop));
-
-   if (ioread32(>regs->ctrl_req) & CRB_CTRL_REQ_CMD_READY) {
+   if (!crb_wait_for_reg_32(>regs->ctrl_req,
+CRB_CTRL_REQ_CMD_READY /* mask */,
+0, /* value */
+TPM2_TIMEOUT_C)) {
dev_warn(dev, "cmdReady timed out\n");
return -ETIME;
}
-- 
2.7.4

[PATCH RFC 0/3] Locality support for the CRB driver

[Jarkko Sakkinen]

Request and relinquish locality 0 so that the CRB driver is a good
citizen in a multi locality environment like TXT.

Jarkko Sakkinen (3):
  tpm_crb: expand struct crb_control_area to struct crb_regs
  tpm_crb: encapsulate crb_wait_for_reg_32
  tpm_crb: request and relinquish locality 0

 drivers/char/tpm/tpm_crb.c | 148 -
 1 file changed, 92 insertions(+), 56 deletions(-)

-- 
2.7.4

[PATCH RFC 2/3] tpm_crb: encapsulate crb_wait_for_reg_32

[Jarkko Sakkinen]

Encapsulated crb_wait_for_reg32() so that state changes in other CRB
registers than CTRL_REQ_X can be waited.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_crb.c | 40 +++-
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 3d021e6..ffd3a6c 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -118,6 +118,25 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
return 0;
 }
 
+static bool crb_wait_for_reg_32(u32 __iomem *reg, u32 mask, u32 value,
+   unsigned long timeout)
+{
+   ktime_t start;
+   ktime_t stop;
+
+   start = ktime_get();
+   stop = ktime_add(start, ms_to_ktime(timeout));
+
+   do {
+   if ((ioread32(reg) & mask) == value)
+   return true;
+
+   usleep_range(50, 100);
+   } while (ktime_before(ktime_get(), stop));
+
+   return false;
+}
+
 /**
  * crb_cmd_ready - request tpm crb device to enter ready state
  *
@@ -135,27 +154,14 @@ static int __maybe_unused crb_go_idle(struct device *dev, 
struct crb_priv *priv)
 static int __maybe_unused crb_cmd_ready(struct device *dev,
struct crb_priv *priv)
 {
-   ktime_t stop, start;
-   u32 req;
-
if (priv->flags & CRB_FL_ACPI_START)
return 0;
 
iowrite32(CRB_CTRL_REQ_CMD_READY, >regs->ctrl_req);
-
-   start = ktime_get();
-   stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
-   do {
-   req = ioread32(>regs->ctrl_req);
-   if (!(req & CRB_CTRL_REQ_CMD_READY)) {
-   dev_dbg(dev, "cmdReady in %lld usecs\n",
-   ktime_to_us(ktime_sub(ktime_get(), start)));
-   return 0;
-   }
-   usleep_range(50, 100);
-   } while (ktime_before(ktime_get(), stop));
-
-   if (ioread32(>regs->ctrl_req) & CRB_CTRL_REQ_CMD_READY) {
+   if (!crb_wait_for_reg_32(>regs->ctrl_req,
+CRB_CTRL_REQ_CMD_READY /* mask */,
+0, /* value */
+TPM2_TIMEOUT_C)) {
dev_warn(dev, "cmdReady timed out\n");
return -ETIME;
}
-- 
2.7.4

[PATCH v2] sched/fair: Fix dereference NULL sched domain during select_idle_sibling

[Wanpeng Li]

From: Wanpeng Li 

Commit:

  10e2f1acd01 ("sched/core: Rewrite and improve select_idle_siblings()")

... improved select_idle_sibling() but also triggered a regression:

BUG: unable to handle kernel NULL pointer dereference at 0078
IP: [] select_idle_sibling+0x1c2/0x4f0
PGD 0 
Oops:  [#1] SMP
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.8.0+ #16
RIP: 0010:[]  [] 
select_idle_sibling+0x1c2/0x4f0
Call Trace:
  
  select_task_rq_fair+0x749/0x930
  ? select_task_rq_fair+0xb4/0x930
  ? __lock_is_held+0x54/0x70
  try_to_wake_up+0x19a/0x5b0
  default_wake_function+0x12/0x20
  autoremove_wake_function+0x12/0x40
  __wake_up_common+0x55/0x90
  __wake_up+0x39/0x50
  wake_up_klogd_work_func+0x40/0x60
  irq_work_run_list+0x57/0x80
  irq_work_run+0x2c/0x30
  smp_irq_work_interrupt+0x2e/0x40
  irq_work_interrupt+0x96/0xa0
  
  ? _raw_spin_unlock_irqrestore+0x45/0x80
  try_to_wake_up+0x4a/0x5b0
  wake_up_state+0x10/0x20
  __kthread_unpark+0x67/0x70
  kthread_unpark+0x22/0x30
  cpuhp_online_idle+0x3e/0x70
  cpu_startup_entry+0x6a/0x450
  start_secondary+0x154/0x180

This can be reproduced by running the ftrace test case of kselftest, the 
test case will hot-unplug the cpu and the cpu will attach to the NULL 
sched-domain during scheduler teardown. 

The step 2 for the rewrite select_idle_siblings():

| Step 2) tracks the average cost of the scan and compares this to the
| average idle time guestimate for the CPU doing the wakeup.

If the cpu which doing the wakeup is the going hot-unplug cpu, then NULL
sched domain will be dereferenced to acquire the average cost of the scan.

This patch fix it by failing the search of an idle CPU in the LLC process 
if this sched domain is NULL.

Cc: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * remove rcu_read_lock()

 kernel/sched/fair.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 543b2f2..cfcdaf4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5472,13 +5472,18 @@ static inline int select_idle_smt(struct task_struct 
*p, struct sched_domain *sd
  */
 static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int 
target)
 {
-   struct sched_domain *this_sd = rcu_dereference(*this_cpu_ptr(_llc));
-   u64 avg_idle = this_rq()->avg_idle;
-   u64 avg_cost = this_sd->avg_scan_cost;
+   struct sched_domain *this_sd;
+   u64 avg_cost, avg_idle = this_rq()->avg_idle;
u64 time, cost;
s64 delta;
int cpu, wrap;
 
+   this_sd = rcu_dereference(*this_cpu_ptr(_llc));
+   if (!this_sd)
+   return -1;
+
+   avg_cost = this_sd->avg_scan_cost;
+
/*
 * Due to large variance we need a large fuzz factor; hackbench in
 * particularly is sensitive here.
-- 
1.9.1

[PATCH v2] sched/fair: Fix dereference NULL sched domain during select_idle_sibling

[Wanpeng Li]

From: Wanpeng Li 

Commit:

  10e2f1acd01 ("sched/core: Rewrite and improve select_idle_siblings()")

... improved select_idle_sibling() but also triggered a regression:

BUG: unable to handle kernel NULL pointer dereference at 0078
IP: [] select_idle_sibling+0x1c2/0x4f0
PGD 0 
Oops:  [#1] SMP
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.8.0+ #16
RIP: 0010:[]  [] 
select_idle_sibling+0x1c2/0x4f0
Call Trace:
  
  select_task_rq_fair+0x749/0x930
  ? select_task_rq_fair+0xb4/0x930
  ? __lock_is_held+0x54/0x70
  try_to_wake_up+0x19a/0x5b0
  default_wake_function+0x12/0x20
  autoremove_wake_function+0x12/0x40
  __wake_up_common+0x55/0x90
  __wake_up+0x39/0x50
  wake_up_klogd_work_func+0x40/0x60
  irq_work_run_list+0x57/0x80
  irq_work_run+0x2c/0x30
  smp_irq_work_interrupt+0x2e/0x40
  irq_work_interrupt+0x96/0xa0
  
  ? _raw_spin_unlock_irqrestore+0x45/0x80
  try_to_wake_up+0x4a/0x5b0
  wake_up_state+0x10/0x20
  __kthread_unpark+0x67/0x70
  kthread_unpark+0x22/0x30
  cpuhp_online_idle+0x3e/0x70
  cpu_startup_entry+0x6a/0x450
  start_secondary+0x154/0x180

This can be reproduced by running the ftrace test case of kselftest, the 
test case will hot-unplug the cpu and the cpu will attach to the NULL 
sched-domain during scheduler teardown. 

The step 2 for the rewrite select_idle_siblings():

| Step 2) tracks the average cost of the scan and compares this to the
| average idle time guestimate for the CPU doing the wakeup.

If the cpu which doing the wakeup is the going hot-unplug cpu, then NULL
sched domain will be dereferenced to acquire the average cost of the scan.

This patch fix it by failing the search of an idle CPU in the LLC process 
if this sched domain is NULL.

Cc: Ingo Molnar 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * remove rcu_read_lock()

 kernel/sched/fair.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 543b2f2..cfcdaf4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5472,13 +5472,18 @@ static inline int select_idle_smt(struct task_struct 
*p, struct sched_domain *sd
  */
 static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int 
target)
 {
-   struct sched_domain *this_sd = rcu_dereference(*this_cpu_ptr(_llc));
-   u64 avg_idle = this_rq()->avg_idle;
-   u64 avg_cost = this_sd->avg_scan_cost;
+   struct sched_domain *this_sd;
+   u64 avg_cost, avg_idle = this_rq()->avg_idle;
u64 time, cost;
s64 delta;
int cpu, wrap;
 
+   this_sd = rcu_dereference(*this_cpu_ptr(_llc));
+   if (!this_sd)
+   return -1;
+
+   avg_cost = this_sd->avg_scan_cost;
+
/*
 * Due to large variance we need a large fuzz factor; hackbench in
 * particularly is sensitive here.
-- 
1.9.1

Re: [PATCH] sched/fair: Fix dereference NULL sched domain during select_idle_sibling

[Wanpeng Li]

2016-10-09 1:06 GMT+08:00 Peter Zijlstra :
> On Sat, Oct 08, 2016 at 06:24:38PM +0800, Wanpeng Li wrote:
>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 543b2f2..03a6620 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5472,19 +5472,29 @@ static inline int select_idle_smt(struct task_struct 
>> *p, struct sched_domain *sd
>>   */
>>  static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, 
>> int target)
>>  {
>> - struct sched_domain *this_sd = rcu_dereference(*this_cpu_ptr(_llc));
>
> So select_idle_cpu() <- select_idle_sibling() is called from two places,
> both which already hold rcu_read_lock() afaict.

Agreed.

>
> This would've insta-triggered a rcu-lockdep splat otherwise I think.

CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_LOCK_ALLOC=y

So it is interesting why not a rcu-lockdep splat. :)

>
> That is, selsect_task_rq_fair() has rcu_read_lock() taken when calling
> this, and task_numa_compare() does too.
>
>> + struct sched_domain *this_sd;
>>   u64 avg_idle = this_rq()->avg_idle;
>> - u64 avg_cost = this_sd->avg_scan_cost;
>> + u64 avg_cost;
>>   u64 time, cost;
>>   s64 delta;
>>   int cpu, wrap;
>>
>> + rcu_read_lock();
>> + this_sd = rcu_dereference(*this_cpu_ptr(_llc));
>> + if (!this_sd) {
>> + cpu = -1;
>> + goto unlock;
>> + }
>
> Yes, this is the part that was missing. We need to test this_sd after
> the lookup.
>
> Thanks for looking at this!

NP, I will send out v2 soon. :)

Regards,
Wanpeng Li

Re: [PATCH] sched/fair: Fix dereference NULL sched domain during select_idle_sibling

[Wanpeng Li]

2016-10-09 1:06 GMT+08:00 Peter Zijlstra :
> On Sat, Oct 08, 2016 at 06:24:38PM +0800, Wanpeng Li wrote:
>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 543b2f2..03a6620 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5472,19 +5472,29 @@ static inline int select_idle_smt(struct task_struct 
>> *p, struct sched_domain *sd
>>   */
>>  static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, 
>> int target)
>>  {
>> - struct sched_domain *this_sd = rcu_dereference(*this_cpu_ptr(_llc));
>
> So select_idle_cpu() <- select_idle_sibling() is called from two places,
> both which already hold rcu_read_lock() afaict.

Agreed.

>
> This would've insta-triggered a rcu-lockdep splat otherwise I think.

CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_LOCK_ALLOC=y

So it is interesting why not a rcu-lockdep splat. :)

>
> That is, selsect_task_rq_fair() has rcu_read_lock() taken when calling
> this, and task_numa_compare() does too.
>
>> + struct sched_domain *this_sd;
>>   u64 avg_idle = this_rq()->avg_idle;
>> - u64 avg_cost = this_sd->avg_scan_cost;
>> + u64 avg_cost;
>>   u64 time, cost;
>>   s64 delta;
>>   int cpu, wrap;
>>
>> + rcu_read_lock();
>> + this_sd = rcu_dereference(*this_cpu_ptr(_llc));
>> + if (!this_sd) {
>> + cpu = -1;
>> + goto unlock;
>> + }
>
> Yes, this is the part that was missing. We need to test this_sd after
> the lookup.
>
> Thanks for looking at this!

NP, I will send out v2 soon. :)

Regards,
Wanpeng Li

Re: btrfs_direct_IO oops

[Dave Jones]

On Sat, Oct 08, 2016 at 07:29:03PM +0100, Al Viro wrote:
 > On Sat, Oct 08, 2016 at 02:08:06PM -0400, Dave Jones wrote:
 > > That code: matches this dissembly:
 > > 
 > > for (i = seg + 1; i < iter->nr_segs; i++) {
 > 
 > *whoa*
 > 
 > OK, that loop in check_direct_IO() should be done *ONLY* for
 > iovec iter - even for a bvec one it's completely bogus, and
 > for pipe ones it blows up immediately.
 > 
 > Sorry, I'd missed that bogosity - replace
 > if (iov_iter_rw(iter) == WRITE)
 >  return 0;
 > with
 >  if (iov_iter_rw(iter) != READ || !iter_is_iovec(iter))
 >  return 0;
 > in there; that should fix the damn thing.

Yep, seems to do the trick. Have been running the last six hours
without seeing it or anything similar since.

Dave

Re: btrfs_direct_IO oops

[Dave Jones]

On Sat, Oct 08, 2016 at 07:29:03PM +0100, Al Viro wrote:
 > On Sat, Oct 08, 2016 at 02:08:06PM -0400, Dave Jones wrote:
 > > That code: matches this dissembly:
 > > 
 > > for (i = seg + 1; i < iter->nr_segs; i++) {
 > 
 > *whoa*
 > 
 > OK, that loop in check_direct_IO() should be done *ONLY* for
 > iovec iter - even for a bvec one it's completely bogus, and
 > for pipe ones it blows up immediately.
 > 
 > Sorry, I'd missed that bogosity - replace
 > if (iov_iter_rw(iter) == WRITE)
 >  return 0;
 > with
 >  if (iov_iter_rw(iter) != READ || !iter_is_iovec(iter))
 >  return 0;
 > in there; that should fix the damn thing.

Yep, seems to do the trick. Have been running the last six hours
without seeing it or anything similar since.

Dave

[PATCH] tmp: use pdev for parent device in tpm_chip_alloc

[Tomas Winkler]

The tpm stack uses pdev name convention for the parent device.
Fix that also in tpm_chip_alloc().

Fixes: 3897cd9c8d1d ("tpm: Split out the devm stuff from tpmm_chip_alloc")'
Signed-off-by: Tomas Winkler 
---
 drivers/char/tpm/tpm-chip.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index e5950131bd90..a017ccd8cc3b 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -140,7 +140,7 @@ static void tpm_dev_release(struct device *dev)
  * Allocates a new struct tpm_chip instance and assigns a free
  * device number for it. Must be paired with put_device(>dev).
  */
-struct tpm_chip *tpm_chip_alloc(struct device *dev,
+struct tpm_chip *tpm_chip_alloc(struct device *pdev,
const struct tpm_class_ops *ops)
 {
struct tpm_chip *chip;
@@ -159,7 +159,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *dev,
rc = idr_alloc(_nums_idr, NULL, 0, TPM_NUM_DEVICES, GFP_KERNEL);
mutex_unlock(_lock);
if (rc < 0) {
-   dev_err(dev, "No available tpm device numbers\n");
+   dev_err(pdev, "No available tpm device numbers\n");
kfree(chip);
return ERR_PTR(rc);
}
@@ -169,7 +169,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *dev,
 
chip->dev.class = tpm_class;
chip->dev.release = tpm_dev_release;
-   chip->dev.parent = dev;
+   chip->dev.parent = pdev;
chip->dev.groups = chip->groups;
 
if (chip->dev_num == 0)
@@ -181,7 +181,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *dev,
if (rc)
goto out;
 
-   if (!dev)
+   if (!pdev)
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
 
cdev_init(>cdev, _fops);
-- 
2.7.4

[PATCH] tmp: use pdev for parent device in tpm_chip_alloc

[Tomas Winkler]

The tpm stack uses pdev name convention for the parent device.
Fix that also in tpm_chip_alloc().

Fixes: 3897cd9c8d1d ("tpm: Split out the devm stuff from tpmm_chip_alloc")'
Signed-off-by: Tomas Winkler 
---
 drivers/char/tpm/tpm-chip.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index e5950131bd90..a017ccd8cc3b 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -140,7 +140,7 @@ static void tpm_dev_release(struct device *dev)
  * Allocates a new struct tpm_chip instance and assigns a free
  * device number for it. Must be paired with put_device(>dev).
  */
-struct tpm_chip *tpm_chip_alloc(struct device *dev,
+struct tpm_chip *tpm_chip_alloc(struct device *pdev,
const struct tpm_class_ops *ops)
 {
struct tpm_chip *chip;
@@ -159,7 +159,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *dev,
rc = idr_alloc(_nums_idr, NULL, 0, TPM_NUM_DEVICES, GFP_KERNEL);
mutex_unlock(_lock);
if (rc < 0) {
-   dev_err(dev, "No available tpm device numbers\n");
+   dev_err(pdev, "No available tpm device numbers\n");
kfree(chip);
return ERR_PTR(rc);
}
@@ -169,7 +169,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *dev,
 
chip->dev.class = tpm_class;
chip->dev.release = tpm_dev_release;
-   chip->dev.parent = dev;
+   chip->dev.parent = pdev;
chip->dev.groups = chip->groups;
 
if (chip->dev_num == 0)
@@ -181,7 +181,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *dev,
if (rc)
goto out;
 
-   if (!dev)
+   if (!pdev)
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
 
cdev_init(>cdev, _fops);
-- 
2.7.4

[GIT PULL]: CRIS changes for 4.9

[Jesper Nilsson]

Hi Linus,

Please pull for cris changes for 4.9.

The following changes since commit 7d1e042314619115153a0f6f06e4552c09a50e13:

  Merge tag 'usercopy-v4.8-rc8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-09-20 17:11:19 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git 
tags/cris-for-4.9

for you to fetch changes up to 2dc024e94578c53e2c579a48725c8fe2527f9d5e:

  cris: return of class_create should be considered (2016-09-23 16:06:00 +0200)


CRIS changes for 4.9


Andrea Gelmini (7):
  Fix typo
  Fix typo
  Fix typo
  Fix typo
  Fix typo
  Fix typo
  Fix typo

Dan Carpenter (1):
  CRIS v32: remove some double unlocks

Fabian Frederick (1):
  CRIS: defconfig: remove MTDRAM_ABS_POS

Jesper Nilsson (1):
  cris: intmem: fix device_initcall compile warning

Niklas Cassel (8):
  cris: intmem: fix pointer comparison compile warning
  cris: fasttimer: fix mixed declarations and code compile warning
  cris: irq: stop loop from accessing array out of bounds
  cris: add dev88_defconfig
  cris: cardbus: fix header include path
  cris: fix Kconfig mismatch when building with CONFIG_PCI
  cris: use generic io.h
  cris: v10: axisflashmap: remove unused ifdefs

Paul Gortmaker (1):
  cris: migrate exception table users off module.h and onto extable.h

yizhouz...@ict.ac.cn (1):
  cris: return of class_create should be considered

 arch/cris/Kconfig |   2 +-
 arch/cris/arch-v10/drivers/axisflashmap.c |  19 ---
 arch/cris/arch-v10/drivers/eeprom.c   |   2 +-
 arch/cris/arch-v10/lib/dram_init.S|   2 +-
 arch/cris/arch-v32/drivers/cryptocop.c|   2 +-
 arch/cris/arch-v32/drivers/pci/bios.c |   2 +-
 arch/cris/arch-v32/drivers/sync_serial.c  |   6 +
 arch/cris/arch-v32/kernel/fasttimer.c |  15 +-
 arch/cris/arch-v32/kernel/irq.c   |   3 +-
 arch/cris/arch-v32/mach-a3/dma.c  |   1 -
 arch/cris/arch-v32/mach-a3/dram_init.S|   2 +-
 arch/cris/arch-v32/mach-fs/dma.c  |   1 -
 arch/cris/arch-v32/mach-fs/dram_init.S|   2 +-
 arch/cris/arch-v32/mm/intmem.c|  13 +-
 arch/cris/configs/artpec_3_defconfig  |   1 -
 arch/cris/configs/dev88_defconfig |  48 ++
 arch/cris/configs/etrax-100lx_v2_defconfig|   1 -
 arch/cris/configs/etraxfs_defconfig   |   1 -
 arch/cris/include/arch-v32/arch/cryptocop.h   |   2 +-
 arch/cris/include/asm/io.h| 171 +-
 arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h |   2 +-
 arch/cris/mm/fault.c  |   2 +-
 22 files changed, 83 insertions(+), 217 deletions(-)
 create mode 100644 arch/cris/configs/dev88_defconfig

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

[GIT PULL]: CRIS changes for 4.9

[Jesper Nilsson]

Hi Linus,

Please pull for cris changes for 4.9.

The following changes since commit 7d1e042314619115153a0f6f06e4552c09a50e13:

  Merge tag 'usercopy-v4.8-rc8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-09-20 17:11:19 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git 
tags/cris-for-4.9

for you to fetch changes up to 2dc024e94578c53e2c579a48725c8fe2527f9d5e:

  cris: return of class_create should be considered (2016-09-23 16:06:00 +0200)


CRIS changes for 4.9


Andrea Gelmini (7):
  Fix typo
  Fix typo
  Fix typo
  Fix typo
  Fix typo
  Fix typo
  Fix typo

Dan Carpenter (1):
  CRIS v32: remove some double unlocks

Fabian Frederick (1):
  CRIS: defconfig: remove MTDRAM_ABS_POS

Jesper Nilsson (1):
  cris: intmem: fix device_initcall compile warning

Niklas Cassel (8):
  cris: intmem: fix pointer comparison compile warning
  cris: fasttimer: fix mixed declarations and code compile warning
  cris: irq: stop loop from accessing array out of bounds
  cris: add dev88_defconfig
  cris: cardbus: fix header include path
  cris: fix Kconfig mismatch when building with CONFIG_PCI
  cris: use generic io.h
  cris: v10: axisflashmap: remove unused ifdefs

Paul Gortmaker (1):
  cris: migrate exception table users off module.h and onto extable.h

yizhouz...@ict.ac.cn (1):
  cris: return of class_create should be considered

 arch/cris/Kconfig |   2 +-
 arch/cris/arch-v10/drivers/axisflashmap.c |  19 ---
 arch/cris/arch-v10/drivers/eeprom.c   |   2 +-
 arch/cris/arch-v10/lib/dram_init.S|   2 +-
 arch/cris/arch-v32/drivers/cryptocop.c|   2 +-
 arch/cris/arch-v32/drivers/pci/bios.c |   2 +-
 arch/cris/arch-v32/drivers/sync_serial.c  |   6 +
 arch/cris/arch-v32/kernel/fasttimer.c |  15 +-
 arch/cris/arch-v32/kernel/irq.c   |   3 +-
 arch/cris/arch-v32/mach-a3/dma.c  |   1 -
 arch/cris/arch-v32/mach-a3/dram_init.S|   2 +-
 arch/cris/arch-v32/mach-fs/dma.c  |   1 -
 arch/cris/arch-v32/mach-fs/dram_init.S|   2 +-
 arch/cris/arch-v32/mm/intmem.c|  13 +-
 arch/cris/configs/artpec_3_defconfig  |   1 -
 arch/cris/configs/dev88_defconfig |  48 ++
 arch/cris/configs/etrax-100lx_v2_defconfig|   1 -
 arch/cris/configs/etraxfs_defconfig   |   1 -
 arch/cris/include/arch-v32/arch/cryptocop.h   |   2 +-
 arch/cris/include/asm/io.h| 171 +-
 arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h |   2 +-
 arch/cris/mm/fault.c  |   2 +-
 22 files changed, 83 insertions(+), 217 deletions(-)
 create mode 100644 arch/cris/configs/dev88_defconfig

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

Re: parisc crash on boot with 4.8+git

[Helge Deller]

Hi Meelis,

On 08.10.2016 23:52, Meelis Roos wrote:
> Just tried 4.8.0-11288-gb66484c on three of my parsic machines (enabled 
> strict usercopy checking or somethinng like that in make oldconfig).

It's not related to the usercopy checks, instead it's most likely a
parisc-specific problem I just noticed today as well and which I'm 
currently fixing.
 
> rp3440 worked fine. a500 and rp3410 cras on boot.
> 
> rp3410 crashed on boot with the following:
> 
> Linux version 4.8.0-11288-gb66484c (mroos@rp3410) (gcc version 5.4.0 (Gentoo 
> 5.4.0 p1.0) ) #81 Sat Oct 8 20:40:24 EEST 2016
> unwind_init: start = 0x4076e980, end = 0x407a7060, entries = 14446
> The 64-bit Kernel has started...
> Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and 2 
> MB virtual size.
> bootconsole [ttyB0] enabled
> ...
> Memory Ranges:
>  0) Start 0x End 0x3fff Size   1024 MB
>  1) Start 0x00404000 End 0x00407fdf Size   1022 MB
> Total Memory: 2046 MB
> Backtrace:
>  [<40102d40>] paging_init+0x5e0/0x740
>  [<40103744>] setup_arch+0x16c/0x1b0
>  [<40100ce0>] start_kernel+0xb8/0x668
> 
> Bad Address (null pointer deref?): Code=15 regs=408034c0 
> (Addr=00099cf94000)

You probably are facing one or both of those problems:
1. Your kernel is bigger than the initial kernel mappings
2. You face a bug in the palo boot loader.

Regarding 1, you probably have CONFIG_TRACE=y or CONFIG_TEST_RHASHTABLE=y 
enabled?
Both increase the kernel size a lot and trigger this bug. 
To fix it, make sure you have this patch in your kernel (it's upstream):
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=690d097c00c88fa9d93d198591e184164b1d8c20

Additionally if people (not you) use a 32bit kernel I suggest this one too (in 
my for-next tree):
http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=96c65e4d1c77f461b34161dc8e6f2db7c50fd3e8

Both patches increase the initial kernel page mappings to 32MB which should be 
sufficient.

Even if you fix the kernel with the patches above, you still may run
into the palo bug. I've just pushed a fix for it into the palo tree:
https://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/commit/?id=70bd7a9a41e318c0575755a78c4d18ad97495c47

If you rebuild palo, please make sure to install the new ipl boot loader into
the palo partition of your boot disc. palo should report at bootup version 1.96.

Helge

Re: parisc crash on boot with 4.8+git

[Helge Deller]

Hi Meelis,

On 08.10.2016 23:52, Meelis Roos wrote:
> Just tried 4.8.0-11288-gb66484c on three of my parsic machines (enabled 
> strict usercopy checking or somethinng like that in make oldconfig).

It's not related to the usercopy checks, instead it's most likely a
parisc-specific problem I just noticed today as well and which I'm 
currently fixing.
 
> rp3440 worked fine. a500 and rp3410 cras on boot.
> 
> rp3410 crashed on boot with the following:
> 
> Linux version 4.8.0-11288-gb66484c (mroos@rp3410) (gcc version 5.4.0 (Gentoo 
> 5.4.0 p1.0) ) #81 Sat Oct 8 20:40:24 EEST 2016
> unwind_init: start = 0x4076e980, end = 0x407a7060, entries = 14446
> The 64-bit Kernel has started...
> Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and 2 
> MB virtual size.
> bootconsole [ttyB0] enabled
> ...
> Memory Ranges:
>  0) Start 0x End 0x3fff Size   1024 MB
>  1) Start 0x00404000 End 0x00407fdf Size   1022 MB
> Total Memory: 2046 MB
> Backtrace:
>  [<40102d40>] paging_init+0x5e0/0x740
>  [<40103744>] setup_arch+0x16c/0x1b0
>  [<40100ce0>] start_kernel+0xb8/0x668
> 
> Bad Address (null pointer deref?): Code=15 regs=408034c0 
> (Addr=00099cf94000)

You probably are facing one or both of those problems:
1. Your kernel is bigger than the initial kernel mappings
2. You face a bug in the palo boot loader.

Regarding 1, you probably have CONFIG_TRACE=y or CONFIG_TEST_RHASHTABLE=y 
enabled?
Both increase the kernel size a lot and trigger this bug. 
To fix it, make sure you have this patch in your kernel (it's upstream):
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=690d097c00c88fa9d93d198591e184164b1d8c20

Additionally if people (not you) use a 32bit kernel I suggest this one too (in 
my for-next tree):
http://git.kernel.org/cgit/linux/kernel/git/deller/parisc-linux.git/commit/?h=for-next=96c65e4d1c77f461b34161dc8e6f2db7c50fd3e8

Both patches increase the initial kernel page mappings to 32MB which should be 
sufficient.

Even if you fix the kernel with the patches above, you still may run
into the palo bug. I've just pushed a fix for it into the palo tree:
https://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/commit/?id=70bd7a9a41e318c0575755a78c4d18ad97495c47

If you rebuild palo, please make sure to install the new ipl boot loader into
the palo partition of your boot disc. palo should report at bootup version 1.96.

Helge

Re: [PATCH] ARM: dts: fix naming of pinctrl node

[Ray Jui]

On 10/8/2016 1:34 PM, Scott Branden wrote:

Remove 0x from pinctrl node to match device tree naming convention.

Signed-off-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index fabc9f3..539c58f 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -108,7 +108,7 @@
};
};

-   pinctrl: pinctrl@0x0301d0c8 {
+   pinctrl: pinctrl@0301d0c8 {
compatible = "brcm,cygnus-pinmux";
reg = <0x0301d0c8 0x30>,
  <0x0301d24c 0x2c>;



Looks good to me!

Reviewed-by: Ray Jui 

Re: [PATCH] ARM: dts: fix naming of pinctrl node

[Ray Jui]

On 10/8/2016 1:34 PM, Scott Branden wrote:

Remove 0x from pinctrl node to match device tree naming convention.

Signed-off-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index fabc9f3..539c58f 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -108,7 +108,7 @@
};
};

-   pinctrl: pinctrl@0x0301d0c8 {
+   pinctrl: pinctrl@0301d0c8 {
compatible = "brcm,cygnus-pinmux";
reg = <0x0301d0c8 0x30>,
  <0x0301d24c 0x2c>;



Looks good to me!

Reviewed-by: Ray Jui