Re: [PATCH 1/1] ACPI: fix acpi table use after free
Hello Rafael, On Fri, Mar 05, 2021 at 02:30:07PM +0100, Rafael J. Wysocki wrote: > On Fri, Mar 5, 2021 at 12:14 AM George Kennedy > wrote: > > > The ibft table, for example, is mapped in via acpi_map() and kmap(). The > > page for the ibft table is not reserved, so it can end up on the freelist. > > You appear to be saying that it is not sufficient to kmap() a page in > order to use it safely. It is also necessary to reserve it upfront, > for example with the help of memblock_reserve(). Is that correct? If > so, is there an alternative way to reserve a page frame? Like David said in the other reply, if a BIOS does not mark the memory that contains an ACPI table as used (e.g. reserved or ACPI data), we need to make sure the kernel knows that such memory is in use and an early call to memblock_reserve() is exactly what we need here. George had this issue with iBFT, but in general this could be any table that a buggy BIOS forgot to mark as ACPI data. > > >> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > >> index d883176..97deea3 100644 > > >> --- a/arch/x86/kernel/setup.c > > >> +++ b/arch/x86/kernel/setup.c > > >> @@ -1046,6 +1046,7 @@ void __init setup_arch(char **cmdline_p) > > >> cleanup_highmap(); > > >> > > >> memblock_set_current_limit(ISA_END_ADDRESS); > > >> + acpi_boot_table_init(); > > > This cannot be moved before the acpi_table_upgrade() invocation AFAICS. > > > > > > Why exactly do you want to move it? > > > > Want to make sure there are slots for memblock_reserve() to be able to > > reserve the page. > > Well, that may not require reordering the initialization this way. The memory that is used by the firmware should be reserved before memblock allocations are allowed so that ACPI tables won't get trampled by some random allocation. On x86 this essentially means that the early reservations need to be complete before the call to e820__memblock_setup(). We probably need more precise refactoring of ACPI init than simply moving acpi_boot_table_init() earlier. > > >> e820__memblock_setup(); > > >> -- Sincerely yours, Mike.
[syzbot] KASAN: use-after-free Read in ovl_real_fdget_meta
Hello, syzbot found the following issue on: HEAD commit:92f791eb Add linux-next specific files for 20210302 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=12696076d0 kernel config: https://syzkaller.appspot.com/x/.config?x=55e0d976097c2fbd dashboard link: https://syzkaller.appspot.com/bug?extid=d8f10499005854b34b80 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d8f10499005854b34...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in file_inode include/linux/fs.h:1301 [inline] BUG: KASAN: use-after-free in ovl_real_fdget_meta+0x482/0x500 fs/overlayfs/file.c:118 Read of size 8 at addr 88801854d420 by task syz-executor.2/18364 CPU: 0 PID: 18364 Comm: syz-executor.2 Not tainted 5.12.0-rc1-next-20210302-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xfa/0x151 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 file_inode include/linux/fs.h:1301 [inline] ovl_real_fdget_meta+0x482/0x500 fs/overlayfs/file.c:118 ovl_real_fdget+0xad/0x260 fs/overlayfs/file.c:141 ovl_flush+0x72/0x230 fs/overlayfs/file.c:695 filp_close+0xb4/0x170 fs/open.c:1295 close_fd+0x5c/0x80 fs/file.c:628 __do_sys_close fs/open.c:1314 [inline] __se_sys_close fs/open.c:1312 [inline] __x64_sys_close+0x2f/0xa0 fs/open.c:1312 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x41920b Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44 RSP: 002b:7fffbf66ec90 EFLAGS: 0293 ORIG_RAX: 0003 RAX: ffda RBX: 0004 RCX: 0041920b RDX: 00570448 RSI: 8906c86e RDI: 0003 RBP: 0001 R08: R09: 001b2c13ba84 R10: 7fffbf66ed80 R11: 0293 R12: 0005a429 R13: 03e8 R14: 0056bf60 R15: 0005a36d Allocated by task 18368: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:427 [inline] __kasan_slab_alloc+0x75/0x90 mm/kasan/common.c:460 kasan_slab_alloc include/linux/kasan.h:223 [inline] slab_post_alloc_hook mm/slab.h:516 [inline] slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x15e/0x380 mm/slub.c:2920 kmem_cache_zalloc include/linux/slab.h:674 [inline] __alloc_file+0x21/0x280 fs/file_table.c:101 alloc_empty_file_noaccount+0x19/0x90 fs/file_table.c:172 open_with_fake_path+0x27/0xe0 fs/open.c:969 ovl_open_realfile+0x270/0x2f0 fs/overlayfs/file.c:60 ovl_open fs/overlayfs/file.c:156 [inline] ovl_open+0x125/0x270 fs/overlayfs/file.c:144 do_dentry_open+0x4b9/0x11b0 fs/open.c:826 do_open fs/namei.c:3365 [inline] path_openat+0x1c0e/0x27e0 fs/namei.c:3498 do_filp_open+0x17e/0x3c0 fs/namei.c:3525 do_sys_openat2+0x16d/0x420 fs/open.c:1187 do_sys_open fs/open.c:1203 [inline] __do_sys_openat fs/open.c:1219 [inline] __se_sys_openat fs/open.c:1214 [inline] __x64_sys_openat+0x13f/0x1f0 fs/open.c:1214 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 4854: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357 kasan_slab_free mm/kasan/common.c:360 [inline] kasan_slab_free mm/kasan/common.c:325 [inline] __kasan_slab_free+0xf5/0x130 mm/kasan/common.c:367 kasan_slab_free include/linux/kasan.h:199 [inline] slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x72/0x1b0 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x8b/0x730 mm/slub.c:3177 rcu_do_batch kernel/rcu/tree.c:2559 [inline] rcu_core+0x722/0x1280 kernel/rcu/tree.c:2794 __do_softirq+0x29b/0x9f6 kernel/softirq.c:345 Last potentially related work creation: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_record_aux_stack+0xe5/0x110 mm/kasan/generic.c:345 __call_rcu kernel/rcu/tree.c:3039 [inline] call_rcu+0xb1/0x700 kernel/rcu/tree.c:3114 task_work_run+0xdd/0x1a0 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:301
Re: [bugreport 5.9-rc8] general protection fault in __bfq_deactivate_entity
On Sun, Mar 7, 2021 at 3:15 AM Hillf Danton wrote: > > On Fri, 5 Mar 2021 18:01:04 +0800 Ming Lei wrote: > > On Fri, Mar 05, 2021 at 10:32:04AM +0100, Paolo Valente wrote: > > > I'm thinking of a way to debug this too. The symptom may hint at a > > > use-after-free. Could you enable KASAN in your tests? (On the flip > > > side, I know this might change timings, thereby making the fault > > > disappear). > > > > I have asked our QE to reproduce the issue with debug kernel, which may > > take a > > while. And I can't trigger it in my box. > > > > BTW, for the 2nd 'kernel NULL pointer dereference', the RIP points to: > > > > (gdb) l *(__bfq_deactivate_entity+0x5b) > > 0x814c31cb is in __bfq_deactivate_entity (block/bfq-wf2q.c:1181). > > 1176 * bfq_group_set_parent has already been invoked for the group > > 1177 * represented by entity. Therefore, the field > > 1178 * entity->sched_data has been set, and we can safely use it. > > 1179 */ > > 1180 st = bfq_entity_service_tree(entity); > > 1181 is_in_service = entity == sd->in_service_entity; > > 1182 > > 1183 bfq_calc_finish(entity, entity->service); > > 1184 > > 1185 if (is_in_service) > > > > Seems entity->sched_data points to NULL. > > Hi Ming, > > Thanks for your report. > > Given the invalid pointer cannot explain line 1180, you are reporting > a different issue from what Mike reported, and we can do nothing now > for both without a reproducer. > > Dmitry can you shed some light on the tricks to config kasan to print > Call Trace as the reports with the leading [syzbot] on the subject line do? +kasan-dev Hi Hillf, KASAN prints stack traces always unconditionally. There is nothing you need to do at all. Do you have any reports w/o stack traces? "[syzbot]" is prepend by syzbot code. If you want some prefix, you would need to prepend it manually. > > > Thanks, > > > Paolo > > > > > > > Il giorno 5 mar 2021, alle ore 10:27, Ming Lei > > > > ha scritto: > > > > > > > > Hello Hillf, > > > > > > > > Thanks for the debug patch. > > > > > > > > On Fri, Mar 5, 2021 at 5:00 PM Hillf Danton wrote: > > > >> > > > >> On Thu, 4 Mar 2021 16:42:30 +0800 Ming Lei wrote: > > > >>> On Sat, Oct 10, 2020 at 1:40 PM Mikhail Gavrilov > > > >>> wrote: > > > > > > Paolo, Jens I am sorry for the noise. > > > But today I hit the kernel panic and git blame said that you have > > > created the file in which happened panic (this I saw from trace) > > > > > > $ /usr/src/kernels/`uname -r`/scripts/faddr2line > > > /lib/debug/lib/modules/`uname -r`/vmlinux > > > __bfq_deactivate_entity+0x15a > > > __bfq_deactivate_entity+0x15a/0x240: > > > bfq_gt at block/bfq-wf2q.c:20 > > > (inlined by) bfq_insert at block/bfq-wf2q.c:381 > > > (inlined by) bfq_idle_insert at block/bfq-wf2q.c:621 > > > (inlined by) __bfq_deactivate_entity at block/bfq-wf2q.c:1203 > > > > > > https://github.com/torvalds/linux/blame/master/block/bfq-wf2q.c#L1203 > > > > > > $ head /sys/block/*/queue/scheduler > > > ==> /sys/block/nvme0n1/queue/scheduler <== > > > [none] mq-deadline kyber bfq > > > > > > ==> /sys/block/sda/queue/scheduler <== > > > mq-deadline kyber [bfq] none > > > > > > ==> /sys/block/zram0/queue/scheduler <== > > > none > > > > > > Trace: > > > general protection fault, probably for non-canonical address > > > 0x46b1b0f0d8856e4a: [#1] SMP NOPTI > > > CPU: 27 PID: 1018 Comm: kworker/27:1H Tainted: GW > > > - --- 5.9.0-0.rc8.28.fc34.x86_64 #1 > > > Hardware name: System manufacturer System Product Name/ROG STRIX > > > X570-I GAMING, BIOS 2606 08/13/2020 > > > Workqueue: kblockd blk_mq_run_work_fn > > > RIP: 0010:__bfq_deactivate_entity+0x15a/0x240 > > > Code: 48 2b 41 28 48 85 c0 7e 05 49 89 5c 24 18 49 8b 44 24 08 4d 8d > > > 74 24 08 48 85 c0 0f 84 d6 00 00 00 48 8b 7b 28 eb 03 48 89 c8 <48> > > > 8b > > > 48 28 48 8d 70 10 48 8d 50 08 48 29 f9 48 85 c9 48 0f 4f d6 > > > RSP: 0018:adf6c0c6fc00 EFLAGS: 00010002 > > > RAX: 46b1b0f0d8856e4a RBX: 8dc2773b5c88 RCX: 46b1b0f0d8856e4a > > > RDX: 8dc7d02ed0a0 RSI: 8dc7d02ed0a8 RDI: 584e64e96beb > > > RBP: 8dc2773b5c00 R08: 8dc9054cb938 R09: > > > R10: 0018 R11: 0018 R12: 8dc904927150 > > > R13: 0001 R14: 8dc904927158 R15: 8dc2773b5c88 > > > FS: () GS:8dc90e0c() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 80050033 > > > CR2: 003e8ebe4000 CR3: 0007c2546000 CR4: 00350ee0 > > > Call Trace: > > > bfq_deactivate_entity+0x4f/0xc0 > > > >>> > > > >>> Hello, > > > >>> > > > >>> The same stack trace was observed in RH internal
Re: [RFC v3] scripts: kernel-doc: fix typedef support for struct/union parsing
On 6/3/21 8:50 pm, Matthew Wilcox wrote: > On Sat, Mar 06, 2021 at 01:18:38PM +0530, Aditya wrote: >> On 6/3/21 11:55 am, Lukas Bulwahn wrote: >>> I agree. That might be a suitable clean-up to keep the code for >>> functions and struct/union parsing similar in style/spirit. >>> >>> Aditya, would you like to create a patch for that? >> >> Sure Lukas. >> I have a doubt though, Can't we use a single expression separated by >> "|" here, instead of multiple lines? i.e., >> >> $x =~ >> s/__packed|__aligned|cacheline_aligned_in_smp|cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)\s*//; >> >> >> Probably we could do something similar for dump_function, i.e., >> -$prototype =~ s/^static +//; >> -$prototype =~ s/^extern +//; >> -$prototype =~ s/^asmlinkage +//; >> -$prototype =~ s/^inline +//; >> -$prototype =~ s/^__inline__ +//; >> -$prototype =~ s/^__inline +//; >> -$prototype =~ s/^__always_inline +//; >> -$prototype =~ s/^noinline +//; >> >> +$prototype =~ >> s/^(?:static|extern|asmlinkage|__?inline__?|__always_inline|noinline) +//; >> And so on for other regexps. >> >> What do you think? > > I think there's a tradeoff between speed / compactness and readability. > As someone who doesn't know perl particularly well, I can look at the > series of lines and say "Oh, it's stripping out these unwanted things". > Your one line, while undoubtedly more efficient, is considerably less > easy to understand. > > Maybe there's another way to do it that's more efficient while not > sacrificing the readability? > > Also, would your suggestion work for 'static inline void foo(void)'? > I think it needs to remove multiple occurrences of the things in the > regex. Ah, I get it. But maybe that's what the ?: on the beginning is for? > No, "?:" is just to use this regex for matching, without capturing. So, the regex will just remove any of those 'starting' occurrences, consequently, "static inline" occurrence will probably not be removed. I think the reason for using multiple lines for substitution in dump_function is for the same reason, ie, subsequent substitution. But for dump_struct, it is probably not desired, i.e., subsequent substitution/removal. Also, for the same reason, using it with dump_struct may cause unwelcomed discrepancies, or cause the user to understand that here multiple substitutions are required, but is not so. So, I think that we should use a single expression substitution for dump_struct, at best. But am not sure if that is required, as currently also we are not capturing this part of the regex, as well as, matching only at certain position of the definition expression. But I am curious to what others think about this. Will be happy to work on this patch :) Thanks Aditya
[syzbot] general protection fault in bt_accept_unlink (2)
Hello, syzbot found the following issue on: HEAD commit:95b39f07 net: ethernet: mtk-star-emac: fix wrong unmap in .. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=13658a5cd0 kernel config: https://syzkaller.appspot.com/x/.config?x=e2d5ba72abae4f14 dashboard link: https://syzkaller.appspot.com/bug?extid=582be673ab4f59f68c5e Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+582be673ab4f59f68...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xf7775c001777: [#1] PREEMPT SMP KASAN KASAN: maybe wild-memory-access in range [0xbbb8-0xbbbf] CPU: 0 PID: 6057 Comm: kworker/0:6 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events l2cap_chan_timeout RIP: 0010:__list_del_entry_valid+0x81/0xf0 lib/list_debug.c:51 Code: 0f 84 af d4 08 05 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 b0 d4 08 05 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 51 49 8b 14 24 48 39 ea 0f 85 67 d4 08 05 49 8d 7d RSP: 0018:c90002bafb28 EFLAGS: 00010a06 RAX: dc00 RBX: 8880283424b8 RCX: RDX: 177760001777 RSI: 87ebecff RDI: 8880283424c0 RBP: 8880283424b8 R08: 8a7af760 R09: 87f99626 R10: 0004 R11: 0005 R12: R13: bb00 R14: 888028341020 R15: 0005 FS: () GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 02349848 CR3: 18f19000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_del_entry include/linux/list.h:132 [inline] list_del_init include/linux/list.h:204 [inline] bt_accept_unlink+0x35/0x2f0 net/bluetooth/af_bluetooth.c:187 l2cap_sock_teardown_cb+0x197/0x660 net/bluetooth/l2cap_sock.c:1542 l2cap_chan_del+0xbc/0xa80 net/bluetooth/l2cap_core.c:618 l2cap_chan_close+0x1bc/0xaf0 net/bluetooth/l2cap_core.c:823 l2cap_chan_timeout+0x17e/0x2f0 net/bluetooth/l2cap_core.c:436 process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: ---[ end trace 7d7f7782958a606a ]--- RIP: 0010:__list_del_entry_valid+0x81/0xf0 lib/list_debug.c:51 Code: 0f 84 af d4 08 05 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 b0 d4 08 05 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 51 49 8b 14 24 48 39 ea 0f 85 67 d4 08 05 49 8d 7d RSP: 0018:c90002bafb28 EFLAGS: 00010a06 RAX: dc00 RBX: 8880283424b8 RCX: RDX: 177760001777 RSI: 87ebecff RDI: 8880283424c0 RBP: 8880283424b8 R08: 8a7af760 R09: 87f99626 R10: 0004 R11: 0005 R12: R13: bb00 R14: 888028341020 R15: 0005 FS: () GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f53667bf000 CR3: 2623d000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report 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 issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH RESEND v2 STABLE 4.4] futex: fix irq self-deadlock and satisfy assertion
From: Thomas Schoebel-Theuer
This patch and problem analysis is specific for 4.4 LTS, due to incomplete
backporting of other fixes. Later LTS series have different backports.
Since v4.4.257 when CONFIG_PROVE_LOCKING=y
the following triggers right after reboot of our pre-life systems
which equal our production setup:
Mar 03 11:27:33 icpu-test-bap10 kernel: =
Mar 03 11:27:33 icpu-test-bap10 kernel: [ INFO: inconsistent lock state ]
Mar 03 11:27:33 icpu-test-bap10 kernel: 4.4.259-rc1-grsec+ #730 Not tainted
Mar 03 11:27:33 icpu-test-bap10 kernel: -
Mar 03 11:27:33 icpu-test-bap10 kernel: inconsistent {IN-HARDIRQ-W} ->
{HARDIRQ-ON-W} usage.
Mar 03 11:27:33 icpu-test-bap10 kernel: apache2-ssl/9310
[HC0[0]:SC0[0]:HE1:SE1] takes:
Mar 03 11:27:33 icpu-test-bap10 kernel: (>pi_lock){?.-.-.}, at:
[] pi_state_update_owner+0x51/0xd7
Mar 03 11:27:33 icpu-test-bap10 kernel: {IN-HARDIRQ-W} state was registered at:
Mar 03 11:27:33 icpu-test-bap10 kernel: []
__lock_acquire+0x3a7/0xe4a
Mar 03 11:27:33 icpu-test-bap10 kernel: []
lock_acquire+0x18d/0x1bc
Mar 03 11:27:33 icpu-test-bap10 kernel: []
_raw_spin_lock_irqsave+0x3e/0x50
Mar 03 11:27:33 icpu-test-bap10 kernel: []
try_to_wake_up+0x2c/0x210
Mar 03 11:27:33 icpu-test-bap10 kernel: []
default_wake_function+0xd/0xf
Mar 03 11:27:33 icpu-test-bap10 kernel: []
autoremove_wake_function+0x11/0x35
Mar 03 11:27:33 icpu-test-bap10 kernel: []
__wake_up_common+0x48/0x7c
Mar 03 11:27:33 icpu-test-bap10 kernel: []
__wake_up+0x34/0x46
Mar 03 11:27:33 icpu-test-bap10 kernel: []
megasas_complete_int_cmd+0x31/0x33
Mar 03 11:27:33 icpu-test-bap10 kernel: []
megasas_complete_cmd+0x570/0x57b
Mar 03 11:27:33 icpu-test-bap10 kernel: []
complete_cmd_fusion+0x23e/0x33d
Mar 03 11:27:33 icpu-test-bap10 kernel: []
megasas_isr_fusion+0x67/0x74
Mar 03 11:27:33 icpu-test-bap10 kernel: []
handle_irq_event_percpu+0x134/0x311
Mar 03 11:27:33 icpu-test-bap10 kernel: []
handle_irq_event+0x33/0x51
Mar 03 11:27:33 icpu-test-bap10 kernel: []
handle_edge_irq+0xa3/0xc2
Mar 03 11:27:33 icpu-test-bap10 kernel: []
handle_irq+0xf9/0x101
Mar 03 11:27:33 icpu-test-bap10 kernel: [] do_IRQ+0x80/0xf5
Mar 03 11:27:33 icpu-test-bap10 kernel: []
ret_from_intr+0x0/0x20
Mar 03 11:27:33 icpu-test-bap10 kernel: []
arch_cpu_idle+0xa/0xc
Mar 03 11:27:33 icpu-test-bap10 kernel: []
default_idle_call+0x1e/0x20
Mar 03 11:27:33 icpu-test-bap10 kernel: []
cpu_startup_entry+0x141/0x22f
Mar 03 11:27:33 icpu-test-bap10 kernel: []
rest_init+0x135/0x13b
Mar 03 11:27:33 icpu-test-bap10 kernel: []
start_kernel+0x3fa/0x40a
Mar 03 11:27:33 icpu-test-bap10 kernel: []
x86_64_start_reservations+0x2a/0x2c
Mar 03 11:27:33 icpu-test-bap10 kernel: []
x86_64_start_kernel+0x11f/0x12c
Mar 03 11:27:33 icpu-test-bap10 kernel: irq event stamp: 1457
Mar 03 11:27:33 icpu-test-bap10 kernel: hardirqs last enabled at (1457):
[] get_user_pages_fast+0xeb/0x14f
Mar 03 11:27:33 icpu-test-bap10 kernel: hardirqs last disabled at (1456):
[] get_user_pages_fast+0x5f/0x14f
Mar 03 11:27:33 icpu-test-bap10 kernel: softirqs last enabled at (1446):
[] release_sock+0x142/0x14d
Mar 03 11:27:33 icpu-test-bap10 kernel: softirqs last disabled at (1444):
[] release_sock+0x34/0x14d
Mar 03 11:27:33 icpu-test-bap10 kernel:
other info that might help us debug
this:
Mar 03 11:27:33 icpu-test-bap10 kernel: Possible unsafe locking scenario:
Mar 03 11:27:33 icpu-test-bap10 kernel:CPU0
Mar 03 11:27:33 icpu-test-bap10 kernel:
Mar 03 11:27:33 icpu-test-bap10 kernel: lock(>pi_lock);
Mar 03 11:27:33 icpu-test-bap10 kernel:
Mar 03 11:27:33 icpu-test-bap10 kernel: lock(>pi_lock);
Mar 03 11:27:33 icpu-test-bap10 kernel:
*** DEADLOCK ***
Mar 03 11:27:33 icpu-test-bap10 kernel: 2 locks held by apache2-ssl/9310:
Mar 03 11:27:33 icpu-test-bap10 kernel: #0:
(&(&(__futex_data.queues)[i].lock)->rlock){+.+...}, at: [] do
Mar 03 11:27:33 icpu-test-bap10 kernel: #1: (>wait_lock){+.+...}, at:
[] do_futex+0x639/0x809
Mar 03 11:27:33 icpu-test-bap10 kernel:
stack backtrace:
Mar 03 11:27:33 icpu-test-bap10 kernel: CPU: 13 PID: 9310 UID: 99 Comm:
apache2-ssl Not tainted 4.4.259-rc1-grsec+ #730
Mar 03 11:27:33 icpu-test-bap10 kernel: Hardware name: Dell Inc. PowerEdge
R630/02C2CP, BIOS 2.11.0 11/02/2019
Mar 03 11:27:33 icpu-test-bap10 kernel: 883fb79bfc00
816f8fc2 883ffa66d300
Mar 03 11:27:33 icpu-test-bap10 kernel: 8eaa71f0 883fb79bfc50
81088484
Mar 03 11:27:33 icpu-test-bap10 kernel: 0001 0001
0002 883ffa66db58
Mar 03 11:27:33 icpu-test-bap10 kernel: Call Trace:
Mar 03 11:27:33 icpu-test-bap10 kernel: []
dump_stack+0x94/0xca
Mar 03 11:27:33 icpu-test-bap10 kernel: []
[PATCH RESEND v2 STABLE 4.4] futex: fix spin_lock() / spin_unlock_irq() imbalance
From: Thomas Schoebel-Theuer
This patch and problem analysis is specific for 4.4 LTS, due to incomplete
backporting of other fixes. Later LTS series have different backports.
The following is obviously incorrect:
static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this,
struct futex_hash_bucket *hb)
{
[...]
raw_spin_lock(_state->pi_mutex.wait_lock);
[...]
raw_spin_unlock_irq(_state->pi_mutex.wait_lock);
[...]
}
The 4.4-specific fix should probably go in the direction of
b4abf91047c,
making everything irq-safe.
Probably, backporting of b4abf91047c
to 4.4 LTS could thus be another good idea.
However, this might involve some more 4.4-specific work and
require thorough testing:
> git log --oneline v4.4..b4abf91047c -- kernel/futex.c
> kernel/locking/rtmutex.c | wc -l
10
So this patch is just an obvious quickfix for now.
Hint: the lock order is documented in 4.9.y and later. A similar
documenting is missing in 4.4.y. Please somebody either backport also,
or write a new description, if there would be some differences I cannot
easily see at the moment. Without reliable docs,
inspection of the locking correctness may become a pain.
Signed-off-by: Thomas Schoebel-Theuer
Cc: Thomas Gleixner
Cc: Lee Jones
Cc: Greg Kroah-Hartman
Fixes: 394fc498142
Fixes: 6510e4a2d04
---
kernel/futex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 70ad21bbb1d5..4a707bc7cceb 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1406,7 +1406,7 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval,
struct futex_q *this,
if (pi_state->owner != current)
return -EINVAL;
- raw_spin_lock(_state->pi_mutex.wait_lock);
+ raw_spin_lock_irq(_state->pi_mutex.wait_lock);
new_owner = rt_mutex_next_owner(_state->pi_mutex);
/*
--
2.26.2
[PATCH] ASoC: codecs/jz4770: Remove superfluous error message
The function devm_platform_ioremap_resource has already contained
error message if failed, so remove superfluous dev_err here.
Signed-off-by: Zhang Shengju
Signed-off-by: Tang Bin
---
sound/soc/codecs/jz4770.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/jz4770.c b/sound/soc/codecs/jz4770.c
index 298689a07..5a24471a5 100644
--- a/sound/soc/codecs/jz4770.c
+++ b/sound/soc/codecs/jz4770.c
@@ -900,11 +900,8 @@ static int jz4770_codec_probe(struct platform_device *pdev)
codec->dev = dev;
codec->base = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(codec->base)) {
- ret = PTR_ERR(codec->base);
- dev_err(dev, "Failed to ioremap mmio memory: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(codec->base))
+ return PTR_ERR(codec->base);
codec->regmap = devm_regmap_init(dev, NULL, codec,
_codec_regmap_config);
--
2.20.1.windows.1
Re: [PATCH v2] MIPS: kernel: Reserve exception base early to prevent corruption
On Sat, Mar 06, 2021 at 09:29:09AM +0100, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
> Before the cited commit, early allocations would be in the [kernel_end,
> RAM_END] range, but after commit they would be within [RAM_START +
> PAGE_SIZE, RAM_END].
>
> The custom exception base handler that is installed by
> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
> memory region allocated by unflatten_and_copy_device_tree() thus
> corrupting the FDT used by the kernel.
>
> To fix this, we need to perform an early reservation of the custom
> exception space. So we reserve it already in cpu_probe() for the CPUs
> where this is fixed. For CPU with an ebase config register allocation
> of exception space will be done in trap_init().
>
> Huge thanks to Serget for analysing and proposing a solution to this
> issue.
>
> Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with
> kernel_end")
> Reported-by: Kamal Dasu
> Debugged-by: Serge Semin
> Signed-off-by: Thomas Bogendoerfer
Acked-by: Mike Rapoport
> ---
> Changes in v2:
> - do only memblock reservation in reserve_exception_space()
> - reserve 0..0x400 for all CPUs without ebase register and
>to addtional reserve_exception_space for BMIPS CPUs
>
> arch/mips/include/asm/traps.h| 3 +++
> arch/mips/kernel/cpu-probe.c | 7 +++
> arch/mips/kernel/cpu-r3k-probe.c | 3 +++
> arch/mips/kernel/traps.c | 10 +-
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
> index 6aa8f126a43d..b710e76c9c65 100644
> --- a/arch/mips/include/asm/traps.h
> +++ b/arch/mips/include/asm/traps.h
> @@ -24,8 +24,11 @@ extern void (*board_ebase_setup)(void);
> extern void (*board_cache_error_setup)(void);
>
> extern int register_nmi_notifier(struct notifier_block *nb);
> +extern void reserve_exception_space(phys_addr_t addr, unsigned long size);
> extern char except_vec_nmi[];
>
> +#define VECTORSPACING 0x100 /* for EI/VI mode */
> +
> #define nmi_notifier(fn, pri)
> \
> ({ \
> static struct notifier_block fn##_nb = {\
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index 9a89637b4ecf..b565bc4b900d 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "fpu-probe.h"
> @@ -1628,6 +1629,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> c->cputype = CPU_BMIPS3300;
> __cpu_name[cpu] = "Broadcom BMIPS3300";
> set_elf_platform(cpu, "bmips3300");
> + reserve_exception_space(0x400, VECTORSPACING * 64);
> break;
> case PRID_IMP_BMIPS43XX: {
> int rev = c->processor_id & PRID_REV_MASK;
> @@ -1638,6 +1640,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS4380";
> set_elf_platform(cpu, "bmips4380");
> c->options |= MIPS_CPU_RIXI;
> + reserve_exception_space(0x400, VECTORSPACING * 64);
> } else {
> c->cputype = CPU_BMIPS4350;
> __cpu_name[cpu] = "Broadcom BMIPS4350";
> @@ -1654,6 +1657,7 @@ static inline void cpu_probe_broadcom(struct
> cpuinfo_mips *c, unsigned int cpu)
> __cpu_name[cpu] = "Broadcom BMIPS5000";
> set_elf_platform(cpu, "bmips5000");
> c->options |= MIPS_CPU_ULRI | MIPS_CPU_RIXI;
> + reserve_exception_space(0x1000, VECTORSPACING * 64);
> break;
> }
> }
> @@ -2133,6 +2137,9 @@ void cpu_probe(void)
> if (cpu == 0)
> __ua_limit = ~((1ull << cpu_vmbits) - 1);
> #endif
> +
> + if (cpu_has_mips_r2_r6)
> + reserve_exception_space(0, 0x400);
> }
>
> void cpu_report(void)
> diff --git a/arch/mips/kernel/cpu-r3k-probe.c
> b/arch/mips/kernel/cpu-r3k-probe.c
> index abdbbe8c5a43..af654771918c 100644
> --- a/arch/mips/kernel/cpu-r3k-probe.c
> +++ b/arch/mips/kernel/cpu-r3k-probe.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "fpu-probe.h"
>
> @@ -158,6 +159,8 @@ void cpu_probe(void)
> cpu_set_fpu_opts(c);
> else
> cpu_set_nofpu_opts(c);
> +
> + reserve_exception_space(0, 0x400);
> }
>
> void cpu_report(void)
> diff --git a/arch/mips/kernel/traps.c
Re: [PATCH] leds: trigger: fix potential deadlock with libata
On Sun, Mar 07, 2021 at 10:02:32AM +0800, Boqun Feng wrote:
> On Sat, Mar 06, 2021 at 09:39:54PM +0100, Marc Kleine-Budde wrote:
> > Hello *,
> >
> > On 02.11.2020 11:41:52, Andrea Righi wrote:
> > > We have the following potential deadlock condition:
> > >
> > >
> > > WARNING: possible irq lock inversion dependency detected
> > > 5.10.0-rc2+ #25 Not tainted
> > >
> > > swapper/3/0 just changed the state of lock:
> > > 8880063bd618 (>lock){-...}-{2:2}, at:
> > > ata_bmdma_interrupt+0x27/0x200
> > > but this lock took another, HARDIRQ-READ-unsafe lock in the past:
> > > (>leddev_list_lock){.+.?}-{2:2}
> > >
> > > and interrupts could create inverse lock ordering between them.
> >
> > [...]
> >
> > > ---
> > > drivers/leds/led-triggers.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> > > index 91da90cfb11d..16d1a93a10a8 100644
> > > --- a/drivers/leds/led-triggers.c
> > > +++ b/drivers/leds/led-triggers.c
> > > @@ -378,14 +378,15 @@ void led_trigger_event(struct led_trigger *trig,
> > > enum led_brightness brightness)
> > > {
> > > struct led_classdev *led_cdev;
> > > + unsigned long flags;
> > >
> > > if (!trig)
> > > return;
> > >
> > > - read_lock(>leddev_list_lock);
> > > + read_lock_irqsave(>leddev_list_lock, flags);
> > > list_for_each_entry(led_cdev, >led_cdevs, trig_list)
> > > led_set_brightness(led_cdev, brightness);
> > > - read_unlock(>leddev_list_lock);
> > > + read_unlock_irqrestore(>leddev_list_lock, flags);
> > > }
> > > EXPORT_SYMBOL_GPL(led_trigger_event);
> >
> > meanwhile this patch hit v5.10.x stable and caused a performance
> > degradation on our use case:
> >
> > It's an embedded ARM system, 4x Cortex A53, with an SPI attached CAN
> > controller. CAN stands for Controller Area Network and here used to
> > connect to some automotive equipment. Over CAN an ISOTP (a CAN-specific
> > Transport Protocol) transfer is running. With this patch, we see CAN
> > frames delayed for ~6ms, the usual gap between CAN frames is 240µs.
> >
> > Reverting this patch, restores the old performance.
> >
> > What is the best way to solve this dilemma? Identify the critical path
> > in our use case? Is there a way we can get around the irqsave in
> > led_trigger_event()?
> >
>
> Probably, we can change from rwlock to rcu here, POC code as follow,
> only compile tested. Marc, could you see whether this help the
> performance on your platform? Please note that I haven't test it in a
> running kernel and I'm not that familir with led subsystem, so use it
> with caution ;-)
If we don't want to touch the led subsystem at all maybe we could try to
fix the problem in libata, we just need to prevent calling
led_trigger_blink_oneshot() with >lock held from
ata_qc_complete(), maybe doing the led blinking from another context (a
workqueue for example)?
-Andrea
[PATCH v10 3/6] clk: ralink: add clock driver for mt7621 SoC
The documentation for this SOC only talks about two
registers regarding to the clocks:
* SYSC_REG_CPLL_CLKCFG0 - provides some information about
boostrapped refclock. PLL and dividers used for CPU and some
sort of BUS.
* SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable
clocks for all or some ip cores.
Looking into driver code, and some openWRT patched there are
another frequencies which are used in some drivers (uart, sd...).
According to all of this information the clock plan for this
SoC is set as follows:
- Main top clock "xtal" from where all the rest of the world is
derived.
- CPU clock "cpu" derived from "xtal" frequencies and a bunch of
register reads and predividers.
- BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz.
- Fixed clocks from "xtal":
* "50m": 50 MHz.
* "125m": 125 MHz.
* "150m": 150 MHz.
* "250m": 250 MHz.
* "270m": 270 MHz.
We also have a buch of gate clocks with their parents:
* "hsdma": "150m"
* "fe": "250m"
* "sp_divtx": "270m"
* "timer": "50m"
* "pcm": "270m"
* "pio": "50m"
* "gdma": "bus"
* "nand": "125m"
* "i2c": "50m"
* "i2s": "270m"
* "spi": "bus"
* "uart1": "50m"
* "uart2": "50m"
* "uart3": "50m"
* "eth": "50m"
* "pcie0": "125m"
* "pcie1": "125m"
* "pcie2": "125m"
* "crypto": "250m"
* "shxc": "50m"
With this information the clk driver will provide clock and gates
functionality from a a set of hardcoded clocks allowing to define
a nice device tree without fixed clocks.
Signed-off-by: Sergio Paracuellos
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile| 1 +
drivers/clk/ralink/Kconfig | 15 +
drivers/clk/ralink/Makefile | 2 +
drivers/clk/ralink/clk-mt7621.c | 528
5 files changed, 547 insertions(+)
create mode 100644 drivers/clk/ralink/Kconfig
create mode 100644 drivers/clk/ralink/Makefile
create mode 100644 drivers/clk/ralink/clk-mt7621.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 7c5dc348c16f..70b23da997bf 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -382,6 +382,7 @@ source "drivers/clk/mediatek/Kconfig"
source "drivers/clk/meson/Kconfig"
source "drivers/clk/mvebu/Kconfig"
source "drivers/clk/qcom/Kconfig"
+source "drivers/clk/ralink/Kconfig"
source "drivers/clk/renesas/Kconfig"
source "drivers/clk/rockchip/Kconfig"
source "drivers/clk/samsung/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5325847469e9..1b35ad852721 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_COMMON_CLK_NXP) += nxp/
obj-$(CONFIG_MACH_PISTACHIO) += pistachio/
obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
+obj-y += ralink/
obj-y += renesas/
obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig
new file mode 100644
index ..3e3f5cb9ad88
--- /dev/null
+++ b/drivers/clk/ralink/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# MediaTek Mt7621 Clock Driver
+#
+menu "Clock driver for Mediatek mt7621 SoC"
+ depends on SOC_MT7621 || COMPILE_TEST
+
+config CLK_MT7621
+ bool "Clock driver for MediaTek MT7621"
+ depends on SOC_MT7621 || COMPILE_TEST
+ default SOC_MT7621
+ select MFD_SYSCON
+ help
+ This driver supports MediaTek MT7621 basic clocks.
+endmenu
diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
new file mode 100644
index ..cf6f9216379d
--- /dev/null
+++ b/drivers/clk/ralink/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c
new file mode 100644
index ..6aea5accd51c
--- /dev/null
+++ b/drivers/clk/ralink/clk-mt7621.c
@@ -0,0 +1,528 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek MT7621 Clock Driver
+ * Author: Sergio Paracuellos
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Configuration registers */
+#define SYSC_REG_SYSTEM_CONFIG0 0x10
+#define SYSC_REG_SYSTEM_CONFIG1 0x14
+#define SYSC_REG_CLKCFG0 0x2c
+#define SYSC_REG_CLKCFG1 0x30
+#define SYSC_REG_CUR_CLK_STS 0x44
+#define MEMC_REG_CPU_PLL 0x648
+
+#define XTAL_MODE_SEL_MASK GENMASK(8, 6)
+#define CPU_CLK_SEL_MASK GENMASK(31, 30)
+#define CUR_CPU_FDIV_MASK GENMASK(12, 8)
+#define CUR_CPU_FFRAC_MASK GENMASK(4, 0)
+#define CPU_PLL_PREDIV_MASKGENMASK(13, 12)
+#define CPU_PLL_FBDIV_MASK GENMASK(10, 4)
+
+struct mt7621_clk_priv {
+ struct regmap *sysc;
+
[PATCH v10 6/6] MAINTAINERS: add MT7621 CLOCK maintainer
Adding myself as maintainer for mt7621 clock driver. Signed-off-by: Sergio Paracuellos --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 809a68af5efd..be5ada6b4309 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11288,6 +11288,12 @@ L: linux-wirel...@vger.kernel.org S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ +MEDIATEK MT7621 CLOCK DRIVER +M: Sergio Paracuellos +S: Maintained +F: Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml +F: drivers/clk/ralink/clk-mt7621.c + MEDIATEK MT7621/28/88 I2C DRIVER M: Stefan Roese L: linux-...@vger.kernel.org -- 2.25.1
[PATCH v10 5/6] staging: mt7621-dts: use valid vendor 'mediatek' instead of invalid 'mtk'
Vendor listed for mediatek in kernel vendor file 'vendor-prefixes.yaml'
contains 'mediatek' as a valid vendor string. Some nodes in the device
tree are using an invalid vendor string vfor 'mtk' instead. Fix all of
them in dts file. Update also ralink mt7621 related code to properly
match new strings. Even there are used in the device tree there are
some strings that are not referred anywhere but have been also updated
with new vendor name. These are 'mtk,mt7621-wdt', 'mtk,mt7621-nand',
'mtk,mt7621-mc', and 'mtk,mt7621-cpc'.
Acked-by: Greg Kroah-Hartman
Signed-off-by: Sergio Paracuellos
---
arch/mips/ralink/mt7621.c | 6 +++---
drivers/staging/mt7621-dts/mt7621.dtsi | 12 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index ca0ac607b0f3..5d74fc1c96ac 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -112,8 +112,8 @@ phys_addr_t mips_cpc_default_phys_base(void)
void __init ralink_of_remap(void)
{
- rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
- rt_memc_membase = plat_of_remap_node("mtk,mt7621-memc");
+ rt_sysc_membase = plat_of_remap_node("mediatek,mt7621-sysc");
+ rt_memc_membase = plat_of_remap_node("mediatek,mt7621-memc");
if (!rt_sysc_membase || !rt_memc_membase)
panic("Failed to remap core resources");
@@ -181,7 +181,7 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
if (n0 == MT7621_CHIP_NAME0 && n1 == MT7621_CHIP_NAME1) {
name = "MT7621";
- soc_info->compatible = "mtk,mt7621-soc";
+ soc_info->compatible = "mediatek,mt7621-soc";
} else {
panic("mt7621: unknown SoC, n0:%08x n1:%08x\n", n0, n1);
}
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index b68183e7e6ad..f0c9ae757bcd 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -56,7 +56,7 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc", "syscon";
+ compatible = "mediatek,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
#clock-cells = <1>;
ralink,memctl = <>;
@@ -66,7 +66,7 @@ sysc: sysc@0 {
};
wdt: wdt@100 {
- compatible = "mtk,mt7621-wdt";
+ compatible = "mediatek,mt7621-wdt";
reg = <0x100 0x100>;
};
@@ -123,17 +123,17 @@ i2s: i2s@a00 {
};
memc: memc@5000 {
- compatible = "mtk,mt7621-memc", "syscon";
+ compatible = "mediatek,mt7621-memc", "syscon";
reg = <0x5000 0x1000>;
};
cpc: cpc@1fbf {
-compatible = "mtk,mt7621-cpc";
+compatible = "mediatek,mt7621-cpc";
reg = <0x1fbf 0x8000>;
};
mc: mc@1fbf8000 {
- compatible = "mtk,mt7621-mc";
+ compatible = "mediatek,mt7621-mc";
reg = <0x1fbf8000 0x8000>;
};
@@ -361,7 +361,7 @@ timer {
nand: nand@1e003000 {
status = "disabled";
- compatible = "mtk,mt7621-nand";
+ compatible = "mediatek,mt7621-nand";
bank-width = <2>;
reg = <0x1e003000 0x800
0x1e003800 0x800>;
--
2.25.1
[PATCH v10 2/6] dt: bindings: add mt7621-sysc device tree binding documentation
Adds device tree binding documentation for clocks in the
MT7621 SOC.
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-sysc.yaml | 68 +++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
new file mode 100644
index ..ef2d71b23ba0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-sysc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 Clock Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos
+
+description: |
+ The MT7621 has a PLL controller from where the cpu clock is provided
+ as well as derived clocks for the bus and the peripherals. It also
+ can gate SoC device clocks.
+
+ Each clock is assigned an identifier and client nodes use this identifier
+ to specify the clock which they consume.
+
+ All these identifiers could be found in:
+ [1]: .
+
+ The clocks are provided inside a system controller node.
+
+properties:
+ compatible:
+items:
+ - const: mediatek,mt7621-sysc
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ "#clock-cells":
+description:
+ The first cell indicates the clock number, see [1] for available
+ clocks.
+const: 1
+
+ ralink,memctl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle of syscon used to control memory registers
+
+ clock-output-names:
+maxItems: 8
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - ralink,memctl
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+sysc: sysc@0 {
+ compatible = "mediatek,mt7621-sysc", "syscon";
+ reg = <0x0 0x100>;
+ #clock-cells = <1>;
+ ralink,memctl = <>;
+ clock-output-names = "xtal", "cpu", "bus",
+ "50m", "125m", "150m",
+ "250m", "270m";
+};
--
2.25.1
[PATCH v10 4/6] staging: mt7621-dts: make use of new 'mt7621-clk'
Clocks for SoC mt7621 have been properly integrated so there is
no need to declare fixed clocks at all in the device tree. Remove
all of them, add new device tree nodes for mt7621-clk and update
the rest of the nodes to use them.
Acked-by: Greg Kroah-Hartman
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/gbpc1.dts | 11
drivers/staging/mt7621-dts/mt7621.dtsi | 74 --
2 files changed, 33 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index a7c0d3115d72..7716d0efe524 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -100,17 +100,6 @@ partition@5 {
};
};
- {
- compatible = "fixed-clock";
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22500>;
-};
-
- {
- compatible = "fixed-clock";
- clock-frequency = <9>;
-};
-
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 16fc94f65486..b68183e7e6ad 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,5 +1,6 @@
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -27,27 +28,6 @@ aliases {
serial0 =
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
- };
-
- sysclock: sysclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22000>;
- };
-
- mmc_clock: mmc_clock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <4800>;
- };
mmc_fixed_3v3: fixedregulator@0 {
compatible = "regulator-fixed";
@@ -76,8 +56,13 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc";
+ compatible = "mtk,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
+ #clock-cells = <1>;
+ ralink,memctl = <>;
+ clock-output-names = "xtal", "cpu", "bus",
+"50m", "125m", "150m",
+"250m", "270m";
};
wdt: wdt@100 {
@@ -101,8 +86,8 @@ i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
- clocks = <>;
-
+ clocks = < MT7621_CLK_I2C>;
+ clock-names = "i2c";
resets = < 16>;
reset-names = "i2c";
@@ -119,8 +104,8 @@ i2s: i2s@a00 {
compatible = "mediatek,mt7621-i2s";
reg = <0xa00 0x100>;
- clocks = <>;
-
+ clocks = < MT7621_CLK_I2S>;
+ clock-names = "i2s";
resets = < 17>;
reset-names = "i2s";
@@ -138,7 +123,7 @@ i2s: i2s@a00 {
};
memc: memc@5000 {
- compatible = "mtk,mt7621-memc";
+ compatible = "mtk,mt7621-memc", "syscon";
reg = <0x5000 0x1000>;
};
@@ -156,8 +141,8 @@ uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <>;
- clock-frequency = <5000>;
+ clocks = < MT7621_CLK_UART1>;
+ clock-names = "uart1";
interrupt-parent = <>;
interrupts = ;
@@ -173,7 +158,8 @@ spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <>;
+ clocks = < MT7621_CLK_SPI>;
+ clock-names = "spi";
resets = < 18>;
reset-names = "spi";
@@ -189,6 +175,8 @@ gdma: gdma@2800 {
compatible = "ralink,rt3883-gdma";
reg = <0x2800 0x800>;
+ clocks = < MT7621_CLK_GDMA>;
+ clock-names = "gdma";
resets = < 14>;
reset-names = "dma";
@@ -206,6 +194,8 @@ hsdma: hsdma@7000 {
[PATCH v10 1/6] dt-bindings: clock: add dt binding header for mt7621 clocks
Adds dt binding header for 'mediatek,mt7621-clk' clocks. Acked-by: Rob Herring Signed-off-by: Sergio Paracuellos --- include/dt-bindings/clock/mt7621-clk.h | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 include/dt-bindings/clock/mt7621-clk.h diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h new file mode 100644 index ..1422badcf9de --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Author: Sergio Paracuellos + */ + +#ifndef _DT_BINDINGS_CLK_MT7621_H +#define _DT_BINDINGS_CLK_MT7621_H + +#define MT7621_CLK_XTAL0 +#define MT7621_CLK_CPU 1 +#define MT7621_CLK_BUS 2 +#define MT7621_CLK_50M 3 +#define MT7621_CLK_125M4 +#define MT7621_CLK_150M5 +#define MT7621_CLK_250M6 +#define MT7621_CLK_270M7 + +#define MT7621_CLK_HSDMA 8 +#define MT7621_CLK_FE 9 +#define MT7621_CLK_SP_DIVTX10 +#define MT7621_CLK_TIMER 11 +#define MT7621_CLK_PCM 12 +#define MT7621_CLK_PIO 13 +#define MT7621_CLK_GDMA14 +#define MT7621_CLK_NAND15 +#define MT7621_CLK_I2C 16 +#define MT7621_CLK_I2S 17 +#define MT7621_CLK_SPI 18 +#define MT7621_CLK_UART1 19 +#define MT7621_CLK_UART2 20 +#define MT7621_CLK_UART3 21 +#define MT7621_CLK_ETH 22 +#define MT7621_CLK_PCIE0 23 +#define MT7621_CLK_PCIE1 24 +#define MT7621_CLK_PCIE2 25 +#define MT7621_CLK_CRYPTO 26 +#define MT7621_CLK_SHXC27 + +#define MT7621_CLK_MAX 28 + +#endif /* _DT_BINDINGS_CLK_MT7621_H */ -- 2.25.1
[PATCH v10 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt and adds a complete clock plan for the mt7621 SOC. The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. Registers needed for this driver to work are in two already mapped areas in its platform's device tree. These are 'sysc' and 'memc' nodes. Most of other drivers just make use of platform operations defined in 'asm/mach-ralink/ralink_regs.h' but this can be avoided declaring this two nodes to be accesible through syscon. Main registers for the clocks are in the sysc control node so this node is merged with clock properties and will also be the clock provider for the SoC. No documentation about a probably existent set of dividers for each ip core is included in the datasheets. So we cannot make anything better, AFAICT. Looking into driver code, and some openWRT patched there are another frequences which are used in some drivers (uart, sd...). According to all of this information the clock plan for this SoC is set as follows: - Main top clock "xtal" from where all the rest of the world is derived. - CPU clock "cpu" derived from "xtal" frequencies and a bunch of register reads and predividers. - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. - Fixed clocks from "xtal": * "50m": 50 MHz. * "125m": 125 MHz. * "150m": 150 MHz. * "250m": 250 MHz. * "270m": 270 MHz. We also have a buch of gate clocks with their parents: - "hsdma": "150m" - "fe": "250m" - "sp_divtx": "270m" - "timer": "50m" - "pcm": "270m" - "pio": "50m" - "gdma": "bus" - "nand": "125m" - "i2c": "50m" - "i2s": "270m" - "spi": "bus" - "uart1": "50m" - "uart2": "50m" - "uart3": "50m" - "eth": "50m" - "pcie0": "125m" - "pcie1": "125m" - "pcie2": "125m" - "crypto": "250m" - "shxc": "50m" There was a previous attempt of doing this here[0] but the author (Chuanhong Guo) did not wanted to make assumptions of a clock plan for the platform that time. It seems that now he has a better idea of how the clocks are dispossed for this SoC so he share code[1] where some frequencies and clock parents for the gates are coded from a real mediatek private clock plan. I do really want this to be upstreamed so according to the comments in previous attempt[0] from Oleksij Rempel and the frequencies in code[1] I have tried to do this by myself. All of this patches have been tested in a GNUBee PC1 resulting in a working platform. Changes in v10: - Merge clock properties into 'sysc' system control node making this node a clock provider. - Update driver to use 'mediatek,mt7621-sysc' as compatible string. - Update documentation bindings and its related filename to 'mediatek,mt7621-sysc.yaml'. - Make use of 'linux/bitfields.h' header to avoid some preprocesor shift definitions and just use bit masks decreasing a bit LOC. Changes in v9: - Set two missing ret values to its related PTR_ERR in function 'mt7621_clk_probe' (also related with [3]). - Select MFC_SYSCON in Kconfig. Changes in v8: - Fix kernel test robot complain about the use of 'ret' variable initialized: see [3] Changes in v7: - Make use of CLK_OF_DECLARE_DRIVER instead of CLK_OF_DECLARE and register there only the top clocks that are needed in 'of_clk_init'. The rest of the clocks (fixed and gates) are now registered using a platform driver. Because we have avoid architecture dependent stuff now this has sense because we can enable this driver for COMPILE_TEST. - Convert fixed clocks and gates related function to receive a 'struct device' pointer instead of 'struct device_node' one. - Make use of dev_ APIS in stuff related with platform driver instead of use device_node related stuff. - Add new static global 'mt7621_clk_early' to store pointers to clk_hw registered at 'of_clk_init' stage. Make use of this in platform device probe function to properly copy this into the new required 'clk_data' to provide a properly hierarchy clock structure. - Rename 'mt7621_register_top_clocks' function into a more accurate name now which is 'mt7621_register_early_clocks'. - Enable driver for COMPILE_TEST. Changes in v6: - Rewrite bindings to properly access the registers needed for the driver making use of syscon for two different areas: 'sysc' and 'memc'. With this changes architecture dependent include 'asm/mach-ralink/ralink_regs.h' is not needed anymore because we access this two syscons using a phandle through kernel's regmap APIs. Explanation of this two areas is in [2]. - Add new 'mt7621_clk_priv' struct to store there pointers to regmap handlers to be able to use regmap operations
RE: [PATCH] scsi: ufs: fix error return code of ufshcd_populate_vreg()
>
> When np is NULL or of_parse_phandle() returns NULL, no error return code
> of ufshcd_populate_vreg() is assigned.
> To fix this bug, ret is assigned with -EINVAL or -ENOENT as error return
> code.
This changes the flow of ufshcd_parse_regulator_info so you need to:
a) get a tested-by tag and indicate which platform & devices you used, and
b) explain further why ufshcd_parse_regulator_info doesn't no longer allow
some of the regulators not to be set via DT, which is the current state.
Thanks,
Avri
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/scsi/ufs/ufshcd-pltfrm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
> b/drivers/scsi/ufs/ufshcd-pltfrm.c
> index 1a69949a4ea1..9f11c416a919 100644
> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> @@ -113,6 +113,7 @@ static int ufshcd_populate_vreg(struct device *dev,
> const char *name,
>
> if (!np) {
> dev_err(dev, "%s: non DT initialization\n", __func__);
> + ret = -EINVAL;
> goto out;
> }
>
> @@ -120,6 +121,7 @@ static int ufshcd_populate_vreg(struct device *dev,
> const char *name,
> if (!of_parse_phandle(np, prop_name, 0)) {
> dev_info(dev, "%s: Unable to find %s regulator, assuming
> enabled\n",
> __func__, prop_name);
> + ret = -ENOENT;
> goto out;
> }
>
> --
> 2.17.1
[PATCH] tee: amdtee: unload TA only when its refcount becomes 0
Same Trusted Application (TA) can be loaded in multiple TEE contexts.
If it is a single instance TA, the TA should not get unloaded from AMD
Secure Processor, while it is still in use in another TEE context.
Therefore reference count TA and unload it when the count becomes zero.
Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
Reviewed-by: Devaraj Rangasamy
Signed-off-by: Rijo Thomas
---
drivers/tee/amdtee/amdtee_private.h | 13 +
drivers/tee/amdtee/call.c | 73 +++--
drivers/tee/amdtee/core.c | 15 +++---
3 files changed, 92 insertions(+), 9 deletions(-)
diff --git a/drivers/tee/amdtee/amdtee_private.h
b/drivers/tee/amdtee/amdtee_private.h
index 337c8d82f74e..6d0f7062bb87 100644
--- a/drivers/tee/amdtee/amdtee_private.h
+++ b/drivers/tee/amdtee/amdtee_private.h
@@ -21,6 +21,7 @@
#define TEEC_SUCCESS 0x
#define TEEC_ERROR_GENERIC 0x
#define TEEC_ERROR_BAD_PARAMETERS 0x0006
+#define TEEC_ERROR_OUT_OF_MEMORY 0x000C
#define TEEC_ERROR_COMMUNICATION 0x000E
#define TEEC_ORIGIN_COMMS 0x0002
@@ -93,6 +94,18 @@ struct amdtee_shm_data {
u32 buf_id;
};
+/**
+ * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure
+ *Processor
+ * @ta_handle: Handle to TA loaded in TEE
+ * @refcount: Reference count for the loaded TA
+ */
+struct amdtee_ta_data {
+ struct list_head list_node;
+ u32 ta_handle;
+ u32 refcount;
+};
+
#define LOWER_TWO_BYTE_MASK0x
/**
diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c
index 096dd4d92d39..e10601417ea3 100644
--- a/drivers/tee/amdtee/call.c
+++ b/drivers/tee/amdtee/call.c
@@ -121,15 +121,69 @@ static int amd_params_to_tee_params(struct tee_param
*tee, u32 count,
return ret;
}
+static DEFINE_MUTEX(ta_refcount_mutex);
+static struct list_head ta_list = LIST_HEAD_INIT(ta_list);
+
+static u32 get_ta_refcount(u32 ta_handle)
+{
+ struct amdtee_ta_data *ta_data;
+ u32 count = 0;
+
+ /* Caller must hold a mutex */
+ list_for_each_entry(ta_data, _list, list_node)
+ if (ta_data->ta_handle == ta_handle)
+ return ++ta_data->refcount;
+
+ ta_data = kzalloc(sizeof(*ta_data), GFP_KERNEL);
+ if (ta_data) {
+ ta_data->ta_handle = ta_handle;
+ ta_data->refcount = 1;
+ count = ta_data->refcount;
+ list_add(_data->list_node, _list);
+ }
+
+ return count;
+}
+
+static u32 put_ta_refcount(u32 ta_handle)
+{
+ struct amdtee_ta_data *ta_data;
+ u32 count = 0;
+
+ /* Caller must hold a mutex */
+ list_for_each_entry(ta_data, _list, list_node)
+ if (ta_data->ta_handle == ta_handle) {
+ count = --ta_data->refcount;
+ if (count == 0) {
+ list_del(_data->list_node);
+ kfree(ta_data);
+ break;
+ }
+ }
+
+ return count;
+}
+
int handle_unload_ta(u32 ta_handle)
{
struct tee_cmd_unload_ta cmd = {0};
- u32 status;
+ u32 status, count;
int ret;
if (!ta_handle)
return -EINVAL;
+ mutex_lock(_refcount_mutex);
+
+ count = put_ta_refcount(ta_handle);
+
+ if (count) {
+ pr_debug("unload ta: not unloading %u count %u\n",
+ta_handle, count);
+ ret = -EBUSY;
+ goto unlock;
+ }
+
cmd.ta_handle = ta_handle;
ret = psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, (void *),
@@ -137,8 +191,12 @@ int handle_unload_ta(u32 ta_handle)
if (!ret && status != 0) {
pr_err("unload ta: status = 0x%x\n", status);
ret = -EBUSY;
+ } else {
+ pr_debug("unloaded ta handle %u\n", ta_handle);
}
+unlock:
+ mutex_unlock(_refcount_mutex);
return ret;
}
@@ -357,14 +415,23 @@ int handle_load_ta(void *data, u32 size, struct
tee_ioctl_open_session_arg *arg)
cmd.low_addr = lower_32_bits(blob);
cmd.size = size;
+ mutex_lock(_refcount_mutex);
+
ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *),
sizeof(cmd), >ret);
if (ret) {
arg->ret_origin = TEEC_ORIGIN_COMMS;
arg->ret = TEEC_ERROR_COMMUNICATION;
- } else {
- set_session_id(cmd.ta_handle, 0, >session);
+ } else if (arg->ret == TEEC_SUCCESS) {
+ ret = get_ta_refcount(cmd.ta_handle);
+ if (!ret) {
+ arg->ret_origin = TEEC_ORIGIN_COMMS;
+ arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
+ } else {
+ set_session_id(cmd.ta_handle, 0,
Re: [PATCH] Replace __toc_start + 0x8000 with .TOC.
On Sat, Mar 6, 2021 at 10:25 PM Segher Boessenkool wrote: > > Hi! > > On Sat, Mar 06, 2021 at 09:14:33PM -0800, Fangrui Song wrote: > > TOC relocations are like GOT relocations on other architectures. > > However, unlike other architectures, GNU ld's ppc64 port defines .TOC. > > relative to the .got output section instead of the linker synthesized > > .got input section. LLD defines .TOC. as the .got input section plus > > 0x8000. When CONFIG_PPC_OF_BOOT_TRAMPOLINE=y, > > arch/powerpc/kernel/prom_init.o is built, and LLD computed .TOC. can be > > different from __toc_start defined by the linker script. > > > > Simplify kernel_toc_addr with asm label .TOC. so that we can get rid of > > __toc_start. > > > > With this change, powernv_defconfig with CONFIG_PPC_OF_BOOT_TRAMPOLINE=y > > is bootable with LLD. There is still an untriaged issue with Alexey's > > configuration. > > Do you have any explanation why this *does* work, while the original > doesn't? Some explanation that says *what* is wrong. To me it doesn't > look like the kernel script is. > > > Segher The kernel code probably wants to access .TOC. (the TOC base symbol) via __toc_start+0x8000. If the kernel understood TOC base is different from the linker understood TOC base (.TOC.), there should be a problem. By using .TOC. in the kernel code, the two concepts are guaranteed to match.
Re: [PATCH] Replace __toc_start + 0x8000 with .TOC.
Hi! On Sat, Mar 06, 2021 at 09:14:33PM -0800, Fangrui Song wrote: > TOC relocations are like GOT relocations on other architectures. > However, unlike other architectures, GNU ld's ppc64 port defines .TOC. > relative to the .got output section instead of the linker synthesized > .got input section. LLD defines .TOC. as the .got input section plus > 0x8000. When CONFIG_PPC_OF_BOOT_TRAMPOLINE=y, > arch/powerpc/kernel/prom_init.o is built, and LLD computed .TOC. can be > different from __toc_start defined by the linker script. > > Simplify kernel_toc_addr with asm label .TOC. so that we can get rid of > __toc_start. > > With this change, powernv_defconfig with CONFIG_PPC_OF_BOOT_TRAMPOLINE=y > is bootable with LLD. There is still an untriaged issue with Alexey's > configuration. Do you have any explanation why this *does* work, while the original doesn't? Some explanation that says *what* is wrong. To me it doesn't look like the kernel script is. Segher
Re: [PATCH v9 2/6] dt: bindings: add mt7621-clk device tree binding documentation
Hi,
On Sat, Mar 6, 2021 at 10:54 AM Sergio Paracuellos
wrote:
>
> Hi again,
>
> On Sat, Mar 6, 2021 at 8:12 AM Sergio Paracuellos
> wrote:
> >
> > Hi Rob,
> >
> > On Fri, Mar 5, 2021 at 11:47 PM Rob Herring wrote:
> > [snip]
> > > > +
> > > > + ralink,sysctl:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > > +description:
> > > > + phandle of syscon used to control system registers
> > > > +
> > > > + ralink,memctl:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > > +description:
> > > > + phandle of syscon used to control memory registers
> > >
> > > I assume one of these phandles are the main registers for the clocks?
> > > Make this a child node and drop that phandle.
> >
> > The 'ralink,sysctl' phandle is to read bootstrap register to be able
> > to derive xtal and a clk gate register for the peripherals.
> > The 'ralink,memctl' phandle is to read the cpu clock frequency from
> > the memory controller.
> >
> > So there is not "main registers". I already put this as a child node
> > in v4 and I was told to get rid of child nodes. I need this as a
> > regmap to other DT node registers (sysctl, and memctl) to be able to
> > use the driver without specific architecture operations and properly
> > enable for COMPILE_TEST without dirty Makefile arch flags. Both sysctl
> > and memctl has no other child nodes, and I think that's why I was told
> > to avoid child nodes at the end. I explained here [0] current sysctl
> > and memctl in the mt7621 device tree and my view of the need for this
> > two syscons:
> >
> > [0]: https://lkml.org/lkml/2021/1/2/9
> >
> > So to avoid to send again "a previous version" on this patch, please
> > guide me in the correct thing to do. Stephen, Rob, I will be really
> > happy with your help :)
>
> Since there are no other child nodes for this sysc, should merge clock
> properties
> with this node in the following way a valid approach:
>
> sysc: sysc@0 {
> compatible = "mediatek,mt7621-sysc", "syscon";
> reg = <0x0 0x100>;
> #clock-cells = <1>;
> ralink,memctl = <>;
> clock-output-names = "xtal", "cpu", "bus",
> "50m", "125m", "150m",
> "250m", "270m";
> };
>
> Consumer clock:
>
> node: node@0 {
> ...
> clocks = < MT7621_CLK_WHATEVER>;
> ...
> };
I have been reviewing bindings review comments along the time and I
was already suggested to do this I am saying here (see [0]) but my
mind seems that filtered it for any reason I don't really understand.
Maybe I should sleep a bit more :).
I will send v10 with these changes that hopefully will be the correct ones.
Thanks and sorry for bothering you with already suggested things.
Best regards,
Sergio Paracuellos
[0]: https://lkml.org/lkml/2020/12/31/206
>
> If that is the case... and since 'sysc' is used as system control
> registers for all the rest of the world, where should be the yaml file
> with bindings placed?
>
> Thanks in advance again for your help.
>
> Best regards,
> Sergio Paracuellos
>
> >
> > Best regards,
> > Sergio Paracuellos
> > >
> > > > +
> > > > + clock-output-names:
> > > > +maxItems: 8
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - '#clock-cells'
> > > > + - ralink,sysctl
> > > > + - ralink,memctl
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > +#include
> > > > +
> > > > +pll {
> > > > + compatible = "mediatek,mt7621-clk";
> > > > + #clock-cells = <1>;
> > > > + ralink,sysctl = <>;
> > > > + ralink,memctl = <>;
> > > > + clock-output-names = "xtal", "cpu", "bus",
> > > > + "50m", "125m", "150m",
> > > > + "250m", "270m";
> > > > +};
> > > > --
> > > > 2.25.1
> > > >
Re: [PATCH] Staging: android: ashmem: fixed a struct without const
Hi nabil5352,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/nabil5352/Staging-android-ashmem-fixed-a-struct-without-const/20210307-103559
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
4e1c5d4c35d8d5a5f861019f1392ebaa0abb490b
config: x86_64-randconfig-m001-20210307 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/4847faabe2fac6d0cf216c0d7ad02e0a263945b4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
nabil5352/Staging-android-ashmem-fixed-a-struct-without-const/20210307-103559
git checkout 4847faabe2fac6d0cf216c0d7ad02e0a263945b4
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/staging/android/ashmem.c: In function 'ashmem_mmap':
>> drivers/staging/android/ashmem.c:430:16: error: assignment of read-only
>> variable 'vmfile_fops'
430 |vmfile_fops = *vmfile->f_op;
|^
>> drivers/staging/android/ashmem.c:431:21: error: assignment of member 'mmap'
>> in read-only object
431 |vmfile_fops.mmap = ashmem_vmfile_mmap;
| ^
>> drivers/staging/android/ashmem.c:432:34: error: assignment of member
>> 'get_unmapped_area' in read-only object
432 |vmfile_fops.get_unmapped_area =
| ^
vim +/vmfile_fops +430 drivers/staging/android/ashmem.c
6d67b0290b4b84 Suren Baghdasaryan 2020-01-27 376
11980c2ac4ccfa Robert Love2011-12-20 377 static int
ashmem_mmap(struct file *file, struct vm_area_struct *vma)
11980c2ac4ccfa Robert Love2011-12-20 378 {
4847faabe2fac6 nabil5352 2021-03-06 379 static const struct
file_operations vmfile_fops;
11980c2ac4ccfa Robert Love2011-12-20 380 struct ashmem_area
*asma = file->private_data;
11980c2ac4ccfa Robert Love2011-12-20 381 int ret = 0;
11980c2ac4ccfa Robert Love2011-12-20 382
11980c2ac4ccfa Robert Love2011-12-20 383
mutex_lock(_mutex);
11980c2ac4ccfa Robert Love2011-12-20 384
11980c2ac4ccfa Robert Love2011-12-20 385 /* user needs to
SET_SIZE before mapping */
59848d6aded59a Alistair Strachan 2018-06-19 386 if (!asma->size) {
11980c2ac4ccfa Robert Love2011-12-20 387 ret = -EINVAL;
11980c2ac4ccfa Robert Love2011-12-20 388 goto out;
11980c2ac4ccfa Robert Love2011-12-20 389 }
11980c2ac4ccfa Robert Love2011-12-20 390
8632c614565d0c Alistair Strachan 2018-06-19 391 /* requested mapping
size larger than object size */
8632c614565d0c Alistair Strachan 2018-06-19 392 if (vma->vm_end -
vma->vm_start > PAGE_ALIGN(asma->size)) {
11980c2ac4ccfa Robert Love2011-12-20 393 ret = -EINVAL;
11980c2ac4ccfa Robert Love2011-12-20 394 goto out;
11980c2ac4ccfa Robert Love2011-12-20 395 }
11980c2ac4ccfa Robert Love2011-12-20 396
11980c2ac4ccfa Robert Love2011-12-20 397 /* requested protection
bits must match our allowed protection mask */
59848d6aded59a Alistair Strachan 2018-06-19 398 if ((vma->vm_flags &
~calc_vm_prot_bits(asma->prot_mask, 0)) &
59848d6aded59a Alistair Strachan 2018-06-19 399
calc_vm_prot_bits(PROT_MASK, 0)) {
11980c2ac4ccfa Robert Love2011-12-20 400 ret = -EPERM;
11980c2ac4ccfa Robert Love2011-12-20 401 goto out;
11980c2ac4ccfa Robert Love2011-12-20 402 }
56f76fc68492af Arve Hjønnevåg 2011-12-20 403 vma->vm_flags &=
~calc_vm_may_flags(~asma->prot_mask);
11980c2ac4ccfa Robert Love2011-12-20 404
11980c2ac4ccfa Robert Love2011-12-20 405 if (!asma->file) {
11980c2ac4ccfa Robert Love2011-12-20 406 char *name =
ASHMEM_NAME_DEF;
11980c2ac4ccfa Robert Love2011-12-20 407 struct file
*vmfile;
3e338d3c95c735 Suren Baghdasaryan 2020-07-30 408 struct inode
*inode;
11980c2ac4ccfa Robert Love2011-12-20 409
11980c2ac4ccfa Robert Love2011-12-20 410 if
(asma->name[ASHMEM_NAME_PREFIX_LEN] != '\0')
11980c2ac4ccfa Robert Love2011-12-20 411 name =
asma->name;
11980c2ac4ccfa Robert Love2011-12-20 412
11980c2ac4ccfa Robert Love2011-12-20 413 /* ... and
allocate the backing shmem file */
11980c2ac4ccfa Robert Love2011-12-20 414 vmfile =
shmem_file_setup(name, asma->size, vma->vm_flags);
7f44cb0ba88b40 Viresh
drivers/scsi/fnic/vnic_dev.c:332:32: 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: a38fd8748464831584a19438cbb3082b5a2dab15
commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX()
iomem argument (as in generic implementation)
date: 7 months ago
config: x86_64-randconfig-s021-20210307 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-245-gacc5c298-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f28ca6bd8211214faf717677bbffe375c2a6072
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 8f28ca6bd8211214faf717677bbffe375c2a6072
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/scsi/fnic/vnic_dev.c:332:32: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const [noderef]
>> __iomem * @@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: expected void const
[noderef] __iomem *
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const [noderef]
__iomem * @@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: expected void const
[noderef] __iomem *
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void [noderef] __iomem *
@@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: expected void [noderef]
__iomem *
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected struct vnic_wq_ctrl
*wq_ctrl @@ got struct vnic_wq_ctrl [noderef] __iomem *ctrl @@
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: expected struct
vnic_wq_ctrl *wq_ctrl
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: got struct vnic_wq_ctrl
[noderef] __iomem *ctrl
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected void *p @@ got void
[noderef] __iomem * @@
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: expected void *p
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: got void [noderef] __iomem *
vim +332 drivers/scsi/fnic/vnic_dev.c
5df6d737dd4b0f Abhijeet Joglekar 2009-04-17 318
363f4d937501ba Jason Yan 2020-04-15 319 static int
vnic_dev_cmd2(struct vnic_dev *vdev, enum vnic_devcmd_cmd cmd,
0a2fdd2215e1fa Satish Kharat 2019-01-18 320int wait)
0a2fdd2215e1fa Satish Kharat 2019-01-18 321 {
0a2fdd2215e1fa Satish Kharat 2019-01-18 322struct
devcmd2_controller *dc2c = vdev->devcmd2;
0a2fdd2215e1fa Satish Kharat 2019-01-18 323struct devcmd2_result
*result;
0a2fdd2215e1fa Satish Kharat 2019-01-18 324u8 color;
0a2fdd2215e1fa Satish Kharat 2019-01-18 325unsigned int i;
0a2fdd2215e1fa Satish Kharat 2019-01-18 326int delay;
0a2fdd2215e1fa Satish Kharat 2019-01-18 327int err;
0a2fdd2215e1fa Satish Kharat 2019-01-18 328u32 fetch_index;
0a2fdd2215e1fa Satish Kharat 2019-01-18 329u32 posted;
0a2fdd2215e1fa Satish Kharat 2019-01-18 330u32 new_posted;
0a2fdd2215e1fa Satish Kharat 2019-01-18 331
0a2fdd2215e1fa Satish Kharat 2019-01-18 @332posted =
ioread32(>wq_ctrl->posted_index);
0a2fdd2215e1fa Satish Kharat 2019-01-18 333fetch_index =
ioread32(>wq_ctrl->fetch_index);
0a2fdd2215e1fa Satish Kharat 2019-01-18 334
0a2fdd2215e1fa Satish Kharat 2019-01-18 335if (posted ==
0x || fetch_index == 0x) {
0a2fdd2215e1fa Satish Kharat 2019-01-18 336/* Hardware
surprise removal: return error */
0a2fdd2215e1fa Satish Kharat 2019-01-18 337pr_err("%s:
devcmd2 invalid posted or fetch index on cmd %d\n",
0a2fdd2215e1fa Satish Kharat 2019-01-18 338
pci_name(vdev->pdev), _CMD_N(cmd));
0a2fdd2215e1fa Satish Kharat 2019-01-18 339pr_err("%s:
fetch index: %u, posted index: %u\n",
0a2fdd2215e1fa Satish Kharat 2019-01-18 340
pci_name(vdev->pdev), fetch_index, posted);
0a2fdd2215e1fa Satish Kharat 2019-01-18 341
0a2fdd2215e1fa Satish Kharat
[PATCH] Replace __toc_start + 0x8000 with .TOC.
TOC relocations are like GOT relocations on other architectures.
However, unlike other architectures, GNU ld's ppc64 port defines .TOC.
relative to the .got output section instead of the linker synthesized
.got input section. LLD defines .TOC. as the .got input section plus
0x8000. When CONFIG_PPC_OF_BOOT_TRAMPOLINE=y,
arch/powerpc/kernel/prom_init.o is built, and LLD computed .TOC. can be
different from __toc_start defined by the linker script.
Simplify kernel_toc_addr with asm label .TOC. so that we can get rid of
__toc_start.
With this change, powernv_defconfig with CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
is bootable with LLD. There is still an untriaged issue with Alexey's
configuration.
Link: https://github.com/ClangBuiltLinux/linux/issues/1318
Reported-by: Alexey Kardashevskiy
Signed-off-by: Fangrui Song
---
arch/powerpc/boot/crt0.S| 2 +-
arch/powerpc/boot/zImage.lds.S | 1 -
arch/powerpc/include/asm/sections.h | 10 ++
arch/powerpc/kernel/head_64.S | 2 +-
arch/powerpc/kernel/vmlinux.lds.S | 1 -
5 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 1d83966f5ef6..e45907fe468f 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -28,7 +28,7 @@ p_etext: .8byte _etext
p_bss_start: .8byte __bss_start
p_end: .8byte _end
-p_toc: .8byte __toc_start + 0x8000 - p_base
+p_toc: .8byte .TOC. - p_base
p_dyn: .8byte __dynamic_start - p_base
p_rela:.8byte __rela_dyn_start - p_base
p_prom:.8byte 0
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
index d6f072865627..32cf7816292f 100644
--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -39,7 +39,6 @@ SECTIONS
. = ALIGN(256);
.got :
{
-__toc_start = .;
*(.got)
*(.toc)
}
diff --git a/arch/powerpc/include/asm/sections.h
b/arch/powerpc/include/asm/sections.h
index 324d7b298ec3..bd22ca0b5eca 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -48,14 +48,8 @@ static inline int in_kernel_text(unsigned long addr)
static inline unsigned long kernel_toc_addr(void)
{
- /* Defined by the linker, see vmlinux.lds.S */
- extern unsigned long __toc_start;
-
- /*
-* The TOC register (r2) points 32kB into the TOC, so that 64kB of
-* the TOC can be addressed using a single machine instruction.
-*/
- return (unsigned long)(&__toc_start) + 0x8000UL;
+ extern unsigned long toc asm(".TOC.");
+ return (unsigned long)();
}
static inline int overlaps_interrupt_vector_text(unsigned long start,
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index ece7f97bafff..9542d03b2efe 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -899,7 +899,7 @@ _GLOBAL(relative_toc)
blr
.balign 8
-p_toc: .8byte __toc_start + 0x8000 - 0b
+p_toc: .8byte .TOC. - 0b
/*
* This is where the main kernel code starts.
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 72fa3c00229a..c28f4e5bae3f 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -328,7 +328,6 @@ SECTIONS
. = ALIGN(256);
.got : AT(ADDR(.got) - LOAD_OFFSET) {
- __toc_start = .;
#ifndef CONFIG_RELOCATABLE
__prom_init_toc_start = .;
arch/powerpc/kernel/prom_init.o*(.toc .got)
--
2.30.1.766.gb4fecdf3b7-goog
[PATCH] MIPS: ralink: make RALINK_ILL_ACC symbol visible
The illegal access driver is optional - it is informational and does not provide critical functionality. Furthermore, it is currently not functional on RT5350 SoCs, so a user may choose to omit non-functional code on that platform. The default is kept at 'y' for backwards compatibility. This change only makes the symbol visible and adds a brief description. Signed-off-by: Ilya Lipnitskiy Cc: linux-m...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- arch/mips/ralink/Kconfig | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/mips/ralink/Kconfig b/arch/mips/ralink/Kconfig index c10d8b233ab1..c20c44788b62 100644 --- a/arch/mips/ralink/Kconfig +++ b/arch/mips/ralink/Kconfig @@ -9,9 +9,14 @@ config CLKEVT_RT3352 select CLKSRC_MMIO config RALINK_ILL_ACC - bool + bool "Illegal memory access IRQ driver" depends on SOC_RT305X default y + help + This enables notifications of illegal memory access events. + + RT305x/RT5350 SoCs have a special IRQ that fires upon an illegal memory + access. config IRQ_INTC bool -- 2.30.1
Re: [PATCH] tasklet: Remove tasklet_kill_immediate
On Sat, Mar 06, 2021 at 01:36:58PM -0800, Davidlohr Bueso wrote:
> Ever since RCU was converted to softirq, it has no users.
>
> Signed-off-by: Davidlohr Bueso
That was a long time ago...
Acked-by: Paul E. McKenney
> ---
> include/linux/interrupt.h | 1 -
> kernel/softirq.c | 32
> 2 files changed, 33 deletions(-)
>
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 967e25767153..36a2ac6baf9a 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -712,7 +712,6 @@ static inline void tasklet_enable(struct tasklet_struct
> *t)
> }
>
> extern void tasklet_kill(struct tasklet_struct *t);
> -extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int
> cpu);
> extern void tasklet_init(struct tasklet_struct *t,
>void (*func)(unsigned long), unsigned long data);
> extern void tasklet_setup(struct tasklet_struct *t,
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 9908ec4a9bfe..8b44ab9a2f69 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -658,38 +658,6 @@ static void run_ksoftirqd(unsigned int cpu)
> }
>
> #ifdef CONFIG_HOTPLUG_CPU
> -/*
> - * tasklet_kill_immediate is called to remove a tasklet which can already be
> - * scheduled for execution on @cpu.
> - *
> - * Unlike tasklet_kill, this function removes the tasklet
> - * _immediately_, even if the tasklet is in TASKLET_STATE_SCHED state.
> - *
> - * When this function is called, @cpu must be in the CPU_DEAD state.
> - */
> -void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu)
> -{
> - struct tasklet_struct **i;
> -
> - BUG_ON(cpu_online(cpu));
> - BUG_ON(test_bit(TASKLET_STATE_RUN, >state));
> -
> - if (!test_bit(TASKLET_STATE_SCHED, >state))
> - return;
> -
> - /* CPU is dead, so no lock needed. */
> - for (i = _cpu(tasklet_vec, cpu).head; *i; i = &(*i)->next) {
> - if (*i == t) {
> - *i = t->next;
> - /* If this was the tail element, move the tail ptr */
> - if (*i == NULL)
> - per_cpu(tasklet_vec, cpu).tail = i;
> - return;
> - }
> - }
> - BUG();
> -}
> -
> static int takeover_tasklets(unsigned int cpu)
> {
> /* CPU is dead, so no lock needed. */
> --
> 2.26.2
>
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1807:1: warning: unused variable 'iwl_dbgfs_dbg_time_point_ops'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: a38fd8748464831584a19438cbb3082b5a2dab15
commit: 9dbb62a29042e543ab6671dc12c1473c3cbc58c2 iwlwifi: mvm: add debugfs
entry to trigger a dump as any time-point
date: 4 weeks ago
config: riscv-randconfig-r031-20210307 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
4d90e460bcc7b3e5ff6c7e2e05e974772489c4b8)
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 riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9dbb62a29042e543ab6671dc12c1473c3cbc58c2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9dbb62a29042e543ab6671dc12c1473c3cbc58c2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1807:1: warning: unused
>> variable 'iwl_dbgfs_dbg_time_point_ops' [-Wunused-const-variable]
MVM_DEBUGFS_WRITE_FILE_OPS(dbg_time_point, 64);
^
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1554:2: note: expanded from
macro 'MVM_DEBUGFS_WRITE_FILE_OPS'
_MVM_DEBUGFS_WRITE_FILE_OPS(name, bufsz, struct iwl_mvm)
^
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.h:39:37: note: expanded from
macro '_MVM_DEBUGFS_WRITE_FILE_OPS'
static const struct file_operations iwl_dbgfs_##name##_ops = { \
^
:117:1: note: expanded from here
iwl_dbgfs_dbg_time_point_ops
^
1 warning generated.
vim +/iwl_dbgfs_dbg_time_point_ops +1807
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
1780
1781 /* Device wide debugfs entries */
1782 MVM_DEBUGFS_READ_FILE_OPS(ctdp_budget);
1783 MVM_DEBUGFS_WRITE_FILE_OPS(stop_ctdp, 8);
1784 MVM_DEBUGFS_WRITE_FILE_OPS(force_ctkill, 8);
1785 MVM_DEBUGFS_WRITE_FILE_OPS(tx_flush, 16);
1786 MVM_DEBUGFS_WRITE_FILE_OPS(sta_drain, 8);
1787 MVM_DEBUGFS_WRITE_FILE_OPS(send_echo_cmd, 8);
1788 MVM_DEBUGFS_READ_WRITE_FILE_OPS(sram, 64);
1789 MVM_DEBUGFS_READ_WRITE_FILE_OPS(set_nic_temperature, 64);
1790 MVM_DEBUGFS_READ_FILE_OPS(nic_temp);
1791 MVM_DEBUGFS_READ_FILE_OPS(stations);
1792 MVM_DEBUGFS_READ_FILE_OPS(rs_data);
1793 MVM_DEBUGFS_READ_FILE_OPS(bt_notif);
1794 MVM_DEBUGFS_READ_FILE_OPS(bt_cmd);
1795 MVM_DEBUGFS_READ_WRITE_FILE_OPS(disable_power_off, 64);
1796 MVM_DEBUGFS_READ_FILE_OPS(fw_rx_stats);
1797 MVM_DEBUGFS_READ_FILE_OPS(drv_rx_stats);
1798 MVM_DEBUGFS_READ_FILE_OPS(fw_ver);
1799 MVM_DEBUGFS_READ_FILE_OPS(phy_integration_ver);
1800 MVM_DEBUGFS_WRITE_FILE_OPS(fw_restart, 10);
1801 MVM_DEBUGFS_WRITE_FILE_OPS(fw_nmi, 10);
1802 MVM_DEBUGFS_WRITE_FILE_OPS(bt_tx_prio, 10);
1803 MVM_DEBUGFS_WRITE_FILE_OPS(bt_force_ant, 10);
1804 MVM_DEBUGFS_READ_WRITE_FILE_OPS(scan_ant_rxchain, 8);
1805 MVM_DEBUGFS_READ_WRITE_FILE_OPS(fw_dbg_conf, 8);
1806 MVM_DEBUGFS_WRITE_FILE_OPS(fw_dbg_collect, 64);
> 1807 MVM_DEBUGFS_WRITE_FILE_OPS(dbg_time_point, 64);
1808 MVM_DEBUGFS_WRITE_FILE_OPS(indirection_tbl,
1809 (IWL_RSS_INDIRECTION_TABLE_SIZE * 2));
1810 MVM_DEBUGFS_WRITE_FILE_OPS(inject_packet, 512);
1811 MVM_DEBUGFS_WRITE_FILE_OPS(inject_beacon_ie, 512);
1812 MVM_DEBUGFS_WRITE_FILE_OPS(inject_beacon_ie_restore, 512);
1813
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 3/4] kbuild: check the minimum assembler version in Kconfig
On Sat, Mar 06, 2021 at 02:48:38AM +0900, Masahiro Yamada wrote:
> On Fri, Mar 5, 2021 at 10:26 AM Nick Desaulniers
> wrote:
> >
> > On Wed, Mar 3, 2021 at 10:34 AM Masahiro Yamada
> > wrote:
> > >
> > > Documentation/process/changes.rst defines the minimum assembler version
> > > (binutils version), but we have never checked it in the build time.
> > >
> > > Kbuild never invokes 'as' directly because all assembly files in the
> > > kernel tree are *.S, hence must be preprocessed. I do not expect
> > > raw assembly source files (*.s) would be added to the kernel tree.
> > >
> > > Therefore, we always use $(CC) as the assembler driver, and commit
> > > aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
> > > we are still interested in the version of the assembler sitting behind.
> > >
> > > As usual, the --version option prints the version string.
> > >
> > > $ as --version | head -n 1
> > > GNU assembler (GNU Binutils for Ubuntu) 2.35.1
> > >
> > > But, we do not have $(AS). So, we can add the -Wa prefix so that
> > > $(CC) passes --version down to the backing assembler.
> > >
> > > $ gcc -Wa,--version | head -n 1
> > > gcc: fatal error: no input files
> > > compilation terminated.
> > >
> > > OK, we need to input something to satisfy gcc.
> > >
> > > $ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
> > > GNU assembler (GNU Binutils for Ubuntu) 2.35.1
> > >
> > > The combination of Clang and GNU assembler works in the same way:
> > >
> > > $ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o
> > > /dev/null | head -n 1
> > > GNU assembler (GNU Binutils for Ubuntu) 2.35.1
> > >
> > > Clang with the integrated assembler fails like this:
> > >
> > > $ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o
> > > /dev/null | head -n 1
> > > clang: error: unsupported argument '--version' to option 'Wa,'
> >
> > Was this a feature request to "please implement -Wa,--version for clang?"
> > :-P
> > https://github.com/ClangBuiltLinux/linux/issues/1320
> >
> > >
> > > With all this in my mind, I implemented scripts/as-version.sh.
> > >
> > > $ scripts/as-version.sh gcc
> > > GNU 23501
> > > $ scripts/as-version.sh clang -no-integrated-as
> > > GNU 23501
> > > $ scripts/as-version.sh clang -integrated-as
> > > LLVM 0
> > >
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > arch/Kconfig| 3 +-
> > > init/Kconfig| 12 +++
> > > scripts/Kconfig.include | 6
> > > scripts/as-version.sh | 77 +
> > > 4 files changed, 96 insertions(+), 2 deletions(-)
> > > create mode 100755 scripts/as-version.sh
> > >
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index 2af10ebe5ed0..d7214f4ae1f7 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -631,8 +631,7 @@ config ARCH_SUPPORTS_LTO_CLANG_THIN
> > > config HAS_LTO_CLANG
> > > def_bool y
> > > # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
> > > - depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD
> > > - depends on $(success,test $(LLVM_IAS) -eq 1)
> > > + depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD &&
> > > AS_IS_LLVM
> > > depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> > > depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> > > depends on ARCH_SUPPORTS_LTO_CLANG
> > > diff --git a/init/Kconfig b/init/Kconfig
> > > index 22946fe5ded9..f76e5a44e4fe 100644
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -41,6 +41,18 @@ config CLANG_VERSION
> > > default $(cc-version) if CC_IS_CLANG
> > > default 0
> > >
> > > +config AS_IS_GNU
> > > + def_bool $(success,test "$(as-name)" = GNU)
> > > +
> > > +config AS_IS_LLVM
> > > + def_bool $(success,test "$(as-name)" = LLVM)
> > > +
> > > +config AS_VERSION
> > > + int
> > > + # If it is integrated assembler, the version is the same as
> > > Clang's one.
> > > + default CLANG_VERSION if AS_IS_LLVM
> > > + default $(as-version)
> > > +
> > > config LD_IS_BFD
> > > def_bool $(success,test "$(ld-name)" = BFD)
> > >
> > > diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> > > index 58fdb5308725..0496efd6e117 100644
> > > --- a/scripts/Kconfig.include
> > > +++ b/scripts/Kconfig.include
> > > @@ -45,6 +45,12 @@ $(error-if,$(success,test -z
> > > "$(cc-info)"),Sorry$(comma) this compiler is not su
> > > cc-name := $(shell,set -- $(cc-info) && echo $1)
> > > cc-version := $(shell,set -- $(cc-info) && echo $2)
> > >
> > > +# Get the assembler name, version, and error out if it is not supported.
> > > +as-info := $(shell,$(srctree)/scripts/as-version.sh $(CC) $(CLANG_FLAGS))
> > > +$(error-if,$(success,test -z "$(as-info)"),Sorry$(comma) this assembler
> > > is not supported.)
> > > +as-name := $(shell,set -- $(as-info)
Re: [PATCH] KVM: arm64: Don't use cbz/adr with external symbols
On Fri, Mar 05, 2021 at 12:21:24PM -0800, Sami Tolvanen wrote: > allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following > linker errors: > > ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC): > relocation R_AARCH64_CONDBR19 out of range: 2031220 is not in > [-1048576, 1048575]; references hyp_panic > >>> defined in vmlinux.o > > ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21E0): > relocation R_AARCH64_ADR_PREL_LO21 out of range: 2031200 is not in > [-1048576, 1048575]; references hyp_panic > >>> defined in vmlinux.o > > This is because with LTO, the compiler ends up placing hyp_panic() > more than 1MB away from __guest_enter(). Use an unconditional branch > and adr_l instead to fix the issue. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1317 > Reported-by: Nathan Chancellor > Suggested-by: Marc Zyngier > Suggested-by: Ard Biesheuvel > Signed-off-by: Sami Tolvanen I booted an kernel with this patch in it on my Raspberry Pi 4 and booted a kernel under KVM without any issues. Tested-by: Nathan Chancellor > --- > arch/arm64/kvm/hyp/entry.S | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S > index b0afad7a99c6..c62265951467 100644 > --- a/arch/arm64/kvm/hyp/entry.S > +++ b/arch/arm64/kvm/hyp/entry.S > @@ -85,8 +85,10 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL) > > // If the hyp context is loaded, go straight to hyp_panic > get_loaded_vcpu x0, x1 > - cbz x0, hyp_panic > + cbnzx0, 1f > + b hyp_panic > > +1: > // The hyp context is saved so make sure it is restored to allow > // hyp_panic to run at hyp and, subsequently, panic to run in the host. > // This makes use of __guest_exit to avoid duplication but sets the > @@ -94,7 +96,7 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL) > // current state is saved to the guest context but it will only be > // accurate if the guest had been completely restored. > adr_this_cpu x0, kvm_hyp_ctxt, x1 > - adr x1, hyp_panic > + adr_l x1, hyp_panic > str x1, [x0, #CPU_XREG_OFFSET(30)] > > get_vcpu_ptrx1, x0 > > base-commit: 280d542f6ffac0e6d65dc267f92191d509b13b64 > -- > 2.30.1.766.gb4fecdf3b7-goog > > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH] MIPS: pci-mt7620: fix PLL lock check
Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL
lock check. The existing code checks the wrong register bit: PPLL_SW_SET
is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved
in the MT7620 Programming Guide. The correct bit to check for PLL lock
is PPLL_LD (bit 23).
Also reword the error message for clarity.
Without this change it is unlikely that this driver ever worked with
mainline kernel.
[0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.html
Signed-off-by: Ilya Lipnitskiy
Cc: John Crispin
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
arch/mips/pci/pci-mt7620.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pci/pci-mt7620.c b/arch/mips/pci/pci-mt7620.c
index d36061603752..e032932348d6 100644
--- a/arch/mips/pci/pci-mt7620.c
+++ b/arch/mips/pci/pci-mt7620.c
@@ -30,6 +30,7 @@
#define RALINK_GPIOMODE0x60
#define PPLL_CFG1 0x9c
+#define PPLL_LDBIT(23)
#define PPLL_DRV 0xa0
#define PDRV_SW_SETBIT(31)
@@ -239,8 +240,8 @@ static int mt7620_pci_hw_init(struct platform_device *pdev)
rt_sysc_m32(0, RALINK_PCIE0_CLK_EN, RALINK_CLKCFG1);
mdelay(100);
- if (!(rt_sysc_r32(PPLL_CFG1) & PDRV_SW_SET)) {
- dev_err(>dev, "MT7620 PPLL unlock\n");
+ if (!(rt_sysc_r32(PPLL_CFG1) & PPLL_LD)) {
+ dev_err(>dev, "pcie PLL not locked, aborting init\n");
reset_control_assert(rstpcie0);
rt_sysc_m32(RALINK_PCIE0_CLK_EN, 0, RALINK_CLKCFG1);
return -1;
--
2.30.1
Re: [PATCH v2] MIPS: kernel: Reserve exception base early to prevent corruption
On 3/6/2021 12:29 AM, Thomas Bogendoerfer wrote:
> BMIPS is one of the few platforms that do change the exception base.
> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
> with kernel_end") we started seeing BMIPS boards fail to boot with the
> built-in FDT being corrupted.
>
> Before the cited commit, early allocations would be in the [kernel_end,
> RAM_END] range, but after commit they would be within [RAM_START +
> PAGE_SIZE, RAM_END].
>
> The custom exception base handler that is installed by
> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
> memory region allocated by unflatten_and_copy_device_tree() thus
> corrupting the FDT used by the kernel.
>
> To fix this, we need to perform an early reservation of the custom
> exception space. So we reserve it already in cpu_probe() for the CPUs
> where this is fixed. For CPU with an ebase config register allocation
> of exception space will be done in trap_init().
>
> Huge thanks to Serget for analysing and proposing a solution to this
> issue.
I made a typo on Sergey's name in my original version here.
>
> Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with
> kernel_end")
> Reported-by: Kamal Dasu
> Debugged-by: Serge Semin
> Signed-off-by: Thomas Bogendoerfer
Tested-by: Florian Fainelli
Thanks!
--
Florian
Re: [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from trace events
On 21-03-02 09:56:05, Steven Rostedt wrote: > On Tue, 2 Mar 2021 16:23:55 +0800 > Peter Chen wrote: > > s it looks like it uses %pa which IIUC from the printk code, it > > > >> dereferences the pointer to find it's virtual address. The event has > > > >> this as the field: > > > >> > > > >> __field(struct cdns3_trb *, start_trb_addr) > > > >> > > > >> Assigns it with: > > > >> > > > >> __entry->start_trb_addr = req->trb; > > > >> > > > >> And prints that with %pa, which will dereference pointer at the time of > > > >> reading, where the address in question may no longer be around. That > > > >> looks to me as a potential bug. > > > > Steven, thanks for reporting. Do you mind sending patch to fix it? > > If you have no time to do it, I will do it later. > > > > I would have already fixed it, but I wasn't exactly sure how this is used. > > In Documentation/core-api/printk-formats.rst we have: > >Physical address types phys_addr_t >-- > >:: > >%pa[p] 0x01234567 or 0x0123456789abcdef > >For printing a phys_addr_t type (and its derivatives, such as >resource_size_t) which can vary based on build options, regardless of the >width of the CPU data path. > > So it only looks like it is used to for the size of the pointer. > > I guess something like this might work: > > diff --git a/drivers/usb/cdns3/cdns3-trace.h b/drivers/usb/cdns3/cdns3-trace.h > index 8648c7a7a9dd..d3b8624fc427 100644 > --- a/drivers/usb/cdns3/cdns3-trace.h > +++ b/drivers/usb/cdns3/cdns3-trace.h > @@ -214,7 +214,7 @@ DECLARE_EVENT_CLASS(cdns3_log_request, > __field(int, no_interrupt) > __field(int, start_trb) > __field(int, end_trb) > - __field(struct cdns3_trb *, start_trb_addr) > + __field(phys_addr_t, start_trb_addr) > __field(int, flags) > __field(unsigned int, stream_id) > ), > @@ -230,7 +230,7 @@ DECLARE_EVENT_CLASS(cdns3_log_request, > __entry->no_interrupt = req->request.no_interrupt; > __entry->start_trb = req->start_trb; > __entry->end_trb = req->end_trb; > - __entry->start_trb_addr = req->trb; > + __entry->start_trb_addr = *(const phys_addr_t *)req->trb; > __entry->flags = req->flags; > __entry->stream_id = req->request.stream_id; > ), > @@ -244,7 +244,7 @@ DECLARE_EVENT_CLASS(cdns3_log_request, > __entry->status, > __entry->start_trb, > __entry->end_trb, > - __entry->start_trb_addr, > + /* %pa dereferences */ &__entry->start_trb_addr, > __entry->flags, > __entry->stream_id > ) > > > Can you please test it? I don't have the hardware, but I also want to make > sure I don't break anything. > > Thanks, > Since the virtual address for req->trb is NULL before using it. It will trigger below oops using your change. There is already index (start_trb/end_trb) for which TRB it has handled, it is not necessary to trace information for its physical address. I decide to delete this trace entry, thanks for reporting it. [ 61.695160] Unable to handle kernel NULL pointer dereference at virtual address [ 61.704066] Mem abort info: [ 61.706910] ESR = 0x9606 [ 61.71] EC = 0x25: DABT (current EL), IL = 32 bits [ 61.715339] SET = 0, FnV = 0 [ 61.718416] EA = 0, S1PTW = 0 [ 61.721575] Data abort info: [ 61.724482] ISV = 0, ISS = 0x0006 [ 61.728323] CM = 0, WnR = 0 [ 61.731324] user pgtable: 4k pages, 48-bit VAs, pgdp=0008856dd000 [ 61.737816] [] pgd=00088577a003, p4d=00088577a003, pud=00088477c003, pmd= [ 61.748532] Internal error: Oops: 9606 [#1] PREEMPT SMP [ 61.754113] Modules linked in: fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes crct10dif_ce mxc_jpeg_encdec imx8_media_dev(C) caam error Message from syslogd@imx8qmmek at Fri Jul 10 06:52:44 2020 ... imx8qmmek kernel: [ 61.748532] Internal error: Oops: 9606 [#1] PREEMPT SMP [ 61.784245] CPU: 3 PID: 188 Comm: 1-0050 Tainted: G C 5.10.0-rc7-04451-gfcfe23a5424-dirty #3 [ 61.793993] Hardware name: Freescale i.MX8QXP MEK (DT) [ 61.799139] pstate: 8005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 61.805162] pc : trace_event_raw_event_cdns3_log_request+0xf4/0x170 [ 61.811440] lr : trace_event_raw_event_cdns3_log_request+0x94/0x170 [ 61.817707] sp : 80001387ba40 [ 61.821019] x29: 80001387ba40 x28: 0002 [ 61.826336] x27: 000801e20080 x26: 000800e5c8c8 [ 61.831652] x25: 0008044e0c00 x24: 000800505308 [ 61.836969] x23: 800012464000 x22: 00040050 [ 61.842286] x21: 000801e0aa00 x20: 0008002e7f18 [ 61.847603] x19:
Re: [PATCH 2/2] riscv: Enable generic clockevent broadcast
On Sun, Mar 7, 2021 at 7:55 AM wrote:
>
> From: Guo Ren
>
> When percpu-timers are stopped by deep power saving mode, we
> need system timer help to broadcast IPI_TIMER.
>
> This is first introduced by broken x86 hardware, where the local apic
> timer stops in C3 state. But many other architectures(powerpc, mips,
> arm, hexagon, openrisc, sh) have supported the infrastructure to
> deal with Power Management issues.
>
> Signed-off-by: Guo Ren
> Cc: Arnd Bergmann
> Cc: Thomas Gleixner
> Cc: Daniel Lezcano
> Cc: Anup Patel
> Cc: Atish Patra
> Cc: Palmer Dabbelt
> Cc: Greentime Hu
Looks good to me.
Reviewed-by: Anup Patel
Regards,
Anup
> ---
> arch/riscv/Kconfig | 2 ++
> arch/riscv/kernel/smp.c | 16
> 2 files changed, 18 insertions(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 85d626b8ce5e..8637e7344abe 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -28,6 +28,7 @@ config RISCV
> select ARCH_HAS_SET_DIRECT_MAP
> select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_STRICT_KERNEL_RWX if MMU
> + select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> @@ -39,6 +40,7 @@ config RISCV
> select EDAC_SUPPORT
> select GENERIC_ARCH_TOPOLOGY if SMP
> select GENERIC_ATOMIC64 if !64BIT
> + select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> select GENERIC_EARLY_IOREMAP
> select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
> select GENERIC_IOREMAP
> diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
> index ea028d9e0d24..8325d33411d8 100644
> --- a/arch/riscv/kernel/smp.c
> +++ b/arch/riscv/kernel/smp.c
> @@ -9,6 +9,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -27,6 +28,7 @@ enum ipi_message_type {
> IPI_CALL_FUNC,
> IPI_CPU_STOP,
> IPI_IRQ_WORK,
> + IPI_TIMER,
> IPI_MAX
> };
>
> @@ -176,6 +178,12 @@ void handle_IPI(struct pt_regs *regs)
> irq_work_run();
> }
>
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> + if (ops & (1 << IPI_TIMER)) {
> + stats[IPI_TIMER]++;
> + tick_receive_broadcast();
> + }
> +#endif
> BUG_ON((ops >> IPI_MAX) != 0);
>
> /* Order data access and bit testing. */
> @@ -192,6 +200,7 @@ static const char * const ipi_names[] = {
> [IPI_CALL_FUNC] = "Function call interrupts",
> [IPI_CPU_STOP] = "CPU stop interrupts",
> [IPI_IRQ_WORK] = "IRQ work interrupts",
> + [IPI_TIMER] = "Timer broadcast interrupts",
> };
>
> void show_ipi_stats(struct seq_file *p, int prec)
> @@ -217,6 +226,13 @@ void arch_send_call_function_single_ipi(int cpu)
> send_ipi_single(cpu, IPI_CALL_FUNC);
> }
>
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> +void tick_broadcast(const struct cpumask *mask)
> +{
> + send_ipi_mask(mask, IPI_TIMER);
> +}
> +#endif
> +
> void smp_send_stop(void)
> {
> unsigned long timeout;
> --
> 2.25.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2] Expose the bus kernel docs to the build docs.
On 3/6/21 7:16 PM, Matthew Wilcox wrote: On Sat, Mar 06, 2021 at 07:12:19PM -0800, Wren Turkal wrote: +Fucntions and Structures Typo, but hold off on a v3 until someone weighs in with an opinion on the rest of the patch. Okay, I fixed the misspelling locally. Looking forward to addtional feedback. Thanks, wt
Re: [PATCH v2] Expose the bus kernel docs to the build docs.
On Sat, Mar 06, 2021 at 07:12:19PM -0800, Wren Turkal wrote: > +Fucntions and Structures Typo, but hold off on a v3 until someone weighs in with an opinion on the rest of the patch.
[PATCH 1/2] net: allwinner: reset control support
R40 (aka V40/A40i/T3) and A10/A20 share the same EMAC IP.
However, on R40 the EMAC is gated by default.
Signed-off-by: Evgeny Boger
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 5ed80d9a6b9f..c0ae06dd922c 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "sun4i-emac.h"
@@ -85,6 +86,7 @@ struct emac_board_info {
unsigned intlink;
unsigned intspeed;
unsigned intduplex;
+ struct reset_control *reset;
phy_interface_t phy_interface;
};
@@ -791,6 +793,7 @@ static int emac_probe(struct platform_device *pdev)
struct net_device *ndev;
int ret = 0;
const char *mac_addr;
+ struct reset_control *reset;
ndev = alloc_etherdev(sizeof(struct emac_board_info));
if (!ndev) {
@@ -852,6 +855,19 @@ static int emac_probe(struct platform_device *pdev)
goto out_release_sram;
}
+ reset = devm_reset_control_get_optional_exclusive(>dev, NULL);
+ if (IS_ERR(reset)) {
+ dev_err(>dev, "unable to request reset\n");
+ ret = -ENODEV;
+ goto out_release_sram;
+ }
+ db->reset = reset;
+ ret = reset_control_deassert(db->reset);
+ if (ret) {
+ dev_err(>dev, "could not deassert EMAC reset\n");
+ goto out_release_sram;
+ }
+
/* Read MAC-address from DT */
mac_addr = of_get_mac_address(np);
if (!IS_ERR(mac_addr))
@@ -881,7 +897,7 @@ static int emac_probe(struct platform_device *pdev)
if (ret) {
dev_err(>dev, "Registering netdev failed!\n");
ret = -ENODEV;
- goto out_release_sram;
+ goto out_assert_reset;
}
dev_info(>dev, "%s: at %p, IRQ %d MAC: %pM\n",
@@ -889,6 +905,8 @@ static int emac_probe(struct platform_device *pdev)
return 0;
+out_assert_reset:
+ reset_control_assert(db->reset);
out_release_sram:
sunxi_sram_release(>dev);
out_clk_disable_unprepare:
@@ -913,6 +931,7 @@ static int emac_remove(struct platform_device *pdev)
unregister_netdev(ndev);
sunxi_sram_release(>dev);
clk_disable_unprepare(db->clk);
+ reset_control_assert(db->reset);
irq_dispose_mapping(ndev->irq);
iounmap(db->membase);
free_netdev(ndev);
--
2.17.1
[PATCH 2/2] dts: r40: add second ethernet support
R40 (aka V40, A40i, T3) has two different Ethernet IP
called EMAC and GMAC.
EMAC only support 10/100 Mbit in MII mode,
while GMAC support both 10/100 (MII) and 10/100/1000 (RGMII).
In contrast to A10/A20 where GMAC and EMAC share the same pins
making EMAC somewhat pointless, on R40 EMAC can be routed to port H.
Both EMAC (on port H) and GMAC (on port A)
can be then enabled at the same time, allowing for two ethernet ports.
Signed-off-by: Evgeny Boger
---
arch/arm/boot/dts/sun8i-r40.dtsi | 53
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index d5ad3b9efd12..c102c1510012 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -217,6 +217,20 @@
#size-cells = <1>;
ranges;
+ sram_a: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x 0xc000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x 0xc000>;
+
+ emac_sram: sram-section@8000 {
+ compatible =
"allwinner,sun4i-a10-sram-a3-a4";
+ reg = <0x8000 0x4000>;
+ status = "okay";
+ };
+ };
+
sram_c: sram@1d0 {
compatible = "mmio-sram";
reg = <0x01d0 0xd>;
@@ -541,6 +555,24 @@
drive-strength = <40>;
};
+ emac_ph_pins: emac-ph-pins {
+ pins = "PH8", "PH9", "PH10", "PH11",
+ "PH14", "PH15", "PH16", "PH17",
+ "PH18","PH19", "PH20", "PH21",
+ "PH22", "PH23", "PH24", "PH25",
+ "PH26", "PH27";
+ function = "emac";
+ };
+
+ emac_pa_pins: emac-pa-pins {
+ pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA9", "PA10",
+ "PA11", "PA12", "PA13", "PA14",
+ "PA15", "PA16";
+ function = "emac";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PB0", "PB1";
function = "i2c0";
@@ -885,6 +917,27 @@
};
};
+ emac: ethernet@1c0b000 {
+ syscon = <>;
+ compatible = "allwinner,sun4i-a10-emac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = ;
+ clocks = < CLK_BUS_EMAC>;
+ resets = < RST_BUS_EMAC>;
+ allwinner,sram = <_sram 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_ph_pins>;
+ status = "disabled";
+ };
+
+ emac_mdio: mdio@1c0b080 {
+ compatible = "allwinner,sun4i-a10-mdio";
+ reg = <0x01c0b080 0x14>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
mbus: dram-controller@1c62000 {
compatible = "allwinner,sun8i-r40-mbus";
reg = <0x01c62000 0x1000>;
--
2.17.1
[PATCH 0/2] sun8i: r40: second ethernet support
This patch series adds support for two Ethernet ports on Allwinner R40. R40 (aka V40,A40i,T3) has two different Ethernet IPs called EMAC and GMAC. EMAC only support 10/100 Mbit in MII mode, while GMAC support both 10/100 (MII) and 10/100/1000 (RGMII). In contrast to A10/A20 where GMAC and EMAC share the same pins making EMAC somewhat pointless, on R40 EMAC can be routed to port H. Both EMAC (on port H) and GMAC (on port A) can be then enabled at the same time, allowing for two ethernet ports. Evgeny Boger (2): net: allwinner: reset control support dts: r40: add second ethernet support arch/arm/boot/dts/sun8i-r40.dtsi| 53 + drivers/net/ethernet/allwinner/sun4i-emac.c | 21 +++- 2 files changed, 73 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH v2] Expose the bus kernel docs to the build docs.
Before, the bus type related APIs that were defined in the include/linux/device/bus.h were not referenced anywhere in the docs, so I linked it to the bus types api documentation. Signed-off-by: Wren Turkal --- Documentation/driver-api/driver-model/bus.rst | 8 Documentation/driver-api/infrastructure.rst | 3 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/driver-api/driver-model/bus.rst b/Documentation/driver-api/driver-model/bus.rst index 016b15a6e8ea..6bed459b87cc 100644 --- a/Documentation/driver-api/driver-model/bus.rst +++ b/Documentation/driver-api/driver-model/bus.rst @@ -1,3 +1,5 @@ +.. _bus_types: + = Bus Types = @@ -144,3 +146,9 @@ sysfs directory using:: int bus_create_file(struct bus_type *, struct bus_attribute *); void bus_remove_file(struct bus_type *, struct bus_attribute *); + +Fucntions and Structures + + +.. kernel-doc:: include/linux/device/bus.h +.. kernel-doc:: drivers/base/bus.c diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index 683bd460e222..eb2a2c9e3c0c 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -41,8 +41,7 @@ Device Drivers Base .. kernel-doc:: drivers/base/platform.c :export: -.. kernel-doc:: drivers/base/bus.c - :export: +:ref:`bus_types` Device Drivers DMA Management - -- 2.30.1
Re: [PATCH 4.9 00/41] 4.9.260-rc1 review
On Fri, 5 Mar 2021 at 18:12, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.260 release. > There are 41 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.260-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.9.260-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: e118f9b98b963e03939869e5953a52351352f216 git describe: v4.9.259-42-ge118f9b98b96 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.259-42-ge118f9b98b96 No regressions (compared to build v4.9.259) No fixes (compared to build v4.9.259) Ran 39259 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-64k_page_size - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - sparc - x15 - arm - x86_64 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-intel_pstate * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sysctl * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-zram * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * v4l2-compliance * fwts * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-ipc * kselftest-ir * kselftest-kcmp * libhugetlbfs * ltp-fs-tests * ltp-hugetlb-tests * ltp-mm-tests * network-basic-tests * kvm-unit-tests * ltp-open-posix-tests * kselftest-vm * kselftest-kexec * kselftest-x86 -- Linaro LKFT https://lkft.linaro.org
[PATCH 2/2] riscv: Enable generic clockevent broadcast
From: Guo Ren
When percpu-timers are stopped by deep power saving mode, we
need system timer help to broadcast IPI_TIMER.
This is first introduced by broken x86 hardware, where the local apic
timer stops in C3 state. But many other architectures(powerpc, mips,
arm, hexagon, openrisc, sh) have supported the infrastructure to
deal with Power Management issues.
Signed-off-by: Guo Ren
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Daniel Lezcano
Cc: Anup Patel
Cc: Atish Patra
Cc: Palmer Dabbelt
Cc: Greentime Hu
---
arch/riscv/Kconfig | 2 ++
arch/riscv/kernel/smp.c | 16
2 files changed, 18 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85d626b8ce5e..8637e7344abe 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -28,6 +28,7 @@ config RISCV
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU
+ select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
@@ -39,6 +40,7 @@ config RISCV
select EDAC_SUPPORT
select GENERIC_ARCH_TOPOLOGY if SMP
select GENERIC_ATOMIC64 if !64BIT
+ select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_EARLY_IOREMAP
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
select GENERIC_IOREMAP
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index ea028d9e0d24..8325d33411d8 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -27,6 +28,7 @@ enum ipi_message_type {
IPI_CALL_FUNC,
IPI_CPU_STOP,
IPI_IRQ_WORK,
+ IPI_TIMER,
IPI_MAX
};
@@ -176,6 +178,12 @@ void handle_IPI(struct pt_regs *regs)
irq_work_run();
}
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+ if (ops & (1 << IPI_TIMER)) {
+ stats[IPI_TIMER]++;
+ tick_receive_broadcast();
+ }
+#endif
BUG_ON((ops >> IPI_MAX) != 0);
/* Order data access and bit testing. */
@@ -192,6 +200,7 @@ static const char * const ipi_names[] = {
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_CPU_STOP] = "CPU stop interrupts",
[IPI_IRQ_WORK] = "IRQ work interrupts",
+ [IPI_TIMER] = "Timer broadcast interrupts",
};
void show_ipi_stats(struct seq_file *p, int prec)
@@ -217,6 +226,13 @@ void arch_send_call_function_single_ipi(int cpu)
send_ipi_single(cpu, IPI_CALL_FUNC);
}
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+void tick_broadcast(const struct cpumask *mask)
+{
+ send_ipi_mask(mask, IPI_TIMER);
+}
+#endif
+
void smp_send_stop(void)
{
unsigned long timeout;
--
2.25.1
[PATCH 1/2] csky: Enable generic clockevent broadcast
From: Guo Ren
When percpu-timers are stopped by deep power saving mode, we need
system timer help to broadcast IPI_TIMER.
This is first introduced by broken x86 hardware, where the local apic
timer stops in C3 state. But many other architectures(powerpc, mips,
arm, hexagon, openrisc, sh) have supported the infrastructure to
deal with Power Management issues.
Signed-off-by: Guo Ren
Cc: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Daniel Lezcano
---
arch/csky/Kconfig | 2 ++
arch/csky/kernel/smp.c | 17 +
2 files changed, 19 insertions(+)
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index 34e91224adc3..4328511ac050 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -6,6 +6,7 @@ config CSKY
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
+ select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_WANT_FRAME_POINTERS if !CPU_CK610
@@ -19,6 +20,7 @@ config CSKY
select IRQ_DOMAIN
select HANDLE_DOMAIN_IRQ
select DW_APB_TIMER_OF
+ select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IOREMAP
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
diff --git a/arch/csky/kernel/smp.c b/arch/csky/kernel/smp.c
index 0f9f5eef9338..76d38d84da70 100644
--- a/arch/csky/kernel/smp.c
+++ b/arch/csky/kernel/smp.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,7 @@ enum ipi_message_type {
IPI_RESCHEDULE,
IPI_CALL_FUNC,
IPI_IRQ_WORK,
+ IPI_TIMER,
IPI_MAX
};
@@ -67,6 +69,13 @@ static irqreturn_t handle_ipi(int irq, void *dev)
irq_work_run();
}
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+ if (ops & (1 << IPI_TIMER)) {
+ stats[IPI_TIMER]++;
+ tick_receive_broadcast();
+ }
+#endif
+
BUG_ON((ops >> IPI_MAX) != 0);
}
@@ -102,6 +111,7 @@ static const char * const ipi_names[] = {
[IPI_RESCHEDULE]= "Rescheduling interrupts",
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_IRQ_WORK] = "Irq work interrupts",
+ [IPI_TIMER] = "Timer broadcast interrupts",
};
int arch_show_interrupts(struct seq_file *p, int prec)
@@ -130,6 +140,13 @@ void arch_send_call_function_single_ipi(int cpu)
send_ipi_message(cpumask_of(cpu), IPI_CALL_FUNC);
}
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+void tick_broadcast(const struct cpumask *mask)
+{
+ send_ipi_message(mask, IPI_TIMER);
+}
+#endif
+
static void ipi_stop(void *unused)
{
while (1);
--
2.25.1
[syzbot] general protection fault in klist_iter_exit
Hello, syzbot found the following issue on: HEAD commit:d310ec03 Merge tag 'perf-core-2021-02-17' of git://git.ker.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1350c796d0 kernel config: https://syzkaller.appspot.com/x/.config?x=2b8307379601586a dashboard link: https://syzkaller.appspot.com/bug?extid=e690c969b19e84332c36 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1480f5b6d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e826dad0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e690c969b19e84332...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc01: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0008-0x000f] CPU: 0 PID: 3882 Comm: kworker/0:3 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x21/0x80 lib/klist.c:313 Code: 66 0f 1f 84 00 00 00 00 00 41 54 55 53 48 89 fb e8 24 30 98 fd 48 8d 6b 08 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <80> 3c 02 00 75 40 4c 8b 63 08 4d 85 e4 74 2e e8 fb 2f 98 fd 31 f6 RSP: 0018:c9000312fbf8 EFLAGS: 00010202 RAX: dc00 RBX: RCX: RDX: 0001 RSI: 83daa98c RDI: RBP: 0008 R08: R09: 8d6fc867 R10: fbfff1adf90c R11: 11ede8aa R12: 888143cb7540 R13: R14: 88801bce1520 R15: 8880b9c34980 FS: () GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f2a3562f1f0 CR3: 17103000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: nfc_device_iter_exit net/nfc/nfc.h:121 [inline] nfc_genl_dump_devices_done+0x31/0x50 net/nfc/netlink.c:639 genl_lock_done+0x8d/0x100 net/netlink/genetlink.c:636 netlink_sock_destruct+0x96/0x2b0 net/netlink/af_netlink.c:398 __sk_destruct+0x4b/0x900 net/core/sock.c:1795 sk_destruct+0xbd/0xe0 net/core/sock.c:1839 __sk_free+0xef/0x3d0 net/core/sock.c:1850 sk_free+0x78/0xa0 net/core/sock.c:1861 process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 --- This report 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 issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 5.11 000/104] 5.11.4-rc1 review
On Fri, 5 Mar 2021 at 17:55, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.11.4 release. > There are 104 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.4-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.11.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing NOTE: LTP pty test case hangup01 is getting PASS on this version. Summary kernel: 5.11.4-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.11.y git commit: f598f183ed0a259f541fe8479bbadcc20c89c7a9 git describe: v5.11.3-105-gf598f183ed0a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.11.y/build/v5.11.3-105-gf598f183ed0a No regressions (compared to build v5.11.3) fixes (compared to build 5.11.3) -- ltp-pty-tests: * hangup01 Ran 45135 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-64k_page_size - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - nxp-ls2088-64k_page_size - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * kselftest- * kselftest-bpf * kselftest-intel_pstate * kselftest-lib * kselftest-livepatch * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * libhugetlbfs * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * perf * v4l2-compliance * ltp-commands-tests * ltp-containers-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * kselftest-android * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lkdtm * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * ltp-controllers-tests * ltp-open-posix-tests * ltp-sched-tests * kvm-unit-tests * fwts * kunit * rcutorture -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] leds: trigger: fix potential deadlock with libata
On Sat, Mar 06, 2021 at 09:39:54PM +0100, Marc Kleine-Budde wrote:
> Hello *,
>
> On 02.11.2020 11:41:52, Andrea Righi wrote:
> > We have the following potential deadlock condition:
> >
> >
> > WARNING: possible irq lock inversion dependency detected
> > 5.10.0-rc2+ #25 Not tainted
> >
> > swapper/3/0 just changed the state of lock:
> > 8880063bd618 (>lock){-...}-{2:2}, at:
> > ata_bmdma_interrupt+0x27/0x200
> > but this lock took another, HARDIRQ-READ-unsafe lock in the past:
> > (>leddev_list_lock){.+.?}-{2:2}
> >
> > and interrupts could create inverse lock ordering between them.
>
> [...]
>
> > ---
> > drivers/leds/led-triggers.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> > index 91da90cfb11d..16d1a93a10a8 100644
> > --- a/drivers/leds/led-triggers.c
> > +++ b/drivers/leds/led-triggers.c
> > @@ -378,14 +378,15 @@ void led_trigger_event(struct led_trigger *trig,
> > enum led_brightness brightness)
> > {
> > struct led_classdev *led_cdev;
> > + unsigned long flags;
> >
> > if (!trig)
> > return;
> >
> > - read_lock(>leddev_list_lock);
> > + read_lock_irqsave(>leddev_list_lock, flags);
> > list_for_each_entry(led_cdev, >led_cdevs, trig_list)
> > led_set_brightness(led_cdev, brightness);
> > - read_unlock(>leddev_list_lock);
> > + read_unlock_irqrestore(>leddev_list_lock, flags);
> > }
> > EXPORT_SYMBOL_GPL(led_trigger_event);
>
> meanwhile this patch hit v5.10.x stable and caused a performance
> degradation on our use case:
>
> It's an embedded ARM system, 4x Cortex A53, with an SPI attached CAN
> controller. CAN stands for Controller Area Network and here used to
> connect to some automotive equipment. Over CAN an ISOTP (a CAN-specific
> Transport Protocol) transfer is running. With this patch, we see CAN
> frames delayed for ~6ms, the usual gap between CAN frames is 240µs.
>
> Reverting this patch, restores the old performance.
>
> What is the best way to solve this dilemma? Identify the critical path
> in our use case? Is there a way we can get around the irqsave in
> led_trigger_event()?
>
Probably, we can change from rwlock to rcu here, POC code as follow,
only compile tested. Marc, could you see whether this help the
performance on your platform? Please note that I haven't test it in a
running kernel and I'm not that familir with led subsystem, so use it
with caution ;-)
(While at it, I think maybe we miss the leddev_list_lock in net/mac80211
in the patch)
Regards,
Boqun
--->8
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 4e7b78a84149..ae68ccab6cc9 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -171,10 +171,12 @@ int led_trigger_set(struct led_classdev *led_cdev, struct
led_trigger *trig)
/* Remove any existing trigger */
if (led_cdev->trigger) {
- write_lock_irqsave(_cdev->trigger->leddev_list_lock, flags);
- list_del(_cdev->trig_list);
- write_unlock_irqrestore(_cdev->trigger->leddev_list_lock,
+ spin_lock_irqsave(_cdev->trigger->leddev_list_lock, flags);
+ list_del_rcu(_cdev->trig_list);
+ spin_unlock_irqrestore(_cdev->trigger->leddev_list_lock,
flags);
+ /* Wait for the readers gone */
+ synchronize_rcu();
cancel_work_sync(_cdev->set_brightness_work);
led_stop_software_blink(led_cdev);
if (led_cdev->trigger->deactivate)
@@ -186,9 +188,9 @@ int led_trigger_set(struct led_classdev *led_cdev, struct
led_trigger *trig)
led_set_brightness(led_cdev, LED_OFF);
}
if (trig) {
- write_lock_irqsave(>leddev_list_lock, flags);
- list_add_tail(_cdev->trig_list, >led_cdevs);
- write_unlock_irqrestore(>leddev_list_lock, flags);
+ spin_lock_irqsave(>leddev_list_lock, flags);
+ list_add_tail_rcu(_cdev->trig_list, >led_cdevs);
+ spin_unlock_irqrestore(>leddev_list_lock, flags);
led_cdev->trigger = trig;
if (trig->activate)
@@ -223,9 +225,12 @@ int led_trigger_set(struct led_classdev *led_cdev, struct
led_trigger *trig)
trig->deactivate(led_cdev);
err_activate:
- write_lock_irqsave(_cdev->trigger->leddev_list_lock, flags);
- list_del(_cdev->trig_list);
- write_unlock_irqrestore(_cdev->trigger->leddev_list_lock, flags);
+ spin_lock_irqsave(_cdev->trigger->leddev_list_lock, flags);
+ list_del_rcu(_cdev->trig_list);
+ spin_unlock_irqrestore(_cdev->trigger->leddev_list_lock, flags);
+
+ /* XXX could use call_rcu() here? */
+
Re: [PATCH] Expose the bus kernel docs to the build docs.
Thanks for the feedback. I will cut another patch in a sec. On 3/6/21 5:44 PM, Matthew Wilcox wrote: Do you want to put a heading in front of it? I did this in xarray.rst: Functions and structures .. kernel-doc:: include/linux/xarray.h .. kernel-doc:: lib/xarray.c Also, I see that drivers/base/bus.c is included in driver-api/infrastructure.rst, and I feel that they should probably be included together?
Re: [PATCH] Expose the bus kernel docs to the build docs.
On Sat, Mar 06, 2021 at 05:33:01PM -0800, Wren Turkal wrote: > Before, the bus type related APIs that were defined in the > include/linux/device/bus.h were not referenced anywhere in the docs, so > I linked it to the bus types api documentation. I think this is a good thing to do. > +++ b/Documentation/driver-api/driver-model/bus.rst > @@ -144,3 +144,5 @@ sysfs directory using:: > > int bus_create_file(struct bus_type *, struct bus_attribute *); > void bus_remove_file(struct bus_type *, struct bus_attribute *); > + > +.. kernel-doc:: include/linux/device/bus.h Do you want to put a heading in front of it? I did this in xarray.rst: Functions and structures .. kernel-doc:: include/linux/xarray.h .. kernel-doc:: lib/xarray.c Also, I see that drivers/base/bus.c is included in driver-api/infrastructure.rst, and I feel that they should probably be included together?
[rcu:rcu/next] BUILD SUCCESS 87f839888775b31854553de50d67b1c207dad705
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next branch HEAD: 87f839888775b31854553de50d67b1c207dad705 Merge branch 'lkmm-dev.2021.03.04a' into HEAD elapsed time: 3072m configs tested: 131 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig sh se7750_defconfig arm pxa3xx_defconfig arm u8500_defconfig m68k sun3x_defconfig armmvebu_v7_defconfig arm aspeed_g4_defconfig sh se7724_defconfig riscvalldefconfig mips bmips_be_defconfig m68km5272c3_defconfig m68km5307c3_defconfig shecovec24-romimage_defconfig sparc64 alldefconfig armdove_defconfig arm multi_v4t_defconfig powerpc chrp32_defconfig powerpc tqm8541_defconfig arm s3c6400_defconfig m68km5407c3_defconfig powerpc bamboo_defconfig arm shannon_defconfig powerpc akebono_defconfig powerpc motionpro_defconfig arm omap2plus_defconfig armqcom_defconfig powerpcklondike_defconfig mipsqi_lb60_defconfig arm pxa255-idp_defconfig sh sh7785lcr_32bit_defconfig arm integrator_defconfig powerpc ppc64_defconfig mips loongson3_defconfig sh se7619_defconfig mips cobalt_defconfig arm sunxi_defconfig armtrizeps4_defconfig powerpc pseries_defconfig h8300 defconfig powerpc iss476-smp_defconfig armshmobile_defconfig m68k atari_defconfig armmmp2_defconfig powerpc mpc836x_mds_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20210304 x86_64 randconfig-a001-20210304 x86_64 randconfig-a004-20210304 x86_64 randconfig-a005-20210304 x86_64 randconfig-a002-20210304 x86_64 randconfig-a003-20210304 i386 randconfig-a005-20210305 i386 randconfig-a003-20210305 i386 randconfig-a002-20210305 i386 randconfig-a004-20210305 i386 randconfig-a006-20210305 i386 randconfig-a001-20210305 i386 randconfig-a005-20210304 i386 randconfig-a003-20210304 i386 randconfig-a002-20210304 i386 randconfig-a004-20210304 i386 randconfig-a006-20210304 i386 randconfig-a001-20210304 x86_64 randconfig-a013-20210305 x86_64
[rcu:dev.2021.03.03b] BUILD SUCCESS b4838c004a52080e221bc224d6425a5a8eba238d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2021.03.03b branch HEAD: b4838c004a52080e221bc224d6425a5a8eba238d net: phy: make mdio_bus_phy_suspend/resume as __maybe_unused elapsed time: 3149m configs tested: 98 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig armspear6xx_defconfig powerpc arches_defconfig powerpc pseries_defconfig xtensa iss_defconfig sh ul2_defconfig microblaze mmu_defconfig nds32alldefconfig sh se7705_defconfig mipsmaltaup_defconfig arm pxa255-idp_defconfig arm pxa168_defconfig powerpc pq2fads_defconfig arm h3600_defconfig armcerfcube_defconfig shshmin_defconfig arm cm_x300_defconfig mips db1xxx_defconfig shedosk7760_defconfig powerpc lite5200b_defconfig powerpc tqm8540_defconfig arm pxa3xx_defconfig armshmobile_defconfig m68k atari_defconfig armmmp2_defconfig powerpc mpc836x_mds_defconfig mips rt305x_defconfig sh secureedge5410_defconfig powerpc ppc6xx_defconfig arm iop32x_defconfig powerpc ksi8560_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig s390 allmodconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20210304 x86_64 randconfig-a001-20210304 x86_64 randconfig-a004-20210304 x86_64 randconfig-a005-20210304 x86_64 randconfig-a002-20210304 x86_64 randconfig-a003-20210304 i386 randconfig-a005-20210304 i386 randconfig-a003-20210304 i386 randconfig-a002-20210304 i386 randconfig-a004-20210304 i386 randconfig-a006-20210304 i386 randconfig-a001-20210304 i386 randconfig-a016-20210304 i386 randconfig-a012-20210304 i386 randconfig-a013-20210304 i386 randconfig-a014-20210304 i386 randconfig-a015-20210304 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation
[PATCH] Expose the bus kernel docs to the build docs.
Before, the bus type related APIs that were defined in the include/linux/device/bus.h were not referenced anywhere in the docs, so I linked it to the bus types api documentation. Signed-off-by: Wren Turkal --- Documentation/driver-api/driver-model/bus.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/driver-api/driver-model/bus.rst b/Documentation/driver-api/driver-model/bus.rst index 016b15a6e8ea..4cd237ded827 100644 --- a/Documentation/driver-api/driver-model/bus.rst +++ b/Documentation/driver-api/driver-model/bus.rst @@ -144,3 +144,5 @@ sysfs directory using:: int bus_create_file(struct bus_type *, struct bus_attribute *); void bus_remove_file(struct bus_type *, struct bus_attribute *); + +.. kernel-doc:: include/linux/device/bus.h -- 2.30.1
Re: [RFC][PATCH 1/2] x86: remove duplicate TSC DEADLINE MSR definitions
On 3/5/20 9:47 AM, Dave Hansen wrote: > There are two definitions for the TSC deadline MSR in msr-index.h, > one with an underscore and one without. Axe one of them and move > all the references over to the other one. > > Cc: x...@kernel.org > Cc: Peter Zijlstra Better late than never: Signed-off-by: Dave Hansen
Re: [PATCH v10 3/9] crypto: Add math to support fast NIST P384
On 3/6/21 7:03 PM, Vitaly Chikunov wrote:
Stefan,
On Sat, Mar 06, 2021 at 06:29:18PM -0500, Stefan Berger wrote:
On 3/6/21 2:25 PM, Vitaly Chikunov wrote:
On Thu, Mar 04, 2021 at 07:51:57PM -0500, Stefan Berger wrote:
From: Saulo Alessandre
* crypto/ecc.c
- add vli_mmod_fast_384
- change some routines to pass ecc_curve forward until vli_mmod_fast
* crypto/ecc.h
- add ECC_CURVE_NIST_P384_DIGITS
- change ECC_MAX_DIGITS to P384 size
Signed-off-by: Saulo Alessandre
Tested-by: Stefan Berger
---
crypto/ecc.c | 266 +--
crypto/ecc.h | 3 +-
2 files changed, 194 insertions(+), 75 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index f6cef5a7942d..c125576cda6b 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -778,18 +778,133 @@ static void vli_mmod_fast_256(u64 *result, const u64
*product,
...
/* Computes result = product % curve_prime for different curve_primes.
*
* Note that curve_primes are distinguished just by heuristic check and
* not by complete conformance check.
*/
static bool vli_mmod_fast(u64 *result, u64 *product,
- const u64 *curve_prime, unsigned int ndigits)
+ const struct ecc_curve *curve)
{
u64 tmp[2 * ECC_MAX_DIGITS];
+ const u64 *curve_prime = curve->p;
+ const unsigned int ndigits = curve->g.ndigits;
- /* Currently, both NIST primes have -1 in lowest qword. */
- if (curve_prime[0] != -1ull) {
+ /* Currently, all NIST have name nist_.* */
+ if (strncmp(curve->name, "nist_", 5) != 0) {
I am not sure, but maybe this strncmp should not be optimized somehow,
since vli_mmod_fast could be called quite frequently. Perhaps by integer
algo id or even callback?
Should be optimized or should not be? You seem to say both.
Excuse me for the typo. I meant "should be optimized". I think, maybe
it's time to add algo selector id (for the case statement, for example
instead of `switch (ndigits)') or just callback for a low level mmod
function.
If you think this would not impact performance then nevermind.
I think it would only be a few cycles. Of course we could introduce a
flag to indicate nist functions (rather than using strncmp on the name)
or work with the callbacks (only for the nist functions?) as you
mentioned, but maybe that's something we could do after? Either way we
would have to pass the ecc_curve pointer all the way into vli_mmod_fast.
So this change here is preparing for this as well.
Stefan
Re: [PATCH] PCI: acpiphp: Fixed coding style
Hi,
Thank you for sending the patch over. Few suggestions below.
There seem to be an extra space in the subject line.
> In this commit fixed coding style for braces and comments.
Where these coding style changes suggested by a tool? For example, was it
something like checkpatch.pl? If so, then it would be prudent to
mention that the script found these for future reference.
[...]
> - struct list_head funcs; /* one slot may have different
> -objects (i.e. for each function) */
> + struct list_head funcs; /* one slot may have different */
> + /* objects (i.e. for each function) */
[...]
Above would be a single line commit that has been made to with within
the line length rules, as otherwise the line would be too long.
This is not necessarily something that we ought to fix, see for example:
https://elixir.bootlin.com/linux/v5.11.3/source/include/linux/pci.h
[...]
> -struct acpiphp_attention_info
> -{
> +struct acpiphp_attention_info {
> int (*set_attn)(struct hotplug_slot *slot, u8 status);
> int (*get_attn)(struct hotplug_slot *slot, u8 *status);
> struct module *owner;
[...]
Nice catch!
Generally, you would also need to your full name when providing your
"Signed-off-by:" following the style that has been widely accepted. See
git log for how it would normally look like, and also have a look at the
following for some general guidance on how to submit patches:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Krzysztof
Re: [PATCH] xhci: Remove unused value len from xhci_unmap_temp_buf
On 3/7/21 12:25 AM, Greg Kroah-Hartman wrote:
> On Sat, Mar 06, 2021 at 08:06:44PM +0800, zhangkun...@163.com wrote:
>> From: Zhang Kun
>>
>> The value assigned to len by sg_pcopy_from_buffer() never used for
>> anything, so remove it.
>>
>> Signed-off-by: Zhang Kun
>> ---
>> drivers/usb/host/xhci.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index bd27bd670104..6ebda89d476c 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -1335,7 +1335,6 @@ static bool xhci_urb_temp_buffer_required(struct
>> usb_hcd *hcd,
>>
>> static void xhci_unmap_temp_buf(struct usb_hcd *hcd, struct urb *urb)
>> {
>> -unsigned int len;
>> unsigned int buf_len;
>> enum dma_data_direction dir;
>>
>> @@ -1351,7 +1350,7 @@ static void xhci_unmap_temp_buf(struct usb_hcd *hcd,
>> struct urb *urb)
>> dir);
>>
>> if (usb_urb_dir_in(urb))
>> -len = sg_pcopy_from_buffer(urb->sg, urb->num_sgs,
>> +sg_pcopy_from_buffer(urb->sg, urb->num_sgs,
>> urb->transfer_buffer,
>> buf_len,
>> 0);
>
> SHouldn't this be checked instead of ignored?
>
Hi, Greg.
Considering your tips I checked sg_pcopy_from_buffer(). it copys data
from urb->transfer_buffer to urb->sg, and only returns 0 or the
'number of copied bytes', and seems to has no other exception branchs
that need to be checked. So I think it should be ingnored.
It may also be that I missed something, if that's the case, please
correct me.
Thanks,
Zhang
Re: [PATCH v3 3/3] dt-bindings: mediatek,dpi: add mt8192 to mediatek,dpi
Hi, Jitao: Rob Herring 於 2021年2月11日 週四 上午4:19寫道： > > On Mon, 08 Feb 2021 09:42:21 +0800, Jitao Shi wrote: > > Add compatible "mediatek,mt8192-dpi" for the mt8192 dpi. > > > > Signed-off-by: Jitao Shi > > --- > > .../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > Acked-by: Rob Herring Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang.
Re: [PATCH v2 2/2] drm/mediatek: dsi: fine tune the line time cause by EOTp
Hi, Jitao: Jitao Shi 於 2021年2月1日 週一 上午11:36寫道： > > Enabling EoTp will make the line time larger, so the hfp and > hbp should be reduced to keep line time. Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 2bc46f2350f1..8c70ec39bfe1 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > @@ -481,6 +481,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) > timing->da_hs_zero + timing->da_hs_exit + 3; > > delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 : 12; > + delta += dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET ? 2 : 0; > > horizontal_frontporch_byte = vm->hfront_porch * dsi_tmp_buf_bpp; > horizontal_front_back_byte = horizontal_frontporch_byte + > horizontal_backporch_byte; > -- > 2.12.5 > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/mediatek: dsi: Fix EoTp flag
Hi, Jitao: Jitao Shi 於 2021年2月1日 週一 上午11:36寫道： > > SoC will transmit the EoTp (End of Transmission packet) when > MIPI_DSI_MODE_EOT_PACKET flag is set. I've modified the title and message as: drm/mediatek: dsi: Use symbolized register definition For HSTX_CKLP_EN and DIS_EOT, use symbolized register definition instead of magic number. And applied to mediatek-drm-next [1], thanks. https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 65fd99c528af..2bc46f2350f1 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > @@ -401,8 +401,11 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) > break; > } > > - tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; > - tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; > + if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) > + tmp_reg |= HSTX_CKLP_EN; > + > + if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET)) > + tmp_reg |= DIS_EOT; > > writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); > } > -- > 2.12.5 > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] PCI: quirk for preventing bus reset on TI C667X
Hi Antti, A few nitpicks, so feel free to ignore these, of course. If possible, capitalise the subject line. Also, perhaps "Add quirk to prevent bus (...)" might read better. > Some TI keystone C667X devices do no support bus/hot reset. Its PCIESS [...] It would be KeyStone in the above sentence. [...] > With this change device can be assigned to VMs with VFIO, but it will > leak state between VMs. Following-up on Bojrn's question about the state leak, see: https://lore.kernel.org/linux-pci/20210129234946.GA124037@bjorn-Precision-5520/ Would there be anything else that has to be done? Krzysztof
qemu meltdown test failure was Re: [PATCH 4.4 00/30] 4.4.260-rc1 review
Hi! > > Ok, so we ran some tests. > > > > And they failed: > > > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449 > > > > [ 26.785861] > > Received signal: TEST_CASE_ID=CVE-2018-3639 RESULT=fail > > > > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow > > strange, but it looks like real test failure. First let me try 7d472e4a11d6a2fb1c492b02c7d7dacd3297bbf4 -- v4.4.257-cip54. That is https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266532179 ... Qemu is OKAY. add3ff3730919447a7519fede0b8554132e0f8d5 Merge remote-tracking branch 'stable/queue/4.4' in to v4.4.260-bisect. Results will be at https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266534478 ... ... still pending. Aha, but I won't be able to bisect in that :-(. So let's create v4.4.259-cip: e988bf453263ff43de27336a31115e8f552cd520 Merge commit '93af63b25443f66d90450845526843076c81c7f0' into v4.4.260-bisect 93af63b25443f66d90450845526843076c81c7f0 Linux 4.4.259 And rebase v4.4.260 on top of that. So we now have this ... and it should enable bisection: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/XXX c700659b7d3efe7e5e1482aac93ccc6d88896696 media: v4l: ioctl: Fix memory leak in video_usercopy 430f39261e34361d909df9d25cdd7fe4925ab147 swap: fix swapfile read/write offset 0a3f4c372b91921ffc9976c142cc7de42f527d15 zsmalloc: account the number of compacted pages correctly test 266539168 8c461bb103f89696576945ad9cb376df34fa9d28 xen-netback: respect gnttab_map_refs()'s return value c6352c9b2e66258bd78101a85858e1b1c6c01fe2 Xen/gnttab: handle p2m update errors on a per-slot basis b854b5154c7a682856081b25552f59ff13b5edf6 scsi: iscsi: Verify lengths on passthrough PDUs 015110b4ba859649dd94f23040732c75fcd3c0f2 scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE 679dbc5d12389622c842ccce08b92bab3d8ce853 sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output 8f5a499b4489f8aaeb7e95ec8da955317006f767 scsi: iscsi: Restrict sessions and handles to admin capabilities 8e3bd2f64a90b6be947fc8636e2642f2f4186077 media: uvcvideo: Allow entities with no pads 55a0611f55d162faecf4514dea4351612b2ffc26 staging: most: sound: add sanity check for function argument 76471b77ee8eb76795cfaffef9065cf219fef432 Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data 163650eed99950e9a1b485fd927323430db2a01a x86/build: Treat R_386_PLT32 relocation as R_386_PC32 fcd9411f34ca2b80244adeb4589ee592cebabe58 ath10k: fix wmi mgmt tx queue full due to race condition c8b13f3c80f4ff8201a149a1eb2a45859be5b28b pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() a3a6ff3d2a4a5f6f092c3294c9c7c8d3a26a1190 wlcore: Fix command execute failure 19 for wl12xx 0334ca6c8e3a07688ceb5bbf7589d9ca8ad25d53 vt/consolemap: do font sum unsigned 48145a8b9d1aa1a8eada534df395f39355eb02f8 x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk test 266538760 1efe86b456816c95485c65cf9ba46a5bff8a241e staging: fwserial: Fix error handling in fwserial_create d1b114d9ab15fe3f9f87178af194c8e6573948a5 mm/hugetlb.c: fix unnecessary address expansion of pmd sharing ee60af793079bcf79a4ae0ff0877bd1c5767b0de net: fix up truesize of cloned skb in skb_prepare_for_shift() 6f2e9739399d5d2ba02d82fe32177c1e933116e9 xfs: Fix assert failure in xfs_setattr_size() 1ba9d3843164451426cc37413cd20d55a5702b3e JFS: more checks for invalid superblock 11f19718da9f3e5307a08d03e6bb72aef9450a9c hugetlb: fix update_and_free_page contig page struct assumption d2f0c8c15ff0900d76496b7cbb870c830b120867 scripts: set proper OpenSSL include dir also for sign-file ae3507eb02e8b6449add4d356d6ba788d65aee14 scripts: use pkg-config to locate libcrypto 66e96f4397bd1ca22275c3d7c2820d04a11ff765 mmc: sdhci-esdhc-imx: fix kernel panic when remove module test 266539768 8b4bc0f97fdd13b08c2436aad01bd4515d07f93a iwlwifi: pcie: fix to correct null check 6805f20f2187dde9e2ad44e045747bcaa621ee51 net: usb: qmi_wwan: support ZTE P685M modem 3879e0dbe534ac4b937455fe3af2248692e9f6d8 futex: Ensure the correct return value from futex_lock_pi() e988bf453263ff43de27336a31115e8f552cd520 Merge commit '93af63b25443f66d90450845526843076c81c7f0' into v4.4.260-bisect 93af63b25443f66d90450845526843076c81c7f0 Linux 4.4.259 Best regards,
Re: [PATCH v10 3/9] crypto: Add math to support fast NIST P384
Stefan,
On Sat, Mar 06, 2021 at 06:29:18PM -0500, Stefan Berger wrote:
> On 3/6/21 2:25 PM, Vitaly Chikunov wrote:
> >
> > On Thu, Mar 04, 2021 at 07:51:57PM -0500, Stefan Berger wrote:
> > > From: Saulo Alessandre
> > >
> > > * crypto/ecc.c
> > >- add vli_mmod_fast_384
> > >- change some routines to pass ecc_curve forward until vli_mmod_fast
> > >
> > > * crypto/ecc.h
> > >- add ECC_CURVE_NIST_P384_DIGITS
> > >- change ECC_MAX_DIGITS to P384 size
> > >
> > > Signed-off-by: Saulo Alessandre
> > > Tested-by: Stefan Berger
> > > ---
> > > crypto/ecc.c | 266 +--
> > > crypto/ecc.h | 3 +-
> > > 2 files changed, 194 insertions(+), 75 deletions(-)
> > >
> > > diff --git a/crypto/ecc.c b/crypto/ecc.c
> > > index f6cef5a7942d..c125576cda6b 100644
> > > --- a/crypto/ecc.c
> > > +++ b/crypto/ecc.c
> > > @@ -778,18 +778,133 @@ static void vli_mmod_fast_256(u64 *result, const
> > > u64 *product,
> > > ...
> > > /* Computes result = product % curve_prime for different curve_primes.
> > >*
> > >* Note that curve_primes are distinguished just by heuristic check and
> > >* not by complete conformance check.
> > >*/
> > > static bool vli_mmod_fast(u64 *result, u64 *product,
> > > - const u64 *curve_prime, unsigned int ndigits)
> > > + const struct ecc_curve *curve)
> > > {
> > > u64 tmp[2 * ECC_MAX_DIGITS];
> > > + const u64 *curve_prime = curve->p;
> > > + const unsigned int ndigits = curve->g.ndigits;
> > > - /* Currently, both NIST primes have -1 in lowest qword. */
> > > - if (curve_prime[0] != -1ull) {
> > > + /* Currently, all NIST have name nist_.* */
> > > + if (strncmp(curve->name, "nist_", 5) != 0) {
> > I am not sure, but maybe this strncmp should not be optimized somehow,
> > since vli_mmod_fast could be called quite frequently. Perhaps by integer
> > algo id or even callback?
>
> Should be optimized or should not be? You seem to say both.
Excuse me for the typo. I meant "should be optimized". I think, maybe
it's time to add algo selector id (for the case statement, for example
instead of `switch (ndigits)') or just callback for a low level mmod
function.
If you think this would not impact performance then nevermind.
Thanks,
>
> The code code here is shared with ecrdsa. The comparison won't go beyond a
> single letter considering the naming of the curves define here:
>
> "cp256a":
> https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L49
>
> "cp256b":
> https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L82
>
> "cp256c":
> https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L119
>
> "tc512a":
> https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L168
>
> and here:
>
> "nist_192":
> https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecc_curve_defs.h#L18
>
> "nist_256":
> https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecc_curve_defs.h#L45
>
>
> All the ecrdsa curves were previously evaluating 'curve_prime[0] != -1ull',
> so it doesn't change anything.
>
> Stefan
>
Re: [PATCH] PCI: iproc: Fix return value of iproc_msi_irq_domain_alloc()
Hi Pali,
> IRQ domain alloc function should return zero on success. Non-zero value
> indicates failure.
>
> Signed-off-by: Pali Rohár
> Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs")
[...]
Nice catch!
Reviewed-by: Krzysztof Wilczyński
Krzysztof
[PATCH] iio: adc: axp20x_adc: fix charging current reporting on AXP22x
Both the charging and discharging currents on AXP22x are stored as 12-bit integers, in accordance with the datasheet. It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA). The scale factor of 0.5 is never mentioned in datasheet, nor in the vendor source code. I think it was here to compensate for erroneous additional bit in register width. Tested on custom A40i+AXP221s board with external ammeter as a reference. Signed-off-by: Evgeny Boger --- drivers/iio/adc/axp20x_adc.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c index 3e0c0233b431..8db6699c20c3 100644 --- a/drivers/iio/adc/axp20x_adc.c +++ b/drivers/iio/adc/axp20x_adc.c @@ -253,17 +253,7 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev, struct axp20x_adc_iio *info = iio_priv(indio_dev); int size; - /* -* N.B.: Unlike the Chinese datasheets tell, the charging current is -* stored on 12 bits, not 13 bits. Only discharging current is on 13 -* bits. -*/ - if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I) - size = 13; - else - size = 12; - - *val = axp20x_read_variable_width(info->regmap, chan->address, size); + *val = axp20x_read_variable_width(info->regmap, chan->address, 12); if (*val < 0) return *val; @@ -387,7 +377,7 @@ static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val, case IIO_CURRENT: *val = 0; - *val2 = 50; + *val2 = 100; return IIO_VAL_INT_PLUS_MICRO; case IIO_TEMP: -- 2.17.1
Re: [PATCH 03/44] PCI: remove synclink entries from pci_ids
Hi Jiri, > The drivers were removed in a1f714b44e34 (tty: Remove redundant synclink > driver) and 3d608a591b2b (tty: Remove redundant synclinkmp driver). > > So remove also the PCI ID entries. [...] Thank you! Reviewed-by: Krzysztof Wilczyński Krzysztof
Re: [PATCH v3 1/2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD
Wesley Cheng wrote: > > On 1/8/2021 4:44 PM, Thinh Nguyen wrote: >> Hi, >> >> John Stultz wrote: >>> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi wrote: Hi, John Stultz writes: > From: Yu Chen > > Just resending this, as discussion died out a bit and I'm not > sure how to make further progress. See here for debug data that > was requested last time around: > > https://urldefense.com/v3/__https://lore.kernel.org/lkml/calaqxlxdnaufjkx0an9xwwtfwvjmwigppy2aqsnj56yvnbu...@mail.gmail.com/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnsnlqd3w$ > > > With the current dwc3 code on the HiKey960 we often see the > COREIDLE flag get stuck off in __dwc3_gadget_start(), which > seems to prevent the reset irq and causes the USB gadget to > fail to initialize. > > We had seen occasional initialization failures with older > kernels but with recent 5.x era kernels it seemed to be becoming > much more common, so I dug back through some older trees and > realized I dropped this quirk from Yu Chen during upstreaming > as I couldn't provide a proper rational for it and it didn't > seem to be necessary. I now realize I was wrong. > > After resubmitting the quirk, Thinh Nguyen pointed out that it > shouldn't be a quirk at all and it is actually mentioned in the > programming guide that it should be done when switching modes > in DRD. > > So, to avoid these !COREIDLE lockups seen on HiKey960, this > patch issues GCTL soft reset when switching modes if the > controller is in DRD mode. > > Cc: Felipe Balbi > Cc: Tejas Joglekar > Cc: Yang Fei > Cc: YongQin Liu > Cc: Andrzej Pietrasiewicz > Cc: Thinh Nguyen > Cc: Jun Li > Cc: Mauro Carvalho Chehab > Cc: Greg Kroah-Hartman > Cc: linux-...@vger.kernel.org > Signed-off-by: Yu Chen > Signed-off-by: John Stultz > --- > v2: > * Rework to always call the GCTL soft reset in DRD mode, > rather then using a quirk as suggested by Thinh Nguyen > > v3: > * Move GCTL soft reset under the spinlock as suggested by > Thinh Nguyen Because this is such an invasive change, I would prefer that we get Tested-By tags from a good fraction of the users before applying these two changes. >>> I'm happy to reach out to folks to try to get that. Though I'm >>> wondering if it would be better to put it behind a dts quirk flag, as >>> originally proposed? >>> >>> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20201021181803.79650-1-john.stu...@linaro.org/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnRWITZfc$ >>> >>> >>> That way folks can enable it for devices as they need? >>> >>> Again, I'm not trying to force this in as-is, just mostly sending it >>> out again for discussion to understand what other approach might work. >>> >>> thanks >>> -john >> A quirk would imply something is broken/diverged from the design right? >> But it's not the case here, and at least this is needed for HiKey960. >> Also, I think Rob will be ok with not adding 1 more quirk to the dwc3 >> devicetree. :) >> >> BR, >> Thinh >> > Hi All, > > Sorry for jumping in, but I checked the SNPS v1.90a databook, and that > seemed to remove the requirement for the GCTL.softreset before writing > to PRTCAPDIR. Should we consider adding a controller version/IP check? > Hi Wesley, From what I see in the v1.90a databook and others, the flow remains the same. I need to check internally, but I'm not aware of the change. BR, Thinh
Re: [PATCH v3 2/2] usb: dwc3: Fix DRD mode change sequence following programming guide
Wesley Cheng wrote: > > On 1/7/2021 5:51 PM, John Stultz wrote: >> In reviewing the previous patch, Thinh Nguyen pointed out that >> the DRD mode change sequence should be like the following when >> switching from host -> device according to the programming guide >> (for all DRD IPs): >> 1. Reset controller with GCTL.CoreSoftReset >> 2. Set GCTL.PrtCapDir(device) >> 3. Soft reset with DCTL.CSftRst >> 4. Then follow up with the initializing registers sequence >> >> The current code does: >> a. Soft reset with DCTL.CSftRst on driver probe >> b. Reset controller with GCTL.CoreSoftReset (added in previous >>patch) >> c. Set GCTL.PrtCapDir(device) >> d. < missing DCTL.CSftRst > >> e. Then follow up with initializing registers sequence >> >> So this patch adds the DCTL.CSftRst soft reset that was currently >> missing from the dwc3 mode switching. >> >> Cc: Felipe Balbi >> Cc: Tejas Joglekar >> Cc: Yang Fei >> Cc: YongQin Liu >> Cc: Andrzej Pietrasiewicz >> Cc: Thinh Nguyen >> Cc: Jun Li >> Cc: Mauro Carvalho Chehab >> Cc: Greg Kroah-Hartman >> Cc: linux-...@vger.kernel.org >> Signed-off-by: John Stultz >> --- >> Feedback would be appreciated. I'm a little worried I should be >> conditionalizing the DCTL.CSftRst on DRD mode controllers, but >> I'm really not sure what the right thing to do is for non-DRD >> mode controllers. >> --- >> drivers/usb/dwc3/core.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index b6a6b90eb2d5..71f8b07ecb99 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -40,6 +40,8 @@ >> >> #define DWC3_DEFAULT_AUTOSUSPEND_DELAY 5000 /* ms */ >> >> +static int dwc3_core_soft_reset(struct dwc3 *dwc); >> + >> /** >> * dwc3_get_dr_mode - Validates and sets dr_mode >> * @dwc: pointer to our context structure >> @@ -177,6 +179,7 @@ static void __dwc3_set_mode(struct work_struct *work) >> >> dwc3_set_prtcap(dwc, dwc->desired_dr_role); >> >> +dwc3_core_soft_reset(dwc); > Hi John/Thinh/Felipe, > > I actually added this change into my local branch, because we were > seeing an issue when switching from host mode --> peripheral mode. What > was happening was that the RXFIFO register did not update back to the > expected value for peripheral mode by the time > dwc3_gadget_init_out_endpoint() was executed. With the logic to > calculate the EP max packet limit based on RXFIFO reg, this caused all > EPs to be set with an EP max limit of 0. > > With this change, it seemed to help with the above issue. However, can > we consider moving the core soft reset outside the spinlock? At least > with our PHY init routines, we have some msleep() calls for waiting for > the PHYs to be ready, which will end up as a sleeping while atomic bug. > (not sure if PHY init is required to be called in atomic context) > > Thanks > Wesley Cheng Hi Wesley, Thanks for letting us know the issue you're having also. Yes, you need to wait a certain amount of time to synchronize with the PHY (at least 50ms for dwc_usb32 and dwc_usb31 v1.80a and above, and less for older versions). When removing the spinlock to use msleep(), just make sure that there's no race issue. BTW, how long does your setup need to msleep()? As we suggested and explained before, this change is required as part of the programming guide. It should be added to the driver. It's not a quirk. BR, Thinh
Re: [PATCH v10 3/9] crypto: Add math to support fast NIST P384
On 3/6/21 2:25 PM, Vitaly Chikunov wrote:
Stefan,
On Thu, Mar 04, 2021 at 07:51:57PM -0500, Stefan Berger wrote:
From: Saulo Alessandre
* crypto/ecc.c
- add vli_mmod_fast_384
- change some routines to pass ecc_curve forward until vli_mmod_fast
* crypto/ecc.h
- add ECC_CURVE_NIST_P384_DIGITS
- change ECC_MAX_DIGITS to P384 size
Signed-off-by: Saulo Alessandre
Tested-by: Stefan Berger
---
crypto/ecc.c | 266 +--
crypto/ecc.h | 3 +-
2 files changed, 194 insertions(+), 75 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index f6cef5a7942d..c125576cda6b 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -778,18 +778,133 @@ static void vli_mmod_fast_256(u64 *result, const u64
*product,
...
/* Computes result = product % curve_prime for different curve_primes.
*
* Note that curve_primes are distinguished just by heuristic check and
* not by complete conformance check.
*/
static bool vli_mmod_fast(u64 *result, u64 *product,
- const u64 *curve_prime, unsigned int ndigits)
+ const struct ecc_curve *curve)
{
u64 tmp[2 * ECC_MAX_DIGITS];
+ const u64 *curve_prime = curve->p;
+ const unsigned int ndigits = curve->g.ndigits;
- /* Currently, both NIST primes have -1 in lowest qword. */
- if (curve_prime[0] != -1ull) {
+ /* Currently, all NIST have name nist_.* */
+ if (strncmp(curve->name, "nist_", 5) != 0) {
I am not sure, but maybe this strncmp should not be optimized somehow,
since vli_mmod_fast could be called quite frequently. Perhaps by integer
algo id or even callback?
Should be optimized or should not be? You seem to say both.
The code code here is shared with ecrdsa. The comparison won't go beyond
a single letter considering the naming of the curves define here:
"cp256a":
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L49
"cp256b":
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L82
"cp256c":
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L119
"tc512a":
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L168
and here:
"nist_192":
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecc_curve_defs.h#L18
"nist_256":
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecc_curve_defs.h#L45
All the ecrdsa curves were previously evaluating 'curve_prime[0] !=
-1ull', so it doesn't change anything.
Stefan
Re: [PATCH] dt-bindings: timer: renesas,tmu: add r8a779a0 TMU support
Hi Wolfram, Thanks for your work. On 2021-03-05 15:23:59 +0100, Wolfram Sang wrote: > Signed-off-by: Wolfram Sang Reviewed-by: Niklas Söderlund > --- > > This is the correct one. TMU passed the testsuite, CMT needs a second > look. > > Documentation/devicetree/bindings/timer/renesas,tmu.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml > b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml > index c54188731a1b..20af9ce05ae5 100644 > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml > @@ -30,6 +30,7 @@ properties: >- renesas,tmu-r8a7779 # R-Car H1 >- renesas,tmu-r8a77970 # R-Car V3M >- renesas,tmu-r8a77980 # R-Car V3H > + - renesas,tmu-r8a779a0 # R-Car V3U >- const: renesas,tmu > >reg: > -- > 2.29.2 > -- Regards, Niklas Söderlund
[PATCH] mfd: ab8500: Drop bm disable parameter
Nobody is passing the module parameter to disable the
battery management portions so just drop this parameter.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased on v5.12-rc, seems to have been missed for v5.12
merge window.
---
drivers/mfd/ab8500-core.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index a9037911162b..db72d27070d9 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -121,12 +121,6 @@
static DEFINE_SPINLOCK(on_stat_lock);
static u8 turn_on_stat_mask = 0xFF;
static u8 turn_on_stat_set;
-static bool no_bm; /* No battery management */
-/*
- * not really modular, but the easiest way to keep compat with existing
- * bootargs behaviour is to continue using module_param here.
- */
-module_param(no_bm, bool, S_IRUGO);
#define AB9540_MODEM_CTRL2_REG 0x23
#define AB9540_MODEM_CTRL2_SWDBBRSTN_BIT BIT(2)
@@ -1255,14 +1249,12 @@ static int ab8500_probe(struct platform_device *pdev)
if (ret)
return ret;
- if (!no_bm) {
- /* Add battery management devices */
- ret = mfd_add_devices(ab8500->dev, 0, ab8500_bm_devs,
- ARRAY_SIZE(ab8500_bm_devs), NULL,
- 0, ab8500->domain);
- if (ret)
- dev_err(ab8500->dev, "error adding bm devices\n");
- }
+ /* Add battery management devices */
+ ret = mfd_add_devices(ab8500->dev, 0, ab8500_bm_devs,
+ ARRAY_SIZE(ab8500_bm_devs), NULL,
+ 0, ab8500->domain);
+ if (ret)
+ dev_err(ab8500->dev, "error adding bm devices\n");
if (((is_ab8505(ab8500) || is_ab9540(ab8500)) &&
ab8500->chip_id >= AB8500_CUT2P0) || is_ab8540(ab8500))
--
2.29.2
Re: [PATCH 4.4 00/30] 4.4.260-rc1 review
Hi! > > > This is the start of the stable review cycle for the 4.4.260 release. > > > There are 30 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > Ok, so we ran some tests. > > > > And they failed: > > > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449 > > > > [ 26.785861] > > Received signal: TEST_CASE_ID=CVE-2018-3639 RESULT=fail > > > > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow > > strange, but it looks like real test failure. > > > > I'm cc: ing Chris, perhaps he can help. > > Can you bisect? I'm kind of hoping someone else hits this, too, as I'm not that experienced with the CIP q/a system. But in the meantime I resubmitted older kerneland it is passing on qemu, so it looks it might be real. I can probably bisect it on Monday. I may try to start bisection on Sunday. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: Digital signature
Re: [PATCH] MIPS: boot/compressed: Copy DTB to aligned address
On Sat, Mar 06, 2021 at 02:35:21PM -0700, Rob Herring wrote: > On Sat, Mar 6, 2021 at 1:45 AM Thomas Bogendoerfer > wrote: > > > > On Wed, Mar 03, 2021 at 02:37:55PM -0600, Rob Herring wrote: > > > On Wed, Mar 3, 2021 at 1:33 PM Paul Cercueil wrote: > > > > > > > > Since 5.12-rc1, the Device Tree blob must now be properly aligned. > > > > > > I had checked the other built-in cases as microblaze broke too, but > > > missed some of the many ways MIPS can have a dtb. Appended and > > > built-in DTBs were supposed to be temporary. :( > > > > and a fdt can also be provided by firmware. And according to spec > > there is no aligmnet requirement. So this whole change will break > > then. What was the reason for the whole churn ? > > There was a long discussion on devicetree-compiler list a few months > ago. In summary, a while back libfdt switched to accessors from raw > pointer accesses to avoid any possible unaligned accesses (is MIPS > always okay with unaligned accesses?). no, it will trap unaligned accesses, that's the reason for Paul's problem. > This was determined to be a > performance regression and an overkill as the DT structure itself > should always be naturally aligned if the dtb is 64-bit aligned. I > think 32-bit aligned has some possible misaligned accesses. the access macros are using *(unsigned long long *), which isn't even nice for 32bit CPUs... > As part of this, a dtb alignment check was added. So worst case, we > could disable that if need be. yeah, or override fdt32/64_to_cpu, if I understood the code correctly. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[PATCH net-next] net: usb: log errors to dmesg/syslog
Errors in protocol should be logged when the driver aborts operations.
If the driver can carry on and "humor" the device, then emitting
the message as debug output level is fine.
Signed-off-by: Grant Grundler
---
drivers/net/usb/usbnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reposting to net-next per instructions in
https://www.spinics.net/lists/netdev/msg715496.html
I've applied this patch to most chromeos kernels:
https://chromium-review.googlesource.com/q/hashtag:usbnet-rtl8156-support
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 1447da1d5729..bc7b93399bd5 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -887,7 +887,7 @@ int usbnet_open (struct net_device *net)
// insist peer be connected
if (info->check_connect && (retval = info->check_connect (dev)) < 0) {
- netif_dbg(dev, ifup, dev->net, "can't open; %d\n", retval);
+ netif_err(dev, ifup, dev->net, "can't open; %d\n", retval);
goto done;
}
--
2.29.2
[PATCH net-next] net: usb: cdc_ncm: emit dev_err on error paths
Several error paths in bind/probe code will only emit
output using dev_dbg. But if we are going to fail the
bind/probe, emit related output with "err" priority.
Signed-off-by: Grant Grundler
---
drivers/net/usb/cdc_ncm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Reposting to net-next per instructions in
https://www.spinics.net/lists/netdev/msg715496.html
I've applied this patch to most chromeos kernels:
https://chromium-review.googlesource.com/q/hashtag:usbnet-rtl8156-support
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 5a78848db93f..25498c311551 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -849,17 +849,17 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
usb_interface *intf, u8 data_
/* check if we got everything */
if (!ctx->data) {
- dev_dbg(>dev, "CDC Union missing and no IAD found\n");
+ dev_err(>dev, "CDC Union missing and no IAD found\n");
goto error;
}
if (cdc_ncm_comm_intf_is_mbim(intf->cur_altsetting)) {
if (!ctx->mbim_desc) {
- dev_dbg(>dev, "MBIM functional descriptor
missing\n");
+ dev_err(>dev, "MBIM functional descriptor
missing\n");
goto error;
}
} else {
if (!ctx->ether_desc || !ctx->func_desc) {
- dev_dbg(>dev, "NCM or ECM functional descriptors
missing\n");
+ dev_err(>dev, "NCM or ECM functional descriptors
missing\n");
goto error;
}
}
@@ -868,7 +868,7 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
usb_interface *intf, u8 data_
if (ctx->data != ctx->control) {
temp = usb_driver_claim_interface(driver, ctx->data, dev);
if (temp) {
- dev_dbg(>dev, "failed to claim data intf\n");
+ dev_err(>dev, "failed to claim data intf\n");
goto error;
}
}
@@ -924,7 +924,7 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
usb_interface *intf, u8 data_
if (ctx->ether_desc) {
temp = usbnet_get_ethernet_addr(dev,
ctx->ether_desc->iMACAddress);
if (temp) {
- dev_dbg(>dev, "failed to get mac address\n");
+ dev_err(>dev, "failed to get mac address\n");
goto error2;
}
dev_info(>dev, "MAC-Address: %pM\n", dev->net->dev_addr);
--
2.29.2
[PATCH] tasklet: Remove tasklet_kill_immediate
Ever since RCU was converted to softirq, it has no users.
Signed-off-by: Davidlohr Bueso
---
include/linux/interrupt.h | 1 -
kernel/softirq.c | 32
2 files changed, 33 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 967e25767153..36a2ac6baf9a 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -712,7 +712,6 @@ static inline void tasklet_enable(struct tasklet_struct *t)
}
extern void tasklet_kill(struct tasklet_struct *t);
-extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
extern void tasklet_init(struct tasklet_struct *t,
void (*func)(unsigned long), unsigned long data);
extern void tasklet_setup(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 9908ec4a9bfe..8b44ab9a2f69 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -658,38 +658,6 @@ static void run_ksoftirqd(unsigned int cpu)
}
#ifdef CONFIG_HOTPLUG_CPU
-/*
- * tasklet_kill_immediate is called to remove a tasklet which can already be
- * scheduled for execution on @cpu.
- *
- * Unlike tasklet_kill, this function removes the tasklet
- * _immediately_, even if the tasklet is in TASKLET_STATE_SCHED state.
- *
- * When this function is called, @cpu must be in the CPU_DEAD state.
- */
-void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu)
-{
- struct tasklet_struct **i;
-
- BUG_ON(cpu_online(cpu));
- BUG_ON(test_bit(TASKLET_STATE_RUN, >state));
-
- if (!test_bit(TASKLET_STATE_SCHED, >state))
- return;
-
- /* CPU is dead, so no lock needed. */
- for (i = _cpu(tasklet_vec, cpu).head; *i; i = &(*i)->next) {
- if (*i == t) {
- *i = t->next;
- /* If this was the tail element, move the tail ptr */
- if (*i == NULL)
- per_cpu(tasklet_vec, cpu).tail = i;
- return;
- }
- }
- BUG();
-}
-
static int takeover_tasklets(unsigned int cpu)
{
/* CPU is dead, so no lock needed. */
--
2.26.2
Re: [PATCH -next] mfd: ntxec: Support for EC in Tolino Shine 2 HD
On Sat, 6 Mar 2021 21:19:38 +0100 Jonathan Neuschäfer wrote: [...] > > > > + case NTXEC_VERSION_TOLINO_SHINE2: > > > > + has_rtc = false; > > > > + ec->regmap = devm_regmap_init(ec->dev, NULL, > > > > + ec->regmap, > > > > + _config_noack); > > > > > > Ah— A custom regmap stacked on top of the old regmap… I think this > > > deserves a comment. > > > > > Yes, devm_regmap_init_i2c() sets a different set of callbacks depending > > on circumstances. Seems to be the easiest way to avoid duplicating too > > much code. I really hope that there are not so much devices requiring > > such a dirty stuff that adding such thing to the generic regmap code > > would be justified. > > Ok, please add a short comment here or extend the one above the repmap > config struct, to save interested readers a bit of trouble. I guess "add > a wrapper" goes in right direction, but it didn't make the stacking > obvious to me when I first read it. > I will wait for some days to see whether anybody chokes on that stack. Regards, Andreas
5.12-rc1 and -rc2 - BUG/crash after KVM/USB connect/disconnect.
HP Z220 (xeon). Fedora 33 GCC 10.2.1 Boot system, connect via KVM (DVI/USB) and disconnect, then: . usb 1-1.1.1: USB disconnect, device number 6 usb 1-1.1.1.2: USB disconnect, device number 8 usb 1-1.1.1.4: USB disconnect, device number 9 usb 1-1.1.1.5: clear tt 5 (90d4) error -71 usb 1-1.1.1.5: USB disconnect, device number 11 usb 1-1.1.1.5.4: USB disconnect, device number 12 cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 BUG: kernel NULL pointer dereference, address: 0278 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] SMP NOPTI CPU: 0 PID: 2899 Comm: kworker/0:0 Not tainted 5.12.0-rc2 #1 Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.87 06/10/2019 Workqueue: usb_hub_wq hub_event RIP: 0010:gpiodevice_release+0xc/0x70 Code: c0 0f b6 c0 5b c3 85 c0 5b 0f 95 c0 0f b6 c0 c3 0f 0b eb b1 b8 fb ff ff ff 5b c3 0f 1f 00 55 48 8b 6f 78 48 c7 c7 d0 24 13 b7 <48> 8b 95 78 02 00 00 48 8b 85 80 02 00 00 48 89 42 08 48 89 10 8b RSP: 0018:b7b600a3bb10 EFLAGS: 00010286 RAX: b6414650 RBX: RCX: 0282 RDX: 8a255a8d6598 RSI: 0282 RDI: b71324d0 RBP: R08: 0001 R09: 0282 R10: 0001 R11: b71646a0 R12: 8a254f51a100 R13: b7145e60 R14: 8a255a811790 R15: 0002 FS: () GS:8a284dc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0278 CR3: 00012dd6a003 CR4: 001706f0 Call Trace: device_release+0x2f/0x80 kobject_put+0x63/0xc0 cp210x_disconnect+0x1b/0x30 [cp210x] usb_serial_disconnect+0xe1/0x130 usb_unbind_interface+0x65/0x1c0 __device_release_driver+0x144/0x1f0 device_release_driver+0x1f/0x30 bus_remove_device+0xcd/0x110 device_del+0x185/0x450 ? kobject_put+0x70/0xc0 usb_disable_device+0xac/0x150 usb_disconnect.cold+0x60/0x1a4 usb_disconnect.cold+0x29/0x1a4 usb_disconnect.cold+0x29/0x1a4 hub_event+0x5cf/0x1230 ? __switch_to_asm+0x42/0x70 process_one_work+0x1ea/0x340 worker_thread+0x48/0x3c0 ? rescuer_thread+0x380/0x380 kthread+0x111/0x130 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Modules linked in: rfcomm cmac hid_logitech_hidpp bnep btusb btrtl btbcm btintel bluetooth ecdh_generic ecc hid_logitech_dj cp210x joydev uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_usb_audio videobuf2_common snd_usbmidi_lib videodev snd_rawmidi mc iptable_filter bpfilter sunrpc snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio x86_pkg_temp_thermal intel_powerclamp snd_hda_intel coretemp snd_intel_dspcfg snd_hda_codec kvm_intel snd_hda_core snd_hwdep snd_seq kvm snd_seq_device irqbypass at24 snd_pcm rapl hp_wmi snd_timer sparse_keymap iTCO_wdt wmi_bmof rfkill iTCO_vendor_support snd intel_cstate pcspkr i2c_i801 intel_uncore i2c_smbus soundcore lpc_ich wmi drm zram ip_tables x_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel r8169 e1000e fuse CR2: 0278 ---[ end trace a5b6fc6316be72a4 ]--- RIP: 0010:gpiodevice_release+0xc/0x70 Code: c0 0f b6 c0 5b c3 85 c0 5b 0f 95 c0 0f b6 c0 c3 0f 0b eb b1 b8 fb ff ff ff 5b c3 0f 1f 00 55 48 8b 6f 78 48 c7 c7 d0 24 13 b7 <48> 8b 95 78 02 00 00 48 8b 85 80 02 00 00 48 89 42 08 48 89 10 8b RSP: 0018:b7b600a3bb10 EFLAGS: 00010286 RAX: b6414650 RBX: RCX: 0282 RDX: 8a255a8d6598 RSI: 0282 RDI: b71324d0 RBP: R08: 0001 R09: 0282 R10: 0001 R11: b71646a0 R12: 8a254f51a100 R13: b7145e60 R14: 8a255a811790 R15: 0002 FS: () GS:8a284dc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0278 CR3: 00012dd6a003 CR4: 001706f0 Fault is 100% reproducible. Login/logout no longer works. Hard power cycle required. No problems with Kernel 5.11.x
[PATCH] soc: qcom: Fix typos in the file qmi_encdec.c
Rudimentory spelling fixes throughout the file. s/descibing/describing/ s/inforation/information/ Signed-off-by: Bhaskar Chowdhury --- drivers/soc/qcom/qmi_encdec.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/soc/qcom/qmi_encdec.c b/drivers/soc/qcom/qmi_encdec.c index 3aaab71d1b2c..328cc8237191 100644 --- a/drivers/soc/qcom/qmi_encdec.c +++ b/drivers/soc/qcom/qmi_encdec.c @@ -451,11 +451,11 @@ static int qmi_decode_basic_elem(void *buf_dst, const void *buf_src, /** * qmi_decode_struct_elem() - Decodes elements of struct data type - * @ei_array: Struct info array descibing the struct element. + * @ei_array: Struct info array describing the struct element. * @buf_dst: Buffer to store the decoded element. * @buf_src: Buffer containing the elements in QMI wire format. * @elem_len: Number of elements to be decoded. - * @tlv_len: Total size of the encoded inforation corresponding to + * @tlv_len: Total size of the encoded information corresponding to * this struct element. * @dec_level: Depth of the nested structure from the main structure. * @@ -499,10 +499,10 @@ static int qmi_decode_struct_elem(struct qmi_elem_info *ei_array, /** * qmi_decode_string_elem() - Decodes elements of string data type - * @ei_array: Struct info array descibing the string element. + * @ei_array: Struct info array describing the string element. * @buf_dst: Buffer to store the decoded element. * @buf_src: Buffer containing the elements in QMI wire format. - * @tlv_len: Total size of the encoded inforation corresponding to + * @tlv_len: Total size of the encoded information corresponding to * this string element. * @dec_level: Depth of the string element from the main structure. * -- 2.26.2
Re: [PATCH] MIPS: boot/compressed: Copy DTB to aligned address
On Sat, Mar 6, 2021 at 1:45 AM Thomas Bogendoerfer wrote: > > On Wed, Mar 03, 2021 at 02:37:55PM -0600, Rob Herring wrote: > > On Wed, Mar 3, 2021 at 1:33 PM Paul Cercueil wrote: > > > > > > Since 5.12-rc1, the Device Tree blob must now be properly aligned. > > > > I had checked the other built-in cases as microblaze broke too, but > > missed some of the many ways MIPS can have a dtb. Appended and > > built-in DTBs were supposed to be temporary. :( > > and a fdt can also be provided by firmware. And according to spec > there is no aligmnet requirement. So this whole change will break > then. What was the reason for the whole churn ? There was a long discussion on devicetree-compiler list a few months ago. In summary, a while back libfdt switched to accessors from raw pointer accesses to avoid any possible unaligned accesses (is MIPS always okay with unaligned accesses?). This was determined to be a performance regression and an overkill as the DT structure itself should always be naturally aligned if the dtb is 64-bit aligned. I think 32-bit aligned has some possible misaligned accesses. As part of this, a dtb alignment check was added. So worst case, we could disable that if need be. Rob
Re: [PATCH 00/11] pragma once: treewide conversion
On Sat, Mar 6, 2021 at 5:07 AM Miguel Ojeda
wrote:
>
> Concerning #pragma once: I actually would like to have a standard
> #once directive if what is a "seen file" could be defined a bit more
> precisely.
I think it would be ok if you had something like
#pragma once IDTOKEN
which would basically act *exactly* as a "#ifndef IDTOKEN/#define
IDTOKEN" with that final #endif at the end of the file.
But even then it should have the rule that it must be the very first
thing in the file (ignoring whitespace and pure comments).
Then it would literally be just a cleaner and simpler version of the
guarding logic, with none of the semantic confusion that #pragma once
now has.
Because I cannot see any other way to define what "seen file" really means.
There's no sane "implied IDTOKEN" that I can see. It can't really be
the pathname, because pathnames are actually really hard to turn into
canonical form in user space thanks to things like symlinks. It can't
be st_ino/st_dev stat information, because the C preprocessor isn't a
"POSIX only" thing.
It could be a "Ok, #pragma once only works if you don't have multiple
ways to reach the same file, and you never have ambiguous include
paths". But that's actually not all that unusual in real projects: you
often have fairly complex include paths, you have C files that include
the header in the same directory with just "filename.h", but it
_could_ get included indirectly from _another_ header that gave a
pathname relative to the project root, etc etc.
This is not unrelated to another complete morass of horrible problems:
precompiled header files. That feature had exactly the same reason for
it as "#pragma once" - slow build speeds due to the cost of parsing
complex header file hierarchies.
And I guarantee that multiple compiler teams spent hundreds of
person-years of effort on trying to make it work. And several
compilers do support the notion. And they ALL have big warnings about
when you should enable it, and when you shouldn't, and what things
don't work if you use them, and about how it can cause really really
subtle problems.
Because it turns out that precompiled header files are a major pain
and a major mistake. Some projects still use them, because they can be
such a huge timesaver (again: particularly C++ projects that just have
a "include everything" approach to headers because trying to separate
things out is too hard). But they all come with huge warnings about
how they break the actual real semantics of a compiler, and if you do
_anything_ to change the build ("hey, I'd like to use a different
compiler option"), things may or may not work.
Linus
Re: [PATCH 1/3] dt-bindings: phy: convert Broadcom NS USB 2.0 to the json-schema
On Fri, 26 Feb 2021 12:44:59 +0100, Rafał Miłecki wrote: > From: Rafał Miłecki > > Minor example fixes: > 1. Include bcm-nsp.h > 2. Add address to the node name > > Signed-off-by: Rafał Miłecki > --- > This has been verified using dt_binding_check > --- > .../bindings/phy/bcm-ns-usb2-phy.txt | 21 --- > .../bindings/phy/brcm,ns-usb2-phy.yaml| 55 +++ > 2 files changed, 55 insertions(+), 21 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt > create mode 100644 > Documentation/devicetree/bindings/phy/brcm,ns-usb2-phy.yaml > Reviewed-by: Rob Herring
[PATCH] net: ethernet: chelsio: inline_crypto: Mundane typos fixed throughout the file chcr_ktls.c
Mundane typos fixes throughout the file.
s/establised/established/
s/availbale/available/
s/vaues/values/
s/Incase/In case/
Signed-off-by: Bhaskar Chowdhury
---
.../ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c| 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
index 1b7e8c91b541..6a9c6aa73eb4 100644
--- a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
+++ b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
@@ -677,7 +677,7 @@ static int chcr_ktls_cpl_act_open_rpl(struct adapter *adap,
if (tx_info->pending_close) {
spin_unlock(_info->lock);
if (!status) {
- /* it's a late success, tcb status is establised,
+ /* it's a late success, tcb status is established,
* mark it close.
*/
chcr_ktls_mark_tcb_close(tx_info);
@@ -935,7 +935,7 @@ chcr_ktls_get_tx_flits(u32 nr_frags, unsigned int
key_ctx_len)
}
/*
- * chcr_ktls_check_tcp_options: To check if there is any TCP option availbale
+ * chcr_ktls_check_tcp_options: To check if there is any TCP option available
* other than timestamp.
* @skb - skb contains partial record..
* return: 1 / 0
@@ -1120,7 +1120,7 @@ static int chcr_ktls_xmit_wr_complete(struct sk_buff *skb,
}
if (unlikely(credits < ETHTXQ_STOP_THRES)) {
- /* Credits are below the threshold vaues, stop the queue after
+ /* Credits are below the threshold values, stop the queue after
* injecting the Work Request for this packet.
*/
chcr_eth_txq_stop(q);
@@ -2011,7 +2011,7 @@ static int chcr_ktls_xmit(struct sk_buff *skb, struct
net_device *dev)
/* TCP segments can be in received either complete or partial.
* chcr_end_part_handler will handle cases if complete record or end
-* part of the record is received. Incase of partial end part of record,
+* part of the record is received. In case of partial end part of
record,
* we will send the complete record again.
*/
--
2.26.2
Re: [PATCH 2/2] iio: qcom-spmi-vadc: Add definitions for USB DP/DM VADCs
On Thu, 25 Feb 2021 22:36:05 +0100, Konrad Dybcio wrote: > From: AngeloGioacchino Del Regno > > Some SoCs do have a USB DP/DM ADC at 0x43, 0x44. > > Signed-off-by: AngeloGioacchino Del Regno > > Signed-off-by: Konrad Dybcio > --- > include/dt-bindings/iio/qcom,spmi-vadc.h | 3 +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 1/2] pinctrl: pmic-mpp: Add missing dt-bindings mpp function defs
On Thu, 25 Feb 2021 22:36:04 +0100, Konrad Dybcio wrote:
> From: AngeloGioacchino Del Regno
>
> The pinctrl-spmi-mpp driver supports setting more mpp functions
> than the ones defined in the dt-bindings header, specifically,
> digital, analog and sink.
>
> To follow the current way of specifying the function config
> in Device-Tree, add the missing three definitions in the
> appropriate dt-bindings header as:
> GPIO_MPP_FUNC_{DIGITAL,ANALOG,SINK}.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> Signed-off-by: Konrad Dybcio
> ---
> include/dt-bindings/pinctrl/qcom,pmic-mpp.h | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring
Re: [PATCH 1/2] dt-bindings: clock: qcom,gcc: Document MSM8976 compatibles
On Thu, 25 Feb 2021 21:18:42 +0100, Konrad Dybcio wrote: > Document the newly added compatibles for 8976 GCC. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
QQQQQQQQQPM
We have a Job vacancy for you in your country, the Job cannot stop your business or the work your doing already. Send your CV/ Resume or Name, Phone No. , address to our Email: mec...@xcontrol.it Thanks Jeff.
Re: [PATCH 3/4] dt-bindings: clock: Add BCM63268 timer binding
On Thu, 25 Feb 2021 20:42:00 +0100, Álvaro Fernández Rojas wrote: > Document the Broadcom BCM63268 Clock and Reset controller. > > Signed-off-by: Álvaro Fernández Rojas > --- > .../clock/brcm,bcm63268-timer-clocks.yaml | 40 +++ > 1 file changed, 40 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml > Reviewed-by: Rob Herring
Re: [PATCH 2/4] mips: bmips: add BCM63268 timer reset definitions
On Thu, Feb 25, 2021 at 08:41:59PM +0100, Álvaro Fernández Rojas wrote: > Add missing timer reset definitions for BCM63268. > > Signed-off-by: Álvaro Fernández Rojas > --- > include/dt-bindings/reset/bcm63268-reset.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/dt-bindings/reset/bcm63268-reset.h > b/include/dt-bindings/reset/bcm63268-reset.h > index 6a6403a4c2d5..d87a7882782a 100644 > --- a/include/dt-bindings/reset/bcm63268-reset.h > +++ b/include/dt-bindings/reset/bcm63268-reset.h > @@ -23,4 +23,8 @@ > #define BCM63268_RST_PCIE_HARD 17 > #define BCM63268_RST_GPHY18 > > +#define BCM63268_TRST_SW 29 > +#define BCM63268_TRST_HW 30 > +#define BCM63268_TRST_POR31 Numbering should be local to the provider, so shouldn't this be 0-2? Unless these numbers correspond to something in the h/w (bit positions for example). > + > #endif /* __DT_BINDINGS_RESET_BCM63268_H */ > -- > 2.20.1 >
[PATCH] fb_defio: Use __set_page_dirty_no_writeback
The home-grown set_page_dirty() implementation had the wrong return value.
Use __set_page_dirty_no_writeback() like other in-memory implementations.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/video/fbdev/core/fb_defio.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index a591d291b231..35021265e294 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -151,15 +151,8 @@ static const struct vm_operations_struct
fb_deferred_io_vm_ops = {
.page_mkwrite = fb_deferred_io_mkwrite,
};
-static int fb_deferred_io_set_page_dirty(struct page *page)
-{
- if (!PageDirty(page))
- SetPageDirty(page);
- return 0;
-}
-
static const struct address_space_operations fb_deferred_io_aops = {
- .set_page_dirty = fb_deferred_io_set_page_dirty,
+ .set_page_dirty = __set_page_dirty_no_writeback,
};
int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
--
2.30.0
Re: [PATCH 1/4] mips: bmips: add BCM63268 timer clock definitions
On Thu, 25 Feb 2021 20:41:58 +0100, Álvaro Fernández Rojas wrote: > Add missing timer clock definitions for BCM63268. > > Signed-off-by: Álvaro Fernández Rojas > --- > include/dt-bindings/clock/bcm63268-clock.h | 13 + > 1 file changed, 13 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v4 15/19] dts: bindings: Document device tree bindings for ETE
On Thu, Feb 25, 2021 at 07:35:39PM +, Suzuki K Poulose wrote:
> Document the device tree bindings for Embedded Trace Extensions.
> ETE can be connected to legacy coresight components and thus
> could optionally contain a connection graph as described by
> the CoreSight bindings.
>
> Cc: devicet...@vger.kernel.org
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Cc: Rob Herring
> Signed-off-by: Suzuki K Poulose
> ---
> Changes:
> - Fix out-ports defintion
> ---
> .../devicetree/bindings/arm/ete.yaml | 71 +++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/ete.yaml
> b/Documentation/devicetree/bindings/arm/ete.yaml
> new file mode 100644
> index ..35a42d92bf97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/ete.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +# Copyright 2021, Arm Ltd
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/arm/ete.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: ARM Embedded Trace Extensions
> +
> +maintainers:
> + - Suzuki K Poulose
> + - Mathieu Poirier
> +
> +description: |
> + Arm Embedded Trace Extension(ETE) is a per CPU trace component that
> + allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
> + architecture and has extended support for future architecture changes.
> + The trace generated by the ETE could be stored via legacy CoreSight
> + components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
> + Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
> + legacy CoreSight components, a node must be listed per instance, along
> + with any optional connection graph as per the coresight bindings.
> + See bindings/arm/coresight.txt.
> +
> +properties:
> + $nodename:
> +pattern: "^ete([0-9a-f]+)$"
> + compatible:
> +items:
> + - const: arm,embedded-trace-extension
> +
> + cpu:
> +description: |
> + Handle to the cpu this ETE is bound to.
> +$ref: /schemas/types.yaml#/definitions/phandle
> +
> + out-ports:
> +description: |
> + Output connections from the ETE to legacy CoreSight trace bus.
> +$ref: /schemas/graph.yaml#/properties/port
s/port/ports/
And then you need:
properties:
port:
description: what this port is
$ref: /schemas/graph.yaml#/properties/port
> +
> +required:
> + - compatible
> + - cpu
> +
> +additionalProperties: false
> +
> +examples:
> +
> +# An ETE node without legacy CoreSight connections
> + - |
> +ete0 {
> + compatible = "arm,embedded-trace-extension";
> + cpu = <_0>;
> +};
> +# An ETE node with legacy CoreSight connections
> + - |
> + ete1 {
> + compatible = "arm,embedded-trace-extension";
> + cpu = <_1>;
> +
> + out-ports {/* legacy coresight connection */
> + port {
> + ete1_out_port: endpoint {
> +remote-endpoint = <_in_port0>;
> + };
> + };
> + };
> + };
> +
> +...
> --
> 2.24.1
>
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:56 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 9:49 PM Sedat Dilek wrote:
> >
> > On Sat, Mar 6, 2021 at 9:38 PM Sedat Dilek wrote:
> > >
> > > On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
> > > >
> > > > On Sat, Mar 6, 2021 at 5:58 PM Alan Stern
> > > > wrote:
> > > > >
> > > > > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > > > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> > > > >
> > > > > Is the kernel the only thing that is different? The rest of the
> > > > > operating system and environment is exactly the same?
> > > > >
> > > > > > But I see there is already a quirk enabled and matches my ASmedia
> > > > > > USB
> > > > > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > > > > >
> > > > > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > > > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > > > > 174c pid 55aa: 40
> > > > >
> > > > > Yes, this is because that type of device already has a quirk entry
> > > > > built
> > > > > into the kernel. You can find it by searching for "174c" in the
> > > > > kernel
> > > > > source file drivers/usb/storage/unusual_devs.h.
> > > > >
> > > > > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > > > > quirks" and your patience.
> > > > >
> > > > > You can try building a 5.11 kernel with the patch below. I don't know
> > > > > whether it will show anything in the dmesg log when one of these
> > > > > resets
> > > > > occurs, but it might.
> > > > >
> > > > > If that doesn't work out, another possibility is to use git bisect to
> > > > > find the commit between 5.10 and 5.11 which caused the problem to
> > > > > start.
> > > > >
> > > > > Alan Stern
> > > > >
> > > > >
> > > > > --- usb-devel.orig/block/scsi_ioctl.c
> > > > > +++ usb-devel/block/scsi_ioctl.c
> > > > > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > > > > hdr->host_status = host_byte(req->result);
> > > > > hdr->driver_status = driver_byte(req->result);
> > > > > hdr->info = 0;
> > > > > - if (hdr->masked_status || hdr->host_status ||
> > > > > hdr->driver_status)
> > > > > + if (hdr->masked_status || hdr->host_status ||
> > > > > hdr->driver_status) {
> > > > > hdr->info |= SG_INFO_CHECK;
> > > > > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog
> > > > > %s\n",
> > > > > + req->cmd[0], current->comm);
> > > > > + }
> > > > > hdr->resid = req->resid_len;
> > > > > hdr->sb_len_wr = 0;
> > > > >
> > > > >
> > > >
> > > > Thanks for the diff, Alan.
> > > >
> > > > With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
> > > >
> > > > root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> > > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:15 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:16 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
>
Re: [PATCH v3 1/3] dt-bindings: mtd: Convert Qcom NANDc binding to YAML
On Thu, 25 Feb 2021 19:38:40 +0530, Manivannan Sadhasivam wrote: > Convert Qcom NANDc devicetree binding to YAML. > > Signed-off-by: Manivannan Sadhasivam > --- > .../devicetree/bindings/mtd/qcom,nandc.yaml | 196 ++ > .../devicetree/bindings/mtd/qcom_nandc.txt| 142 - > 2 files changed, 196 insertions(+), 142 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mtd/qcom,nandc.yaml > delete mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt > Reviewed-by: Rob Herring
Re: [PATCH 1/4] dt-bindings: mfd: Add bindings for Ampere Altra SMPro drivers
On Thu, Feb 25, 2021 at 05:18:51PM +0700, Quan Nguyen wrote:
> Adds device tree bindings for SMPro drivers found on the Mt.Jade hardware
> reference platform with Ampere's Altra Processor family.
>
> Signed-off-by: Quan Nguyen
> ---
> .../bindings/hwmon/ampere,ac01-hwmon.yaml | 27 ++
> .../bindings/mfd/ampere,ac01-smpro.yaml | 82 +++
> 2 files changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml
> create mode 100644
> Documentation/devicetree/bindings/mfd/ampere,ac01-smpro.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml
> b/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml
> new file mode 100644
> index ..d13862ba646b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml
> @@ -0,0 +1,27 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/ampere,ac01-hwmon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Hardware monitoring driver for the Ampere Altra SMPro
> +
> +maintainers:
> + - Quan Nguyen
> +
> +description: |
> + This module is part of the Ampere Altra SMPro multi-function device. For
> more
> + details see ../mfd/ampere,ac01-smpro.yaml.
> +
> +properties:
> + compatible:
> +enum:
> + - ampere,ac01-hwmon
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> diff --git a/Documentation/devicetree/bindings/mfd/ampere,ac01-smpro.yaml
> b/Documentation/devicetree/bindings/mfd/ampere,ac01-smpro.yaml
> new file mode 100644
> index ..06b0239413ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ampere,ac01-smpro.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ampere,ac01-smpro.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ampere Altra SMPro firmware driver
> +
> +maintainers:
> + - Quan Nguyen
> +
> +description: |
> + Ampere Altra SMPro firmware may contain different blocks like hardware
> + monitoring, error monitoring and other miscellaneous features.
> +
> +properties:
> + compatible:
> +const: ampere,ac01-smpro
> +
> + reg:
> +description:
> + I2C device address.
> +maxItems: 1
> +
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> +patternProperties:
> + "^hwmon(@[0-9a-f]+)?$":
> +$ref: ../hwmon/ampere,ac01-hwmon.yaml
> +
> + "^misc(@[0-9a-f]+)?$":
> +type: object
> +description: Ampere Altra SMPro Misc driver
> +properties:
> + compatible:
> +const: "ampere,ac01-misc"
> +
> + "^errmon(@[0-9a-f]+)?$":
> +type: object
> +description: Ampere Altra SMPro Error Monitor driver
> +properties:
> + compatible:
> +const: "ampere,ac01-errmon"
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +smpro@4f {
> +compatible = "ampere,ac01-smpro";
> +reg = <0x4f>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +hwmon {
> +compatible = "ampere,ac01-hwmon";
> +};
> +
> +misc {
> +compatible = "ampere,ac01-misc";
> +};
> +
> +errmon {
> +compatible = "ampere,ac01-errmon";
> +};
No of these have any properties or resources, why do you need them? DT
is not the only way to instantiate drivers...
Rob
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:49 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 9:38 PM Sedat Dilek wrote:
> >
> > On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
> > >
> > > On Sat, Mar 6, 2021 at 5:58 PM Alan Stern
> > > wrote:
> > > >
> > > > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> > > >
> > > > Is the kernel the only thing that is different? The rest of the
> > > > operating system and environment is exactly the same?
> > > >
> > > > > But I see there is already a quirk enabled and matches my ASmedia USB
> > > > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > > > >
> > > > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > > > 174c pid 55aa: 40
> > > >
> > > > Yes, this is because that type of device already has a quirk entry built
> > > > into the kernel. You can find it by searching for "174c" in the kernel
> > > > source file drivers/usb/storage/unusual_devs.h.
> > > >
> > > > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > > > quirks" and your patience.
> > > >
> > > > You can try building a 5.11 kernel with the patch below. I don't know
> > > > whether it will show anything in the dmesg log when one of these resets
> > > > occurs, but it might.
> > > >
> > > > If that doesn't work out, another possibility is to use git bisect to
> > > > find the commit between 5.10 and 5.11 which caused the problem to start.
> > > >
> > > > Alan Stern
> > > >
> > > >
> > > > --- usb-devel.orig/block/scsi_ioctl.c
> > > > +++ usb-devel/block/scsi_ioctl.c
> > > > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > > > hdr->host_status = host_byte(req->result);
> > > > hdr->driver_status = driver_byte(req->result);
> > > > hdr->info = 0;
> > > > - if (hdr->masked_status || hdr->host_status ||
> > > > hdr->driver_status)
> > > > + if (hdr->masked_status || hdr->host_status ||
> > > > hdr->driver_status) {
> > > > hdr->info |= SG_INFO_CHECK;
> > > > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog
> > > > %s\n",
> > > > + req->cmd[0], current->comm);
> > > > + }
> > > > hdr->resid = req->resid_len;
> > > > hdr->sb_len_wr = 0;
> > > >
> > > >
> > >
> > > Thanks for the diff, Alan.
> > >
> > > With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
> > >
> > > root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:15 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:16 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > > [Sat
Re: [PATCH] powerpc: iommu: fix build when neither PCI or IBMVIO is set
On March 2, 2021 3:08:43 AM PST, Michael Ellerman wrote:
>Randy Dunlap writes:
>> When neither CONFIG_PCI nor CONFIG_IBMVIO is enabled:
>>
>> ../arch/powerpc/kernel/iommu.c:178:30: error:
>'fail_iommu_bus_notifier' defined but not used
>[-Werror=unused-variable]
>> 178 | static struct notifier_block fail_iommu_bus_notifier = {
>>
>> If only that struct is bounded by 2 #if defined() phrases (PCI &&
>IBMVIO):
>>
>> ../arch/powerpc/kernel/iommu.c:162:12: error: 'fail_iommu_bus_notify'
>defined but not used [-Werror=unused-function]
>> 162 | static int fail_iommu_bus_notify(struct notifier_block *nb,
>>
>> If that function is also guarded by 2 #if defined() phrases:
>>
>> In file included from ../include/linux/dma-mapping.h:7,
>> from ../arch/powerpc/kernel/iommu.c:19:
>> ../include/linux/device.h:131:26: error: 'dev_attr_fail_iommu'
>defined but not used [-Werror=unused-variable]
>> 131 | struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
>> ../arch/powerpc/kernel/iommu.c:160:8: note: in expansion of macro
>'DEVICE_ATTR_RW'
>> 160 | static DEVICE_ATTR_RW(fail_iommu);
>>
>> and the snowball continues to grow.
>> Next I got this one:
>>
>> ../arch/powerpc/kernel/iommu.c: In function 'iommu_range_alloc':
>> ../arch/powerpc/kernel/iommu.c:234:6: error: implicit declaration of
>function 'should_fail_iommu'; did you mean 'should_failslab'?
>[-Werror=implicit-function-declaration]
>> 234 | if (should_fail_iommu(dev))
>>
>> and
>>
>> ../arch/powerpc/kernel/iommu.c: In function 'should_fail_iommu':
>> ../arch/powerpc/kernel/iommu.c:122:50: error: 'fail_iommu' undeclared
>(first use in this function)
>> 122 | return dev->archdata.fail_iommu && should_fail(_iommu,
>1);
>>
>> So combine CONFIG_FAIL_IOMMU && (CONFIG_PCI || CONFIG_IBMVIO)
>> to decide on building some of this code/data.
>
>Couldn't we just make FAIL_IOMMU depend on PCI || IBMVIO?
>
>cheers
Yes, I thought of that about 5 seconds after hitting Send. But I can't do it
just now -- am away from computer.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH 6/9] dt-bindings: soc: qcom: aoss: Add SC7280 compatible
On Thu, 25 Feb 2021 15:00:22 +0530, Sai Prakash Ranjan wrote: > Add SC7280 AOSS QMP compatible to the list of possible bindings. > > Signed-off-by: Sai Prakash Ranjan > --- > Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:38 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
> >
> > On Sat, Mar 6, 2021 at 5:58 PM Alan Stern wrote:
> > >
> > > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> > >
> > > Is the kernel the only thing that is different? The rest of the
> > > operating system and environment is exactly the same?
> > >
> > > > But I see there is already a quirk enabled and matches my ASmedia USB
> > > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > > >
> > > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > > 174c pid 55aa: 40
> > >
> > > Yes, this is because that type of device already has a quirk entry built
> > > into the kernel. You can find it by searching for "174c" in the kernel
> > > source file drivers/usb/storage/unusual_devs.h.
> > >
> > > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > > quirks" and your patience.
> > >
> > > You can try building a 5.11 kernel with the patch below. I don't know
> > > whether it will show anything in the dmesg log when one of these resets
> > > occurs, but it might.
> > >
> > > If that doesn't work out, another possibility is to use git bisect to
> > > find the commit between 5.10 and 5.11 which caused the problem to start.
> > >
> > > Alan Stern
> > >
> > >
> > > --- usb-devel.orig/block/scsi_ioctl.c
> > > +++ usb-devel/block/scsi_ioctl.c
> > > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > > hdr->host_status = host_byte(req->result);
> > > hdr->driver_status = driver_byte(req->result);
> > > hdr->info = 0;
> > > - if (hdr->masked_status || hdr->host_status || hdr->driver_status)
> > > + if (hdr->masked_status || hdr->host_status || hdr->driver_status)
> > > {
> > > hdr->info |= SG_INFO_CHECK;
> > > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog %s\n",
> > > + req->cmd[0], current->comm);
> > > + }
> > > hdr->resid = req->resid_len;
> > > hdr->sb_len_wr = 0;
> > >
> > >
> >
> > Thanks for the diff, Alan.
> >
> > With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
> >
> > root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:15 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:16 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> > [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog
Re: [PATCH 1/9] dt-bindings: arm: msm: Add LLCC for SC7280
On Thu, 25 Feb 2021 15:00:17 +0530, Sai Prakash Ranjan wrote: > Add LLCC compatible for SC7280 SoC. > > Signed-off-by: Sai Prakash Ranjan > --- > Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2,1/3] dt-bindings: media: mtk-vcodec: Separating mtk vcodec encoder node
On Thu, Feb 25, 2021 at 03:36:01PM +0800, Irui Wang wrote:
> Updates binding document since the avc and vp8 hardware encoder in
> MT8173 are now separated. Separate "mediatek,mt8173-vcodec-enc" to
> "mediatek,mt8173-vcodec-enc-vp8" and "mediatek,mt8173-vcodec-enc".
This is not a compatible change. Please explain that here and why that's
okay (if it is).
>
> This is a preparing patch for smi cleaning up "mediatek,larb".
>
> Acked-by: Tiffany Lin
> Signed-off-by: Hsin-Yi Wang
> Signed-off-by: Maoguang Meng
> Signed-off-by: Irui Wang
> ---
> Change since v1:
> - rename compatible and device node
> ---
> .../bindings/media/mediatek-vcodec.txt| 55 ++-
> 1 file changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> index 8217424fd4bd..03209cbd7540 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> @@ -4,7 +4,9 @@ Mediatek Video Codec is the video codec hw present in
> Mediatek SoCs which
> supports high resolution encoding and decoding functionalities.
>
> Required properties:
> -- compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
> +- compatible : must be one of the following string:
> + "mediatek,mt8173-vcodec-enc-vp8" for mt8173 vp8 encoder.
> + "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder.
>"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
>"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
> - reg : Physical base address of the video codec registers and length of
> @@ -13,10 +15,10 @@ Required properties:
> - mediatek,larb : must contain the local arbiters in the current Socs.
> - clocks : list of clock specifiers, corresponding to entries in
>the clock-names property.
> -- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
> - "venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
> - "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
> - "venc_lt_sel", "vdec_bus_clk_src".
> +- clock-names:
> + encoder must contain "venc_sel";
What happened to the other clocks?
Seems like you are dropping what are parent clocks? That seems unrelated
to the VP8 split? If so, that's a separate change.
> + decoder must contain "vcodecpll", "univpll_d2", "clk_cci400_sel",
> + "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel", "vdec_bus_clk_src".
> - iommus : should point to the respective IOMMU block with master port as
>argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>for details.
> @@ -80,14 +82,10 @@ vcodec_dec: vcodec@1600 {
> assigned-clock-rates = <0>, <0>, <0>, <148200>, <8>;
>};
>
> - vcodec_enc: vcodec@18002000 {
> +vcodec_enc_avc: vcodec@18002000 {
> compatible = "mediatek,mt8173-vcodec-enc";
> -reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
> - <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
> -interrupts = ,
> - ;
> -mediatek,larb = <>,
> - <>;
> +reg = <0 0x18002000 0 0x1000>;
> +interrupts = ;
> iommus = < M4U_PORT_VENC_RCPU>,
> < M4U_PORT_VENC_REC>,
> < M4U_PORT_VENC_BSDMA>,
> @@ -98,8 +96,20 @@ vcodec_dec: vcodec@1600 {
> < M4U_PORT_VENC_REF_LUMA>,
> < M4U_PORT_VENC_REF_CHROMA>,
> < M4U_PORT_VENC_NBM_RDMA>,
> - < M4U_PORT_VENC_NBM_WDMA>,
> - < M4U_PORT_VENC_RCPU_SET2>,
> + < M4U_PORT_VENC_NBM_WDMA>;
> +mediatek,larb = <>;
> +mediatek,vpu = <>;
> +clocks = < CLK_TOP_VENC_SEL>;
> +clock-names = "venc_sel";
> +assigned-clocks = < CLK_TOP_VENC_SEL>;
> +assigned-clock-parents = < CLK_TOP_VCODECPLL>;
> + };
> +
> +vcodec_enc_vp8: vcodec@19002000 {
> +compatible = "mediatek,mt8173-vcodec-enc-vp8";
> +reg = <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
> +interrupts = ;
> +iommus = < M4U_PORT_VENC_RCPU_SET2>,
> < M4U_PORT_VENC_REC_FRM_SET2>,
> < M4U_PORT_VENC_BSDMA_SET2>,
> < M4U_PORT_VENC_SV_COMA_SET2>,
> @@ -108,17 +118,10 @@ vcodec_dec: vcodec@1600 {
> < M4U_PORT_VENC_CUR_CHROMA_SET2>,
> < M4U_PORT_VENC_REF_LUMA_SET2>,
> < M4U_PORT_VENC_REC_CHROMA_SET2>;
> +mediatek,larb = <>;
> mediatek,vpu = <>;
> -clocks = < CLK_TOP_VENCPLL_D2>,
> - < CLK_TOP_VENC_SEL>,
> - < CLK_TOP_UNIVPLL1_D2>,
> - < CLK_TOP_VENC_LT_SEL>;
> -clock-names = "venc_sel_src",
> - "venc_sel",
> - "venc_lt_sel_src",
> - "venc_lt_sel";
> -assigned-clocks = < CLK_TOP_VENC_SEL>,
> - < CLK_TOP_VENC_LT_SEL>;
> -assigned-clock-parents = < CLK_TOP_VENCPLL_D2>,
> - < CLK_TOP_UNIVPLL1_D2>;
> +
Re: [PATCH] leds: trigger: fix potential deadlock with libata
Hello *,
On 02.11.2020 11:41:52, Andrea Righi wrote:
> We have the following potential deadlock condition:
>
>
> WARNING: possible irq lock inversion dependency detected
> 5.10.0-rc2+ #25 Not tainted
>
> swapper/3/0 just changed the state of lock:
> 8880063bd618 (>lock){-...}-{2:2}, at:
> ata_bmdma_interrupt+0x27/0x200
> but this lock took another, HARDIRQ-READ-unsafe lock in the past:
> (>leddev_list_lock){.+.?}-{2:2}
>
> and interrupts could create inverse lock ordering between them.
[...]
> ---
> drivers/leds/led-triggers.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> index 91da90cfb11d..16d1a93a10a8 100644
> --- a/drivers/leds/led-triggers.c
> +++ b/drivers/leds/led-triggers.c
> @@ -378,14 +378,15 @@ void led_trigger_event(struct led_trigger *trig,
> enum led_brightness brightness)
> {
> struct led_classdev *led_cdev;
> + unsigned long flags;
>
> if (!trig)
> return;
>
> - read_lock(>leddev_list_lock);
> + read_lock_irqsave(>leddev_list_lock, flags);
> list_for_each_entry(led_cdev, >led_cdevs, trig_list)
> led_set_brightness(led_cdev, brightness);
> - read_unlock(>leddev_list_lock);
> + read_unlock_irqrestore(>leddev_list_lock, flags);
> }
> EXPORT_SYMBOL_GPL(led_trigger_event);
meanwhile this patch hit v5.10.x stable and caused a performance
degradation on our use case:
It's an embedded ARM system, 4x Cortex A53, with an SPI attached CAN
controller. CAN stands for Controller Area Network and here used to
connect to some automotive equipment. Over CAN an ISOTP (a CAN-specific
Transport Protocol) transfer is running. With this patch, we see CAN
frames delayed for ~6ms, the usual gap between CAN frames is 240µs.
Reverting this patch, restores the old performance.
What is the best way to solve this dilemma? Identify the critical path
in our use case? Is there a way we can get around the irqsave in
led_trigger_event()?
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
