linux-kernel - Re: [PATCH v2 1/2] dt-bindings: watchdog: Add NXP Software Watchdog Timer

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: <abbebdd6-a097-1442-70c7-d5b765568669@oss.nxp.com>
Date: Mon, 7 Apr 2025 07:53:11 +0300
From: Ghennadi Procopciuc <ghennadi.procopciuc@....nxp.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>, wim@...ux-watchdog.org
Cc: linux@...ck-us.net, linux-watchdog@...r.kernel.org,
 linux-kernel@...r.kernel.org, S32@....com, ghennadi.procopciuc@....com,
 thomas.fossati@...aro.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, devicetree@...r.kernel.org,
 Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: watchdog: Add NXP Software Watchdog
 Timer

On 4/6/2025 11:33 PM, Daniel Lezcano wrote:
> On 04/04/2025 08:35, Ghennadi Procopciuc wrote:
>> On 4/3/2025 6:10 PM, Daniel Lezcano wrote:
>>> On 03/04/2025 08:19, Ghennadi Procopciuc wrote:
>>>> On 4/2/2025 6:49 PM, Daniel Lezcano wrote:
>>>> [ ... ]
>>>>> +examples:
>>>>> +  - |
>>>>> +    watchdog@...0100000 {
>>>>> +        compatible = "nxp,s32g2-swt";
>>>>> +        reg = <0x40100000 0x1000>;
>>>>> +        clocks = <&clks 0x3a>;
>>>>> +        timeout-sec = <10>;
>>>>> +    };
>>>>
>>>> The S32G reference manual specifies two clocks for the SWT module: one
>>>> for the registers and another for the counter itself. Shouldn't both
>>>> clocks be represented in the bindings?
>>>
>>> AFAICS, there are two clocks as described in the documentation for the
>>> s32g2 page 846, section 23.7.3.3 SWT clocking.
>>
>> This diagram illustrates the module clocks and their connections to the
>> S32GS system clocks. From the module's perspective, there are three
>> clocks: MODULE_CLOCK, REG_INTF, and COUNTER_CLOCK. Specifically, on
>> S32G2 SoCs, the first two are connected to XBAR_DIV3_CLK, while the
>> counter clock is linked to FIRC_CLK. Based on my understanding of the
>> device tree, this configuration should be listed as follows:
>>
>> clocks = <&clks XBAR_DIV3_CLK>, <&clks XBAR_DIV3_CLK>, <&clks FIRC_CLK>;
>> clock-names = "module", "reg", "counter";
>>
>> Configuring it this way allows flexibility to reuse the same clocking
>> scheme for other SoCs where the integration is performed differently. It
>> is possible that the 'module' and 'reg' clocks could be linked to two
>> distinct system clocks.
> 
> That is something we can handle when the other SoC will be in the
> process of being upstream, no ?
> 
> I don't see how that can help with the current hardware we are
> describing. What is the benefit ?
> 

The benefit is that the binding accurately describes the hardware
module, and no changes are expected in this area over time, even if
different integrations of the module are performed on other SoCs.

Otherwise, the binding will contain a different set of clocks depending
on the SoC integration, even though the exact same hardware IP is used.

> I would prefer to stick to what is needed today
> 
>>> The module and the register clock are fed by the XBAR_DIV3_CLK which is
>>> an system clock always-on.
>>
>> XBAR_DIV3_CLK is not an always-on clock, meaning it is not available
>> during suspend, if that is what you mean by always-on. The SIRC can be
>> considered the only always-on clock on this device.
>>
>>>
>>> The counter is fed by the FIRC_CLK which described as "FIRC_CLK is the
>>> default clock for the entire system at power-up."
>>>
>>>  From my understanding, we should not describe the XBAR_DIV3_CLK as
>>> it is
>>> a system clock.
>>>
>>> And the FIRC_CLK is only there to get the clock rate in the driver.
>>>
>>
> 
> 

-- 
Regards,
Ghennadi