Re: [PATCH] binder: fix race between munmap() and direct reclaim

2019-03-01 Thread Greg KH
On Fri, Mar 01, 2019 at 03:06:06PM -0800, Todd Kjos wrote:
> An munmap() on a binder device causes binder_vma_close() to be called
> which clears the alloc->vma pointer.
> 
> If direct reclaim causes binder_alloc_free_page() to be called, there
> is a race where alloc->vma is read into a local vma pointer and then
> used later after the mm->mmap_sem is acquired. This can result in
> calling zap_page_range() with an invalid vma which manifests as a
> use-after-free in zap_page_range().
> 
> The fix is to check alloc->vma after acquiring the mmap_sem (which we
> were acquiring anyway) and skip zap_page_range() if it has changed
> to NULL.
> 
> Signed-off-by: Todd Kjos 
> ---

Any specific commit that this fixes?  And should it be marked for
stable releases?

thanks,

greg k-h


Re: [PATCH net-next v2 00/15] net: mvpp2: fixes and improvements

2019-03-01 Thread David Miller
From: Antoine Tenart 
Date: Fri,  1 Mar 2019 11:52:02 +0100

> This series aims to improve the Marvell PPv2 driver and to fix various
> issues we encountered while testing the ports in many different
> configurations. The series is based on top of Russell PPv2 phylink
> rework and improvement.
 ...

Series applied, thanks Antoine.


Re: [PATCH] net: e1000e: add MAC address kernel cmd line parameter

2019-03-01 Thread David Miller
From: Flavio Suligoi 
Date: Thu, 28 Feb 2019 10:20:35 +0100

> Sometimes, in some embedded systems boards (i.e. ARM boards),
> the NVM eeprom is not mounted, to save cost and space.
> 
> In this case it is necessary to bypass the NVM management
> and directly force the MAC address using a kernel command-line
> parameter (macaddr).
> 
> Signed-off-by: Flavio Suligoi 

Sorry, we don't do things this way.  Otherwise every single driver would
add a hack like this.

Add either DT or appropriate initrd userland components to achieve
this.



WARNING in lockdep_register_key

2019-03-01 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:c63e9e91a254 Add linux-next specific files for 20190301
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=160f18ecc0
kernel config:  https://syzkaller.appspot.com/x/.config?x=f5875f9dc6e009b2
dashboard link: https://syzkaller.appspot.com/bug?extid=072814ec793ff1946da1
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+072814ec793ff1946...@syzkaller.appspotmail.com

WARNING: CPU: 1 PID: 12512 at kernel/locking/lockdep.c:1024  
lockdep_register_key+0x10d/0x490 kernel/locking/lockdep.c:1024

Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 12512 Comm: syz-executor.4 Not tainted 5.0.0-rc8-next-20190301  
#1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 panic+0x2cb/0x65c kernel/panic.c:214
 __warn.cold+0x20/0x45 kernel/panic.c:571
 report_bug+0x263/0x2b0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:179 [inline]
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:lockdep_register_key+0x10d/0x490 kernel/locking/lockdep.c:1024
Code: 75 23 e9 e5 01 00 00 48 89 da 48 c1 ea 03 42 80 3c 3a 00 0f 85 b1 02  
00 00 48 8b 1b 48 85 db 0f 84 c7 01 00 00 4c 39 e3 75 dd <0f> 0b 48 c7 c0  
f8 55 5e 89 48 ba 00 00 00 00 00 fc ff df 48 89 c1

RSP: :8881d7ce79a0 EFLAGS: 00010046
RAX: dc00 RBX: 88809152d698 RCX: 112bcabf
RDX: 1146832f RSI:  RDI: 88809f98ee3c
RBP: 8881d7ce79d0 R08: 8a341978 R09: ed103af9cf29
R10: ed103af9cf28 R11: 0003 R12: 88809152d698
R13: 0e5b R14: 0286 R15: dc00
 wq_init_lockdep kernel/workqueue.c:3444 [inline]
 alloc_workqueue+0x427/0xe70 kernel/workqueue.c:4263
 tipc_topsrv_work_start net/tipc/topsrv.c:615 [inline]
 tipc_topsrv_start+0x536/0xb90 net/tipc/topsrv.c:659
 tipc_init_net+0x397/0x550 net/tipc/core.c:78
 ops_init+0xb6/0x410 net/core/net_namespace.c:129
 setup_net+0x2c5/0x730 net/core/net_namespace.c:314
 copy_net_ns+0x1d9/0x340 net/core/net_namespace.c:437
 create_new_namespaces+0x400/0x7b0 kernel/nsproxy.c:107
 unshare_nsproxy_namespaces+0xc2/0x200 kernel/nsproxy.c:206
 ksys_unshare+0x440/0x980 kernel/fork.c:2550
 __do_sys_unshare kernel/fork.c:2618 [inline]
 __se_sys_unshare kernel/fork.c:2616 [inline]
 __x64_sys_unshare+0x31/0x40 kernel/fork.c:2616
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f58bcbbdc78 EFLAGS: 0246 ORIG_RAX: 0110
RAX: ffda RBX: 0001 RCX: 00457e29
RDX:  RSI:  RDI: 4000
RBP: 0073bf00 R08:  R09: 
R10:  R11: 0246 R12: 7f58bcbbe6d4
R13: 004c6c3b R14: 004dc3f8 R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.


BUG: MAX_STACK_TRACE_ENTRIES too low!

2019-03-01 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:c63e9e91a254 Add linux-next specific files for 20190301
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16a559b2c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=f5875f9dc6e009b2
dashboard link: https://syzkaller.appspot.com/bug?extid=78923eea7cf44364f4fb
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+78923eea7cf44364f...@syzkaller.appspotmail.com

BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
CPU: 0 PID: 19385 Comm: syz-executor.0 Not tainted 5.0.0-rc8-next-20190301  
#1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 save_trace kernel/locking/lockdep.c:467 [inline]
 save_trace.cold+0x14/0x19 kernel/locking/lockdep.c:437
 mark_lock+0x2fb/0x1380 kernel/locking/lockdep.c:3401
 __lock_acquire+0x548/0x3fb0 kernel/locking/lockdep.c:3648
 lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4202
 flush_workqueue+0x126/0x14c0 kernel/workqueue.c:2774
 drain_workqueue+0x1b4/0x470 kernel/workqueue.c:2939
 destroy_workqueue+0x21/0x700 kernel/workqueue.c:4315
 xfs_destroy_mount_workqueues+0x11d/0x1c0 fs/xfs/xfs_super.c:906
 xfs_fs_fill_super+0x8e9/0x1670 fs/xfs/xfs_super.c:1786
 mount_bdev+0x307/0x3c0 fs/super.c:1346
 xfs_fs_mount+0x35/0x40 fs/xfs/xfs_super.c:1834
 legacy_get_tree+0xf2/0x200 fs/fs_context.c:584
 vfs_get_tree+0x123/0x450 fs/super.c:1481
 do_new_mount fs/namespace.c:2622 [inline]
 do_mount+0x1436/0x2c40 fs/namespace.c:2942
 ksys_mount+0xdb/0x150 fs/namespace.c:3151
 __do_sys_mount fs/namespace.c:3165 [inline]
 __se_sys_mount fs/namespace.c:3162 [inline]
 __x64_sys_mount+0xbe/0x150 fs/namespace.c:3162
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45a89a
Code: b8 a6 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 2d 8e fb ff c3 66 2e 0f  
1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 0a 8e fb ff c3 66 0f 1f 84 00 00 00 00 00

RSP: 002b:7f6d038b0a88 EFLAGS: 0206 ORIG_RAX: 00a5
RAX: ffda RBX: 7f6d038b0b30 RCX: 0045a89a
RDX: 7f6d038b0ad0 RSI: 2140 RDI: 7f6d038b0af0
RBP: 2140 R08: 7f6d038b0b30 R09: 7f6d038b0ad0
R10:  R11: 0206 R12: 0003
R13:  R14: 004dbde0 R15: 


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.


kernel BUG at include/linux/mm.h:LINE! (4)

2019-03-01 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:42fd8df9d1d9 Add linux-next specific files for 20190228
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c3cd5cc0
kernel config:  https://syzkaller.appspot.com/x/.config?x=c0f38652d28b522f
dashboard link: https://syzkaller.appspot.com/bug?extid=cc252aa9d2d3b576246f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cc252aa9d2d3b5762...@syzkaller.appspotmail.com

page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
page->mem_cgroup:888059786cc0
[ cut here ]
kernel BUG at include/linux/mm.h:579!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 22405 Comm: syz-executor.3 Not tainted 5.0.0-rc8-next-20190228  
#45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:put_page_testzero include/linux/mm.h:579 [inline]
RIP: 0010:put_page include/linux/mm.h:1025 [inline]
RIP: 0010:generic_pipe_buf_release+0x120/0x160 fs/pipe.c:224
Code: bd ff 4c 89 e7 e8 90 43 db ff e8 5b 07 bd ff 5b 41 5c 41 5d 5d c3 e8  
4f 07 bd ff 48 c7 c6 60 98 75 87 4c 89 e7 e8 c0 db e4 ff <0f> 0b e8 39 07  
bd ff 4d 8d 65 ff e9 3d ff ff ff 48 89 df e8 e8 f8

RSP: 0018:888056c57920 EFLAGS: 00010246
RAX: 0004 RBX: ea0002283db4 RCX: c9000c456000
RDX: 0004 RSI: 81984e72 RDI: ed100ad8af08
RBP: 888056c57938 R08: 0021 R09: ed1015d05011
R10: ed1015d05010 R11: 8880ae828087 R12: ea0002283d80
R13:  R14: 88809ad3c800 R15: 8880592ac928
FS:  7fb53aaf2700() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fff65e0fdb8 CR3: 93a2f000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 pipe_buf_release include/linux/pipe_fs_i.h:129 [inline]
 iter_file_splice_write+0x7d1/0xbe0 fs/splice.c:759
 do_splice_from fs/splice.c:847 [inline]
 direct_splice_actor+0x126/0x1a0 fs/splice.c:1019
 splice_direct_to_actor+0x369/0x970 fs/splice.c:974
 do_splice_direct+0x1da/0x2a0 fs/splice.c:1062
 do_sendfile+0x597/0xd00 fs/read_write.c:1442
 __do_sys_sendfile64 fs/read_write.c:1503 [inline]
 __se_sys_sendfile64 fs/read_write.c:1489 [inline]
 __x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1489
 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fb53aaf1c78 EFLAGS: 0246 ORIG_RAX: 0028
RAX: ffda RBX: 0004 RCX: 00457e29
RDX:  RSI: 0003 RDI: 0003
RBP: 0073bf00 R08:  R09: 
R10: 00010200 R11: 0246 R12: 7fb53aaf26d4
R13: 004c4dce R14: 004d8af8 R15: 
Modules linked in:
---[ end trace ce17ea3937b628f2 ]---
RIP: 0010:put_page_testzero include/linux/mm.h:579 [inline]
RIP: 0010:put_page include/linux/mm.h:1025 [inline]
RIP: 0010:generic_pipe_buf_release+0x120/0x160 fs/pipe.c:224
Code: bd ff 4c 89 e7 e8 90 43 db ff e8 5b 07 bd ff 5b 41 5c 41 5d 5d c3 e8  
4f 07 bd ff 48 c7 c6 60 98 75 87 4c 89 e7 e8 c0 db e4 ff <0f> 0b e8 39 07  
bd ff 4d 8d 65 ff e9 3d ff ff ff 48 89 df e8 e8 f8

RSP: 0018:888056c57920 EFLAGS: 00010246
RAX: 0004 RBX: ea0002283db4 RCX: c9000c456000
RDX: 0004 RSI: 81984e72 RDI: ed100ad8af08
RBP: 888056c57938 R08: 0021 R09: ed1015d05011
R10: ed1015d05010 R11: 8880ae828087 R12: ea0002283d80
R13:  R14: 88809ad3c800 R15: 8880592ac928
FS:  7fb53aaf2700() GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 001b30225000 CR3: 93a2f000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.


BUG: spinlock bad magic in flush_workqueue_prep_pwqs

2019-03-01 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:7d762d69145a afs: Fix manually set volume location server ..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13044284c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=b76ec970784287c
dashboard link: https://syzkaller.appspot.com/bug?extid=130f0c441448a93a166b
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+130f0c441448a93a1...@syzkaller.appspotmail.com

BUG: spinlock bad magic on CPU#1, syz-executor.2/18168
 lock: 0x8880ae92cd2d, .magic: , .owner: /-1, .owner_cpu:  
0

CPU: 1 PID: 18168 Comm: syz-executor.2 Not tainted 5.0.0-rc8+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 spin_dump.cold+0x81/0xe6 kernel/locking/spinlock_debug.c:67
 spin_bug kernel/locking/spinlock_debug.c:75 [inline]
 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
 do_raw_spin_lock+0x231/0x2e0 kernel/locking/spinlock_debug.c:112
 __raw_spin_lock_irq include/linux/spinlock_api_smp.h:129 [inline]
 _raw_spin_lock_irq+0x68/0x80 kernel/locking/spinlock.c:160
 spin_lock_irq include/linux/spinlock.h:354 [inline]
 flush_workqueue_prep_pwqs+0x1c5/0x590 kernel/workqueue.c:2633
 flush_workqueue+0x54b/0x14c0 kernel/workqueue.c:2704
 capi20_release+0x1e7/0x290 drivers/isdn/capi/kcapi.c:748
 capi_release+0x1cd/0x230 drivers/isdn/capi/capi.c:975
 __fput+0x2df/0x8d0 fs/file_table.c:278
 fput+0x16/0x20 fs/file_table.c:309
 task_work_run+0x14a/0x1c0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f2440e7dc78 EFLAGS: 0246 ORIG_RAX: 0003
RAX:  RBX: 0001 RCX: 00457e29
RDX:  RSI:  RDI: 0003
RBP: 0073bf00 R08:  R09: 
R10:  R11: 0246 R12: 7f2440e7e6d4
R13: 004f4d52 R14: 004ce8f8 R15: 
kobject: 'loop0' (06336e0b): kobject_uevent_env
kobject: 'loop0' (06336e0b): fill_kobj_path: path  
= '/devices/virtual/block/loop0'

kobject: 'kvm' (400fec10): kobject_uevent_env
kobject: 'kvm' (400fec10): fill_kobj_path: path  
= '/devices/virtual/misc/kvm'

kobject: 'loop0' (06336e0b): kobject_uevent_env
kobject: 'kvm' (400fec10): kobject_uevent_env
kobject: 'loop0' (06336e0b): fill_kobj_path: path  
= '/devices/virtual/block/loop0'
kobject: 'kvm' (400fec10): fill_kobj_path: path  
= '/devices/virtual/misc/kvm'

kobject: 'loop2' (cd9c1962): kobject_uevent_env
kobject: 'loop2' (cd9c1962): fill_kobj_path: path  
= '/devices/virtual/block/loop2'

kobject: 'kvm' (400fec10): kobject_uevent_env
kobject: 'loop3' (f8ccfb34): kobject_uevent_env
kobject: 'loop3' (f8ccfb34): fill_kobj_path: path  
= '/devices/virtual/block/loop3'

kobject: 'loop0' (06336e0b): kobject_uevent_env
kobject: 'kvm' (400fec10): fill_kobj_path: path  
= '/devices/virtual/misc/kvm'
kobject: 'loop0' (06336e0b): fill_kobj_path: path  
= '/devices/virtual/block/loop0'

kobject: 'loop1' (dacfac08): kobject_uevent_env
kobject: 'loop1' (dacfac08): fill_kobj_path: path  
= '/devices/virtual/block/loop1'

kobject: 'loop5' (522745e2): kobject_uevent_env
kobject: 'loop5' (522745e2): fill_kobj_path: path  
= '/devices/virtual/block/loop5'

kobject: 'kvm' (400fec10): kobject_uevent_env
kobject: 'kvm' (400fec10): fill_kobj_path: path  
= '/devices/virtual/misc/kvm'

kobject: 'loop4' (a4ac2be3): kobject_uevent_env
kobject: 'loop4' (a4ac2be3): fill_kobj_path: path  
= '/devices/virtual/block/loop4'

kobject: 'kvm' (400fec10): kobject_uevent_env
kobject: 'loop2' (cd9c1962): kobject_uevent_env
kobject: 'kvm' (400fec10): fill_kobj_path: path  
= '/devices/virtual/misc/kvm'
kobject: 'loop2' (cd9c1962): fill_kobj_path: path  
= '/devices/virtual/block/loop2'

kobject: 'loop0' (06336e0b): kobject_uevent_env
kobject: 'kvm' (400fec10): kobject_uevent_env
kobject: 'loop0' (06336e0b): 

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

2019-03-01 Thread Leizhen (ThunderTown)



On 2019/3/1 19:07, Jean-Philippe Brucker wrote:
> Hi Leizhen,
> 
> On 01/03/2019 04:44, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2019/2/26 20:36, Hanjun Guo wrote:
>>> Hi Jean,
>>>
>>> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
 Hi,

 On 31/01/2019 13:52, Zhen Lei wrote:
> Currently, many peripherals are faster than before. For example, the top
> speed of the older netcard is 10Gb/s, and now it's more than 25Gb/s. But
> when iommu page-table mapping enabled, it's hard to reach the top speed
> in strict mode, because of frequently map and unmap operations. In order
> to keep abreast of the times, I think it's better to set non-strict as
> default.

 Most users won't be aware of this relaxation and will have their system
 vulnerable to e.g. thunderbolt hotplug. See for example 4.3 Deferred
 Invalidation in
 http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2018/MSC/MSC-2018-21.pdf
>> Hi Jean,
>>
>>In fact, we have discussed the vulnerable of deferred invalidation before 
>> upstream
>> the non-strict patches. The attacks maybe possible because of an untrusted 
>> device or
>> the mistake of the device driver. And we limited the VFIO to still use 
>> strict mode.
>>As mentioned in the pdf, limit the freed memory with deferred 
>> invalidation only to
>> be reused by the device, can mitigate the vulnerability. But it's too hard 
>> to implement
>> it now.
>>A compromise maybe we only apply non-strict to (1) dma_free_coherent, 
>> because the
>> memory is controlled by DMA common module, so we can make the memory to be 
>> freed after
>> the global invalidation in the timer handler. (2) And provide some new APIs 
>> related to
>> iommu_unmap_page/sg, these new APIs deferred invalidation. And the candiate 
>> device
>> drivers update the APIs if they want to improve performance. (3) Make sure 
>> that only
>> the trusted devices and trusted drivers can apply (1) and (2). For example, 
>> the driver
>> must be built into kernel Image.
> 
> Do we have a notion of untrusted kernel drivers? A userspace driver
It seems impossible to have such driver. The modules insmod by root users 
should be
guaranteed by themselves.

> (VFIO) is untrusted, ok. But a malicious driver loaded into the kernel
> address space would have much easier ways to corrupt the system than to
> exploit lazy mode...
Yes, so that we have no need to consider untrusted drivers.

> 
> For (3), I agree that we should at least disallow lazy mode if
> pci_dev->untrusted is set. At the moment it means that we require the
> strictest IOMMU configuration for external-facing PCI ports, but it can
> be extended to blacklist other vulnerable devices or locations.
I plan to add an attribute file for each device, espcially for hotplug devices. 
And
let the root users to decide which mode should be used, strict or non-strict. 
Becasue
they should known whether the hot-plug divice is trusted or not.

> 
> If you do (3) then maybe we don't need (1) and (2), which require a
> tonne of work in the DMA and IOMMU layers (but would certainly be nice
> to see, since it would also help handle ATS invalidation timeouts)
> 
> Thanks,
> Jean
> 
>>So that some high-end trusted devices use non-strict mode, and keep 
>> others still using
>> strict mode. The drivers who want to use non-strict mode, should change to 
>> use new APIs
>> by themselves.
>>
>>

 Why not keep the policy to secure by default, as we do for
 iommu.passthrough? And maybe add something similar to
 CONFIG_IOMMU_DEFAULT_PASSTRHOUGH? It's easy enough for experts to pass a
 command-line argument or change the default config.
>>>
>>> Sorry for the late reply, it was Chinese new year, and we had a long 
>>> discussion
>>> internally, we are fine to add a Kconfig but not sure OS vendors will set it
>>> to default y.
>>>
>>> OS vendors seems not happy to pass a command-line argument, to be honest,
>>> this is our motivation to enable non-strict as default. Hope OS vendors
>>> can see this email thread, and give some input here.
>>>
>>> Thanks
>>> Hanjun
>>>
>>>
>>> .
>>>
>>
> 
> 
> .
> 

-- 
Thanks!
BestRegards



Re: [PATCH 1/2] CIFS: Fix a bug with re-sending wdata when transport returning -EAGAIN

2019-03-01 Thread Steve French
I tested this vs. Samba a few minutes ago with test 208 - looks like
it works.   Thank you!

Now just need some additional reviews as this can be a complex area of code.

On Fri, Mar 1, 2019 at 9:04 PM Long Li  wrote:
>
> From: Long Li 
>
> When sending a wdata, transport may return -EAGAIN. In this case
> we should re-obtain credits because the session may have been
> reconnected.
>
> Signed-off-by: Long Li 
> ---
>  fs/cifs/file.c | 61 +-
>  1 file changed, 31 insertions(+), 30 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 9b53f33137b3..08e73759d6ec 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -2620,43 +2620,44 @@ cifs_resend_wdata(struct cifs_writedata *wdata, 
> struct list_head *wdata_list,
> struct TCP_Server_Info *server =
> tlink_tcon(wdata->cfile->tlink)->ses->server;
>
> -   /*
> -* Wait for credits to resend this wdata.
> -* Note: we are attempting to resend the whole wdata not in segments
> -*/
> do {
> -   rc = server->ops->wait_mtu_credits(server, wdata->bytes, 
> ,
> -  );
> -
> -   if (rc)
> -   goto out;
> -
> -   if (wsize < wdata->bytes) {
> -   add_credits_and_wake_if(server, , 0);
> -   msleep(1000);
> -   }
> -   } while (wsize < wdata->bytes);
> +   /*
> +* Wait for credits to resend this wdata.
> +* Note: we are attempting to resend the whole wdata not in
> +* segments
> +*/
> +   do {
> +   rc = server->ops->wait_mtu_credits(server, 
> wdata->bytes,
> +   , );
> +   if (rc)
> +   goto fail;
> +
> +   if (wsize < wdata->bytes) {
> +   add_credits_and_wake_if(server, , 0);
> +   msleep(1000);
> +   }
> +   } while (wsize < wdata->bytes);
>
> -   wdata->credits = credits;
> -   rc = -EAGAIN;
> -   while (rc == -EAGAIN) {
> +   wdata->credits = credits;
> rc = 0;
> if (wdata->cfile->invalidHandle)
> rc = cifs_reopen_file(wdata->cfile, false);
> if (!rc)
> rc = server->ops->async_writev(wdata,
> -   cifs_uncached_writedata_release);
> -   }
> +   cifs_uncached_writedata_release);
>
> -   if (!rc) {
> -   list_add_tail(>list, wdata_list);
> -   return 0;
> -   }
> +   /* If the write was successfully sent, we are done */
> +   if (!rc) {
> +   list_add_tail(>list, wdata_list);
> +   return 0;
> +   }
>
> -   add_credits_and_wake_if(server, >credits, 0);
> -out:
> -   kref_put(>refcount, cifs_uncached_writedata_release);
> +   /* Roll back credits and retry if needed */
> +   add_credits_and_wake_if(server, >credits, 0);
> +   } while (rc == -EAGAIN);
>
> +fail:
> +   kref_put(>refcount, cifs_uncached_writedata_release);
> return rc;
>  }
>
> @@ -2884,12 +2885,12 @@ static void collect_uncached_write_data(struct 
> cifs_aio_ctx *ctx)
> wdata->bytes, _from,
> ctx->cfile, cifs_sb, 
> _list,
> ctx);
> +
> +   kref_put(>refcount,
> +   
> cifs_uncached_writedata_release);
> }
>
> list_splice(_list, >list);
> -
> -   kref_put(>refcount,
> -cifs_uncached_writedata_release);
> goto restart_loop;
> }
> }
> --
> 2.17.1
>


-- 
Thanks,

Steve


Re: [PATCH net-next] switchdev: Remove unused transaction item queue

2019-03-01 Thread David Miller
From: Florian Fainelli 
Date: Wed, 27 Feb 2019 16:29:16 -0800

> There are no more in tree users of the
> switchdev_trans_item_{dequeue,enqueue} or switchdev_trans_item structure
> in the kernel since commit 00fc0c51e35b ("rocker: Change world_ops API
> and implementation to be switchdev independant").
> 
> Remove this unused code and update the documentation accordingly since.
> 
> Signed-off-by: Florian Fainelli 

Applied, thanks Florian.


[PATCH V1 10/11] mmc: tegra: fix CQE resume sequence

2019-03-01 Thread Sowjanya Komatineni
Tegra CQHCI/SDHCI design prevents write access to SDHCI block size
register when CQE is enabled and unhalted.

CQHCI driver enabled CQE prior to invoking sdhci_cqe_enable which
violates this Tegra specific host requirement.

This patch fixes this by configuring sdhci block registers prior
to CQE unhalt.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 71 --
 1 file changed, 62 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 2b63626dc2fa..7063cfcdc590 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1126,23 +1126,75 @@ static void tegra_sdhci_voltage_switch(struct 
sdhci_host *host)
tegra_host->pad_calib_required = true;
 }
 
+static void tegra_cqhci_writel(struct cqhci_host *cq_host, u32 val, int reg)
+{
+   struct mmc_host *mmc = cq_host->mmc;
+   u8 ctrl;
+   ktime_t timeout;
+   bool timed_out;
+
+   /*
+* During CQE resume/unhalt, CQHCI driver unhalts CQE prior to
+* cqhci_host_ops enable where SDHCI DMA and BLOCK_SIZE registers need
+* to be re-configured.
+* Tegra CQHCI/SDHCI prevents write access to block size register when
+* CQE is unhalted. So handling CQE resume sequence here to configure
+* SDHCI block registers prior to exiting CQE halt state.
+*/
+   if (reg == CQHCI_CTL && !(val & CQHCI_HALT) &&
+   cqhci_readl(cq_host, CQHCI_CTL) & CQHCI_HALT) {
+   sdhci_cqe_enable(mmc);
+   writel(val, cq_host->mmio + reg);
+   timeout = ktime_add_us(ktime_get(), 50);
+   while (1) {
+   timed_out = ktime_compare(ktime_get(), timeout) > 0;
+   ctrl = cqhci_readl(cq_host, CQHCI_CTL);
+   if (!(ctrl & CQHCI_HALT) || timed_out)
+   break;
+   }
+   /*
+* CQE usually resumes very quick, but incase if Tegra CQE
+* doesn't resume retry unhalt.
+*/
+   if (timed_out)
+   writel(val, cq_host->mmio + reg);
+   } else {
+   writel(val, cq_host->mmio + reg);
+   }
+}
+
 static void sdhci_tegra_cqe_enable(struct mmc_host *mmc)
 {
struct cqhci_host *cq_host = mmc->cqe_private;
-   u32 cqcfg = 0;
+   u32 val;
 
/*
-* Tegra SDMMC Controller design prevents write access to BLOCK_COUNT
-* registers when CQE is enabled.
+* Tegra CQHCI/SDMMC design prevents write access to sdhci block size
+* register when CQE is enabled and unhalted.
+* CQHCI driver enables CQE prior to activation, so disable CQE before
+* programming block size in sdhci controller and enable it back.
 */
-   cqcfg = cqhci_readl(cq_host, CQHCI_CFG);
-   if (cqcfg & CQHCI_ENABLE)
-   cqhci_writel(cq_host, (cqcfg & ~CQHCI_ENABLE), CQHCI_CFG);
+   if (!cq_host->activated) {
+   val = cqhci_readl(cq_host, CQHCI_CFG);
+   if (val & CQHCI_ENABLE)
+   cqhci_writel(cq_host, (val & ~CQHCI_ENABLE),
+CQHCI_CFG);
+   sdhci_cqe_enable(mmc);
+   if (val & CQHCI_ENABLE)
+   cqhci_writel(cq_host, val, CQHCI_CFG);
+   }
 
-   sdhci_cqe_enable(mmc);
+   /*
+* CMD CRC errors are seen sometimes with some eMMC devices when status
+* command is sent during transfer of last data block which is the
+* default case as send status command block counter (CBC) is 1.
+* So changing send status command block counter (CBC) to 0 to allow
+* send status command only when the data lines are idle.
+*/
+   val = cqhci_readl(cq_host, CQHCI_SSC1);
+   val &= ~CQHCI_SSC1_CBC_MASK;
+   cqhci_writel(cq_host, val, CQHCI_SSC1);
 
-   if (cqcfg & CQHCI_ENABLE)
-   cqhci_writel(cq_host, cqcfg, CQHCI_CFG);
 }
 
 static void sdhci_tegra_dumpregs(struct mmc_host *mmc)
@@ -1167,6 +1219,7 @@ static const struct cqhci_host_ops sdhci_tegra_cqhci_ops 
= {
.enable = sdhci_tegra_cqe_enable,
.disable = sdhci_cqe_disable,
.dumpregs = sdhci_tegra_dumpregs,
+   .write_l= tegra_cqhci_writel,
 };
 
 static const struct sdhci_ops tegra_sdhci_ops = {
-- 
2.7.4



[PATCH V1 11/11] arm64: tegra: enable command queue for tegra186 sdmmc4

2019-03-01 Thread Sowjanya Komatineni
This patch enables command queue support for Tegra186 SDMMC4.

Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 472f55fe9488..6e2b6ce99df2 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -321,6 +321,7 @@
nvidia,default-trim = <0x5>;
nvidia,dqs-trim = <63>;
mmc-hs400-1_8v;
+   supports-cqe;
status = "disabled";
};
 
-- 
2.7.4



[PATCH V1 08/11] mmc: tegra: add Tegra186 WAR for CQE

2019-03-01 Thread Sowjanya Komatineni
Tegra186 design has a known bug where CQE does not generated task
complete interrupt for data transfer tasks issued after DCMD task
with R1b response type and results in timeout.

SW WAR is to set CMD_TIMING to 1 in task descriptor for DCMDs with
R1b response type. This bug and SW WAR is applicable only for
Tegra186 and not for Tegra194.

This patch adds this WAR to Tegra186.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 2086e0eced88..2b63626dc2fa 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -116,6 +116,7 @@ struct sdhci_tegra_soc_data {
u32 nvquirks;
u8 min_tap_delay;
u8 max_tap_delay;
+   u32 cqequirks;
 };
 
 /* Magic pull up and pull down pad calibration offsets */
@@ -1354,6 +1355,7 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra186 = {
NVQUIRK_ENABLE_SDR104,
.min_tap_delay = 84,
.max_tap_delay = 136,
+   .cqequirks = CQHCI_QUIRK_CMD_TIMING_R1B_DCMD,
 };
 
 static const struct sdhci_tegra_soc_data soc_data_tegra194 = {
@@ -1383,6 +1385,7 @@ static int sdhci_tegra_add_host(struct sdhci_host *host)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
+   const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
struct cqhci_host *cq_host;
bool dma64;
int ret;
@@ -1407,6 +1410,7 @@ static int sdhci_tegra_add_host(struct sdhci_host *host)
 
cq_host->mmio = host->ioaddr + SDHCI_TEGRA_CQE_BASE_ADDR;
cq_host->ops = _tegra_cqhci_ops;
+   cq_host->quirks = soc_data->cqequirks;
 
dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
if (dma64)
-- 
2.7.4



[PATCH V1 09/11] mmc: cqhci: add CQHCI_SSC1 register CBC field mask

2019-03-01 Thread Sowjanya Komatineni
This patch adds define for CBC field mask of the register
CQHCI_SSC1.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/cqhci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h
index f96d8565cc07..f1dc48c7436f 100644
--- a/drivers/mmc/host/cqhci.h
+++ b/drivers/mmc/host/cqhci.h
@@ -88,6 +88,7 @@
 
 /* send status config 1 */
 #define CQHCI_SSC1 0x40
+#define CQHCI_SSC1_CBC_MASKGENMASK(19, 16)
 
 /* send status config 2 */
 #define CQHCI_SSC2 0x44
-- 
2.7.4



[PATCH V1 04/11] mmc: tegra: update hw tuning process

2019-03-01 Thread Sowjanya Komatineni
This patch includes below HW tuning related fixes.
- configures tuning parameters as per Tegra TRM
- WAR fix for manual tap change
- HW auto-tuning post process

As per Tegra TRM, SDR50 mode tuning execution takes upto maximum
of 256 tuning iterations and SDR104/HS200/HS400 modes tuning
execution takes upto maximum of 128 tuning iterations.

This patch programs tuning control register with maximum tuning
iterations needed based on the timing along with the start tap,
multiplier, and step size used by the HW tuning.

Tegra210 has a known issue of glitch on trimmer output when the
tap value is changed with the trimmer input clock running and the
WAR is to disable card clock before sending tuning command and
after sending tuning command wait for 1usec and issue SW reset
followed by enabling card clock.

This WAR is applicable when changing tap value manually as well.
Tegra SDHCI driver has this implemented correctly for manual tap
change but missing SW reset before enabling card clock during
sending tuning command.

Issuing SW reset during tuning command as a part of WAR and is
applicable in cases where tuning is performed with single step size
for more iterations. This patch includes this fix.

HW auto-tuning finds the best largest passing window and sets the
tap at the middle of the window. With some devices like sandisk
eMMC driving fast edges and due to high tap to tap delay in the
Tegra chipset, auto-tuning does not detect falling tap between the
valid windows resulting in a parital window or a merged window and
the best tap is set at the signal transition which is actually the
worst tap location.

Recommended SW solution is to detect if the best passing window
picked by the HW tuning is a partial or a merged window based on
min and max tap delays found from chip characterization across
PVT and perform tuning correction to pick the best tap.

This patch has this implemention of post tuning and uses tuned tap
delay.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 218 -
 1 file changed, 217 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 46086dd43bfb..2086e0eced88 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -66,6 +66,23 @@
 
 #define SDHCI_VNDR_TUN_CTRL0_0 0x1c0
 #define SDHCI_VNDR_TUN_CTRL0_TUN_HW_TAP0x2
+#define SDHCI_VNDR_TUN_CTRL0_START_TAP_VAL_MASK0x03fc
+#define SDHCI_VNDR_TUN_CTRL0_START_TAP_VAL_SHIFT   18
+#define SDHCI_VNDR_TUN_CTRL0_MUL_M_MASK0x1fc0
+#define SDHCI_VNDR_TUN_CTRL0_MUL_M_SHIFT   6
+#define SDHCI_VNDR_TUN_CTRL0_TUN_ITER_MASK 0x000e000
+#define SDHCI_VNDR_TUN_CTRL0_TUN_ITER_SHIFT13
+#define TRIES_40   0
+#define TRIES_128  2
+#define TRIES_256  4
+#define SDHCI_VNDR_TUN_CTRL0_TUN_WORD_SEL_MASK 0x7
+
+#define SDHCI_TEGRA_VNDR_TUN_CTRL1_0   0x1c4
+#define SDHCI_TEGRA_VNDR_TUN_STATUS0   0x1C8
+#define SDHCI_TEGRA_VNDR_TUN_STATUS1   0x1CC
+#define SDHCI_TEGRA_VNDR_TUN_STATUS1_TAP_MASK  0xFF
+#define SDHCI_TEGRA_VNDR_TUN_STATUS1_END_TAP_SHIFT 0x8
+#define TUNING_WORD_BIT_SIZE   32
 
 #define SDHCI_TEGRA_AUTO_CAL_CONFIG0x1e4
 #define SDHCI_AUTO_CAL_START   BIT(31)
@@ -97,6 +114,8 @@
 struct sdhci_tegra_soc_data {
const struct sdhci_pltfm_data *pdata;
u32 nvquirks;
+   u8 min_tap_delay;
+   u8 max_tap_delay;
 };
 
 /* Magic pull up and pull down pad calibration offsets */
@@ -136,6 +155,8 @@ struct sdhci_tegra {
u32 default_trim;
u32 dqs_trim;
bool enable_hwcq;
+   unsigned long curr_clk_rate;
+   u8 tuned_tap_delay;
 };
 
 static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
@@ -241,6 +262,7 @@ static void tegra210_sdhci_writew(struct sdhci_host *host, 
u16 val, int reg)
 
if (is_tuning_cmd) {
udelay(1);
+   sdhci_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
tegra_sdhci_configure_card_clk(host, clk_enabled);
}
 }
@@ -722,6 +744,7 @@ static void tegra_sdhci_set_clock(struct sdhci_host *host, 
unsigned int clock)
 */
host_clk = tegra_host->ddr_signaling ? clock * 2 : clock;
clk_set_rate(pltfm_host->clk, host_clk);
+   tegra_host->curr_clk_rate = host_clk;
if (tegra_host->ddr_signaling)
host->max_clk = host_clk;
else
@@ -770,6 +793,162 @@ static void tegra_sdhci_hs400_dll_cal(struct sdhci_host 
*host)
"HS400 delay line calibration timed out\n");
 }
 
+static int tegra_sdhci_get_max_tuning_loop(struct sdhci_host *host)
+{
+   u32 val;

[PATCH V1 07/11] mmc: cqhci: add quirk for setting DCMD CMD_TIMING

2019-03-01 Thread Sowjanya Komatineni
This patch adds a quirk for setting CMD_TIMING to 1 in descriptor
for DCMD with R1B response type to allow the command to be sent to
device during data activity or busy time.

Tegra186 CQHCI host has bug where it selects DATA_PRESENT_SELECT
to 1 by CQHCI controller for DCMDs with R1B response type and
since DCMD does not trigger any data transfer, DCMD task complete
happens leaving the DATA FSM of host controller in wait state for
data.

This effects the data transfer task issued after R1B DCMD task
and no interrupt is generated for the data transfer task.

SW WAR for this issue is to set CMD_TIMING bit to 1 in DCMD task
descriptor and as DCMD task descriptor preparation is done by
cqhci driver, this patch adds cqequirk to handle this.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/cqhci.c | 5 -
 drivers/mmc/host/cqhci.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
index a8af682a9182..b34c07125f32 100644
--- a/drivers/mmc/host/cqhci.c
+++ b/drivers/mmc/host/cqhci.c
@@ -521,7 +521,10 @@ static void cqhci_prep_dcmd_desc(struct mmc_host *mmc,
} else {
if (mrq->cmd->flags & MMC_RSP_R1B) {
resp_type = 0x3;
-   timing = 0x0;
+   if (cq_host->quirks & CQHCI_QUIRK_CMD_TIMING_R1B_DCMD)
+   timing = 0x1;
+   else
+   timing = 0x0;
} else {
resp_type = 0x2;
timing = 0x1;
diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h
index 9e68286a07b4..f96d8565cc07 100644
--- a/drivers/mmc/host/cqhci.h
+++ b/drivers/mmc/host/cqhci.h
@@ -170,6 +170,7 @@ struct cqhci_host {
 
u32 quirks;
 #define CQHCI_QUIRK_SHORT_TXFR_DESC_SZ 0x1
+#define CQHCI_QUIRK_CMD_TIMING_R1B_DCMD0x2
 
bool enabled;
bool halted;
-- 
2.7.4



[PATCH V1 05/11] dt-bindings: mmc: tegra: document Tegra194 compatible string

2019-03-01 Thread Sowjanya Komatineni
SDHCI controller of Tegra194 is similar to SDHCI controller in Tegra186.
This patch documents Tegra194 sdhci compatible string.

Signed-off-by: Sowjanya Komatineni 
---
 Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt 
b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
index 2cecdc71d94c..2cf3affa1be7 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
@@ -14,6 +14,7 @@ Required properties:
   - "nvidia,tegra124-sdhci": for Tegra124 and Tegra132
   - "nvidia,tegra210-sdhci": for Tegra210
   - "nvidia,tegra186-sdhci": for Tegra186
+  - "nvidia,tegra194-sdhci": for Tegra194
 - clocks : Must contain one entry, for the module clock.
   See ../clocks/clock-bindings.txt for details.
 - resets : Must contain an entry for each entry in reset-names.
-- 
2.7.4



[PATCH V1 02/11] mmc: sdhci: allow host to specify maximum tuning loops

2019-03-01 Thread Sowjanya Komatineni
As per the Host Controller Standard Specification Version 4.20,
limitation of tuning iteration count is removed as PLL locking
time can be longer than UHS-1 tuning due to larger PVT fluctuation
and it will result in increase of tuning iteration to complete the
tuning.

This patch creates a hook get_max_tuning_loop_count to allow hosts
to specify maximum tuning iterations and updates execute_tuning
to use the specified maximum tuning iteration count.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci.c | 7 +--
 drivers/mmc/host/sdhci.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a8141ff9be03..e9e919218006 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2366,12 +2366,15 @@ EXPORT_SYMBOL_GPL(sdhci_send_tuning);
 static int __sdhci_execute_tuning(struct sdhci_host *host, u32 opcode)
 {
int i;
+   int tuning_loop_count = MAX_TUNING_LOOP;
 
+   if (host->ops->get_max_tuning_loop_count)
+   tuning_loop_count = host->ops->get_max_tuning_loop_count(host);
/*
 * Issue opcode repeatedly till Execute Tuning is set to 0 or the number
-* of loops reaches 40 times.
+* of loops reaches tuning loop count.
 */
-   for (i = 0; i < MAX_TUNING_LOOP; i++) {
+   for (i = 0; i < tuning_loop_count; i++) {
u16 ctrl;
 
sdhci_send_tuning(host, opcode);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 01002cba1359..c80e0d6f9b10 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -638,6 +638,7 @@ struct sdhci_ops {
unsigned int(*get_ro)(struct sdhci_host *host);
void(*reset)(struct sdhci_host *host, u8 mask);
int (*platform_execute_tuning)(struct sdhci_host *host, u32 opcode);
+   int (*get_max_tuning_loop_count)(struct sdhci_host *host);
void(*set_uhs_signaling)(struct sdhci_host *host, unsigned int uhs);
void(*hw_reset)(struct sdhci_host *host);
void(*adma_workaround)(struct sdhci_host *host, u32 intmask);
-- 
2.7.4



[PATCH V1 03/11] mmc: sdhci: add support for post tuning process

2019-03-01 Thread Sowjanya Komatineni
This patch adds support for post tuning process needed for some hosts
to perform after successful completion of HW tuning.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci.c | 6 +-
 drivers/mmc/host/sdhci.h | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e9e919218006..976d4d1e2400 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2392,8 +2392,12 @@ static int __sdhci_execute_tuning(struct sdhci_host 
*host, u32 opcode)
 
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
if (!(ctrl & SDHCI_CTRL_EXEC_TUNING)) {
-   if (ctrl & SDHCI_CTRL_TUNED_CLK)
+   if (ctrl & SDHCI_CTRL_TUNED_CLK) {
+   if (host->ops->post_tuning)
+   host->ops->post_tuning(host);
return 0; /* Success! */
+   }
+
break;
}
 
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c80e0d6f9b10..236d67778645 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -639,6 +639,7 @@ struct sdhci_ops {
void(*reset)(struct sdhci_host *host, u8 mask);
int (*platform_execute_tuning)(struct sdhci_host *host, u32 opcode);
int (*get_max_tuning_loop_count)(struct sdhci_host *host);
+   void(*post_tuning)(struct sdhci_host *host);
void(*set_uhs_signaling)(struct sdhci_host *host, unsigned int uhs);
void(*hw_reset)(struct sdhci_host *host);
void(*adma_workaround)(struct sdhci_host *host, u32 intmask);
-- 
2.7.4



[PATCH V1 06/11] arm64: tegra: fix default tap and trim values

2019-03-01 Thread Sowjanya Komatineni
Default tap and trim values are incorrect for Tegra186 SDMMC4.
This patch fixes it.

Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 97aeb946ed5e..472f55fe9488 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -317,8 +317,8 @@
nvidia,pad-autocal-pull-down-offset-1v8-timeout = <0x0a>;
nvidia,pad-autocal-pull-up-offset-3v3-timeout = <0x0a>;
nvidia,pad-autocal-pull-down-offset-3v3-timeout = <0x0a>;
-   nvidia,default-tap = <0x5>;
-   nvidia,default-trim = <0x9>;
+   nvidia,default-tap = <0x9>;
+   nvidia,default-trim = <0x5>;
nvidia,dqs-trim = <63>;
mmc-hs400-1_8v;
status = "disabled";
-- 
2.7.4



[PATCH V1 01/11] mmc: tegra: fix ddr signaling for non-ddr modes

2019-03-01 Thread Sowjanya Komatineni
ddr_signaling is set to true for DDR50 and DDR52 modes but is
not set back to false for other modes. This programs incorrect
host clock when mode change happens from DDR52/DDR50 to other
SDR or HS modes like incase of mmc_retune where it switches
from HS400 to HS DDR and then from HS DDR to HS mode and then
to HS200.

This patch fixes the ddr_signaling to set properly for non DDR
modes.

Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 32e62904c0d3..46086dd43bfb 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -779,6 +779,7 @@ static void tegra_sdhci_set_uhs_signaling(struct sdhci_host 
*host,
bool set_dqs_trim = false;
bool do_hs400_dll_cal = false;
 
+   tegra_host->ddr_signaling = false;
switch (timing) {
case MMC_TIMING_UHS_SDR50:
case MMC_TIMING_UHS_SDR104:
-- 
2.7.4



[PATCH] mm: compaction: some tracepoints should be defined only when CONFIG_COMPACTION is set

2019-03-01 Thread Yafang Shao
Only mm_compaction_isolate_{free, migrate}pages may be used when
CONFIG_COMPACTION is not set.
All others are used only when CONFIG_COMPACTION is set.

Signed-off-by: Yafang Shao 
---
 include/trace/events/compaction.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/compaction.h 
b/include/trace/events/compaction.h
index 6074eff..3e42078 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -64,6 +64,7 @@
TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
 );
 
+#ifdef CONFIG_COMPACTION
 TRACE_EVENT(mm_compaction_migratepages,
 
TP_PROTO(unsigned long nr_all,
@@ -132,7 +133,6 @@
__entry->sync ? "sync" : "async")
 );
 
-#ifdef CONFIG_COMPACTION
 TRACE_EVENT(mm_compaction_end,
TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
unsigned long free_pfn, unsigned long zone_end, bool sync,
@@ -166,7 +166,6 @@
__entry->sync ? "sync" : "async",
__print_symbolic(__entry->status, COMPACTION_STATUS))
 );
-#endif
 
 TRACE_EVENT(mm_compaction_try_to_compact_pages,
 
@@ -195,7 +194,6 @@
__entry->prio)
 );
 
-#ifdef CONFIG_COMPACTION
 DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
 
TP_PROTO(struct zone *zone,
@@ -296,7 +294,6 @@
 
TP_ARGS(zone, order)
 );
-#endif
 
 TRACE_EVENT(mm_compaction_kcompactd_sleep,
 
@@ -352,6 +349,7 @@
 
TP_ARGS(nid, order, classzone_idx)
 );
+#endif
 
 #endif /* _TRACE_COMPACTION_H */
 
-- 
1.8.3.1



[PATCH] mm: compaction: show gfp flag names in try_to_compact_pages tracepoint

2019-03-01 Thread Yafang Shao
show the gfp flag names instead of the gfp_mask could make the trace
more convenient.

Signed-off-by: Yafang Shao 
---
 include/trace/events/compaction.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/compaction.h 
b/include/trace/events/compaction.h
index 6074eff..e66afb818 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -189,9 +189,9 @@
__entry->prio = prio;
),
 
-   TP_printk("order=%d gfp_mask=0x%x priority=%d",
+   TP_printk("order=%d gfp_mask=%s priority=%d",
__entry->order,
-   __entry->gfp_mask,
+   show_gfp_flags(__entry->gfp_mask),
__entry->prio)
 );
 
-- 
1.8.3.1



[PATCH v3 01/15] clk: sunxi-ng: Mark msgbox clocks as critical

2019-03-01 Thread Samuel Holland
The msgbox clock is critical because the hardware it controls is shared
between Linux and system firmware. The message box may be used by the
EL3 secure monitor's PSCI implementation. On 64-bit sunxi SoCs, this is
provided by ARM TF-A; 32-bit SoCs use a different implementation. The
secure monitor uses the message box to forward requests to power
management firmware running on a separate CPU.

It is not enough for the secure monitor to enable the clock each time
Linux performs a SMC into EL3, as both the firmware and Linux can run
concurrently on separate CPUs. So it is never safe for Linux to turn
this clock off, and it should be marked as critical.

At this time, such power management firmware only exists for the A64 and
H5 SoCs.  However, it makes sense to take care of all CCU drivers now
for consistency, and to ease the transition in the future once firmware
is ported to the other SoCs.

Signed-off-by: Samuel Holland 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 ++-
 drivers/clk/sunxi-ng/ccu-sun50i-h6.c  | 3 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c  | 3 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c  | 3 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 3 ++-
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c   | 3 ++-
 drivers/clk/sunxi-ng/ccu-sun9i-a80.c  | 3 ++-
 7 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 932836d26e2b..22c8de3546e6 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -349,8 +349,9 @@ static SUNXI_CCU_GATE(bus_de_clk,   "bus-de",   "ahb1",
  0x064, BIT(12), 0);
 static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu",  "ahb1",
  0x064, BIT(20), 0);
+/* Used for communication between firmware components at runtime */
 static SUNXI_CCU_GATE(bus_msgbox_clk,  "bus-msgbox",   "ahb1",
- 0x064, BIT(21), 0);
+ 0x064, BIT(21), CLK_IS_CRITICAL);
 static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1",
  0x064, BIT(22), 0);
 
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
index 139e8389615c..02b10ba6f4ce 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
@@ -339,8 +339,9 @@ static SUNXI_CCU_GATE(bus_vp9_clk, "bus-vp9", 
"psi-ahb1-ahb2",
 static SUNXI_CCU_GATE(bus_dma_clk, "bus-dma", "psi-ahb1-ahb2",
  0x70c, BIT(0), 0);
 
+/* Used for communication between firmware components at runtime */
 static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "psi-ahb1-ahb2",
- 0x71c, BIT(0), 0);
+ 0x71c, BIT(0), CLK_IS_CRITICAL);
 
 static SUNXI_CCU_GATE(bus_spinlock_clk, "bus-spinlock", "psi-ahb1-ahb2",
  0x72c, BIT(0), 0);
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index a4fa2945f230..d4eeef69de52 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -262,8 +262,9 @@ static SUNXI_CCU_GATE(bus_de_fe_clk,"bus-de-fe",
"ahb1",
  0x064, BIT(14), 0);
 static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu",  "ahb1",
  0x064, BIT(20), 0);
+/* Used for communication between firmware components at runtime */
 static SUNXI_CCU_GATE(bus_msgbox_clk,  "bus-msgbox",   "ahb1",
- 0x064, BIT(21), 0);
+ 0x064, BIT(21), CLK_IS_CRITICAL);
 static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1",
  0x064, BIT(22), 0);
 static SUNXI_CCU_GATE(bus_drc_clk, "bus-drc",  "ahb1",
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index c7bf814dfd2b..66d958ba86cc 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -274,8 +274,9 @@ static SUNXI_CCU_GATE(bus_de_fe_clk,"bus-de-fe",
"ahb1",
  0x064, BIT(14), 0);
 static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu",  "ahb1",
  0x064, BIT(20), 0);
+/* Used for communication between firmware components at runtime */
 static SUNXI_CCU_GATE(bus_msgbox_clk,  "bus-msgbox",   "ahb1",
- 0x064, BIT(21), 0);
+ 0x064, BIT(21), CLK_IS_CRITICAL);
 static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1",
  0x064, BIT(22), 0);
 static SUNXI_CCU_GATE(bus_drc_clk, "bus-drc",  "ahb1",
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
index 2d6555d73170..24166609fd03 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -346,8 +346,9 @@ static SUNXI_CCU_GATE(bus_de_clk,   "bus-de",   "ahb1",
  0x064, BIT(12), 0);
 static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu",  

[PATCH v3 02/15] clk: sunxi-ng: Mark AR100 clocks as critical

2019-03-01 Thread Samuel Holland
On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires
firmware running on the AR100 coprocessor (the "SCP"). Such firmware can
provide additional features, such as thermal monitoring and poweron/off
support for boards without a PMIC.

Since the AR100 may be running critical firmware, even if Linux does not
know about it or directly interact with it (all requests may go through
an intermediary interface such as PSCI), Linux must not turn off its
clock.

At this time, such power management firmware only exists for the A64 and
H5 SoCs.  However, it makes sense to take care of all CCU drivers now
for consistency, and to ease the transition in the future once firmware
is ported to the other SoCs.

Leaving the clock running is safe even if no firmware is present, since
the AR100 stays in reset by default. In most cases, the AR100 clock is
kept enabled by Linux anyway, since it is the parent of all APB0 bus
peripherals. This change only prevents Linux from turning off the AR100
clock in the rare case that no peripherals are in use.

Signed-off-by: Samuel Holland 
---
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 2 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
index 27554eaf6929..4f822b598ade 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
@@ -45,7 +45,7 @@ static struct ccu_div ar100_clk = {
.hw.init= CLK_HW_INIT_PARENTS("ar100",
  ar100_r_apb2_parents,
  _div_ops,
- 0),
+ CLK_IS_CRITICAL),
},
 };
 
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-r.c
index 71feb7b24e8a..90b3530e2c18 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r.c
@@ -50,7 +50,7 @@ static struct ccu_div ar100_clk = {
.hw.init= CLK_HW_INIT_PARENTS("ar100",
  ar100_parents,
  _div_ops,
- 0),
+ CLK_IS_CRITICAL),
},
 };
 
-- 
2.19.2



[PATCH v3 07/15] ARM: dts: sunxi: h3/h5: Add msgbox node

2019-03-01 Thread Samuel Holland
The H3 and H5 SoCs contain a message box that can be used to send
messages and interrupts back and forth between the ARM application CPUs
and the ARISC coprocessor. Add a device tree node for it.

Signed-off-by: Samuel Holland 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index a4c757c0b741..a42fd3f9739e 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -227,6 +227,16 @@
#size-cells = <0>;
};
 
+   msgbox: mailbox@1c17000 {
+   compatible = "allwinner,sun8i-h3-msgbox",
+"allwinner,sun6i-a31-msgbox";
+   reg = <0x01c17000 0x1000>;
+   clocks = < CLK_BUS_MSGBOX>;
+   resets = < RST_BUS_MSGBOX>;
+   interrupts = ;
+   #mbox-cells = <2>;
+   };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-h3-musb";
reg = <0x01c19000 0x400>;
-- 
2.19.2



[PATCH v3 05/15] ARM: dts: sunxi: a80: Add msgbox node

2019-03-01 Thread Samuel Holland
The A80 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.

Signed-off-by: Samuel Holland 
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index d9532fb1ef65..10e878f94fc0 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -283,6 +283,16 @@
};
};
 
+   msgbox: mailbox@803000 {
+   compatible = "allwinner,sun9i-a80-msgbox",
+"allwinner,sun6i-a31-msgbox";
+   reg = <0x00803000 0x1000>;
+   clocks = < CLK_BUS_MSGBOX>;
+   resets = < RST_BUS_MSGBOX>;
+   interrupts = ;
+   #mbox-cells = <1>;
+   };
+
ehci0: usb@a0 {
compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
reg = <0x00a0 0x100>;
-- 
2.19.2



[PATCH v3 13/15] [NOT FOR MERGE] arm64: dts: allwinner: a64: Add interrupt controller node

2019-03-01 Thread Samuel Holland
In order to give firmware full access to r_intc, Linux needs to avoid
using it in the device tree. Most IRQ lines attached to r_intc are also
attached to the GIC. Unfortunately, the NMI is not. For it to be used in
Linux, we have to forward it in firmware over the mailbox.

Add a node representing this virtual interrupt controller.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 29ee8f0f833a..63e33215dea0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -128,6 +128,14 @@
status = "disabled";
};
 
+   msgbox_intc: interrupt-controller {
+   compatible = "allwinner,sunxi-msgbox-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   mboxes = < 6>, < 7>;
+   mbox-names = "tx", "rx";
+   };
+
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
-- 
2.19.2



[PATCH v3 08/15] arm64: dts: allwinner: a64: Add msgbox node

2019-03-01 Thread Samuel Holland
The A64 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2abb335145a6..29ee8f0f833a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -447,6 +447,16 @@
reg = <0x1c14000 0x400>;
};
 
+   msgbox: mailbox@1c17000 {
+   compatible = "allwinner,sun50i-a64-msgbox",
+"allwinner,sun6i-a31-msgbox";
+   reg = <0x01c17000 0x1000>;
+   clocks = < CLK_BUS_MSGBOX>;
+   resets = < RST_BUS_MSGBOX>;
+   interrupts = ;
+   #mbox-cells = <1>;
+   };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-a33-musb";
reg = <0x01c19000 0x0400>;
-- 
2.19.2



[PATCH v3 03/15] dt-bindings: mailbox: Add a sunxi message box binding

2019-03-01 Thread Samuel Holland
This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i
SoCs. Add a device tree binding for it.

Signed-off-by: Samuel Holland 
---
 .../mailbox/allwinner,sunxi-msgbox.yaml   | 79 +++
 1 file changed, 79 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml

diff --git 
a/Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml 
b/Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
new file mode 100644
index ..f34a1909ab2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/allwinner,sunxi-msgbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner sunxi Message Box
+
+maintainers:
+  - Samuel Holland 
+
+description: |
+  The hardware message box on sun6i and newer sunxi SoCs is a two-user mailbox
+  controller containing 8 unidirectional FIFOs. An interrupt is raised for
+  received messages, but software must poll to know when a transmitted message
+  has been acknowledged by the remote user. Each FIFO can hold four 32-bit
+  messages; when a FIFO is full, clients must wait before more transmissions.
+
+  Refer to ./mailbox.txt for generic information about mailbox device-tree
+  bindings.
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - allwinner,sun8i-a83t-msgbox
+  - allwinner,sun8i-h3-msgbox
+  - allwinner,sun9i-a80-msgbox
+  - allwinner,sun50i-a64-msgbox
+  - allwinner,sun50i-h6-msgbox
+  - const: allwinner,sun6i-a31-msgbox
+  - items:
+  - const: allwinner,sun6i-a31-msgbox
+
+  reg:
+items:
+  - description: MMIO register range
+
+  clocks:
+maxItems: 1
+description: bus clock
+
+  resets:
+maxItems: 1
+description: bus reset
+
+  interrupts:
+maxItems: 1
+description: controller interrupt
+
+  '#mbox-cells':
+const: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+  - interrupts
+  - '#mbox-cells'
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+msgbox: mailbox@1c17000 {
+compatible = "allwinner,sun8i-h3-msgbox",
+ "allwinner,sun6i-a31-msgbox";
+reg = <0x01c17000 0x1000>;
+clocks = < CLK_BUS_MSGBOX>;
+resets = < RST_BUS_MSGBOX>;
+interrupts = ;
+#mbox-cells = <1>;
+};
+
+...
-- 
2.19.2



[PATCH v3 06/15] ARM: dts: sunxi: a83t: Add msgbox node

2019-03-01 Thread Samuel Holland
The A83T SoC contains a message box that can be used to send messages
and interrupts back and forth between the ARM application CPUs and the
ARISC coprocessor. Add a device tree node for it.

Signed-off-by: Samuel Holland 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index b099d2fbb5cd..c80c4f942439 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -546,6 +546,16 @@
reg = <0x1c14000 0x400>;
};
 
+   msgbox: mailbox@1c17000 {
+   compatible = "allwinner,sun8i-a83t-msgbox",
+"allwinner,sun6i-a31-msgbox";
+   reg = <0x01c17000 0x1000>;
+   clocks = < CLK_BUS_MSGBOX>;
+   resets = < RST_BUS_MSGBOX>;
+   interrupts = ;
+   #mbox-cells = <1>;
+   };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-a83t-musb",
 "allwinner,sun8i-a33-musb";
-- 
2.19.2



[PATCH v3 10/15] [NOT FOR MERGE] clk: sunxi-ng: sun8i: Avoid turning off unused PRCM gates

2019-03-01 Thread Samuel Holland
Hardware attached to AHB0/APB0 and controlled in the PRCM is designed to
be used by firmware running on the ARISC core. However, some devices in
this block (specifically the I2C, RSB, PIO, and CIR-RX) have native
Linux drivers and are already in the device tree. In particular, the RSB
and I2C buses may have sound chips and display bridges hanging off of
them that cannot easily be driven from firmware.

To facilitate sharing this hardware block between Linux and system
firmware, avoid turning off PRCM clock gates that are unreferenced in
the device tree. We assume that firmware has already optimally
configured these clocks before booting Linux.

Signed-off-by: Samuel Holland 
---
 drivers/clk/sunxi-ng/ccu-sun8i-r.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-r.c
index 90b3530e2c18..603de1e853e9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r.c
@@ -92,19 +92,19 @@ static struct ccu_div apb0_clk = {
 static SUNXI_CCU_M(a83t_apb0_clk, "apb0", "ahb0", 0x0c, 0, 2, 0);
 
 static SUNXI_CCU_GATE(apb0_pio_clk,"apb0-pio", "apb0",
- 0x28, BIT(0), 0);
+ 0x28, BIT(0), CLK_IGNORE_UNUSED);
 static SUNXI_CCU_GATE(apb0_ir_clk, "apb0-ir",  "apb0",
- 0x28, BIT(1), 0);
+ 0x28, BIT(1), CLK_IGNORE_UNUSED);
 static SUNXI_CCU_GATE(apb0_timer_clk,  "apb0-timer",   "apb0",
- 0x28, BIT(2), 0);
+ 0x28, BIT(2), CLK_IGNORE_UNUSED);
 static SUNXI_CCU_GATE(apb0_rsb_clk,"apb0-rsb", "apb0",
- 0x28, BIT(3), 0);
+ 0x28, BIT(3), CLK_IGNORE_UNUSED);
 static SUNXI_CCU_GATE(apb0_uart_clk,   "apb0-uart","apb0",
- 0x28, BIT(4), 0);
+ 0x28, BIT(4), CLK_IGNORE_UNUSED);
 static SUNXI_CCU_GATE(apb0_i2c_clk,"apb0-i2c", "apb0",
- 0x28, BIT(6), 0);
+ 0x28, BIT(6), CLK_IGNORE_UNUSED);
 static SUNXI_CCU_GATE(apb0_twd_clk,"apb0-twd", "apb0",
- 0x28, BIT(7), 0);
+ 0x28, BIT(7), CLK_IGNORE_UNUSED);
 
 static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M" };
 static SUNXI_CCU_MP_WITH_MUX_GATE(ir_clk, "ir",
@@ -113,7 +113,7 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(ir_clk, "ir",
  16, 2,/* P */
  24, 2,/* mux */
  BIT(31),  /* gate */
- 0);
+ CLK_IGNORE_UNUSED);
 
 static const char *const a83t_r_mod0_parents[] = { "osc16M", "osc24M" };
 static const struct ccu_mux_fixed_prediv a83t_ir_predivs[] = {
@@ -138,7 +138,7 @@ static struct ccu_mp a83t_ir_clk = {
.hw.init= CLK_HW_INIT_PARENTS("ir",
  a83t_r_mod0_parents,
  _mp_ops,
- 0),
+ CLK_IGNORE_UNUSED),
},
 };
 
-- 
2.19.2



[PATCH v3 11/15] [NOT FOR MERGE] dt-bindings: Add a binding for a mailbox-backed interrupt controller

2019-03-01 Thread Samuel Holland
This is a somewhat generic binding for an interrupt controller/forwarder
implemented in firmware and communicated with using a mailbox.

Signed-off-by: Samuel Holland 
---
 .../interrupt-controller/mbox-intc.txt| 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mbox-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mbox-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mbox-intc.txt
new file mode 100644
index ..a0eb7904ca83
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/mbox-intc.txt
@@ -0,0 +1,33 @@
+Mailbox-backed Interrupt Controller
+===
+
+This binding represents an interrupt controller implemented in firmware,
+that uses a mailbox channel to signal and acknowledge interrupts.
+
+Device Node:
+
+
+Required properties:
+
+- compatible:  Must be one of the following strings:
+   - allwinner,sunxi-msgbox-intc
+- interrupt-controller:Signifies that this node is an interrupt 
controller.
+- #interrupt-cells:Must be 1.
+- mboxes:  phandle for the mailbox controller and channel
+   specifier. If the mailbox controller has unidirectional
+   channels, two entries are required (see below).
+- mbox-names:  Only required for unidirectional mailbox channels. In
+   that case, it must contain the strings "tx" and "rx"
+   (where "tx" and "rx" are from Linux's perspective, not
+   the direction the interrupts are traveling).
+
+Example:
+
+
+   msgbox_intc: interrupt-controller {
+   compatible = "allwinner,sunxi-msgbox-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   mboxes = < 6>, < 7>;
+   mbox-names = "tx", "rx";
+   };
-- 
2.19.2



[PATCH v3 00/15] Allwinner sunxi message box support

2019-03-01 Thread Samuel Holland
This series adds support for the "hardware message box" in sun8i, sun9i,
and sun50i SoCs, used for communication with the ARISC management
processor (the platform's equivalent of the ARM SCP). The end goal is to
use the arm_scpi driver as a client, communicating with firmware running
on the AR100 CPU, or to use the mailbox to forward NMIs that the
firmware picks up from R_INTC.

Unfortunately, the ARM SCPI client no longer works with this driver
since it now exposes all 8 hardware FIFOs individually. The SCPI client
could be made to work (and I posted proof-of-concept code to that effect
with v1 of this series), but that is a low priority, as Linux does not
directly use SCPI with the current firmware version; all SCPI use goes
through ATF via PSCI.

An example usage is included at the end of this patch series. The IRQ
forwarding code is WIP and not even RFC quality yet, but it does work.
To build the firmware component, run:

  git clone https://github.com/crust-firmware/meta meta
  git clone https://github.com/smaeul/crust -b linux-mailbox-example meta/crust
  cd meta
  make

That will by default produce a U-Boot + ATF + SCP firmware image in
[meta/]build/pinebook/u-boot-sunxi-with-spl.bin. See the top-level README.md
for more information (like cross-compiler setup). The IRQ-forwarding mailbox
server is implemented in [meta/crust/]common/irqf.c.

With that firmware and the full patch series here (on top of
torvalds/master), Linux boots and is able to receive NMIs from the PMIC
(i.e. use `showkey` to see that the power button works, and see that
/proc/interrupts updates). As an added bonus, suspend/resume also mostly
works :)

Changes from v2:
  - Merge patches 1-3
  - Add a comment in the code explaining the CLK_IS_CRITICAL usage
  - Add a patch to mark the AR100 clocks as critical
  - Use YAML for the device tree binding
  - Include a not-for-merge example usage of the mailbox.

Changes from v1:
  - Marked message box clocks as critical instead of hacks in the driver
  - 8 unidirectional channels instead of 4 bidirectional pairs
  - Use per-SoC compatible strings and an A31 fallback compatible
  - Dropped the mailbox framework patch
  - Include DT patches for SoCs that document the message box

Samuel Holland (15):
  clk: sunxi-ng: Mark msgbox clocks as critical
  clk: sunxi-ng: Mark AR100 clocks as critical
  dt-bindings: mailbox: Add a sunxi message box binding
  mailbox: sunxi-msgbox: Add a new mailbox driver
  ARM: dts: sunxi: a80: Add msgbox node
  ARM: dts: sunxi: a83t: Add msgbox node
  ARM: dts: sunxi: h3/h5: Add msgbox node
  arm64: dts: allwinner: a64: Add msgbox node
  arm64: dts: allwinner: h6: Add msgbox node
  [NOT FOR MERGE] clk: sunxi-ng: sun8i: Avoid turning off unused PRCM
gates
  [NOT FOR MERGE] dt-bindings: Add a binding for a mailbox-backed
interrupt controller
  [NOT FOR MERGE] irqchip/mbox: Introduce a mailbox-backed irqchip
driver
  [NOT FOR MERGE] arm64: dts: allwinner: a64: Add interrupt controller
node
  [NOT FOR MERGE] arm64: dts: allwinner: a64: Convert DTS to use
msgbox_intc
  [NOT FOR MERGE] arm64: dts: allwinner: a64: Remove unused r_intc

 .../interrupt-controller/mbox-intc.txt|  33 ++
 .../mailbox/allwinner,sunxi-msgbox.yaml   |  79 +
 arch/arm/boot/dts/sun8i-a83t.dtsi |  10 +
 arch/arm/boot/dts/sun9i-a80.dtsi  |  10 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi|  10 +
 .../allwinner/sun50i-a64-amarula-relic.dts|   4 +-
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts |   4 +-
 .../dts/allwinner/sun50i-a64-nanopi-a64.dts   |   4 +-
 .../dts/allwinner/sun50i-a64-olinuxino.dts|   4 +-
 .../dts/allwinner/sun50i-a64-orangepi-win.dts |   4 +-
 .../boot/dts/allwinner/sun50i-a64-pine64.dts  |   4 +-
 .../dts/allwinner/sun50i-a64-pinebook.dts |   4 +-
 .../boot/dts/allwinner/sun50i-a64-sopine.dtsi |   4 +-
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts |   4 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  27 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  |  10 +
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c |   3 +-
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c|   2 +-
 drivers/clk/sunxi-ng/ccu-sun50i-h6.c  |   3 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c  |   3 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c  |   3 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c |   3 +-
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c   |   3 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c|  20 +-
 drivers/clk/sunxi-ng/ccu-sun9i-a80.c  |   3 +-
 drivers/irqchip/Kconfig   |   9 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-mbox.c| 199 +++
 drivers/mailbox/Kconfig   |  11 +
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/sunxi-msgbox.c| 315 ++
 31 files changed, 750 insertions(+), 45 deletions(-)
 create mode 100644 

[PATCH v3 14/15] [NOT FOR MERGE] arm64: dts: allwinner: a64: Convert DTS to use msgbox_intc

2019-03-01 Thread Samuel Holland
Now that there is an alternate way for Linux to receive NMIs from the
PMIC, replace references to r_intc with references to the new interrupt
controller.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts  | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts| 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts  | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts| 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts  | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi   | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts   | 4 ++--
 9 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index 6cb2b7f0c817..57690fc3f65e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -78,8 +78,8 @@
axp803: pmic@3a3 {
compatible = "x-powers,axp803";
reg = <0x3a3>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
};
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 9d0afd7d50ec..0d5693710cb2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -214,8 +214,8 @@
axp803: pmic@3a3 {
compatible = "x-powers,axp803";
reg = <0x3a3>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
};
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 31884dbc8838..33d89c2d7b60 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -179,8 +179,8 @@
axp803: pmic@3a3 {
compatible = "x-powers,axp803";
reg = <0x3a3>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
};
 };
 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index f7a4bccaa5d4..6f9da1cc6c79 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -169,8 +169,8 @@
axp803: pmic@3a3 {
compatible = "x-powers,axp803";
reg = <0x3a3>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
};
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index 8974b5a1d3b1..94bc6fadc58f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -186,8 +186,8 @@
axp803: pmic@3a3 {
compatible = "x-powers,axp803";
reg = <0x3a3>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
};
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 216f2f5db5ef..ceb6d7353cc7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -162,8 +162,8 @@
axp803: pmic@3a3 {
compatible = "x-powers,axp803";
reg = <0x3a3>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <_intc>;
+   interrupts = <0>;
};
 };
 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index d22736a62481..02b5dfabc181 100644
--- 

[PATCH v3 04/15] mailbox: sunxi-msgbox: Add a new mailbox driver

2019-03-01 Thread Samuel Holland
Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
used for communication between the ARM CPUs and the ARISC management
coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.

Add a driver for it, so it can be used for SCPI or other communication
protocols.

Signed-off-by: Samuel Holland 
---
 drivers/mailbox/Kconfig|  11 ++
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/sunxi-msgbox.c | 315 +
 3 files changed, 328 insertions(+)
 create mode 100644 drivers/mailbox/sunxi-msgbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 3eeb12e93e98..6309e755d04a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -205,4 +205,15 @@ config MTK_CMDQ_MBOX
  mailbox driver. The CMDQ is used to help read/write registers with
  critical time limitation, such as updating display configuration
  during the vblank.
+
+config SUNXI_MSGBOX
+   tristate "Allwinner sunxi Message Box"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   default ARCH_SUNXI
+   help
+ Mailbox implementation for the hardware message box present in
+ Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
+ used for communication between the application CPUs and the power
+ management coprocessor.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c818b5d011ae..f29a119a3fac 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -44,3 +44,5 @@ obj-$(CONFIG_TEGRA_HSP_MBOX)  += tegra-hsp.o
 obj-$(CONFIG_STM32_IPCC)   += stm32-ipcc.o
 
 obj-$(CONFIG_MTK_CMDQ_MBOX)+= mtk-cmdq-mailbox.o
+
+obj-$(CONFIG_SUNXI_MSGBOX) += sunxi-msgbox.o
diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
new file mode 100644
index ..fb0d733dd3b4
--- /dev/null
+++ b/drivers/mailbox/sunxi-msgbox.c
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2017-2019 Samuel Holland 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUM_CHANS  8
+
+#define CTRL_REG(n)(0x + 0x4 * ((n) / 4))
+#define CTRL_RX(n) BIT(0 + 8 * ((n) % 4))
+#define CTRL_TX(n) BIT(4 + 8 * ((n) % 4))
+
+#define REMOTE_IRQ_EN_REG  0x0040
+#define REMOTE_IRQ_STATUS_REG  0x0050
+#define LOCAL_IRQ_EN_REG   0x0060
+#define LOCAL_IRQ_STATUS_REG   0x0070
+
+#define RX_IRQ(n)  BIT(0 + 2 * (n))
+#define RX_IRQ_MASK0x
+#define TX_IRQ(n)  BIT(1 + 2 * (n))
+#define TX_IRQ_MASK0x
+
+#define FIFO_STATUS_REG(n) (0x0100 + 0x4 * (n))
+#define FIFO_STATUS_MASK   BIT(0)
+
+#define MSG_STATUS_REG(n)  (0x0140 + 0x4 * (n))
+#define MSG_STATUS_MASKGENMASK(2, 0)
+
+#define MSG_DATA_REG(n)(0x0180 + 0x4 * (n))
+
+#define mbox_dbg(mbox, ...)dev_dbg((mbox)->controller.dev, __VA_ARGS__)
+
+struct sunxi_msgbox {
+   struct mbox_controller controller;
+   struct clk *clk;
+   spinlock_t lock;
+   void __iomem *regs;
+};
+
+static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
+static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
+
+static inline int channel_number(struct mbox_chan *chan)
+{
+   return chan - chan->mbox->chans;
+}
+
+static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
+{
+   return (struct sunxi_msgbox *)chan->con_priv;
+}
+
+static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
+{
+   struct mbox_chan *chan;
+   struct sunxi_msgbox *mbox = dev_id;
+   int n;
+   uint32_t msg, status;
+
+   status = readl(mbox->regs + LOCAL_IRQ_STATUS_REG);
+   if (!(status & RX_IRQ_MASK))
+   return IRQ_NONE;
+
+   for (n = 0; n < NUM_CHANS; ++n) {
+   if (!(status & RX_IRQ(n)))
+   continue;
+   chan = >controller.chans[n];
+   while (sunxi_msgbox_peek_data(chan)) {
+   msg = readl(mbox->regs + MSG_DATA_REG(n));
+   mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
+   mbox_chan_received_data(chan, );
+   }
+   /* The IRQ can be cleared only when the FIFO is empty. */
+   writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STATUS_REG);
+   }
+
+   return IRQ_HANDLED;
+}
+
+static int sunxi_msgbox_send_data(struct mbox_chan *chan, void *data)
+{
+   struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
+   int n = channel_number(chan);
+   uint32_t msg = *(uint32_t *)data;
+
+   /* Using a channel backwards gets the hardware into a bad state. */
+   if (WARN_ON_ONCE(!(readl(mbox->regs + CTRL_REG(n)) & CTRL_TX(n
+   return 0;
+
+   /* We cannot post a new 

[PATCH v3 09/15] arm64: dts: allwinner: h6: Add msgbox node

2019-03-01 Thread Samuel Holland
The H6 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index d93a7add67e7..950681b2f7d9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -189,6 +189,16 @@
#interrupt-cells = <3>;
};
 
+   msgbox: mailbox@3003000 {
+   compatible = "allwinner,sun50i-h6-msgbox",
+"allwinner,sun6i-a31-msgbox";
+   reg = <0x03003000 0x1000>;
+   clocks = < CLK_BUS_MSGBOX>;
+   resets = < RST_BUS_MSGBOX>;
+   interrupts = ;
+   #mbox-cells = <1>;
+   };
+
pio: pinctrl@300b000 {
compatible = "allwinner,sun50i-h6-pinctrl";
reg = <0x0300b000 0x400>;
-- 
2.19.2



[PATCH v3 12/15] [NOT FOR MERGE] irqchip/mbox: Introduce a mailbox-backed irqchip driver

2019-03-01 Thread Samuel Holland
This driver implements a simple interrupt controller using message
passing over a mailbox channel. The intention is for the other end of
the channel to be implemented in firmware. This allows filtering and
forwarding interrupts from one processor to another.

Signed-off-by: Samuel Holland 
---
 drivers/irqchip/Kconfig|   9 ++
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-mbox.c | 199 +
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/irqchip/irq-mbox.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3d1e60779078..d22921276797 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -406,6 +406,15 @@ config IMX_IRQSTEER
help
  Support for the i.MX IRQSTEER interrupt multiplexer/remapper.
 
+config IRQ_MBOX
+   tristate "Simple mailbox-backed interrupt controller"
+   depends on MAILBOX
+   select IRQ_DOMAIN
+   help
+ Support for interrupt controllers attached via a mailbox channel.
+ This allows a coprocessor to inject interrupts via a simple
+ message-based protocol.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c93713d24b86..9de16ab4e69a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -94,3 +94,4 @@ obj-$(CONFIG_CSKY_APB_INTC)   += irq-csky-apb-intc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
 obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
 obj-$(CONFIG_MADERA_IRQ)   += irq-madera.o
+obj-$(CONFIG_IRQ_MBOX) += irq-mbox.o
diff --git a/drivers/irqchip/irq-mbox.c b/drivers/irqchip/irq-mbox.c
new file mode 100644
index ..f7f6b47bc5b9
--- /dev/null
+++ b/drivers/irqchip/irq-mbox.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018-2019 Samuel Holland 
+
+/*
+ * Simple mailbox-backed interrupt controller driver using 32-bit messages.
+ * The mailbox controller is expected to take a (uint32_t *) message argument.
+ *
+ * Client-to-server messages:
+ *   Byte 3 (MSB) : Reserved
+ *   Byte 2   : Reserved
+ *   Byte 1   : Message type (enumerated below)
+ *   Byte 0 (LSB) : IRQ number
+ *
+ * Server-to-client messages:
+ *   Byte 3 (MSB) : Reserved
+ *   Byte 2   : Reserved
+ *   Byte 1   : Message type (must be zero == interrupt received)
+ *   Byte 0 (LSB) : IRQ number
+ *
+ * IRQ lines must be unmasked before they can be used (generic irqchip code
+ * takes care of that in this driver).
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MBOX_INTC_MAX_IRQS 32
+
+enum {
+   MSG_EOI= 0,
+   MSG_MASK   = 1,
+   MSG_UNMASK = 2,
+};
+
+struct mbox_intc {
+   struct irq_chip chip;
+   struct irq_domain *domain;
+   struct mbox_chan *rx_chan;
+   struct mbox_chan *tx_chan;
+   struct mbox_client cl;
+};
+
+static int mbox_intc_map(struct irq_domain *domain, unsigned int virq,
+irq_hw_number_t hwirq)
+{
+   struct mbox_intc *intc = domain->host_data;
+
+   if (hwirq >= MBOX_INTC_MAX_IRQS)
+   return -ENODEV;
+
+   irq_set_chip_data(virq, intc);
+   irq_set_chip_and_handler(virq, >chip, handle_fasteoi_irq);
+   irq_set_status_flags(virq, IRQ_LEVEL);
+
+   return 0;
+}
+
+static const struct irq_domain_ops mbox_intc_domain_ops = {
+   .map   = mbox_intc_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void mbox_intc_rx_callback(struct mbox_client *cl, void *msg)
+{
+   struct mbox_intc *intc = container_of(cl, struct mbox_intc, cl);
+   uint32_t hwirq = *(uint32_t *)msg;
+
+   if (hwirq >= MBOX_INTC_MAX_IRQS)
+   return;
+
+   generic_handle_irq(irq_linear_revmap(intc->domain, hwirq));
+}
+
+static void mbox_intc_tx_msg(struct irq_data *d, uint8_t request)
+{
+   struct mbox_intc *intc = irq_data_get_irq_chip_data(d);
+   uint32_t msg = (request << 8) | (d->hwirq & GENMASK(0, 7));
+
+   /* Since we don't expect an ACK for this message, immediately complete
+* the transmission. This ensures that each message is sent out without
+* sleeping, and 'data' remains in scope until actual transmission. */
+   if (mbox_send_message(intc->tx_chan, ) >= 0)
+   mbox_client_txdone(intc->tx_chan, 0);
+}
+
+static void mbox_intc_irq_mask(struct irq_data *d)
+{
+   mbox_intc_tx_msg(d, MSG_MASK);
+}
+
+static void mbox_intc_irq_unmask(struct irq_data *d)
+{
+   mbox_intc_tx_msg(d, MSG_UNMASK);
+}
+
+static void mbox_intc_irq_eoi(struct irq_data *d)
+{
+   mbox_intc_tx_msg(d, MSG_EOI);
+}
+
+static int mbox_intc_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct mbox_intc *intc;
+   int ret;
+
+   intc = devm_kzalloc(dev, sizeof(*intc), GFP_KERNEL);
+   if (!intc)
+   return -ENOMEM;
+
+   

[PATCH v3 15/15] [NOT FOR MERGE] arm64: dts: allwinner: a64: Remove unused r_intc

2019-03-01 Thread Samuel Holland
Now that r_intc is no longer used directly by Linux, it can be removed
from the SoC device tree.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 63e33215dea0..163ee3576329 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -989,15 +989,6 @@
#clock-cells = <1>;
};
 
-   r_intc: interrupt-controller@1f00c00 {
-   compatible = "allwinner,sun50i-a64-r-intc",
-"allwinner,sun6i-a31-r-intc";
-   interrupt-controller;
-   #interrupt-cells = <2>;
-   reg = <0x01f00c00 0x400>;
-   interrupts = ;
-   };
-
r_ccu: clock@1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
-- 
2.19.2



Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

2019-03-01 Thread David R. Bergstein
Larry,

Sorry about all these extra replies.  Shortly after I sent my last
message my access point started recognizing the connection as 802.11ac
with PHY Rate / Modulation Rate of 866.6 Mbps.  What is somewhat
misleading is the information reported by iwconfig (see bit rate below).

$ iwconfig wlo1
wlo1  IEEE 802.11  ESSID:"XX-5G" 
  Mode:Managed  Frequency:5.22 GHz  Access Point:
xx:xx:xx:xx:xx:xx  
  Bit Rate=6.5 Mb/s   Tx-Power=23 dBm  
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:on
  Link Quality=70/70  Signal level=-40 dBm 
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:11   Missed beacon:0

Sincerely,

David R. Bergstein

On 3/1/19 10:16 PM, David R. Bergstein wrote:
> Larry,
>
> Please disregard my last message.  The firmware is now installed and the
> rtw88 module is working with my wireless router.  The next hurdle
> appears to be setting the speed to 802.11ac as it is currently
> connecting as an 802.11n client.
>
> Sincerely,
>
> David R. Bergstein
>
> On 3/1/19 9:55 PM, David R. Bergstein wrote:
>> Larry,
>>
>> Following up to your last reply, I blacklisted the r8822be module,
>> rebooted and was unable to bring up the wireless interface via rtw88. 
>> Below are some errors recorded in my system log:
>>
>>  
>> [  267.509818] rtw_pci :3d:00.0: Direct firmware load for
>> rtw88/rtw8822b_fw.bin failed with error -2
>> [  267.509821] rtw_pci :3d:00.0: failed to request firmware
>> [  267.511068] rtw_pci :3d:00.0: mac power on failed
>> [  267.511072] rtw_pci :3d:00.0: failed to power on mac
>> [  267.511073] rtw_pci :3d:00.0: failed to setup chip efuse info
>> [  267.511075] rtw_pci :3d:00.0: failed to setup chip information
>> [  267.512817] rtw_pci: probe of :3d:00.0 failed with error -114
>>
>> As directed, I used the rtwpci module to perform load/unload the rtw88
>> module before I saw the errors above.  Do I still need to install firmware?
>>
>> Sincerely,
>>
>> David R. Bergstein
>>
>> On 3/1/19 8:46 PM, Larry Finger wrote:
>>> On 3/1/19 4:26 PM, David R. Bergstein wrote:
 Larry,

 Thanks for the response and detailed instructions, which allowed me to
 build and install the rtw88 kernel module.  I cannot however seem to get
 my system to actually use the module.  Just to recap this is an HP Omen
 laptop with secure boot disabled.  Upon boot-up both the new rtw88 and
 old r8822be modules are loaded.  If I unload the r8822be module the wifi
 network connection gets terminated, even if I unload/reload the rtw88
 module.

 Is there something else I should be doing prior to invoking rtw88, e.g.,
 blacklisting the old module?
>>> Yes, r8822be must be blacklisted. Use the lsmod command to see what
>>> modules are actually loaded. You load/unload rtw88 using the rtwpci
>>> module.
>>>
>>> Larry
>>>



Re: [PATCH] fs: use KERNEL_DS instead of get_ds()

2019-03-01 Thread Al Viro
On Fri, Mar 01, 2019 at 09:08:35PM +0100, Jann Horn wrote:
> get_ds() is a legacy name for KERNEL_DS; all architectures #define it to
> KERNEL_DS,

not quite - h8300 and m68k have it as (equivalent) static inline.

> and almost every user of set_fs() uses the name KERNEL_DS.
> 
> Let the VFS also use KERNEL_DS so that we can get rid of get_ds() at some
> point.

No objections, but that kind of stuff might be better done in a different
way: ask Linus to run this

git grep -n -w get_ds | tr ':' ' ' | while read file line junk; do
case "$file" in
*include*|tools*)
;;
*)
ed $file <

[RFC PATCH] KVM: arm64: Force a PTE mapping when logging is enabled

2019-03-01 Thread Zenghui Yu
The idea behind this is: we don't want to keep tracking of huge pages when
logging_active is true, which will result in performance degradation.  We
still need to set vma_pagesize to PAGE_SIZE, so that we can make use of it
to force a PTE mapping.

Cc: Suzuki K Poulose 
Cc: Punit Agrawal 
Signed-off-by: Zenghui Yu 

---
Atfer looking into https://patchwork.codeaurora.org/patch/647985/ , the
"vma_pagesize = PAGE_SIZE" logic was not intended to be deleted. As far
as I can tell, we used to have "hugetlb" to force the PTE mapping, but
we have "vma_pagesize" currently instead. We should set it properly for
performance reasons (e.g, in VM migration). Did I miss something important?

---
 virt/kvm/arm/mmu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 30251e2..7d41b16 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1705,6 +1705,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
phys_addr_t fault_ipa,
 (vma_pagesize == PUD_SIZE && kvm_stage2_has_pmd(kvm))) &&
!force_pte) {
gfn = (fault_ipa & huge_page_mask(hstate_vma(vma))) >> 
PAGE_SHIFT;
+   } else {
+   /*
+* Fallback to PTE if it's not one of the stage2
+* supported hugepage sizes or the corresponding level
+* doesn't exist, or logging is enabled.
+*/
+   vma_pagesize = PAGE_SIZE;
}
up_read(>mm->mmap_sem);
 
-- 
1.8.3.1




Re: [PATCH net-next 4/6] ethernet: eth: add default vid len for all ehternet kind devices

2019-03-01 Thread Florian Fainelli



On 3/1/2019 5:11 AM, Ivan Khoronzhuk wrote:
> On Wed, Feb 27, 2019 at 08:29:20PM -0800, Florian Fainelli wrote:
>>
>>
>> On 2/26/2019 10:45 AM, Ivan Khoronzhuk wrote:
>>> IVDF - individual virtual device filtering. Allows to set per vlan
>>> l2 address filters on end real network device (for unicast and for
>>> multicast) and drop redundant not expected packet income.
>>>
>>> If CONFIG_VLAN_8021Q_IVDF is enabled the following changes are
>>> applied, and only for ethernet network devices.
>>>
>>> By default every ethernet netdev needs vid len = 2 bytes to be able to
>>> hold up to 4096 vids. So set it for every eth device to be correct,
>>> except vlan devs.
>>>
>>> In order to shrink all addresses of devices above vlan, the vid_len
>>> for vlan dev = 0, as result all suckers sync their addresses to common
>>> base not taking in to account vid part (vid_len of "to" devices is
>>> important only). And only vlan device is the source of addresses with
>>> actual its vid set, propagating it to parent devices while rx_mode().
>>>
>>> Also, don't bother those ethernet devices that at this moment are not
>>> moved to vlan addressing scheme, so while end ethernet device is
>>> created - set vid_len to 0, thus, while syncing, its address space is
>>> concatenated to one dimensional like usual, and who needs IVDF - set
>>> it to NET_8021Q_VID_TSIZE.
>>>
>>> There is another decision - is to inherit vid_len or some feature flag
>>> from end root device in order to all upper devices have vlan extended
>>> address space only if exact end real device have such capability. But
>>> I didn't, because it requires more changes and probably I'm not
>>> familiar with all places where it should be inherited, I would
>>> appreciate if someone can guid where it's applicable, then it could
>>> become a little bit more limited.
>>
>> I would think that a call to vlan_dev_ivdf_set() would be enough to
>> indicate that the underlying network device driver supports IVDF and
>> wants to make use of it. The infrastructure itself that you added costs
>> little memory, it is once the call to vlan_dev_ivdf_set() is made that
>> the memory consumption increases which is fine, since we want to make
>> use of that feature.
>>
>> While I appreciate the thoughts given to making this a configurable
>> option, I feel that enabling it unconditionally and having the
>> underlying driver decide would be more manageable.
> 
> Not exactly. Even system has no driver calling vlan_dev_ivdf_set()
> I still has this "mem consumption" from the very beginning. That's why I
> made
> this depended on the driver and CONF. For embedded world it looks fine.
> 
> The issues is that I can't change addressing scheme dynamically since some
> drivers and infrastructure that exists before I called vlan_dev_ivdf_set()
> can already have some synced addresses using old scheme. To do this
> dynamically it needs unsync vlans from old scheme and make sync again.
> Probably that is topic to "sync" :-| about

Good one, that would be very complicated indeed.

> 
> I considered idea making "above infrastructure" IVDF to be dependent on
> underneath end device IVDF and remove this config at all, but here several
> issues with this, the infrastructure has to be "resynced" and some
> signal has
> to inform each vlan to do this, and while this happens, all end devices
> already
> configured and not supported IVDF shouldn't suffer. I can try but it
> looks not
> doable in normal way, and appreciate any thoughts about this.
> 
> Meanwhile, this option looks fine for small embedded paltforms.
> 
>>
>> We have had that conversation before, but let me ask again when we call
>> dev_{uc,mc}_sync() and ultimately the network device's
>> ndo_set_rx_mode(), by the time the ndo_set_rx_mode() function is called,
>> we lost track of the call chain, like which virtual device was it
>> originating from. If we somehow added a notification information about
>> the network device stack (and we could use netdevice notifiers for
>> that), then maybe we don't really need to add all of this code and we
>> can just derive the necessary bits of information we want by checking:
>> is this a VLAN network device? It is, okay what's your VLAN ID, etc.?
>>
>> Either approach would get us our cookie anyway :)
> 
> Postulate here is that address of vlan device is separate from netdevice
> entity
> with it's own context.
> 
> Several cases talking about this:
> 
> - bound device having 2 slaves can have added vid to both slave devices but
> synced addresses for only one of them. So, if vid is set in real device
> it doesn't mean it needs addresses of vlan device.
> 
> - I know that's crazy, but net device tree can contain 2 same vlan
> devices ).
> The scheme doesn't prevent this case. So one vid address can be counted
> by two
> vlan network devices.
> 
> - Any of the devices in _sync/rx_mode() chain is legal to do with addresses
> what ever it's allowed to do, drop some of them, combine with others and

[PATCH] RDMA/umem: minor bug fix and cleanup in error handling paths

2019-03-01 Thread john . hubbard
From: John Hubbard 

1. Bug fix: the error handling release pages starting
at the first page that experienced an error.

2. Refinement: release_pages() is better than put_page()
in a loop.

3. Dead code removal: the check for (user_virt & ~page_mask)
is checking for a condition that can never happen,
because earlier:

user_virt = user_virt & page_mask;

...so, remove that entire phrase.

4. Minor: As long as I'm here, shorten up a couple of long lines
in the same function, without harming the ability to
grep for the printed error message.

Cc: Ira Weiny 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Doug Ledford 
Cc: linux-r...@vger.kernel.org
Cc: linux...@kvack.org
Signed-off-by: John Hubbard 
---
 drivers/infiniband/core/umem_odp.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index acb882f279cb..294bf6676947 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -648,25 +648,17 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp 
*umem_odp, u64 user_virt,
 
if (npages < 0) {
if (npages != -EAGAIN)
-   pr_warn("fail to get %zu user pages with error 
%d\n", gup_num_pages, npages);
+   pr_warn("fail to get %zu user pages with error 
%d\n",
+   gup_num_pages, npages);
else
-   pr_debug("fail to get %zu user pages with error 
%d\n", gup_num_pages, npages);
+   pr_debug("fail to get %zu user pages with error 
%d\n",
+gup_num_pages, npages);
break;
}
 
bcnt -= min_t(size_t, npages << PAGE_SHIFT, bcnt);
mutex_lock(_odp->umem_mutex);
for (j = 0; j < npages; j++, user_virt += PAGE_SIZE) {
-   if (user_virt & ~page_mask) {
-   p += PAGE_SIZE;
-   if (page_to_phys(local_page_list[j]) != p) {
-   ret = -EFAULT;
-   break;
-   }
-   put_page(local_page_list[j]);
-   continue;
-   }
-
ret = ib_umem_odp_map_dma_single_page(
umem_odp, k, local_page_list[j],
access_mask, current_seq);
@@ -684,9 +676,11 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp 
*umem_odp, u64 user_virt,
mutex_unlock(_odp->umem_mutex);
 
if (ret < 0) {
-   /* Release left over pages when handling errors. */
-   for (++j; j < npages; ++j)
-   put_page(local_page_list[j]);
+   /*
+* Release pages, starting at the the first page
+* that experienced an error.
+*/
+   release_pages(_page_list[j], npages - j);
break;
}
}
-- 
2.21.0



[PATCH 0/1] RDMA/umem: minor bug fix and cleanup in error handling paths

2019-03-01 Thread john . hubbard
From: John Hubbard 

Hi,

Ira Weiny alerted me to a couple of places where I'd missed a change from
put_page() to put_user_page(), in my pending patchsets. But when I
attempted to dive more deeply into that code, I ran into things that I
*think* should be fixed up a bit.

I hope I didn't completely miss something. I am not set up to test this
(no Infiniband hardware) so I'm not even sure I should send this out, but
it seems like the best way to ask "is this code really working the way I
think it does"?

This applies to the latest linux.git tree.

Cc: Ira Weiny 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Doug Ledford 
Cc: linux-r...@vger.kernel.org
Cc: linux...@kvack.org

John Hubbard (1):
  RDMA/umem: minor bug fix and cleanup in error handling paths

 drivers/infiniband/core/umem_odp.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

-- 
2.21.0



Re: [PATCH net-next 3/6] net: 8021q: vlan_dev: add vid tag for vlan device own address

2019-03-01 Thread Florian Fainelli



On 3/1/2019 4:28 AM, Ivan Khoronzhuk wrote:
> On Wed, Feb 27, 2019 at 08:13:34PM -0800, Florian Fainelli wrote:
>>
>>
>> On 2/26/2019 10:45 AM, Ivan Khoronzhuk wrote:
>>> The vlan device address is held separately from uc/mc lists and
>>> handled differently. The vlan dev address is bound with real device
>>> address only if it's inherited from init, in all other cases it's
>>> separate address entry in uc list. With vid set, the address becomes
>>> not inherited from real device after it's set manually as before, but
>>> is part of uc list any way, with appropriate vid tag set. If vid_len
>>> for real device is 0, the behaviour is the same as before this change,
>>> so shouldn't be any impact on systems w/o individual virtual device
>>> filtering (IVDF) enabled. This allows to control and sync vlan device
>>> address and disable concrete vlan packet income when vlan interface is
>>> down.
>>>
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>
>> [snip]
>>
>>>
>>> +static int vlan_dev_add_addr(struct net_device *dev, u8 *addr)
>>> +{
>>> +    struct net_device *real_dev = vlan_dev_real_dev(dev);
>>> +    unsigned char naddr[ETH_ALEN + NET_8021Q_VID_TSIZE];
>>> +
>>> +    if (real_dev->vid_len) {
>>
>> Don't you need to check that real_dev->vid_len is >= NET_8021Q_VID_TSIZE
>> here?
> 
> vid_len for all eth devices or 0 or NET_8021Q_VID_TSIZE and used here
> only as
> a flag that different addressing scheme is used.
> vlan_dev_set_addr_vid() do copy only < NET_8021Q_VID_TSIZE anyway.
> 
> Can add the following to be sure:
> if (real_dev->vid_len) {
> if (real_dev->vid_len != NET_8021Q_VID_TSIZE)
>     return -1;
> 
> }
> 
> But frankly, if this happens the system is ill and this check can't help
> it.

Fair enough. All of your responses below make sense to me, thanks!
-- 
Florian


Re: [PATCH net-next 2/6] net: 8021q: vlan_dev: add vid tag to addresses of uc and mc lists

2019-03-01 Thread Florian Fainelli



On 3/1/2019 4:24 AM, Ivan Khoronzhuk wrote:
> On Wed, Feb 27, 2019 at 08:09:44PM -0800, Florian Fainelli wrote:
>>
>>
>> On 2/26/2019 10:45 AM, Ivan Khoronzhuk wrote:
>>> Update vlan mc and uc addresses with VID tag while propagating
>>> addresses to lower devices, do this only if address is not synced.
>>> It allows at end driver level to distinguish addresses belonging
>>> to vlan devices.
>>>
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>
>> [snip]
>>
>>>
>>> +u16 vlan_dev_get_addr_vid(struct net_device *dev, const u8 *addr)
>>
>> Having some kernel doc comment here would also be nice.
> 
> yes can be: vlan_dev_get_addr_vid - get vlan id the address belongs to
> 
> 
>>
>>> +{
>>> +    u16 vid = 0;
>>> +
>>> +    if (dev->vid_len != NET_8021Q_VID_TSIZE)
>>> +    return vid;
>>> +
>>> +    vid = addr[dev->addr_len];
>>> +    vid |= (addr[dev->addr_len + 1] & 0xf) << 8;
>>
>> This uses knowledge of the maximum VLAN ID is 4095, which is fine, might
>> be a good idea to add a check on VID not exceeding the maximum VLAN ID
>> number instead of doing a silent truncation?
> 
> and then return -1, not sure, just because it's 0 or directly set by vlan
> layer and is verified anyway. But no harm to verify even it looks like
> redundancy.

I would have thought that there would be an existing helper function to
put/get a VLAN identifier into/from two bytes but that is fine as-is.

> 
>>
>> [snip]
>>
>>> +static void vlan_dev_align_addr_vid(struct net_device *vlan_dev)
>>> +{
>>> +    struct net_device *real_dev = vlan_dev_real_dev(vlan_dev);
>>> +    struct netdev_hw_addr *ha;
>>> +
>>> +    if (!real_dev->vid_len)
>>> +    return;
>>
>> Should not this check be moved to dev_{mc,uc}_sync? It does not seem to
>> me like this would scale really well across different stacked devices
>> (VLAN, bond, macvlan) as well as underlying drivers (cpsw, dsa, etc.).
>> Or maybe the check should be if vlan_dev->vid_len > real_dev->vid_len ->
>> error, right?
> 
> It shouldn't be part of netdev addr module, no any
> vlan_dev_vlan_id(vlan_dev)
> should be there.
> 
> It's scaled becouse bond/team ...etc, are ethernet devices and have IVDF
> enabled while configuration. Address propagation always is from leafs to
> real root device, every underneeth device knows nothing about above, so
> check is only in one direction.
> 

OK, indeed stacked devices would lead to that, thanks for explaining!
-- 
Florian


Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

2019-03-01 Thread David R. Bergstein
Larry,

Please disregard my last message.  The firmware is now installed and the
rtw88 module is working with my wireless router.  The next hurdle
appears to be setting the speed to 802.11ac as it is currently
connecting as an 802.11n client.

Sincerely,

David R. Bergstein

On 3/1/19 9:55 PM, David R. Bergstein wrote:
> Larry,
>
> Following up to your last reply, I blacklisted the r8822be module,
> rebooted and was unable to bring up the wireless interface via rtw88. 
> Below are some errors recorded in my system log:
>
>  
> [  267.509818] rtw_pci :3d:00.0: Direct firmware load for
> rtw88/rtw8822b_fw.bin failed with error -2
> [  267.509821] rtw_pci :3d:00.0: failed to request firmware
> [  267.511068] rtw_pci :3d:00.0: mac power on failed
> [  267.511072] rtw_pci :3d:00.0: failed to power on mac
> [  267.511073] rtw_pci :3d:00.0: failed to setup chip efuse info
> [  267.511075] rtw_pci :3d:00.0: failed to setup chip information
> [  267.512817] rtw_pci: probe of :3d:00.0 failed with error -114
>
> As directed, I used the rtwpci module to perform load/unload the rtw88
> module before I saw the errors above.  Do I still need to install firmware?
>
> Sincerely,
>
> David R. Bergstein
>
> On 3/1/19 8:46 PM, Larry Finger wrote:
>> On 3/1/19 4:26 PM, David R. Bergstein wrote:
>>> Larry,
>>>
>>> Thanks for the response and detailed instructions, which allowed me to
>>> build and install the rtw88 kernel module.  I cannot however seem to get
>>> my system to actually use the module.  Just to recap this is an HP Omen
>>> laptop with secure boot disabled.  Upon boot-up both the new rtw88 and
>>> old r8822be modules are loaded.  If I unload the r8822be module the wifi
>>> network connection gets terminated, even if I unload/reload the rtw88
>>> module.
>>>
>>> Is there something else I should be doing prior to invoking rtw88, e.g.,
>>> blacklisting the old module?
>> Yes, r8822be must be blacklisted. Use the lsmod command to see what
>> modules are actually loaded. You load/unload rtw88 using the rtwpci
>> module.
>>
>> Larry
>>


[PATCH RFC/RFT] dma-contiguous: Get normal pages for single-page allocations

2019-03-01 Thread Nicolin Chen
The addresses within a single page are always contiguous, so it's
not so necessary to always allocate one single page from CMA area.
Since the CMA area has a limited predefined size of space, it may
run out of space in heavy use cases, where there might be quite a
lot CMA pages being allocated for single pages.

However, there is also a concern that a device might care where a
page comes from -- it might expect the page from CMA area and act
differently if the page doesn't.

This patch tries to get normal pages for single-page allocations
unless the device has its own CMA area. This would save resources
from the CMA area for more CMA allocations. And it'd also reduce
CMA fragmentations resulted from trivial allocations.

Also, it updates the API and its callers so as to pass gfp flags.

Signed-off-by: Nicolin Chen 
---
 arch/arm/mm/dma-mapping.c  |  5 ++---
 arch/arm64/mm/dma-mapping.c|  2 +-
 arch/xtensa/kernel/pci-dma.c   |  2 +-
 drivers/iommu/amd_iommu.c  |  2 +-
 drivers/iommu/intel-iommu.c|  3 +--
 include/linux/dma-contiguous.h |  4 ++--
 kernel/dma/contiguous.c| 23 +++
 7 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 8a90f298af96..c39fc2d97712 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -588,7 +588,7 @@ static void *__alloc_from_contiguous(struct device *dev, 
size_t size,
struct page *page;
void *ptr = NULL;
 
-   page = dma_alloc_from_contiguous(dev, count, order, gfp & __GFP_NOWARN);
+   page = dma_alloc_from_contiguous(dev, count, order, gfp);
if (!page)
return NULL;
 
@@ -1293,8 +1293,7 @@ static struct page **__iommu_alloc_buffer(struct device 
*dev, size_t size,
unsigned long order = get_order(size);
struct page *page;
 
-   page = dma_alloc_from_contiguous(dev, count, order,
-gfp & __GFP_NOWARN);
+   page = dma_alloc_from_contiguous(dev, count, order, gfp);
if (!page)
goto error;
 
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 78c0a72f822c..660adedaab5d 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -159,7 +159,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t 
size,
struct page *page;
 
page = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
-   get_order(size), gfp & __GFP_NOWARN);
+get_order(size), gfp);
if (!page)
return NULL;
 
diff --git a/arch/xtensa/kernel/pci-dma.c b/arch/xtensa/kernel/pci-dma.c
index 9171bff76fc4..e15b893caadb 100644
--- a/arch/xtensa/kernel/pci-dma.c
+++ b/arch/xtensa/kernel/pci-dma.c
@@ -157,7 +157,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
 
if (gfpflags_allow_blocking(flag))
page = dma_alloc_from_contiguous(dev, count, get_order(size),
-flag & __GFP_NOWARN);
+flag);
 
if (!page)
page = alloc_pages(flag | __GFP_ZERO, get_order(size));
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 6b0760dafb3e..c54923a9e31f 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2691,7 +2691,7 @@ static void *alloc_coherent(struct device *dev, size_t 
size,
return NULL;
 
page = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
-   get_order(size), flag & __GFP_NOWARN);
+get_order(size), flag);
if (!page)
return NULL;
}
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a0ef7c5e5dfe..cd3483d03f3b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3789,8 +3789,7 @@ static void *intel_alloc_coherent(struct device *dev, 
size_t size,
if (gfpflags_allow_blocking(flags)) {
unsigned int count = size >> PAGE_SHIFT;
 
-   page = dma_alloc_from_contiguous(dev, count, order,
-flags & __GFP_NOWARN);
+   page = dma_alloc_from_contiguous(dev, count, order, flags);
if (page && iommu_no_mapping(dev) &&
page_to_phys(page) + size > dev->coherent_dma_mask) {
dma_release_from_contiguous(dev, page, count);
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index f247e8aa5e3d..b166e8a8740f 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -112,7 +112,7 @@ static inline int 

Re: [PATCH net 1/2] net: phy: Use C45 Helpers in phy_read_status()

2019-03-01 Thread Florian Fainelli



On 3/1/2019 2:54 AM, Jose Abreu wrote:
> Currently phy_read_status() considers that either the PHY driver has the
> read_status() callback or uses the generic callback.
> 
> For C45 PHYs we need to use the gen10g_read_status() callback.

Right, so we could expect your C45 PHY driver to assign the read_status
callback to gen10g_read_status() if it is appropriate. So far most of
the 10g PHY drivers (cortina, marvell10g, aquantia) have to define their
own read_status() callback to be feature complete. Unlike C22 PHYs that
can really be driven with a simple generic PHY driver model for standard
features, C45 PHYs seem to be quirky enough this does not work anymore.

> 
> Signed-off-by: Jose Abreu 
> Cc: Andrew Lunn 
> Cc: Florian Fainelli 
> Cc: "David S. Miller" 
> Cc: Joao Pinto 
> ---
>  include/linux/phy.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 333b56d8f746..872899136fdc 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -1030,6 +1030,8 @@ static inline int phy_read_status(struct phy_device 
> *phydev)
>  
>   if (phydev->drv->read_status)
>   return phydev->drv->read_status(phydev);
> + else if (phydev->is_c45)
> + return gen10g_read_status(phydev);
>   else
>   return genphy_read_status(phydev);
>  }
> 

-- 
Florian


Re: [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low power by default

2019-03-01 Thread Florian Fainelli



On 3/1/2019 7:07 AM, Antoine Tenart wrote:
> Hi Andrew,
> 
> On Fri, Mar 01, 2019 at 03:19:53PM +0100, Andrew Lunn wrote:
>> On Fri, Mar 01, 2019 at 12:00:47PM +0100, Antoine Tenart wrote:
>>> When the Marvell 10G PHYs are set out of reset, the LPOWER bit is set
>>> depending on an hardware configuration choice. We also do not know what
>>> is the PHY state at boot time. Hence, set the PHY in low power by
>>> default when this driver probes.
>>
>> Florian did some work for c22 PHYs so that the existing link state
>> could be used at boot. So for example, the bootloader configured the
>> PHY up and it got link, there is no need to down/up the PHY when linux
>> takes control. The networking comes up faster that way.
>>
>> Can this work for this PHY?
> 
> This use case (the bootloader configures the PHY, Linux boots and sets
> an interface using this PHY up) would work, and is what's happening in
> some situations right now (the 3310 reset is never asserted prior to
> this series).
> 
> But consider this case (let's say we use a 10G link):
> 
>      
>   |Board 1   |   |Board 2   |
>   | MAC — 3310 — | — SFP cable — | — 3310 — MAC |
>      
> 
> Board 1: The userspace do not set the interface up. The MAC is in reset
>  (default state during the MAC driver probe), the PHY was
>configured by the bootloader.
> Board 2: The userspace set the interface up. The MAC is configured, the
>  PHY is configured as well.
> 
> The two PHY's PCS will establish a link and report it as being up. In
> this case, phylink's AN mode is MLO_AN_PHY and thus will report the
> overall link as being the PHY's link status: up.
> 
> My understanding is that the issue arises because the PHYs were never
> set in reset, or low power, and thus act as if the user wanted the port
> to be up. As the default behaviour for networking ports is to be down at
> boot, I thought to set the PHY as well in a default low power state.

The policy you are creating here for the marvell10g driver is entirely
applicable to any PHY <=> PHY configuration where either of the two
software agents on Board 1 or Board 2 has not had a chance to bring-up
its bootloader/OS/applications to control the PHY.

A number of PHYs come up fully on (or in isolate or super isolate mode)
and will AN with their link partner if connected. For some people it's a
feature, for some it is a waste of power. I don't necessarily have an
issue with your patch per-se, but it does create an one off behavior
that other PHY drivers may not follow.
-- 
Florian


Re: [PATCH] perf c2c: Fix c2c report for empty numa node

2019-03-01 Thread Ravi Bangoria


On 3/1/19 3:56 PM, Jiri Olsa wrote:
> Ravi Bangoria reported that we fail with empty
> numa node with following message:
> 
>   $ lscpu
>   NUMA node0 CPU(s):
>   NUMA node1 CPU(s):   0-4
> 
>   $ sudo ./perf c2c report
>   node/cpu topology bugFailed setup nodes
> 
> Fixing this by detecting empty node and keeping
> its cpu set empty.
> 
> Reported-by: Ravi Bangoria 
> Link: http://lkml.kernel.org/n/tip-dyq5jo6pn1j3yqavb5ukj...@git.kernel.org
> Signed-off-by: Jiri Olsa 

Reported-by: Nageswara R Sastry 
Tested-by: Ravi Bangoria 



[PATCH 1/2] CIFS: Fix a bug with re-sending wdata when transport returning -EAGAIN

2019-03-01 Thread Long Li
From: Long Li 

When sending a wdata, transport may return -EAGAIN. In this case
we should re-obtain credits because the session may have been
reconnected.

Signed-off-by: Long Li 
---
 fs/cifs/file.c | 61 +-
 1 file changed, 31 insertions(+), 30 deletions(-)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 9b53f33137b3..08e73759d6ec 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2620,43 +2620,44 @@ cifs_resend_wdata(struct cifs_writedata *wdata, struct 
list_head *wdata_list,
struct TCP_Server_Info *server =
tlink_tcon(wdata->cfile->tlink)->ses->server;
 
-   /*
-* Wait for credits to resend this wdata.
-* Note: we are attempting to resend the whole wdata not in segments
-*/
do {
-   rc = server->ops->wait_mtu_credits(server, wdata->bytes, ,
-  );
-
-   if (rc)
-   goto out;
-
-   if (wsize < wdata->bytes) {
-   add_credits_and_wake_if(server, , 0);
-   msleep(1000);
-   }
-   } while (wsize < wdata->bytes);
+   /*
+* Wait for credits to resend this wdata.
+* Note: we are attempting to resend the whole wdata not in
+* segments
+*/
+   do {
+   rc = server->ops->wait_mtu_credits(server, wdata->bytes,
+   , );
+   if (rc)
+   goto fail;
+
+   if (wsize < wdata->bytes) {
+   add_credits_and_wake_if(server, , 0);
+   msleep(1000);
+   }
+   } while (wsize < wdata->bytes);
 
-   wdata->credits = credits;
-   rc = -EAGAIN;
-   while (rc == -EAGAIN) {
+   wdata->credits = credits;
rc = 0;
if (wdata->cfile->invalidHandle)
rc = cifs_reopen_file(wdata->cfile, false);
if (!rc)
rc = server->ops->async_writev(wdata,
-   cifs_uncached_writedata_release);
-   }
+   cifs_uncached_writedata_release);
 
-   if (!rc) {
-   list_add_tail(>list, wdata_list);
-   return 0;
-   }
+   /* If the write was successfully sent, we are done */
+   if (!rc) {
+   list_add_tail(>list, wdata_list);
+   return 0;
+   }
 
-   add_credits_and_wake_if(server, >credits, 0);
-out:
-   kref_put(>refcount, cifs_uncached_writedata_release);
+   /* Roll back credits and retry if needed */
+   add_credits_and_wake_if(server, >credits, 0);
+   } while (rc == -EAGAIN);
 
+fail:
+   kref_put(>refcount, cifs_uncached_writedata_release);
return rc;
 }
 
@@ -2884,12 +2885,12 @@ static void collect_uncached_write_data(struct 
cifs_aio_ctx *ctx)
wdata->bytes, _from,
ctx->cfile, cifs_sb, _list,
ctx);
+
+   kref_put(>refcount,
+   
cifs_uncached_writedata_release);
}
 
list_splice(_list, >list);
-
-   kref_put(>refcount,
-cifs_uncached_writedata_release);
goto restart_loop;
}
}
-- 
2.17.1



[PATCH 2/2] CIFS: Fix a bug with re-sending rdata when transport returning -EAGAIN

2019-03-01 Thread Long Li
From: Long Li 

When sending a rdata, transport may return -EAGAIN. In this case
we should re-obtain credits because the session may have been
reconnected.

Signed-off-by: Long Li 
---
 fs/cifs/file.c | 51 +-
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 08e73759d6ec..c83ca96f883b 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3335,44 +3335,45 @@ static int cifs_resend_rdata(struct cifs_readdata 
*rdata,
struct TCP_Server_Info *server =
tlink_tcon(rdata->cfile->tlink)->ses->server;
 
-   /*
-* Wait for credits to resend this rdata.
-* Note: we are attempting to resend the whole rdata not in segments
-*/
do {
-   rc = server->ops->wait_mtu_credits(server, rdata->bytes,
+   /*
+* Wait for credits to resend this rdata.
+* Note: we are attempting to resend the whole rdata not in
+* segments
+*/
+   do {
+   rc = server->ops->wait_mtu_credits(server, rdata->bytes,
, );
 
-   if (rc)
-   goto out;
+   if (rc)
+   goto fail;
 
-   if (rsize < rdata->bytes) {
-   add_credits_and_wake_if(server, , 0);
-   msleep(1000);
-   }
-   } while (rsize < rdata->bytes);
+   if (rsize < rdata->bytes) {
+   add_credits_and_wake_if(server, , 0);
+   msleep(1000);
+   }
+   } while (rsize < rdata->bytes);
 
-   rdata->credits = credits;
-   rc = -EAGAIN;
-   while (rc == -EAGAIN) {
+   rdata->credits = credits;
rc = 0;
if (rdata->cfile->invalidHandle)
rc = cifs_reopen_file(rdata->cfile, true);
if (!rc)
rc = server->ops->async_readv(rdata);
-   }
 
-   if (!rc) {
-   /* Add to aio pending list */
-   list_add_tail(>list, rdata_list);
-   return 0;
-   }
+   /* If the read was successfully sent, we are done */
+   if (!rc) {
+   /* Add to aio pending list */
+   list_add_tail(>list, rdata_list);
+   return 0;
+   }
 
-   add_credits_and_wake_if(server, >credits, 0);
-out:
-   kref_put(>refcount,
-   cifs_uncached_readdata_release);
+   /* Roll back credits and retry if needed */
+   add_credits_and_wake_if(server, >credits, 0);
+   } while (rc == -EAGAIN);
 
+fail:
+   kref_put(>refcount, cifs_uncached_readdata_release);
return rc;
 }
 
-- 
2.17.1



Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

2019-03-01 Thread David R. Bergstein
Larry,

Following up to your last reply, I blacklisted the r8822be module,
rebooted and was unable to bring up the wireless interface via rtw88. 
Below are some errors recorded in my system log:

 
[  267.509818] rtw_pci :3d:00.0: Direct firmware load for
rtw88/rtw8822b_fw.bin failed with error -2
[  267.509821] rtw_pci :3d:00.0: failed to request firmware
[  267.511068] rtw_pci :3d:00.0: mac power on failed
[  267.511072] rtw_pci :3d:00.0: failed to power on mac
[  267.511073] rtw_pci :3d:00.0: failed to setup chip efuse info
[  267.511075] rtw_pci :3d:00.0: failed to setup chip information
[  267.512817] rtw_pci: probe of :3d:00.0 failed with error -114

As directed, I used the rtwpci module to perform load/unload the rtw88
module before I saw the errors above.  Do I still need to install firmware?

Sincerely,

David R. Bergstein

On 3/1/19 8:46 PM, Larry Finger wrote:
> On 3/1/19 4:26 PM, David R. Bergstein wrote:
>> Larry,
>>
>> Thanks for the response and detailed instructions, which allowed me to
>> build and install the rtw88 kernel module.  I cannot however seem to get
>> my system to actually use the module.  Just to recap this is an HP Omen
>> laptop with secure boot disabled.  Upon boot-up both the new rtw88 and
>> old r8822be modules are loaded.  If I unload the r8822be module the wifi
>> network connection gets terminated, even if I unload/reload the rtw88
>> module.
>>
>> Is there something else I should be doing prior to invoking rtw88, e.g.,
>> blacklisting the old module?
>
> Yes, r8822be must be blacklisted. Use the lsmod command to see what
> modules are actually loaded. You load/unload rtw88 using the rtwpci
> module.
>
> Larry
>


[PATCH v4 03/17] wlcore: Align reg_ch_conf_pending and tmp_ch_bitmap to unsigned long for better performance

2019-03-01 Thread Fenghua Yu
A bit in reg_ch_conf_pending in wl271 and tmp_ch_bitmap is set atomically
by set_bit(). set_bit() sets the bit in a single unsigned long location. If
the variables are not aligned to unsigned long, set_bit() accesses two
cache lines and thus causes slower performance. On x86, this scenario is
called split lock and can cause overall performance degradation due to
locked BTSL instruction in set_bit() locks bus.

To avoid performance degradation, the two variables are aligned to
unsigned long.

Signed-off-by: Fenghua Yu 
---
 drivers/net/wireless/ti/wlcore/cmd.c| 3 ++-
 drivers/net/wireless/ti/wlcore/wlcore.h | 6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/cmd.c 
b/drivers/net/wireless/ti/wlcore/cmd.c
index 903968735a74..8d15a6307d44 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -1707,7 +1707,8 @@ int wlcore_cmd_regdomain_config_locked(struct wl1271 *wl)
 {
struct wl12xx_cmd_regdomain_dfs_config *cmd = NULL;
int ret = 0, i, b, ch_bit_idx;
-   u32 tmp_ch_bitmap[2];
+   /* Align to unsigned long for better performance in set_bit() */
+   u32 tmp_ch_bitmap[2] __aligned(sizeof(unsigned long));
struct wiphy *wiphy = wl->hw->wiphy;
struct ieee80211_supported_band *band;
bool timeout = false;
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h 
b/drivers/net/wireless/ti/wlcore/wlcore.h
index dd14850b0603..92d878f01fa5 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -321,8 +321,10 @@ struct wl1271 {
 
/* Reg domain last configuration */
u32 reg_ch_conf_last[2]  __aligned(8);
-   /* Reg domain pending configuration */
-   u32 reg_ch_conf_pending[2];
+   /* Reg domain pending configuration. Aligned to unsigned long for
+* better performane in set_bit().
+*/
+   u32 reg_ch_conf_pending[2] __aligned(sizeof(unsigned long));
 
/* Pointer that holds DMA-friendly block for the mailbox */
void *mbox;
-- 
2.7.4



[PATCH v4 10/17] x86/clearcpuid: Apply cleared feature bits that are forced set before

2019-03-01 Thread Fenghua Yu
Some CPU feature bits are forced set and stored in cpuinfo_x86 before
handling clearcpuid options. To clear those bits from cpuinfo_x86,
apply_forced_cap() is called after handling the options.

Please note, apply_forced_cap() is called twice on boot CPU. But this code
is simple and there is no functionality issue.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cpu.h   | 2 ++
 arch/x86/kernel/cpu/common.c | 5 +++--
 arch/x86/kernel/fpu/init.c   | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index e241abce1a2a..487f32ecea0b 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -26,6 +26,8 @@ struct x86_cpu {
struct cpu cpu;
 };
 
+void apply_forced_caps(struct cpuinfo_x86 *c);
+
 #ifdef CONFIG_HOTPLUG_CPU
 extern int arch_register_cpu(int num);
 extern void arch_unregister_cpu(int);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 79e7cc0c4c85..26723ea322fa 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -758,13 +758,14 @@ void cpu_detect(struct cpuinfo_x86 *c)
}
 }
 
-static void apply_forced_caps(struct cpuinfo_x86 *c)
+void apply_forced_caps(struct cpuinfo_x86 *c)
 {
int i;
 
for (i = 0; i < NCAPINTS + NBUGINTS; i++) {
-   c->x86_capability[i] &= ~cpu_caps_cleared[i];
+   /* Bits may be cleared after they are set. */
c->x86_capability[i] |= cpu_caps_set[i];
+   c->x86_capability[i] &= ~cpu_caps_cleared[i];
}
 }
 
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 99b895eea166..9c2801b605e3 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -261,6 +262,7 @@ static void __init clear_cpuid(void)
bit >= 0 && bit < NCAPINTS * 32)
setup_clear_cpu_cap(bit);
}
+   apply_forced_caps(_cpu_data);
 }
 
 /*
-- 
2.7.4



[PATCH v4 09/17] x86/clearcpuid: Support feature flag string in kernel option clearcpuid

2019-03-01 Thread Fenghua Yu
The kernel option clearcpuid currently only takes feature bit which
can be changed from kernel to kernel.

Extend clearcpuid to use cap flag string, which is defined in
x86_cap_flags[] and won't be changed from kernel to kernel.
And user can easily get the cap flag string from /proc/cpuinfo.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cpufeature.h |  1 +
 arch/x86/kernel/cpu/cpuid-deps.c  | 26 ++
 arch/x86/kernel/fpu/init.c|  3 ++-
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index ce95b8cbd229..6792088525e3 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -132,6 +132,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 
 extern void setup_clear_cpu_cap(unsigned int bit);
 extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
+bool find_cpu_cap(char *cap_flag, unsigned int *pfeature);
 
 #define setup_force_cpu_cap(bit) do { \
set_cpu_cap(_cpu_data, bit);   \
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 5ba11ce99f92..b84b133d0ebd 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -120,3 +120,29 @@ void setup_clear_cpu_cap(unsigned int feature)
 {
do_clear_cpu_cap(NULL, feature);
 }
+
+/**
+ * find_cpu_cap - Given a cap flag string, find its corresponding feature bit.
+ * @cap_flag:  cap flag string as defined in x86_cap_flags[]
+ * @pfeature:  feature bit
+ *
+ * Return: true if the feature is found. false if not found
+ */
+bool find_cpu_cap(char *cap_flag, unsigned int *pfeature)
+{
+#ifdef CONFIG_X86_FEATURE_NAMES
+   unsigned int feature;
+
+   for (feature = 0; feature < NCAPINTS * 32; feature++) {
+   if (!x86_cap_flags[feature])
+   continue;
+
+   if (strcmp(cap_flag, x86_cap_flags[feature]) == 0) {
+   *pfeature = feature;
+
+   return true;
+   }
+   }
+#endif
+   return false;
+}
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 88bbba7ee96a..99b895eea166 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -256,7 +256,8 @@ static void __init clear_cpuid(void)
/* Chang command line range for next search. */
cmdline_size = option_pos - boot_command_line + 1;
argptr = arg;
-   if (get_option(, ) &&
+   /* cpu cap can be specified by either feature bit or string */
+   if ((get_option(, ) || find_cpu_cap(arg, )) &&
bit >= 0 && bit < NCAPINTS * 32)
setup_clear_cpu_cap(bit);
}
-- 
2.7.4



[PATCH v4 08/17] x86/clearcpuid: Support multiple clearcpuid options

2019-03-01 Thread Fenghua Yu
Currently only one kernel option "clearcpuid=" can be picked up by
kernel during boot time.

In some cases, user may want to clear a few cpu caps. This may be
useful to replace endless (new) kernel options like nosmep, nosmap,
etc.

We add support of multiple clearcpuid options to allow user to clear
multiple cpu caps.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cmdline.h |  3 +++
 arch/x86/kernel/fpu/init.c | 30 --
 arch/x86/lib/cmdline.c | 17 +++--
 3 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/cmdline.h b/arch/x86/include/asm/cmdline.h
index 6faaf27e8899..059e29558bb3 100644
--- a/arch/x86/include/asm/cmdline.h
+++ b/arch/x86/include/asm/cmdline.h
@@ -5,5 +5,8 @@
 int cmdline_find_option_bool(const char *cmdline_ptr, const char *option);
 int cmdline_find_option(const char *cmdline_ptr, const char *option,
char *buffer, int bufsize);
+int cmdline_find_option_in_range(const char *cmdline_ptr, int cmdline_size,
+const char *option, char *buffer, int bufsize,
+char **arg_pos);
 
 #endif /* _ASM_X86_CMDLINE_H */
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 6abd83572b01..88bbba7ee96a 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -243,16 +243,31 @@ static void __init fpu__init_system_ctx_switch(void)
WARN_ON_FPU(current->thread.fpu.initialized);
 }
 
+static void __init clear_cpuid(void)
+{
+   char arg[32], *argptr, *option_pos, clearcpuid_option[] = "clearcpuid";
+   int bit, cmdline_size;
+
+   /* Find each option in boot_command_line and clear specified cpu cap. */
+   cmdline_size = COMMAND_LINE_SIZE;
+   while (cmdline_find_option_in_range(boot_command_line, cmdline_size,
+   clearcpuid_option, arg,
+   sizeof(arg), _pos) >= 0) {
+   /* Chang command line range for next search. */
+   cmdline_size = option_pos - boot_command_line + 1;
+   argptr = arg;
+   if (get_option(, ) &&
+   bit >= 0 && bit < NCAPINTS * 32)
+   setup_clear_cpu_cap(bit);
+   }
+}
+
 /*
  * We parse fpu parameters early because fpu__init_system() is executed
  * before parse_early_param().
  */
 static void __init fpu__init_parse_early_param(void)
 {
-   char arg[32];
-   char *argptr = arg;
-   int bit;
-
if (cmdline_find_option_bool(boot_command_line, "no387"))
setup_clear_cpu_cap(X86_FEATURE_FPU);
 
@@ -271,12 +286,7 @@ static void __init fpu__init_parse_early_param(void)
if (cmdline_find_option_bool(boot_command_line, "noxsaves"))
setup_clear_cpu_cap(X86_FEATURE_XSAVES);
 
-   if (cmdline_find_option(boot_command_line, "clearcpuid", arg,
-   sizeof(arg)) &&
-   get_option(, ) &&
-   bit >= 0 &&
-   bit < NCAPINTS * 32)
-   setup_clear_cpu_cap(bit);
+   clear_cpuid();
 }
 
 /*
diff --git a/arch/x86/lib/cmdline.c b/arch/x86/lib/cmdline.c
index 3261abb21ef4..9cf1a0773877 100644
--- a/arch/x86/lib/cmdline.c
+++ b/arch/x86/lib/cmdline.c
@@ -114,13 +114,15 @@ __cmdline_find_option_bool(const char *cmdline, int 
max_cmdline_size,
  * @option: option string to look for
  * @buffer: memory buffer to return the option argument
  * @bufsize: size of the supplied memory buffer
+ * @option_pos: pointer to the option if found
  *
  * Returns the length of the argument (regardless of if it was
  * truncated to fit in the buffer), or -1 on not found.
  */
 static int
 __cmdline_find_option(const char *cmdline, int max_cmdline_size,
- const char *option, char *buffer, int bufsize)
+ const char *option, char *buffer, int bufsize,
+ char **arg_pos)
 {
char c;
int pos = 0, len = -1;
@@ -164,6 +166,9 @@ __cmdline_find_option(const char *cmdline, int 
max_cmdline_size,
len = 0;
bufptr = buffer;
state = st_bufcpy;
+   if (arg_pos)
+   *arg_pos = (char *)cmdline -
+  strlen(option) - 1;
break;
} else if (c == *opptr++) {
/*
@@ -211,5 +216,13 @@ int cmdline_find_option(const char *cmdline, const char 
*option, char *buffer,
int bufsize)
 {
return __cmdline_find_option(cmdline, COMMAND_LINE_SIZE, option,
-buffer, bufsize);
+buffer, bufsize, NULL);
+}
+
+int cmdline_find_option_in_range(const char *cmdline, int 

[PATCH v4 11/17] x86/clearcpuid: Clear CPUID bit in CPUID faulting

2019-03-01 Thread Fenghua Yu
From: Peter Zijlstra 

After kernel clears a CPUID bit through clearcpuid or other kernel options,
CPUID instruction executed from user space should see the same value for
the bit. The CPUID faulting handler returns the cleared bit to user.

Signed-off-by: Peter Zijlstra 
Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cpufeature.h |  4 +++
 arch/x86/kernel/cpu/common.c  |  2 ++
 arch/x86/kernel/cpu/cpuid-deps.c  | 52 
 arch/x86/kernel/cpu/intel.c   | 55 ---
 arch/x86/kernel/cpu/scattered.c   | 17 
 arch/x86/kernel/process.c |  3 +++
 arch/x86/kernel/traps.c   | 11 
 7 files changed, 141 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 6792088525e3..c4ac787d9b85 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -227,5 +227,9 @@ static __always_inline __pure bool _static_cpu_has(u16 bit)
 #define CPU_FEATURE_TYPEVALboot_cpu_data.x86_vendor, 
boot_cpu_data.x86, \
boot_cpu_data.x86_model
 
+extern int cpuid_fault;
+u32 scattered_cpuid_mask(u32 leaf, u32 count, enum cpuid_regs_idx reg);
+u32 cpuid_cap_mask(u32 leaf, u32 count, enum cpuid_regs_idx reg);
+
 #endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
 #endif /* _ASM_X86_CPUFEATURE_H */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 26723ea322fa..aa2658136fe0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1502,6 +1502,8 @@ void print_cpu_info(struct cpuinfo_x86 *c)
pr_cont(")\n");
 }
 
+int cpuid_fault;
+
 /*
  * clearcpuid= was already parsed in fpu__init_parse_early_param.
  * But we need to keep a dummy __setup around otherwise it would
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index b84b133d0ebd..f6c77dcf186d 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -113,9 +113,61 @@ static void do_clear_cpu_cap(struct cpuinfo_x86 *c, 
unsigned int feature)
 
 void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
 {
+   if (boot_cpu_has(feature))
+   cpuid_fault = 1;
do_clear_cpu_cap(c, feature);
 }
 
+u32 cpuid_cap_mask(u32 leaf, u32 count, enum cpuid_regs_idx reg)
+{
+   switch (leaf) {
+   case 0x1:
+   if (reg == CPUID_EDX)
+   return ~cpu_caps_cleared[CPUID_1_EDX];
+   if (reg == CPUID_ECX)
+   return ~cpu_caps_cleared[CPUID_1_ECX];
+   break;
+
+   case 0x6:
+   if (reg == CPUID_EAX)
+   return ~cpu_caps_cleared[CPUID_6_EAX];
+   break;
+
+   case 0x7:
+   if (reg == CPUID_EDX)
+   return ~cpu_caps_cleared[CPUID_7_EDX];
+   if (reg == CPUID_ECX)
+   return ~cpu_caps_cleared[CPUID_7_ECX];
+   if (reg == CPUID_EBX && count == 0)
+   return ~cpu_caps_cleared[CPUID_7_0_EBX];
+   break;
+
+   case 0xD:
+   if (reg == CPUID_EAX)
+   return ~cpu_caps_cleared[CPUID_D_1_EAX];
+   break;
+
+   case 0xF:
+   if (reg == CPUID_EDX) {
+   if (count == 0)
+   return ~cpu_caps_cleared[CPUID_F_0_EDX];
+   if (count == 1)
+   return ~cpu_caps_cleared[CPUID_F_0_EDX];
+   }
+   break;
+
+   case 0x8007:
+   if (reg == CPUID_EDX) {
+   if (test_bit(X86_FEATURE_CONSTANT_TSC,
+(unsigned long *)cpu_caps_cleared))
+   return ~(1 << 8);
+   }
+   break;
+   }
+
+   return scattered_cpuid_mask(leaf, count, reg);
+}
+
 void setup_clear_cpu_cap(unsigned int feature)
 {
do_clear_cpu_cap(NULL, feature);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 0c44c49f6005..1c1ec413a9a9 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -626,13 +628,60 @@ static void intel_bsp_resume(struct cpuinfo_x86 *c)
init_intel_energy_perf(c);
 }
 
+bool fixup_cpuid_exception(struct pt_regs *regs)
+{
+   unsigned int leaf, count, eax, ebx, ecx, edx;
+   unsigned long seg_base = 0;
+   unsigned char buf[2];
+   int not_copied;
+
+   if (!cpuid_fault)
+   return false;
+
+   if (test_thread_flag(TIF_NOCPUID))
+   return false;
+
+   if (!user_64bit_mode(regs))
+   seg_base = insn_get_seg_base(regs, INAT_SEG_REG_CS);
+
+   if 

[PATCH v4 07/17] x86/split_lock: Enumerate #AC for split lock by MSR IA32_CORE_CAPABILITY

2019-03-01 Thread Fenghua Yu
Bits in MSR IA32_CORE_CAPABILITY enumerate features that are not
enumerated through CPUID. Currently bit 5 is defined to enumerate
feature of #AC for split lock accesses. All other bits are reserved now.

When the bit 5 is 1, the feature is supported and feature bit
X86_FEATURE_SPLIT_LOCK_DETECT is set. Otherwise, the feature is not
available.

The MSR IA32_CORE_CAPABILITY itself is enumerated by
CPUID.(EAX=0x7,ECX=0):EDX[30].

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cpu.h |  5 +
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/kernel/cpu/common.c   |  1 +
 arch/x86/kernel/cpu/cpuid-deps.c   |  1 +
 arch/x86/kernel/cpu/intel.c| 21 +
 5 files changed, 29 insertions(+)

diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index adc6cc86b062..e241abce1a2a 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -40,4 +40,9 @@ int mwait_usable(const struct cpuinfo_x86 *);
 unsigned int x86_family(unsigned int sig);
 unsigned int x86_model(unsigned int sig);
 unsigned int x86_stepping(unsigned int sig);
+#ifdef CONFIG_CPU_SUP_INTEL
+void init_core_capability(struct cpuinfo_x86 *c);
+#else
+static inline void init_core_capability(struct cpuinfo_x86 *c) {}
+#endif
 #endif /* _ASM_X86_CPU_H */
diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 350eeccd0ce9..54c73e74213d 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -221,6 +221,7 @@
 #define X86_FEATURE_ZEN( 7*32+28) /* "" CPU is AMD 
family 0x17 (Zen) */
 #define X86_FEATURE_L1TF_PTEINV( 7*32+29) /* "" L1TF 
workaround PTE inversion */
 #define X86_FEATURE_IBRS_ENHANCED  ( 7*32+30) /* Enhanced IBRS */
+#define X86_FEATURE_SPLIT_LOCK_DETECT  ( 7*32+31) /* #AC for split lock */
 
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 51ab37ba5f64..79e7cc0c4c85 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -897,6 +897,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
 
init_scattered_cpuid_features(c);
init_speculation_control(c);
+   init_core_capability(c);
 
/*
 * Clear/Set all flags overridden by options, after probe.
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 2c0bd38a44ab..5ba11ce99f92 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -59,6 +59,7 @@ static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_AVX512_4VNNIW,X86_FEATURE_AVX512F   },
{ X86_FEATURE_AVX512_4FMAPS,X86_FEATURE_AVX512F   },
{ X86_FEATURE_AVX512_VPOPCNTDQ, X86_FEATURE_AVX512F   },
+   { X86_FEATURE_SPLIT_LOCK_DETECT, X86_FEATURE_CORE_CAPABILITY},
{}
 };
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fc3c07fe7df5..0c44c49f6005 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1029,3 +1029,24 @@ static const struct cpu_dev intel_cpu_dev = {
 
 cpu_dev_register(intel_cpu_dev);
 
+/**
+ * init_core_capability - enumerate features supported in IA32_CORE_CAPABILITY
+ * @c: pointer to cpuinfo_x86
+ *
+ * Return: void
+ */
+void init_core_capability(struct cpuinfo_x86 *c)
+{
+   /*
+* If MSR_IA32_CORE_CAPABILITY exists, enumerate features that are
+* reported in the MSR.
+*/
+   if (c == _cpu_data && cpu_has(c, X86_FEATURE_CORE_CAPABILITY)) {
+   u64 val;
+
+   rdmsrl(MSR_IA32_CORE_CAPABILITY, val);
+
+   if (val & CORE_CAP_SPLIT_LOCK_DETECT)
+   setup_force_cpu_cap(X86_FEATURE_SPLIT_LOCK_DETECT);
+   }
+}
-- 
2.7.4



[PATCH v4 04/17] x86/split_lock: Align x86_capability to unsigned long to avoid split locked access

2019-03-01 Thread Fenghua Yu
set_cpu_cap() calls locked BTS and clear_cpu_cap() calls locked BTR to
operate on bitmap defined in x86_capability.

Locked BTS/BTR accesses a single unsigned long location. In 64-bit mode,
the location is at:
base address of x86_capability + (bit offset in x86_capability % 64) * 8

Since base address of x86_capability may not aligned to unsigned long,
the single unsigned long location may cross two cache lines and
accessing the location by locked BTS/BTR introductions will trigger #AC.

To fix the split lock issue, align x86_capability to unsigned long so that
the location will be always within one cache line.

Changing x86_capability[]'s type to unsigned long may also fix the issue
because x86_capability[] will be naturally aligned to unsigned long. But
this needs additional code changes. So we choose the simpler solution
by enforcing alignment using __aligned(unsigned long).

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/processor.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 33051436c864..eb8ae701ef65 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -93,7 +93,9 @@ struct cpuinfo_x86 {
__u32   extended_cpuid_level;
/* Maximum supported CPUID level, -1=no CPUID: */
int cpuid_level;
-   __u32   x86_capability[NCAPINTS + NBUGINTS];
+   /* Unsigned long alignment to avoid split lock in atomic bitmap ops */
+   __u32   x86_capability[NCAPINTS + NBUGINTS]
+   __aligned(sizeof(unsigned long));
charx86_vendor_id[16];
charx86_model_id[64];
/* in KB - valid for CPUS which support this call: */
-- 
2.7.4



[PATCH v4 02/17] drivers/net/b44: Align pwol_mask to unsigned long for better performance

2019-03-01 Thread Fenghua Yu
A bit in pwol_mask is set in b44_magic_pattern automatically by set_bit.
set_bit sets the bit in a single unsigned long location. Since pwol_mask
may not be aligned to unsigned long, the location may cross two cache
lines and accessing the location degradates performance. On x86, accessing
two cache lines in locked instruction in set_bit is called split lock and
can cause overall performance degradation.

To avoid to impact performance by accessing two cache lines in set_bit,
align pwol_mask to unsigned long.

Signed-off-by: Fenghua Yu 
---
 drivers/net/ethernet/broadcom/b44.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 97ab0dd25552..bc544b6b9c3a 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1547,7 +1547,8 @@ static void b44_setup_pseudo_magicp(struct b44 *bp)
u32 val;
int plen0, plen1, plen2;
u8 *pwol_pattern;
-   u8 pwol_mask[B44_PMASK_SIZE];
+   /* Align to unsigned long for better performance in set_bit() */
+   u8 pwol_mask[B44_PMASK_SIZE] __aligned(sizeof(unsigned long));
 
pwol_pattern = kzalloc(B44_PATTERN_SIZE, GFP_KERNEL);
if (!pwol_pattern)
-- 
2.7.4



[PATCH v4 05/17] x86/cpufeatures: Enumerate IA32_CORE_CAPABILITIES MSR

2019-03-01 Thread Fenghua Yu
MSR register IA32_CORE_CAPABILITIES (0xCF) contains bits that enumerate
some model specific features.

The MSR 0xCF itself is enumerated by CPUID.(EAX=0x7,ECX=0):EDX[30].
When this bit is 1, the MSR 0xCF exists.

Detailed information for the CPUID bit and the MSR can be found in the
latest Intel Architecture Instruction Set Extensions and Future Features
Programming Reference.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 6d6122524711..350eeccd0ce9 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -349,6 +349,7 @@
 #define X86_FEATURE_INTEL_STIBP(18*32+27) /* "" Single Thread 
Indirect Branch Predictors */
 #define X86_FEATURE_FLUSH_L1D  (18*32+28) /* Flush L1D cache */
 #define X86_FEATURE_ARCH_CAPABILITIES  (18*32+29) /* IA32_ARCH_CAPABILITIES 
MSR (Intel) */
+#define X86_FEATURE_CORE_CAPABILITY(18*32+30) /* IA32_CORE_CAPABILITY MSR 
*/
 #define X86_FEATURE_SPEC_CTRL_SSBD (18*32+31) /* "" Speculative Store 
Bypass Disable */
 
 /*
-- 
2.7.4



[PATCH v4 01/17] x86/common: Align cpu_caps_cleared and cpu_caps_set to unsigned long

2019-03-01 Thread Fenghua Yu
cpu_caps_cleared and cpu_caps_set may not be aligned to unsigned long.
Atomic operations (i.e. set_bit and clear_bit) on the bitmaps may access
two cache lines (a.k.a. split lock) and lock bus to block all memory
accesses from other processors to ensure atomicity.

To avoid the overall performance degradation from the bus locking, align
the two variables to unsigned long.

Defining the variables as unsigned long may also fix the issue because
they are naturally aligned to unsigned long. But that needs additional
code changes. Adding __aligned(unsigned long) are simpler fixes.

Signed-off-by: Fenghua Yu 
---
 arch/x86/kernel/cpu/common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index cb28e98a0659..51ab37ba5f64 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -488,8 +488,9 @@ static const char *table_lookup_model(struct cpuinfo_x86 *c)
return NULL;/* Not found */
 }
 
-__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS];
-__u32 cpu_caps_set[NCAPINTS + NBUGINTS];
+/* Unsigned long alignment to avoid split lock in atomic bitmap ops */
+__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
+__u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
 
 void load_percpu_segment(int cpu)
 {
-- 
2.7.4



[PATCH v4 12/17] Change document for kernel option clearcpuid

2019-03-01 Thread Fenghua Yu
Since kernel option clearcpuid now supports multiple options and CPU
capability flags, the document needs to be changed.

Signed-off-by: Fenghua Yu 
---
 Documentation/admin-guide/kernel-parameters.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 858b6c0b9a15..1a195f93d3cc 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -558,10 +558,12 @@
loops can be debugged more effectively on production
systems.
 
-   clearcpuid=BITNUM [X86]
+   clearcpuid=BITNUM | FLAG [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
-   numbers. Note the Linux specific bits are not 
necessarily
+   numbers or /proc/cpuinfo for valid CPU flags.
+   Multiple options can be used to disable a few features.
+   Note the Linux specific bits are not necessarily
stable over kernel options, but the vendor specific
ones should be.
Also note that user programs calling CPUID directly
-- 
2.7.4



[PATCH v4 16/17] kvm: x86: Add support IA32_CORE_CAPABILITY MSR

2019-03-01 Thread Fenghua Yu
From: Xiaoyao Li 

MSR IA32_CORE_CAPABILITY is a feature-enumerating MSR, bit 5 of which
reports the capability of enabling detection of split locks (will be
supported on future processors based on Tremont microarchitecture and
later).

Please check the latest Intel Architecture Instruction Set Extensions
and Future Features Programming Reference for more detailed information
on the MSR and the split lock bit.

1. Expose it to user space as a feature-enumerating MSR, so that user
space can query it.

2. Emualte MSR_IA32_CORE_CAPABILITY with vmx->core_capability. And add the
get and set handler of MSR_IA32_CORE_CAPABILITY.
   For uesrspace, it can set this MSR when customizing features of guest,
also it can read the value of this MSR of guest.
   For guest, as it's a feature-enumerating MSR, guest only can read it.

Signed-off-by: Xiaoyao Li 
Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/kvm_host.h |  1 +
 arch/x86/kvm/vmx/vmx.c  | 23 +++
 arch/x86/kvm/vmx/vmx.h  |  1 +
 arch/x86/kvm/x86.c  | 17 -
 4 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 180373360e34..208f15570d17 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1527,6 +1527,7 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long 
ipi_bitmap_low,
unsigned long icr, int op_64_bit);
 
 u64 kvm_get_arch_capabilities(void);
+u64 kvm_get_core_capability(void);
 void kvm_define_shared_msr(unsigned index, u32 msr);
 int kvm_set_shared_msr(unsigned index, u64 val, u64 mask);
 
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 30a6bcd735ec..3e03c6e1e558 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1679,6 +1679,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
 
msr_info->data = to_vmx(vcpu)->spec_ctrl;
break;
+   case MSR_IA32_CORE_CAPABILITY:
+   if (!msr_info->host_initiated &&
+   !guest_cpuid_has(vcpu, X86_FEATURE_CORE_CAPABILITY))
+   return 1;
+   msr_info->data = vmx->core_capability;
+   break;
case MSR_IA32_ARCH_CAPABILITIES:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_ARCH_CAPABILITIES))
@@ -1891,6 +1897,21 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
vmx_disable_intercept_for_msr(vmx->vmcs01.msr_bitmap, 
MSR_IA32_PRED_CMD,
  MSR_TYPE_W);
break;
+   case MSR_IA32_CORE_CAPABILITY:
+   if (!msr_info->host_initiated)
+   return 1;
+   if (data & ~CORE_CAP_SPLIT_LOCK_DETECT)
+   return 1;
+
+   /*
+* Since AC split lock is a hardware feature, and there is no
+* software emulation yet, we cannot enable it for guest if
+* host hardware doesn't support it.
+*/
+   if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
+   data &= ~CORE_CAP_SPLIT_LOCK_DETECT;
+   vmx->core_capability = data;
+   break;
case MSR_IA32_ARCH_CAPABILITIES:
if (!msr_info->host_initiated)
return 1;
@@ -4083,6 +4104,8 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
++vmx->nmsrs;
}
 
+   vmx->core_capability = kvm_get_core_capability();
+
vmx->arch_capabilities = kvm_get_arch_capabilities();
 
vm_exit_controls_init(vmx, vmx_vmexit_ctrl());
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 0ac0a64c7790..cc22379991f3 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -191,6 +191,7 @@ struct vcpu_vmx {
u64   msr_guest_kernel_gs_base;
 #endif
 
+   u64   core_capability;
u64   arch_capabilities;
u64   spec_ctrl;
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 941f932373d0..c3c9e3f2d08a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1125,7 +1125,8 @@ static u32 msrs_to_save[] = {
 #endif
MSR_IA32_TSC, MSR_IA32_CR_PAT, MSR_VM_HSAVE_PA,
MSR_IA32_FEATURE_CONTROL, MSR_IA32_BNDCFGS, MSR_TSC_AUX,
-   MSR_IA32_SPEC_CTRL, MSR_IA32_ARCH_CAPABILITIES,
+   MSR_IA32_SPEC_CTRL, MSR_IA32_CORE_CAPABILITY,
+   MSR_IA32_ARCH_CAPABILITIES,
MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_STATUS, MSR_IA32_RTIT_CR3_MATCH,
MSR_IA32_RTIT_OUTPUT_BASE, MSR_IA32_RTIT_OUTPUT_MASK,
MSR_IA32_RTIT_ADDR0_A, MSR_IA32_RTIT_ADDR0_B,
@@ -1197,11 +1198,22 @@ static u32 msr_based_features[] = {
 
MSR_F10H_DECFG,
MSR_IA32_UCODE_REV,
+   MSR_IA32_CORE_CAPABILITY,

[PATCH v4 17/17] kvm: vmx: Emulate TEST_CTL MSR

2019-03-01 Thread Fenghua Yu
From: Xiaoyao Li 

A control bit (bit 29) in TEST_CTL MSR 0x33 will be introduced in
future x86 processors. When bit 29 is set, the processor causes #AC
exception for split locked accesses at all CPL.

Please check the latest Intel Software Developer's Manual
for more detailed information on the MSR and the split lock bit.

1. Since the kernel chooses to enable AC split lock by default, which
means if we don't emulate TEST_CTL MSR for guest, guest will run with
this feature enable while does not known it. Thus existing guests with
buggy firmware (like OVMF) and old kernels having the cross cache line
issues will fail the boot due to #AC.

So we should emulate TEST_CTL MSR, and set it zero to disable AC split
lock by default. Whether and when to enable it is left to guest firmware
and guest kernel.

2. Host and guest can enable AC split lock independently, so using
msr autoload to switch it during VM entry/exit.

Signed-off-by: Xiaoyao Li 
Signed-off-by: Fenghua Yu 
---
 arch/x86/kvm/vmx/vmx.c | 35 +++
 arch/x86/kvm/vmx/vmx.h |  1 +
 2 files changed, 36 insertions(+)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 3e03c6e1e558..c0c5e8621afa 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1659,6 +1659,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
u32 index;
 
switch (msr_info->index) {
+   case MSR_TEST_CTL:
+   if (!msr_info->host_initiated &&
+   !(vmx->core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
+   return 1;
+   msr_info->data = vmx->msr_test_ctl;
+   break;
 #ifdef CONFIG_X86_64
case MSR_FS_BASE:
msr_info->data = vmcs_readl(GUEST_FS_BASE);
@@ -1805,6 +1811,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
u32 index;
 
switch (msr_index) {
+   case MSR_TEST_CTL:
+   if (!(vmx->core_capability & CORE_CAP_SPLIT_LOCK_DETECT))
+   return 1;
+
+   if (data & ~TEST_CTL_ENABLE_SPLIT_LOCK_DETECT)
+   return 1;
+   vmx->msr_test_ctl = data;
+   break;
case MSR_EFER:
ret = kvm_set_msr_common(vcpu, msr_info);
break;
@@ -4108,6 +4122,9 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
 
vmx->arch_capabilities = kvm_get_arch_capabilities();
 
+   /* disable AC split lock by default */
+   vmx->msr_test_ctl = 0;
+
vm_exit_controls_init(vmx, vmx_vmexit_ctrl());
 
/* 22.2.1, 20.8.1 */
@@ -4145,6 +4162,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
 
vmx->rmode.vm86_active = 0;
vmx->spec_ctrl = 0;
+   vmx->msr_test_ctl = 0;
 
vcpu->arch.microcode_version = 0x1ULL;
vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
@@ -6344,6 +6362,21 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx *vmx)
msrs[i].host, false);
 }
 
+static void atomic_switch_msr_test_ctl(struct vcpu_vmx *vmx)
+{
+   u64 host_msr_test_ctl;
+
+   if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
+   return;
+
+   rdmsrl(MSR_TEST_CTL, host_msr_test_ctl);
+   if (host_msr_test_ctl == vmx->msr_test_ctl)
+   clear_atomic_switch_msr(vmx, MSR_TEST_CTL);
+   else
+   add_atomic_switch_msr(vmx, MSR_TEST_CTL, vmx->msr_test_ctl,
+ host_msr_test_ctl, false);
+}
+
 static void vmx_arm_hv_timer(struct vcpu_vmx *vmx, u32 val)
 {
vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, val);
@@ -6585,6 +6618,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
 
atomic_switch_perf_msrs(vmx);
 
+   atomic_switch_msr_test_ctl(vmx);
+
vmx_update_hv_timer(vcpu);
 
/*
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index cc22379991f3..e8831609c6c3 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -191,6 +191,7 @@ struct vcpu_vmx {
u64   msr_guest_kernel_gs_base;
 #endif
 
+   u64   msr_test_ctl;
u64   core_capability;
u64   arch_capabilities;
u64   spec_ctrl;
-- 
2.7.4



[PATCH v4 14/17] x86/split_lock: Add a sysfs interface to allow user to enable or disable split lock detection on all CPUs during run time

2019-03-01 Thread Fenghua Yu
The interface /sys/device/system/cpu/split_lock_detect is added
to allow user to control split lock detection and show current split
lock detection setting.

Writing 1 to the file enables split lock detection and writing 0
disables split lock detection. Split lock detection is enabled or
disabled on all CPUs.

Reading the file shows current global split lock detection setting:
disabled when 0 and enabled when 1.

Please note the interface only shows global setting. During run time,
split lock detection on one CPU may be disabled if split lock
in kernel code happens on the CPU. The interface doesn't show split
lock detection status on individual CPU. User can run rdmsr on 0x33
to check split lock detection on each CPU.

Signed-off-by: Fenghua Yu 
---
 arch/x86/kernel/cpu/intel.c | 96 -
 1 file changed, 95 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 1c1ec413a9a9..1512e96287b8 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -33,6 +33,12 @@
 #include 
 #endif
 
+#define DISABLE_SPLIT_LOCK_DETECT 0
+#define ENABLE_SPLIT_LOCK_DETECT  1
+
+static DEFINE_MUTEX(split_lock_detect_mutex);
+static int split_lock_detect_val;
+
 /*
  * Just in case our CPU detection goes bad, or you have a weird system,
  * allow a way to override the automatic disabling of MPX.
@@ -163,10 +169,35 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c)
return false;
 }
 
+static u32 new_sp_test_ctl_val(u32 test_ctl_val)
+{
+   /* Change the split lock setting. */
+   if (split_lock_detect_val == DISABLE_SPLIT_LOCK_DETECT)
+   test_ctl_val &= ~TEST_CTL_ENABLE_SPLIT_LOCK_DETECT;
+   else
+   test_ctl_val |= TEST_CTL_ENABLE_SPLIT_LOCK_DETECT;
+
+   return test_ctl_val;
+}
+
+static void init_split_lock_detect(struct cpuinfo_x86 *c)
+{
+   if (cpu_has(c, X86_FEATURE_SPLIT_LOCK_DETECT)) {
+   u32 l, h;
+
+   rdmsr(MSR_TEST_CTL, l, h);
+   l = new_sp_test_ctl_val(l);
+   wrmsr(MSR_TEST_CTL, l, h);
+   pr_info_once("#AC for split lock is enabled\n");
+   }
+}
+
 static void early_init_intel(struct cpuinfo_x86 *c)
 {
u64 misc_enable;
 
+   init_split_lock_detect(c);
+
/* Unmask CPUID levels if masked: */
if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
if (msr_clear_bit(MSR_IA32_MISC_ENABLE,
@@ -1095,7 +1126,70 @@ void init_core_capability(struct cpuinfo_x86 *c)
 
rdmsrl(MSR_IA32_CORE_CAPABILITY, val);
 
-   if (val & CORE_CAP_SPLIT_LOCK_DETECT)
+   if (val & CORE_CAP_SPLIT_LOCK_DETECT) {
setup_force_cpu_cap(X86_FEATURE_SPLIT_LOCK_DETECT);
+   split_lock_detect_val = 1;
+   }
}
 }
+
+static ssize_t
+split_lock_detect_show(struct device *dev, struct device_attribute *attr,
+  char *buf)
+{
+   return sprintf(buf, "%u\n", READ_ONCE(split_lock_detect_val));
+}
+
+static ssize_t
+split_lock_detect_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   u32 val, l, h;
+   int cpu, ret;
+
+   ret = kstrtou32(buf, 10, );
+   if (ret)
+   return ret;
+
+   if (val != DISABLE_SPLIT_LOCK_DETECT && val != ENABLE_SPLIT_LOCK_DETECT)
+   return -EINVAL;
+
+   /* No need to update MSR if new setting is the same as old one. */
+   if (val == split_lock_detect_val)
+   return count;
+
+   /* Only one write can happen at the same time. */
+   mutex_lock(_lock_detect_mutex);
+
+   WRITE_ONCE(split_lock_detect_val, val);
+
+   /* Get MSR_TEST_CTL on this CPU, assuming all CPUs have same value. */
+   rdmsr(MSR_TEST_CTL, l, h);
+   l = new_sp_test_ctl_val(l);
+   /* Update the split lock detection setting on all online CPUs. */
+   for_each_online_cpu(cpu)
+   wrmsr_on_cpu(cpu, MSR_TEST_CTL, l, h);
+
+   mutex_unlock(_lock_detect_mutex);
+
+   return count;
+}
+
+static DEVICE_ATTR_RW(split_lock_detect);
+
+static int __init split_lock_init(void)
+{
+   int ret;
+
+   if (!boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
+   return -ENODEV;
+
+   ret = device_create_file(cpu_subsys.dev_root,
+_attr_split_lock_detect);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+subsys_initcall(split_lock_init);
-- 
2.7.4



[PATCH v4 15/17] kvm: x86: Report CORE_CAPABILITY on GET_SUPPORTED_CPUID

2019-03-01 Thread Fenghua Yu
From: Xiaoyao Li 

In the latest Intel SDM, CPUID.(EAX=7H,ECX=0):EDX[30] will enumerate
the presence of the IA32_CORE_CAPABILITY MSR.

Update GET_SUPPORTED_CPUID to expose this feature bit to user space, so
that user space know this bit can be enabled in CPUID.

Signed-off-by: Xiaoyao Li 
---
 arch/x86/kvm/cpuid.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index c07958b59f50..e0e17b9c65da 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -410,7 +410,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
-   F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP);
+   F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(CORE_CAPABILITY) |
+   F(INTEL_STIBP);
 
/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
-- 
2.7.4



[PATCH v4 13/17] x86/split_lock: Handle #AC exception for split lock

2019-03-01 Thread Fenghua Yu
There may be different considerations on how to handle #AC for split lock,
e.g. how to handle system hang caused by split lock issue in firmware,
how to emulate faulting instruction, etc. We use a simple method to
handle user and kernel split lock and may extend the method in the future.

When #AC exception for split lock is triggered from user process, the
process is killed by SIGBUS. To execute the process properly, user
application developer needs to fix the split lock issue.

When #AC exception for split lock is triggered from a kernel instruction,
disable #AC for split lock on local CPU and warn the split lock issue.
After the exception, the faulting instruction will be executed and kernel
execution continues. #AC for split lock is only disabled on the local CPU
not globally. It will be re-enabled if the CPU is offline and then online.

Kernel developer should check the warning, which contains helpful faulting
address, context, and callstack info, and fix the split lock issue
one by one. Then further split lock may be captured and fixed.

After bit 29 in MSR_TEST_CTL is set as one in kernel, firmware inherits
the setting when firmware is executed in S4, S5, run time services, SMI,
etc. Split lock issue in firmware triggers #AC and may hang the system
depending on how firmware handles the #AC. It's up to firmware developer
to fix the split lock issues in firmware.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/msr-index.h |  4 
 arch/x86/kernel/traps.c  | 31 +++
 2 files changed, 35 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 549e73dcca15..d2d43ebcb8ab 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -39,6 +39,10 @@
 
 /* Intel MSRs. Some also available on other CPUs */
 
+#define MSR_TEST_CTL   0x0033
+#define TEST_CTL_ENABLE_SPLIT_LOCK_DETECT_SHIFT29
+#define TEST_CTL_ENABLE_SPLIT_LOCK_DETECT  BIT(29)
+
 #define MSR_IA32_SPEC_CTRL 0x0048 /* Speculation Control */
 #define SPEC_CTRL_IBRS (1 << 0)   /* Indirect Branch 
Restricted Speculation */
 #define SPEC_CTRL_STIBP_SHIFT  1  /* Single Thread Indirect 
Branch Predictor (STIBP) bit */
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c43c2608332e..63a4dc985340 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -61,6 +61,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -292,7 +293,37 @@ DO_ERROR(X86_TRAP_OLD_MF, SIGFPE,   0, NULL, 
"coprocessor segment overru
 DO_ERROR(X86_TRAP_TS, SIGSEGV,  0, NULL, "invalid TSS", 
invalid_TSS)
 DO_ERROR(X86_TRAP_NP, SIGBUS,   0, NULL, "segment not present", 
segment_not_present)
 DO_ERROR(X86_TRAP_SS, SIGBUS,   0, NULL, "stack segment",   
stack_segment)
+#ifndef CONFIG_CPU_SUP_INTEL
 DO_ERROR(X86_TRAP_AC, SIGBUS,  BUS_ADRALN, NULL, "alignment check", 
alignment_check)
+#else
+dotraplinkage void do_alignment_check(struct pt_regs *regs, long error_code)
+{
+   unsigned int trapnr = X86_TRAP_AC;
+   char str[] = "alignment check";
+   int signr = SIGBUS;
+
+   RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
+
+   if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
+   NOTIFY_STOP) {
+   cond_local_irq_enable(regs);
+   if (!user_mode(regs)) {
+   /*
+* Only split lock can generate #AC from kernel. Warn
+* and disable #AC for split lock on current CPU.
+*/
+   msr_clear_bit(MSR_TEST_CTL,
+ TEST_CTL_ENABLE_SPLIT_LOCK_DETECT_SHIFT);
+   WARN_ONCE(1, "A split lock issue is detected.\n");
+
+   return;
+   }
+   /* Handle #AC generated from user code. */
+   do_trap(X86_TRAP_AC, SIGBUS, "alignment check", regs,
+   error_code, BUS_ADRALN, NULL);
+   }
+}
+#endif
 #undef IP
 
 #ifdef CONFIG_VMAP_STACK
-- 
2.7.4



[PATCH v4 06/17] x86/msr-index: Define IA32_CORE_CAPABILITY MSR and #AC exception for split lock bit

2019-03-01 Thread Fenghua Yu
A new IA32_CORE_CAPABILITY MSR (0xCF) is defined. Each bit in
the MSR enumerates a model specific feature. Currently bit 5 enumerates
#AC exception for split locked accesses. When bit 5 is 1, split locked
accesses will generate #AC exception. When bit 5 is 0, split locked
accesses will not generate #AC exception.

Please check the latest Intel Architecture Instruction Set Extensions
and Future Features Programming Reference for more detailed information
on the MSR and the split lock bit.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/msr-index.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 8e40c2446fd1..549e73dcca15 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -59,6 +59,9 @@
 #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT  31
 #define MSR_PLATFORM_INFO_CPUID_FAULT  
BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
 
+#define MSR_IA32_CORE_CAPABILITY   0x00cf
+#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
+
 #define MSR_PKG_CST_CONFIG_CONTROL 0x00e2
 #define NHM_C3_AUTO_DEMOTE (1UL << 25)
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
-- 
2.7.4



[PATCH v4 00/17] x86/split_lock: Enable #AC exception for split locked accesses

2019-03-01 Thread Fenghua Yu
==Introduction==

A split lock is any atomic operation whose operand crosses two cache
lines. Since the operand spans two cache lines and the operation must
be atomic, the system locks the bus while the CPU accesses the two cache
lines.

During bus locking, request from other CPUs or bus agents for control
of the bus are blocked. Blocking bus access from other CPUs plus
overhead of configuring bus locking protocol degrade not only the
performance of one CPU but overall system performance.

If operand is cacheable and completely contained in one cache line, atomic
operation is optimized by less expensive cache locking on Intel P6 and
recent processors. If split lock is detected and the two cache lines in the
operand can be merged into one cache line, cache locking instead of
more expensive bus locking will be used for atomic operation. Removing
split lock can improve overall performance.

Instructions that may cause split lock issue include lock add, lock btc,
xchg, lsl, far call, ltr, etc.

More information about split lock, bus locking, and cache locking can be
found in the latest Intel 64 and IA-32 Architecture Software Developer's
Manual.

==Split lock detection==

Currently we can trace split lock event counter sq_misc.split_lock
for debug purpose. But for system deployed in the field, this event
counter after the fact is insufficient. We need a mechanism that
detects split lock before it happens to ensure that bus lock is never
incurred due to split lock.

Intel introduces a mechanism to detect split lock via Alignment Check
(#AC) exception before badly aligned atomic instructions might impact
whole system performance in Tremont and other future processors. 

This capability is critical for real time system designers who build
consolidated real time systems. These systems run hard real time
code on some cores and run "untrusted" user processes on some
other cores. The hard real time cannot afford to have any bus lock from
the untrusted processes to hurt real time performance. To date the
designers have been unable to deploy these solutions as they have no
way to prevent the "untrusted" user code from generating split lock and
bus lock to block the hard real time code to access memory during bus
locking.

This capability may also find usage in cloud. A user process with split
lock running in one guest can block other cores from accessing shared
memory during its split locked memory access. That may cause overall
system performance degradation.

Split lock may open a security hole where malicious user code may slow
down overall system by executing instructions with split lock.

==Enumerate #AC for split lock==

A control bit (bit 29) in TEST_CTL MSR 0x33 will be introduced in
future x86 processors. When the bit 29 is set, the processor causes
#AC exception for split locked accesses at all CPL.

The split lock detection feature is enumerated through bit 5 in
MSR IA32_CORE_CAPABILITY (0xCF). The MSR 0xCF itself is enumerated by
CPUID.(EAX=0x7,ECX=0):EDX[30].

The enumeration method is published in the latest Intel Software
Developer's Manual.

A few processors don't follow the above enumeration. For those processors,
we can enable #AC for split lock based on their FMS numbers. We will
enable split lock detection on those processors in the future once their
FMS numbers are public.

==Handle Split Lock===

There may be different considerations to handle split lock, e.g. how
to handle split lock issue in firmware after kernel enables #AC for
split lock.

But we use a simple way to handle split lock which is suggested
by Thomas Gleixner and Dave Hansen:

- If split lock happens in kernel, a warning is issued and #AC for
split lock is disabled on the local CPU. The split lock issue should
be fixed in kernel.

- If split lock happens in user process, the process is killed by
SIGBUS. Unless the issue is fixed, the process cannot run in the
system.

- If split lock happens in firmware, system may hang in firmware. The
issue should be fixed in firmware.

- Enable split lock detection by default once the feature is enumerated.

- Disable split lock detection by "clearcpuid=split_lock_detect" during
boot time.

- Disable/enable split lock detection by interface
/sys/devices/system/cpu/split_lock_detect during run time.

==Expose to guest==

To expose this feature to guest, we need to
1. report the new CPUID bit to guest.
2. emulate IA32_CORE_CAPABILITIES MSR.
3. emulate TEST_CTL MSR. We must do it. Since this patch
series enable split lock detection in host kernel by default, if we do
not emualte TEST_CTL MSR for guest, guest will run with the value set
by host without knowing that. So guest will run with split lock detection
enabled due to the host's value. Thus guest running with buggy firmware
and old kernel will fail because they lack the ability to handle #AC for
split lock. So we should emulate TEST_CTL MSR and separate its value
between host and guest.

==Patches==
Patch 1-4: Fix a few split lock issues.

[GIT] Crypto Fixes for 5.0

2019-03-01 Thread Herbert Xu
Hi Linus: 

This push fixes a couple of issues in arm64/chacha that was
introduced in 5.0.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Eric Biggers (2):
  crypto: arm64/chacha - fix chacha_4block_xor_neon() for big endian
  crypto: arm64/chacha - fix hchacha_block_neon() for big endian

 arch/arm64/crypto/chacha-neon-core.S | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel

2019-03-01 Thread Joel Fernandes
On Sat, Mar 02, 2019 at 11:13:07AM +0900, Masahiro Yamada wrote:
> On Sat, Mar 2, 2019 at 3:03 AM Joel Fernandes  wrote:
> >
> > On Fri, Mar 01, 2019 at 03:25:05PM +0900, Masahiro Yamada wrote:
> > [...]
> > > > > I am guessing the user will run these commands
> > > > > on the target system.
> > > > > In other words, external modules are native-compiled.
> > > > > So,
> > > > >
> > > > >   target-arch: arm64
> > > > >   host-arch:   arm64
> > > > >
> > > > >
> > > > > Is this correct?
> > > > >
> > > > >
> > > > > If I understood the assumed use-case correctly,
> > > > > kheaders.tar.xw will contain host-programs compiled for x86,
> > > > > which will not work on the target system.
> > > > >
> > > >
> > > > You are right, the above commands in the commit message work only if the
> > > > host/target are same arch due to scripts.
> > > >
> > > > However we can build with arm64 device connected to a host, like this 
> > > > (which
> > > > I tested):
> > > >
> > > > adb shell modprobe kheaders; adb pull /proc/kheaders.tar.xz
> > > > rm -rf $HOME/headers; mkdir -p $HOME/headers
> > > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null
> > > > cd my-kernel-module
> > > > make -C $HOME/headers M=$(pwd) ARCH=arm64 CROSS_COMPILE=aarch64- modules
> > > > adb push test.ko /data/; adb shell rmmod kheaders
> > > >
> > > > The other way we can make this work is using x86 usermode emulation 
> > > > inside a
> > > > chroot on the Android device which will make the earlier commands work. 
> > > > One
> > > > thing to note is that Android also runs on x86 hardware so the commands 
> > > > in
> > > > the commit message will work even for x86 Android targets already.
> > > >
> > > > Also note that this the "module building" part is really only one of the
> > > > usecases. eBPF is another which needs the headers - and the headers are 
> > > > vast
> > > > majority of the archive. Headers take 3.1MB out of 3.6MB of the archive 
> > > > on
> > > > arm64 builds.
> > > >
> > > > How do you want to proceed here, should I mention these points in the 
> > > > commit
> > > > message?
> > >
> > >
> > >
> > > I do not request a re-spin just for a matter of commit log,
> > > but this version produces an empty tarball.
> > > So, you will have a chance to update the patch anyway.
> > >
> > > In the next version, it would be nice to note that
> > > "external modules must be built on the same host arch
> > > as built vmlinux".
> >
> > Ok, I respun it with 1 more minor nit for arm64 building. Please take a 
> > look.
> 
> 
> I have not checked code-diff in v3 yet.
> 
> Anyway, I will add comments to v4
> if I notice something.

Ok. Since all your comments from previous series were addressed, it would be
nice to get your Acked-by tag for v4 unless you have further comments or
concerns.

> > > Let me ask one more question.
> > >
> > > I guess this patch is motivated by
> > > how difficult to convey kernel headers
> > > from vendors to users.
> > >
> > > In that situation, how will the user find
> > > the right compiler to use for building external modules?
> > >
> > >
> > >
> > >
> > > Greg KH said:
> > >
> > > We don't ever support the system of loading a module built with anything
> > > other than the _exact_ same compiler than the kernel was.
> > >
> > >
> > > For the full context, see this:
> > > https://lore.kernel.org/patchwork/patch/836247/#1031547
> >
> > IMO this issue is not related to this patch but is just an issue with
> > building external modules in general.
> 
> 
> I do not think it is an issue of the build system, at least.
> 
> As far as I understood Greg's comment, it is troublesome
> without the assumption that vmlinux and modules are built
> by the same compiler.
> It is related to this patch since this patch assumes use-cases
> where external modules are built in a completely different environment,
> where a different compiler is probably installed.

Yes, but what I'm trying to say is the same issue exists with all other
solutions today that do this. Such as debian you have linux-headers package.
A user could totally use the build artifacts obtained from somewhere to build
a kernel module with a completely different compiler. That issue has just to
do with the reality, and isn't an issue caused by any one solution such as
this one.  I agree care must be taken whenever user is building external
kernel modules independent of kernel sources.  Did I miss something else?

thanks a lot,

 - Joel



[PATCH] net-sysfs: Fix mem leak in netdev_register_kobject

2019-03-01 Thread Yue Haibing
From: YueHaibing 

syzkaller report this:
BUG: memory leak
unreferenced object 0x88837a71a500 (size 256):
  comm "syz-executor.2", pid 9770, jiffies 4297825125 (age 17.843s)
  hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .N..
ff ff ff ff ff ff ff ff 20 c0 ef 86 ff ff ff ff   ...
  backtrace:
[] netdev_register_kobject+0x124/0x2e0 
net/core/net-sysfs.c:1751
[] register_netdevice+0xcc1/0x1270 net/core/dev.c:8516
[] tun_set_iff drivers/net/tun.c:2649 [inline]
[] __tun_chr_ioctl+0x2218/0x3d20 drivers/net/tun.c:2883
[<1b8ac127>] vfs_ioctl fs/ioctl.c:46 [inline]
[<1b8ac127>] do_vfs_ioctl+0x1a5/0x10e0 fs/ioctl.c:690
[<79b269f8>] ksys_ioctl+0x89/0xa0 fs/ioctl.c:705
[] __do_sys_ioctl fs/ioctl.c:712 [inline]
[] __se_sys_ioctl fs/ioctl.c:710 [inline]
[] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:710
[<7ebded1e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
[] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[<115be9bb>] 0x

It should call kset_unregister to free 'dev->queues_kset'
in error path of register_queue_kobjects, otherwise will cause a mem leak.

Reported-by: Hulk Robot 
Fixes: 1d24eb4815d1 ("xps: Transmit Packet Steering")
Signed-off-by: YueHaibing 
---
 net/core/net-sysfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 7c50611..bbeb606 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -1541,6 +1541,9 @@ static int register_queue_kobjects(struct net_device *dev)
 error:
netdev_queue_update_kobjects(dev, txq, 0);
net_rx_queue_update_kobjects(dev, rxq, 0);
+#ifdef CONFIG_SYSFS
+   kset_unregister(dev->queues_kset);
+#endif
return error;
 }
 
-- 
2.7.0




Re: [PATCH] x86/boot: clean up headers

2019-03-01 Thread Stephen Rothwell
Hi Nick,

On Sat, 2 Mar 2019 13:27:50 +1100 Stephen Rothwell  
wrote:
>
> On Fri,  1 Mar 2019 16:07:14 -0800 Nick Desaulniers  
> wrote:
> >
> > It turns out that arch/x86/boot/string.c doesn't actually need
> > linux/kernel.h, simply linux/limits.h and linux/compiler.h. Include them,
> > and sort the headers alphabetically.  
> 
> One small nit: please do not do the sort in the same commit as the bug
> fix.  It just complicates the review and has (a remote) possibility of
> adding a new problem.  (Not a big issue here, but in general cleanups
> and bug fixes should be separate.)

Also it is *very* common for headers to be included in the order:
linux/ asm/ and then local.

-- 
Cheers,
Stephen Rothwell


pgpurutBvw_46.pgp
Description: OpenPGP digital signature


Re: [PATCH] x86/boot: clean up headers

2019-03-01 Thread Stephen Rothwell
Hi Nick,

On Fri,  1 Mar 2019 16:07:14 -0800 Nick Desaulniers  
wrote:
>
> It turns out that arch/x86/boot/string.c doesn't actually need
> linux/kernel.h, simply linux/limits.h and linux/compiler.h. Include them,
> and sort the headers alphabetically.

One small nit: please do not do the sort in the same commit as the bug
fix.  It just complicates the review and has (a remote) possibility of
adding a new problem.  (Not a big issue here, but in general cleanups
and bug fixes should be separate.)
-- 
Cheers,
Stephen Rothwell


pgpB7yydg0grY.pgp
Description: OpenPGP digital signature


Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel

2019-03-01 Thread Masahiro Yamada
On Sat, Mar 2, 2019 at 3:03 AM Joel Fernandes  wrote:
>
> On Fri, Mar 01, 2019 at 03:25:05PM +0900, Masahiro Yamada wrote:
> [...]
> > > > I am guessing the user will run these commands
> > > > on the target system.
> > > > In other words, external modules are native-compiled.
> > > > So,
> > > >
> > > >   target-arch: arm64
> > > >   host-arch:   arm64
> > > >
> > > >
> > > > Is this correct?
> > > >
> > > >
> > > > If I understood the assumed use-case correctly,
> > > > kheaders.tar.xw will contain host-programs compiled for x86,
> > > > which will not work on the target system.
> > > >
> > >
> > > You are right, the above commands in the commit message work only if the
> > > host/target are same arch due to scripts.
> > >
> > > However we can build with arm64 device connected to a host, like this 
> > > (which
> > > I tested):
> > >
> > > adb shell modprobe kheaders; adb pull /proc/kheaders.tar.xz
> > > rm -rf $HOME/headers; mkdir -p $HOME/headers
> > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null
> > > cd my-kernel-module
> > > make -C $HOME/headers M=$(pwd) ARCH=arm64 CROSS_COMPILE=aarch64- modules
> > > adb push test.ko /data/; adb shell rmmod kheaders
> > >
> > > The other way we can make this work is using x86 usermode emulation 
> > > inside a
> > > chroot on the Android device which will make the earlier commands work. 
> > > One
> > > thing to note is that Android also runs on x86 hardware so the commands in
> > > the commit message will work even for x86 Android targets already.
> > >
> > > Also note that this the "module building" part is really only one of the
> > > usecases. eBPF is another which needs the headers - and the headers are 
> > > vast
> > > majority of the archive. Headers take 3.1MB out of 3.6MB of the archive on
> > > arm64 builds.
> > >
> > > How do you want to proceed here, should I mention these points in the 
> > > commit
> > > message?
> >
> >
> >
> > I do not request a re-spin just for a matter of commit log,
> > but this version produces an empty tarball.
> > So, you will have a chance to update the patch anyway.
> >
> > In the next version, it would be nice to note that
> > "external modules must be built on the same host arch
> > as built vmlinux".
>
> Ok, I respun it with 1 more minor nit for arm64 building. Please take a look.


I have not checked code-diff in v3 yet.

Anyway, I will add comments to v4
if I notice something.


> > Let me ask one more question.
> >
> > I guess this patch is motivated by
> > how difficult to convey kernel headers
> > from vendors to users.
> >
> > In that situation, how will the user find
> > the right compiler to use for building external modules?
> >
> >
> >
> >
> > Greg KH said:
> >
> > We don't ever support the system of loading a module built with anything
> > other than the _exact_ same compiler than the kernel was.
> >
> >
> > For the full context, see this:
> > https://lore.kernel.org/patchwork/patch/836247/#1031547
>
> IMO this issue is not related to this patch but is just an issue with
> building external modules in general.


I do not think it is an issue of the build system, at least.

As far as I understood Greg's comment, it is troublesome
without the assumption that vmlinux and modules are built
by the same compiler.

It is related to this patch since this patch assumes use-cases
where external modules are built in a completely different environment,
where a different compiler is probably installed.



> It is up to the user to use the right
> compiler, etc. I will let Greg comment more on that.







> thanks,
>
>  - Joel
>


-- 
Best Regards
Masahiro Yamada


Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

2019-03-01 Thread Larry Finger

On 3/1/19 4:26 PM, David R. Bergstein wrote:

Larry,

Thanks for the response and detailed instructions, which allowed me to
build and install the rtw88 kernel module.  I cannot however seem to get
my system to actually use the module.  Just to recap this is an HP Omen
laptop with secure boot disabled.  Upon boot-up both the new rtw88 and
old r8822be modules are loaded.  If I unload the r8822be module the wifi
network connection gets terminated, even if I unload/reload the rtw88
module.

Is there something else I should be doing prior to invoking rtw88, e.g.,
blacklisting the old module?


Yes, r8822be must be blacklisted. Use the lsmod command to see what modules are 
actually loaded. You load/unload rtw88 using the rtwpci module.


Larry



Re: [PATCH] update NFIT flags error message

2019-03-01 Thread Dan Williams
On Thu, Feb 28, 2019 at 12:14 PM Toshi Kani  wrote:
>
> ACPI NFIT flags field reports major errors on NVDIMM, which need
> user's attention.
>
> Update the current log to a proper error message with dev_err().
> The current message string is kept for grep-compatibility.
>

Looks good, applied.


Re: [PATCH -next] fbdev: omap2: omapfb: trivial code cleanup

2019-03-01 Thread YueHaibing
On 2019/3/1 22:50, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On 03/01/2019 02:53 AM, Yue Haibing wrote:
>> From: YueHaibing 
>>
>> After commit 60d2fa0dad06 ("fbdev: omap2: no need to check
>> return value of debugfs_create functions"), there are corner
>> code need to be cleaned.
>>
>> Signed-off-by: YueHaibing 
> 
> Thanks but I've already applied earlier patch from Anders Roxell:
> 
> https://marc.info/?l=linux-fbdev=155004766902831=2

Good to know this, Thanks!

> 
>> ---
>>  drivers/video/fbdev/omap2/omapfb/dss/core.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/core.c 
>> b/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> index 7e6a3eb..b5956a1 100644
>> --- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
>> @@ -136,7 +136,6 @@ static inline void dss_uninitialize_debugfs(void)
>>  }
>>  void dss_debugfs_create_file(const char *name, void (*write)(struct 
>> seq_file *))
>>  {
>> -return 0;
>>  }
>>  #endif /* CONFIG_FB_OMAP2_DSS_DEBUGFS */
>>  
>> @@ -169,8 +168,6 @@ static struct notifier_block omap_dss_pm_notif_block = {
>>  
>>  static int __init omap_dss_probe(struct platform_device *pdev)
>>  {
>> -int r;
>> -
>>  core.pdev = pdev;
>>  
>>  dss_features_init(omapdss_get_version());
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
> 
> 



[PATCH v2 6/7] perf script python: add Python3 support to sql scripts

2019-03-01 Thread Tony Jones
Support both Python2 and Python3 in the exported-sql-viewer.py,
export-to-postgresql.py and export-to-sqlite.py scripts

There may be differences in the ordering of output lines due to
differences in dictionary ordering etc.  However the format within lines
should be unchanged.

The use of 'from __future__' implies the minimum supported Python2 version
is now v2.6

Signed-off-by: Tony Jones 
Signed-off-by: Seeteena Thoufeek 
Cc: Adrian Hunter 
---
 tools/perf/scripts/python/export-to-postgresql.py | 65 +++
 tools/perf/scripts/python/export-to-sqlite.py | 23 
 tools/perf/scripts/python/exported-sql-viewer.py  | 42 ++-
 3 files changed, 84 insertions(+), 46 deletions(-)

diff --git a/tools/perf/scripts/python/export-to-postgresql.py 
b/tools/perf/scripts/python/export-to-postgresql.py
index 390a351d15ea..439bbbf1e036 100644
--- a/tools/perf/scripts/python/export-to-postgresql.py
+++ b/tools/perf/scripts/python/export-to-postgresql.py
@@ -10,6 +10,8 @@
 # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 # more details.
 
+from __future__ import print_function
+
 import os
 import sys
 import struct
@@ -199,6 +201,16 @@ import datetime
 
 from PySide.QtSql import *
 
+if sys.version_info < (3, 0):
+   def tobytes(str):
+   return str
+else:
+   def tobytes(str):
+   # Use latin-1 (ISO-8859-1) so all code-points 0-255 will result
+   # in one byte (note utf-8 is 2 bytes for values > 128 and
+   # ascii is limited to values <= 128)
+   return bytes(str, "ISO-8859-1")
+
 # Need to access PostgreSQL C library directly to use COPY FROM STDIN
 from ctypes import *
 libpq = CDLL("libpq.so.5")
@@ -234,12 +246,14 @@ perf_db_export_mode = True
 perf_db_export_calls = False
 perf_db_export_callchains = False
 
+def printerr(*args, **kw_args):
+   print(*args, file=sys.stderr, **kw_args)
 
 def usage():
-   print >> sys.stderr, "Usage is: export-to-postgresql.py  
[] [] []"
-   print >> sys.stderr, "where:columns 'all' or 'branches'"
-   print >> sys.stderr, "  calls   'calls' => create calls 
and call_paths table"
-   print >> sys.stderr, "  callchains  'callchains' => create 
call_paths table"
+   printerr("Usage is: export-to-postgresql.py  [] 
[] []")
+   printerr("where:columns 'all' or 'branches'")
+   printerr("  calls   'calls' => create calls and 
call_paths table")
+   printerr("  callchains  'callchains' => create 
call_paths table")
raise Exception("Too few arguments")
 
 if (len(sys.argv) < 2):
@@ -273,7 +287,7 @@ def do_query(q, s):
return
raise Exception("Query failed: " + q.lastError().text())
 
-print datetime.datetime.today(), "Creating database..."
+print(datetime.datetime.today(), "Creating database...")
 
 db = QSqlDatabase.addDatabase('QPSQL')
 query = QSqlQuery(db)
@@ -506,12 +520,12 @@ do_query(query, 'CREATE VIEW samples_view AS '
' FROM samples')
 
 
-file_header = struct.pack("!11sii", "PGCOPY\n\377\r\n\0", 0, 0)
-file_trailer = "\377\377"
+file_header = struct.pack("!11sii", tobytes("PGCOPY\n\377\r\n\0"), 0, 0)
+file_trailer = tobytes("\377\377")
 
 def open_output_file(file_name):
path_name = output_dir_name + "/" + file_name
-   file = open(path_name, "w+")
+   file = open(path_name, "wb+")
file.write(file_header)
return file
 
@@ -526,13 +540,13 @@ def copy_output_file_direct(file, table_name):
 
 # Use COPY FROM STDIN because security may prevent postgres from accessing the 
files directly
 def copy_output_file(file, table_name):
-   conn = PQconnectdb("dbname = " + dbname)
+   conn = PQconnectdb(tobytes("dbname = " + dbname))
if (PQstatus(conn)):
raise Exception("COPY FROM STDIN PQconnectdb failed")
file.write(file_trailer)
file.seek(0)
sql = "COPY " + table_name + " FROM STDIN (FORMAT 'binary')"
-   res = PQexec(conn, sql)
+   res = PQexec(conn, tobytes(sql))
if (PQresultStatus(res) != 4):
raise Exception("COPY FROM STDIN PQexec failed")
data = file.read(65536)
@@ -566,7 +580,7 @@ if perf_db_export_calls:
call_file   = open_output_file("call_table.bin")
 
 def trace_begin():
-   print datetime.datetime.today(), "Writing to intermediate files..."
+   print(datetime.datetime.today(), "Writing to intermediate files...")
# id == 0 means unknown.  It is easier to create records for them than 
replace the zeroes with NULLs
evsel_table(0, "unknown")
machine_table(0, 0, "unknown")
@@ -582,7 +596,7 @@ def trace_begin():
 unhandled_count = 0
 
 def trace_end():
-   print datetime.datetime.today(), "Copying to database..."
+   print(datetime.datetime.today(), "Copying to database...")

[PATCH v2 5/7] perf script python: add Python3 support to intel-pt-events.py

2019-03-01 Thread Tony Jones
Support both Python2 and Python3 in the intel-pt-events.py script

There may be differences in the ordering of output lines due to
differences in dictionary ordering etc.  However the format within lines
should be unchanged.

The use of 'from __future__' implies the minimum supported Python2 version
is now v2.6

Signed-off-by: Tony Jones 
Signed-off-by: Seeteena Thoufeek 
Cc: Adrian Hunter 
---
 tools/perf/scripts/python/intel-pt-events.py | 30 +---
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/tools/perf/scripts/python/intel-pt-events.py 
b/tools/perf/scripts/python/intel-pt-events.py
index 2177722f509e..5c42c4c359dc 100644
--- a/tools/perf/scripts/python/intel-pt-events.py
+++ b/tools/perf/scripts/python/intel-pt-events.py
@@ -10,6 +10,8 @@
 # FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 # more details.
 
+from __future__ import print_function
+
 import os
 import sys
 import struct
@@ -22,10 +24,10 @@ sys.path.append(os.environ['PERF_EXEC_PATH'] + \
 #from Core import *
 
 def trace_begin():
-   print "Intel PT Power Events and PTWRITE"
+   print("Intel PT Power Events and PTWRITE")
 
 def trace_end():
-   print "End"
+   print("End")
 
 def trace_unhandled(event_name, context, event_fields_dict):
print ' '.join(['%s=%s'%(k,str(v))for k,v in 
sorted(event_fields_dict.items())])
@@ -35,21 +37,21 @@ def print_ptwrite(raw_buf):
flags = data[0]
payload = data[1]
exact_ip = flags & 1
-   print "IP: %u payload: %#x" % (exact_ip, payload),
+   print("IP: %u payload: %#x" % (exact_ip, payload), end=' ')
 
 def print_cbr(raw_buf):
data = struct.unpack_from("> 32) & 0x3
-   print "hints: %#x extensions: %#x" % (hints, extensions),
+   print("hints: %#x extensions: %#x" % (hints, extensions), end=' ')
 
 def print_pwre(raw_buf):
data = struct.unpack_from("> 7) & 1
cstate = (payload >> 12) & 0xf
subcstate = (payload >> 8) & 0xf
-   print "hw: %u cstate: %u sub-cstate: %u" % (hw, cstate, subcstate),
+   print("hw: %u cstate: %u sub-cstate: %u" % (hw, cstate, subcstate),
+   end=' ')
 
 def print_exstop(raw_buf):
data = struct.unpack_from("> 4) & 0xf
wake_reason = (payload >> 8) & 0xf
-   print "deepest cstate: %u last cstate: %u wake reason: %#x" % 
(deepest_cstate, last_cstate, wake_reason),
+   print("deepest cstate: %u last cstate: %u wake reason: %#x" %
+   (deepest_cstate, last_cstate, wake_reason), end=' ')
 
 def print_common_start(comm, sample, name):
ts = sample["time"]
cpu = sample["cpu"]
pid = sample["pid"]
tid = sample["tid"]
-   print "%16s %5u/%-5u [%03u] %9u.%09u %7s:" % (comm, pid, tid, cpu, ts / 
10, ts %10, name),
+   print("%16s %5u/%-5u [%03u] %9u.%09u %7s:" %
+   (comm, pid, tid, cpu, ts / 10, ts %10, name),
+   end=' ')
 
 def print_common_ip(sample, symbol, dso):
ip = sample["ip"]
-   print "%16x %s (%s)" % (ip, symbol, dso)
+   print("%16x %s (%s)" % (ip, symbol, dso))
 
 def process_event(param_dict):
event_attr = param_dict["attr"]
@@ -92,12 +98,12 @@ def process_event(param_dict):
name   = param_dict["ev_name"]
 
# Symbol and dso info are not always resolved
-   if (param_dict.has_key("dso")):
+   if "dso" in param_dict:
dso = param_dict["dso"]
else:
dso = "[unknown]"
 
-   if (param_dict.has_key("symbol")):
+   if "symbol" in param_dict:
symbol = param_dict["symbol"]
else:
symbol = "[unknown]"
-- 
2.16.4



[PATCH v2 4/7] perf script python: add Python3 support to event_analyzing_sample.py

2019-03-01 Thread Tony Jones
Support both Python2 and Python3 in the event_analyzing_sample.py script

There may be differences in the ordering of output lines due to
differences in dictionary ordering etc.  However the format within lines
should be unchanged.

The use of 'from __future__' implies the minimum supported Python2 version
is now v2.6

Signed-off-by: Tony Jones 
Signed-off-by: Seeteena Thoufeek 
Cc: Feng Tang 
---
 .../perf/scripts/python/event_analyzing_sample.py  | 48 +++---
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/tools/perf/scripts/python/event_analyzing_sample.py 
b/tools/perf/scripts/python/event_analyzing_sample.py
index 2ec8915b74c5..aa1e2cfa26a6 100644
--- a/tools/perf/scripts/python/event_analyzing_sample.py
+++ b/tools/perf/scripts/python/event_analyzing_sample.py
@@ -15,6 +15,8 @@
 # for a x86 HW PMU event: PEBS with load latency data.
 #
 
+from __future__ import print_function
+
 import os
 import sys
 import math
@@ -37,7 +39,7 @@ con = sqlite3.connect("/dev/shm/perf.db")
 con.isolation_level = None
 
 def trace_begin():
-print "In trace_begin:\n"
+print("In trace_begin:\n")
 
 #
 # Will create several tables at the start, pebs_ll is for PEBS data 
with
@@ -76,12 +78,12 @@ def process_event(param_dict):
 name   = param_dict["ev_name"]
 
 # Symbol and dso info are not always resolved
-if (param_dict.has_key("dso")):
+if ("dso" in param_dict):
 dso = param_dict["dso"]
 else:
 dso = "Unknown_dso"
 
-if (param_dict.has_key("symbol")):
+if ("symbol" in param_dict):
 symbol = param_dict["symbol"]
 else:
 symbol = "Unknown_symbol"
@@ -102,7 +104,7 @@ def insert_db(event):
 event.ip, event.status, event.dse, event.dla, 
event.lat))
 
 def trace_end():
-print "In trace_end:\n"
+print("In trace_end:\n")
 # We show the basic info for the 2 type of event classes
 show_general_events()
 show_pebs_ll()
@@ -123,29 +125,29 @@ def show_general_events():
 # Check the total record number in the table
 count = con.execute("select count(*) from gen_events")
 for t in count:
-print "There is %d records in gen_events table" % t[0]
+print("There is %d records in gen_events table" % t[0])
 if t[0] == 0:
 return
 
-print "Statistics about the general events grouped by 
thread/symbol/dso: \n"
+print("Statistics about the general events grouped by 
thread/symbol/dso: \n")
 
  # Group by thread
 commq = con.execute("select comm, count(comm) from gen_events group by 
comm order by -count(comm)")
-print "\n%16s %8s %16s\n%s" % ("comm", "number", "histogram", "="*42)
+print("\n%16s %8s %16s\n%s" % ("comm", "number", "histogram", "="*42))
 for row in commq:
- print "%16s %8d %s" % (row[0], row[1], num2sym(row[1]))
+ print("%16s %8d %s" % (row[0], row[1], num2sym(row[1])))
 
 # Group by symbol
-print "\n%32s %8s %16s\n%s" % ("symbol", "number", "histogram", "="*58)
+print("\n%32s %8s %16s\n%s" % ("symbol", "number", "histogram", 
"="*58))
 symbolq = con.execute("select symbol, count(symbol) from gen_events 
group by symbol order by -count(symbol)")
 for row in symbolq:
- print "%32s %8d %s" % (row[0], row[1], num2sym(row[1]))
+ print("%32s %8d %s" % (row[0], row[1], num2sym(row[1])))
 
 # Group by dso
-print "\n%40s %8s %16s\n%s" % ("dso", "number", "histogram", "="*74)
+print("\n%40s %8s %16s\n%s" % ("dso", "number", "histogram", "="*74))
 dsoq = con.execute("select dso, count(dso) from gen_events group by 
dso order by -count(dso)")
 for row in dsoq:
- print "%40s %8d %s" % (row[0], row[1], num2sym(row[1]))
+ print("%40s %8d %s" % (row[0], row[1], num2sym(row[1])))
 
 #
 # This function just shows the basic info, and we could do more with the
@@ -156,35 +158,35 @@ def show_pebs_ll():
 
 count = con.execute("select count(*) from pebs_ll")
 for t in count:
-print "There is %d records in pebs_ll table" % t[0]
+print("There is %d records in pebs_ll table" % t[0])
 if t[0] == 0:
 return
 
-print "Statistics about the PEBS Load Latency events grouped by 
thread/symbol/dse/latency: \n"
+print("Statistics about the PEBS Load Latency events grouped by 
thread/symbol/dse/latency: \n")
 
 # Group by thread
 commq = con.execute("select comm, count(comm) from pebs_ll group by 
comm order by -count(comm)")
-print "\n%16s %8s %16s\n%s" % ("comm", "number", "histogram", "="*42)
+print("\n%16s %8s %16s\n%s" % ("comm", "number", 

[PATCH v2 7/7] perf script python: add printdate function to SQL exporters

2019-03-01 Thread Tony Jones
Introduce a printdate function to eliminate the repetitive use of
datetime.datetime.today() in the SQL exporting scripts.

Signed-off-by: Tony Jones 
Cc: Adrian Hunter 
---
 tools/perf/scripts/python/export-to-postgresql.py | 19 +++
 tools/perf/scripts/python/export-to-sqlite.py | 13 -
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/tools/perf/scripts/python/export-to-postgresql.py 
b/tools/perf/scripts/python/export-to-postgresql.py
index 439bbbf1e036..515dc5506427 100644
--- a/tools/perf/scripts/python/export-to-postgresql.py
+++ b/tools/perf/scripts/python/export-to-postgresql.py
@@ -249,6 +249,9 @@ perf_db_export_callchains = False
 def printerr(*args, **kw_args):
print(*args, file=sys.stderr, **kw_args)
 
+def printdate(*args, **kw_args):
+print(datetime.datetime.today(), *args, sep=' ', **kw_args)
+
 def usage():
printerr("Usage is: export-to-postgresql.py  [] 
[] []")
printerr("where:columns 'all' or 'branches'")
@@ -287,7 +290,7 @@ def do_query(q, s):
return
raise Exception("Query failed: " + q.lastError().text())
 
-print(datetime.datetime.today(), "Creating database...")
+printdate("Creating database...")
 
 db = QSqlDatabase.addDatabase('QPSQL')
 query = QSqlQuery(db)
@@ -580,7 +583,7 @@ if perf_db_export_calls:
call_file   = open_output_file("call_table.bin")
 
 def trace_begin():
-   print(datetime.datetime.today(), "Writing to intermediate files...")
+   printdate("Writing to intermediate files...")
# id == 0 means unknown.  It is easier to create records for them than 
replace the zeroes with NULLs
evsel_table(0, "unknown")
machine_table(0, 0, "unknown")
@@ -596,7 +599,7 @@ def trace_begin():
 unhandled_count = 0
 
 def trace_end():
-   print(datetime.datetime.today(), "Copying to database...")
+   printdate("Copying to database...")
copy_output_file(evsel_file,"selected_events")
copy_output_file(machine_file,  "machines")
copy_output_file(thread_file,   "threads")
@@ -611,7 +614,7 @@ def trace_end():
if perf_db_export_calls:
copy_output_file(call_file, "calls")
 
-   print(datetime.datetime.today(), "Removing intermediate files...")
+   printdate("Removing intermediate files...")
remove_output_file(evsel_file)
remove_output_file(machine_file)
remove_output_file(thread_file)
@@ -626,7 +629,7 @@ def trace_end():
if perf_db_export_calls:
remove_output_file(call_file)
os.rmdir(output_dir_name)
-   print(datetime.datetime.today(), "Adding primary keys")
+   printdate("Adding primary keys")
do_query(query, 'ALTER TABLE selected_events ADD PRIMARY KEY (id)')
do_query(query, 'ALTER TABLE machinesADD PRIMARY KEY (id)')
do_query(query, 'ALTER TABLE threads ADD PRIMARY KEY (id)')
@@ -641,7 +644,7 @@ def trace_end():
if perf_db_export_calls:
do_query(query, 'ALTER TABLE calls   ADD PRIMARY KEY 
(id)')
 
-   print(datetime.datetime.today(), "Adding foreign keys")
+   printdate("Adding foreign keys")
do_query(query, 'ALTER TABLE threads '
'ADD CONSTRAINT machinefk  FOREIGN KEY 
(machine_id)   REFERENCES machines   (id),'
'ADD CONSTRAINT processfk  FOREIGN KEY 
(process_id)   REFERENCES threads(id)')
@@ -677,8 +680,8 @@ def trace_end():
do_query(query, 'CREATE INDEX pid_idx ON calls (parent_id)')
 
if (unhandled_count):
-   print(datetime.datetime.today(), "Warning: ", unhandled_count, 
" unhandled events")
-   print(datetime.datetime.today(), "Done")
+   printdate("Warning: ", unhandled_count, " unhandled events")
+   printdate("Done")
 
 def trace_unhandled(event_name, context, event_fields_dict):
global unhandled_count
diff --git a/tools/perf/scripts/python/export-to-sqlite.py 
b/tools/perf/scripts/python/export-to-sqlite.py
index 3da338243aed..3b71902a5a21 100644
--- a/tools/perf/scripts/python/export-to-sqlite.py
+++ b/tools/perf/scripts/python/export-to-sqlite.py
@@ -65,6 +65,9 @@ perf_db_export_callchains = False
 def printerr(*args, **keyword_args):
print(*args, file=sys.stderr, **keyword_args)
 
+def printdate(*args, **kw_args):
+print(datetime.datetime.today(), *args, sep=' ', **kw_args)
+
 def usage():
printerr("Usage is: export-to-sqlite.py  [] 
[] []");
printerr("where:columns 'all' or 'branches'");
@@ -105,7 +108,7 @@ def do_query_(q):
return
raise Exception("Query failed: " + q.lastError().text())
 
-print(datetime.datetime.today(), "Creating database ...")
+printdate("Creating database ...")
 
 db_exists = False
 try:
@@ -383,7 +386,7 @@ if 

[PATCH v2 3/7] perf script python: add Python3 support to check-perf-trace.py

2019-03-01 Thread Tony Jones
Support both Python 2 and Python 3 in the check-perf-trace.py script.

There may be differences in the ordering of output lines due to
differences in dictionary ordering etc.  However the format within lines
should be unchanged.

The use of from __future__ implies the minimum supported version of
Python2 is now v2.6

Signed-off-by: Tony Jones 
Signed-off-by: Seeteena Thoufeek 
Cc: Tom Zanussi 
---
 tools/perf/scripts/python/check-perf-trace.py | 31 +++
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/tools/perf/scripts/python/check-perf-trace.py 
b/tools/perf/scripts/python/check-perf-trace.py
index f4838db3e518..d2c22954800d 100644
--- a/tools/perf/scripts/python/check-perf-trace.py
+++ b/tools/perf/scripts/python/check-perf-trace.py
@@ -7,6 +7,8 @@
 # events, etc.  Basically, if this script runs successfully and
 # displays expected results, Python scripting support should be ok.
 
+from __future__ import print_function
+
 import os
 import sys
 
@@ -19,7 +21,7 @@ from perf_trace_context import *
 unhandled = autodict()
 
 def trace_begin():
-   print "trace_begin"
+   print("trace_begin")
pass
 
 def trace_end():
@@ -33,7 +35,7 @@ def irq__softirq_entry(event_name, context, common_cpu,
 
print_uncommon(context)
 
-   print "vec=%s\n" % (symbol_str("irq__softirq_entry", "vec", vec)),
+   print("vec=%s" % (symbol_str("irq__softirq_entry", "vec", vec)))
 
 def kmem__kmalloc(event_name, context, common_cpu,
  common_secs, common_nsecs, common_pid, common_comm,
@@ -44,10 +46,10 @@ def kmem__kmalloc(event_name, context, common_cpu,
 
print_uncommon(context)
 
-   print "call_site=%u, ptr=%u, bytes_req=%u, " \
-   "bytes_alloc=%u, gfp_flags=%s\n" % \
+   print("call_site=%u, ptr=%u, bytes_req=%u, "
+   "bytes_alloc=%u, gfp_flags=%s" %
(call_site, ptr, bytes_req, bytes_alloc,
-   flag_str("kmem__kmalloc", "gfp_flags", gfp_flags)),
+   flag_str("kmem__kmalloc", "gfp_flags", gfp_flags)))
 
 def trace_unhandled(event_name, context, event_fields_dict):
try:
@@ -56,26 +58,27 @@ def trace_unhandled(event_name, context, event_fields_dict):
unhandled[event_name] = 1
 
 def print_header(event_name, cpu, secs, nsecs, pid, comm):
-   print "%-20s %5u %05u.%09u %8u %-20s " % \
+   print("%-20s %5u %05u.%09u %8u %-20s " %
(event_name, cpu, secs, nsecs, pid, comm),
+   end=' ')
 
 # print trace fields not included in handler args
 def print_uncommon(context):
-   print "common_preempt_count=%d, common_flags=%s, " \
-   "common_lock_depth=%d, " % \
+   print("common_preempt_count=%d, common_flags=%s, "
+   "common_lock_depth=%d, " %
(common_pc(context), trace_flag_str(common_flags(context)),
-   common_lock_depth(context))
+   common_lock_depth(context)))
 
 def print_unhandled():
keys = unhandled.keys()
if not keys:
return
 
-   print "\nunhandled events:\n\n",
+   print("\nunhandled events:\n")
 
-   print "%-40s  %10s\n" % ("event", "count"),
-   print "%-40s  %10s\n" % ("", \
-   "---"),
+   print("%-40s  %10s" % ("event", "count"))
+   print("%-40s  %10s" % ("",
+   "---"))
 
for event_name in keys:
-   print "%-40s  %10d\n" % (event_name, unhandled[event_name])
+   print("%-40s  %10d\n" % (event_name, unhandled[event_name]))
-- 
2.16.4



[PATCH v2 0/7] perf script python: add Python3 support

2019-03-01 Thread Tony Jones
This is v2 of my version of the patchset.  Incorporating the 
previous feedback.  Some changes from v1 were already merged.

Patch 1/7 deals with the existing inconsistent indentation.
Indentation is now consistent per file but varying styles (tabs,
4 spaces and 8 spaces).   
I will followup at a later date with changes to checkpatch to ensure
that the syntax per file is maintained.

Patches 2/7 through 5/7 were sent in v1,  they have been changed 
to remove the previous indentation changes

Patch 6/7 was sent in v1.  I had previously *not* been able to test 
export-to-postgresql.py.  I was able to do so this time and found
that more changes were needed.The author of the original code
seems concerned about code-style so I would suggest you only merge 
with his explicit ACK.

Patch 7/7 was not in v1, it cleans up some repeated use of date
functions in the SQL exporters.  It is not mandatory for Python3
support.  It is dependent on Patch#6.

I hope I've got everything correct, I've retested until I feel I 
can't look at Python code anymore for a while :-). Hopefully I've 
not made any more mistakes.  If I have, please LMK and I'll do v3.

Thanks

Tony


[PATCH v2 2/7] perf script python: add Python3 support to futex-contention.py

2019-03-01 Thread Tony Jones
Support both Python2 and Python3 in the futex-contention.py script

There may be differences in the ordering of output lines due to
differences in dictionary ordering etc.  However the format within lines
should be unchanged.

The use of 'from __future__' implies the minimum supported Python2 version
is now v2.6

Signed-off-by: Tony Jones 
Signed-off-by: Seeteena Thoufeek 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/scripts/python/futex-contention.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/perf/scripts/python/futex-contention.py 
b/tools/perf/scripts/python/futex-contention.py
index f221c62e0a10..0c4841acf75d 100644
--- a/tools/perf/scripts/python/futex-contention.py
+++ b/tools/perf/scripts/python/futex-contention.py
@@ -10,6 +10,8 @@
 #
 # Measures futex contention
 
+from __future__ import print_function
+
 import os, sys
 sys.path.append(os.environ['PERF_EXEC_PATH'] + 
'/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
 from Util import *
@@ -33,18 +35,18 @@ def syscalls__sys_enter_futex(event, ctxt, cpu, s, ns, tid, 
comm, callchain,
 
 def syscalls__sys_exit_futex(event, ctxt, cpu, s, ns, tid, comm, callchain,
 nr, ret):
-   if thread_blocktime.has_key(tid):
+   if tid in thread_blocktime:
elapsed = nsecs(s, ns) - thread_blocktime[tid]
add_stats(lock_waits, (tid, thread_thislock[tid]), elapsed)
del thread_blocktime[tid]
del thread_thislock[tid]
 
 def trace_begin():
-   print "Press control+C to stop and show the summary"
+   print("Press control+C to stop and show the summary")
 
 def trace_end():
for (tid, lock) in lock_waits:
min, max, avg, count = lock_waits[tid, lock]
-   print "%s[%d] lock %x contended %d times, %d avg ns" % \
-   (process_names[tid], tid, lock, count, avg)
+   print("%s[%d] lock %x contended %d times, %d avg ns" %
+   (process_names[tid], tid, lock, count, avg))
 
-- 
2.16.4



[PATCH v2 1/7] perf script python: remove mixed indentation

2019-03-01 Thread Tony Jones
Remove mixed indentation in Python scripts.  Revert to either all 
tabs (most common form) or all spaces (4 or 8) depending on what 
was the intent of the original commit.  This is necessary to 
complete Python3 support as it will flag an error if it encounters 
mixed indentation.

Signed-off-by: Tony Jones 
---
 tools/perf/scripts/python/check-perf-trace.py  | 65 +++---
 tools/perf/scripts/python/compaction-times.py  |  8 +--
 .../perf/scripts/python/event_analyzing_sample.py  |  6 +-
 .../perf/scripts/python/failed-syscalls-by-pid.py  | 38 ++---
 tools/perf/scripts/python/futex-contention.py  |  2 +-
 tools/perf/scripts/python/intel-pt-events.py   | 32 +--
 tools/perf/scripts/python/mem-phys-addr.py |  7 ++-
 tools/perf/scripts/python/net_dropmonitor.py   |  2 +-
 tools/perf/scripts/python/netdev-times.py  | 12 ++--
 tools/perf/scripts/python/sched-migration.py   |  6 +-
 tools/perf/scripts/python/sctop.py | 13 +++--
 tools/perf/scripts/python/stackcollapse.py |  2 +-
 tools/perf/scripts/python/syscall-counts-by-pid.py | 47 
 tools/perf/scripts/python/syscall-counts.py| 31 +--
 14 files changed, 136 insertions(+), 135 deletions(-)

diff --git a/tools/perf/scripts/python/check-perf-trace.py 
b/tools/perf/scripts/python/check-perf-trace.py
index 334599c6032c..f4838db3e518 100644
--- a/tools/perf/scripts/python/check-perf-trace.py
+++ b/tools/perf/scripts/python/check-perf-trace.py
@@ -23,60 +23,59 @@ def trace_begin():
pass
 
 def trace_end():
-print_unhandled()
+   print_unhandled()
 
 def irq__softirq_entry(event_name, context, common_cpu,
-   common_secs, common_nsecs, common_pid, common_comm,
-   common_callchain, vec):
-   print_header(event_name, common_cpu, common_secs, common_nsecs,
-   common_pid, common_comm)
+  common_secs, common_nsecs, common_pid, common_comm,
+  common_callchain, vec):
+   print_header(event_name, common_cpu, common_secs, common_nsecs,
+   common_pid, common_comm)
 
-print_uncommon(context)
+   print_uncommon(context)
 
-   print "vec=%s\n" % \
-   (symbol_str("irq__softirq_entry", "vec", vec)),
+   print "vec=%s\n" % (symbol_str("irq__softirq_entry", "vec", vec)),
 
 def kmem__kmalloc(event_name, context, common_cpu,
-   common_secs, common_nsecs, common_pid, common_comm,
-   common_callchain, call_site, ptr, bytes_req, bytes_alloc,
-   gfp_flags):
-   print_header(event_name, common_cpu, common_secs, common_nsecs,
-   common_pid, common_comm)
+ common_secs, common_nsecs, common_pid, common_comm,
+ common_callchain, call_site, ptr, bytes_req, bytes_alloc,
+ gfp_flags):
+   print_header(event_name, common_cpu, common_secs, common_nsecs,
+   common_pid, common_comm)
 
-print_uncommon(context)
+   print_uncommon(context)
 
-   print "call_site=%u, ptr=%u, bytes_req=%u, " \
+   print "call_site=%u, ptr=%u, bytes_req=%u, " \
"bytes_alloc=%u, gfp_flags=%s\n" % \
(call_site, ptr, bytes_req, bytes_alloc,
-
flag_str("kmem__kmalloc", "gfp_flags", gfp_flags)),
 
 def trace_unhandled(event_name, context, event_fields_dict):
-try:
-unhandled[event_name] += 1
-except TypeError:
-unhandled[event_name] = 1
+   try:
+   unhandled[event_name] += 1
+   except TypeError:
+   unhandled[event_name] = 1
 
 def print_header(event_name, cpu, secs, nsecs, pid, comm):
print "%-20s %5u %05u.%09u %8u %-20s " % \
-   (event_name, cpu, secs, nsecs, pid, comm),
+   (event_name, cpu, secs, nsecs, pid, comm),
 
 # print trace fields not included in handler args
 def print_uncommon(context):
-print "common_preempt_count=%d, common_flags=%s, common_lock_depth=%d, " \
-% (common_pc(context), trace_flag_str(common_flags(context)), \
-   common_lock_depth(context))
+   print "common_preempt_count=%d, common_flags=%s, " \
+   "common_lock_depth=%d, " % \
+   (common_pc(context), trace_flag_str(common_flags(context)),
+   common_lock_depth(context))
 
 def print_unhandled():
-keys = unhandled.keys()
-if not keys:
-return
+   keys = unhandled.keys()
+   if not keys:
+   return
 
-print "\nunhandled events:\n\n",
+   print "\nunhandled events:\n\n",
 
-print "%-40s  %10s\n" % ("event", "count"),
-print "%-40s  %10s\n" % ("", \
- "---"),
+   print "%-40s  %10s\n" % ("event", "count"),
+   print "%-40s  %10s\n" % ("", \
+ 

Re: [PATCH 2/5] ocxl: Clean up printf formats

2019-03-01 Thread Joe Perches
On Wed, 2019-02-27 at 15:57 +1100, Alastair D'Silva wrote:
> From: Alastair D'Silva 
> 
> Use %# instead of using a literal '0x'

  I think it's better not to change this unless
the compilation unit already uses a mix of styles.

Overall, the kernel uses "0x%" over "%#"
by ~8:1

$ git grep -P '0x%\d*[hl]*x' | wc -l
27654
$ git grep -P '%#\d*[hl]*x' | wc -l
3454

> diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
[]
> @@ -178,9 +178,9 @@ static int read_dvsec_vendor(struct pci_dev *dev)
>   pci_read_config_dword(dev, pos + OCXL_DVSEC_VENDOR_DLX_VERS, );
>  
>   dev_dbg(>dev, "Vendor specific DVSEC:\n");
> - dev_dbg(>dev, "  CFG version = 0x%x\n", cfg);
> - dev_dbg(>dev, "  TLX version = 0x%x\n", tlx);
> - dev_dbg(>dev, "  DLX version = 0x%x\n", dlx);
> + dev_dbg(>dev, "  CFG version = %#x\n", cfg);
> + dev_dbg(>dev, "  TLX version = %#x\n", tlx);
> + dev_dbg(>dev, "  DLX version = %#x\n", dlx);
[...]



Re: [PATCH v2 08/10] hikey960: Support usb functionality of Hikey960

2019-03-01 Thread Chen Yu
Hi Chunfeng Yun,

On 2019/2/22 15:32, Chunfeng Yun wrote:
> On Tue, 2019-02-19 at 11:20 +0800, Chen Yu wrote:
>> Hi,
>>
>> On 2019/2/19 10:50, Chunfeng Yun wrote:
 +  if (ret)
 +  hisi_hikey_usb->typec_vbus_enable_val = 1;
 +
 +  hisi_hikey_usb->typec_vbus = devm_gpiod_get(dev, "typec-vbus",
 +  hisi_hikey_usb->typec_vbus_enable_val ?
 +  GPIOD_OUT_LOW : GPIOD_OUT_HIGH);
 +  if (!hisi_hikey_usb->typec_vbus)
 +  return -ENOENT;
 +  else if (IS_ERR(hisi_hikey_usb->typec_vbus))
 +  return PTR_ERR(hisi_hikey_usb->typec_vbus);
 +
 +  gpiod_direction_output(hisi_hikey_usb->typec_vbus,
 +  !hisi_hikey_usb->typec_vbus_enable_val);
>>> maybe a simple way if use fixed regulator?
>>>
>> The hardware of the Hikey960 board has been fixed, and the type-c
>> port can act as UFP. So it is better to close the vbus when Hikey960
>> connect to host(e.g PC).
> I guess you misunderstand what I mean?
> Please refer to bindings/regulator/fixed-regulator.txt
> If you control vbus by gpio, you can use fixed-regulator, it will be
> easy to make compatible with other cases, think about using a LDO to
> control vbus
Sorry for misunderstanding the fixed-regulator and thanks for your advice!
I have read bindings/regulator/fixed-regulator.txt and I think it is enough
to use gpiod API right now.
 +
 +  hisi_hikey_usb->otg_switch = devm_gpiod_get(dev, "otg-switch", 
 GPIOD_IN);
 +  if (!hisi_hikey_usb->otg_switch)
 +  return -ENOENT;
 +  else if (IS_ERR(hisi_hikey_usb->otg_switch))
 +  return PTR_ERR(hisi_hikey_usb->otg_switch);
 +
 +  gpiod_direction_output(hisi_hikey_usb->otg_switch, USB_SWITCH_TO_HUB);
 +
 +  /* hub-vdd33-en is optional */
 +  hisi_hikey_usb->hub_vbus = devm_gpiod_get(dev, "hub-vdd33-en",
 +  GPIOD_OUT_LOW);
 +  if (IS_ERR(hisi_hikey_usb->hub_vbus))
 +  return PTR_ERR(hisi_hikey_usb->hub_vbus);
 +
 +  gpiod_direction_output(hisi_hikey_usb->hub_vbus, HUB_VBUS_POWER_ON);
>>> ditto
 +
 +  hisi_hikey_usb->role_sw = usb_role_switch_get(dev);
 +  if (!hisi_hikey_usb->role_sw)
 +  return -EPROBE_DEFER;
 +  else if (IS_ERR(hisi_hikey_usb->role_sw))
 +  return PTR_ERR(hisi_hikey_usb->role_sw);
 +
>>
>> Thanks
>> Yu Chen
>>
> 

Thanks
Yu Chen



Re: [PATCH 11/15] habanalabs: print pointer using %p

2019-03-01 Thread Joe Perches
On Thu, 2019-02-28 at 11:55 +0200, Oded Gabbay wrote:
> Don't cast pointer to u64 to print it. Instead, print the pointer using
> %p.

You might want to use %px here if you _really_
want the actual address and not the hashed output
%p normally produces.

> diff --git a/drivers/misc/habanalabs/goya/goya.c 
> b/drivers/misc/habanalabs/goya/goya.c
[]
> @@ -4276,9 +4276,8 @@ static int goya_parse_cb_no_ext_quque(struct hl_device 
> *hdev,
>   return 0;
>  
>   dev_err(hdev->dev,
> - "Internal CB address 0x%llx + 0x%x is not in SRAM nor 
> in DRAM\n",
> - (u64) (uintptr_t) parser->user_cb,
> - parser->user_cb_size);
> + "Internal CB address %p + 0x%x is not in SRAM nor in 
> DRAM\n",
> + parser->user_cb, parser->user_cb_size);




Re: [PATCH] printk: Remove no longer used LOG_PREFIX.

2019-03-01 Thread Joe Perches
On Fri, 2019-03-01 at 13:48 +0100, Petr Mladek wrote:
> I want to double check what was the history of KERN_DEFAULT defined
> as "d". It existed since ages...

There less than 100 uses of KERN_DEFAULT.

Relatively speaking, KERN_DEFAULT hasn't existed all
that long actually.

commit e28d713704117bca0820c732210df6075b09f13b
Author: Linus Torvalds 
Date:   Tue Jun 16 11:02:28 2009 -0700

printk: Add KERN_DEFAULT printk log-level

This adds a KERN_DEFAULT loglevel marker, for when you cannot decide
which loglevel you want, and just want to keep an existing printk
with the default loglevel.

The difference between having KERN_DEFAULT and having no log-level
marker at all is two-fold:

 - having the log-level marker will now force a new-line if the
   previous printout had not added one (perhaps because it forgot,
   but perhaps because it expected a continuation)

 - having a log-level marker is required if you are printing out a
   message that otherwise itself could perhaps otherwise be mistaken
   for a log-level.

Signed-of-by: Linus Torvalds 

Ever since Linus changed the default logging mechanism
for printks and KERN_CONT uses in

commit 4bcc595ccd80decb4245096e3d1258989c50ed41
Author: Linus Torvalds 
Date:   Sat Oct 8 20:32:40 2016 -0700

printk: reinstate KERN_CONT for printing continuation lines

the listed reasons in commit e28d713704117bca0820c732210df6075b09f13b
for the use of KERN_DEFAULT are no longer necessary.

I still think it'd be better to remove KERN_DEFAULT altogether.




[PATCH 2/4] printk: Add ability to set loglevel via "console=" cmdline

2019-03-01 Thread Calvin Owens
This extends the "console=" interface to allow setting the per-console
loglevel by adding "/N" to the string, where N is the desired loglevel
expressed as a base 10 integer. Invalid values are silently ignored.

Signed-off-by: Calvin Owens 
---
 .../admin-guide/kernel-parameters.txt |  6 ++--
 kernel/printk/console_cmdline.h   |  1 +
 kernel/printk/printk.c| 30 +++
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 858b6c0b9a15..afada61dcbce 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -612,10 +612,10 @@
ttyS[,options]
ttyUSB0[,options]
Use the specified serial port.  The options are of
-   the form "pnf", where "" is the baud rate,
+   the form "pnf/l", where "" is the baud rate,
"p" is parity ("n", "o", or "e"), "n" is number of
-   bits, and "f" is flow control ("r" for RTS or
-   omit it).  Default is "9600n8".
+   bits, "f" is flow control ("r" for RTS or omit it),
+   and "l" is the loglevel on [0,7]. Default is "9600n8".
 
See Documentation/admin-guide/serial-console.rst for 
more
information.  See
diff --git a/kernel/printk/console_cmdline.h b/kernel/printk/console_cmdline.h
index 11f19c466af5..fbf9b539366e 100644
--- a/kernel/printk/console_cmdline.h
+++ b/kernel/printk/console_cmdline.h
@@ -6,6 +6,7 @@ struct console_cmdline
 {
charname[16];   /* Name of the driver   */
int index;  /* Minor dev. to use*/
+   int loglevel;   /* Loglevel to use */
char*options;   /* Options for the driver   */
 #ifdef CONFIG_A11Y_BRAILLE_CONSOLE
char*brl_options;   /* Options for braille driver */
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 6ead14f8c2bc..2e0eb89f046c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2057,7 +2057,7 @@ asmlinkage __visible void early_printk(const char *fmt, 
...)
 #endif
 
 static int __add_preferred_console(char *name, int idx, char *options,
-  char *brl_options)
+  int loglevel, char *brl_options)
 {
struct console_cmdline *c;
int i;
@@ -2083,6 +2083,7 @@ static int __add_preferred_console(char *name, int idx, 
char *options,
c->options = options;
braille_set_options(c, brl_options);
 
+   c->loglevel = loglevel;
c->index = idx;
return 0;
 }
@@ -2104,8 +2105,8 @@ __setup("console_msg_format=", console_msg_format_setup);
 static int __init console_setup(char *str)
 {
char buf[sizeof(console_cmdline[0].name) + 4]; /* 4 for "ttyS" */
-   char *s, *options, *brl_options = NULL;
-   int idx;
+   char *s, *options, *llevel, *brl_options = NULL;
+   int idx, loglevel = LOGLEVEL_EMERG;
 
if (_braille_console_setup(, _options))
return 1;
@@ -2123,6 +2124,14 @@ static int __init console_setup(char *str)
options = strchr(str, ',');
if (options)
*(options++) = 0;
+
+   llevel = strchr(str, '/');
+   if (llevel) {
+   *(llevel++) = 0;
+   if (kstrtoint(llevel, 10, ))
+   loglevel = LOGLEVEL_EMERG;
+   }
+
 #ifdef __sparc__
if (!strcmp(str, "ttya"))
strcpy(buf, "ttyS0");
@@ -2135,7 +2144,7 @@ static int __init console_setup(char *str)
idx = simple_strtoul(s, NULL, 10);
*s = 0;
 
-   __add_preferred_console(buf, idx, options, brl_options);
+   __add_preferred_console(buf, idx, options, loglevel, brl_options);
console_set_on_cmdline = 1;
return 1;
 }
@@ -2156,7 +2165,8 @@ __setup("console=", console_setup);
  */
 int add_preferred_console(char *name, int idx, char *options)
 {
-   return __add_preferred_console(name, idx, options, NULL);
+   return __add_preferred_console(name, idx, options, LOGLEVEL_EMERG,
+  NULL);
 }
 
 bool console_suspend_enabled = true;
@@ -2574,6 +2584,7 @@ void register_console(struct console *newcon)
struct console *bcon = NULL;
struct console_cmdline *c;
static bool has_preferred;
+   bool cmdline_exists = false;
 
if (console_drivers)
for_each_console(bcon)
@@ -2640,6 +2651,12 @@ void register_console(struct console *newcon)
if (newcon->index < 0)
newcon->index = c->index;
 
+  

[PATCH 1/4] printk: Introduce per-console loglevel setting

2019-03-01 Thread Calvin Owens
Not all consoles are created equal: depending on the actual hardware,
the latency of a printk() call can vary dramatically. The worst examples
are serial consoles, where it can spin for tens of milliseconds banging
the UART to emit a message, which can cause application-level problems
when the kernel spews onto the console.

At Facebook we use netconsole to monitor our fleet, but we still have
serial consoles attached on each host for live debugging, and the latter
has caused problems. An obvious solution is to disable the kernel
console output to ttyS0, but this makes live debugging frustrating,
since crashes become silent and opaque to the ttyS0 user. Enabling it on
the fly when needed isn't feasible, since boxes you need to debug via
serial are likely to be borked in ways that make this impossible.

That puts us between a rock and a hard place: we'd love to set
kernel.printk to KERN_INFO and get all the logs. But while netconsole is
fast enough to permit that without perturbing userspace, ttyS0 is not,
and we're forced to limit console logging to KERN_WARNING and higher.

This patch introduces a new per-console loglevel setting, and changes
console_unlock() to use max(global_level, per_console_level) when
deciding whether or not to emit a given log message.

This lets us have our cake and eat it too: instead of being forced to
limit all consoles verbosity based on the speed of the slowest one, we
can "promote" the faster console while still using a conservative system
loglevel setting to avoid disturbing applications.

Signed-off-by: Calvin Owens 
---
 include/linux/console.h |  1 +
 kernel/printk/printk.c  | 36 +++-
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/include/linux/console.h b/include/linux/console.h
index ec9bdb3d7bab..3c27a4a29b8c 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -155,6 +155,7 @@ struct console {
int cflag;
void*data;
struct   console *next;
+   int level;
 };
 
 /*
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index d3d170374ceb..6ead14f8c2bc 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1164,9 +1164,14 @@ module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(ignore_loglevel,
 "ignore loglevel setting (prints all kernel messages to the 
console)");
 
-static bool suppress_message_printing(int level)
+static int effective_loglevel(struct console *con)
 {
-   return (level >= console_loglevel && !ignore_loglevel);
+   return max(console_loglevel, con ? con->level : LOGLEVEL_EMERG);
+}
+
+static bool suppress_message_printing(int level, struct console *con)
+{
+   return (level >= effective_loglevel(con) && !ignore_loglevel);
 }
 
 #ifdef CONFIG_BOOT_PRINTK_DELAY
@@ -1198,7 +1203,7 @@ static void boot_delay_msec(int level)
unsigned long timeout;
 
if ((boot_delay == 0 || system_state >= SYSTEM_RUNNING)
-   || suppress_message_printing(level)) {
+   || suppress_message_printing(level, NULL)) {
return;
}
 
@@ -1712,7 +1717,7 @@ static int console_trylock_spinning(void)
  * The console_lock must be held.
  */
 static void call_console_drivers(const char *ext_text, size_t ext_len,
-const char *text, size_t len)
+const char *text, size_t len, int level)
 {
struct console *con;
 
@@ -1731,6 +1736,8 @@ static void call_console_drivers(const char *ext_text, 
size_t ext_len,
if (!cpu_online(smp_processor_id()) &&
!(con->flags & CON_ANYTIME))
continue;
+   if (suppress_message_printing(level, con))
+   continue;
if (con->flags & CON_EXTENDED)
con->write(con, ext_text, ext_len);
else
@@ -2022,7 +2029,7 @@ static ssize_t msg_print_ext_body(char *buf, size_t size,
 static void console_lock_spinning_enable(void) { }
 static int console_lock_spinning_disable_and_check(void) { return 0; }
 static void call_console_drivers(const char *ext_text, size_t ext_len,
-const char *text, size_t len) {}
+const char *text, size_t len, int level) {}
 static size_t msg_print_text(const struct printk_log *msg, bool syslog,
 bool time, char *buf, size_t size) { return 0; }
 static bool suppress_message_printing(int level) { return false; }
@@ -2358,21 +2365,11 @@ void console_unlock(void)
} else {
len = 0;
}
-skip:
+
if (console_seq == log_next_seq)
break;
 
msg = log_from_idx(console_idx);
-   if (suppress_message_printing(msg->level)) {
-   /*
-* Skip record we have buffered 

[PATCH 4/4] printk: Add a device attribute for the per-console loglevel

2019-03-01 Thread Calvin Owens
Signed-off-by: Calvin Owens 
---
 kernel/printk/printk.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 67e1e993ab80..e7e602fa2d0b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2560,8 +2560,48 @@ static int __init keep_bootcon_setup(char *str)
 
 early_param("keep_bootcon", keep_bootcon_setup);
 
+static ssize_t loglevel_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   struct console *con = container_of(dev, struct console, dev);
+   return sprintf(buf, "%d\n", con->level);
+}
+
+static ssize_t loglevel_store(struct device *dev, struct device_attribute 
*attr,
+ const char *buf, size_t count)
+{
+   struct console *con = container_of(dev, struct console, dev);
+   ssize_t ret;
+   int tmp;
+
+   ret = kstrtoint(buf, 10, );
+   if (ret < 0)
+   return ret;
+
+   if (tmp < LOGLEVEL_EMERG)
+   return -ERANGE;
+
+   /*
+* Mimic the behavior of /dev/kmsg with respect to minimum_loglevel.
+*/
+   if (tmp < minimum_console_loglevel)
+   tmp = minimum_console_loglevel;
+
+   con->level = tmp;
+   return ret;
+}
+
+static DEVICE_ATTR_RW(loglevel);
+
+static struct attribute *console_sysfs_attrs[] = {
+   _attr_loglevel.attr,
+   NULL,
+};
+ATTRIBUTE_GROUPS(console_sysfs);
+
 static struct bus_type console_subsys = {
.name = "console",
+   .dev_groups = console_sysfs_groups,
 };
 
 static void console_release(struct device *dev)
-- 
2.17.1



[RFC][PATCH 0/4] Per-console loglevel support, console device bus

2019-03-01 Thread Calvin Owens
Hello all,

This is an extremely overdue refresh of this series:

https://lkml.org/lkml/2017/9/28/770

The big change here is the 3rd patch, which actually wires up the console
drivers to support embedding a device structure, so we can place them on
a "console" bus and expose attributes in sysfs.

I left the very long list of driver maintainers off this first submission,
once there's agreement on the core idea here I'll add them.

Thanks,
Calvin


Calvin Owens (4):
  printk: Introduce per-console loglevel setting
  printk: Add ability to set loglevel via "console=" cmdline
  printk: Add consoles to a virtual "console" bus
  printk: Add a device attribute for the per-console loglevel

 131 files changed, 1859 insertions(+), 1061 deletions(-)

-- 
2.17.1



Re: [PATCH 3/3] arm64: dts: rockchip: Disable DCMDs on RK3399's eMMC controller.【请注意,邮件由linux-mmc-ow...@vger.kernel.org代发】

2019-03-01 Thread Shawn Lin

On 2019/3/2 0:43, Christoph Muellner wrote:

When using direct commands (DCMDs) on an RK3399, we get spurious
CQE completion interrupts for the DCMD transaction slot (#31):


I didn't see it. Do you try any newer code, for instance, linux-next?



[  931.196520] [ cut here ]
[  931.201702] mmc1: cqhci: spurious TCN for tag 31
[  931.206906] WARNING: CPU: 0 PID: 1433 at
/usr/src/kernel/drivers/mmc/host/cqhci.c:725 cqhci_irq+0x2e4/0x490
[  931.206909] Modules linked in:
[  931.206918] CPU: 0 PID: 1433 Comm: irq/29-mmc1 Not tainted
4.19.8-rt6-funkadelic #1
[  931.206920] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
[  931.206924] pstate: 4005 (nZcv daif -PAN -UAO)
[  931.206927] pc : cqhci_irq+0x2e4/0x490
[  931.206931] lr : cqhci_irq+0x2e4/0x490
[  931.206933] sp : 0e54bc80
[  931.206934] x29: 0e54bc80 x28: 
[  931.206939] x27: 0001 x26: 08f217e8
[  931.206944] x25: 8000f02ef030 x24: 091417b0
[  931.206948] x23: 090aa000 x22: 8000f008b000
[  931.206953] x21: 0002 x20: 001f
[  931.206957] x19: 8000f02ef018 x18: 
[  931.206961] x17:  x16: 
[  931.206966] x15: 090aa6c8 x14: 0720072007200720
[  931.206970] x13: 0720072007200720 x12: 0720072007200720
[  931.206975] x11: 0720072007200720 x10: 0720072007200720
[  931.206980] x9 : 0720072007200720 x8 : 0720072007200720
[  931.206984] x7 : 0720073107330720 x6 : 05a0
[  931.206988] x5 : 0860d4b0 x4 : 
[  931.206993] x3 : 0001 x2 : 0001
[  931.206997] x1 : 1bde3a91b0d4d900 x0 : 
[  931.207001] Call trace:
[  931.207005]  cqhci_irq+0x2e4/0x490
[  931.207009]  sdhci_arasan_cqhci_irq+0x5c/0x90
[  931.207013]  sdhci_irq+0x98/0x930
[  931.207019]  irq_forced_thread_fn+0x2c/0xa0
[  931.207023]  irq_thread+0x114/0x1c0
[  931.207027]  kthread+0x128/0x130
[  931.207032]  ret_from_fork+0x10/0x20
[  931.207035] ---[ end trace 0002 ]---

The driver shows this message only for the first spurious interrupt
by using WARN_ONCE(). Changing this to WARN() shows, that this is
happening quite frequently (up to once a second).

Since the eMMC 5.1 specification, where CQE and CQHCI are specified,
does not mention that spurious TCN interrupts for DCMDs can be simply
ignored, we must assume that using this feature is not working reliably.

The current implementation uses DCMD for REQ_OP_FLUSH only, and
I could not see any performance/power impact when disabling
this optional feature for RK3399.

Therefore this patch disables DCMDs for RK3399.


We need to sort out the problem, and see if it could be solved, or
we just simply remove MMC_CAP2_CQE_DCMD it from sdhci-of-arasan



Signed-off-by: Christoph Muellner 
Signed-off-by: Philipp Tomsich 
---
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6cc1c9fa4ea6..1bbf0da4e01d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -333,6 +333,7 @@
phys = <_phy>;
phy-names = "phy_arasan";
power-domains = < RK3399_PD_EMMC>;
+   disable-cqe-dcmd;
status = "disabled";
};
  






Re: [PATCH v2 0/8] Rewrite clk parent handling

2019-03-01 Thread Stephen Boyd
Quoting Stephen Boyd (2019-02-26 14:34:21)
> 
> I plan to at least merge the early patches in this series into clk-next
> so we can clear the way for the later patches. I don't think anything is
> too controversial until we get to the new way of specifying parents
> at the end and of course, the sdm845 patch is incomplete so it's not
> going to be merged.

I've pushed the first 5 to clk-next. 



  1   2   3   4   5   6   7   8   >