linux-kernel - Re: [PATCH v2] clocksource: timer-tegra186: Enable WDT at probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fc2956c4-4b09-4573-abcc-df5258488e6d@linaro.org>
Date: Tue, 8 Jul 2025 16:10:41 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Jon Hunter <jonathanh@...dia.com>,
 Thierry Reding <thierry.reding@...il.com>
Cc: Kartik Rajput <kkartik@...dia.com>, tglx@...utronix.de,
 linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v2] clocksource: timer-tegra186: Enable WDT at probe

On 08/07/2025 13:42, Jon Hunter wrote:
> 
> On 08/07/2025 12:22, Thierry Reding wrote:
>> On Tue, Jul 08, 2025 at 12:03:52AM +0200, Daniel Lezcano wrote:
>>> On 07/07/2025 23:19, Jon Hunter wrote:
>>>>
>>>> On 07/07/2025 10:51, Daniel Lezcano wrote:
>>>>> On Thu, Jul 03, 2025 at 04:34:15PM +0530, Kartik Rajput wrote:
>>>>>> Currently, if the system crashes or hangs during kernel boot before
>>>>>> userspace initializes and configures the watchdog timer, then the
>>>>>> watchdog won’t be able to recover the system as it’s not running. 
>>>>>> This
>>>>>> becomes crucial during an over-the-air update, where if the newly
>>>>>> updated kernel crashes on boot, the watchdog is needed to reset the
>>>>>> device and boot into an alternative system partition. If the watchdog
>>>>>> is disabled in such scenarios, it can lead to the system getting
>>>>>> bricked.
>>>>>>
>>>>>> Enable the WDT during driver probe to allow recovery from any 
>>>>>> crash/hang
>>>>>> seen during early kernel boot. Also, disable interrupts once 
>>>>>> userspace
>>>>>> starts pinging the watchdog.
>>>>>
>>>>> Please resend with proper recipients (linux-watchdog@, Wim Van
>>>>> Sebroeck, Guenter Roeck) and the changelog.
>>>>
>>>> ACK.
>>>>
>>>>> Can someone take the opportunity to split this watchdog code and move
>>>>> it in the proper watchdog drivers directory ?
>>>>
>>>> I understand that this was mentioned before, but Thierry previously
>>>> objected to this for this particular driver [0].
>>>
>>> Yes but meanwhile we found that the auxiliary device is designed for 
>>> this
>>> situation.
>>
>> Honestly, adding auxiliary bus into the mix is total overkill here. I
>> always thought with all the tools we have today it'd be easy enough to
>> have drivers spread across subsystems if that's what's best.
>>
>> But if y'all think this is the way, then sure, we'll do that.
> 
> 
> Yes we are happy to conform to whatever is preferred. However, this is 
> really a fix and IMO outside the scope of any refactoring work. I have 
> been pushing the necessary people at NVIDIA to get fixes upstream so 
> that any known issues are fixed. Hence, I would prefer to handle the 
> refactoring separately.


Yes, absolutely


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog