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] [thread-next>] [day] [month] [year] [list]

Message-ID: <031fd310-f484-488e-a6e3-88802f42d821@nvidia.com>
Date: Tue, 8 Jul 2025 12:42:26 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Thierry Reding <thierry.reding@...il.com>,
 Daniel Lezcano <daniel.lezcano@...aro.org>
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 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.

Thanks!
Jon

-- 
nvpublic