On 09.02.2026 17:52, Oleksii Kurochko wrote: > Implement reprogram_timer() on RISC-V using the standard SBI timer call. > > The privileged architecture only defines machine-mode timer interrupts > (using mtime/mtimecmp). Therefore, timer services for S/HS/VS mode must > be provided by M-mode via SBI calls. SSTC (Supervisor-mode Timer Control) > is optional and is not supported on the boards available to me, so the > only viable approach today is to program the timer through SBI. > > reprogram_timer() enables/disables the supervisor timer interrupt and > programs the next timer deadline using sbi_set_timer(). If the SBI call > fails, the code panics, because sbi_set_timer() is expected to return > either 0 or -ENOSUPP (this has been stable from early OpenSBI versions to > the latest ones). The SBI spec does not define a standard negative error > code for this call, and without SSTC there is no alternative method to > program the timer, so the SBI timer call must be available. > > reprogram_timer() currently returns int for compatibility with the > existing prototype. While it might be cleaner to return bool, keeping the > existing signature avoids premature changes in case sbi_set_timer() ever > needs to return other values (based on which we could try to avoid > panic-ing) in the future. > > Signed-off-by: Oleksii Kurochko <[email protected]>
Acked-by: Jan Beulich <[email protected]> > --- > Changes in v3: > - Correct the comments in reprogram_timer(). > - Move enablement of timer interrupt after sbi_set_timer() to avoid > potentially receiving a timer interrupt between these 2 operations. I'd like to mention that this is of only hypothetical concern, at least for the sole caller in common code: That's doing the call with IRQs off, so only the bit in SIP could become set too early, while no IRQ would surface before timer_softirq_action() turns IRQs on again. (This isn't to say that it wasn't a good thing to adjust the order.) Jan
