summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-12-08docs/LoongArch: Add booting descriptionYanteng Si2-0/+43
1, Describe the information passed from BootLoader to kernel. 2, Describe the meaning and values of the kernel image header field. Suggested-by: Xiaotian Wu <wuxiaotian@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-12-08LoongArch: mm: Fix huge page entry update for virtual machineHuacai Chen1-14/+16
In virtual machine (guest mode), the tlbwr instruction can not write the last entry of MTLB, so we need to make it non-present by invtlb and then write it by tlbfill. This also simplify the whole logic. Signed-off-by: Rui Wang <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-12-08LoongArch: Export symbol for function smp_send_reschedule()Bibo Mao2-10/+11
Function smp_send_reschedule() is standard kernel API, which is defined in header file include/linux/smp.h. However, on LoongArch it is defined as an inline function, this is confusing and kernel modules can not use this function. Now we define smp_send_reschedule() as a general function, and add a EXPORT_SYMBOL_GPL on this function, so that kernel modules can use it. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2022-12-08arm64: dts: apple: t6002: Fix GPU power domainsAsahi Lina1-0/+5
On t6002 (M1 Ultra), each die contains a self-contained GPU block. However, only the coprocessor and global management circuitry of the first die are used. This is what is represented by the "gpu" PS (the one in die1 is disabled). Nonetheless, this shared component drives the processing blocks in both dies, and therefore depends on the AFR fabric being powered up on both dies. Add an explicit dependency from the GPU block on die0 to AFR on die1, next to the existing die0 AFR dependency. Fixes: fa86294eb355 ("arm64: dts: apple: Add initial t6000/t6001/t6002 DTs") Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-08arm64: dts: apple: t600x-pmgr: Fix search & replace typoAsahi Lina1-1/+1
It looks like the search-and-replace that happened to add die IDs to the t600x PMGR tree was a little bit too eager on a comment, and nobody noticed! Let's fix that. Fixes: fa86294eb355 ("arm64: dts: apple: Add initial t6000/t6001/t6002 DTs") Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07ipv6: avoid use-after-free in ip6_fragment()Eric Dumazet1-0/+5
Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers. It seems to not be always true, at least for UDP stack. syzbot reported: BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline] BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618 CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [inline] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 </TASK> Allocated by task 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline] rt6_make_pcpu_route net/ipv6/route.c:1417 [inline] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [inline] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 __sys_sendto+0x23a/0x340 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7599: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:511 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] kmem_cache_free+0xee/0x5c0 mm/slub.c:3683 dst_destroy+0x2ea/0x400 net/core/dst.c:127 rcu_do_batch kernel/rcu/tree.c:2250 [inline] rcu_core+0x81f/0x1980 kernel/rcu/tree.c:2510 __do_softirq+0x1fb/0xadc kernel/softirq.c:571 Last potentially related work creation: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:481 call_rcu+0x9d/0x820 kernel/rcu/tree.c:2798 dst_release net/core/dst.c:177 [inline] dst_release+0x7d/0xe0 net/core/dst.c:167 refdst_drop include/net/dst.h:256 [inline] skb_dst_drop include/net/dst.h:268 [inline] skb_release_head_state+0x250/0x2a0 net/core/skbuff.c:838 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x151/0x4b0 net/core/skbuff.c:891 kfree_skb_list_reason+0x4b/0x70 net/core/skbuff.c:901 kfree_skb_list include/linux/skbuff.h:1227 [inline] ip6_fragment+0x2026/0x2770 net/ipv6/ip6_output.c:949 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Second to last potentially related work creation: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:481 call_rcu+0x9d/0x820 kernel/rcu/tree.c:2798 dst_release net/core/dst.c:177 [inline] dst_release+0x7d/0xe0 net/core/dst.c:167 refdst_drop include/net/dst.h:256 [inline] skb_dst_drop include/net/dst.h:268 [inline] __dev_queue_xmit+0x1b9d/0x3ba0 net/core/dev.c:4211 dev_queue_xmit include/linux/netdevice.h:3008 [inline] neigh_resolve_output net/core/neighbour.c:1552 [inline] neigh_resolve_output+0x51b/0x840 net/core/neighbour.c:1532 neigh_output include/net/neighbour.h:546 [inline] ip6_finish_output2+0x56c/0x1530 net/ipv6/ip6_output.c:134 __ip6_finish_output net/ipv6/ip6_output.c:195 [inline] ip6_finish_output+0x694/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] mld_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820 mld_send_cr net/ipv6/mcast.c:2121 [inline] mld_ifc_work+0x720/0xdc0 net/ipv6/mcast.c:2653 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 The buggy address belongs to the object at ffff88801d403dc0 which belongs to the cache ip6_dst_cache of size 240 The buggy address is located 192 bytes inside of 240-byte region [ffff88801d403dc0, ffff88801d403eb0) The buggy address belongs to the physical page: page:ffffea00007500c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d403 memcg:ffff888022f49c81 flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000200 ffffea0001ef6580 dead000000000002 ffff88814addf640 raw: 0000000000000000 00000000800c000c 00000001ffffffff ffff888022f49c81 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_HARDWALL), pid 3719, tgid 3719 (kworker/0:6), ts 136223432244, free_ts 136222971441 prep_new_page mm/page_alloc.c:2539 [inline] get_page_from_freelist+0x10b5/0x2d50 mm/page_alloc.c:4288 __alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5555 alloc_pages+0x1aa/0x270 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x213/0x300 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0xa91/0x1400 mm/slub.c:3180 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279 slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x31a/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 icmp6_dst_alloc+0x71/0x680 net/ipv6/route.c:3261 mld_sendpack+0x5de/0xe70 net/ipv6/mcast.c:1809 mld_send_cr net/ipv6/mcast.c:2121 [inline] mld_ifc_work+0x720/0xdc0 net/ipv6/mcast.c:2653 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1459 [inline] free_pcp_prepare+0x65c/0xd90 mm/page_alloc.c:1509 free_unref_page_prepare mm/page_alloc.c:3387 [inline] free_unref_page+0x1d/0x4d0 mm/page_alloc.c:3483 __unfreeze_partials+0x17c/0x1a0 mm/slub.c:2586 qlink_free mm/kasan/quarantine.c:168 [inline] qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187 kasan_quarantine_reduce+0x184/0x210 mm/kasan/quarantine.c:294 __kasan_slab_alloc+0x66/0x90 mm/kasan/common.c:302 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] kmem_cache_alloc_node+0x304/0x410 mm/slub.c:3443 __alloc_skb+0x214/0x300 net/core/skbuff.c:497 alloc_skb include/linux/skbuff.h:1267 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1191 [inline] netlink_sendmsg+0x9a6/0xe10 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 __sys_sendto+0x23a/0x340 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 1758fd4688eb ("ipv6: remove unnecessary dst_hold() in ip6_fragment()") Reported-by: syzbot+8c0ac31aa9681abb9e2d@syzkaller.appspotmail.com Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Wei Wang <weiwan@google.com> Cc: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/r/20221206101351.2037285-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-07net: plip: don't call kfree_skb/dev_kfree_skb() under spin_lock_irq()Yang Yingliang1-2/+2
It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb/dev_kfree_skb() with dev_kfree_skb_irq() and dev_consume_skb_irq() under spin_lock_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20221207015310.2984909-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-07net: phy: mxl-gpy: add MDINT workaroundMichael Walle1-0/+85
At least the GPY215B and GPY215C has a bug where it is still driving the interrupt line (MDINT) even after the interrupt status register is read and its bits are cleared. This will cause an interrupt storm. Although the MDINT is multiplexed with a GPIO pin and theoretically we could switch the pinmux to GPIO input mode, this isn't possible because the access to this register will stall exactly as long as the interrupt line is asserted. We exploit this very fact and just read a random internal register in our interrupt handler. This way, it will be delayed until the external interrupt line is released and an interrupt storm is avoided. The internal register access via the mailbox was deduced by looking at the downstream PHY API because the datasheet doesn't mention any of this. Fixes: 7d901a1e878a ("net: phy: add Maxlinear GPY115/21x/24x driver") Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221205200453.3447866-1-michael@walle.cc Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-07Merge tag 'linux-can-fixes-for-6.1-20221207' of ↵Jakub Kicinski4-14/+25
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2022-12-07 The 1st patch is by Oliver Hartkopp and fixes a potential NULL pointer deref found by syzbot in the AF_CAN protocol. The next 2 patches are by Jiri Slaby and Max Staudt and add the missing flush_work() before freeing the underlying memory in the slcan and can327 driver. The last patch is by Frank Jungclaus and target the esd_usb driver and fixes the CAN error counters, allowing them to return to zero. * tag 'linux-can-fixes-for-6.1-20221207' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: esd_usb: Allow REC and TEC to return to zero can: can327: flush TX_work on ldisc .close() can: slcan: fix freed work crash can: af_can: fix NULL pointer dereference in can_rcv_filter ==================== Link: https://lore.kernel.org/r/20221207105243.2483884-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-08platform/chrome: cros_ec_typec: zero out stale pointersVictor Ding1-0/+3
`cros_typec_get_switch_handles` allocates four pointers when obtaining type-c switch handles. These pointers are all freed if failing to obtain any of them; therefore, pointers in `port` become stale. The stale pointers eventually cause use-after-free or double free in later code paths. Zeroing out all pointer fields after freeing to eliminate these stale pointers. Fixes: f28adb41dab4 ("platform/chrome: cros_ec_typec: Register Type C switches") Fixes: 1a8912caba02 ("platform/chrome: cros_ec_typec: Get retimer handle") Signed-off-by: Victor Ding <victording@chromium.org> Acked-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221207093924.v2.1.I1864b6a7ee98824118b93677868d22d3750f439b@changeid
2022-12-07Merge tag 'qcom-arm64-defconfig-for-6.2-2' of ↵Arnd Bergmann0-0/+0
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig More Qualcomm ARM64 defconfig updates for 6.2 This enables Globalc Clock Controller (GCC) and TLMM pinctrl for SM6115 and SM4250. * tag 'qcom-arm64-defconfig-for-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: defconfig: Enable Qualcomm SM6115 / SM4250 GCC and Pinctrl Link: https://lore.kernel.org/r/20221207154339.3234068-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'qcom-drivers-for-6.2-2' of ↵Arnd Bergmann16-101/+383
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers More Qualcomm driver updates for 6.2 Socinfo is extended with knowledge about MSM8956, MSM8976, SM6115, SM4250, SM8150, SA8155 and SM8550. Support for RSC v3, as found in SM8550 is added to the RPMH RSC driver. Support for SM8550 and SM4250 ARC regulators are added to the RPM(h) power-domain drivers. SM8550 support is added to the LLCC driver. The AOSS QMP binding is declared compatible for SM8550. BWMON and LLCC now selects REGMAP_MMIO to ensure dependencies are built properly. * tag 'qcom-drivers-for-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: socinfo: Add SM6115 / SM4250 SoC IDs to the soc_id table dt-bindings: arm: qcom,ids: Add SoC IDs for SM6115 / SM4250 and variants soc: qcom: socinfo: Add SM8150 and SA8155 SoC IDs to the soc_id table dt-bindings: arm: qcom,ids: Add SoC IDs for SM8150 and SA8155 dt-bindings: soc: qcom: apr: document generic qcom,apr compatible soc: qcom: Select REMAP_MMIO for ICC_BWMON driver soc: qcom: Select REMAP_MMIO for LLCC driver soc: qcom: rpmpd: Add SM4250 support dt-bindings: power: rpmpd: Add SM4250 support dt-bindings: soc: qcom: aoss: Add compatible for SM8550 soc: qcom: llcc: Add configuration data for SM8550 dt-bindings: arm: msm: Add LLCC compatible for SM8550 soc: qcom: llcc: Add v4.1 HW version support soc: qcom: socinfo: Add SM8550 ID soc: qcom: rpmh-rsc: Avoid unnecessary checks on irq-done response soc: qcom: rpmh-rsc: Add support for RSC v3 register offsets soc: qcom: rpmhpd: Add SM8550 power domains dt-bindings: power: rpmpd: Add SM8550 to rpmpd binding soc: qcom: socinfo: Add MSM8956/76 SoC IDs to the soc_id table dt-bindings: arm: qcom,ids: Add SoC IDs for MSM8956 and MSM8976 Link: https://lore.kernel.org/r/20221207154134.3233779-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'qcom-dts-for-6.2-2' of ↵Arnd Bergmann49-2715/+3939
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt More Qualcomm DTS updates for 6.2 This introduces support for the OnePlus One, on MSM8974Pro, and properly marks other Pro devices as compatible thereof. Also on MSM8974, the description of USB devices and their PHYs are cleaned up. On the binding side compatibles for recently added ARM and ARM64 boards are added. * tag 'qcom-dts-for-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (102 commits) dt-bindings: arm: qcom: Add zombie ARM: dts: qcom: msm8974: Add OnePlus One dt-bindings: arm: qcom: Document oneplus,bacon device ARM: dts: qcom: msm8974: clean up USB nodes arm: dts: qcom: use qcom,msm8974pro for pro devices dt-bindings: arm: qcom: split MSM8974 Pro and MSM8974 ARM: dts: qcom: align LED node names with dtschema dt-bindings: arm: qcom: Document additional sa8540p device dt-bindings: arm: qcom: Add Xperia 5 IV (PDX224) dt-bindings: arm: qcom: Document msm8956 and msm8976 SoC and devices dt-bindings: arm: add xiaomi,sagit board based on msm8998 chip dt-bindings: arm: qcom: add sdm670 and pixel 3a compatible dt-bindings: arm: cpus: add qcom kryo 360 compatible ARM: dts: qcom-msm8960-cdp: align TLMM pin configuration with DT schema ARM: dts: qcom-msm8960: use define for interrupt constants dt-bindings: arm: qcom: Document SM6375 & Xperia 10 IV ARM: dts: qcom-apq8060: align TLMM pin configuration with DT schema ARM: dts: qcom: msm8226: Add MMCC node dt-bindings: arm: qcom: Separate LTE/WIFI SKU for sc7280-evoker dt-bindings: arm: qcom: Document QDU1000/QRU1000 SoCs and boards ... Link: https://lore.kernel.org/r/20221207153201.3233015-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'qcom-arm64-for-6.2-2' of ↵Arnd Bergmann68-950/+8035
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt More Qualcomm ARM64 DT updates for 6.2 This introduce description of MSM8956 and MSM8976 and based on this adds Sony Xperia X and X Compact. It adds the SA8540P QDrive 3 automotive development board and enables PCIe on the same. Add description of the Vision Mezzanine for the RB5 board and the Navigation Mezzanine for the SDM845 RB3. SC8280XP adds L3 and DDR scaling support, resulting in good performance improvement. PCIe and UFS is marked DMA coherent, resolving data corruption issues. Reference clocks for UFS phy and device are corrected, to resolve issues seen in combinations with some bootloaders where it's not sufficient to rely on the bootloader state. RTC description is added to the SA8295P ADP board. For SM6115 GPI, PRNG, tsens, WCN, cpufreq, I2C/SPI and display blocks are added. On SM6375 QUP blocks are described, allowing the addition of touchscreen and remoteprocs for ADSP and CDSP are introduced. Sony Xperia 10 IV adds description of regulators, allowing enabling SD-card support. SM8250 Coresight components are described It introduces support for the Xiaomi Mi 6 on MSM8998 and adds flash LED to the Xiaomi Redmi 2. The SDHCI block on SM8350 is described and enabled on Sony Xperia 5 III. SM8450 sound and Soundwire blocks are described, and enabled on HDK. CPU supply clock is described, to satisfy the DT binding and the opp-framework. Sony Xperia 5 IV support is added, with touchscreen added. Lastly a range of changes to align DT source with their bindings. * tag 'qcom-arm64-for-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (98 commits) dt-bindings: iio: adc: qcom,spmi-vadc: fix PM8350 define dt-bindings: iio: adc: qcom,spmi-vadc: extend example arm64: dts: qcom: sc8280xp: fix UFS DMA coherency arm64: dts: qcom: sc7280: Add DT for sc7280-herobrine-zombie arm64: dts: qcom: sm8250-sony-xperia-edo: fix no-mmc property for SDHCI arm64: dts: qcom: sdm845-sony-xperia-tama: fix no-mmc property for SDHCI arm64: dts: qcom: sda660-inforce-ifc6560: fix no-mmc property for SDHCI arm64: dts: qcom: sa8155p-adp: fix no-mmc property for SDHCI arm64: dts: qcom: qrb5165-rb: fix no-mmc property for SDHCI arm64: dts: qcom: sm8450: align MMC node names with dtschema arm64: dts: qcom: sc7180-trogdor: use generic node names arm64: dts: qcom: sm8450-hdk: add sound support arm64: dts: qcom: sm8450: add Soundwire and LPASS arm64: dts: qcom: sm8450: add GPR node arm64: dts: qcom: sa8540p-ride: enable PCIe support arm64: dts: qcom: sm6115: Add smmu fallback to qcom generic compatible arm64: dts: qcom: sm6115: Add WCN node arm64: dts: qcom: sm6115: Add i2c/spi nodes arm64: dts: qcom: sm6115: Add GPI DMA arm64: dts: qcom: sm6115: Add mdss/dpu node ... Link: https://lore.kernel.org/r/20221207152554.3232434-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'socfpga_dts_updates_for_v6.2_part2' of ↵Arnd Bergmann6-16/+16
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into soc/dt SoCFPGA dts updates for v6.2, part 2 - Fix dtschema for LED node - Fix dtschema for i2c-mux * tag 'socfpga_dts_updates_for_v6.2_part2' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: ARM: dts: socfpga: Fix pca9548 i2c-mux node name ARM: dts: socfpga: align LED node names with dtschema arm64: dts: altera: align LED node names with dtschema Link: https://lore.kernel.org/r/20221206214006.590562-1-dinguyen@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-07Merge tag 'platform-drivers-x86-v6.1-5' of ↵Linus Torvalds1-0/+6
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fix from Hans de Goede: "A single fix for 6.1 for suspend/resume issues on some AMD systems" * tag 'platform-drivers-x86-v6.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86/amd: pmc: Add a workaround for an s0i3 issue on Cezanne
2022-12-07fscache: Fix oops due to race with cookie_lru and use_cookieDave Wysochanski2-0/+10
If a cookie expires from the LRU and the LRU_DISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscache_use_cookie and begin to use it. When the cookie_worker finally runs, it will see the LRU_DISCARD flag set, transition the cookie->state to LRU_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL. Fix the oops by clearing the LRU_DISCARD bit if another thread uses the cookie before the cookie_worker runs. BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100 Fixes: 12bb21a29c19 ("fscache: Implement cookie user counting and resource pinning") Reported-by: Daire Byrne <daire.byrne@gmail.com> Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Daire Byrne <daire@dneg.com> Link: https://lore.kernel.org/r/20221117115023.1350181-1-dwysocha@redhat.com/ # v1 Link: https://lore.kernel.org/r/20221117142915.1366990-1-dwysocha@redhat.com/ # v2 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-12-07media: videobuf2-core: take mmap_lock in vb2_get_unmapped_area()Hans Verkuil1-29/+73
While vb2_mmap took the mmap_lock mutex, vb2_get_unmapped_area didn't. Add this. Also take this opportunity to move the 'q->memory != VB2_MEMORY_MMAP' check and vb2_fileio_is_active() check into __find_plane_by_offset() so both vb2_mmap and vb2_get_unmapped_area do the same checks. Since q->memory is checked while mmap_lock is held, also take that lock in reqbufs and create_bufs when it is set, and set it back to MEMORY_UNKNOWN on error. Fixes: f035eb4e976e ("[media] videobuf2: fix lockdep warning") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-12-07drm/amd/display: fix array index out of bound error in DCN32 DMLAurabindo Pillai1-1/+1
[Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states. Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.0.x
2022-12-07drm/amdgpu/sdma_v4_0: turn off SDMA ring buffer in the s2idle suspendPrike Liang1-9/+15
In the SDMA s0ix save process requires to turn off SDMA ring buffer for avoiding the SDMA in-flight request, otherwise will suffer from SDMA page fault which causes by page request from in-flight SDMA ring accessing at SDMA restore phase. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2248 Cc: stable@vger.kernel.org # 6.0,5.15+ Fixes: f8f4e2a51834 ("drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix.") Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-12-07Merge tag 'irqchip-6.2' of ↵Thomas Gleixner23-144/+557
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates frim Marc Zyngier: - More APCI fixes and improvements for the LoongArch architecture, adding support for the HTVEC irqchip, suspend-resume, and some PCI INTx workarounds - Initial DT support for LoongArch. I'm not even kidding. - Support for the MTK CIRQv2, a minor deviation from the original version - Error handling fixes for wpcm450, GIC... - BE detection for a FSL controller - Declare the Sifive PLIC as wake-up agnostic - Simplify fishing out the device data for the ST irqchip - Mark some data structures as __initconst in the apple-aic driver - Switch over from strtobool to kstrtobool - COMPILE_TEST fixes
2022-12-07Merge tag 'nvme-6.1-2022-12-07' of git://git.infradead.org/nvme into block-6.1Jens Axboe1-4/+4
Pull NVMe fix from Christoph: "nvme fixes for Linux 6.1 - initialize core quirks before calling nvme_init_subsystem (Pankaj Raghav)" * tag 'nvme-6.1-2022-12-07' of git://git.infradead.org/nvme: nvme initialize core quirks before calling nvme_init_subsystem
2022-12-07net: dsa: mv88e6xxx: accept phy-mode = "internal" for internal PHY portsVladimir Oltean1-2/+5
The ethernet-controller dt-schema, mostly pushed forward by Linux, has the "internal" PHY mode for denoting MAC connections to an internal PHY. U-Boot may provide device tree blobs where this phy-mode is specified, so make the Linux driver accept them. It appears that the current behavior with phy-mode = "internal" was introduced when mv88e6xxx started reporting supported_interfaces to phylink. Prior to that, I don't think it would have any issues accepting this phy-mode. Fixes: d4ebf12bcec4 ("net: dsa: mv88e6xxx: populate supported_interfaces and mac_capabilities") Link: https://lore.kernel.org/linux-arm-kernel/20221205172709.kglithpbhdbsakvd@skbuf/T/ Reported-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Tim Harvey <tharvey@gateworks.com> # imx6q-gw904.dts Link: https://lore.kernel.org/r/20221205194845.2131161-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-07xen/netback: fix build warningJuergen Gross1-1/+1
Commit ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area") introduced a (valid) build warning. There have even been reports of this problem breaking networking of Xen guests. Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com> Tested-by: Jason Andryuk <jandryuk@gmail.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2022-12-07xen/netback: don't call kfree_skb() under spin_lock_irqsave()Yang Yingliang1-1/+1
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Fixes: be81992f9086 ("xen/netback: don't queue unlimited number of packages") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Paul Durrant <paul@xen.org> Link: https://lore.kernel.org/r/20221205141333.3974565-1-yangyingliang@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-07platform/x86/amd: pmc: Add a workaround for an s0i3 issue on CezanneMario Limonciello1-0/+6
Cezanne platforms under the right circumstances have a synchronization problem where attempting to enter s2idle may fail if the x86 cores are put into HLT before hardware resume from the previous attempt has completed. To avoid this issue add a 10-20ms delay before entering s2idle another time. This workaround will only be applied on interrupts that wake the hardware but don't break the s2idle loop. Cc: stable@vger.kernel.org # 6.1 Cc: "Mahapatra, Rajib" <Rajib.Mahapatra@amd.com> Cc: "Raul Rangel" <rrangel@chromium.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20221116154341.13382-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-12-07ARM: 9278/1: kfence: only handle translation faultsWang Kefeng2-5/+22
This is a similar fixup like arm64 does, only handle translation faults in case of unexpected kfence report when alignment faults on ARM, see more from commit 0bb1fbffc631 ("arm64: mm: kfence: only handle translation faults"). Fixes: 75969686ec0d ("ARM: 9166/1: Support KFENCE for ARM") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-12-07io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()Harshit Mogalapalli1-1/+3
Syzkaller reports a NULL deref bug as follows: BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3 Read of size 4 at addr 0000000000000138 by task file1/1955 CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ? io_tctx_exit_cb+0x53/0xd3 kasan_report+0xbb/0x1f0 ? io_tctx_exit_cb+0x53/0xd3 kasan_check_range+0x140/0x190 io_tctx_exit_cb+0x53/0xd3 task_work_run+0x164/0x250 ? task_work_cancel+0x30/0x30 get_signal+0x1c3/0x2440 ? lock_downgrade+0x6e0/0x6e0 ? lock_downgrade+0x6e0/0x6e0 ? exit_signals+0x8b0/0x8b0 ? do_raw_read_unlock+0x3b/0x70 ? do_raw_spin_unlock+0x50/0x230 arch_do_signal_or_restart+0x82/0x2470 ? kmem_cache_free+0x260/0x4b0 ? putname+0xfe/0x140 ? get_sigframe_size+0x10/0x10 ? do_execveat_common.isra.0+0x226/0x710 ? lockdep_hardirqs_on+0x79/0x100 ? putname+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: panic_on_warn set ... This happens because the adding of task_work from io_ring_exit_work() isn't synchronized with canceling all work items from eg exec. The execution of the two are ordered in that they are both run by the task itself, but if io_tctx_exit_cb() is queued while we're canceling all work items off exec AND gets executed when the task exits to userspace rather than in the main loop in io_uring_cancel_generic(), then we can find current->io_uring == NULL and hit the above crash. It's safe to add this NULL check here, because the execution of the two paths are done by the task itself. Cc: stable@vger.kernel.org Fixes: d56d938b4bef ("io_uring: do ctx initiated file note removal") Reported-by: syzkaller <syzkaller@googlegroups.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20221206093833.3812138-1-harshit.m.mogalapalli@oracle.com [axboe: add code comment and also put an explanation in the commit msg] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-12-07Merge tag 'ieee802154-for-net-2022-12-05' of ↵Paolo Abeni3-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan Stefan Schmidt says: ==================== pull-request: ieee802154 for net 2022-12-05 An update from ieee802154 for your *net* tree: Three small fixes this time around. Ziyang Xuan fixed an error code for a timeout during initialization of the cc2520 driver. Hauke Mehrtens fixed a crash in the ca8210 driver SPI communication due uninitialized SPI structures. Wei Yongjun added INIT_LIST_HEAD ieee802154_if_add() to avoid a potential null pointer dereference. ==================== Link: https://lore.kernel.org/r/20221205122515.1720539-1-stefan@datenfreihafen.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-07dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and ↵Yuan Can1-0/+4
dpaa2_switch_acl_entry_remove() The cmd_buff needs to be freed when error happened in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove(). Fixes: 1110318d83e8 ("dpaa2-switch: add tc flower hardware offload on ingress traffic") Signed-off-by: Yuan Can <yuancan@huawei.com> Link: https://lore.kernel.org/r/20221205061515.115012-1-yuancan@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-07ethernet: aeroflex: fix potential skb leak in greth_init_rings()Zhang Changzhong1-0/+1
The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only. Fixes: d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/1670134149-29516-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-07tipc: call tipc_lxc_xmit without holding node_read_lockXin Long1-3/+9
When sending packets between nodes in netns, it calls tipc_lxc_xmit() for peer node to receive the packets where tipc_sk_mcast_rcv()/tipc_sk_rcv() might be called, and it's pretty much like in tipc_rcv(). Currently the local 'node rw lock' is held during calling tipc_lxc_xmit() to protect the peer_net not being freed by another thread. However, when receiving these packets, tipc_node_add_conn() might be called where the peer 'node rw lock' is acquired. Then a dead lock warning is triggered by lockdep detector, although it is not a real dead lock: WARNING: possible recursive locking detected -------------------------------------------- conn_server/1086 is trying to acquire lock: ffff8880065cb020 (&n->lock#2){++--}-{2:2}, \ at: tipc_node_add_conn.cold.76+0xaa/0x211 [tipc] but task is already holding lock: ffff8880065cd020 (&n->lock#2){++--}-{2:2}, \ at: tipc_node_xmit+0x285/0xb30 [tipc] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&n->lock#2); lock(&n->lock#2); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by conn_server/1086: #0: ffff8880036d1e40 (sk_lock-AF_TIPC){+.+.}-{0:0}, \ at: tipc_accept+0x9c0/0x10b0 [tipc] #1: ffff8880036d5f80 (sk_lock-AF_TIPC/1){+.+.}-{0:0}, \ at: tipc_accept+0x363/0x10b0 [tipc] #2: ffff8880065cd020 (&n->lock#2){++--}-{2:2}, \ at: tipc_node_xmit+0x285/0xb30 [tipc] #3: ffff888012e13370 (slock-AF_TIPC){+...}-{2:2}, \ at: tipc_sk_rcv+0x2da/0x1b40 [tipc] Call Trace: <TASK> dump_stack_lvl+0x44/0x5b __lock_acquire.cold.77+0x1f2/0x3d7 lock_acquire+0x1d2/0x610 _raw_write_lock_bh+0x38/0x80 tipc_node_add_conn.cold.76+0xaa/0x211 [tipc] tipc_sk_finish_conn+0x21e/0x640 [tipc] tipc_sk_filter_rcv+0x147b/0x3030 [tipc] tipc_sk_rcv+0xbb4/0x1b40 [tipc] tipc_lxc_xmit+0x225/0x26b [tipc] tipc_node_xmit.cold.82+0x4a/0x102 [tipc] __tipc_sendstream+0x879/0xff0 [tipc] tipc_accept+0x966/0x10b0 [tipc] do_accept+0x37d/0x590 This patch avoids this warning by not holding the 'node rw lock' before calling tipc_lxc_xmit(). As to protect the 'peer_net', rcu_read_lock() should be enough, as in cleanup_net() when freeing the netns, it calls synchronize_rcu() before the free is continued. Also since tipc_lxc_xmit() is like the RX path in tipc_rcv(), it makes sense to call it under rcu_read_lock(). Note that the right lock order must be: rcu_read_lock(); tipc_node_read_lock(n); tipc_node_read_unlock(n); tipc_lxc_xmit(); rcu_read_unlock(); instead of: tipc_node_read_lock(n); rcu_read_lock(); tipc_node_read_unlock(n); tipc_lxc_xmit(); rcu_read_unlock(); and we have to call tipc_node_read_lock/unlock() twice in tipc_node_xmit(). Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns") Reported-by: Shuang Li <shuali@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/5bdd1f8fee9db695cfff4528a48c9b9d0523fb00.1670110641.git.lucien.xin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-12-07can: esd_usb: Allow REC and TEC to return to zeroFrank Jungclaus1-0/+6
We don't get any further EVENT from an esd CAN USB device for changes on REC or TEC while those counters converge to 0 (with ecc == 0). So when handling the "Back to Error Active"-event force txerr = rxerr = 0, otherwise the berr-counters might stay on values like 95 forever. Also, to make life easier during the ongoing development a netdev_dbg() has been introduced to allow dumping error events send by an esd CAN USB device. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/all/20221130202242.3998219-2-frank.jungclaus@esd.eu Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-12-07can: can327: flush TX_work on ldisc .close()Max Staudt1-7/+10
Additionally, remove it from .ndo_stop(). This ensures that the worker is not called after being freed, and that the UART TX queue remains active to send final commands when the netdev is stopped. Thanks to Jiri Slaby for finding this in slcan: https://lore.kernel.org/linux-can/20221201073426.17328-1-jirislaby@kernel.org/ A variant of this patch for slcan, with the flush in .ndo_stop() still present, has been tested successfully on physical hardware: https://bugzilla.suse.com/show_bug.cgi?id=1205597 Fixes: 43da2f07622f ("can: can327: CAN/ldisc driver for ELM327 based OBD-II adapters") Cc: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Cc: Max Staudt <max@enpas.org> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Max Staudt <max@enpas.org> Link: https://lore.kernel.org/all/20221202160148.282564-1-max@enpas.org Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-12-07can: slcan: fix freed work crashJiri Slaby (SUSE)1-4/+6
The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Apparently, the slcan's tx_work is freed while being scheduled. While slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), slcan_close() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed. So add an additional flush_work() to slcan_close() to be sure the work is flushed under all circumstances. The Fixes commit below moved flush_work() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_netdev_close()? I see the same pattern in can327. So it perhaps needs the very same fix. Fixes: cfcb4465e992 ("can: slcan: remove legacy infrastructure") Link: https://bugzilla.suse.com/show_bug.cgi?id=1205597 Reported-by: Richard Palethorpe <richard.palethorpe@suse.com> Tested-by: Petr Vorel <petr.vorel@suse.com> Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Cc: Max Staudt <max@enpas.org> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Reviewed-by: Max Staudt <max@enpas.org> Link: https://lore.kernel.org/all/20221201073426.17328-1-jirislaby@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-12-07can: af_can: fix NULL pointer dereference in can_rcv_filterOliver Hartkopp1-3/+3
Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly. Fixes: 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") Reported-by: syzbot+2d7f58292cb5b29eb5ad@syzkaller.appspotmail.com Reported-by: Wei Chen <harperchen1110@gmail.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20221206201259.3028-1-socketcan@hartkopp.net Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-12-06Merge branch '40GbE' of ↵Jakub Kicinski3-11/+22
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-12-05 (i40e) Michal clears XPS init flag on reset to allow for updated values to be written. Sylwester adds sleep to VF reset to resolve issue of VFs not getting resources. Przemyslaw rejects filters for raw IPv4 or IPv6 l4_4_bytes filters as they are not supported. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: i40e: Disallow ip4 and ip6 l4_4_bytes i40e: Fix for VF MAC address 0 i40e: Fix not setting default xps_cpus after reset ==================== Link: https://lore.kernel.org/r/20221205212523.3197565-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-06net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions()Zhengchao Shao1-0/+2
When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released. Fixes: bf425b82059e ("net: dsa: sja1105: expose static config as devlink region") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221205012132.2110979-1-shaozhengchao@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-06Merge branch 'ipv4-two-bug-fixes'Jakub Kicinski3-0/+41
Ido Schimmel says: ==================== ipv4: Two small fixes for bugs in IPv4 routing code. A variation of the second bug was reported by an FRR 5.0 (released 06/18) user as this version was setting a table ID of 0 for the default VRF, unlike iproute2 and newer FRR versions. The first bug was discovered while fixing the second. Both bugs are not regressions (never worked) and are not critical in my opinion, so the fixes can be applied to net-next, if desired. No regressions in other tests: # ./fib_tests.sh ... Tests passed: 191 Tests failed: 0 ==================== Link: https://lore.kernel.org/r/20221204075045.3780097-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-06ipv4: Fix incorrect route flushing when table ID 0 is usedIdo Schimmel2-0/+13
Cited commit added the table ID to the FIB info structure, but did not properly initialize it when table ID 0 is used. This can lead to a route in the default VRF with a preferred source address not being flushed when the address is deleted. Consider the following example: # ip address add dev dummy1 192.0.2.1/28 # ip address add dev dummy1 192.0.2.17/28 # ip route add 198.51.100.0/24 via 192.0.2.2 src 192.0.2.17 metric 100 # ip route add table 0 198.51.100.0/24 via 192.0.2.2 src 192.0.2.17 metric 200 # ip route show 198.51.100.0/24 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 100 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 200 Both routes are installed in the default VRF, but they are using two different FIB info structures. One with a metric of 100 and table ID of 254 (main) and one with a metric of 200 and table ID of 0. Therefore, when the preferred source address is deleted from the default VRF, the second route is not flushed: # ip address del dev dummy1 192.0.2.17/28 # ip route show 198.51.100.0/24 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 200 Fix by storing a table ID of 254 instead of 0 in the route configuration structure. Add a test case that fails before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Table ID 0 TEST: Route removed in default VRF when source address deleted [FAIL] Tests passed: 8 Tests failed: 1 And passes after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Table ID 0 TEST: Route removed in default VRF when source address deleted [ OK ] Tests passed: 9 Tests failed: 0 Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs") Reported-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-06ipv4: Fix incorrect route flushing when source address is deletedIdo Schimmel2-0/+28
Cited commit added the table ID to the FIB info structure, but did not prevent structures with different table IDs from being consolidated. This can lead to routes being flushed from a VRF when an address is deleted from a different VRF. Fix by taking the table ID into account when looking for a matching FIB info. This is already done for FIB info structures backed by a nexthop object in fib_find_info_nh(). Add test cases that fail before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [FAIL] TEST: Route in default VRF not removed [ OK ] RTNETLINK answers: File exists TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [FAIL] Tests passed: 6 Tests failed: 2 And pass after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Tests passed: 8 Tests failed: 0 Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-06net: fec: properly guard irq coalesce setupRasmus Villemoes1-1/+2
Prior to the Fixes: commit, the initialization code went through the same fec_enet_set_coalesce() function as used by ethtool, and that function correctly checks whether the current variant has support for irq coalescing. Now that the initialization code instead calls fec_enet_itr_coal_set() directly, that call needs to be guarded by a check for the FEC_QUIRK_HAS_COALESCE bit. Fixes: df727d4547de (net: fec: don't reset irq coalesce settings to defaults on "ip link up") Reported-by: Greg Ungerer <gregungerer@westnet.com.au> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221205204604.869853-1-linux@rasmusvillemoes.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-06bonding: get correct NA dest addressHangbin Liu1-1/+1
In commit 4d633d1b468b ("bonding: fix ICMPv6 header handling when receiving IPv6 messages"), there is a copy/paste issue for NA daddr. I found that in my testing and fixed it in my local branch. But I forgot to re-format the patch and sent the wrong mail. Fix it by reading the correct dest address. Fixes: 4d633d1b468b ("bonding: fix ICMPv6 header handling when receiving IPv6 messages") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Jonathan Toppins <jtoppins@redhat.com> Link: https://lore.kernel.org/r/20221206032055.7517-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-07arm64: dts: apple: Add t8103 L1/L2 cache properties and nodesJanne Grunau1-0/+38
The t8103 CPU nodes are missing the cache hierarchy information. The cache hierarchy on Arm can not be detected and needs to be described in DT. The OS scheduler can make use of this information for scheduling decisions. The cache size information is based on various articles about the processors. There's also an L3 system level cache (SLC). It's not described here because SLCs typically have some MMIO interface which would need to be described. Based on Rob Herring's patch adding cache properties and nodes for t600x. Link: https://lore.kernel.org/asahi/20221122220619.659174-1-robh@kernel.org/ Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07arm64: dts: apple: Rename dart-sio* to sio-dart*Hector Martin2-5/+5
All the other DARTs are named foo-dart, so let's keep things consistent. Fixes: 51979fbb7fb8 ("arm64: dts: apple: t600x: Add MCA and its support") Fixes: 8a3df85ad87d ("arm64: dts: apple: t8103: Add MCA and its support") Reviewed-by: Sven Peter <sven@svenpeter.dev> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07arch: arm64: apple: t600x: Use standard "iommu" node nameJanne Grunau1-4/+4
The PCIe iommu nodes use "dart" as node names. Replace it with the the standard "iommu" node name as all other iommu nodes. Fixes: 7b0b0191a2c7 ("arm64: dts: apple: Add initial t6000/t6001/t6002 DTs") Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07arch: arm64: apple: t8103: Use standard "iommu" node nameJanne Grunau1-3/+3
The PCIe iommu nodes use "dart" as node names. Replace it with the the standard "iommu" node name as all other iommu nodes. Fixes: 3c866bb79577 ("arm64: dts: apple: t8103: Add PCIe DARTs") Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-07ata: libahci_platform: ahci_platform_find_clk: oops, NULL pointerAnders Roxell1-1/+1
When booting a arm 32-bit kernel with config CONFIG_AHCI_DWC enabled on a am57xx-evm board. This happens when the clock references are unnamed in DT, the strcmp() produces a NULL pointer dereference, see the following oops, NULL pointer dereference: [ 4.673950] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 4.682098] [00000000] *pgd=00000000 [ 4.685699] Internal error: Oops: 5 [#1] SMP ARM [ 4.690338] Modules linked in: [ 4.693420] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc7 #1 [ 4.699615] Hardware name: Generic DRA74X (Flattened Device Tree) [ 4.705749] PC is at strcmp+0x0/0x34 [ 4.709350] LR is at ahci_platform_find_clk+0x3c/0x5c [ 4.714416] pc : [<c130c494>] lr : [<c0c230e0>] psr: 20000013 [ 4.720703] sp : f000dda8 ip : 00000001 fp : c29b1840 [ 4.725952] r10: 00000020 r9 : c1b23380 r8 : c1b23368 [ 4.731201] r7 : c1ab4cc4 r6 : 00000001 r5 : c3c66040 r4 : 00000000 [ 4.737762] r3 : 00000080 r2 : 00000080 r1 : c1ab4cc4 r0 : 00000000 [...] [ 4.998870] strcmp from ahci_platform_find_clk+0x3c/0x5c [ 5.004302] ahci_platform_find_clk from ahci_dwc_probe+0x1f0/0x54c [ 5.010589] ahci_dwc_probe from platform_probe+0x64/0xc0 [ 5.016021] platform_probe from really_probe+0xe8/0x41c [ 5.021362] really_probe from __driver_probe_device+0xa4/0x204 [ 5.027313] __driver_probe_device from driver_probe_device+0x38/0xc8 [ 5.033782] driver_probe_device from __driver_attach+0xb4/0x1ec [ 5.039825] __driver_attach from bus_for_each_dev+0x78/0xb8 [ 5.045532] bus_for_each_dev from bus_add_driver+0x17c/0x220 [ 5.051300] bus_add_driver from driver_register+0x90/0x124 [ 5.056915] driver_register from do_one_initcall+0x48/0x1e8 [ 5.062591] do_one_initcall from kernel_init_freeable+0x1cc/0x234 [ 5.068817] kernel_init_freeable from kernel_init+0x20/0x13c [ 5.074584] kernel_init from ret_from_fork+0x14/0x2c [ 5.079681] Exception stack(0xf000dfb0 to 0xf000dff8) [ 5.084747] dfa0: 00000000 00000000 00000000 00000000 [ 5.092956] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 5.101165] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 5.107818] Code: e5e32001 e3520000 1afffffb e12fff1e (e4d03001) [ 5.114013] ---[ end trace 0000000000000000 ]--- Add an extra check in the if-statement if hpriv-clks[i].id. Fixes: 6ce73f3a6fc0 ("ata: libahci_platform: Add function returning a clock-handle by id") Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-12-06ARM: dts: socfpga: Fix pca9548 i2c-mux node nameGeert Uytterhoeven1-1/+1
"make dtbs_check": arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch@70: $nodename:0: 'i2cswitch@70' does not match '^(i2c-?)?mux' From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3', 'i2c@4', 'i2c@5', 'i2c@6', 'i2c@7' were unexpected) From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml Fix this by renaming the PCA9548 node to "i2c-mux", to match the I2C bus multiplexer/switch DT bindings and the Generic Names Recommendation in the Devicetree Specification. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2022-12-06Merge tag 'arm64-fixes' of ↵Linus Torvalds1-1/+16
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Revert the dropping of the cache invalidation from the arm64 arch_dma_prep_coherent() as it caused a regression in the qcom_q6v5_mss remoteproc driver. The driver is already buggy but the original arm64 change made the problem obvious. The change will be re-introduced once the driver is fixed" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()"
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-13 18:49:48 +0000