Bl808/watchdog #2
Conversation
Add bindings doc for Bouffalolab UART Driver Signed-off-by: Jisheng Zhang <[email protected]>
The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux. Signed-off-by: Jisheng Zhang <[email protected]>
Add a baisc dtsi for the bouffalolab bl808 SoC. Signed-off-by: Jisheng Zhang <[email protected]>
Sipeed manufactures a M1S system-on-module and dock board, add basic support for them. Signed-off-by: Jisheng Zhang <[email protected]>
I want to maintain this Bouffalolab riscv SoC entry from now on. Signed-off-by: Jisheng Zhang <[email protected]>
ehci controller registers are at address 0x20072000 not 0x20072010
Pinmux for this device conflicts with EMAC, so disable it until pinmux is changed to some other pins.
Add device-tree node for EMAC ethernet device and fake clock node to represent 50MHz clock to the device. Add a virtualized interrupt bit for forwareded EMAC interrupts.
The number of address cells needed here (one) does not match the implicitly-defined default number of cells. Signed-off-by: Samuel Holland <[email protected]>
The number of address cells needed here (one) does not match the implicitly-defined default number of cells. Signed-off-by: Allen Martin <[email protected]>
…string on the Ox64 device tree
|
There were two issues remaining that I didn't take care of.
|
Hey! I don't think 2 is too much if at all an issue. If it works and it does not cause any issues or have any caveats, thats fine IMO. With regards to 1, I do think this is an issue worth further discussion before we complete this PR. All the different bits I have looked at appear to point "timer" as under the category of "clocksource" and commonly associated with watchdogs too. I think it might be worth taking a look around the clocksource API to see if the timer setup can be implemented there or not (I have not checked at all) and if it does appear possible, it might be worth looking at supporting as a dependency to this prior to completing this driver. Not sure if @smaeul wants to chime in with anything else regarding clocksource considering this is not the only clock thing that needs to be considered right now for the BL808? |
|
I think we need to first decide which timer should be "supported" on linux. There are two timers, (timer0, and timer1) both wired upto M0/LP... (and thus IRQ forwarding is also required one way or another). Timers are also a pretty standard requirement for a lot of RTOS/Bare Metal programs so having linux take over both is not optimal. But I was also thinking of writing a different WDG driver here. The actual WDG runs on M0, but a new Linux WDG pings it via the Mailbox Services. If we don't get a WDG ping from linux (and don't get a ping from anything running on D0) then we let the WDG expire and execute a reset. This handles the case of M0 or D0 crashing, where as right now if M0 crashes (and stops forwarding interupts) then linux just sits there throwing errors and the WDG doesn't trigger. (nothing stopping us from having both @grant-olson driver and a 2nd driver, and in fact we might be able to merge them via some Device Tree Magic) |
…eues(). Christoph Paasch reported that commit b5fc292 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues(). [0 - 2] Also, we can reproduce it by a program in [3]. In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy() to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in inet_csk_destroy_sock(). The same check has been in inet_sock_destruct() from at least v2.6, we can just remove the WARN_ON_ONCE(). However, among the users of sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct(). Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor(). [0]: https://lore.kernel.org/netdev/[email protected]/ [1]: multipath-tcp/mptcp_net-next#341 [2]: WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0 Modules linked in: CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0 Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9 RSP: 0018:ffff88810570fc68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005 RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488 R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458 FS: 00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0 Call Trace: <TASK> inet_csk_destroy_sock+0x1a1/0x320 __tcp_close+0xab6/0xe90 tcp_close+0x30/0xc0 inet_release+0xe9/0x1f0 inet6_release+0x4c/0x70 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f7fdf7ae28d Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003 RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000 R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8 </TASK> [3]: https://lore.kernel.org/netdev/[email protected]/ Fixes: b5fc292 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") Reported-by: syzbot <[email protected]> Reported-by: Christoph Paasch <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Jakub Sitnicki says: ==================== This patch set addresses the syzbot report in [1]. Patch #1 has been suggested by Eric [2]. I extended it to cover the rest of sock_map proto callbacks. Otherwise we would still overflow the stack. Patch #2 contains the actual fix and bug analysis. Patches #3 & #4 add coverage to selftests to trigger the bug. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/CANn89iK2UN1FmdUcH12fv_xiZkv2G+Nskvmq7fG6aA_6VKRf6g@mail.gmail.com/ --- v1 -> v2: v1: https://lore.kernel.org/r/[email protected] [v1 didn't hit bpf@ ML by mistake] * pull in Eric's patch to protect against recursion loop bugs (Eric) * add a macro helper to check if pointer is inside a memory range (Eric) ==================== Signed-off-by: Alexei Starovoitov <[email protected]>
alexhorner
force-pushed
the
bl808/board
branch
2 times, most recently
from
b84f64f to
d95c24a
Compare
|
Hey all, just wanted to spark conversation on this one again. Looking to merge it when/if appropriate We no longer have an IRQ forwarding dependency on M0 too, so that probably changes things a tad |
6 participants
This adds support for the BL808 watchdog. The implementation has a resolution of 1 second and the timeout range can be set from 1 - 2^14 seconds. To test with busybox's watchdog:
watchdog -T 10 -t 1 /dev/watchdog -FThis should run just fine.watchdog -T 1 -t 10 /dev/watchdog -F.