An SBI Watchdog for RISC-V: Qualcomm Posts a Firmware-Defined Driver With IMSIC Pretimeout

On 2 October 2026 (date header Fri Oct 02 2026 - 12:43:08 EST), Prajwal N posted an RFC two-patch series to the Linux kernel mailing list: [RFC PATCH 1/2] include: sbi_ecall_interface: Add defines for the RISC-V SBI watchdog extension and [RFC PATCH 2/2] drivers/watchdog: Add RISC-V SBI watchdog driver. The new driver file carries a Copyright (C) 2026 Qualcomm Inc. header.

The series is small in volume — 416 insertions across a nine-line Kconfig stanza, a one-line Makefile change and a new 406-line drivers/watchdog/riscv_sbi_wdt.c — but it changes what a watchdog is on a RISC-V platform. Instead of an MMIO timer block inside a specific SoC, the watchdog becomes a service that firmware exposes through the Supervisor Binary Interface, and Linux reaches it with SBI ecalls. If it lands, a vendor with a compliant SBI implementation gets a working watchdog on Linux with no SoC-specific driver at all.

What the Driver Actually Does

The new RISCV_SBI_WATCHDOG Kconfig symbol is a tristate that depends on RISCV_SBI and defaults to RISCV. Its help text is a single blunt sentence: "Requires firmware support." That dependency is the whole design: every watchdog action becomes an ecall against a new extension ID, SBI_EXT_WDT.

Functionally the driver implements the standard Linux watchdog contract. sbiwdt_info advertises WDIOF_SETTIMEOUT, WDIOF_KEEPALIVEPING, WDIOF_PRETIMEOUT and WDIOF_MAGICCLOSE, and the ops table wires the standard callbacks onto six SBI function IDs:

Defaults are conservative. SBI_WDT_DEFAULT_TIMEOUT is 60 seconds, and sbiwdt_init_attributes() reads the firmware's minimum period and uses it as min_timeout, falling back to 1 µs if the firmware reports zero. SBI error codes are translated to Linux errno values through the existing sbi_err_map_linux_errno() helper, so the watchdog core sees ordinary return codes.

Pretimeout Arrives as an MSI, Not an Interrupt Line

The most interesting engineering detail is how the pretimeout notification — the "the real timeout is about to fire" warning that lets software dump state or trigger a controlled recovery — is delivered. Rather than a wired interrupt from a timer block, the driver asks the IMSIC (the incoming message-signaled interrupt controller of the ratified RISC-V AIA) for a platform MSI:

• sbiwdt_probe() calls imsic_get_global_config(), then irq_find_matching_fwnode(imsic_global->fwnode, DOMAIN_BUS_PLATFORM_MSI) to locate the MSI interrupt domain.
• platform_device_msi_init_and_alloc_irqs(dev, 1, sbiwdt_msi_write) allocates one MSI for the platform device.
• The sbiwdt_msi_write() callback receives the MSI address and data that the kernel has prepared and forwards both to firmware in a single SBI_EXT_WATCHDOG_WRITE_NOTIF_MSI_MESSAGE ecall — so it is OpenSBI itself that will raise the notification message when the pretimeout expires.
• The resulting virtual IRQ is registered under the name "sbiwdt-pretimeout" and its handler simply calls watchdog_notify_pretimeout(), handing the event to the watchdog core's pretimeout governor machinery.

This path is gated on a capability bit: SBI_WDT_CAP_MSI_SUPPORT_MASK is BIT(1) of the firmware-reported wdt_capability. If the bit is clear, the driver still registers with the watchdog core — it simply has no pretimeout path.

The SBI v3.0 Gate

Module init is where platform support is enforced. Two conditions must both hold, or the driver refuses to load:

if (sbi_spec_version < sbi_mk_version(3, 0) ||
    sbi_probe_extension(SBI_EXT_WDT) <= 0)
        return -ENODEV;

The running firmware must implement SBI 3.0 or later, and it must probe positive for the watchdog extension. Registration happens at late_initcall through platform_driver_register() plus platform_device_register_simple() — and there is no device-tree node in this RFC, because the "device" is the firmware interface itself rather than a memory-mapped block. The kernel discovers it by probing, the same way it discovers the SBAI console or the SBI PMU.

Why This Matters for Bring-Up

A per-SoC watchdog driver is one of the first things a new RISC-V SoC needs — and historically one of the least portable things in the tree. Every vendor's timer block has its own registers, its own timeout semantics and its own quirk list. Moving the interface behind SBI has three consequences:

• Portability. A board with compliant firmware gets a working watchdog on any kernel new enough to carry the driver. The same binary kernel image can serve boards whose watchdogs live in entirely different silicon.
• Single place to fix bugs. Timeout arithmetic and error translation live in one driver, not in a dozen vendor copies.
• Firmware becomes the safety boundary. The actual timer, its clock domain and its reset behavior stay under M-mode control, which matches how functional-safety platforms already treat watchdogs.

The trade-off is a hard dependency on firmware that does not exist everywhere yet. The RFC status also means the ABI is not settled: the ecall IDs and attribute enumerations live in a shared header, so any change on the OpenSBI side has to stay in lockstep with the kernel. And on boards whose firmware predates SBI 3.0, the driver simply declines to load — those platforms keep their existing SoC watchdog drivers.

Where This Fits With the Rest of the RISC-V Firmware Surface

The SBI watchdog RFC lands in a busy season for the RISC-V firmware/OS boundary: the gtrace hardware-trace framework (also posted this month), RISC-V IOMMU v6 with IMSIC MSI remapping for VFIO, and the K3's mainline bring-up where OpenSBI platform support has been advancing patch by patch. The common thread: RISC-V is pushing more platform functionality behind standardized firmware interfaces — RFENCE, SSE, PMU, now a watchdog — so that OS support scales across vendors without N per-SoC drivers.

• Related reading: OpenSBI K3 platform support · gtrace hardware-trace framework · RISC-V IOMMU v6 MSI remapping · Xen boots on the K3