linux-next boot error: WARNING in kmem_cache_free
Hello, syzbot found the following crash on: HEAD commit:5a94f5bc Add linux-next specific files for 20200621 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=12a02c7610 kernel config: https://syzkaller.appspot.com/x/.config?x=e1788c418b2ddc66 dashboard link: https://syzkaller.appspot.com/bug?extid=95bccd805a4aa06a4b0d compiler: gcc (GCC) 9.0.0 20181231 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+95bccd805a4aa06a4...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 0 PID: 0 at mm/slab.h:232 kmem_cache_free+0x0/0x200 mm/slab.c:2262 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.8.0-rc1-next-20200621-syzkaller #0 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+0x18f/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:231 __warn.cold+0x2f/0x3a kernel/panic.c:600 report_bug+0x271/0x2f0 lib/bug.c:198 exc_invalid_op+0x1b9/0x370 arch/x86/kernel/traps.c:235 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:563 RIP: 0010:kmem_cache_debug_flags mm/slab.h:232 [inline] RIP: 0010:cache_from_obj mm/slab.h:459 [inline] RIP: 0010:kmem_cache_free+0x0/0x200 mm/slab.c:3678 Code: ff 49 c7 84 24 90 00 00 00 00 00 00 00 83 c3 01 39 1d 2c ec fb 08 77 af 5b 5d 41 5c 41 5d c3 90 66 2e 0f 1f 84 00 00 00 00 00 <0f> 0b 48 85 ff 0f 84 a9 01 00 00 48 83 3d 15 6b 02 08 00 0f 84 9c RSP: :89a07a58 EFLAGS: 00010293 RAX: 89a86580 RBX: 8880aa01f0e8 RCX: 81a84573 RDX: RSI: 8880aa01f480 RDI: 8880aa00fe00 RBP: 8880aa01f4a8 R08: 89a86580 R09: fbfff1340f3f R10: 0003 R11: fbfff1340f3e R12: 8880aa01f4b0 R13: 8880aa01f688 R14: 8880aa01f480 R15: c900 adjust_va_to_fit_type mm/vmalloc.c:980 [inline] __alloc_vmap_area mm/vmalloc.c:1096 [inline] alloc_vmap_area+0x1494/0x1df0 mm/vmalloc.c:1196 __get_vm_area_node+0x178/0x3b0 mm/vmalloc.c:2060 __vmalloc_node_range+0x12c/0x910 mm/vmalloc.c:2484 __vmalloc_node mm/vmalloc.c:2532 [inline] __vmalloc_area_node mm/vmalloc.c:2404 [inline] __vmalloc_node_range+0x76c/0x910 mm/vmalloc.c:2489 __vmalloc_node mm/vmalloc.c:2532 [inline] __vmalloc+0x69/0x80 mm/vmalloc.c:2546 alloc_large_system_hash+0x1c9/0x2e2 mm/page_alloc.c:8181 inode_init+0xab/0xbc fs/inode.c:2099 vfs_caches_init+0x104/0x11e fs/dcache.c:3231 start_kernel+0x978/0x9fb init/main.c:1025 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 --- 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#status for how to communicate with syzbot.
Re: [PATCH 3/3] ALSA: compress: fix partial_drain completion state
On 19-06-20, 10:13, Srinivas Kandagatla wrote:
>
>
> On 19/06/2020 05:54, Vinod Koul wrote:
> > On partial_drain completion we should be in SNDRV_PCM_STATE_RUNNING
> > state, so set that for partially draining streams in
> > snd_compr_drain_notify() and use a flag for partially draining streams
> >
> > While at it, add locks for stream state change in
> > snd_compr_drain_notify() as well.
> >
> > Fixes: f44f2a5417b2 ("ALSA: compress: fix drain calls blocking other
> > compress functions (v6)")
> > Reported-by: Srinivas Kandagatla
> > Signed-off-by: Vinod Koul
> > ---
>
> Reviewed-by: Srinivas Kandagatla
> Tested-by: Srinivas Kandagatla
Thanks for testing Srini
--
~Vinod
Re: [PATCH] proc: Avoid a thundering herd of threads freeing proc dentries
On Fri, Jun 19, 2020 at 11:14 PM Eric W. Biederman
wrote:
>
>
> Junxiao Bi reported:
> > When debugging some performance issue, i found that thousands of threads
> > exit
> > around same time could cause a severe spin lock contention on proc dentry
> > "/proc/$parent_process_pid/task/", that's because threads needs to clean up
> > their pid file from that dir when exit.
>
> Matthew Wilcox reported:
> > We've looked at a few different ways of fixing this problem.
>
> The flushing of the proc dentries from the dcache is an optmization,
> and is not necessary for correctness. Eventually cache pressure will
> cause the dentries to be freed even if no flushing happens. Some
> light testing when I refactored the proc flushg[1] indicated that at
> least the memory footprint is easily measurable.
>
> An optimization that causes a performance problem due to a thundering
> herd of threads is no real optimization.
>
> Modify the code to only flush the /proc// directory when all
> threads in a process are killed at once. This continues to flush
> practically everything when the process is reaped as the threads live
> under /proc//task/.
>
> There is a rare possibility that a debugger will access /proc//,
> which this change will no longer flush, but I believe such accesses
> are sufficiently rare to not be observed in practice.
>
> [1] 7bc3e6e55acf ("proc: Use a list of inodes to flush from proc")
> Link:
> https://lkml.kernel.org/r/54091fc0-ca46-2186-97a8-d1f3c4f38...@oracle.com
> Reported-by: Masahiro Yamada
I did not report this.
> Reported-by: Matthew Wilcox
> Signed-off-by: "Eric W. Biederman"
> ---
--
Best Regards
Masahiro Yamada
Re: [PATCH 2/3] ALSA: compress: document the compress gapless audio state machine
On 19-06-20, 09:27, Pierre-Louis Bossart wrote: > > > +For Gapless, we move from running state to partial drain and back, along > > +with setting of meta_data and signalling for next track :: > > + > > + > > ++--+ > > +compr_drain_notify()| | > > + +>| RUNNING | > > + | | | > > + | +--+ > > + | | > > + | | > > + | | compr_next_track() > > + | | > > + | V > > + | +--+ > > + | | | > > + | |NEXT_TRACK| > > + | | | > > + | +--+ > > + | | > > + | | > > + | | compr_partial_drain() > > + | | > > + | V > > + | +--+ > > + | | | > > + + | PARTIAL_ | > > +| DRAIN | > > ++--+ > > May I suggest having a single state machine, not a big one and an additional > partial one. It would help explain why in one case compr_drain_notify() > triggers a transition to RUNNING while in the other one it goes to SETUP. > > I realize it's more complicated to edit but it'd be easier on > reviewers/users. Ell adding stop and transitions would really make it complicated and gapless is a bit different handling and it looks cleaner this way IMO, so lets stick to this. Feel free to create one if you are up for it. -- ~Vinod
Re: [PATCH 1/3] ALSA: compress: document the compress audio state machine
HI Pierre, On 19-06-20, 09:22, Pierre-Louis Bossart wrote: > > > + > > ++--+ > > +| | > > +| OPEN | > > +| | > > ++--+ > > + | > > + | > > + | compr_set_params() > > + | > > + V > > ++--+ > > +compr_drain_notify()| | > > + +>| SETUP | > > + | | | > > + | +--+ > > + | | > > + | | > > + | | compr_write() > > + | | > > + | V > > + | +--+ > > + | | | > > + | | PREPARE | > > + | | | > > + | +--+ > > + | | > > + | | > > + | | compr_start() > > + | | > > + | V > > ++--++--+ compr_pause() > > +--+ > > +| || > > |--->| | > > +| DRAIN |<---| RUNNING | > > | PAUSE | > > +| || > > |<---| | > > ++--++--+ compr_resume() > > +--+ > > + | | > > + | | > > + | | compr_free() > > + | | > > + | V > > + | +--+ > > + | compr_free()| | > > + +>| | > > +| STOP | > > +| | > > ++--+ > > > The STOP state doesn't seem quite right to me, sorry. We should call it free, Will update > the direction of the DRAIN-STOP comp_free() arrow seems wrong? Of if it is > correct, then something's missing to exit the STOP state so that the stream > can be opened again. Once stream is freed, it can't be opened again. But we have trigger stop which is not comprehended here, I will add compr_stop() above which would transition to SETUP state. And a stopped stream can be freed up as well, so one more transition from SETUP to FREE. Thanks for reviewing -- ~Vinod
[PATCH] drm/mediatek: check plane visibility in atomic_update
Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
would proceed with invalid plane and we may see vblank timeout.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index c2bd683a87c8..74dc71c7f3b6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -164,6 +164,16 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
true, true);
}
+static void mtk_plane_atomic_disable(struct drm_plane *plane,
+struct drm_plane_state *old_state)
+{
+ struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
+
+ state->pending.enable = false;
+ wmb(); /* Make sure the above parameter is set before update */
+ state->pending.dirty = true;
+}
+
static void mtk_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
@@ -178,6 +188,9 @@ static void mtk_plane_atomic_update(struct drm_plane *plane,
if (!crtc || WARN_ON(!fb))
return;
+ if (!plane->state->visible)
+ return mtk_plane_atomic_disable(plane, old_state);
+
gem = fb->obj[0];
mtk_gem = to_mtk_gem_obj(gem);
addr = mtk_gem->dma_addr;
@@ -200,16 +213,6 @@ static void mtk_plane_atomic_update(struct drm_plane
*plane,
state->pending.dirty = true;
}
-static void mtk_plane_atomic_disable(struct drm_plane *plane,
-struct drm_plane_state *old_state)
-{
- struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
-
- state->pending.enable = false;
- wmb(); /* Make sure the above parameter is set before update */
- state->pending.dirty = true;
-}
-
static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
.prepare_fb = drm_gem_fb_prepare_fb,
.atomic_check = mtk_plane_atomic_check,
--
2.27.0.111.gc72c7da667-goog
WARNING in tcf_chain0_head_change_cb_del
Hello, syzbot found the following crash on: HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1630b4d110 kernel config: https://syzkaller.appspot.com/x/.config?x=d195fe572fb15312 dashboard link: https://syzkaller.appspot.com/bug?extid=438750324c752008e890 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+438750324c752008e...@syzkaller.appspotmail.com Free swap = 0kB Total swap = 0kB 1965979 pages RAM 0 pages HighMem/MovableOnly 349378 pages reserved 0 pages cma reserved [ cut here ] DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 1 PID: 3326 at kernel/locking/mutex.c:938 __mutex_lock_common kernel/locking/mutex.c:938 [inline] WARNING: CPU: 1 PID: 3326 at kernel/locking/mutex.c:938 __mutex_lock+0xd75/0x13c0 kernel/locking/mutex.c:1103 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 3326 Comm: syz-executor.2 Not tainted 5.7.0-syzkaller #0 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+0x188/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x27b/0x2f0 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:105 [inline] fixup_bug arch/x86/kernel/traps.c:100 [inline] do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:197 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:216 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:938 [inline] RIP: 0010:__mutex_lock+0xd75/0x13c0 kernel/locking/mutex.c:1103 Code: d2 0f 85 98 05 00 00 44 8b 05 07 44 ae 02 45 85 c0 0f 85 c1 f3 ff ff 48 c7 c6 c0 8b 2b 88 48 c7 c7 80 89 2b 88 e8 e3 78 67 f9 <0f> 0b e9 a7 f3 ff ff 65 48 8b 1c 25 00 1f 02 00 be 08 00 00 00 48 RSP: 0018:c9001675f200 EFLAGS: 00010282 RAX: RBX: RCX: RDX: 0004 RSI: 815d5ba7 RDI: f52002cebe32 RBP: c9001675f370 R08: 88808823a5c0 R09: R10: 899b2823 R11: fbfff1336504 R12: R13: dc00 R14: 88809d5e9000 R15: 88809d5e9000 tcf_chain0_head_change_cb_del.isra.0+0x31/0x3c0 net/sched/cls_api.c:803 tcf_block_put_ext.part.0+0x25/0x80 net/sched/cls_api.c:1375 tcf_block_put_ext net/sched/cls_api.c:1373 [inline] tcf_block_put+0xb3/0x100 net/sched/cls_api.c:1388 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2667 qdisc_create+0xd93/0x1430 net/sched/sch_api.c:1295 tc_modify_qdisc+0x4c5/0x1a00 net/sched/sch_api.c:1662 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5461 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e6/0x810 net/socket.c:2352 ___sys_sendmsg+0x100/0x170 net/socket.c:2406 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45ca59 Code: 0d b7 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 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f6a1c91fc78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 00501a60 RCX: 0045ca59 RDX: RSI: 27c0 RDI: 0004 RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: 0005 R13: 0a22 R14: 004cd04d R15: 7f6a1c9206d4 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#status for how to communicate with syzbot.
KASAN: null-ptr-deref Write in kvm_vcpu_halt
Hello, syzbot found the following crash on: HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17d9bfa910 kernel config: https://syzkaller.appspot.com/x/.config?x=be4578b3f1083656 dashboard link: https://syzkaller.appspot.com/bug?extid=76004d8cdf5443dcd8e7 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) 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+76004d8cdf5443dcd...@syzkaller.appspotmail.com == BUG: KASAN: null-ptr-deref in kvm_vcpu_halt+0xea/0x110 arch/x86/kvm/x86.c:7546 Write of size 4 at addr by task syz-executor.0/1 CPU: 1 PID: 1 Comm: syz-executor.0 Not tainted 5.7.0-syzkaller #0 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+0x1e9/0x30e lib/dump_stack.c:118 __kasan_report mm/kasan/report.c:517 [inline] kasan_report+0x151/0x1d0 mm/kasan/report.c:530 kvm_vcpu_halt+0xea/0x110 arch/x86/kvm/x86.c:7546 == Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 1 Comm: syz-executor.0 Tainted: GB 5.7.0-syzkaller #0 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+0x1e9/0x30e lib/dump_stack.c:118 panic+0x264/0x7a0 kernel/panic.c:221 end_report mm/kasan/report.c:104 [inline] __kasan_report mm/kasan/report.c:520 [inline] kasan_report+0x1c9/0x1d0 mm/kasan/report.c:530 kvm_vcpu_halt+0xea/0x110 arch/x86/kvm/x86.c:7546 Shutting down cpus with NMI 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#status for how to communicate with syzbot.
[snd_pcm] [5.8RC1] kernel BUG at mm/huge_memory.c:2613! (system stopped playing sound)
Hi folks. After upgrade kernel to 5.8RC1 (git69119673bd50) my system stopped playing sound. In the kernel log, I see the message 'invalid opcode: [#1] SMP NOPTI' which probably related to this issue. [ 19.076508] page:eb1b1dc14b00 refcount:1 mapcount:0 mapping: index:0x0 head:eb1b1dc14b00 order:2 compound_mapcount:0 compound_pincount:0 [ 19.076515] flags: 0x17c001(head) [ 19.076520] raw: 0017c001 dead0100 dead0122 [ 19.076524] raw: 0001 [ 19.076527] page dumped because: VM_BUG_ON_PAGE(!PageLocked(head)) [ 19.076561] [ cut here ] [ 19.076562] kernel BUG at mm/huge_memory.c:2613! [ 19.076581] invalid opcode: [#1] SMP NOPTI [ 19.076584] CPU: 12 PID: 1787 Comm: pulseaudio Not tainted 5.8.0-0.rc1.20200617git69119673bd50.1.fc33.x86_64 #1 [ 19.076586] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 1407 04/02/2020 [ 19.076592] RIP: 0010:split_huge_page_to_list+0x86a/0xd90 [ 19.076596] Code: 48 c7 c6 c0 d5 38 9c 48 8d 50 ff a8 01 48 0f 45 da 48 89 df e8 b7 d0 f8 ff 0f 0b 48 c7 c6 88 f1 3b 9c 48 89 df e8 a6 d0 f8 ff <0f> 0b 48 8b 07 f6 c4 04 0f 84 b4 f9 ff ff 48 89 df e8 f0 59 fc ff [ 19.076599] RSP: 0018:b580c249fad8 EFLAGS: 00010296 [ 19.076601] RAX: RBX: eb1b1dc14b00 RCX: 93f1fbbdb5f8 [ 19.076603] RDX: ffd8 RSI: RDI: 93f1fbbdb5f0 [ 19.076605] RBP: 93f21e2ff688 R08: R09: [ 19.076606] R10: 0001 R11: R12: 93f21e2d5000 [ 19.076608] R13: eb1b1dc14b00 R14: 0007 R15: eb1b1dc14b00 [ 19.076610] FS: 7f6f4e421880() GS:93f1fba0() knlGS: [ 19.076612] CS: 0010 DS: ES: CR0: 80050033 [ 19.076613] CR2: 7f6f3ceab000 CR3: 000779996000 CR4: 003406e0 [ 19.076615] Call Trace: [ 19.076622] ? rcu_read_lock_sched_held+0x3f/0x80 [ 19.076626] ? __alloc_pages_nodemask+0x3df/0x450 [ 19.076631] iommu_dma_alloc+0x316/0x580 [ 19.076637] dma_alloc_attrs+0x86/0x90 [ 19.076645] snd_dma_alloc_pages+0xdf/0x160 [snd_pcm] [ 19.076651] snd_dma_alloc_pages_fallback+0x5d/0x80 [snd_pcm] [ 19.076657] snd_malloc_sgbuf_pages+0x166/0x380 [snd_pcm] [ 19.076665] ? trace_kmalloc+0xf2/0x120 [ 19.076670] snd_dma_alloc_pages+0x64/0x160 [snd_pcm] [ 19.076676] do_alloc_pages+0x3c/0x90 [snd_pcm] [ 19.076683] snd_pcm_lib_malloc_pages+0x115/0x1a0 [snd_pcm] [ 19.076690] snd_pcm_hw_params+0x4de/0x5b0 [snd_pcm] [ 19.076694] ? _copy_from_user+0x6b/0xb0 [ 19.076700] snd_pcm_common_ioctl+0x209/0x1340 [snd_pcm] [ 19.076703] ? selinux_file_ioctl+0x132/0x1e0 [ 19.076711] snd_pcm_ioctl+0x23/0x30 [snd_pcm] [ 19.076715] ksys_ioctl+0x82/0xc0 [ 19.076718] __x64_sys_ioctl+0x16/0x20 [ 19.076722] do_syscall_64+0x52/0xb0 [ 19.076724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 19.076727] RIP: 0033:0x7f6f4ed53e9b [ 19.076728] Code: Bad RIP value. [ 19.076730] RSP: 002b:7ffe556b7e18 EFLAGS: 0246 ORIG_RAX: 0010 [ 19.076732] RAX: ffda RBX: 7ffe556b8020 RCX: 7f6f4ed53e9b [ 19.076733] RDX: 7ffe556b8020 RSI: c2604111 RDI: 0016 [ 19.076735] RBP: 5562734fdfa0 R08: R09: [ 19.076737] R10: 0004 R11: 0246 R12: 5562734fdf20 [ 19.076738] R13: 7ffe556b7e54 R14: R15: 7ffe556b8020 [ 19.076743] Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp nf_conntrack_tftp tun bridge stp llc nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_raw iptable_security ip_set nf_tables nfnetlink ip6table_filter ip6_tables iptable_filter cmac bnep sunrpc vfat fat hid_logitech_hidpp joydev hid_logitech_dj mt76x2u mt76x2_common mt76x02_usb mt76_usb mt76x02_lib mt76 edac_mce_amd amd_energy kvm_amd kvm gspca_zc3xx gspca_main irqbypass eeepc_wmi asus_wmi btusb sparse_keymap btrtl video wmi_bmof btbcm btintel bluetooth ecdh_generic uvcvideo ecc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_usb_audio videobuf2_common snd_usbmidi_lib videodev snd_rawmidi pcspkr iwlmvm mc [ 19.076777] mac80211 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio libarc4 snd_hda_codec_hdmi iwlwifi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep cfg80211 snd_seq snd_seq_device rfkill snd_pcm snd_timer snd soundcore k10temp sp5100_tco i2c_piix4 acpi_cpufreq binfmt_misc ip_tables amdgpu iommu_v2 gpu_sched ttm
[PATCH -next] lib/test_bits: add MODULE_LICENSE()
From: Randy Dunlap
Add MODULE_LICENSE() to prevent build warning:
WARNING: modpost: missing MODULE_LICENSE() in lib/test_bits.o
Signed-off-by: Randy Dunlap
Cc: Rikard Falkeborn
Cc: Andrew Morton
---
lib/test_bits.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20200621.orig/lib/test_bits.c
+++ linux-next-20200621/lib/test_bits.c
@@ -71,3 +71,5 @@ static struct kunit_suite bits_test_suit
.test_cases = bits_test_cases,
};
kunit_test_suite(bits_test_suite);
+
+MODULE_LICENSE("GPL");
Re: [PATCH][next] dmaengine: hisilicon: Use struct_size() in devm_kzalloc()
On 2020/6/18 5:11, Gustavo A. R. Silva wrote: > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mistakes. > > This code was detected with the help of Coccinelle and, audited and > fixed manually. > > Signed-off-by: Gustavo A. R. Silva Looks good to me, thanks! Reviewed-by: Zhou Wang > --- > drivers/dma/hisi_dma.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/dma/hisi_dma.c b/drivers/dma/hisi_dma.c > index ed3619266a48..e1a958ae7925 100644 > --- a/drivers/dma/hisi_dma.c > +++ b/drivers/dma/hisi_dma.c > @@ -511,7 +511,6 @@ static int hisi_dma_probe(struct pci_dev *pdev, const > struct pci_device_id *id) > struct device *dev = >dev; > struct hisi_dma_dev *hdma_dev; > struct dma_device *dma_dev; > - size_t dev_size; > int ret; > > ret = pcim_enable_device(pdev); > @@ -534,9 +533,7 @@ static int hisi_dma_probe(struct pci_dev *pdev, const > struct pci_device_id *id) > if (ret) > return ret; > > - dev_size = sizeof(struct hisi_dma_chan) * HISI_DMA_CHAN_NUM + > -sizeof(*hdma_dev); > - hdma_dev = devm_kzalloc(dev, dev_size, GFP_KERNEL); > + hdma_dev = devm_kzalloc(dev, struct_size(hdma_dev, chan, > HISI_DMA_CHAN_NUM), GFP_KERNEL); > if (!hdma_dev) > return -EINVAL; > >
Re: [PATCH] dt-bindings: iio: bmc150_magn: Document missing compatibles
On Sat, Jun 20, 2020 at 04:40:49PM +0100, Jonathan Cameron wrote:
> On Wed, 17 Jun 2020 12:12:59 +0200
> Krzysztof Kozlowski wrote:
>
> > The driver supports also BMC156B and BMM150B so document the compatibles
> > for these devices.
> >
> > Fixes: 9d75db36df14 ("iio: magn: Add support for BMM150 magnetometer")
> > Cc:
> > Signed-off-by: Krzysztof Kozlowski
> >
> > ---
> >
> > The fixes tag is not accurate but at least offer some backporting.
>
> I'm not sure we generally bother backporting a missing section of binding
> documentation. Particularly as this doc isn't in yaml yet so it's not
> as though any automated checking is likely to be occurring.
>
> Rob, any views on backporting this sort of missing id addition?
>
> One side comment here is that the devices that are magnetometers only
> should never have had the _magn prefix in their compatibles. We only
> do that for devices in incorporating several sensors in one package
> (like the bmc150) where we have multiple drivers for the different
> sensors incorporated. We are too late to fix that now though. It
> may make sense to mark the _magn variants deprecated though and
> add the ones without the _magn postfix.
I can add proper compatibles and mark these as deprecated but actually
the driver should not have additional compatibles in first place - all
devices are just compatible with bosch,bmc150.
Therefore I can just add one new compatible: "bosch,bmc156" and mark the
last two deprecated.
Best regards,
Krzysztof
>
> > ---
> > .../devicetree/bindings/iio/magnetometer/bmc150_magn.txt | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> > b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> > index fd5fca90fb39..7469073022db 100644
> > --- a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> > +++ b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> > @@ -4,7 +4,10 @@
> > http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS00
> >
> > Required properties:
> >
> > - - compatible : should be "bosch,bmc150_magn"
> > + - compatible : should be one of:
> > + "bosch,bmc150_magn"
> > + "bosch,bmc156_magn"
> > + "bosch,bmm150_magn"
> >- reg : the I2C address of the magnetometer
> >
> > Optional properties:
>
linux-next: Tree for Jun 22
Hi all,
Changes since 20200621:
New tree: seccomp
My fixes tree contains:
466d58f824f1 ("device_cgroup: Fix RCU list debugging warning")
9bd7b7c45d71 ("sched: Fix RANDSTRUCT build fail")
The printk tree still had its build failure so I used the version from
next-20200618.
The hid tree still had its build failure so I used the version from
next-20200618.
The amdgpu tree still had its build failure so I used the version from
next-20200616.
The tip tree still had its build failure for which I applied a supplied
patch, but also gained another for which I reverted a commit.
The kspp tree lost its build failure.
Non-merge commits (relative to Linus' tree): 2314
2634 files changed, 277652 insertions(+), 35554 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 321 trees (counting Linus' and 82 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (16f4aa9b7c23 Merge tag 'pinctrl-v5.8-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl)
Merging fixes/master (9bd7b7c45d71 sched: Fix RANDSTRUCT build fail)
Merging kbuild-current/fixes (214377e9b7e3 samples: watch_queue: build sample
program for target architecture)
Merging arc-current/for-curr (10011f7d95de ARCv2: support loop buffer (LPB)
disabling)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag
'omap-for-v5.7/cpsw-fixes-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (24ebec25fb27 arm64: hw_breakpoint: Don't
invoke overflow handler on uaccess watchpoints)
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length
array with flexible-array member)
Merging powerpc-fixes/fixes (c0e1c8c22beb powerpc/8xx: Provide ptep_get() with
16k pages)
Merging s390-fixes/fixes (b3583fca5fb6 s390: fix syscall_get_error for compat
processes)
Merging sparc/master (b3a9e3b9622a Linux 5.8-rc1)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (67c20de35a3c net: Add MODULE_DESCRIPTION entries to network
modules)
Merging bpf/master (ef7232da6bcd ionic: export features for vlans to use)
Merging ipsec/master (be01369859b8 esp, ah: modernize the crypto algorithm
selections)
Merging netfilter/master (c92cbaea3cc0 net: dsa: sja1105: fix PTP timestamping
with large tc-taprio cycles)
Merging ipvs/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging wireless-drivers/master (b3a9e3b9622a Linux 5.8-rc1)
Merging mac80211/master (59d4bfc1e2c0 net: fix wiki website url mac80211 and
wireless files)
Merging rdma-fixes/for-rc (9e0dc7b9e1cb RDMA/mlx5: Fix integrity enabled QP
creation)
Merging sound-current/for-linus (d50313a5a0d8 ALSA: hda: Intel: add missing PCI
IDs for ICL-H, TGL-H and EKL)
Merging sound-asoc-fixes/for-linus (f66aada04ccf Merge remote-tracking branch
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (82228364de4a Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (1b3bcc
Re: [PATCH] proc: Avoid a thundering herd of threads freeing proc dentries
On 6/20/20 9:27 AM, Matthew Wilcox wrote: On Fri, Jun 19, 2020 at 05:42:45PM -0500, Eric W. Biederman wrote: Junxiao Bi writes: Still high lock contention. Collect the following hot path. A different location this time. I know of at least exit_signal and exit_notify that take thread wide locks, and it looks like exit_mm is another. Those don't use the same locks as flushing proc. So I think you are simply seeing a result of the thundering herd of threads shutting down at once. Given that thread shutdown is fundamentally a slow path there is only so much that can be done. If you are up for a project to working through this thundering herd I expect I can help some. It will be a long process of cleaning up the entire thread exit process with an eye to performance. Wengang had some tests which produced wall-clock values for this problem, which I agree is more informative. I'm not entirely sure what the customer workload is that requires a highly threaded workload to also shut down quickly. To my mind, an overall workload is normally composed of highly-threaded tasks that run for a long time and only shut down rarely (thus performance of shutdown is not important) and single-threaded tasks that run for a short time. The real workload is a Java application working in server-agent mode, issue happened in agent side, all it do is waiting works dispatching from server and execute. To execute one work, agent will start lots of short live threads, there could be a lot of threads exit same time if there were a lots of work to execute, the contention on the exit path caused a high %sys time which impacted other workload. Thanks, Junxiao. Understanding this workload is important to my next suggestion, which is that rather than searching for all the places in the exit path which contend on a single spinlock, we simply set the allowed CPUs for an exiting task to include only the CPU that this thread is running on. It will probably run faster to take the threads down in series on one CPU rather than take them down in parallel across many CPUs (or am I mistaken? Is there inherently a lot of parallelism in the thread exiting process?)
Re: kbuild: separate kerneldoc warnings from compiler warnings
On Sun, Jun 21, 2020 at 3:52 AM Valdis Klētnieks
wrote:
>
> This patch introduces a new build flag 'K=1' which controls whether kerneldoc
> warnings should be issued, separating them from the compiler warnings that W=
> controls.
I do not understand why this change is needed.
IIRC, our goal was to enable this check by default.
https://patchwork.kernel.org/patch/10030521/
but there are so many warnings.
Meanwhile, this is checked only when W= is given
because 0-day bot tests with W=1 to
block new kerneldoc warnings.
K=1 ? Do people need to learn this new switch?
> Signed-off-by: Valdis Kletnieks
>
> diff --git a/Makefile b/Makefile
> index 29abe44ada91..b1c0f9484a66 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1605,6 +1605,7 @@ PHONY += help
> @echo ' (sparse by default)'
> @echo ' make C=2 [targets] Force check of all c source with
> $$CHECK'
> @echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored
> mcount sections'
> + @echo ' make K=1 [targets] Warn about problems in kerneldoc
> comments'
> @echo ' make W=n [targets] Enable extra build checks, n=1,2,3
> where'
> @echo '1: warnings which may be relevant and do not
> occur too often'
> @echo '2: warnings which occur quite often but may
> still be relevant'
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 2e8810b7e5ed..9bcb77f5a5f1 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -100,7 +100,7 @@ else ifeq ($(KBUILD_CHECKSRC),2)
> cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $<
> endif
>
> -ifneq ($(KBUILD_EXTRA_WARN),)
> +ifneq ($(KBUILD_KDOC_WARN),)
>cmd_checkdoc = $(srctree)/scripts/kernel-doc -none $<
> endif
>
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index 4aea7cf71d11..3fd5881c91b0 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -17,6 +17,12 @@ endif
>
> export KBUILD_EXTRA_WARN
>
> +ifeq ("$(origin K)", "command line")
> + KBUILD_KDOC_WARN := $(K)
> +endif
> +
> +export KBUILD_KDOC_WARN
> +
> #
> # W=1 - warnings which may be relevant and do not occur too often
> #
>
>
--
Best Regards
Masahiro Yamada
ld.lld: warning: kernel/built-in.a(trace/trace_events_hist.o):(".discard.ksym") is being placed in '".discard.ksym"'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 625d3449788f85569096780592549d0340e9c0c7
commit: 5990cdee689c6885b27c6d969a3d58b09002b0bc lib/mpi: Fix building for
powerpc with clang
date: 8 weeks ago
config: powerpc64-randconfig-r003-20200621 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
ef455a55bcf2cfea04a99c361b182ad18b7f03f1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
git checkout 5990cdee689c6885b27c6d969a3d58b09002b0bc
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
ld.lld: warning:
arch/powerpc/built-in.a(platforms/44x/virtex.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(fork.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(panic.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(cpu.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(exit.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(softirq.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(resource.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sysctl.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(capability.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(ptrace.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(user.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(signal.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sys.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(umh.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(workqueue.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(pid.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(params.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(kthread.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(notifier.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(ksysfs.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(cred.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(reboot.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(async.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(smpboot.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(kmod.o):(".discard.ksym") is being placed in
'".discard.ksym"'
ld.lld: warning: kernel/built-in.a(groups.o):(".discard.ksym") is being placed
in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sched/core.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sched/loadavg.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sched/clock.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sched/cputime.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sched/idle.o):(".discard.ksym") is being
placed in '".discard.ksym"'
ld.lld: warning: kernel/built-in.a(sched/fair.o):(".discard.ksym") is being
placed in '&quo
[PATCH V2] arm64/panic: Unify all three existing notifier blocks
Currently there are three different registered panic notifier blocks. This
unifies all of them into a single one i.e arm64_panic_block, hence reducing
code duplication and required calling sequence during panic. This preserves
the existing dump sequence. While here, just use device_initcall() instead
of __initcall().
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Steve Capper
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
Applies on 5.8-rc2.
Changes in V2:
- Replaced __initcall() directly with device_initcall()
- Added static for dump_kernel_offset()
Changes in V1: (https://patchwork.kernel.org/patch/11606291/)
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/memory.h | 1 +
arch/arm64/kernel/cpufeature.c | 15 +--
arch/arm64/kernel/setup.c | 24 ++--
arch/arm64/mm/init.c| 18 +-
5 files changed, 18 insertions(+), 41 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 5d1f4ae42799..e375529ca9fc 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -774,6 +774,7 @@ static inline unsigned int get_vmid_bits(u64 mmfr1)
}
u32 get_kvm_ipa_limit(void);
+void dump_cpu_features(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index a1871bb32bb1..2a88cb734d06 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -322,6 +322,7 @@ static inline void *phys_to_virt(phys_addr_t x)
__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr)); \
})
+void dump_mem_limit(void);
#endif /* !ASSEMBLY */
/*
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 4ae41670c2e6..5ec61175c634 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -119,24 +119,11 @@ static inline void finalize_system_capabilities(void)
static_branch_enable(_const_caps_ready);
}
-static int dump_cpu_hwcaps(struct notifier_block *self, unsigned long v, void
*p)
+void dump_cpu_features(void)
{
/* file-wide pr_fmt adds "CPU features: " prefix */
pr_emerg("0x%*pb\n", ARM64_NCAPS, _hwcaps);
- return 0;
-}
-
-static struct notifier_block cpu_hwcaps_notifier = {
- .notifier_call = dump_cpu_hwcaps
-};
-
-static int __init register_cpu_hwcaps_dumper(void)
-{
- atomic_notifier_chain_register(_notifier_list,
- _hwcaps_notifier);
- return 0;
}
-__initcall(register_cpu_hwcaps_dumper);
DEFINE_STATIC_KEY_ARRAY_FALSE(cpu_hwcap_keys, ARM64_NCAPS);
EXPORT_SYMBOL(cpu_hwcap_keys);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 93b3844cf442..c793276ec7ad 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -400,11 +400,7 @@ static int __init topology_init(void)
}
subsys_initcall(topology_init);
-/*
- * Dump out kernel offset information on panic.
- */
-static int dump_kernel_offset(struct notifier_block *self, unsigned long v,
- void *p)
+static void dump_kernel_offset(void)
{
const unsigned long offset = kaslr_offset();
@@ -415,17 +411,25 @@ static int dump_kernel_offset(struct notifier_block
*self, unsigned long v,
} else {
pr_emerg("Kernel Offset: disabled\n");
}
+}
+
+static int arm64_panic_block_dump(struct notifier_block *self,
+ unsigned long v, void *p)
+{
+ dump_kernel_offset();
+ dump_cpu_features();
+ dump_mem_limit();
return 0;
}
-static struct notifier_block kernel_offset_notifier = {
- .notifier_call = dump_kernel_offset
+static struct notifier_block arm64_panic_block = {
+ .notifier_call = arm64_panic_block_dump
};
-static int __init register_kernel_offset_dumper(void)
+static int __init register_arm64_panic_block(void)
{
atomic_notifier_chain_register(_notifier_list,
- _offset_notifier);
+ _panic_block);
return 0;
}
-__initcall(register_kernel_offset_dumper);
+device_initcall(register_arm64_panic_block);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 1e93cfc7c47a..6c3eb424c613 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -563,27 +563,11 @@ void free_initmem(void)
unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
}
-/*
- * Dump out memory limit information on panic.
- */
-static int dump_mem_limit(struct notifier_block *self, unsigned long v, void
*p)
+void dump_mem_limit(void)
{
if (memory_limit != PHYS_ADDR_MAX) {
pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
} else {
pr_emerg("Memory Limit:
Re: DMA Engine: Transfer From Userspace
On 21-06-20, 22:36, Federico Vaga wrote: > On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote: > > On 19-06-20, 16:31, Dave Jiang wrote: > > > > > > > > > On 6/19/2020 3:47 PM, Federico Vaga wrote: > > > > Hello, > > > > > > > > is there the possibility of using a DMA engine channel from userspace? > > > > > > > > Something like: > > > > - configure DMA using ioctl() (or whatever configuration mechanism) > > > > - read() or write() to trigger the transfer > > > > > > > > > > I may have supposedly promised Vinod to look into possibly providing > > > something like this in the future. But I have not gotten around to do that > > > yet. Currently, no such support. > > > > And I do still have serious reservations about this topic :) Opening up > > userspace access to DMA does not sound very great from security point of > > view. > > I was thinking about a dedicated module, and not something that the DMA engine > offers directly. You load the module only if you need it (like the test > module) But loading that module would expose dma to userspace. > > > Federico, what use case do you have in mind? > > Userspace drivers more the reason not do do so, why cant a kernel driver be added for your usage? -- ~Vinod
Re: [PATCH v2 01/11] KVM: x86: Add helper functions for illegal GPA checking and page fault injection
On Fri, Jun 19, 2020 at 05:39:15PM +0200, Mohammed Gamal wrote:
> This patch adds two helper functions that will be used to support virtualizing
> MAXPHYADDR in both kvm-intel.ko and kvm.ko.
>
> kvm_fixup_and_inject_pf_error() injects a page fault for a user-specified GVA,
> while kvm_mmu_is_illegal_gpa() checks whether a GPA exceeds vCPU address
> limits.
>
> Signed-off-by: Mohammed Gamal
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/mmu.h | 6 ++
> arch/x86/kvm/x86.c | 21 +
> arch/x86/kvm/x86.h | 1 +
> 3 files changed, 28 insertions(+)
>
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 0ad06bfe2c2c..555237dfb91c 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -4,6 +4,7 @@
>
> #include
> #include "kvm_cache_regs.h"
> +#include "cpuid.h"
>
> #define PT64_PT_BITS 9
> #define PT64_ENT_PER_PAGE (1 << PT64_PT_BITS)
> @@ -158,6 +159,11 @@ static inline bool is_write_protection(struct kvm_vcpu
> *vcpu)
> return kvm_read_cr0_bits(vcpu, X86_CR0_WP);
> }
>
> +static inline bool kvm_mmu_is_illegal_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
> +{
> +return (gpa >= BIT_ULL(cpuid_maxphyaddr(vcpu)));
> +}
> +
> /*
> * Check if a given access (described through the I/D, W/R and U/S bits of a
> * page fault error code pfec) causes a permission fault with the given PTE
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 00c88c2f34e4..ac8642e890b1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10693,6 +10693,27 @@ u64 kvm_spec_ctrl_valid_bits(struct kvm_vcpu *vcpu)
> }
> EXPORT_SYMBOL_GPL(kvm_spec_ctrl_valid_bits);
>
> +void kvm_fixup_and_inject_pf_error(struct kvm_vcpu *vcpu, gva_t gva, u16
> error_code)
> +{
> + struct x86_exception fault;
> +
> + if (!(error_code & PFERR_PRESENT_MASK) ||
> + vcpu->arch.walk_mmu->gva_to_gpa(vcpu, gva, error_code, ) !=
> UNMAPPED_GVA) {
> + /*
> + * If vcpu->arch.walk_mmu->gva_to_gpa succeeded, the page
> + * tables probably do not match the TLB. Just proceed
> + * with the error code that the processor gave.
> + */
> + fault.vector = PF_VECTOR;
> + fault.error_code_valid = true;
> + fault.error_code = error_code;
> + fault.nested_page_fault = false;
> + fault.address = gva;
> + }
> + vcpu->arch.walk_mmu->inject_page_fault(vcpu, );
Should this "vcpu->arch.walk_mmu->inject_page_fault(vcpu, )" inside the
last brace?
Otherwise an uninitialized fault variable will be passed to the
walk_mmu->inject_page_fault.
> +}
> +EXPORT_SYMBOL_GPL(kvm_fixup_and_inject_pf_error);
> +
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_fast_mmio);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index 6eb62e97e59f..239ae0f3e40b 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -272,6 +272,7 @@ int kvm_mtrr_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64
> *pdata);
> bool kvm_mtrr_check_gfn_range_consistency(struct kvm_vcpu *vcpu, gfn_t gfn,
> int page_num);
> bool kvm_vector_hashing_enabled(void);
> +void kvm_fixup_and_inject_pf_error(struct kvm_vcpu *vcpu, gva_t gva, u16
> error_code);
> int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
> int emulation_type, void *insn, int insn_len);
> fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu);
> --
> 2.26.2
>
Re: [PATCH v2 00/11] KVM: Support guest MAXPHYADDR < host MAXPHYADDR
On Fri, Jun 19, 2020 at 05:39:14PM +0200, Mohammed Gamal wrote: > When EPT/NPT is enabled, KVM does not really look at guest physical > address size. Address bits above maximum physical memory size are reserved. > Because KVM does not look at these guest physical addresses, it currently > effectively supports guest physical address sizes equal to the host. > > This can be problem when having a mixed setup of machines with 5-level page > tables and machines with 4-level page tables, as live migration can change > MAXPHYADDR while the guest runs, which can theoretically introduce bugs. > > In this patch series we add checks on guest physical addresses in EPT > violation/misconfig and NPF vmexits and if needed inject the proper > page faults in the guest. > > A more subtle issue is when the host MAXPHYADDR is larger than that of the > guest. Page faults caused by reserved bits on the guest won't cause an EPT > violation/NPF and hence we also check guest MAXPHYADDR and add PFERR_RSVD_MASK > error code to the page fault if needed. > > The last 3 patches (i.e. SVM bits and patch 11) are not intended for > immediate inclusion and probably need more discussion. > We've been noticing some unexpected behavior in handling NPF vmexits > on AMD CPUs (see individual patches for details), and thus we are > proposing a workaround (see last patch) that adds a capability that > userspace can use to decide who to deal with hosts that might have > issues supprting guest MAXPHYADDR < host MAXPHYADDR. > > > Mohammed Gamal (7): > KVM: x86: Add helper functions for illegal GPA checking and page fault > injection > KVM: x86: mmu: Move translate_gpa() to mmu.c > KVM: x86: mmu: Add guest physical address check in translate_gpa() > KVM: VMX: Add guest physical address check in EPT violation and > misconfig > KVM: SVM: introduce svm_need_pf_intercept > KVM: SVM: Add guest physical address check in NPF/PF interception > KVM: x86: SVM: VMX: Make GUEST_MAXPHYADDR < HOST_MAXPHYADDR support > configurable > > Paolo Bonzini (4): > KVM: x86: rename update_bp_intercept to update_exception_bitmap > KVM: x86: update exception bitmap on CPUID changes > KVM: VMX: introduce vmx_need_pf_intercept > KVM: VMX: optimize #PF injection when MAXPHYADDR does not match > > arch/x86/include/asm/kvm_host.h | 10 ++-- > arch/x86/kvm/cpuid.c| 2 ++ > arch/x86/kvm/mmu.h | 6 + > arch/x86/kvm/mmu/mmu.c | 12 + > arch/x86/kvm/svm/svm.c | 41 +++--- > arch/x86/kvm/svm/svm.h | 6 + > arch/x86/kvm/vmx/nested.c | 28 > arch/x86/kvm/vmx/vmx.c | 45 + > arch/x86/kvm/vmx/vmx.h | 6 + > arch/x86/kvm/x86.c | 29 - > arch/x86/kvm/x86.h | 1 + > include/uapi/linux/kvm.h| 1 + > 12 files changed, 158 insertions(+), 29 deletions(-) > > -- > 2.26.2 >
[PATCH V8 2/4] clk: qcom: Add ipq apss pll driver
The CPUs on Qualcomm ipq based devices are clocked by an alpha PLL.
Add support for the apss pll found on ipq based devices which can
support CPU frequencies above 1Ghz.
Signed-off-by: Sivaprakash Murugesan
---
drivers/clk/qcom/Kconfig| 8
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/apss-ipq-pll.c | 95 +
3 files changed, 104 insertions(+)
create mode 100644 drivers/clk/qcom/apss-ipq-pll.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index cde6ca90a06b..49e265ddcdab 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -89,6 +89,14 @@ config APQ_MMCC_8084
Say Y if you want to support multimedia devices such as display,
graphics, video encode/decode, camera, etc.
+config IPQ_APSS_PLL
+ tristate "IPQ APSS PLL"
+ help
+ Support for APSS PLL on ipq devices. The APSS PLL is the main
+ clock that feeds the CPUs on ipq based devices.
+ Say Y if you want to support CPU frequency scaling on ipq based
+ devices.
+
config IPQ_GCC_4019
tristate "IPQ4019 Global Clock Controller"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 7ec8561a1270..7942c00902ec 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -19,6 +19,7 @@ clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
# Keep alphabetically sorted by config
obj-$(CONFIG_APQ_GCC_8084) += gcc-apq8084.o
obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
+obj-$(CONFIG_IPQ_APSS_PLL) += apss-ipq-pll.o
obj-$(CONFIG_IPQ_GCC_4019) += gcc-ipq4019.o
obj-$(CONFIG_IPQ_GCC_6018) += gcc-ipq6018.o
obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
diff --git a/drivers/clk/qcom/apss-ipq-pll.c b/drivers/clk/qcom/apss-ipq-pll.c
new file mode 100644
index ..e34f4cd1daa5
--- /dev/null
+++ b/drivers/clk/qcom/apss-ipq-pll.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+#include
+#include
+#include
+#include
+
+#include "clk-alpha-pll.h"
+
+static const u8 ipq_pll_offsets[] = {
+ [PLL_OFF_L_VAL] = 0x08,
+ [PLL_OFF_ALPHA_VAL] = 0x10,
+ [PLL_OFF_USER_CTL] = 0x18,
+ [PLL_OFF_CONFIG_CTL] = 0x20,
+ [PLL_OFF_CONFIG_CTL_U] = 0x24,
+ [PLL_OFF_STATUS] = 0x28,
+ [PLL_OFF_TEST_CTL] = 0x30,
+ [PLL_OFF_TEST_CTL_U] = 0x34,
+};
+
+static struct clk_alpha_pll ipq_pll = {
+ .offset = 0x0,
+ .regs = ipq_pll_offsets,
+ .flags = SUPPORTS_DYNAMIC_UPDATE,
+ .clkr = {
+ .enable_reg = 0x0,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "a53pll",
+ .parent_data = &(const struct clk_parent_data) {
+ .fw_name = "xo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_huayra_ops,
+ },
+ },
+};
+
+static const struct alpha_pll_config ipq_pll_config = {
+ .l = 0x37,
+ .config_ctl_val = 0x04141200,
+ .config_ctl_hi_val = 0x0,
+ .early_output_mask = BIT(3),
+ .main_output_mask = BIT(0),
+};
+
+static const struct regmap_config ipq_pll_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x40,
+ .fast_io= true,
+};
+
+static int apss_ipq_pll_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct regmap *regmap;
+ void __iomem *base;
+ int ret;
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ regmap = devm_regmap_init_mmio(dev, base, _pll_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ clk_alpha_pll_configure(_pll, regmap, _pll_config);
+
+ ret = devm_clk_register_regmap(dev, _pll.clkr);
+ if (ret)
+ return ret;
+
+ return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
+ _pll.clkr.hw);
+}
+
+static const struct of_device_id apss_ipq_pll_match_table[] = {
+ { .compatible = "qcom,ipq6018-a53pll" },
+ { }
+};
+
+static struct platform_driver apss_ipq_pll_driver = {
+ .probe = apss_ipq_pll_probe,
+ .driver = {
+ .name = "qcom-ipq-apss-pll",
+ .of_match_table = apss_ipq_pll_match_table,
+ },
+};
+module_platform_driver(apss_ipq_pll_driver);
+
+MODULE_DESCRIPTION("Qualcomm technology Inc APSS ALPHA PLL Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V8 3/4] clk: qcom: Add DT bindings for ipq6018 apss clock controller
Add dt-binding for ipq6018 apss clock controller Acked-by: Rob Herring Signed-off-by: Sivaprakash Murugesan --- [V8] * took Ack from Rob include/dt-bindings/clock/qcom,apss-ipq.h | 12 1 file changed, 12 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,apss-ipq.h diff --git a/include/dt-bindings/clock/qcom,apss-ipq.h b/include/dt-bindings/clock/qcom,apss-ipq.h new file mode 100644 index ..77b6e05492e2 --- /dev/null +++ b/include/dt-bindings/clock/qcom,apss-ipq.h @@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2018, The Linux Foundation. All rights reserved. + */ + +#ifndef _DT_BINDINGS_CLOCK_QCA_APSS_IPQ6018_H +#define _DT_BINDINGS_CLOCK_QCA_APSS_IPQ6018_H + +#define APCS_ALIAS0_CLK_SRC0 +#define APCS_ALIAS0_CORE_CLK 1 + +#endif -- 2.7.4
[PATCH V8 0/4] Add APSS clock controller support for IPQ6018
The CPU on Qualcomm's IPQ6018 devices are primarily fed by APSS PLL and XO, these are connected to a clock mux and enable block. This patch series adds support for these clocks and inturn enables clocks required for CPU freq. [V8] * In patch 1 changed compatible string from const to enum * Since this change is minimal retained Review tag from Rob * In patch 3 re added Ack from Rob [V7] * Removed dts patch from this series, will send that separately * Addressed Rob's minor comment on the binding * Patch 1 depends on a53 pll bindings https://lkml.org/lkml/2020/5/4/60 [V6] * Split mailbox driver from this series, mailbox changes will sent as a separate series * Addressed review comments from Stephen [V5] * Addressed Bjorn comments on apss clk and dt-bindings * Patch 2 depends on a53 pll dt-bindings https://www.spinics.net/lists/linux-clk/msg48358.html [V4] * Re-written PLL found on IPQ platforms as a separate driver * Addressed stephen's comments on apss clock controller and pll * Addressed Rob's review comments on bindings * moved a53 pll binding from this series as it is not applicable, will send it separately. [V3] * Fixed dt binding check error in patch2 dt-bindings: clock: Add YAML schemas for QCOM A53 PLL [V2] * Restructred the patch series as there are two different HW blocks, the mux and enable belongs to the apcs block and PLL has a separate HW block. * Converted qcom mailbox and qcom a53 pll documentation to yaml. * Addressed review comments from Stephen, Rob and Sibi where it is applicable. * Changed this cover letter to state the purpose of this patch series Sivaprakash Murugesan (4): dt-bindings: clock: add ipq6018 a53 pll compatible clk: qcom: Add ipq apss pll driver clk: qcom: Add DT bindings for ipq6018 apss clock controller clk: qcom: Add ipq6018 apss clock controller .../devicetree/bindings/clock/qcom,a53pll.yaml | 18 drivers/clk/qcom/Kconfig | 19 drivers/clk/qcom/Makefile | 2 + drivers/clk/qcom/apss-ipq-pll.c| 95 ++ drivers/clk/qcom/apss-ipq6018.c| 106 + include/dt-bindings/clock/qcom,apss-ipq.h | 12 +++ 6 files changed, 252 insertions(+) create mode 100644 drivers/clk/qcom/apss-ipq-pll.c create mode 100644 drivers/clk/qcom/apss-ipq6018.c create mode 100644 include/dt-bindings/clock/qcom,apss-ipq.h -- 2.7.4
[PATCH V8 1/4] dt-bindings: clock: add ipq6018 a53 pll compatible
cpus on ipq6018 are clocked by a53 pll, add device compatible for a53
pll found on ipq6018 devices.
Reviewed-by: Rob Herring
Signed-off-by: Sivaprakash Murugesan
---
[V8]
* converted compatible strings from const to enum to avoid dt binding error
* retained Rob's review tag as the change is minimal
.../devicetree/bindings/clock/qcom,a53pll.yaml | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
index 20d2638b4cd2..db3d0ea6bc7a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
@@ -15,7 +15,9 @@ description:
properties:
compatible:
-const: qcom,msm8916-a53pll
+enum:
+ - qcom,ipq6018-a53pll
+ - qcom,msm8916-a53pll
reg:
maxItems: 1
@@ -23,6 +25,14 @@ properties:
'#clock-cells':
const: 0
+ clocks:
+items:
+ - description: board XO clock
+
+ clock-names:
+items:
+ - const: xo
+
required:
- compatible
- reg
@@ -38,3 +48,12 @@ examples:
reg = <0xb016000 0x40>;
#clock-cells = <0>;
};
+ #Example 2 - A53 PLL found on IPQ6018 devices
+ - |
+a53pll_ipq: clock-controller@b116000 {
+compatible = "qcom,ipq6018-a53pll";
+reg = <0x0b116000 0x40>;
+#clock-cells = <0>;
+clocks = <>;
+clock-names = "xo";
+};
--
2.7.4
[PATCH V8 4/4] clk: qcom: Add ipq6018 apss clock controller
The CPU on Qualcomm ipq6018 devices are clocked primarily by a aplha PLL
and xo which are connected to a mux and enable block.
Add support for the mux and enable block which feeds the CPU on ipq6018
devices.
Reviewed-by: Stephen Boyd
Signed-off-by: Sivaprakash Murugesan
---
drivers/clk/qcom/Kconfig| 11 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/apss-ipq6018.c | 106
3 files changed, 118 insertions(+)
create mode 100644 drivers/clk/qcom/apss-ipq6018.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 49e265ddcdab..f510ef61db69 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -97,6 +97,17 @@ config IPQ_APSS_PLL
Say Y if you want to support CPU frequency scaling on ipq based
devices.
+config IPQ_APSS_6018
+ tristate "IPQ APSS Clock Controller"
+ select IPQ_APSS_PLL
+ depends on QCOM_APCS_IPC || COMPILE_TEST
+ help
+ Support for APSS clock controller on IPQ platforms. The
+ APSS clock controller manages the Mux and enable block that feeds the
+ CPUs.
+ Say Y if you want to support CPU frequency scaling on
+ ipq based devices.
+
config IPQ_GCC_4019
tristate "IPQ4019 Global Clock Controller"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 7942c00902ec..21439b94395a 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -20,6 +20,7 @@ clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
obj-$(CONFIG_APQ_GCC_8084) += gcc-apq8084.o
obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
obj-$(CONFIG_IPQ_APSS_PLL) += apss-ipq-pll.o
+obj-$(CONFIG_IPQ_APSS_6018) += apss-ipq6018.o
obj-$(CONFIG_IPQ_GCC_4019) += gcc-ipq4019.o
obj-$(CONFIG_IPQ_GCC_6018) += gcc-ipq6018.o
obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
diff --git a/drivers/clk/qcom/apss-ipq6018.c b/drivers/clk/qcom/apss-ipq6018.c
new file mode 100644
index ..004f7e1ecdc2
--- /dev/null
+++ b/drivers/clk/qcom/apss-ipq6018.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "clk-regmap-mux.h"
+
+enum {
+ P_XO,
+ P_APSS_PLL_EARLY,
+};
+
+static const struct clk_parent_data parents_apcs_alias0_clk_src[] = {
+ { .fw_name = "xo" },
+ { .fw_name = "pll" },
+};
+
+static const struct parent_map parents_apcs_alias0_clk_src_map[] = {
+ { P_XO, 0 },
+ { P_APSS_PLL_EARLY, 5 },
+};
+
+static struct clk_regmap_mux apcs_alias0_clk_src = {
+ .reg = 0x0050,
+ .width = 3,
+ .shift = 7,
+ .parent_map = parents_apcs_alias0_clk_src_map,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "apcs_alias0_clk_src",
+ .parent_data = parents_apcs_alias0_clk_src,
+ .num_parents = 2,
+ .ops = _regmap_mux_closest_ops,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+static struct clk_branch apcs_alias0_core_clk = {
+ .halt_reg = 0x0058,
+ .clkr = {
+ .enable_reg = 0x0058,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "apcs_alias0_core_clk",
+ .parent_hws = (const struct clk_hw *[]){
+ _alias0_clk_src.clkr.hw },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = _branch2_ops,
+ },
+ },
+};
+
+static const struct regmap_config apss_ipq6018_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x1000,
+ .fast_io= true,
+};
+
+static struct clk_regmap *apss_ipq6018_clks[] = {
+ [APCS_ALIAS0_CLK_SRC] = _alias0_clk_src.clkr,
+ [APCS_ALIAS0_CORE_CLK] = _alias0_core_clk.clkr,
+};
+
+static const struct qcom_cc_desc apss_ipq6018_desc = {
+ .config = _ipq6018_regmap_config,
+ .clks = apss_ipq6018_clks,
+ .num_clks = ARRAY_SIZE(apss_ipq6018_clks),
+};
+
+static int apss_ipq6018_probe(struct platform_device *pdev)
+{
+ struct regmap *regmap;
+
+ regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return qcom_cc_really_probe(pdev, _ipq6018_desc, regmap);
+}
+
+static struct platform_driver apss_ipq6018_driver = {
+ .probe = apss_ipq6018_probe,
+ .driver = {
+ .name = "qcom,apss-ipq6018-clk",
+ },
+};
+
+module_platform_driver(apss_ipq6018_driver);
+
+MODULE_DESCRIPTION("QCOM APSS IPQ 6018 CLK Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
Re: [PATCH] venus: core: add shutdown callback for venus
Hi Stan,
On 2020-06-13 17:43, Stanimir Varbanov wrote:
Hi Mansur,
Thanks for the patch!
How you test this? Is it enough to start playback and issue reboot
(did
you test with reboot -f) ?
Yes, I have tested it with "reboot -f" and started video playback
(YouTube browser and local video)
and issue reboot command.
On 6/13/20 1:33 PM, Mansur Alisha Shaik wrote:
After the SMMU translation is disabled in the
arm-smmu shutdown callback during reboot, if
any subsystem are still alive then IOVAs they
are using will become PAs on bus, which may
lead to crash.
Below are the consumers of smmu from venus
arm-smmu: consumer: aa0.video-codec supplier=1500.iommu
arm-smmu: consumer: video-firmware.0 supplier=1500.iommu
So implemented shutdown callback, which detach iommu maps.
Change-Id: I0f0f331056e0b84b92f1d86f66618d4b1caaa24a
Signed-off-by: Mansur Alisha Shaik
---
drivers/media/platform/qcom/venus/core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 30d4b9e..acf798c 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -371,6 +371,14 @@ static int venus_remove(struct platform_device
*pdev)
return ret;
}
+static void venus_core_shutdown(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = venus_remove(pdev);
+ WARN_ON(ret < 0);
+}
+
static __maybe_unused int venus_runtime_suspend(struct device *dev)
{
struct venus_core *core = dev_get_drvdata(dev);
@@ -628,6 +636,7 @@ static struct platform_driver qcom_venus_driver =
{
.of_match_table = venus_dt_match,
.pm = _pm_ops,
},
+ .shutdown = venus_core_shutdown,
};
module_platform_driver(qcom_venus_driver);
Thank,
Mansur
Re: [RFC PATCH 1/2] Explicitly include linux/major.h where it is needed
Hi Arnd, On Wed, 17 Jun 2020 16:18:10 +1000 Stephen Rothwell wrote: > > On Wed, 17 Jun 2020 07:58:43 +0200 Greg KH wrote: > > > > On Wed, Jun 17, 2020 at 09:27:47AM +1000, Stephen Rothwell wrote: > > > This is in preparation for removing the include of major.h where it is > > > not needed. > > > > > > These files were found using > > > > > > grep -E -L '[<"](uapi/)?linux/major\.h' $(git grep -l -w -f /tmp/xx) > > > > > > where /tmp/xx contains all the symbols defined in major.h. There were > > > a couple of files in that list that did not need the include since the > > > references are in comments. > > > > > > Signed-off-by: Stephen Rothwell > > > > Any reason this had an RFC, but patch 2/2 did not? > > I forgot :-) I added RFC just to hopefully get some attention as this > is just the start of a long slow use of my "spare" time. > > > They look good to me, I will be glad to take these, but do you still > > want reviews from others for this? It seems simple enough to me... > > Yeah, well, we all know the simplest patches usually cause the most pain :-) > > However, I have been fairly careful and it is an easy include file to > work with. And I have done my usual build checks, so the linux-next > maintainer won't complain about build problems :-) > > I would like to hear from Arnd, at least, as I don't want to step on > his toes (he is having a larger look at our include files). Any comment? -- Cheers, Stephen Rothwell pgpvcDfAWgD8W.pgp Description: OpenPGP digital signature
[rcu:rcu/next] BUILD SUCCESS d831090dafcc38c0c5671e69c3c7efa422bf4242
allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a006-20200621 i386 randconfig-a002-20200621 i386 randconfig-a003-20200621 i386 randconfig-a001-20200621 i386 randconfig-a005-20200621 i386 randconfig-a004-20200621 riscvallyesconfig riscv allnoconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec x86_64 rhel x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [RFC PATCH v2 0/5] scsi: ufs: Add Host Performance Booster Support
On 2020-06-14 23:27, Daejun Park wrote: > The current version only supports the DCM (device control mode). > This patch consists of 4 parts to support HPB feature. > > 1) UFS-feature layer > 2) HPB probe and initialization process > 3) READ -> HPB READ using cached map information > 4) L2P (logical to physical) map management I'm still not enthusiast about the choice for a bus to connect UFS core and the HPB module. But if others are fine with this choice, I won't object. Bart.
Re: [PATCH] Documentation: kunit: Add naming guidelines
Hi-- On 6/19/20 10:49 PM, David Gow wrote: > Documentation/dev-tools/kunit/index.rst | 1 + > Documentation/dev-tools/kunit/style.rst | 139 > 2 files changed, 140 insertions(+) > create mode 100644 Documentation/dev-tools/kunit/style.rst > > diff --git a/Documentation/dev-tools/kunit/index.rst > b/Documentation/dev-tools/kunit/index.rst > index e93606ecfb01..117c88856fb3 100644 > --- a/Documentation/dev-tools/kunit/index.rst > +++ b/Documentation/dev-tools/kunit/index.rst > @@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel > usage > kunit-tool > api/index > +style Use tab for indentation, not spaces. > faq thanks. -- ~Randy
Re: [PATCH v2 3/5] mm: memcg/percpu: per-memcg percpu memory statistics
On Sun, Jun 21, 2020 at 08:26:35PM -0700, Roman Gushchin wrote:
> On Sun, Jun 21, 2020 at 06:48:03PM -0700, Nathan Chancellor wrote:
> > On Mon, Jun 08, 2020 at 04:08:17PM -0700, Roman Gushchin wrote:
> > > Percpu memory can represent a noticeable chunk of the total
> > > memory consumption, especially on big machines with many CPUs.
> > > Let's track percpu memory usage for each memcg and display
> > > it in memory.stat.
> > >
> > > A percpu allocation is usually scattered over multiple pages
> > > (and nodes), and can be significantly smaller than a page.
> > > So let's add a byte-sized counter on the memcg level:
> > > MEMCG_PERCPU_B. Byte-sized vmstat infra created for slabs
> > > can be perfectly reused for percpu case.
> > >
> > > Signed-off-by: Roman Gushchin
> > > Acked-by: Dennis Zhou
> > > ---
> > > Documentation/admin-guide/cgroup-v2.rst | 4
> > > include/linux/memcontrol.h | 8
> > > mm/memcontrol.c | 4 +++-
> > > mm/percpu.c | 10 ++
> > > 4 files changed, 25 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/admin-guide/cgroup-v2.rst
> > > b/Documentation/admin-guide/cgroup-v2.rst
> > > index ce3e05e41724..7c1e784239bf 100644
> > > --- a/Documentation/admin-guide/cgroup-v2.rst
> > > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > > @@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
> > > Amount of memory used for storing in-kernel data
> > > structures.
> > >
> > > + percpu
> > > + Amount of memory used for storing per-cpu kernel
> > > + data structures.
> > > +
> > > sock
> > > Amount of memory used in network transmission buffers
> > >
> > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > > index eede46c43573..7ed3af71a6fb 100644
> > > --- a/include/linux/memcontrol.h
> > > +++ b/include/linux/memcontrol.h
> > > @@ -32,11 +32,19 @@ struct kmem_cache;
> > > enum memcg_stat_item {
> > > MEMCG_SWAP = NR_VM_NODE_STAT_ITEMS,
> > > MEMCG_SOCK,
> > > + MEMCG_PERCPU_B,
> > > /* XXX: why are these zone and not node counters? */
> > > MEMCG_KERNEL_STACK_KB,
> > > MEMCG_NR_STAT,
> > > };
> > >
> > > +static __always_inline bool memcg_stat_item_in_bytes(enum
> > > memcg_stat_item item)
> > > +{
> > > + if (item == MEMCG_PERCPU_B)
> > > + return true;
> > > + return vmstat_item_in_bytes(item);
> >
> > This patch is now in -next and this line causes a warning from clang,
> > which shows up in every translation unit that includes this header,
> > which is a lot:
> >
> > include/linux/memcontrol.h:45:30: warning: implicit conversion from
> > enumeration type 'enum memcg_stat_item' to different enumeration type
> > 'enum node_stat_item' [-Wenum-conversion]
> > return vmstat_item_in_bytes(item);
> > ^~~~
> > 1 warning generated.
> >
> > I assume this conversion is intentional; if so, it seems like expecting
> > a specific enum is misleading. Perhaps this should be applied on top?
>
> Hi Nathan!
>
> Yeah, these enums are kind of stacked on each other, so memcg_stat values
> extend node_stat values. And I think your patch is correct.
Yeah, I figured. It happens in the kernel in a couple of different
places that we have seen so far. So far, my suggestion seems to be the
best one that we have uncovered when dealing with one enum that
supplments or extends another. These functions are fairly self
explanation so I don't think that blowing away the type safety here is a
big deal.
> I'm going to refresh the series with some small fixups. If you're not against
> it, I'll merge your patch into the corresponding patches.
Please do! Thanks for the quick response.
Cheers,
Nathan
> And thank you for reporting the problem!
>
> >
> > Cheers,
> > Nathan
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index 2499f78cf32d..bddeb4ce7a4f 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -38,7 +38,7 @@ enum memcg_stat_item {
> > MEMCG_NR_STAT,
> > };
> >
> > -static __always_inline bool memcg_stat_item_in_bytes(enum memcg_stat_item
> > item)
> > +static __always_inline bool memcg_stat_item_in_bytes(int item)
> > {
> > if (item == MEMCG_PERCPU_B)
> > return true;
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 084ee1c17160..52d7961a24f0 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -211,7 +211,7 @@ enum node_stat_item {
> > * measured in pages). This defines the API part, the internal
> > representation
> > * might be different.
> > */
> > -static __always_inline bool vmstat_item_in_bytes(enum node_stat_item item)
> > +static __always_inline bool vmstat_item_in_bytes(int item)
> > {
> > /*
> > * Global and per-node slab counters track slab pages.
Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"
On Sun, Jun 21, 2020 at 8:02 PM Jason A. Donenfeld wrote: > > This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809. > > This commit broke userspace. Bash uses ESPIPE to determine whether or > not the file should be read using "unbuffered I/O", which means reading > 1 byte at a time instead of 128 bytes at a time. Ack. Somewhat odd behavior, but clearly user space depended on the legacy "return EINVAL rather than ESPIPE" behavior. I do think there are other reasons to not return ESPIPE. The fact is, the printk buffer _is_ seekable, it's just relative seeking that doesn't work. You can seek to the beginning and the end and a particular offset, just not relative. So I kind of see why people wanted to return ESPIPE, but at the same time it really is very misleading: ESPIPE is for pure streams that can't lseek at all. The fact that some silly shell internal then reacts very badly to that may be extreme, but it may be as well as you can do it you worry about leaving data for the next user. I've applied the revert. Linus
Re: [PATCH] rcu/tree: Force quiescent state on callback overload
Hi Paul,
On 6/22/2020 8:43 AM, Paul E. McKenney wrote:
On Mon, Jun 22, 2020 at 01:30:31AM +0530, Neeraj Upadhyay wrote:
Hi Paul,
On 6/22/2020 1:20 AM, Paul E. McKenney wrote:
On Mon, Jun 22, 2020 at 12:07:27AM +0530, Neeraj Upadhyay wrote:
On callback overload, we want to force quiescent state immediately,
for the first and second fqs. Enforce the same, by including
RCU_GP_FLAG_OVLD flag, in fqsstart check.
Signed-off-by: Neeraj Upadhyay
Good catch!
But what did you do to verify that this change does the right thing?
Thanx, Paul
I haven't done a runtime verification of this code path; I posted this,
based on review of this code.
My concern is that under overload, the FQS scans would happen continuously
rather than accelerating only the first such scan in a given grace period.
This would of course result in a CPU-bound grace-period kthread, which
users might not be all that happy with.
Or am I missing something subtle that prevents this?
Looks like under overload, only the first and second scans are accelerated?
gf = 0;
if (first_gp_fqs) {
first_gp_fqs = false;
gf = rcu_state.cbovld ? RCU_GP_FLAG_OVLD : 0;
}
Thanks
Neeraj
But yes, it does look like the current mainline code fails to do the
first scan immediately, so again, good catch!
Thanx, Paul
Thanks
Neeraj
---
kernel/rcu/tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d0988a1..6226bfb 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1865,7 +1865,7 @@ static void rcu_gp_fqs_loop(void)
break;
/* If time for quiescent-state forcing, do it. */
if (!time_after(rcu_state.jiffies_force_qs, jiffies) ||
- (gf & RCU_GP_FLAG_FQS)) {
+ (gf & (RCU_GP_FLAG_FQS | RCU_GP_FLAG_OVLD))) {
trace_rcu_grace_period(rcu_state.name, rcu_state.gp_seq,
TPS("fqsstart"));
rcu_gp_fqs(first_gp_fqs);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
the Code Aurora Forum, hosted by The Linux Foundation
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC PATCH v4 07/10] vfio/pci: introduce a new irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION
On Fri, Jun 19, 2020 at 04:55:34PM -0600, Alex Williamson wrote: > On Wed, 10 Jun 2020 01:23:14 -0400 > Yan Zhao wrote: > > > On Fri, Jun 05, 2020 at 10:13:01AM -0600, Alex Williamson wrote: > > > On Thu, 4 Jun 2020 22:02:31 -0400 > > > Yan Zhao wrote: > > > > > > > On Wed, Jun 03, 2020 at 10:10:58PM -0600, Alex Williamson wrote: > > > > > On Wed, 3 Jun 2020 22:42:28 -0400 > > > > > Yan Zhao wrote: > > > > > > > > > > > On Wed, Jun 03, 2020 at 05:04:52PM -0600, Alex Williamson wrote: > > > > > > > On Tue, 2 Jun 2020 21:40:58 -0400 > > > > > > > Yan Zhao wrote: > > > > > > > > > > > > > > > On Tue, Jun 02, 2020 at 01:34:35PM -0600, Alex Williamson > > > > > > > > wrote: > > > > > > > > > I'm not at all happy with this. Why do we need to hide the > > > > > > > > > migration > > > > > > > > > sparse mmap from the user until migration time? What if > > > > > > > > > instead we > > > > > > > > > introduced a new VFIO_REGION_INFO_CAP_SPARSE_MMAP_SAVING > > > > > > > > > capability > > > > > > > > > where the existing capability is the normal runtime sparse > > > > > > > > > setup and > > > > > > > > > the user is required to use this new one prior to enabled > > > > > > > > > device_state > > > > > > > > > with _SAVING. The vendor driver could then simply track mmap > > > > > > > > > vmas to > > > > > > > > > the region and refuse to change device_state if there are > > > > > > > > > outstanding > > > > > > > > > mmaps conflicting with the _SAVING sparse mmap layout. No > > > > > > > > > new IRQs > > > > > > > > > required, no new irqfds, an incremental change to the > > > > > > > > > protocol, > > > > > > > > > backwards compatible to the extent that a vendor driver > > > > > > > > > requiring this > > > > > > > > > will automatically fail migration. > > > > > > > > > > > > > > > > > right. looks we need to use this approach to solve the problem. > > > > > > > > thanks for your guide. > > > > > > > > so I'll abandon the current remap irq way for dirty tracking > > > > > > > > during live > > > > > > > > migration. > > > > > > > > but anyway, it demos how to customize irq_types in vendor > > > > > > > > drivers. > > > > > > > > then, what do you think about patches 1-5? > > > > > > > > > > > > > > In broad strokes, I don't think we've found the right solution > > > > > > > yet. I > > > > > > > really question whether it's supportable to parcel out vfio-pci > > > > > > > like > > > > > > > this and I don't know how I'd support unraveling whether we have > > > > > > > a bug > > > > > > > in vfio-pci, the vendor driver, or how the vendor driver is > > > > > > > making use > > > > > > > of vfio-pci. > > > > > > > > > > > > > > Let me also ask, why does any of this need to be in the kernel? > > > > > > > We > > > > > > > spend 5 patches slicing up vfio-pci so that we can register a > > > > > > > vendor > > > > > > > driver and have that vendor driver call into vfio-pci as it sees > > > > > > > fit. > > > > > > > We have two patches creating device specific interrupts and a BAR > > > > > > > remapping scheme that we've decided we don't need. That brings > > > > > > > us to > > > > > > > the actual i40e vendor driver, where the first patch is simply > > > > > > > making > > > > > > > the vendor driver work like vfio-pci already does, the second > > > > > > > patch is > > > > > > > handling the migration region, and the third patch is > > > > > > > implementing the > > > > > > > BAR remapping IRQ that we decided we don't need. It's difficult > > > > > > > to > > > > > > > actually find the small bit of code that's required to support > > > > > > > migration outside of just dealing with the protocol we've defined > > > > > > > to > > > > > > > expose this from the kernel. So why are we trying to do this in > > > > > > > the > > > > > > > kernel? We have quirk support in QEMU, we can easily flip > > > > > > > MemoryRegions on and off, etc. What access to the device outside > > > > > > > of > > > > > > > what vfio-pci provides to the user, and therefore QEMU, is > > > > > > > necessary to > > > > > > > implement this migration support for i40e VFs? Is this just an > > > > > > > exercise in making use of the migration interface? Thanks, > > > > > > > > > > > > > hi Alex > > > > > > > > > > > > There was a description of intention of this series in RFC v1 > > > > > > (https://www.spinics.net/lists/kernel/msg3337337.html). > > > > > > sorry, I didn't include it in starting from RFC v2. > > > > > > > > > > > > " > > > > > > The reason why we don't choose the way of writing mdev parent > > > > > > driver is > > > > > > that > > > > > > > > > > I didn't mention an mdev approach, I'm asking what are we > > > > > accomplishing > > > > > by doing this in the kernel at all versus exposing the device as > > > > > normal > > > > > through vfio-pci and providing the migration support in QEMU. Are you > > > > > actually
Re: [PATCH v8 00/13] perf: support enable and disable commands in stat and record modes
Hi,
On 17.06.2020 11:30, Alexey Budankov wrote:
>
> Changes in v8:
> - avoided moving of fds at fdarray__filter() call
> - skipped counting of fds with zeroed revents at fdarray__filter() call
> - converted explicit --ctl-fd[-ack] into --control fd:ctl-fd[,ack-fd option
> - updated docs to accommodate --control fd:ctl-fd[,ack-fd] option
Are there any questions or thoughts so far?
Thanks,
Alexey
>
> v7:
> https://lore.kernel.org/lkml/5de4b954-24f0-1e8d-5a0d-7b12783b8...@linux.intel.com/
>
> Changes in v7:
> - added missing perf-record.txt changes
> - adjusted docs wording for --ctl-fd,ctl-fd-ack options
> to additionally mention --delay=-1 effect
>
> v6:
> https://lore.kernel.org/lkml/f8e3a714-d9b1-4647-e1d2-9981cbaa8...@linux.intel.com/
>
> Changes in v6:
> - split re-factoring of events handling loops for stat mode
> into smaller incremental parts
> - added parts missing at v5
> - corrected v5 runtime issues
>
> v5:
> https://lore.kernel.org/lkml/e5cac8dd-7aa4-ec7c-671c-07756907a...@linux.intel.com/
>
> Changes in v5:
> - split re-factoring of events handling loops for stat mode
> into smaller incremental parts
>
> v4:
> https://lore.kernel.org/lkml/653fe5f3-c986-a841-1ed8-0a7d2fa24...@linux.intel.com/
>
> Changes in v4:
> - made checking of ctlfd state unconditional in record trace streaming loop
> - introduced static poll fds to keep evlist__filter_pollfd() unaffected
> - handled ret code of evlist__initialize_ctlfd() where need
> - renamed and structured handle_events() function
> - applied anonymous structs where needed
>
> v3:
> https://lore.kernel.org/lkml/eb38e9e5-754f-d410-1d9b-e26b702d5...@linux.intel.com/
>
> Changes in v3:
> - renamed functions and types from perf_evlist_ to evlist_ to avoid
> clash with libperf code;
> - extended commands to be strings of variable length consisting of
> command name and also possibly including command specific data;
> - merged docs update with the code changes;
> - updated docs for -D,--delay=-1 option for stat and record modes;
>
> v2:
> https://lore.kernel.org/lkml/d582cc3d-2302-c7e2-70d3-bc7ab6f62...@linux.intel.com/
>
> Changes in v2:
> - renamed resume and pause commands to enable and disable ones, renamed
> CTL_CMD_RESUME and CTL_CMD_PAUSE to CTL_CMD_ENABLE and CTL_CMD_DISABLE
> to fit to the appropriate ioctls and avoid mixing up with PAUSE_OUTPUT
> ioctl;
> - factored out event handling loop into a handle_events() for stat mode;
> - separated -D,--delay=-1 into separate patches for stat and record modes;
>
> v1:
> https://lore.kernel.org/lkml/825a5132-b58d-c0b6-b050-5a6040386...@linux.intel.com/
>
> repo: tip of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> perf/core
>
> The patch set implements handling of 'start disabled', 'enable' and 'disable'
> external control commands which can be provided for stat and record modes
> of the tool from an external controlling process. 'start disabled' command
> can be used to postpone enabling of events in the beginning of a monitoring
> session. 'enable' and 'disable' commands can be used to enable and disable
> events correspondingly any time after the start of the session.
>
> The 'start disabled', 'enable' and 'disable' external control commands can be
> used to focus measurement on specially selected time intervals of workload
> execution. Focused measurement reduces tool intrusion and influence on
> workload behavior, reduces distortion and amount of collected and stored
> data, mitigates data accuracy loss because measurement and data capturing
> happen only during intervals of interest.
>
> A controlling process can be a bash shell script [1], native executable or
> any other language program that can directly work with file descriptors,
> e.g. pipes [2], and spawn a process, specially the tool one.
>
> -D,--delay option is extended with -1 value to skip events enabling
> in the beginning of a monitoring session ('start disabled' command).
> --control fd:ctl-fd[,ack-fd] command line option is introduced to provide the
> tool with a pair of file descriptors to listen to control commands and reply
> to the controlling process on the completion of received commands.
>
> The tool reads control command message from ctl-fd descriptor, handles the
> command and optionally replies acknowledgement message to ack-fd descriptor,
> if it is specified on the command line. 'enable' command is recognized as
> 'enable' string message and 'disable' command is recognized as 'disable'
> string message both received from ctl-fd descriptor. Completion message is
> 'ack\n' and sent to ack-fd descriptor.
>
> Example bash script demonstrating simple use case follows:
>
> #!/bin/bash
>
> ctl_dir=/tmp/
>
> ctl_fifo=${ctl_dir}perf_ctl.fifo
> test -p ${ctl_fifo} && unlink ${ctl_fifo}
> mkfifo ${ctl_fifo} && exec {ctl_fd}<>${ctl_fifo}
>
> ctl_ack_fifo=${ctl_dir}perf_ctl_ack.fifo
> test -p ${ctl_ack_fifo} && unlink ${ctl_ack_fifo}
> mkfifo ${ctl_ack_fifo} &&
Re: [PATCH v2 3/5] mm: memcg/percpu: per-memcg percpu memory statistics
On Sun, Jun 21, 2020 at 06:48:03PM -0700, Nathan Chancellor wrote:
> On Mon, Jun 08, 2020 at 04:08:17PM -0700, Roman Gushchin wrote:
> > Percpu memory can represent a noticeable chunk of the total
> > memory consumption, especially on big machines with many CPUs.
> > Let's track percpu memory usage for each memcg and display
> > it in memory.stat.
> >
> > A percpu allocation is usually scattered over multiple pages
> > (and nodes), and can be significantly smaller than a page.
> > So let's add a byte-sized counter on the memcg level:
> > MEMCG_PERCPU_B. Byte-sized vmstat infra created for slabs
> > can be perfectly reused for percpu case.
> >
> > Signed-off-by: Roman Gushchin
> > Acked-by: Dennis Zhou
> > ---
> > Documentation/admin-guide/cgroup-v2.rst | 4
> > include/linux/memcontrol.h | 8
> > mm/memcontrol.c | 4 +++-
> > mm/percpu.c | 10 ++
> > 4 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/admin-guide/cgroup-v2.rst
> > b/Documentation/admin-guide/cgroup-v2.rst
> > index ce3e05e41724..7c1e784239bf 100644
> > --- a/Documentation/admin-guide/cgroup-v2.rst
> > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > @@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
> > Amount of memory used for storing in-kernel data
> > structures.
> >
> > + percpu
> > + Amount of memory used for storing per-cpu kernel
> > + data structures.
> > +
> > sock
> > Amount of memory used in network transmission buffers
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index eede46c43573..7ed3af71a6fb 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -32,11 +32,19 @@ struct kmem_cache;
> > enum memcg_stat_item {
> > MEMCG_SWAP = NR_VM_NODE_STAT_ITEMS,
> > MEMCG_SOCK,
> > + MEMCG_PERCPU_B,
> > /* XXX: why are these zone and not node counters? */
> > MEMCG_KERNEL_STACK_KB,
> > MEMCG_NR_STAT,
> > };
> >
> > +static __always_inline bool memcg_stat_item_in_bytes(enum memcg_stat_item
> > item)
> > +{
> > + if (item == MEMCG_PERCPU_B)
> > + return true;
> > + return vmstat_item_in_bytes(item);
>
> This patch is now in -next and this line causes a warning from clang,
> which shows up in every translation unit that includes this header,
> which is a lot:
>
> include/linux/memcontrol.h:45:30: warning: implicit conversion from
> enumeration type 'enum memcg_stat_item' to different enumeration type
> 'enum node_stat_item' [-Wenum-conversion]
> return vmstat_item_in_bytes(item);
> ^~~~
> 1 warning generated.
>
> I assume this conversion is intentional; if so, it seems like expecting
> a specific enum is misleading. Perhaps this should be applied on top?
Hi Nathan!
Yeah, these enums are kind of stacked on each other, so memcg_stat values
extend node_stat values. And I think your patch is correct.
I'm going to refresh the series with some small fixups. If you're not against
it, I'll merge your patch into the corresponding patches.
And thank you for reporting the problem!
>
> Cheers,
> Nathan
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 2499f78cf32d..bddeb4ce7a4f 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -38,7 +38,7 @@ enum memcg_stat_item {
> MEMCG_NR_STAT,
> };
>
> -static __always_inline bool memcg_stat_item_in_bytes(enum memcg_stat_item
> item)
> +static __always_inline bool memcg_stat_item_in_bytes(int item)
> {
> if (item == MEMCG_PERCPU_B)
> return true;
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 084ee1c17160..52d7961a24f0 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -211,7 +211,7 @@ enum node_stat_item {
> * measured in pages). This defines the API part, the internal representation
> * might be different.
> */
> -static __always_inline bool vmstat_item_in_bytes(enum node_stat_item item)
> +static __always_inline bool vmstat_item_in_bytes(int item)
> {
> /*
>* Global and per-node slab counters track slab pages.
Re: [PATCH v2] nbd: Fix memory leak in nbd_add_socket
On 2020/6/20 20:05, Markus Elfring wrote:
If we add first socket to nbd, config->socks is malloced but
num_connections does not update(nsock's allocation fail), the memory
is leaked. Cause in later nbd_config_put(), will only free config->socks
when num_connections is not 0.
Let nsock's allocation first to avoid this.
I suggest to improve this change description.
Can an other wording variant be nicer?
em, how about this?
When adding first socket to nbd, if nsock's allocation fails, config->socks
is malloced but num_connections does not update, memory leak will
occur(Function
nbd_config_put will only free config->socks when num_connections is not 0).
…
+++ b/drivers/block/nbd.c
@@ -1037,21 +1037,22 @@ static int nbd_add_socket(struct nbd_device *nbd,
unsigned long arg,
return -EBUSY;
}
+ nsock = kzalloc(sizeof(struct nbd_sock), GFP_KERNEL);
Please use the following code variant.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=4333a9b0b67bb4e8bcd91bdd80da80b0ec151162#n854
+ nsock = kzalloc(sizeof(*nsock), GFP_KERNEL);
…
if (!socks) {
sockfd_put(sock);
+ kfree(nsock);
return -ENOMEM;
}
Please take another software design possibility into account.
if (!socks) {
- sockfd_put(sock);
- return -ENOMEM;
+ kfree(nsock);
+ goto put_socket;
}
Regards,
Markus
.
RE: [PATCH] ASoC: Intel: KeemBay: Fix header guard
Looks good to me.
Thanks
Regards
Jee Heng
-Original Message-
From: Nathan Chancellor
Sent: Wednesday, June 17, 2020 9:03 AM
To: Rojewski, Cezary ; Pierre-Louis Bossart
; Liam Girdwood
; Jie Yang ; Mark
Brown
Cc: Sia, Jee Heng ; alsa-de...@alsa-project.org;
linux-kernel@vger.kernel.org; clang-built-li...@googlegroups.com; Nathan
Chancellor
Subject: [PATCH] ASoC: Intel: KeemBay: Fix header guard
Clang warns:
In file included from sound/soc/intel/keembay/kmb_platform.c:14:
sound/soc/intel/keembay/kmb_platform.h:9:9: warning: 'KMB_PLATFORM_H_'
is used as a header guard here, followed by #define of a different macro
[-Wheader-guard] #ifndef KMB_PLATFORM_H_
^~~
sound/soc/intel/keembay/kmb_platform.h:10:9: note: 'KMB_PLATFORMP_H_'
is defined here; did you mean 'KMB_PLATFORM_H_'?
#define KMB_PLATFORMP_H_
^~~~
KMB_PLATFORM_H_
1 warning generated.
Fix the typo so that the header guard works as intended.
Fixes: c5477e966728 ("ASoC: Intel: Add KeemBay platform driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1053
Signed-off-by: Nathan Chancellor
---
sound/soc/intel/keembay/kmb_platform.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/keembay/kmb_platform.h
b/sound/soc/intel/keembay/kmb_platform.h
index 29600652d8f4..6bf221aa8fff 100644
--- a/sound/soc/intel/keembay/kmb_platform.h
+++ b/sound/soc/intel/keembay/kmb_platform.h
@@ -7,7 +7,7 @@
*/
#ifndef KMB_PLATFORM_H_
-#define KMB_PLATFORMP_H_
+#define KMB_PLATFORM_H_
#include
#include
base-commit: 27f70ec4fa0e0f419031f1b8d61b1a788244e313
--
2.27.0
WARNING in usb_ep_queue
We report a bug (in linux-5.6.11) found by FuzzUSB (a modified version of syzkaller) == WARNING: CPU: 0 PID: 4452 at drivers/usb/gadget/udc/core.c:276 usb_ep_queue+0x157/0x3a0 drivers/usb/gadget/udc/core.c:276 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4452 Comm: syz-executor.0 Not tainted 5.6.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 panic+0x2de/0x6fa kernel/panic.c:221 __warn+0x1e1/0x1f6 kernel/panic.c:582 report_bug+0x208/0x320 lib/bug.c:195 fixup_bug.part.6+0x37/0x80 arch/x86/kernel/traps.c:174 fixup_bug arch/x86/kernel/traps.c:261 [inline] do_error_trap+0x131/0x170 arch/x86/kernel/traps.c:267 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:usb_ep_queue+0x157/0x3a0 drivers/usb/gadget/udc/core.c:276 Code: 48 0f a3 1d 7b c3 12 05 0f 82 2b 01 00 00 e8 e0 0a 8c fd 44 89 e8 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 c9 0a 8c fd <0f> 0b 41 bd 94 ff ff ff eb 96 e8 ba 0a 8c fd 65 44 8b 25 a2 da 4a RSP: 0018:888039f37c78 EFLAGS: 00010216 RAX: 0004 RBX: 888065ecc0d8 RCX: 83b6d8a7 RDX: 00f1 RSI: c99b3000 RDI: 888065ecc10d RBP: 888039f37ca8 R08: ed100a825a17 R09: R10: R11: R12: R13: 0a20 R14: 88803e970710 R15: 0001 f_hidg_write+0x6a9/0x9e0 drivers/usb/gadget/function/f_hid.c:396 __vfs_write+0x85/0x110 fs/read_write.c:494 vfs_write+0x1cd/0x510 fs/read_write.c:558 ksys_write+0x18a/0x220 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:620 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4531a9 Code: ed 60 fc 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 bb 60 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7efd8e783c78 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0073bf00 RCX: 004531a9 RDX: 0001 RSI: 2080 RDI: 0005 RBP: 0003 R08: R09: R10: R11: 0246 R12: 004c09c7 R13: 004d8a48 R14: 7efd8e7846d4 R15: == Thanks, Kyungtae Kim
Re: [PATCH] rcu/tree: Force quiescent state on callback overload
On Mon, Jun 22, 2020 at 01:30:31AM +0530, Neeraj Upadhyay wrote:
> Hi Paul,
>
> On 6/22/2020 1:20 AM, Paul E. McKenney wrote:
> > On Mon, Jun 22, 2020 at 12:07:27AM +0530, Neeraj Upadhyay wrote:
> > > On callback overload, we want to force quiescent state immediately,
> > > for the first and second fqs. Enforce the same, by including
> > > RCU_GP_FLAG_OVLD flag, in fqsstart check.
> > >
> > > Signed-off-by: Neeraj Upadhyay
> >
> > Good catch!
> >
> > But what did you do to verify that this change does the right thing?
> >
> > Thanx, Paul
> >
>
> I haven't done a runtime verification of this code path; I posted this,
> based on review of this code.
My concern is that under overload, the FQS scans would happen continuously
rather than accelerating only the first such scan in a given grace period.
This would of course result in a CPU-bound grace-period kthread, which
users might not be all that happy with.
Or am I missing something subtle that prevents this?
But yes, it does look like the current mainline code fails to do the
first scan immediately, so again, good catch!
Thanx, Paul
> Thanks
> Neeraj
>
> > > ---
> > > kernel/rcu/tree.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index d0988a1..6226bfb 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -1865,7 +1865,7 @@ static void rcu_gp_fqs_loop(void)
> > > break;
> > > /* If time for quiescent-state forcing, do it. */
> > > if (!time_after(rcu_state.jiffies_force_qs, jiffies) ||
> > > - (gf & RCU_GP_FLAG_FQS)) {
> > > + (gf & (RCU_GP_FLAG_FQS | RCU_GP_FLAG_OVLD))) {
> > > trace_rcu_grace_period(rcu_state.name,
> > > rcu_state.gp_seq,
> > > TPS("fqsstart"));
> > > rcu_gp_fqs(first_gp_fqs);
> > > --
> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > > a Linux Foundation Collaborative Project
> > >
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
> the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 2/2] checks: Improve i2c reg property checking
The i2c bindings in the kernel tree describe support for 10 bit
addressing, which must be indicated with the I2C_TEN_BIT_ADDRESS flag.
When this is set the address can be up to 10 bits. When it is not set
the address is a maximum of 7 bits.
See Documentation/devicetree/bindings/i2c/i2c.txt.
Take into account this flag when checking the address is valid.
Signed-off-by: Joel Stanley
---
v2: Mask reg when checking the 10-bit size
v3: Fix test
v4: Add U to define
---
checks.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/checks.c b/checks.c
index 69b0156c940c..b7955dbd71ca 100644
--- a/checks.c
+++ b/checks.c
@@ -1023,6 +1023,7 @@ static void check_i2c_bus_bridge(struct check *c, struct
dt_info *dti, struct no
WARNING(i2c_bus_bridge, check_i2c_bus_bridge, NULL, _size_cells);
#define I2C_OWN_SLAVE_ADDRESS (1U << 30)
+#define I2C_TEN_BIT_ADDRESS(1U << 31)
static void check_i2c_bus_reg(struct check *c, struct dt_info *dti, struct
node *node)
{
@@ -1057,10 +1058,13 @@ static void check_i2c_bus_reg(struct check *c, struct
dt_info *dti, struct node
reg = fdt32_to_cpu(*(cells++));
/* Ignore I2C_OWN_SLAVE_ADDRESS */
reg &= ~I2C_OWN_SLAVE_ADDRESS;
- if (reg > 0x3ff)
+
+ if ((reg & I2C_TEN_BIT_ADDRESS) && ((reg &
~I2C_TEN_BIT_ADDRESS) > 0x3ff))
FAIL_PROP(c, dti, node, prop, "I2C address must be less
than 10-bits, got \"0x%x\"",
reg);
-
+ else if (reg > 0x7f)
+ FAIL_PROP(c, dti, node, prop, "I2C address must be less
than 7-bits, got \"0x%x\". Set I2C_TEN_BIT_ADDRESS for 10 bit addresses or fix
the property",
+ reg);
}
}
WARNING(i2c_bus_reg, check_i2c_bus_reg, NULL, _format, _bus_bridge);
--
2.27.0
[PATCH v4 1/2] checks: Remove warning for I2C_OWN_SLAVE_ADDRESS
dtc does a sanity check on reg properties that they are within the 10
bit address range for i2c slave addresses. In the case of multi-master
buses or devices that act as a slave, the binding may describe an
address that the bus will listen on as a device. Do not warn when this
flag is set.
See Documentation/devicetree/bindings/i2c/i2c.txt.
This fixes the following build warnings reported by Stephen and by Arnd:
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:126.11-130.4:
Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10:
I2C bus unit address format error, expected "4010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:128.3-30:
Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10:reg:
I2C address must be less than 10-bits, got "0x4010"
Reported-by: Stephen Rothwell
Reported-by: Arnd Bergmann
Signed-off-by: Joel Stanley
---
v2: Fix typo
v4: Add U to define
---
checks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/checks.c b/checks.c
index a8213c0e13a8..69b0156c940c 100644
--- a/checks.c
+++ b/checks.c
@@ -1022,6 +1022,8 @@ static void check_i2c_bus_bridge(struct check *c, struct
dt_info *dti, struct no
}
WARNING(i2c_bus_bridge, check_i2c_bus_bridge, NULL, _size_cells);
+#define I2C_OWN_SLAVE_ADDRESS (1U << 30)
+
static void check_i2c_bus_reg(struct check *c, struct dt_info *dti, struct
node *node)
{
struct property *prop;
@@ -1044,6 +1046,8 @@ static void check_i2c_bus_reg(struct check *c, struct
dt_info *dti, struct node
}
reg = fdt32_to_cpu(*cells);
+ /* Ignore I2C_OWN_SLAVE_ADDRESS */
+ reg &= ~I2C_OWN_SLAVE_ADDRESS;
snprintf(unit_addr, sizeof(unit_addr), "%x", reg);
if (!streq(unitname, unit_addr))
FAIL(c, dti, node, "I2C bus unit address format error, expected
\"%s\"",
@@ -1051,6 +1055,8 @@ static void check_i2c_bus_reg(struct check *c, struct
dt_info *dti, struct node
for (len = prop->val.len; len > 0; len -= 4) {
reg = fdt32_to_cpu(*(cells++));
+ /* Ignore I2C_OWN_SLAVE_ADDRESS */
+ reg &= ~I2C_OWN_SLAVE_ADDRESS;
if (reg > 0x3ff)
FAIL_PROP(c, dti, node, prop, "I2C address must be less
than 10-bits, got \"0x%x\"",
reg);
--
2.27.0
[PATCH v4 0/2] dtc: Improve checks for i2c reg properties
This is to fix a build warning in the Linux kernel caused by dtc incorrectly warning about I2C_OWN_SLAVE_ADDRESS. v4 adds a U to the defines v3 fixes the 10 bit size check v2 contains a second patch to check for 10 bit vs 7 bit addresses. Joel Stanley (2): checks: Remove warning for I2C_OWN_SLAVE_ADDRESS checks: Improve i2c reg property checking checks.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) -- 2.27.0
Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly
ping..
On 6/11/20 6:07 PM, Bob Liu wrote:
> Current code always set 'Unbound && max_active == 1' workqueues to ordered
> implicitly, while this may be not an expected behaviour for some use cases.
>
> E.g some scsi and iscsi workqueues(unbound && max_active = 1) want to be bind
> to different cpu so as to get better isolation, but their cpumask can't be
> changed because WQ_ORDERED is set implicitly.
>
> This patch adds a flag __WQ_ORDERED_DISABLE and also
> create_singlethread_workqueue_noorder() to offer an new option.
>
> Signed-off-by: Bob Liu
> ---
> include/linux/workqueue.h | 4
> kernel/workqueue.c| 4 +++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> index e48554e..4c86913 100644
> --- a/include/linux/workqueue.h
> +++ b/include/linux/workqueue.h
> @@ -344,6 +344,7 @@ enum {
> __WQ_ORDERED= 1 << 17, /* internal: workqueue is ordered */
> __WQ_LEGACY = 1 << 18, /* internal: create*_workqueue() */
> __WQ_ORDERED_EXPLICIT = 1 << 19, /* internal:
> alloc_ordered_workqueue() */
> + __WQ_ORDERED_DISABLE= 1 << 20, /* internal: don't set __WQ_ORDERED
> implicitly */
>
> WQ_MAX_ACTIVE = 512,/* I like 512, better ideas? */
> WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
> @@ -433,6 +434,9 @@ struct workqueue_struct *alloc_workqueue(const char *fmt,
> #define create_singlethread_workqueue(name) \
> alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
>
> +#define create_singlethread_workqueue_noorder(name) \
> + alloc_workqueue("%s", WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | \
> + WQ_UNBOUND | __WQ_ORDERED_DISABLE, 1, (name))
> extern void destroy_workqueue(struct workqueue_struct *wq);
>
> struct workqueue_attrs *alloc_workqueue_attrs(void);
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 4e01c44..2167013 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -4237,7 +4237,9 @@ struct workqueue_struct *alloc_workqueue(const char
> *fmt,
>* on NUMA.
>*/
> if ((flags & WQ_UNBOUND) && max_active == 1)
> - flags |= __WQ_ORDERED;
> + /* the caller may don't want __WQ_ORDERED to be set implicitly.
> */
> + if (!(flags & __WQ_ORDERED_DISABLE))
> + flags |= __WQ_ORDERED;
>
> /* see the comment above the definition of WQ_POWER_EFFICIENT */
> if ((flags & WQ_POWER_EFFICIENT) && wq_power_efficient)
>
Re: [PATCH v6 00/19] The new cgroup slab memory controller
On Sun, Jun 21, 2020 at 07:53:23PM -0400, Qian Cai wrote:
>
>
> > On Jun 21, 2020, at 7:34 PM, Roman Gushchin wrote:
> >
> > My wild guess is that kmemleak is getting confused by modifying the lowest
> > bit of page->mem_cgroup/obhj_cgroups pointer:
> >
> > struct page {
> >...
> >union {
> >struct mem_cgroup *mem_cgroup;
> >struct obj_cgroup **obj_cgroups;
> >};
> >...
> > }
> >
> > We're using the lowest bit to distinguish between a "normal" mem_cgroup
> > pointer and a vector of obj_cgroup pointers.
> >
> > This pointer to obj_cgroup vector is saved only here, so if we're modifying
> > the address, I guess it's what makes kmemleak think that there is a leak.
> >
> > Or do you have a real leak?
>
> The point is that we can’t have a patchset in the current form to totally
> render kmemleak useless with so many even false positives.
>
> Anyway, this is rather easy to reproduce where I am able to reproduce on
> multiple bare-metal machines by just booting it.
>
> # echo scan > /sys/kernel/debug/kmemleak
> # cat /sys/kernel/debug/kmemleak
Ok, thank you for the report, I'll take care of it.
It's easy to mark these vectors to be ignored by kmemleak, but I guess it's
better
to explicitly add an additional reference, so we can track actual leaks.
I'll send a patch with fix soon-ish.
Thanks!
Re: [PATCH 0/4] small random patches
On 6/21/20 4:09 AM, Pavel Begunkov wrote: > Nothing interesting, just killing some stuff first. > Based on top of io_uring-5.8 + 15 async-buf patches. > > Pavel Begunkov (4): > io_uring: remove setting REQ_F_MUST_PUNT in rw > io_uring: remove REQ_F_MUST_PUNT > io_uring: set @poll->file after @poll init > io_uring: kill NULL checks for submit state > > fs/io_uring.c | 38 +- > 1 file changed, 9 insertions(+), 29 deletions(-) Thanks, applied. -- Jens Axboe
drivers/misc/mic/vop/vop_main.c:551:51: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 48778464bb7d346b47157d21ffde2af6b2d39110 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 3 days ago config: sh-randconfig-s032-20200622 (attached as .config) compiler: sh4-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-rc2-13-gc59158c8-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree make W=1 C=1 ARCH=sh CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/misc/mic/vop/vop_main.c:551:51: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void const volatile >> [noderef] __iomem * @@ got restricted __le64 * @@ >> drivers/misc/mic/vop/vop_main.c:551:51: sparse: expected void const >> volatile [noderef] __iomem * drivers/misc/mic/vop/vop_main.c:551:51: sparse: got restricted __le64 * drivers/misc/mic/vop/vop_main.c:560:49: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct mic_device_ctrl *dc @@ got struct mic_device_ctrl [noderef] __iomem *dc @@ drivers/misc/mic/vop/vop_main.c:560:49: sparse: expected struct mic_device_ctrl *dc drivers/misc/mic/vop/vop_main.c:560:49: sparse: got struct mic_device_ctrl [noderef] __iomem *dc drivers/misc/mic/vop/vop_main.c:579:49: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct mic_device_ctrl *dc @@ got struct mic_device_ctrl [noderef] __iomem *dc @@ drivers/misc/mic/vop/vop_main.c:579:49: sparse: expected struct mic_device_ctrl *dc drivers/misc/mic/vop/vop_main.c:579:49: sparse: got struct mic_device_ctrl [noderef] __iomem *dc -- drivers/input/joydev.c:528:24: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected signed int const *__gu_addr @@ got signed int [noderef] [usertype] __user * @@ drivers/input/joydev.c:528:24: sparse: expected signed int const *__gu_addr drivers/input/joydev.c:528:24: sparse: got signed int [noderef] [usertype] __user * >> drivers/input/joydev.c:528:24: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __user * @@ got signed int const *__gu_addr @@ >> drivers/input/joydev.c:528:24: sparse: expected void const volatile >> [noderef] __user * drivers/input/joydev.c:528:24: sparse: got signed int const *__gu_addr drivers/input/joydev.c:680:26: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected long const *__gu_addr @@ got long [noderef] __user * @@ drivers/input/joydev.c:680:26: sparse: expected long const *__gu_addr drivers/input/joydev.c:680:26: sparse: got long [noderef] __user * >> drivers/input/joydev.c:680:26: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __user * @@ got long const *__gu_addr @@ drivers/input/joydev.c:680:26: sparse: expected void const volatile [noderef] __user * drivers/input/joydev.c:680:26: sparse: got long const *__gu_addr -- drivers/hid/hidraw.c:389:37: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected int const *__gu_addr @@ got int [noderef] __user * @@ drivers/hid/hidraw.c:389:37: sparse: expected int const *__gu_addr drivers/hid/hidraw.c:389:37: sparse: got int [noderef] __user * >> drivers/hid/hidraw.c:389:37: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __user * @@ got int const *__gu_addr @@ >> drivers/hid/hidraw.c:389:37: sparse: expected void const volatile >> [noderef] __user * drivers/hid/hidraw.c:389:37: sparse: got int const *__gu_addr -- >> drivers/vhost/vringh.c:567:18: sparse: sparse: incorrect type in initializer >> (different address spaces) @@ expected restricted __virtio16 const >> *__gu_addr @@ got restricted __virtio16 [noderef] [usertype] __user * @@ drivers/vhost/vringh.c:567:18: sparse: expected restricted __virtio16 const *__gu_addr >> drivers/vhost/vringh.c:567:18: sparse: got restricted __virtio16 >> [noderef] [usertype] __user * >> drivers/vhost/vringh.c:567:18: sparse: sparse: incorrect type in argument 1 >> (different address spaces) @@ expected void const volatile [noderef] >> __user * @@ got restricted __virtio16 const *__gu_addr @@ >> drivers/vhost/vringh.c:567:18: sparse: expected void const volatile >> [noderef] __user * drivers/vhost/vringh.c:567:18: sparse: got
[PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"
This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809. This commit broke userspace. Bash uses ESPIPE to determine whether or not the file should be read using "unbuffered I/O", which means reading 1 byte at a time instead of 128 bytes at a time. I used to use bash to read through kmsg in a really quite nasty way: while read -t 0.1 -r line 2>/dev/null || [[ $? -ne 142 ]]; do echo "SARU $line" done < /dev/kmsg This will show all lines that can fit into the 128 byte buffer, and skip lines that don't. That's pretty awful, but at least it worked. With this change, bash now tries to do 1-byte reads, which means it skips all the lines, which is worse than before. Now, I don't really care very much about this, and I'm already look for a workaround. But I did just spend an hour trying to figure out why my scripts were broken. Either way, it makes no difference to me personally whether this is reverted, but it might be something to consider. If you declare that "trying to read /dev/kmsg with bash is terminally stupid anyway," I might be inclined to agree with you. But do note that bash uses lseek(fd, 0, SEEK_CUR)==>ESPIPE to determine whether or not it's reading from a pipe. Cc: Bruno Meneguele Cc: pmla...@suse.com Cc: sergey.senozhat...@gmail.com Cc: rost...@goodmis.org Cc: david.lai...@aculab.com Cc: Linus Torvalds Cc: Sergey Senozhatsky Cc: Petr Mladek Signed-off-by: Jason A. Donenfeld --- Documentation/ABI/testing/dev-kmsg | 5 - kernel/printk/printk.c | 10 -- 2 files changed, 15 deletions(-) diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index 1e6c28b1942b..f307506eb54c 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg @@ -56,11 +56,6 @@ Description: The /dev/kmsg character device node provides userspace access seek after the last record available at the time the last SYSLOG_ACTION_CLEAR was issued. - Due to the record nature of this interface with a "read all" - behavior and the specific positions each seek operation sets, - SEEK_CUR is not supported, returning -ESPIPE (invalid seek) to - errno whenever requested. - The output format consists of a prefix carrying the syslog prefix including priority and facility, the 64 bit message sequence number and the monotonic timestamp in microseconds, diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 8c14835be46c..b71eaf5f5a86 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -974,16 +974,6 @@ static loff_t devkmsg_llseek(struct file *file, loff_t offset, int whence) user->idx = log_next_idx; user->seq = log_next_seq; break; - case SEEK_CUR: - /* -* It isn't supported due to the record nature of this -* interface: _SET _DATA and _END point to very specific -* record positions, while _CUR would be more useful in case -* of a byte-based log. Because of that, return the default -* errno value for invalid seek operation. -*/ - ret = -ESPIPE; - break; default: ret = -EINVAL; } -- 2.27.0
[PATCH v2 04/11] pinctrl: sunxi: add support for the Allwinner A100 pin controller
This commit introduces support for the pin controller on A100.
Signed-off-by: Frank Lee
---
drivers/pinctrl/sunxi/Kconfig | 10 +
drivers/pinctrl/sunxi/Makefile| 2 +
drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105
drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 708 ++
4 files changed, 825 insertions(+)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f7aae20..5932935 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -94,6 +94,16 @@ config PINCTRL_SUN50I_A64_R
default ARM64 && ARCH_SUNXI
select PINCTRL_SUNXI
+config PINCTRL_SUN50I_A100
+ bool "Support for the Allwinner A100 PIO"
+ default ARM64 && ARCH_SUNXI
+ select PINCTRL_SUNXI
+
+config PINCTRL_SUN50I_A100_R
+ bool "Support for the Allwinner A100 R-PIO"
+ default ARM64 && ARCH_SUNXI
+ select PINCTRL_SUNXI
+
config PINCTRL_SUN50I_H5
bool "Support for the Allwinner H5 PIO"
default ARM64 && ARCH_SUNXI
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index fafcdae..8b7ff0d 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
obj-$(CONFIG_PINCTRL_SUN50I_A64_R) += pinctrl-sun50i-a64-r.o
+obj-$(CONFIG_PINCTRL_SUN50I_A100) += pinctrl-sun50i-a100.o
+obj-$(CONFIG_PINCTRL_SUN50I_A100_R)+= pinctrl-sun50i-a100-r.o
obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
obj-$(CONFIG_PINCTRL_SUN8I_A83T_R) += pinctrl-sun8i-a83t-r.o
obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
new file mode 100644
index 000..6e4a96c
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Frank Lee
+ *
+ * Based on:
+ * huangshuosheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin a100_r_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_i2c0"),/* SCK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_i2c0"),/* SDA */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart0"), /* TX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart0"), /* RX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_jtag"),/* MS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_jtag"),/* CK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_jtag"),/* DO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_jtag"),/* DI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_i2c1"),/* SCK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1,
[PATCH v2 05/11] dt-bindings: nvmem: SID: add binding for A100's SID controller
Add a binding for A100's SID controller. Signed-off-by: Frank Lee --- Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml index daf1321..c1a0b32 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -21,6 +21,7 @@ properties: - allwinner,sun8i-a83t-sid - allwinner,sun8i-h3-sid - allwinner,sun50i-a64-sid + - allwinner,sun50i-a100-sid - allwinner,sun50i-h5-sid - allwinner,sun50i-h6-sid -- 1.9.1
[PATCH v2 11/11] arm64: allwinner: A100: add support for Allwinner Perf1 board
A100 perf1 is an Allwinner A100-based SBC, with the following features:
- 1GiB DDR3 DRAM
- AXP803 PMIC
- 2 USB 2.0 ports
- MicroSD slot and on-board eMMC module
- on-board Nand flash
- ···
Adds initial support for it, including the UART.
Signed-off-by: Frank Lee
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-a100-allwinner-perf1.dts | 27 ++
2 files changed, 28 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index e4d3cd0..ab780db 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-emlid-neutis-n5-devboard.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
new file mode 100644
index 000..d03fa26
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (c) 2020 Frank Lee
+ */
+
+/dts-v1/;
+
+#include "sun50i-a100.dtsi"
+
+/{
+ model = "Allwinner A100 Perf1";
+ compatible = "allwinner,a100-perf1", "allwinner,sun50i-a100";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pb_pins>;
+ status = "okay";
+};
--
1.9.1
[PATCH v2 10/11] dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings
Document board compatible names for Allwinner A100 Perf1 Board. Signed-off-by: Frank Lee --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index abf2d97..8cdc677 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -16,6 +16,11 @@ properties: compatible: oneOf: + - description: Allwinner A100 Perf1 Board +items: + - const: allwinner,a100-perf1 + - const: allwinner,sun50i-a100 + - description: Allwinner A23 Evaluation Board items: - const: allwinner,sun8i-a23-evb -- 1.9.1
[PATCH v2 08/11] thermal: sun8i: Add A100's THS controller support
This patch add thermal sensor controller support for A100,
which is similar to the previous ones.
Signed-off-by: Frank Lee
Signed-off-by: Yangtao Li
---
drivers/thermal/sun8i_thermal.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
index 74d73be..7a69442 100644
--- a/drivers/thermal/sun8i_thermal.c
+++ b/drivers/thermal/sun8i_thermal.c
@@ -590,6 +590,19 @@ static int sun8i_ths_remove(struct platform_device *pdev)
.calc_temp = sun8i_ths_calc_temp,
};
+static const struct ths_thermal_chip sun50i_a100_ths = {
+ .sensor_num = 3,
+ .has_bus_clk_reset = true,
+ .ft_deviation = 8000,
+ .offset = 187744,
+ .scale = 672,
+ .temp_data_base = SUN50I_H6_THS_TEMP_DATA,
+ .calibrate = sun50i_h6_ths_calibrate,
+ .init = sun50i_h6_thermal_init,
+ .irq_ack = sun50i_h6_irq_ack,
+ .calc_temp = sun8i_ths_calc_temp,
+};
+
static const struct ths_thermal_chip sun50i_h5_ths = {
.sensor_num = 2,
.has_mod_clk = true,
@@ -619,6 +632,7 @@ static int sun8i_ths_remove(struct platform_device *pdev)
{ .compatible = "allwinner,sun8i-h3-ths", .data = _h3_ths },
{ .compatible = "allwinner,sun8i-r40-ths", .data = _r40_ths },
{ .compatible = "allwinner,sun50i-a64-ths", .data = _a64_ths },
+ { .compatible = "allwinner,sun50i-a100-ths", .data = _a100_ths },
{ .compatible = "allwinner,sun50i-h5-ths", .data = _h5_ths },
{ .compatible = "allwinner,sun50i-h6-ths", .data = _h6_ths },
{ /* sentinel */ },
--
1.9.1
[PATCH v2 07/11] dt-bindings: thermal: sun8i: Add binding for A100's THS controller
Add a binding for A100's ths controller. Signed-off-by: Frank Lee Signed-off-by: Yangtao Li --- .../devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index 8736926..9d40fc7 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -17,6 +17,7 @@ properties: - allwinner,sun8i-h3-ths - allwinner,sun8i-r40-ths - allwinner,sun50i-a64-ths + - allwinner,sun50i-a100-ths - allwinner,sun50i-h5-ths - allwinner,sun50i-h6-ths @@ -61,7 +62,9 @@ allOf: properties: compatible: contains: -const: allwinner,sun50i-h6-ths +enum: + - allwinner,sun50i-a100-ths + - allwinner,sun50i-h6-ths then: properties: @@ -103,6 +106,7 @@ allOf: - const: allwinner,sun8i-h3-ths - const: allwinner,sun8i-r40-ths - const: allwinner,sun50i-a64-ths + - const: allwinner,sun50i-a100-ths - const: allwinner,sun50i-h5-ths - const: allwinner,sun50i-h6-ths -- 1.9.1
[PATCH v2 01/11] dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and R-CCU
This patch adds binding to a100's ccu clock and r-ccu clock. Signed-off-by: Frank Lee --- .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index 4d38212..3b45344 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -36,6 +36,8 @@ properties: - allwinner,sun9i-a80-ccu - allwinner,sun50i-a64-ccu - allwinner,sun50i-a64-r-ccu + - allwinner,sun50i-a100-ccu + - allwinner,sun50i-a100-r-ccu - allwinner,sun50i-h5-ccu - allwinner,sun50i-h6-ccu - allwinner,sun50i-h6-r-ccu @@ -78,6 +80,7 @@ if: - allwinner,sun8i-a83t-r-ccu - allwinner,sun8i-h3-r-ccu - allwinner,sun50i-a64-r-ccu +- allwinner,sun50i-a100-r-ccu - allwinner,sun50i-h6-r-ccu then: @@ -94,7 +97,9 @@ else: if: properties: compatible: -const: allwinner,sun50i-h6-ccu +enum: + - allwinner,sun50i-a100-ccu + - allwinner,sun50i-h6-ccu then: properties: -- 1.9.1
[PATCH v2 03/11] dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings
Add device tree binding Documentation details for A100 pinctrl driver, whic has an r pin controller and a pin controller with more irq lines. Signed-off-by: Frank Lee --- .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 72 +- 1 file changed, 43 insertions(+), 29 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index bfefd09..2ac5eb5 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -48,6 +48,8 @@ properties: - allwinner,sun9i-a80-r-pinctrl - allwinner,sun50i-a64-pinctrl - allwinner,sun50i-a64-r-pinctrl + - allwinner,sun50i-a100-pinctrl + - allwinner,sun50i-a100-r-pinctrl - allwinner,sun50i-h5-pinctrl - allwinner,sun50i-h6-pinctrl - allwinner,sun50i-h6-r-pinctrl @@ -144,75 +146,87 @@ allOf: # FIXME: We should have the pin bank supplies here, but not a lot of # boards are defining it at the moment so it would generate a lot of # warnings. - - if: properties: compatible: enum: -- allwinner,sun9i-a80-pinctrl +- allwinner,sun50i-a100-pinctrl then: properties: interrupts: - minItems: 5 - maxItems: 5 + minItems: 7 + maxItems: 7 else: if: properties: compatible: enum: - - allwinner,sun6i-a31-pinctrl - - allwinner,sun6i-a31s-pinctrl - - allwinner,sun50i-h6-pinctrl + - allwinner,sun9i-a80-pinctrl then: properties: interrupts: -minItems: 4 -maxItems: 4 +minItems: 5 +maxItems: 5 else: if: properties: compatible: enum: -- allwinner,sun8i-a23-pinctrl -- allwinner,sun8i-a83t-pinctrl -- allwinner,sun50i-a64-pinctrl -- allwinner,sun50i-h5-pinctrl -- allwinner,suniv-f1c100s-pinctrl +- allwinner,sun6i-a31-pinctrl +- allwinner,sun6i-a31s-pinctrl +- allwinner,sun50i-h6-pinctrl then: properties: interrupts: - minItems: 3 - maxItems: 3 + minItems: 4 + maxItems: 4 else: if: properties: compatible: enum: - - allwinner,sun6i-a31-r-pinctrl - - allwinner,sun8i-a33-pinctrl - - allwinner,sun8i-h3-pinctrl - - allwinner,sun8i-v3-pinctrl - - allwinner,sun8i-v3s-pinctrl - - allwinner,sun9i-a80-r-pinctrl - - allwinner,sun50i-h6-r-pinctrl + - allwinner,sun8i-a23-pinctrl + - allwinner,sun8i-a83t-pinctrl + - allwinner,sun50i-a64-pinctrl + - allwinner,sun50i-h5-pinctrl + - allwinner,suniv-f1c100s-pinctrl then: properties: interrupts: -minItems: 2 -maxItems: 2 +minItems: 3 +maxItems: 3 else: -properties: - interrupts: -minItems: 1 -maxItems: 1 +if: + properties: +compatible: + enum: +- allwinner,sun6i-a31-r-pinctrl +- allwinner,sun8i-a33-pinctrl +- allwinner,sun8i-h3-pinctrl +- allwinner,sun8i-v3-pinctrl +- allwinner,sun8i-v3s-pinctrl +- allwinner,sun9i-a80-r-pinctrl +- allwinner,sun50i-h6-r-pinctrl + +then: + properties: +interrupts: + minItems: 2 + maxItems: 2 + +else: + properties: +interrupts: + minItems: 1 + maxItems: 1 additionalProperties: false -- 1.9.1
[PATCH v2 09/11] arm64: allwinner: A100: add the basical Allwinner A100 DTSI file
Allwinner A100 is a new SoC with Cortex-A53 cores, this commit adds
the basical DTSI file of it, including the clock, i2c, pins, sid, ths,
and UART support.
Signed-off-by: Frank Lee
---
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 337 +
1 file changed, 337 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
new file mode 100644
index 000..5133897
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (c) 2020 Frank Lee
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ compatible = "arm,armv8";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ iosc: internal-osc-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1600>;
+ clock-accuracy = <3>;
+ clock-output-names = "iosc";
+ #clock-cells = <0>;
+ };
+
+ dcxo24M: dcxo24M_clk {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ clock-output-names = "dcxo24M";
+ #clock-cells = <0>;
+ };
+
+ osc32k: osc32k_clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "osc32k";
+ #clock-cells = <0>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ccu: clock@3001000 {
+ compatible = "allwinner,sun50i-a100-ccu";
+ reg = <0x0 0x03001000 0x0 0x1000>;
+ clocks = <>, <>, <>;
+ clock-names = "hosc", "losc", "iosc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ gic: interrupt-controller@3021000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0x03021000 0x0 0x1000>,
+ <0x0 0x03022000 0x0 0x2000>,
+ <0x0 0x03024000 0x0 0x2000>,
+ <0x0 0x03026000 0x0 0x2000>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ sid@3006000 {
+ compatible = "allwinner,sun50i-a100-sid";
+ reg = <0x0 0x03006000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ths_calibration: calib@14 {
+ reg = <0x14 8>;
+ };
+ };
+
+ pio: pinctrl@300b000 {
+ compatible = "allwinner,sun50i-a100-pinctrl";
+ reg = <0x0 0x0300b000 0x0 0x400>;
+ interrupts = ,
+,
+,
+,
+,
+,
+;
+ clocks = < CLK_APB1>, <>, <>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+
[PATCH v2 02/11] clk: sunxi-ng: add support for the Allwinner A100 CCU
Add support for a100 in the sunxi-ng CCU framework.
Signed-off-by: Frank Lee
---
drivers/clk/sunxi-ng/Kconfig | 10 +
drivers/clk/sunxi-ng/Makefile |2 +
drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c | 214 +
drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h | 21 +
drivers/clk/sunxi-ng/ccu-sun50i-a100.c| 1261 +
drivers/clk/sunxi-ng/ccu-sun50i-a100.h| 56 ++
include/dt-bindings/clock/sun50i-a100-ccu.h | 116 +++
include/dt-bindings/clock/sun50i-a100-r-ccu.h | 23 +
include/dt-bindings/reset/sun50i-a100-ccu.h | 68 ++
include/dt-bindings/reset/sun50i-a100-r-ccu.h | 18 +
10 files changed, 1789 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.h
create mode 100644 include/dt-bindings/clock/sun50i-a100-ccu.h
create mode 100644 include/dt-bindings/clock/sun50i-a100-r-ccu.h
create mode 100644 include/dt-bindings/reset/sun50i-a100-ccu.h
create mode 100644 include/dt-bindings/reset/sun50i-a100-r-ccu.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index cdf3330..ce5f584 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -17,6 +17,16 @@ config SUN50I_A64_CCU
default ARM64 && ARCH_SUNXI
depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
+config SUN50I_A100_CCU
+ bool "Support for the Allwinner A100 CCU"
+ default ARM64 && ARCH_SUNXI
+ depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
+
+config SUN50I_A100_R_CCU
+ bool "Support for the Allwinner A100 PRCM CCU"
+ default ARM64 && ARCH_SUNXI
+ depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
+
config SUN50I_H6_CCU
bool "Support for the Allwinner H6 CCU"
default ARM64 && ARCH_SUNXI
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 4c7bee8..3eb5cff 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,6 +23,8 @@ obj-y += ccu_mp.o
# SoC support
obj-$(CONFIG_SUNIV_F1C100S_CCU)+= ccu-suniv-f1c100s.o
obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
+obj-$(CONFIG_SUN50I_A100_CCU) += ccu-sun50i-a100.o
+obj-$(CONFIG_SUN50I_A100_R_CCU)+= ccu-sun50i-a100-r.o
obj-$(CONFIG_SUN50I_H6_CCU)+= ccu-sun50i-h6.o
obj-$(CONFIG_SUN50I_H6_R_CCU) += ccu-sun50i-h6-r.o
obj-$(CONFIG_SUN4I_A10_CCU)+= ccu-sun4i-a10.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
new file mode 100644
index 000..d6dbd355
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Frank Lee
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_nm.h"
+
+#include "ccu-sun50i-a100-r.h"
+
+static const char * const cpus_r_apb2_parents[] = { "dcxo24M", "osc32k",
+"iosc", "pll-periph0" };
+static const struct ccu_mux_var_prediv cpus_r_apb2_predivs[] = {
+ { .index = 3, .shift = 0, .width = 5 },
+};
+
+static struct ccu_div r_cpus_clk = {
+ .div= _SUNXI_CCU_DIV_FLAGS(8, 2, CLK_DIVIDER_POWER_OF_TWO),
+
+ .mux= {
+ .shift = 24,
+ .width = 2,
+
+ .var_predivs= cpus_r_apb2_predivs,
+ .n_var_predivs = ARRAY_SIZE(cpus_r_apb2_predivs),
+ },
+
+ .common = {
+ .reg= 0x000,
+ .features = CCU_FEATURE_VARIABLE_PREDIV,
+ .hw.init= CLK_HW_INIT_PARENTS("cpus",
+ cpus_r_apb2_parents,
+ _div_ops,
+ 0),
+ },
+};
+
+static CLK_FIXED_FACTOR_HW(r_ahb_clk, "r-ahb", _cpus_clk.common.hw, 1, 1, 0);
+
+static struct ccu_div r_apb1_clk = {
+ .div= _SUNXI_CCU_DIV(0, 2),
+
+ .common = {
+ .reg= 0x00c,
+ .hw.init= CLK_HW_INIT("r-apb1",
+ "r-ahb",
+ _div_ops,
+ 0),
+ },
+};
+
+static struct ccu_div r_apb2_clk = {
+ .div= _SUNXI_CCU_DIV_FLAGS(8, 2, CLK_DIVIDER_POWER_OF_TWO),
+
+ .mux= {
+ .shift = 24,
+ .width = 2,
+
+ .var_predivs= cpus_r_apb2_predivs,
+ .n_var_predivs = ARRAY_SIZE(cpus_r_apb2_predivs),
+ },
+
+ .common
[PATCH v2 00/11] Allwinner A100 Initial support
From: frank This patch set adds initial support for allwinner a100 soc, which is a 64-bit tablet chip. v2: -Some naming consistency -Repair email address -Fix mmc clock -Don't export system clock -Fix checkpatch warning -Drop unneeded pin function, convert to jtag_gpu and i2s_x Frank Lee (11): dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and R-CCU clk: sunxi-ng: add support for the Allwinner A100 CCU dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings pinctrl: sunxi: add support for the Allwinner A100 pin controller dt-bindings: nvmem: SID: add binding for A100's SID controller nvmem: sunxi-sid: add support for A100's SID controller dt-bindings: thermal: sun8i: Add binding for A100's THS controller thermal: sun8i: Add A100's THS controller support arm64: allwinner: A100: add the basical Allwinner A100 DTSI file dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings arm64: allwinner: A100: add support for Allwinner Perf1 board Documentation/devicetree/bindings/arm/sunxi.yaml |5 + .../bindings/clock/allwinner,sun4i-a10-ccu.yaml|7 +- .../bindings/nvmem/allwinner,sun4i-a10-sid.yaml|1 + .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 72 +- .../bindings/thermal/allwinner,sun8i-a83t-ths.yaml |6 +- arch/arm64/boot/dts/allwinner/Makefile |1 + .../dts/allwinner/sun50i-a100-allwinner-perf1.dts | 27 + arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 337 ++ drivers/clk/sunxi-ng/Kconfig | 10 + drivers/clk/sunxi-ng/Makefile |2 + drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c | 214 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h | 21 + drivers/clk/sunxi-ng/ccu-sun50i-a100.c | 1261 drivers/clk/sunxi-ng/ccu-sun50i-a100.h | 56 + drivers/nvmem/sunxi_sid.c |6 + drivers/pinctrl/sunxi/Kconfig | 10 + drivers/pinctrl/sunxi/Makefile |2 + drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 ++ drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c| 708 +++ drivers/thermal/sun8i_thermal.c| 14 + include/dt-bindings/clock/sun50i-a100-ccu.h| 116 ++ include/dt-bindings/clock/sun50i-a100-r-ccu.h | 23 + include/dt-bindings/reset/sun50i-a100-ccu.h| 68 ++ include/dt-bindings/reset/sun50i-a100-r-ccu.h | 18 + 24 files changed, 3059 insertions(+), 31 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100-r.h create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a100.h create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c create mode 100644 include/dt-bindings/clock/sun50i-a100-ccu.h create mode 100644 include/dt-bindings/clock/sun50i-a100-r-ccu.h create mode 100644 include/dt-bindings/reset/sun50i-a100-ccu.h create mode 100644 include/dt-bindings/reset/sun50i-a100-r-ccu.h -- 1.9.1
[PATCH v2 06/11] nvmem: sunxi-sid: add support for A100's SID controller
Add support for A100's SID controller.
Signed-off-by: Frank Lee
---
drivers/nvmem/sunxi_sid.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index e26ef1b..8ac074b 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -189,6 +189,11 @@ static int sunxi_sid_probe(struct platform_device *pdev)
.need_register_readout = true,
};
+static const struct sunxi_sid_cfg sun50i_a100_cfg = {
+ .value_offset = 0x200,
+ .size = 0x100,
+};
+
static const struct sunxi_sid_cfg sun50i_h6_cfg = {
.value_offset = 0x200,
.size = 0x200,
@@ -200,6 +205,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
{ .compatible = "allwinner,sun8i-a83t-sid", .data = _a64_cfg },
{ .compatible = "allwinner,sun8i-h3-sid", .data = _h3_cfg },
{ .compatible = "allwinner,sun50i-a64-sid", .data = _a64_cfg },
+ { .compatible = "allwinner,sun50i-a100-sid", .data = _a100_cfg },
{ .compatible = "allwinner,sun50i-h5-sid", .data = _a64_cfg },
{ .compatible = "allwinner,sun50i-h6-sid", .data = _h6_cfg },
{/* sentinel */},
--
1.9.1
[PATCH 0/3] crypto: allow users to specify acomp hardware from a desired NUMA node
For a typical Linux server, probably there are several hardware modules. For example, numa node0 has a compressor, numa node2 has a same module. Some drivers are automatically using the module near the CPU calling acomp_alloc. But it isn't necessarily correct. Just like memory allocation API like kmalloc and kmalloc_node. Similar optimization may be done for crypto. Barry Song (3): crypto: permit users to specify numa node of acomp hardware crypto: hisilicon/zip - permit users to specify NUMA node mm/zswap: specify the NUMA node of acomp to use local compressors [mm/zswap patch is on top of linux-next tree] crypto/acompress.c| 8 crypto/api.c | 22 ++ crypto/internal.h | 23 +++ drivers/crypto/hisilicon/zip/zip.h| 2 +- drivers/crypto/hisilicon/zip/zip_crypto.c | 6 +++--- drivers/crypto/hisilicon/zip/zip_main.c | 5 +++-- include/crypto/acompress.h| 7 +++ include/linux/crypto.h| 3 ++- mm/zswap.c| 2 +- 9 files changed, 58 insertions(+), 20 deletions(-) -- 2.27.0
[PATCH 2/3] crypto: hisilicon/zip - permit users to specify NUMA node
If users don't specify NUMA node, the driver will use the ZIP module near
the CPU allocating acomp. Otherwise, it uses the ZIP module according to
the requirement of users.
Cc: Zhou Wang
Signed-off-by: Barry Song
---
drivers/crypto/hisilicon/zip/zip.h| 2 +-
drivers/crypto/hisilicon/zip/zip_crypto.c | 6 +++---
drivers/crypto/hisilicon/zip/zip_main.c | 5 +++--
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip.h
b/drivers/crypto/hisilicon/zip/zip.h
index f3ed4c0e5493..4484be13812b 100644
--- a/drivers/crypto/hisilicon/zip/zip.h
+++ b/drivers/crypto/hisilicon/zip/zip.h
@@ -76,7 +76,7 @@ struct hisi_zip_sqe {
u32 rsvd1[4];
};
-int zip_create_qps(struct hisi_qp **qps, int ctx_num);
+int zip_create_qps(struct hisi_qp **qps, int ctx_num, int node);
int hisi_zip_register_to_crypto(void);
void hisi_zip_unregister_from_crypto(void);
#endif
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index c73707c2e539..01fd6a78111d 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -158,13 +158,13 @@ static void hisi_zip_release_qp(struct hisi_zip_qp_ctx
*ctx)
hisi_qm_release_qp(ctx->qp);
}
-static int hisi_zip_ctx_init(struct hisi_zip_ctx *hisi_zip_ctx, u8 req_type)
+static int hisi_zip_ctx_init(struct hisi_zip_ctx *hisi_zip_ctx, u8 req_type,
int node)
{
struct hisi_qp *qps[HZIP_CTX_Q_NUM] = { NULL };
struct hisi_zip *hisi_zip;
int ret, i, j;
- ret = zip_create_qps(qps, HZIP_CTX_Q_NUM);
+ ret = zip_create_qps(qps, HZIP_CTX_Q_NUM, node);
if (ret) {
pr_err("Can not create zip qps!\n");
return -ENODEV;
@@ -379,7 +379,7 @@ static int hisi_zip_acomp_init(struct crypto_acomp *tfm)
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(>base);
int ret;
- ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name));
+ ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name),
tfm->base.node);
if (ret)
return ret;
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 2229a21ae7c8..e2845b2c963d 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -234,9 +234,10 @@ static const struct pci_device_id hisi_zip_dev_ids[] = {
};
MODULE_DEVICE_TABLE(pci, hisi_zip_dev_ids);
-int zip_create_qps(struct hisi_qp **qps, int qp_num)
+int zip_create_qps(struct hisi_qp **qps, int qp_num, int node)
{
- int node = cpu_to_node(smp_processor_id());
+ if (node == NUMA_NO_NODE)
+ node = cpu_to_node(smp_processor_id());
return hisi_qm_alloc_qps_node(_devices, qp_num, 0, node, qps);
}
--
2.27.0
[PATCH 1/3] crypto: permit users to specify numa node of acomp hardware
For a Linux server with NUMA, there are possibly multiple (de)compressors
which are either local or remote to some NUMA node. Some drivers will
automatically use the (de)compressor near the CPU calling acomp_alloc().
However, it is not necessarily correct because users who send acomp_req
could be from different NUMA node with the CPU which allocates acomp.
Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
same support.
Cc: Seth Jennings
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: Andrew Morton
Signed-off-by: Barry Song
---
crypto/acompress.c | 8
crypto/api.c | 22 ++
crypto/internal.h | 23 +++
include/crypto/acompress.h | 7 +++
include/linux/crypto.h | 3 ++-
5 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/crypto/acompress.c b/crypto/acompress.c
index 84a76723e851..c32c72048a1c 100644
--- a/crypto/acompress.c
+++ b/crypto/acompress.c
@@ -109,6 +109,14 @@ struct crypto_acomp *crypto_alloc_acomp(const char
*alg_name, u32 type,
}
EXPORT_SYMBOL_GPL(crypto_alloc_acomp);
+struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name, u32 type,
+ u32 mask, int node)
+{
+ return crypto_alloc_tfm_node(alg_name, _acomp_type, type, mask,
+ node);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node);
+
struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp)
{
struct crypto_tfm *tfm = crypto_acomp_tfm(acomp);
diff --git a/crypto/api.c b/crypto/api.c
index edcf690800d4..4ecf712286af 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -433,8 +433,9 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name,
u32 type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alloc_base);
-void *crypto_create_tfm(struct crypto_alg *alg,
- const struct crypto_type *frontend)
+void *crypto_create_tfm_node(struct crypto_alg *alg,
+ const struct crypto_type *frontend,
+ int node)
{
char *mem;
struct crypto_tfm *tfm = NULL;
@@ -451,6 +452,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
tfm = (struct crypto_tfm *)(mem + tfmsize);
tfm->__crt_alg = alg;
+ tfm->node = node;
err = frontend->init_tfm(tfm);
if (err)
@@ -472,7 +474,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
out:
return mem;
}
-EXPORT_SYMBOL_GPL(crypto_create_tfm);
+EXPORT_SYMBOL_GPL(crypto_create_tfm_node);
struct crypto_alg *crypto_find_alg(const char *alg_name,
const struct crypto_type *frontend,
@@ -490,11 +492,13 @@ struct crypto_alg *crypto_find_alg(const char *alg_name,
EXPORT_SYMBOL_GPL(crypto_find_alg);
/*
- * crypto_alloc_tfm - Locate algorithm and allocate transform
+ * crypto_alloc_tfm_node - Locate algorithm and allocate transform
* @alg_name: Name of algorithm
* @frontend: Frontend algorithm type
* @type: Type of algorithm
* @mask: Mask for type comparison
+ * @node: NUMA node in which users desire to put requests, if node is
+ * NUMA_NO_NODE, it means users have no special requirement.
*
* crypto_alloc_tfm() will first attempt to locate an already loaded
* algorithm. If that fails and the kernel supports dynamically loadable
@@ -509,8 +513,10 @@ EXPORT_SYMBOL_GPL(crypto_find_alg);
*
* In case of error the return value is an error pointer.
*/
-void *crypto_alloc_tfm(const char *alg_name,
- const struct crypto_type *frontend, u32 type, u32 mask)
+
+void *crypto_alloc_tfm_node(const char *alg_name,
+ const struct crypto_type *frontend, u32 type, u32 mask,
+ int node)
{
void *tfm;
int err;
@@ -524,7 +530,7 @@ void *crypto_alloc_tfm(const char *alg_name,
goto err;
}
- tfm = crypto_create_tfm(alg, frontend);
+ tfm = crypto_create_tfm_node(alg, frontend, node);
if (!IS_ERR(tfm))
return tfm;
@@ -542,7 +548,7 @@ void *crypto_alloc_tfm(const char *alg_name,
return ERR_PTR(err);
}
-EXPORT_SYMBOL_GPL(crypto_alloc_tfm);
+EXPORT_SYMBOL_GPL(crypto_alloc_tfm_node);
/*
* crypto_destroy_tfm - Free crypto transform
diff --git a/crypto/internal.h b/crypto/internal.h
index ff06a3bd1ca1..1b92a5a61852 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -68,13 +68,28 @@ void crypto_remove_final(struct list_head *list);
void crypto_shoot_alg(struct crypto_alg *alg);
struct crypto_tfm *__crypto_alloc_tfm(struct crypto_alg *alg, u32 type,
u32 mask);
-void *crypto_create_tfm(struct crypto_alg *alg,
- const struct crypto_type *frontend);
+void *crypto_create_tfm_node(struct crypto_alg *alg,
+ const struct crypto_type
[PATCH 3/3] mm/zswap: specify the NUMA node of acomp to use local compressors
zswap_cpu_comp_prepare() is called on a different CPU with the CPU which
will really send acomp_req. In order to use the right local compressors,
this patch specifies the NUMA node to which the CPU sending acomp_req
belongs.
Cc: Seth Jennings
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: Herbert Xu
Cc: David S. Miller"
Cc: Andrew Morton
Signed-off-by: Barry Song
---
mm/zswap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 0d914ba6b4a0..9b1aa477022e 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -437,7 +437,7 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct
hlist_node *node)
pr_err("Could not initialize acomp_ctx\n");
return -ENOMEM;
}
- acomp = crypto_alloc_acomp(pool->tfm_name, 0, 0);
+ acomp = crypto_alloc_acomp_node(pool->tfm_name, 0, 0, cpu_to_node(cpu));
if (IS_ERR_OR_NULL(acomp)) {
pr_err("could not alloc crypto acomp %s : %ld\n",
pool->tfm_name, PTR_ERR(acomp));
--
2.27.0
RE: [PATCH 1/2 v4] exfat: write multiple sectors at once
> 2020-06-19 17:38 GMT+09:00, Tetsuhiro Kohada : > > Write multiple sectors at once when updating dir-entries. > > Add exfat_update_bhs() for that. It wait for write completion once > > instead of sector by sector. > > It's only effective if sync enabled. > > > > Reviewed-by: Christoph Hellwig > He didn't give reviewed-by tag for this patch. > You shouldn't add it at will. I understand. Should I remove reviewed-by tag and repost the patch? BR --- Kohada Tetsuhiro
Re: [PATCH v1 01/11] soc: mediatek: cmdq: add address shift in jump
Reviewed-by: Bibby Hsieh Thanks. On Sun, 2020-06-21 at 22:18 +0800, Dennis YC Hsieh wrote: > Add address shift when compose jump instruction > to compatible with 35bit format. > > Signed-off-by: Dennis YC Hsieh > --- > drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c > b/drivers/soc/mediatek/mtk-cmdq-helper.c > index c67081759728..98f23ba3ba47 100644 > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c > @@ -291,7 +291,8 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt) > > /* JUMP to end */ > inst.op = CMDQ_CODE_JUMP; > - inst.value = CMDQ_JUMP_PASS; > + inst.value = CMDQ_JUMP_PASS >> > + cmdq_mbox_shift(((struct cmdq_client *)pkt->cl)->chan); > err = cmdq_pkt_append_command(pkt, inst); > > return err;
[PATCH] crypto: sun8i-ce - Fix runtime PM imbalance in sun8i_ce_cipher_init
pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a corresponding decrement is needed on the error handling path to keep the counter balanced. Fix this by adding the missed function call. Signed-off-by: Dinghao Liu --- drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c index a6abb701bfc6..3665a0a2038f 100644 --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c @@ -358,6 +358,7 @@ int sun8i_ce_cipher_init(struct crypto_tfm *tfm) return 0; error_pm: + pm_runtime_put_noidle(op->ce->dev); crypto_free_sync_skcipher(op->fallback_tfm); return err; } -- 2.17.1
Re: [PATCH v1 0/11] support cmdq helper function on mt6779 platform
Hi, Dennis, Please add "depends on patch: support gce on mt6779 platform" in cover letter. Thanks Bibby On Sun, 2020-06-21 at 22:18 +0800, Dennis YC Hsieh wrote: > This patch support cmdq helper function on mt6779 platform, > based on "support gce on mt6779 platform" patchset. > > > Dennis YC Hsieh (11): > soc: mediatek: cmdq: add address shift in jump > soc: mediatek: cmdq: add assign function > soc: mediatek: cmdq: add write_s function > soc: mediatek: cmdq: add write_s_mask function > soc: mediatek: cmdq: add read_s function > soc: mediatek: cmdq: add write_s value function > soc: mediatek: cmdq: add write_s_mask value function > soc: mediatek: cmdq: export finalize function > soc: mediatek: cmdq: add jump function > soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api > soc: mediatek: cmdq: add set event function > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +- > drivers/soc/mediatek/mtk-cmdq-helper.c | 159 +-- > include/linux/mailbox/mtk-cmdq-mailbox.h | 8 +- > include/linux/soc/mediatek/mtk-cmdq.h| 124 +- > 4 files changed, 280 insertions(+), 14 deletions(-) >
Re: [GIT PULL] libnvdimm for v5.8-rc2
Dan Williams writes: > Hi Linus, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-for-5.8-rc2 > > ...to receive a feature (papr_scm health retrieval) and a fix (sysfs > attribute visibility) for v5.8. > > Vaibhav explains in the merge commit below why missing v5.8 would be > painful and I agreed to try a -rc2 pull because only cosmetics kept > this out of -rc1 and his initial versions were posted in more than > enough time for v5.8 consideration. > > === > These patches are tied to specific features that were committed to > customers in upcoming distros releases (RHEL and SLES) whose time-lines > are tied to 5.8 kernel release. > > Being able to track the health of an nvdimm is critical for our > customers that are running workloads leveraging papr-scm nvdimms. > Missing the 5.8 kernel would mean missing the distro timelines and > shifting forward the availability of this feature in distro kernels by > at least 6 months. > === > > I notice that these do not have an ack from Michael, but I had been > assuming that he was deferring this to a libnvdimm subsystem decision > ever since v7 back at the end of May where he said "I don't have > strong opinions about the user API, it's really up to the nvdimm > folks." [1] Yeah, sorry for not providing an actual ack, I didn't realise you were planning to send it for 5.8. The arch parts of that series are pretty boring plumbing of hypervisor calls, so the important details were all the libnvdimm related issues IMO. So please consider this a belated ack and thanks for getting it merged. cheers
Re: [PATCH v5 0/4] introduction of migration_version attribute for VFIO live migration
On Fri, Jun 19, 2020 at 04:40:46PM -0600, Alex Williamson wrote: > On Tue, 9 Jun 2020 20:37:31 -0400 > Yan Zhao wrote: > > > On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote: > > > > > > I tried to simplify the problem a bit, but we keep going backwards. > > > > > > If > > > > > > the requirement is that potentially any source device can migrate > > > > > > to any > > > > > > target device and we cannot provide any means other than writing an > > > > > > opaque source string into a version attribute on the target and > > > > > > evaluating the result to determine compatibility, then we're > > > > > > requiring > > > > > > userspace to do an exhaustive search to find a potential match. > > > > > > That > > > > > > sucks. > > > > > > > hi Alex and Dave, > > do you think it's good for us to put aside physical devices and mdev > > aggregation > > for the moment, and use Alex's original idea that > > > > + Userspace should regard two mdev devices compatible when ALL of below > > + conditions are met: > > + (0) The mdev devices are of the same type > > + (1) success when reading from migration_version attribute of one mdev > > device. > > + (2) success when writing migration_version string of one mdev device to > > + migration_version attribute of the other mdev device. > > I think Pandora's box is already opened, if we can't articulate how > this solution would evolve to support features that we know are coming, > why should we proceed with this approach? We've already seen interest > in breaking rule (0) in this thread, so we can't focus the solution on > mdev devices. > > Maybe the best we can do is to compare one instance of a device to > another instance of a device, without any capability to predict > compatibility prior to creating devices, in the case on mdev. The > string would need to include not only the device and vendor driver > compatibility, but also anything that has modified the state of the > device, such as creation time or post-creation time configuration. The > user is left on their own for creating a compatible device, or > filtering devices to determine which might be, or which might generate, > compatible devices. It's not much of a solution, I wonder if anyone > would even use it. > > > and what about adding another sysfs attribute for vendors to put > > recommended migration compatible device type. e.g. > > #cat > > /sys/bus/pci/devices/:00:02.0/mdev_supported_types/i915-GVTg_V5_8/migration_compatible_devices > > parent id: 8086 591d > > mdev_type: i915-GVTg_V5_8 > > > > vendors are free to define the format and conent of this > > migration_compatible_devices > > and it's even not to be a full list. > > > > before libvirt or user to do live migration, they have to read and test > > migration_version attributes of src/target devices to check migration > > compatibility. > > AFAICT, free-form, vendor defined attributes are useless to libvirt. > Vendors could already put this information in the description attribute > and have it ignored by userspace tools due to the lack of defined > format. It's also not clear what value this provides when it's > necessarily incomplete, a driver written today cannot know what future > drivers might be compatible with its migration data. Thanks, > hi Alex maybe the problem can be divided into two pieces: (1) how to create/locate two migration compatible devices. For normal users, the most common and safest way to do it is to find a exact duplication of the source device. so for mdev, it's probably to create a target mdev of the same parent pci id, mdev type and creation parameters as the source mdev; and for physical devices, it's to locate a target device of the same pci id as the source device, plus some extra constraints (e.g. the target NVMe device is configured to the same remote device as the source NVMe device; or the target QAT device is supporting equal encryption algorithm set as the source QAT device...). I think a possible solution for this piece is to let vendor drivers provide a creating/locating script to find such exact duplication of source device. Then before libvirt is about to do live migration, it can use this script to create a target vm of exactly duplicated configuration of the source vm. (2) how to identify two devices are migration compatible after they are created and even they are not exactly identical (e.g. their parent devices are of minor difference in hardware SKUs). This identification is necessary even after in step (1) when libvirt has created/located two identical devices and are about to start live migration. Also, users are free to create/configure target devices and use the read-and-test interfaces defined in this series to check if they are live migration compatible. The read and test behavior in this patch set can grant vendor drivers the freedom to decide whether to support migration between only exact identical devices or able to support migration
Re: [PATCH v7 4/4] mailbox: mediatek: cmdq: clear task in channel before shutdown
Reviewed-by: Bibby Hsieh
Thanks.
On Sun, 2020-06-21 at 21:22 +0800, Dennis YC Hsieh wrote:
> Do success callback in channel when shutdown. For those task not finish,
> callback with error code thus client has chance to cleanup or reset.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 38
>
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 9994ac9426d6..b56d340c8982 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -387,6 +387,12 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan,
> void *data)
>
> if (list_empty(>task_busy_list)) {
> WARN_ON(clk_enable(cmdq->clock) < 0);
> + /*
> + * The thread reset will clear thread related register to 0,
> + * including pc, end, priority, irq, suspend and enable. Thus
> + * set CMDQ_THR_ENABLED to CMDQ_THR_ENABLE_TASK will enable
> + * thread and make it running.
> + */
> WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
>
> writel(task->pa_base >> cmdq->shift_pa,
> @@ -450,6 +456,38 @@ static int cmdq_mbox_startup(struct mbox_chan *chan)
>
> static void cmdq_mbox_shutdown(struct mbox_chan *chan)
> {
> + struct cmdq_thread *thread = (struct cmdq_thread *)chan->con_priv;
> + struct cmdq *cmdq = dev_get_drvdata(chan->mbox->dev);
> + struct cmdq_task *task, *tmp;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>chan->lock, flags);
> + if (list_empty(>task_busy_list))
> + goto done;
> +
> + WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
> +
> + /* make sure executed tasks have success callback */
> + cmdq_thread_irq_handler(cmdq, thread);
> + if (list_empty(>task_busy_list))
> + goto done;
> +
> + list_for_each_entry_safe(task, tmp, >task_busy_list,
> + list_entry) {
> + cmdq_task_exec_done(task, CMDQ_CB_ERROR);
> + kfree(task);
> + }
> +
> + cmdq_thread_disable(cmdq, thread);
> + clk_disable(cmdq->clock);
> +done:
> + /*
> + * The thread->task_busy_list empty means thread already disable. The
> + * cmdq_mbox_send_data() always reset thread which clear disable and
> + * suspend statue when first pkt send to channel, so there is no need
> + * to do any operation here, only unlock and leave.
> + */
> + spin_unlock_irqrestore(>chan->lock, flags);
> }
>
> static const struct mbox_chan_ops cmdq_mbox_chan_ops = {
Re: [PATCH v7 3/4] mailbox: cmdq: support mt6779 gce platform definition
Reviewed-by: Bibby Hsieh
Thanks.
On Sun, 2020-06-21 at 21:22 +0800, Dennis YC Hsieh wrote:
> Add gce v4 hardware support with different thread number and shift.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> Reviewed-by: Matthias Brugger
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 4dbee9258127..9994ac9426d6 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -572,10 +572,12 @@ static int cmdq_probe(struct platform_device *pdev)
>
> static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
> static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
> +static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
>
> static const struct of_device_id cmdq_of_ids[] = {
> {.compatible = "mediatek,mt8173-gce", .data = (void *)_plat_v2},
> {.compatible = "mediatek,mt8183-gce", .data = (void *)_plat_v3},
> + {.compatible = "mediatek,mt6779-gce", .data = (void *)_plat_v4},
> {}
> };
>
Re: [PATCH v7 1/4] dt-binding: gce: add gce header file for mt6779
Reviewed-by: Bibby Hsieh Thanks. On Sun, 2020-06-21 at 21:22 +0800, Dennis YC Hsieh wrote: > Add documentation for the mt6779 gce. > > Add gce header file defined the gce hardware event, > subsys number and constant for mt6779. > > Signed-off-by: Dennis YC Hsieh > Reviewed-by: Rob Herring > Reviewed-by: CK Hu > --- > .../devicetree/bindings/mailbox/mtk-gce.txt|8 +- > include/dt-bindings/gce/mt6779-gce.h | 222 > > 2 files changed, 227 insertions(+), 3 deletions(-) > create mode 100644 include/dt-bindings/gce/mt6779-gce.h > > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > index 7b13787ab13d..82c0a83fed09 100644 > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt > @@ -9,7 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please > refer to > mailbox.txt for generic information about mailbox device-tree bindings. > > Required properties: > -- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" > +- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or > + "mediatek,mt6779-gce". > - reg: Address range of the GCE unit > - interrupts: The interrupt signal from the GCE block > - clock: Clocks according to the common clock binding > @@ -36,8 +37,9 @@ Optional properties for a client device: >start_offset: the start offset of register address that GCE can access. >size: the total size of register address that GCE can access. > > -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' > -or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, > event ids. > +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', > +'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as > +sub-system ids, thread priority, event ids. > > Example: > > diff --git a/include/dt-bindings/gce/mt6779-gce.h > b/include/dt-bindings/gce/mt6779-gce.h > new file mode 100644 > index ..06101316ace4 > --- /dev/null > +++ b/include/dt-bindings/gce/mt6779-gce.h > @@ -0,0 +1,222 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2019 MediaTek Inc. > + * Author: Dennis-YC Hsieh > + */ > + > +#ifndef _DT_BINDINGS_GCE_MT6779_H > +#define _DT_BINDINGS_GCE_MT6779_H > + > +#define CMDQ_NO_TIMEOUT 0x > + > +/* GCE HW thread priority */ > +#define CMDQ_THR_PRIO_LOWEST 0 > +#define CMDQ_THR_PRIO_1 1 > +#define CMDQ_THR_PRIO_2 2 > +#define CMDQ_THR_PRIO_3 3 > +#define CMDQ_THR_PRIO_4 4 > +#define CMDQ_THR_PRIO_5 5 > +#define CMDQ_THR_PRIO_6 6 > +#define CMDQ_THR_PRIO_HIGHEST7 > + > +/* GCE subsys table */ > +#define SUBSYS_1300 0 > +#define SUBSYS_1400 1 > +#define SUBSYS_1401 2 > +#define SUBSYS_1402 3 > +#define SUBSYS_1502 4 > +#define SUBSYS_1880 5 > +#define SUBSYS_1881 6 > +#define SUBSYS_1882 7 > +#define SUBSYS_1883 8 > +#define SUBSYS_1884 9 > +#define SUBSYS_1000 10 > +#define SUBSYS_1001 11 > +#define SUBSYS_1002 12 > +#define SUBSYS_1003 13 > +#define SUBSYS_1004 14 > +#define SUBSYS_1005 15 > +#define SUBSYS_1020 16 > +#define SUBSYS_1028 17 > +#define SUBSYS_1700 18 > +#define SUBSYS_1701 19 > +#define SUBSYS_1702 20 > +#define SUBSYS_1703 21 > +#define SUBSYS_1800 22 > +#define SUBSYS_1801 23 > +#define SUBSYS_1802 24 > +#define SUBSYS_1804 25 > +#define SUBSYS_1805 26 > +#define SUBSYS_1808 27 > +#define SUBSYS_180a 28 > +#define SUBSYS_180b 29 > +#define CMDQ_SUBSYS_OFF 32 > + > +/* GCE hardware events */ > +#define CMDQ_EVENT_DISP_RDMA0_SOF0 > +#define CMDQ_EVENT_DISP_RDMA1_SOF1 > +#define CMDQ_EVENT_MDP_RDMA0_SOF 2 > +#define CMDQ_EVENT_MDP_RDMA1_SOF 3 > +#define CMDQ_EVENT_MDP_RSZ0_SOF 4 > +#define CMDQ_EVENT_MDP_RSZ1_SOF 5 > +#define CMDQ_EVENT_MDP_TDSHP_SOF 6 > +#define CMDQ_EVENT_MDP_WROT0_SOF 7 > +#define CMDQ_EVENT_MDP_WROT1_SOF 8 > +#define CMDQ_EVENT_DISP_OVL0_SOF 9 > +#define CMDQ_EVENT_DISP_2L_OVL0_SOF 10 > +#define CMDQ_EVENT_DISP_2L_OVL1_SOF 11 > +#define CMDQ_EVENT_DISP_WDMA0_SOF12 > +#define CMDQ_EVENT_DISP_COLOR0_SOF 13 > +#define CMDQ_EVENT_DISP_CCORR0_SOF
Re: [PATCH v7 2/4] mailbox: cmdq: variablize address shift in platform
On Sun, 2020-06-21 at 21:22 +0800, Dennis YC Hsieh wrote:
> Some gce hardware shift pc and end address in register to support
> large dram addressing.
> Implement gce address shift when write or read pc and end register.
> And add shift bit in platform definition.
>
> Signed-off-by: Dennis YC Hsieh
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 61
> ++
> include/linux/mailbox/mtk-cmdq-mailbox.h |2 +
> 2 files changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 9a6ce9f5a7db..4dbee9258127 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -76,8 +76,22 @@ struct cmdq {
> struct cmdq_thread *thread;
> struct clk *clock;
> boolsuspended;
> + u8 shift_pa;
> };
>
> +struct gce_plat {
> + u32 thread_nr;
> + u8 shift;
> +};
> +
> +u8 cmdq_mbox_shift(struct mbox_chan *chan)
How about rename this function as cmdq_get_shift_pa()?
Bibby
> +{
> + struct cmdq *cmdq = container_of(chan->mbox, struct cmdq, mbox);
> +
> + return cmdq->shift_pa;
> +}
> +EXPORT_SYMBOL(cmdq_mbox_shift);
> +
> static int cmdq_thread_suspend(struct cmdq *cmdq, struct cmdq_thread *thread)
> {
> u32 status;
> @@ -183,7 +197,7 @@ static void cmdq_task_remove_wfe(struct cmdq_task *task)
> for (i = 0; i < CMDQ_NUM_CMD(task->pkt); i++)
> if (cmdq_command_is_wfe(base[i]))
> base[i] = (u64)CMDQ_JUMP_BY_OFFSET << 32 |
> - CMDQ_JUMP_PASS;
> + CMDQ_JUMP_PASS >> task->cmdq->shift_pa;
> dma_sync_single_for_device(dev, task->pa_base, task->pkt->cmd_buf_size,
> DMA_TO_DEVICE);
> }
> @@ -221,13 +235,15 @@ static void cmdq_task_handle_error(struct cmdq_task
> *task)
> {
> struct cmdq_thread *thread = task->thread;
> struct cmdq_task *next_task;
> + struct cmdq *cmdq = task->cmdq;
>
> - dev_err(task->cmdq->mbox.dev, "task 0x%p error\n", task);
> - WARN_ON(cmdq_thread_suspend(task->cmdq, thread) < 0);
> + dev_err(cmdq->mbox.dev, "task 0x%p error\n", task);
> + WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
> next_task = list_first_entry_or_null(>task_busy_list,
> struct cmdq_task, list_entry);
> if (next_task)
> - writel(next_task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
> + writel(next_task->pa_base >> cmdq->shift_pa,
> +thread->base + CMDQ_THR_CURR_ADDR);
> cmdq_thread_resume(thread);
> }
>
> @@ -257,7 +273,7 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
> else
> return;
>
> - curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR);
> + curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR) << cmdq->shift_pa;
>
> list_for_each_entry_safe(task, tmp, >task_busy_list,
>list_entry) {
> @@ -373,16 +389,20 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan,
> void *data)
> WARN_ON(clk_enable(cmdq->clock) < 0);
> WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
>
> - writel(task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
> - writel(task->pa_base + pkt->cmd_buf_size,
> + writel(task->pa_base >> cmdq->shift_pa,
> +thread->base + CMDQ_THR_CURR_ADDR);
> + writel((task->pa_base + pkt->cmd_buf_size) >> cmdq->shift_pa,
> thread->base + CMDQ_THR_END_ADDR);
> +
> writel(thread->priority, thread->base + CMDQ_THR_PRIORITY);
> writel(CMDQ_THR_IRQ_EN, thread->base + CMDQ_THR_IRQ_ENABLE);
> writel(CMDQ_THR_ENABLED, thread->base + CMDQ_THR_ENABLE_TASK);
> } else {
> WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
> - curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR);
> - end_pa = readl(thread->base + CMDQ_THR_END_ADDR);
> + curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR) <<
> + cmdq->shift_pa;
> + end_pa = readl(thread->base + CMDQ_THR_END_ADDR) <<
> + cmdq->shift_pa;
>
> /*
>* Atomic execution should remove the following wfe, i.e. only
> @@ -395,7 +415,7 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan,
> void *data)
> cmdq_thread_wait_end(thread, end_pa);
> WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
> /* set to this task directly */
> - writel(task->pa_base,
> + writel(task->pa_base >> cmdq->shift_pa,
> thread->base + CMDQ_THR_CURR_ADDR);
>
RE: [EXT] Re: stress-ng --hrtimers hangs system
Thanks Kurt for your confirmation. Best Regards, Jiafei. -Original Message- From: Kurt Kanzenbach Sent: Saturday, June 20, 2020 4:08 PM To: Vladimir Oltean ; Jiafei Pan Cc: linux-rt-us...@vger.kernel.org; lkml ; r...@vger.kernel.org; Colin King ; Jiafei Pan Subject: Re: [EXT] Re: stress-ng --hrtimers hangs system Caution: EXT Email Hi Jiafei, On Friday, June 12, 2020 2:49:17 AM CEST Jiafei Pan wrote: > Hi, Kurt, > > May I know whether you used "root" user to run stress-ng? using "root" > user will change the scheduler to be "SCHED_RR", so would you please > share test result with root and non-root users? Thanks. Performed the test now as root and non-root user. Same result: No problem. Thanks, Kurt
Re: [PATCH v6 1/7] dt-bindings: pinctrl: add bindings for MediaTek MT6779 SoC
On Sun, 2020-06-21 at 23:13 +0200, Pavel Machek wrote: > On Thu 2020-06-18 19:33:32, Hanks Chen wrote: > > From: Andy Teng > > > > Add devicetree bindings for MediaTek MT6779 pinctrl driver. > > > > Signed-off-by: Andy Teng > > > > + Pull up setings for 2 pull resistors, R0 and R1. User can > > + configure those special pins. Valid arguments are described > > as below: > > + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disable. > > Typo => disabled. Got it, I'll fix the typo in next version. Thanks! > Pavel >
RE: [PATCH] serial: samsung: fix spelling mistake
Hi Tamseel, > -Original Message- > From: Tamseel Shams > Sent: 17 June 2020 16:29 > To: kg...@kernel.org; k...@kernel.org; gre...@linuxfoundation.org; > jsl...@suse.com > Cc: linux-arm-ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; > linux-ser...@vger.kernel.org; linux-kernel@vger.kernel.org; > alim.akh...@samsung.com; Tamseel Shams > Subject: [PATCH] serial: samsung: fix spelling mistake > > There is a spelling mistake in a comment. Fix it. > > Signed-off-by: Tamseel Shams > --- Reviewed-by: Alim Akhtar > drivers/tty/serial/samsung_tty.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/samsung_tty.c > b/drivers/tty/serial/samsung_tty.c > index 6ef614d8648c..050a47fecdef 100644 > --- a/drivers/tty/serial/samsung_tty.c > +++ b/drivers/tty/serial/samsung_tty.c > @@ -6,7 +6,7 @@ > * http://armlinux.simtec.co.uk/ > */ > > -/* Hote on 2410 error handling > +/* Note on 2410 error handling > * > * The s3c2410 manual has a love/hate affair with the contents of the > * UERSTAT register in the UART blocks, and keeps marking some of the > -- > 2.17.1
RE: [RFC PATCH v13 7/9] arm64/kvm: Add hypercall service for kvm ptp.
Hi Steven,
> -Original Message-
> From: Steven Price
> Sent: Friday, June 19, 2020 6:45 PM
> To: Jianyong Wu ; net...@vger.kernel.org;
> yangbo...@nxp.com; john.stu...@linaro.org; t...@linutronix.de;
> pbonz...@redhat.com; sean.j.christopher...@intel.com; m...@kernel.org;
> richardcoch...@gmail.com; Mark Rutland ;
> w...@kernel.org; Suzuki Poulose
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu; k...@vger.kernel.org; Steve Capper
> ; Kaly Xin ; Justin He
> ; Wei Chen ; nd
> Subject: Re: [RFC PATCH v13 7/9] arm64/kvm: Add hypercall service for kvm
> ptp.
>
> On 19/06/2020 10:30, Jianyong Wu wrote:
> > ptp_kvm will get this service through smccc call.
> > The service offers wall time and counter cycle of host for guest.
> > caller must explicitly determines which cycle of virtual counter or
> > physical counter to return if it needs counter cycle.
> >
> > Signed-off-by: Jianyong Wu
> > ---
> > arch/arm64/kvm/Kconfig | 6 +
> > arch/arm64/kvm/hypercalls.c | 50
> +
> > include/linux/arm-smccc.h | 30 ++
> > 3 files changed, 86 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index
> > 13489aff4440..79091f6e5e7a 100644
> > --- a/arch/arm64/kvm/Kconfig
> > +++ b/arch/arm64/kvm/Kconfig
> > @@ -60,6 +60,12 @@ config KVM_ARM_PMU
> > config KVM_INDIRECT_VECTORS
> > def_bool HARDEN_BRANCH_PREDICTOR || HARDEN_EL2_VECTORS
> >
> > +config ARM64_KVM_PTP_HOST
> > + bool "KVM PTP host service for arm64"
> > + default y
> > + help
> > + virtual kvm ptp clock hypercall service for arm64
> > +
> > endif # KVM
> >
> > endif # VIRTUALIZATION
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index db6dce3d0e23..366b0646c360 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -3,6 +3,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -11,6 +12,10 @@
> >
> > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > {
> > +#ifdef CONFIG_ARM64_KVM_PTP_HOST
> > + struct system_time_snapshot systime_snapshot;
> > + u64 cycles = 0;
> > +#endif
> > u32 func_id = smccc_get_function(vcpu);
> > u32 val[4] = {SMCCC_RET_NOT_SUPPORTED};
> > u32 feature;
> > @@ -70,7 +75,52 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > break;
> > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
> > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
> > +
> > +#ifdef CONFIG_ARM64_KVM_PTP_HOST
> > + val[0] |= BIT(ARM_SMCCC_KVM_FUNC_KVM_PTP); #endif
> > + break;
> > +
> > +#ifdef CONFIG_ARM64_KVM_PTP_HOST
> > + /*
> > +* This serves virtual kvm_ptp.
> > +* Four values will be passed back.
> > +* reg0 stores high 32-bit host ktime;
> > +* reg1 stores low 32-bit host ktime;
> > +* reg2 stores high 32-bit difference of host cycles and cntvoff;
> > +* reg3 stores low 32-bit difference of host cycles and cntvoff.
> > +*/
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + /*
> > +* system time and counter value must captured in the same
> > +* time to keep consistency and precision.
> > +*/
> > + ktime_get_snapshot(_snapshot);
> > + if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER)
> > + break;
> > + val[0] = upper_32_bits(systime_snapshot.real);
> > + val[1] = lower_32_bits(systime_snapshot.real);
> > + /*
> > +* which of virtual counter or physical counter being
> > +* asked for is decided by the first argument of smccc
> > +* call. If no first argument or invalid argument, zero
> > +* counter value will return;
> > +*/
>
> It's not actually possible to have "no first argument" - there's no argument
> count, so whatever is in the register during the call with be passed. I'd also
> caution that "first argument" is ambigious: r0 could be the 'first' but is
> also the
> function number, here you mean r1.
>
Sorry, I really make mistake here, I really mean no r1 value.
> There's also a subtle cast to 32 bits here (feature is u32), which might be
> worth a comment before someone 'optimises' by removing the 'feature'
> variable.
>
Yeah, it's better to add a note, but I think it's better add it at the first
time calling smccc_get_arg1.
WDYT?
> Finally I'm not sure if zero counter value is best - would it not be possible
> for
> this to be a valid counter value?
We have two different ways to call this service in ptp_kvm guest, one needs
counter cycle, the other
not. So I think it's vain to return a valid counter cycle back if the ptp_kvm
does not needs it.
>
> > + feature = smccc_get_arg1(vcpu);
> > + switch (feature) {
> > + case ARM_PTP_VIRT_COUNTER:
> > +
[PATCH] [net/sched] tcindex_change: Remove redundant null check
arg cannot be NULL since its already being dereferenced
before. Remove the redundant NULL check.
Signed-off-by: Gaurav Singh
---
net/sched/cls_tcindex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index 61e95029c18f..78bec347b8b6 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -533,7 +533,7 @@ tcindex_change(struct net *net, struct sk_buff *in_skb,
pr_debug("tcindex_change(tp %p,handle 0x%08x,tca %p,arg %p),opt %p,"
"p %p,r %p,*arg %p\n",
- tp, handle, tca, arg, opt, p, r, arg ? *arg : NULL);
+ tp, handle, tca, arg, opt, p, r, *arg);
if (!opt)
return 0;
--
2.17.1
Re: [PATCH] cpufreq: dt: fix oops on armada37xx
On 20-06-20, 17:44, Ivan Kokshaysky wrote: > Commit 0c868627e617e43a295d8 (cpufreq: dt: Allow platform specific > intermediate callbacks) added two function pointers to the > struct cpufreq_dt_platform_data. However, armada37xx_cpufreq_driver_init() > has this struct (pdata) located on the stack and uses only "suspend" > and "resume" fields. So these newly added "get_intermediate" and > "target_intermediate" pointers are uninitialized and contain arbitrary > non-null values, causing all kinds of trouble. > > For instance, here is an oops on espressobin after an attempt to change > the cpefreq governor: > > [ 29.174554] Unable to handle kernel execute from non-executable memory at > virtual address 3f87bdc0 > ... > [ 29.269373] pc : 0x3f87bdc0 > [ 29.272957] lr : __cpufreq_driver_target+0x138/0x580 > ... > > Fixed by zeroing out pdata before use. > > Signed-off-by: Ivan Kokshaysky > --- > drivers/cpufreq/armada-37xx-cpufreq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c > b/drivers/cpufreq/armada-37xx-cpufreq.c > index aa0f06dec959..df1c941260d1 100644 > --- a/drivers/cpufreq/armada-37xx-cpufreq.c > +++ b/drivers/cpufreq/armada-37xx-cpufreq.c > @@ -456,6 +456,7 @@ static int __init armada37xx_cpufreq_driver_init(void) > /* Now that everything is setup, enable the DVFS at hardware level */ > armada37xx_cpufreq_enable_dvfs(nb_pm_base); > > + memset(, 0, sizeof(pdata)); > pdata.suspend = armada37xx_cpufreq_suspend; > pdata.resume = armada37xx_cpufreq_resume; Applied. Thanks. -- viresh
[PATCH] net: ath10k: santity check for ep connectivity
Function ep_rx_complete is being called without NULL checking
in ath10k_htc_rx_completion_handler. Without such check, mal-
formed packet is able to cause jump to NULL.
ep->service_id seems a good candidate for sanity check as it is
used in usb.c.
Signed-off-by: Zekun Shen
---
drivers/net/wireless/ath/ath10k/htc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index 31df6dd04..e00794d97 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -450,6 +450,11 @@ void ath10k_htc_rx_completion_handler(struct ath10k *ar,
struct sk_buff *skb)
ep = >endpoint[eid];
+ if (ep->service_id == 0) {
+ ath10k_warn(ar, "HTC Rx: ep %d is not connect\n", eid);
+ goto out;
+ }
+
payload_len = __le16_to_cpu(hdr->len);
if (payload_len + sizeof(*hdr) > ATH10K_HTC_MAX_LEN) {
--
2.17.1
Re: opp: core: Add missing export to core.c
On 20-06-20, 13:03, Valdis Klētnieks wrote:
> After this commit, a 'make allmodconfig' fails due to a missing export.
> commit 5f2430fb40c74db85764c8a472ecd6849025dd3f
> Author: Sibi Sankar
> Date: Sat Jun 6 03:03:31 2020 +0530
>
> cpufreq: qcom: Update the bandwidth levels on frequency change
>
> ERROR: modpost: "dev_pm_opp_adjust_voltage"
> [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
>
> Provide the export.
>
> Fixes: 5f2430fb40c7 ("cpufreq: qcom: Update the bandwidth levels on frequency
> change")
> Signed-off-by: Valdis Kletnieks
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 6937bf45f497..c9336aac74e9 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2302,6 +2302,7 @@ int dev_pm_opp_adjust_voltage(struct device *dev,
> unsigned long freq,
> dev_pm_opp_put_opp_table(opp_table);
> return r;
> }
> +EXPORT_SYMBOL_GPL(dev_pm_opp_adjust_voltage);
>
> /**
> * dev_pm_opp_enable() - Enable a specific OPP
>
Applied with reworded logs.
--
viresh
[PATCH] i2c: sprd: Fix runtime PM imbalance on error
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a corresponding decrement is
needed on the error handling path to keep the counter balanced.
Fix this by adding the missed function call.
Signed-off-by: Dinghao Liu
---
drivers/i2c/busses/i2c-sprd.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index 19cda6742423..675f72a3fd60 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -285,8 +285,10 @@ static int sprd_i2c_master_xfer(struct i2c_adapter
*i2c_adap,
int im, ret;
ret = pm_runtime_get_sync(i2c_dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+ }
for (im = 0; im < num - 1; im++) {
ret = sprd_i2c_handle_msg(i2c_adap, [im], 0);
@@ -571,8 +573,10 @@ static int sprd_i2c_remove(struct platform_device *pdev)
int ret;
ret = pm_runtime_get_sync(i2c_dev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+ }
i2c_del_adapter(_dev->adap);
clk_disable_unprepare(i2c_dev->clk);
--
2.17.1
[RFC PATCH RT] when panic use prink_flush_buffer to dump printk_ringbuffer
From: wangyong
echo c > proc/sysrq-trigger to trigger system panic, there is no debug
information.
I think the reason is using printk_kthread_func, since panic will call
local_irq_disable to disable interrupts, and then call smp_send_stop to
stop other cpus, the printk thread probably is not waken up by irq_work
and can't print messages during panic.
Using printk_flush_buffer to force flush printk_ringbuffer after all
messages are added to printk_ringbuffer by printk.
Because printk_kthread_func may call console_lock and be blocked when
cpus stop, so printk_flush_buffer does't call console_lock.
Signed-off-by: wangyong
---
include/linux/printk.h | 1 +
kernel/panic.c | 2 +
kernel/printk/printk.c | 99 ++
3 files changed, 78 insertions(+), 24 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index bbfe04c..66a5acf 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -193,6 +193,7 @@ void dump_stack_print_info(const char *log_lvl);
void show_regs_print_info(const char *log_lvl);
extern asmlinkage void dump_stack(void) __cold;
struct wait_queue_head *printk_wait_queue(void);
+void printk_flush_buffer(void);
#else
static inline __printf(1, 0)
int vprintk(const char *s, va_list args)
diff --git a/kernel/panic.c b/kernel/panic.c
index 4d893b6..c19b84b 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -301,6 +301,7 @@ void panic(const char *fmt, ...)
* We can't use the "normal" timers since we just panicked.
*/
pr_emerg("Rebooting in %d seconds..\n", panic_timeout);
+ printk_flush_buffer();
for (i = 0; i < panic_timeout * 1000; i += PANIC_TIMER_STEP) {
touch_nmi_watchdog();
@@ -334,6 +335,7 @@ void panic(const char *fmt, ...)
disabled_wait();
#endif
pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
+ printk_flush_buffer();
/* Do not scroll important messages printed above */
suppress_printk = 1;
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 6296d34..96e7f07 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1875,6 +1875,59 @@ static void cont_add(int ctx, int cpu, u32 caller_id,
int facility, int level,
}
}
+/*
+ * Record key parameters used to print printk_ringbuffer
+ */
+static struct prb_info {
+ struct prb_iterator iter;
+ char *ext_text;
+ char *text;
+ char *buf;
+ u64 master_seq;
+} prb_info;
+void printk_flush_buffer(void)
+{
+ int ret;
+ size_t len;
+ size_t ext_len;
+ struct printk_log *msg;
+ struct prb_info *info;
+
+ info = _info;
+ if (!info->ext_text || !info->text || !info->buf)
+ return;
+
+ do {
+ ret = prb_iter_next(>iter, info->buf,
+PRINTK_RECORD_MAX, >master_seq);
+ if (ret == -ERESTARTSYS) {
+ continue;
+ } else if (ret < 0) {
+ /* iterator invalid, start over */
+ prb_iter_init(>iter, _rb, NULL);
+ continue;
+ } else if (ret == 0) {
+ break;
+ }
+
+ msg = (struct printk_log *)info->buf;
+ format_text(msg, info->master_seq, info->ext_text, _len,
+ info->text, , printk_time);
+
+ //console_lock(); since printk thread may hold lock
+ call_console_drivers(info->master_seq, info->ext_text, ext_len,
+ info->text, len, msg->level, msg->facility);
+
+ if (len > 0 || ext_len > 0)
+ printk_delay(msg->level);
+ } while (ret != 0);
+
+ kfree(info->ext_text);
+ kfree(info->text);
+ kfree(info->buf);
+}
+EXPORT_SYMBOL(printk_flush_buffer);
+
/* ring buffer used as memory allocator for temporary sprint buffers */
DECLARE_STATIC_PRINTKRB(sprint_rb,
ilog2(PRINTK_RECORD_MAX + sizeof(struct prb_entry) +
@@ -2681,52 +2734,50 @@ late_initcall(printk_late_init);
#if defined CONFIG_PRINTK
static int printk_kthread_func(void *data)
{
- struct prb_iterator iter;
- struct printk_log *msg;
- size_t ext_len;
- char *ext_text;
- u64 master_seq;
- size_t len;
- char *text;
- char *buf;
+
int ret;
+ size_t len;
+ size_t ext_len;
+ struct printk_log *msg;
+ struct prb_info *info;
- ext_text = kmalloc(CONSOLE_EXT_LOG_MAX, GFP_KERNEL);
- text = kmalloc(PRINTK_SPRINT_MAX, GFP_KERNEL);
- buf = kmalloc(PRINTK_RECORD_MAX, GFP_KERNEL);
- if (!ext_text || !text || !buf)
+ info = _info;
+ info->ext_text = kmalloc(CONSOLE_EXT_LOG_MAX, GFP_KERNEL);
+ info->text =
Re: [PATCH net-next v1 5/5] hinic: add support to get eeprom information
On 2020/6/21 0:00, Andrew Lunn wrote:
>> +static int hinic_get_module_eeprom(struct net_device *netdev,
>> + struct ethtool_eeprom *ee, u8 *data)
>> +{
>> +struct hinic_dev *nic_dev = netdev_priv(netdev);
>> +u8 sfp_data[STD_SFP_INFO_MAX_SIZE];
>
> sfp_data will contain whatever is on the stack.
>
>> +u16 len;
>> +int err;
>> +
>> +if (!ee->len || ((ee->len + ee->offset) > STD_SFP_INFO_MAX_SIZE))
>> +return -EINVAL;
>> +
>> +memset(data, 0, ee->len);
>
> This clears what you are going to return.
>
>> +
>> +err = hinic_get_sfp_eeprom(nic_dev->hwdev, sfp_data, );
>
> Upto len bytes of sfp_data now contain useful data. The rest of
> sfp_data is still stack data.
>
>
>> +if (err)
>> +return err;
>> +
>> +memcpy(data, sfp_data + ee->offset, ee->len);
>
> If len < ee->len, you have just returned to user space some stack data.
>
>Andrew
> .
>
The whole sfp_data will be assigned values in hinic_get_sfp_eeprom function,
so stack data won't be returned to user space. Thanks for your review.
[PATCH] [objtoo] fix memory leak in special_get_alts
Free alt before returning to avoid memory leak.
Signed-off-by: Gaurav Singh
---
tools/objtool/special.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/special.c b/tools/objtool/special.c
index e74e0189de22..f6f7dee1ba77 100644
--- a/tools/objtool/special.c
+++ b/tools/objtool/special.c
@@ -188,8 +188,10 @@ int special_get_alts(struct elf *elf, struct list_head
*alts)
memset(alt, 0, sizeof(*alt));
ret = get_alt_entry(elf, entry, sec, idx, alt);
- if (ret)
+ if (ret) {
+ free(alt);
return ret;
+ }
list_add_tail(>list, alts);
}
--
2.17.1
[PATCH v2, 1/2] media: v4l UAPI: add V4L2_BUF_CAP_SUPPORTS_RO_REQUESTS
This patch adds support for the V4L2_BUF_CAP_SUPPORTS_RO_REQUESTS flag. This flag is used for Read-only(Ro) Request. Signed-off-by: Yunfei Dong --- Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst index b6d52083707b..7c7451773b8e 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst @@ -126,6 +126,7 @@ aborting or finishing any DMA in progress, an implicit .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS: .. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS: .. _V4L2-BUF-CAP-SUPPORTS-M2M-HOLD-CAPTURE-BUF: +.. _V4L2-BUF-CAP-SUPPORTS-RO-REQUESTS: .. cssclass:: longtable @@ -156,6 +157,9 @@ aborting or finishing any DMA in progress, an implicit - Only valid for stateless decoders. If set, then userspace can set the ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag to hold off on returning the capture buffer until the OUTPUT timestamp changes. +* - ``V4L2_BUF_CAP_SUPPORTS_RO_REQUESTS`` + - 0x0040 + - This buffer type supports :ref:`requests `. Return Value -- 2.18.0
[PATCH v2, 2/2] media: v4l: Add Ro request api for capture queue
Add Read-only(Ro) request for capture queue. Ro request mean that
user driver can get ext ctrls, buf set ext ctrls is not allowed.
Add param ro_requests in struct v4l2_ctrl_handler to present current
ctrl is read only. Add param ro_ctrl_handler in struct v4l2_fh used
for ro request.
When set/get ext ctrls, will check whether current CID ctrls is ro ctrls
or not using function v4l2_check_ro_ext_ctrls().
Signed-off-by: Yunfei Dong
---
.../media/common/videobuf2/videobuf2-v4l2.c | 7 ++
drivers/media/mc/mc-request.c | 10 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 107 +++---
drivers/media/v4l2-core/v4l2-ioctl.c | 22
drivers/media/v4l2-core/v4l2-mem2mem.c| 19 ++--
include/media/v4l2-ctrls.h| 22 +++-
include/media/v4l2-fh.h | 2 +
include/media/videobuf2-core.h| 2 +
include/uapi/linux/videodev2.h| 1 +
9 files changed, 154 insertions(+), 38 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index eb5d5db96552..91a6f3a0c208 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -402,6 +402,11 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q,
struct media_device *md
return -EBUSY;
}
return 0;
+ } else if (!V4L2_TYPE_IS_OUTPUT(q->type)) {
+ if (!q->supports_ro_requests || q->supports_requests) {
+ dprintk(1, "%s: cap queue use ro requests\n", opname);
+ return -EBADR;
+ }
} else if (!q->supports_requests) {
dprintk(1, "%s: queue does not support requests\n", opname);
return -EBADR;
@@ -665,6 +670,8 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
if (q->supports_requests)
*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+ if (q->supports_ro_requests)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_RO_REQUESTS;
#endif
}
diff --git a/drivers/media/mc/mc-request.c b/drivers/media/mc/mc-request.c
index e3fca436c75b..e50ae259c1ff 100644
--- a/drivers/media/mc/mc-request.c
+++ b/drivers/media/mc/mc-request.c
@@ -404,16 +404,12 @@ int media_request_object_bind(struct media_request *req,
struct media_request_object *obj)
{
unsigned long flags;
- int ret = -EBUSY;
if (WARN_ON(!ops->release))
return -EBADR;
spin_lock_irqsave(>lock, flags);
- if (WARN_ON(req->state != MEDIA_REQUEST_STATE_UPDATING))
- goto unlock;
-
obj->req = req;
obj->ops = ops;
obj->priv = priv;
@@ -423,11 +419,9 @@ int media_request_object_bind(struct media_request *req,
else
list_add(>list, >objects);
req->num_incomplete_objects++;
- ret = 0;
-
-unlock:
spin_unlock_irqrestore(>lock, flags);
- return ret;
+
+ return 0;
}
EXPORT_SYMBOL_GPL(media_request_object_bind);
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 3f3fbcd60cc6..effc26f733de 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3386,22 +3386,6 @@ static const struct media_request_object_ops req_ops = {
.release = v4l2_ctrl_request_release,
};
-struct v4l2_ctrl_handler *v4l2_ctrl_request_hdl_find(struct media_request *req,
- struct v4l2_ctrl_handler *parent)
-{
- struct media_request_object *obj;
-
- if (WARN_ON(req->state != MEDIA_REQUEST_STATE_VALIDATING &&
- req->state != MEDIA_REQUEST_STATE_QUEUED))
- return NULL;
-
- obj = media_request_object_find(req, _ops, parent);
- if (obj)
- return container_of(obj, struct v4l2_ctrl_handler, req_obj);
- return NULL;
-}
-EXPORT_SYMBOL_GPL(v4l2_ctrl_request_hdl_find);
-
struct v4l2_ctrl *
v4l2_ctrl_request_hdl_ctrl_find(struct v4l2_ctrl_handler *hdl, u32 id)
{
@@ -3420,6 +3404,10 @@ static int v4l2_ctrl_request_bind(struct media_request
*req,
ret = v4l2_ctrl_request_clone(hdl, from);
if (!ret) {
+ if (!hdl->ro_requests &&
+ WARN_ON(req->state != MEDIA_REQUEST_STATE_UPDATING))
+ return -EBUSY;
+
ret = media_request_object_bind(req, _ops,
from, false, >req_obj);
if (!ret)
@@ -3593,6 +3581,62 @@ static int class_check(struct v4l2_ctrl_handler *hdl,
u32 which)
return find_ref_lock(hdl, which | 1) ? 0 : -EINVAL;
}
+int v4l2_check_ro_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+ struct video_device *vdev, struct media_device
[PATCH v2, 0/2] This patchset add Read-only(Ro) request for capture queue
User driver need to get HDR10+ information for each capture buffer; For some encoder cases, user driver need to get encoded message for each frame. So add support read-only(Ro) request for capture queue. Ro request mean that user driver just can get ext ctrls, set ext ctrls is not not allowed. Ro Request also can be used in output queue. There is not upstream driver to use this feature at now, but we are developing internal driver to use it. If it is ready, we will try to upstream vdec/venc driver based on this feature. Change compared to v1: -change commit message of patch 01/02 -change commit message of patch 02/02 Yunfei Dong (2): media: v4l UAPI: add V4L2_BUF_CAP_SUPPORTS_RO_REQUESTS media: v4l: Add Ro request api for capture queue .../media/v4l/vidioc-reqbufs.rst | 4 + .../media/common/videobuf2/videobuf2-v4l2.c | 7 ++ drivers/media/mc/mc-request.c | 10 +- drivers/media/v4l2-core/v4l2-ctrls.c | 107 +++--- drivers/media/v4l2-core/v4l2-ioctl.c | 22 drivers/media/v4l2-core/v4l2-mem2mem.c| 19 ++-- include/media/v4l2-ctrls.h| 22 +++- include/media/v4l2-fh.h | 2 + include/media/videobuf2-core.h| 2 + include/uapi/linux/videodev2.h| 1 + 10 files changed, 158 insertions(+), 38 deletions(-)
[PATCH] [x86] overlap: cleanup redundant logic
In overlap check, same expression is repeated twice.
Remove one of them.
Signed-off-by: Gaurav Singh
---
arch/x86/mm/pat/set_memory.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 77e04304a2a7..7d44b4863ee5 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -388,8 +388,7 @@ static void cpa_flush(struct cpa_data *data, int cache)
static bool overlaps(unsigned long r1_start, unsigned long r1_end,
unsigned long r2_start, unsigned long r2_end)
{
- return (r1_start <= r2_end && r1_end >= r2_start) ||
- (r2_start <= r1_end && r2_end >= r1_start);
+ return (r1_start <= r2_end && r1_end >= r2_start);
}
#ifdef CONFIG_PCI_BIOS
--
2.17.1
Re: [PATCH v2 3/5] mm: memcg/percpu: per-memcg percpu memory statistics
On Mon, Jun 08, 2020 at 04:08:17PM -0700, Roman Gushchin wrote:
> Percpu memory can represent a noticeable chunk of the total
> memory consumption, especially on big machines with many CPUs.
> Let's track percpu memory usage for each memcg and display
> it in memory.stat.
>
> A percpu allocation is usually scattered over multiple pages
> (and nodes), and can be significantly smaller than a page.
> So let's add a byte-sized counter on the memcg level:
> MEMCG_PERCPU_B. Byte-sized vmstat infra created for slabs
> can be perfectly reused for percpu case.
>
> Signed-off-by: Roman Gushchin
> Acked-by: Dennis Zhou
> ---
> Documentation/admin-guide/cgroup-v2.rst | 4
> include/linux/memcontrol.h | 8
> mm/memcontrol.c | 4 +++-
> mm/percpu.c | 10 ++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index ce3e05e41724..7c1e784239bf 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
> Amount of memory used for storing in-kernel data
> structures.
>
> + percpu
> + Amount of memory used for storing per-cpu kernel
> + data structures.
> +
> sock
> Amount of memory used in network transmission buffers
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index eede46c43573..7ed3af71a6fb 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -32,11 +32,19 @@ struct kmem_cache;
> enum memcg_stat_item {
> MEMCG_SWAP = NR_VM_NODE_STAT_ITEMS,
> MEMCG_SOCK,
> + MEMCG_PERCPU_B,
> /* XXX: why are these zone and not node counters? */
> MEMCG_KERNEL_STACK_KB,
> MEMCG_NR_STAT,
> };
>
> +static __always_inline bool memcg_stat_item_in_bytes(enum memcg_stat_item
> item)
> +{
> + if (item == MEMCG_PERCPU_B)
> + return true;
> + return vmstat_item_in_bytes(item);
This patch is now in -next and this line causes a warning from clang,
which shows up in every translation unit that includes this header,
which is a lot:
include/linux/memcontrol.h:45:30: warning: implicit conversion from
enumeration type 'enum memcg_stat_item' to different enumeration type
'enum node_stat_item' [-Wenum-conversion]
return vmstat_item_in_bytes(item);
^~~~
1 warning generated.
I assume this conversion is intentional; if so, it seems like expecting
a specific enum is misleading. Perhaps this should be applied on top?
Cheers,
Nathan
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 2499f78cf32d..bddeb4ce7a4f 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -38,7 +38,7 @@ enum memcg_stat_item {
MEMCG_NR_STAT,
};
-static __always_inline bool memcg_stat_item_in_bytes(enum memcg_stat_item item)
+static __always_inline bool memcg_stat_item_in_bytes(int item)
{
if (item == MEMCG_PERCPU_B)
return true;
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 084ee1c17160..52d7961a24f0 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -211,7 +211,7 @@ enum node_stat_item {
* measured in pages). This defines the API part, the internal representation
* might be different.
*/
-static __always_inline bool vmstat_item_in_bytes(enum node_stat_item item)
+static __always_inline bool vmstat_item_in_bytes(int item)
{
/*
* Global and per-node slab counters track slab pages.
Re: linux-next: build failure after merge of the tip tree
Hi Borislav,
On Sun, 21 Jun 2020 12:53:50 +0200 Borislav Petkov wrote:
>
> + acme for an FYI.
>
> On Sun, Jun 21, 2020 at 04:33:23PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> >
> > In file included from trace/beauty/tracepoints/x86_msr.c:10:
> > perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: error:
> > initialized field overwritten [-Werror=override-init]
> > 292 | [0xc0010280 - x86_AMD_V_KVM_MSRs_offset] = "F15H_PTSC",
> > | ^~~
> > perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: note: (near
> > initialization for 'x86_AMD_V_KVM_MSRs[640]')
> >
> > Caused by commit
> >
> > 1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
> >
> > I have used the tip tree from next-20200618 for tooday.
>
> Thanks, I saw that once but then got distracted to something of higher
> prio. :-\
>
> I'll apply this after testing it a bit:
>
> ---
> From: Borislav Petkov
> Date: Sun, 21 Jun 2020 12:41:53 +0200
> Subject: [PATCH] x86/msr: Move the F15h MSRs where they belong
>
> 1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
>
> moved the three F15h power MSRs to the architectural list but that was
> wrong as they belong in the family 0x15 list. That also caused:
>
> In file included from trace/beauty/tracepoints/x86_msr.c:10:
> perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: error:
> initialized field overwritten [-Werror=override-init]
> 292 | [0xc0010280 - x86_AMD_V_KVM_MSRs_offset] = "F15H_PTSC",
> | ^~~
> perf/trace/beauty/generated/x86_arch_MSRs_array.c:292:45: note: (near
> initialization for 'x86_AMD_V_KVM_MSRs[640]')
>
> due to MSR_F15H_PTSC ending up being defined twice. Move them where they
> belong and drop the duplicate.
>
> While at it, update the msr-index.h copy to pick up the changes from
>
> 7e5b3c267d25 ("x86/speculation: Add Special Register Buffer Data Sampling
> (SRBDS) mitigation")
>
> Fixes: 1068ed4547ad ("x86/msr: Lift AMD family 0x15 power-specific MSRs")
> Reported-by: Stephen Rothwell
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/include/asm/msr-index.h | 5 ++---
> tools/arch/x86/include/asm/msr-index.h | 9 ++---
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index eb9537254920..63ed8fe35738 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -422,11 +422,8 @@
> #define MSR_AMD_PERF_CTL 0xc0010062
> #define MSR_AMD_PERF_STATUS 0xc0010063
> #define MSR_AMD_PSTATE_DEF_BASE 0xc0010064
> -#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> -#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
> #define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140
> #define MSR_AMD64_OSVW_STATUS0xc0010141
> -#define MSR_F15H_PTSC0xc0010280
> #define MSR_AMD_PPIN_CTL 0xc00102f0
> #define MSR_AMD_PPIN 0xc00102f1
> #define MSR_AMD64_CPUID_FN_1 0xc0011004
> @@ -469,6 +466,8 @@
> #define MSR_F16H_DR0_ADDR_MASK 0xc0011027
>
> /* Fam 15h MSRs */
> +#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> +#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
> #define MSR_F15H_PERF_CTL0xc0010200
> #define MSR_F15H_PERF_CTL0 MSR_F15H_PERF_CTL
> #define MSR_F15H_PERF_CTL1 (MSR_F15H_PERF_CTL + 2)
> diff --git a/tools/arch/x86/include/asm/msr-index.h
> b/tools/arch/x86/include/asm/msr-index.h
> index 7dfd45bb6cdb..63ed8fe35738 100644
> --- a/tools/arch/x86/include/asm/msr-index.h
> +++ b/tools/arch/x86/include/asm/msr-index.h
> @@ -128,6 +128,10 @@
> #define TSX_CTRL_RTM_DISABLE BIT(0) /* Disable RTM feature */
> #define TSX_CTRL_CPUID_CLEAR BIT(1) /* Disable TSX enumeration */
>
> +/* SRBDS support */
> +#define MSR_IA32_MCU_OPT_CTRL0x0123
> +#define RNGDS_MITG_DIS BIT(0)
> +
> #define MSR_IA32_SYSENTER_CS 0x0174
> #define MSR_IA32_SYSENTER_ESP0x0175
> #define MSR_IA32_SYSENTER_EIP0x0176
> @@ -418,11 +422,8 @@
> #define MSR_AMD_PERF_CTL 0xc0010062
> #define MSR_AMD_PERF_STATUS 0xc0010063
> #define MSR_AMD_PSTATE_DEF_BASE 0xc0010064
> -#define MSR_F15H_CU_PWR_ACCUMULATOR 0xc001007a
> -#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR 0xc001007b
> #define MSR_AMD64_OSVW_ID_LENGTH 0xc0010140
> #define MSR_AMD64_OSVW_STATUS0xc0010141
> -#define MSR_F15H_PTSC0xc0010280
> #define MSR_AMD_PPIN_CTL 0xc00102f0
> #define MSR_AMD_PPIN 0xc00102f1
> #define MSR_AMD64_CPUID_FN_1 0xc0011004
>
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: modpost: "sched_setscheduler" [kernel/trace/ring_buffer_benchmark.ko]
undefined!
Caused by commit
616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")
Missed one :-)
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpEHwTABV1R2.pgp
Description: OpenPGP digital signature
Re: kprobe: __blkdev_put probe is missed
On Mon, 22 Jun 2020 08:27:53 +0800
Ming Lei wrote:
> I mean it isn't from user's viewpoint, and the binary code is usually a
> black box for final kprobe user.
>
> IMO, all your and Steven's input are just from kprobe/trace developer's
> viewpoint.
> Can you think about the issue from kprobe real/final user?
>
> Trace is very useful tools to observe system internal, and people often
> relies on trace to understand system. However, missed probe often causes
> trouble for us to understand the system correctly.
Agreed. However, since kprobes related tracing tools are layered
to provide different features (e.g. kprobes abstructs sw breakpoint,
ftrace kprobe-events provides a minimum CUI, and perf-probe provides
binary analysis, etc.), this issue should be solved by user-level
binary analysis layer. (it is not good idea to analyze the optimized
code in kernel)
> > > 2) from implementation view, I understand exception should be trapped
> > > on the entry of __blkdev_put(), looks it isn't done.
> >
> > No, it is correctly trapped the function entry address. The problem is
> > that the gcc optimized the nested function call into jump to the
> > beginning of function body (skip prologue).
> >
> > Usually, a function is compiled as below
> >
> > func() (1) the entry address (func:)
> > { (2) the function prologue (setup stackframe)
> > int a(3) the beginning of function body
> >...
> > func() (4) the nested function call
> >
> > And in this case, the gcc optimized (4) into jump to (3) instead of
> > actual function call instruction. Thus, for the nested case (1) and
> > (2) are skipped.
> > IOW, the code flow becomes
> > (1)->(2)->(3)->(4)->(3)
> > instead of
> > (1)->(2)->(3)->(4)->(1)->(2)->(3)
> >
> > In this case, if we put a probe on (1) or (2), those are disappeared
> > in the nested call. Thus if you put a probe on (3) ('perf probe
> > __blkdev_put:2')
> > you'll see the event twice.
>
> Thanks for your explanation.
>
> Can you kprobe guys improve the implementation for covering this case?
> For example, put probe on 3) in case the above situation is recognized.
OK, let me try to fix this in perf-probe since that is the simplest
binary analysis part in user-space.
Thank you,
--
Masami Hiramatsu
RE: [PATCH v13 3/9] smccc: Export smccc conduit get helper.
Hi Christoph, > -Original Message- > From: Christoph Hellwig > Sent: Friday, June 19, 2020 9:57 PM > To: Jianyong Wu > Cc: net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linaro.org; > t...@linutronix.de; pbonz...@redhat.com; sean.j.christopher...@intel.com; > m...@kernel.org; richardcoch...@gmail.com; Mark Rutland > ; w...@kernel.org; Suzuki Poulose > ; Steven Price ; Justin > He ; Wei Chen ; > k...@vger.kernel.org; Steve Capper ; linux- > ker...@vger.kernel.org; Kaly Xin ; nd ; > kvm...@lists.cs.columbia.edu; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v13 3/9] smccc: Export smccc conduit get helper. > > On Fri, Jun 19, 2020 at 09:01:14PM +0800, Jianyong Wu wrote: > > Export arm_smccc_1_1_get_conduit then modules can use smccc helper > > which adopts it. > > > > Acked-by: Mark Rutland > > Signed-off-by: Jianyong Wu > > --- > > drivers/firmware/smccc/smccc.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/firmware/smccc/smccc.c > > b/drivers/firmware/smccc/smccc.c index 4e80921ee212..b855fe7b5c90 > > 100644 > > --- a/drivers/firmware/smccc/smccc.c > > +++ b/drivers/firmware/smccc/smccc.c > > @@ -24,6 +24,7 @@ enum arm_smccc_conduit > > arm_smccc_1_1_get_conduit(void) > > > > return smccc_conduit; > > } > > +EXPORT_SYMBOL(arm_smccc_1_1_get_conduit); > > EXPORT_SYMBOL_GPL, please. Ok, thanks. Thanks Jianyong
RE: Re: [RFC,net-next 8/9] net: qos: police action add index for tc flower offloading
Hi Ido,
> -Original Message-
> From: Ido Schimmel
> Sent: 2020年6月21日 18:04
> To: Po Liu
> Cc: da...@davemloft.net; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org; vinicius.go...@intel.com; Claudiu Manoil
> ; Vladimir Oltean ;
> Alexandru Marginean ; Xiaoliang Yang
> ; Roy Zang ; Mingkai Hu
> ; Jerry Huang ; Leo Li
> ; michael.c...@broadcom.com; vis...@chelsio.com;
> sae...@mellanox.com; l...@kernel.org; j...@mellanox.com;
> ido...@mellanox.com; alexandre.bell...@bootlin.com;
> unglinuxdri...@microchip.com; k...@kernel.org; j...@mojatatu.com;
> xiyou.wangc...@gmail.com; john.hur...@netronome.com;
> simon.hor...@netronome.com;
> pieter.jansenvanvuu...@netronome.com; pa...@netfilter.org;
> mo...@mellanox.com; ivan.khoronz...@linaro.org; m-kariche...@ti.com;
> andre.gue...@linux.intel.com; jakub.kicin...@netronome.com
> Subject: Re: [RFC,net-next 8/9] net: qos: police action add index for
> tc flower offloading
>
>
> On Fri, Mar 06, 2020 at 08:56:06PM +0800, Po Liu wrote:
> > Hardware may own many entries for police flow. So that make one(or
> > multi) flow to be policed by one hardware entry. This patch add the
> > police action index provide to the driver side make it mapping the
> > driver hardware entry index.
> >
> > Signed-off-by: Po Liu
>
> Hi,
>
> I started looking into tc-police offload in mlxsw and remembered your
> patch. Are you planning to formally submit it? I'm asking because in mlxsw
> it is also possible to share the same policer between multiple filters.
Yes, I am preparing the patches and push again very soon. The patches will add
mtu and index for offloading as first step.
The next step is seeking method to implement two color + two buckets mode but
seems absent one bucket in policing action. The current burst + rate_bytes_ps
only can only implement one color+ one bucket policing.
>
> Thanks
>
> > ---
> > include/net/flow_offload.h | 1 +
> > net/sched/cls_api.c| 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> > index 54df87328edc..3b78b15ed20b 100644
> > --- a/include/net/flow_offload.h
> > +++ b/include/net/flow_offload.h
> > @@ -201,6 +201,7 @@ struct flow_action_entry {
> > booltruncate;
> > } sample;
> > struct {/* FLOW_ACTION_POLICE
> > */
> > + u32 index;
> > s64 burst;
> > u64 rate_bytes_ps;
> > u32 mtu;
> > diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index
> > 363d3991793d..ce846a9dadc1 100644
> > --- a/net/sched/cls_api.c
> > +++ b/net/sched/cls_api.c
> > @@ -3584,6 +3584,7 @@ int tc_setup_flow_action(struct flow_action
> *flow_action,
> > entry->police.rate_bytes_ps =
> > tcf_police_rate_bytes_ps(act);
> > entry->police.mtu = tcf_police_mtu(act);
> > + entry->police.index = act->tcfa_index;
> > } else if (is_tcf_ct(act)) {
> > entry->id = FLOW_ACTION_CT;
> > entry->ct.action = tcf_ct_action(act);
> > --
> > 2.17.1
> >
Thanks a lot!
Br,
Po Liu
Re: [RFC] Bypass filesystems for reading cached pages
On Sat, Jun 20, 2020 at 12:15:21PM -0700, Matthew Wilcox wrote: > On Sat, Jun 20, 2020 at 09:19:37AM +0300, Amir Goldstein wrote: > > On Fri, Jun 19, 2020 at 6:52 PM Matthew Wilcox wrote: > > > This patch lifts the IOCB_CACHED idea expressed by Andreas to the VFS. > > > The advantage of this patch is that we can avoid taking any filesystem > > > lock, as long as the pages being accessed are in the cache (and we don't > > > need to readahead any pages into the cache). We also avoid an indirect > > > function call in these cases. > > > > XFS is taking i_rwsem lock in read_iter() for a surprising reason: > > https://lore.kernel.org/linux-xfs/caoq4uxjpqdqp2aka8hrt4jdc65cto4qdydokfe-c3clxbba...@mail.gmail.com/ > > In that post I claim that ocfs2 and cifs also do some work in read_iter(). > > I didn't go back to check what, but it sounds like cache coherence among > > nodes. > > That's out of date. Here's POSIX-2017: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html > > "I/O is intended to be atomic to ordinary files and pipes and > FIFOs. Atomic means that all the bytes from a single operation that > started out together end up together, without interleaving from other > I/O operations. It is a known attribute of terminals that this is not > honored, and terminals are explicitly (and implicitly permanently) > excepted, making the behavior unspecified. The behavior for other > device types is also left unspecified, but the wording is intended to > imply that future standards might choose to specify atomicity (or not)." > > That _doesn't_ say "a read cannot observe a write in progress". It says > "Two writes cannot interleave". Indeed, further down in that section, it > says: Nope, it says "... without interleaving from other I/O operations". That means read() needs to be atomic w.r.t truncate, hole punching, extent zeroing, etc, not just other write() syscalls. Really, though, I'm not going to get drawn into a language lawyering argument here. We've discussed this before, and it's pretty clear the language supports both arguments in one way or another. And that means we are not going to change behaviour that XFS has provided for 27 years now. Last time this came up, I said: "XFS was designed with the intent that buffered writes are atomic w.r.t. to all other file accesses." Christoph said: "Downgrading these long standing guarantees is simply not an option" Darrick: "I don't like the idea of adding a O_BROKENLOCKINGPONIES flag" Nothing has changed since this was last discussed. Well, except for the fact that since then I've seen the source code to some 20+ year old enterprise applications that have been ported to Linux and that has made me even more certain that we need to maintain XFS's existing behaviour Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: Linux 5.8-rc2
On 16:00 Sun 21 Jun 2020, Linus Torvalds wrote:
So 5.8 may end up- being a big release, but rc2 looks fairly normal.
Despite having one pull request that missed rc1 by five minutes (and
thus getting pulled into rc2) and having a couple of small series of
"post-rc1 cleanup after we're past the conflicts", and despite being
one of the largest merge windows ever, last week was fairly calm.
So rc2 isn't particularly big or scary, and falls right in the normal range.
We'll see how much of that is the usual "catch our breath after the
merge window", and how much of that is just "5.8 looks fairly normal
despite being large".
Shortlog appended, there's nothing that looks alarming to me. It's a
mix of arch fixes, GPU driver fixes, filesystems, selftests and misc
small noise all over.
So whether you're a father or not (and whether you live in one of the
countries that celebrate it today or not), have a happy Father's Day.
And go test, it's not scary. Ok?
Linus
Thanks, man! time to give it a spin...-rc2 build...
Thanks,
Bhaskar
---
Aditya Pakki (2):
test_objagg: Fix potential memory leak in error handling
rocker: fix incorrect error handling in dma_rings_init
Alaa Hleihel (2):
net/sched: act_ct: Make tcf_ct_flow_table_restore_skb inline
netfilter: flowtable: Make nf_flow_table_offload_add/del_cb inline
Alex Deucher (2):
drm/amdgpu/pm: update comment to clarify Overdrive interfaces
drm/amdgpu: fix documentation around busy_percentage
Andy Shevchenko (1):
partitions/ldm: Replace uuid_copy() with import_uuid() where it
makes sense
Aneesh Kumar K.V (1):
powerpc: Fix kernel crash in show_instructions() w/DEBUG_VIRTUAL
Ard Biesheuvel (1):
arm64: remove TEXT_OFFSET randomization
Arnaldo Carvalho de Melo (10):
tools headers API: Update faccessat2 affected files
tools arch x86 uapi: Synch asm/unistd.h with the kernel sources
tools headers uapi: Sync linux/stat.h with the kernel sources
perf beauty: Add support to STATX_MNT_ID in the 'statx' syscall
'mask' argument
tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
tools headers UAPI: Sync drm/i915_drm.h with the kernel sources
tools headers UAPI: Sync kvm.h headers with the kernel sources
tools arch x86: Sync the msr-index.h copy with the kernel sources
tools include UAPI: Sync linux/vhost.h with the kernel sources
tools headers UAPI: Sync linux/fs.h with the kernel sources
Arnd Bergmann (3):
drm/i915/pmu: avoid an maybe-uninitialized warning
drm/i915: work around false-positive maybe-uninitialized warning
e1000e: fix unused-function warning
Arvind Sankar (2):
Makefile: Improve compressed debug info support detection
x86/purgatory: Add -fno-stack-protector
Atish Patra (1):
RISC-V: Acquire mmap lock before invoking walk_page_range
Baolin Wang (1):
blk-mq: Remove redundant 'return' statement
Barry Song (1):
arm64: mm: reserve hugetlb CMA after numa_init
Bartosz Golaszewski (1):
net: ethernet: mtk-star-emac: simplify interrupt handling
Charles Keepax (1):
net: macb: Only disable NAPI on the actual error path
Chen Yu (1):
e1000e: Do not wake up the system via WOL if device wakeup is disabled
Chen Zhou (3):
s390/crypto: use scnprintf() instead of snprintf()
s390: use scnprintf() in sys_##_prefix##_##_name##_show
s390/protvirt: use scnprintf() instead of snprintf()
Chris Wilson (10):
drm/i915/gt: Incorporate the virtual engine into timeslicing
drm/i915/selftests: Restore to default heartbeat
drm/i915/gt: Prevent timeslicing into unpreemptable requests
drm/i915/gt: Incrementally check for rewinding
drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds
drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds
drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds
drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds
drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to
workarounds
Christoph Hellwig (5):
scsi: libata: Provide an ata_scsi_dma_need_drain stub for !CONFIG_ATA
scsi: Wire up ata_scsi_dma_need_drain for SAS HBA drivers
maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault
maccess: rename probe_user_{read,write} to copy_{from,to}_user_nofault
maccess: rename probe_kernel_address to get_kernel_nofault
Christophe Leroy (3):
mm/gup: Use huge_ptep_get() in gup_hugepte()
mm: Allow arches to provide ptep_get()
powerpc/8xx: Provide ptep_get() with 16k pages
Colin Ian King (1):
net: axienet: fix spelling mistake in comment "Exteneded" -> "extended"
Coly Li (2):
bcache: use delayed kworker fo asynchronous devices registration
bcache: pr_info() format clean up in
Re: [PATCH 1/5] f2fs: fix to wait page writeback before update
On 2020/6/22 0:38, Jaegeuk Kim wrote:
> On 06/20, Chao Yu wrote:
>> On 2020/6/20 6:47, Jaegeuk Kim wrote:
>>> On 06/19, Chao Yu wrote:
On 2020/6/19 13:49, Jaegeuk Kim wrote:
> On 06/19, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2020/6/19 7:59, Jaegeuk Kim wrote:
>>> Hi Chao,
>>>
>>> On 06/18, Chao Yu wrote:
to make page content stable for special device like raid.
>>>
>>> Could you elaborate the problem a bit?
>>
>> Some devices like raid5 wants page content to be stable, because
>> it will calculate parity info based page content, if page is not
>> stable, parity info could be corrupted, result in data inconsistency
>> in stripe.
>
> I don't get the point, since those pages are brand new pages which were
> not
> modified before. If it's on writeback, we should not modify them
> regardless
> of whatever raid configuration. For example, f2fs_new_node_page() waits
> for
> writeback. Am I missing something?
I think we should use f2fs_bug_on(, PageWriteback()) rather than
f2fs_wait_on_page_writeback() for brand new page which is allocated just
now.
For other paths, we can keep rule that waiting for writeback before
updating.
How do you think?
Thanks,
>
>>
>> Thanks,
>>
>>>
Signed-off-by: Chao Yu
---
fs/f2fs/dir.c | 2 ++
fs/f2fs/extent_cache.c | 18 +-
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/file.c | 1 +
fs/f2fs/inline.c | 2 ++
fs/f2fs/inode.c| 3 +--
6 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index d35976785e8c..91e86747a604 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -495,6 +495,8 @@ static int make_empty_dir(struct inode *inode,
if (IS_ERR(dentry_page))
return PTR_ERR(dentry_page);
+ f2fs_bug_on(F2FS_I_SB(inode), PageWriteback(dentry_page));
+
dentry_blk = page_address(dentry_page);
make_dentry_ptr_block(NULL, , dentry_blk);
diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index e60078460ad1..686c68b98610 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -325,9 +325,10 @@ static void __drop_largest_extent(struct
extent_tree *et,
}
/* return true, if inode page is changed */
-static bool __f2fs_init_extent_tree(struct inode *inode, struct
f2fs_extent *i_ext)
+static void __f2fs_init_extent_tree(struct inode *inode, struct page
*ipage)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct f2fs_extent *i_ext = ipage ? _INODE(ipage)->i_ext :
NULL;
struct extent_tree *et;
struct extent_node *en;
struct extent_info ei;
@@ -335,16 +336,18 @@ static bool __f2fs_init_extent_tree(struct inode
*inode, struct f2fs_extent *i_e
if (!f2fs_may_extent_tree(inode)) {
/* drop largest extent */
if (i_ext && i_ext->len) {
+ f2fs_wait_on_page_writeback(ipage, NODE, true,
true);
i_ext->len = 0;
- return true;
+ set_page_dirty(ipage);
+ return;
}
- return false;
+ return;
}
et = __grab_extent_tree(inode);
if (!i_ext || !i_ext->len)
- return false;
+ return;
get_extent_info(, i_ext);
@@ -360,17 +363,14 @@ static bool __f2fs_init_extent_tree(struct inode
*inode, struct f2fs_extent *i_e
}
out:
write_unlock(>lock);
- return false;
}
-bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent
*i_ext)
+void f2fs_init_extent_tree(struct inode *inode, struct page *ipage)
{
- bool ret = __f2fs_init_extent_tree(inode, i_ext);
+ __f2fs_init_extent_tree(inode, ipage);
if (!F2FS_I(inode)->extent_tree)
set_inode_flag(inode, FI_NO_EXTENT);
-
- return ret;
}
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t
pgofs,
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index
Re: [PATCH v3 13/14] crypto: sun8i-ce: Add support for the PRNG
Hi Corentin,
I love your patch! Perhaps something to improve:
[auto build test WARNING on sunxi/sunxi/for-next]
[also build test WARNING on cryptodev/master crypto/master v5.8-rc2]
[cannot apply to next-20200621]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Corentin-Labbe/crypto-allwinner-add-xRNG-and-hashes/20200622-033401
base: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
sunxi/for-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
ef455a55bcf2cfea04a99c361b182ad18b7f03f1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c:818:26: warning: result of
>> comparison of constant 255 with expression of type 'const char' is always
>> false [-Wtautological-constant-out-of-range-compare]
if (ce->variant->prng == CE_ID_NOTSUPP) {
~ ^ ~
1 warning generated.
vim +818 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
761
762 static int sun8i_ce_register_algs(struct sun8i_ce_dev *ce)
763 {
764 int ce_method, err, id, i;
765
766 for (i = 0; i < ARRAY_SIZE(ce_algs); i++) {
767 ce_algs[i].ce = ce;
768 switch (ce_algs[i].type) {
769 case CRYPTO_ALG_TYPE_SKCIPHER:
770 id = ce_algs[i].ce_algo_id;
771 ce_method = ce->variant->alg_cipher[id];
772 if (ce_method == CE_ID_NOTSUPP) {
773 dev_dbg(ce->dev,
774 "DEBUG: Algo of %s not
supported\n",
775
ce_algs[i].alg.skcipher.base.cra_name);
776 ce_algs[i].ce = NULL;
777 break;
778 }
779 id = ce_algs[i].ce_blockmode;
780 ce_method = ce->variant->op_mode[id];
781 if (ce_method == CE_ID_NOTSUPP) {
782 dev_dbg(ce->dev, "DEBUG: Blockmode of
%s not supported\n",
783
ce_algs[i].alg.skcipher.base.cra_name);
784 ce_algs[i].ce = NULL;
785 break;
786 }
787 dev_info(ce->dev, "Register %s\n",
788 ce_algs[i].alg.skcipher.base.cra_name);
789 err =
crypto_register_skcipher(_algs[i].alg.skcipher);
790 if (err) {
791 dev_err(ce->dev, "ERROR: Fail to
register %s\n",
792
ce_algs[i].alg.skcipher.base.cra_name);
793 ce_algs[i].ce = NULL;
794 return err;
795 }
796 break;
797 case CRYPTO_ALG_TYPE_AHASH:
798 id = ce_algs[i].ce_algo_id;
799 ce_method = ce->variant->alg_hash[id];
800 if (ce_method == CE_ID_NOTSUPP) {
801 dev_info(ce->dev,
802 "DEBUG: Algo of %s not
supported\n",
803
ce_algs[i].alg.hash.halg.base.cra_name);
804 ce_algs[i].ce = NULL;
805 break;
806 }
807 dev_info(ce->dev, "Register %s\n",
808
ce_algs[i].alg.hash.halg.base.cra_name);
809 err =
crypto_register_ahash(_algs[i].alg.hash);
810 if (err) {
811 dev_err(ce->dev, "ERROR: Fail to
register %s\n",
812
