Re: [PATCH 3/3] arm: dts: ti: omap: Prevent watchdog from being reset on kernel boot

[Diogo Ivo <diogo.ivo@bootlin.com>]

On 9/11/26 11:30 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The patch exposes the system to unexpected reboots due to a 30-second window before the watchdog is idled, contrary to the '3 second window' claimed in the commit message.
> --
> 
> commit 1abe23cd5472149baeeab9af481deaf65caccd1f
> Author: Diogo Ivo <diogo.ivo@bootlin.com>
> Subject: arm: dts: ti: omap: Prevent watchdog from being reset on kernel boot
> 
> This commit prevents the watchdog from being reset and idled during kernel
> boot by adding the ti,no-reset-on-init property to the target-module node.
> This is intended to provide a 3-second window for the watchdog driver to
> probe without resetting the watchdog.
> 
>> diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
>> index 4c78a0b28fab3..e061ea3fc8e70 100644
>> --- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
>> +++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
>> @@ -1126,6 +1126,7 @@ target-module@4000 {			/* 0x4a314000, ap 7 18.0 */
>>   					<SYSC_IDLE_SMART>,
>>   					<SYSC_IDLE_SMART_WKUP>;
>>   			ti,syss-mask = <1>;
>> +			ti,no-reset-on-init;
> 
> [Severity: High]
> Does adding this property unintentionally cause a regression where the system
> experiences unexpected reboots due to a 30-second delay instead of the
> intended 3-second window?
> 
> Adding ti,no-reset-on-init skips the immediate hardware reset and triggers the
> delayed work fallback in sysc_probe():
> 
> drivers/bus/ti-sysc.c:sysc_probe() {
>      ...
>      schedule_delayed_work(&ddata->idle_work, 3000);
>      ...
> }
> 
> Because schedule_delayed_work() takes its delay in jiffies rather than
> milliseconds, passing 3000 evaluates to 3000 jiffies. On typical ARM
> configurations where HZ=100 (the default), this results in a 30-second delay
> instead of the expected 3 seconds.
> 
> This could lead to a boot loop if the bootloader configures a watchdog timeout
> of less than 30 seconds and the system relies on the driver to stop it.

This is a valid point that I am not sure how to solve. I could change
the hardcoded 3000 but I don't know if that is the way to go. Any help
would be greatly appreciated.

Diogo