linux-kernel - Re: [PATCHv4 3/4] watchdog: rti-wdt: attach to running watchdog during 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: <c96bffda-73bc-0cdf-c77a-39d57abe1a95@ti.com>
Date:   Mon, 21 Feb 2022 10:29:20 -0600
From:   Hari Nagalla <hnagalla@...com>
To:     Jan Kiszka <jan.kiszka@...mens.com>, Nishanth Menon <nm@...com>
CC:     <wim@...ux-watchdog.org>, <linux@...ck-us.net>,
        <linux-watchdog@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv4 3/4] watchdog: rti-wdt: attach to running watchdog
 during probe

On 2/21/22 10:03, Jan Kiszka wrote:
>> K, so we do want a safety margin for min_hw_heartbeat_ms, make it
>> larger. But I still don't think it is best achieved by bending the
>> frequency. That will also affect other values, e.g. returning a wrong
>> programmed timeout to userspace if that was programmed earlier, using
>> the original frequency.
>>
> I think I'm starting to get the original logic, and the result now works
> here:
> 
> The clock driving the watchdog might be slower than thought, and then we
> may time out later than intended - generally not an issue. But it may
> also be faster, and then we will see an expiry earlier than what is
> supposed to be configured via "heartbeat". For the latter case, we lower
> the frequency virtually by 10%, crossing fingers that this is enough.
> 
Humm.. To me it appears the intent is to adjust when the input 32KHz 
clock is slower? when it is slower we reduce the pulse count by 10% 
(assuming the crystals are with 10% off clock) so that the desired 
timeout is achieved with lesser pulse count?
> The problems are now:
>   - U-Boot (as a known early watchdog starter) does not do that as well,
>     and we will cause at least confusion on Linux side (60s will become
>     66s from Linux POV e.g., and we may expire at 54s already)
>      => U-Boot should add the same 10%, patch will be sent
Yes, i see that we need similar adjustment in u-boot as well.
>   - even with U-Boot on the same page, the rounding issue will prevent
>     accurate calculations of derived values, namely min_hw_heartbeat_ms.
>      => patch to come
>   - and ...
>