mbox series

[v3,0/2] Add the NXP S32 Watchdog

Message ID 20250407160318.936142-1-daniel.lezcano@linaro.org
Headers show
Series Add the NXP S32 Watchdog | expand

Message

Daniel Lezcano April 7, 2025, 4:03 p.m. UTC
The NXP S32 watchdog, referenced in the documentation as the Software
Watchdog Timer is actually a hardware watchdog. The system has one
watchdog per core but an assertation does not directly reset the
system as this behavior relies on a particular setup and another
component which is not part of these changes. However the first
watchdog on the system, tied with the Cortex-M4 #0 is a particular
case where it will reset the system directly. This is enough for the
watchdog purpose on Linux.

The watchdog relies on the default timeout described in the device
tree but if another timeout is needed at boot time, it can be changed
with the module parameter.

If the kernel has to service the watchdog in place of the userspace,
it can specify the 'early-enable' option at boot time.

And finally, if starting the watchdog has no wayback then the option
'nowayout' can be also specified in the boot option.

Changelog:

 - v3:
    - Add the clocks for the module and the register (Ghennadi Procopciuc)
    - Use the clock name from the driver
    - Removed Review-by tag from Krzysztof Kozlowski as the bindings changed

 - v2:
    - Removed debugfs code as considered pointless for a such simple
      driver (Arnd Bergmann)
    - Replaced __raw_readl / __raw_writel by readl and writel (Arnd Bergmann)
    - Reordered alphabetically the headers (Guenter Roeck)
    - Enclosed macro parameter into parenthesis (Guenter Roeck)
    - Fixed checkpatch reported errors (Guenter Roeck)
    - Clarified a ping on a stopped timer does not affect it (Guenter Roeck)
    - Used wdt_is_running() to save an extra IO (Guenter Roeck)
    - Fixed a misleading comment about starting the watchdog at boot time (Guenter Roeck)
    - Replaced allocation size sizeof(struct ...) by sizeof(*var) (Krzysztof Kozlowski)
    - Drop old way of describing the module and use table module device (Krzysztof Kozlowski)
    - Replaced additionalProperties by unevaluatedProperties (Rob Herring)
    - Removed the DT bindings description as it is obvious (Ghennadi Procopciuc)
    - Fixed DT bindings compatible string (Krzysztof Kozlowski)

 - v1: initial posting


Daniel Lezcano (2):
  dt-bindings: watchdog: Add NXP Software Watchdog Timer
  watchdog: Add the Watchdog Timer for the NXP S32 platform

 .../bindings/watchdog/nxp,s32g2-swt.yaml      |  56 ++++
 drivers/watchdog/Kconfig                      |   9 +
 drivers/watchdog/Makefile                     |   1 +
 drivers/watchdog/s32g_wdt.c                   | 313 ++++++++++++++++++
 4 files changed, 379 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml
 create mode 100644 drivers/watchdog/s32g_wdt.c

Comments

Krzysztof Kozlowski April 8, 2025, 8:21 a.m. UTC | #1
On 07/04/2025 18:03, Daniel Lezcano wrote:
> +
> +allOf:
> +  - $ref: watchdog.yaml#
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: nxp,s32g2-swt
> +      - items:
> +          - const: nxp,s32g3-swt
> +          - const: nxp,s32g2-swt
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: Counter clock
> +      - description: Module clock
> +      - description: Register clock
> +    minItems: 1

Why clocks are flexible? The SoC does not change between boards. It
should be a fixed list - block receives that number of clocks or does
not... unless you meant that different instances of the block have
different clocks?

Best regards,
Krzysztof
Daniel Lezcano April 8, 2025, 9:03 a.m. UTC | #2
On 08/04/2025 10:21, Krzysztof Kozlowski wrote:
> On 07/04/2025 18:03, Daniel Lezcano wrote:
>> +
>> +allOf:
>> +  - $ref: watchdog.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - const: nxp,s32g2-swt
>> +      - items:
>> +          - const: nxp,s32g3-swt
>> +          - const: nxp,s32g2-swt
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    items:
>> +      - description: Counter clock
>> +      - description: Module clock
>> +      - description: Register clock
>> +    minItems: 1
> 
> Why clocks are flexible? The SoC does not change between boards. It
> should be a fixed list - block receives that number of clocks or does
> not... unless you meant that different instances of the block have
> different clocks?

The documentation describe the watchdog module with a clock for the 
counter, a clock for the register and the last one for the module.

IIUC, these clocks are enabled when the system is powered-on or exits 
suspend.

The driver does not have a control on them.

The only usage of the clock is to retrieve the rate of the counter in 
order to compute the maximum timeout. So only one is needed.

However Ghennadi would like to describe the register and the module 
clocks in case there is SoC variant where it is possible to have control 
on them [1]

The goal is to give the description the flexibility to describe just one 
because the other ones are not needed for this s32g2/3 platform.


[1] 
https://lore.kernel.org/all/93d83df2-d3bc-e32d-70a6-158571504275@oss.nxp.com/
Krzysztof Kozlowski April 8, 2025, 9:39 a.m. UTC | #3
On 08/04/2025 11:03, Daniel Lezcano wrote:
> On 08/04/2025 10:21, Krzysztof Kozlowski wrote:
>> On 07/04/2025 18:03, Daniel Lezcano wrote:
>>> +
>>> +allOf:
>>> +  - $ref: watchdog.yaml#
>>> +
>>> +properties:
>>> +  compatible:
>>> +    oneOf:
>>> +      - const: nxp,s32g2-swt
>>> +      - items:
>>> +          - const: nxp,s32g3-swt
>>> +          - const: nxp,s32g2-swt
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  clocks:
>>> +    items:
>>> +      - description: Counter clock
>>> +      - description: Module clock
>>> +      - description: Register clock
>>> +    minItems: 1
>>
>> Why clocks are flexible? The SoC does not change between boards. It
>> should be a fixed list - block receives that number of clocks or does
>> not... unless you meant that different instances of the block have
>> different clocks?
> 
> The documentation describe the watchdog module with a clock for the 
> counter, a clock for the register and the last one for the module.
> 
> IIUC, these clocks are enabled when the system is powered-on or exits 
> suspend.
> 
> The driver does not have a control on them.
> 
> The only usage of the clock is to retrieve the rate of the counter in 
> order to compute the maximum timeout. So only one is needed.
> 
> However Ghennadi would like to describe the register and the module 
> clocks in case there is SoC variant where it is possible to have control 
> on them [1]

Different SoC means different compatible, so I don't get why this is
relevant here. Either these clocks inputs are there in the hardware or not.

> 
> The goal is to give the description the flexibility to describe just one 
> because the other ones are not needed for this s32g2/3 platform.

But bindings are not meant to be flexible but accurately describe the
hardware. If hardware always has these clock inputs, then they are
supposed to be always provided.


Best regards,
Krzysztof
Ghennadi Procopciuc April 8, 2025, 10:30 a.m. UTC | #4
On 4/8/2025 12:39 PM, Krzysztof Kozlowski wrote:
> On 08/04/2025 11:03, Daniel Lezcano wrote:
>> On 08/04/2025 10:21, Krzysztof Kozlowski wrote:
>>> On 07/04/2025 18:03, Daniel Lezcano wrote:
>>>> +
>>>> +allOf:
>>>> +  - $ref: watchdog.yaml#
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - const: nxp,s32g2-swt
>>>> +      - items:
>>>> +          - const: nxp,s32g3-swt
>>>> +          - const: nxp,s32g2-swt
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    items:
>>>> +      - description: Counter clock
>>>> +      - description: Module clock
>>>> +      - description: Register clock
>>>> +    minItems: 1
>>>
>>> Why clocks are flexible? The SoC does not change between boards. It
>>> should be a fixed list - block receives that number of clocks or does
>>> not... unless you meant that different instances of the block have
>>> different clocks?
>>
>> The documentation describe the watchdog module with a clock for the 
>> counter, a clock for the register and the last one for the module.
>>
>> IIUC, these clocks are enabled when the system is powered-on or exits 
>> suspend.
>>
>> The driver does not have a control on them.
>>
>> The only usage of the clock is to retrieve the rate of the counter in 
>> order to compute the maximum timeout. So only one is needed.
>>
>> However Ghennadi would like to describe the register and the module 
>> clocks in case there is SoC variant where it is possible to have control 
>> on them [1]
> 
> Different SoC means different compatible, so I don't get why this is
> relevant here. Either these clocks inputs are there in the hardware or not.
> 
>>
>> The goal is to give the description the flexibility to describe just one 
>> because the other ones are not needed for this s32g2/3 platform.
> 
> But bindings are not meant to be flexible but accurately describe the
> hardware. If hardware always has these clock inputs, then they are
> supposed to be always provided.
> 

Indeed, as mentioned in my previous replies, the SWT hardware module has
three clocks as inputs: counter, module, and register.

> 
> Best regards,
> Krzysztof
> 
>