[PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Sander Vanheule]

Like for the GPIO hardware of the Realtek Otto platform, add a fallback
compatible for the watchdog hardware.

For backward compatibility, the binding will still allow current
single-compatible devicetrees to work, but new devicetrees, including
new compatibles, should use a two-component compatible.

This series serves to address comments regarding the device compatibles
for the patches adding RTL9607C watchdog support [1].

[1] https://lore.kernel.org/lkml/20260509163101.722793-1-adilov@disroot.org/

Sander Vanheule (2):
  dt-bindings: watchdog: realtek,otto-wdt: Add fallback compatible
  watchdog: realtek-otto: add fallback compatible

 .../bindings/watchdog/realtek,otto-wdt.yaml   | 22 ++++++++++++++-----
 drivers/watchdog/realtek_otto_wdt.c           |  2 ++
 2 files changed, 18 insertions(+), 6 deletions(-)

-- 
2.54.0

[PATCH v2 1/2] dt-bindings: watchdog: realtek,otto-wdt: Add fallback compatible

[Sander Vanheule]

As all known hardware instantiations of this watchdog behave the same, a
fallback compatible can be added.

To remain compatible with existing single-compatible bindings, the
current compatibles are duplicated. New compatibles should only be added
to the list with fallback.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
---
Changes since v1:
- Fix indendations
- Add deprecated property to old compatible
- Use two-part compatible in example
---
 .../bindings/watchdog/realtek,otto-wdt.yaml   | 22 ++++++++++++++-----
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
index 1f5390a67cdb..e470e0fcbb2a 100644
--- a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
@@ -25,11 +25,21 @@ allOf:
 
 properties:
   compatible:
-    enum:
-      - realtek,rtl8380-wdt
-      - realtek,rtl8390-wdt
-      - realtek,rtl9300-wdt
-      - realtek,rtl9310-wdt
+    oneOf:
+      - items:
+          - enum:
+              - realtek,rtl8380-wdt
+              - realtek,rtl8390-wdt
+              - realtek,rtl9300-wdt
+              - realtek,rtl9310-wdt
+          - const: realtek,otto-wdt
+      # Legacy without fallback, do not extend
+      - deprecated: true
+        enum:
+          - realtek,rtl8380-wdt
+          - realtek,rtl8390-wdt
+          - realtek,rtl9300-wdt
+          - realtek,rtl9310-wdt
 
   reg:
     maxItems: 1
@@ -74,7 +84,7 @@ unevaluatedProperties: false
 examples:
   - |
     watchdog: watchdog@3150 {
-        compatible = "realtek,rtl8380-wdt";
+        compatible = "realtek,rtl8380-wdt", "realtek,otto-wdt";
         reg = <0x3150 0xc>;
 
         realtek,reset-mode = "soc";
-- 
2.54.0

[PATCH v2 2/2] watchdog: realtek-otto: add fallback compatible

[Sander Vanheule]

As the binding now supports a fallback compatible for (new) devicetrees,
let's add it to the list of supported compatibles. If new compatibles
are added to the binding, driver updates may no longer be required.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
---
 drivers/watchdog/realtek_otto_wdt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/watchdog/realtek_otto_wdt.c b/drivers/watchdog/realtek_otto_wdt.c
index 2c30ddd574c5..b4eb2f87f991 100644
--- a/drivers/watchdog/realtek_otto_wdt.c
+++ b/drivers/watchdog/realtek_otto_wdt.c
@@ -350,6 +350,8 @@ static int otto_wdt_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id otto_wdt_ids[] = {
+	{ .compatible = "realtek,otto-wdt" },
+	/* Legacy bindings without fallback compatible */
 	{ .compatible = "realtek,rtl8380-wdt" },
 	{ .compatible = "realtek,rtl8390-wdt" },
 	{ .compatible = "realtek,rtl9300-wdt" },
-- 
2.54.0

Re: [PATCH v2 1/2] dt-bindings: watchdog: realtek,otto-wdt: Add fallback compatible

[Guenter Roeck]

On Tue, May 12, 2026 at 10:48:53PM +0200, Sander Vanheule wrote:
> As all known hardware instantiations of this watchdog behave the same, a
> fallback compatible can be added.
> 
> To remain compatible with existing single-compatible bindings, the
> current compatibles are duplicated. New compatibles should only be added
> to the list with fallback.
> 
> Signed-off-by: Sander Vanheule <sander@svanheule.net>
> ---
> Changes since v1:
> - Fix indendations
> - Add deprecated property to old compatible
> - Use two-part compatible in example
> ---
>  .../bindings/watchdog/realtek,otto-wdt.yaml   | 22 ++++++++++++++-----
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
> index 1f5390a67cdb..e470e0fcbb2a 100644
> --- a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
> @@ -25,11 +25,21 @@ allOf:
>  
>  properties:
>    compatible:
> -    enum:
> -      - realtek,rtl8380-wdt
> -      - realtek,rtl8390-wdt
> -      - realtek,rtl9300-wdt
> -      - realtek,rtl9310-wdt
> +    oneOf:
> +      - items:
> +          - enum:
> +              - realtek,rtl8380-wdt
> +              - realtek,rtl8390-wdt
> +              - realtek,rtl9300-wdt
> +              - realtek,rtl9310-wdt
> +          - const: realtek,otto-wdt

For the Apple watchdog driver, the generic property "apple,wdt" is
considered to be bad and is not supposed to be used for newer chips.
For this watchdog driver, a generic property is introduced.

What is the overall logic ? Is there some rule when a generic property
such as "realtek,otto-wdt" is appropriate and preferred, and when it isn't
(as in "apple,wdt") ?

Thanks,
Guenter

Re: [PATCH v2 1/2] dt-bindings: watchdog: realtek,otto-wdt: Add fallback compatible

[Rob Herring]

On Wed, May 13, 2026 at 05:20:59PM -0700, Guenter Roeck wrote:
> On Tue, May 12, 2026 at 10:48:53PM +0200, Sander Vanheule wrote:
> > As all known hardware instantiations of this watchdog behave the same, a
> > fallback compatible can be added.
> > 
> > To remain compatible with existing single-compatible bindings, the
> > current compatibles are duplicated. New compatibles should only be added
> > to the list with fallback.
> > 
> > Signed-off-by: Sander Vanheule <sander@svanheule.net>
> > ---
> > Changes since v1:
> > - Fix indendations
> > - Add deprecated property to old compatible
> > - Use two-part compatible in example
> > ---
> >  .../bindings/watchdog/realtek,otto-wdt.yaml   | 22 ++++++++++++++-----
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
> > index 1f5390a67cdb..e470e0fcbb2a 100644
> > --- a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
> > +++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
> > @@ -25,11 +25,21 @@ allOf:
> >  
> >  properties:
> >    compatible:
> > -    enum:
> > -      - realtek,rtl8380-wdt
> > -      - realtek,rtl8390-wdt
> > -      - realtek,rtl9300-wdt
> > -      - realtek,rtl9310-wdt
> > +    oneOf:
> > +      - items:
> > +          - enum:
> > +              - realtek,rtl8380-wdt
> > +              - realtek,rtl8390-wdt
> > +              - realtek,rtl9300-wdt
> > +              - realtek,rtl9310-wdt
> > +          - const: realtek,otto-wdt
> 
> For the Apple watchdog driver, the generic property "apple,wdt" is
> considered to be bad and is not supposed to be used for newer chips.
> For this watchdog driver, a generic property is introduced.
> 
> What is the overall logic ? Is there some rule when a generic property
> such as "realtek,otto-wdt" is appropriate and preferred, and when it isn't
> (as in "apple,wdt") ?

Never preferred. Retroactively adding them, that's a definite no.

Rob

Re: [PATCH v2 1/2] dt-bindings: watchdog: realtek,otto-wdt: Add fallback compatible

[Krzysztof Kozlowski]

On 14/05/2026 02:20, Guenter Roeck wrote:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - realtek,rtl8380-wdt
>> +              - realtek,rtl8390-wdt
>> +              - realtek,rtl9300-wdt
>> +              - realtek,rtl9310-wdt
>> +          - const: realtek,otto-wdt
> 
> For the Apple watchdog driver, the generic property "apple,wdt" is
> considered to be bad and is not supposed to be used for newer chips.
> For this watchdog driver, a generic property is introduced.
> 
> What is the overall logic ? Is there some rule when a generic property
> such as "realtek,otto-wdt" is appropriate and preferred, and when it isn't
> (as in "apple,wdt") ?

Except what Rob said, it is also documented:

https://elixir.bootlin.com/linux/v7.1-rc3/source/Documentation/devicetree/bindings/writing-bindings.rst#L60

Best regards,
Krzysztof

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Rob Herring]

On Tue, May 12, 2026 at 10:48:52PM +0200, Sander Vanheule wrote:
> Like for the GPIO hardware of the Realtek Otto platform, add a fallback
> compatible for the watchdog hardware.
> 
> For backward compatibility, the binding will still allow current
> single-compatible devicetrees to work, but new devicetrees, including
> new compatibles, should use a two-component compatible.
> 
> This series serves to address comments regarding the device compatibles
> for the patches adding RTL9607C watchdog support [1].
> 
> [1] https://lore.kernel.org/lkml/20260509163101.722793-1-adilov@disroot.org/

You misunderstood the discussion (though some came after this). The 
fallback should be one of the existing compatibles (the oldest one), so 
there are no driver changes needed for the OS. Creating a new fallback 
completely misses that point.

Rob

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Sander Vanheule]

On Thu, 2026-05-14 at 11:10 -0500, Rob Herring wrote:
> On Tue, May 12, 2026 at 10:48:52PM +0200, Sander Vanheule wrote:
> > Like for the GPIO hardware of the Realtek Otto platform, add a fallback
> > compatible for the watchdog hardware.
> > 
> > For backward compatibility, the binding will still allow current
> > single-compatible devicetrees to work, but new devicetrees, including
> > new compatibles, should use a two-component compatible.
> > 
> > This series serves to address comments regarding the device compatibles
> > for the patches adding RTL9607C watchdog support [1].
> > 
> > [1] https://lore.kernel.org/lkml/20260509163101.722793-1-adilov@disroot.org/
> 
> You misunderstood the discussion (though some came after this). The 
> fallback should be one of the existing compatibles (the oldest one), so 
> there are no driver changes needed for the OS. Creating a new fallback 
> completely misses that point.

Using a SoC-specific compatible would mean we should go for something like:
	compatible = "realtek,rtl9706c-wdt", "realtek,rtl8380-wdt";

Then that means we can never change our interpretation of how the rtl8380
behaves (we don't have datasheets), because it would also impact the behavior of
the rtl9706c.

I also think "apple,wdt" is a bad example to compare with "realtek,otto-wdt".
The former only specifies the vendor, while the latter refers to the line of
SoCs this IP block is used for. Although I see the docs also discourage family
compatibles.

If I may ask, what is the rationale for preferring the "older implementation"
approach over a "family compatible" to match the common subset of supported
features?

Best,
Sander

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Rob Herring]

On Thu, May 14, 2026 at 11:25 AM Sander Vanheule <sander@svanheule.net> wrote:
>
> On Thu, 2026-05-14 at 11:10 -0500, Rob Herring wrote:
> > On Tue, May 12, 2026 at 10:48:52PM +0200, Sander Vanheule wrote:
> > > Like for the GPIO hardware of the Realtek Otto platform, add a fallback
> > > compatible for the watchdog hardware.
> > >
> > > For backward compatibility, the binding will still allow current
> > > single-compatible devicetrees to work, but new devicetrees, including
> > > new compatibles, should use a two-component compatible.
> > >
> > > This series serves to address comments regarding the device compatibles
> > > for the patches adding RTL9607C watchdog support [1].
> > >
> > > [1] https://lore.kernel.org/lkml/20260509163101.722793-1-adilov@disroot.org/
> >
> > You misunderstood the discussion (though some came after this). The
> > fallback should be one of the existing compatibles (the oldest one), so
> > there are no driver changes needed for the OS. Creating a new fallback
> > completely misses that point.
>
> Using a SoC-specific compatible would mean we should go for something like:
>         compatible = "realtek,rtl9706c-wdt", "realtek,rtl8380-wdt";
>
> Then that means we can never change our interpretation of how the rtl8380
> behaves (we don't have datasheets), because it would also impact the behavior of
> the rtl9706c.

No, at that point you would add the rtl9706c compatible to the driver
to distinguish.

You have the same constraint with your generic compatible.

> I also think "apple,wdt" is a bad example to compare with "realtek,otto-wdt".
> The former only specifies the vendor, while the latter refers to the line of
> SoCs this IP block is used for. Although I see the docs also discourage family
> compatibles.

Is M1, M2, M3 not a family? Maybe A series is included too, but if
there's anyone that maintains some consistency across SoCs, it is
Apple.

The docs are based on experience and regret...

>
> If I may ask, what is the rationale for preferring the "older implementation"
> approach over a "family compatible" to match the common subset of supported
> features?

If you create bindings as the SoCs are created, then you don't really
know what's in a family, only does it work with the existing driver .
You only know what's in a family after the fact. Things are never that
clean either.

I just picked the oldest as that's probably the most well known, least
likely to need some future change, and would have the oldest OS
version support.

Rob

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Sander Vanheule]

Hi Rob,

On Thu, 2026-05-14 at 15:57 -0500, Rob Herring wrote:
> On Thu, May 14, 2026 at 11:25 AM Sander Vanheule <sander@svanheule.net> wrote:
> > 
> > On Thu, 2026-05-14 at 11:10 -0500, Rob Herring wrote:
> > > On Tue, May 12, 2026 at 10:48:52PM +0200, Sander Vanheule wrote:
> > > > Like for the GPIO hardware of the Realtek Otto platform, add a fallback
> > > > compatible for the watchdog hardware.
> > > > 
> > > > For backward compatibility, the binding will still allow current
> > > > single-compatible devicetrees to work, but new devicetrees, including
> > > > new compatibles, should use a two-component compatible.
> > > > 
> > > > This series serves to address comments regarding the device compatibles
> > > > for the patches adding RTL9607C watchdog support [1].
> > > > 
> > > > [1]
> > > > https://lore.kernel.org/lkml/20260509163101.722793-1-adilov@disroot.org/
> > > 
> > > You misunderstood the discussion (though some came after this). The
> > > fallback should be one of the existing compatibles (the oldest one), so
> > > there are no driver changes needed for the OS. Creating a new fallback
> > > completely misses that point.
> > 
> > Using a SoC-specific compatible would mean we should go for something like:
> >         compatible = "realtek,rtl9706c-wdt", "realtek,rtl8380-wdt";
> > 
> > Then that means we can never change our interpretation of how the rtl8380
> > behaves (we don't have datasheets), because it would also impact the
> > behavior of
> > the rtl9706c.
> 
> No, at that point you would add the rtl9706c compatible to the driver
> to distinguish.
> 
> You have the same constraint with your generic compatible.
> 
> > I also think "apple,wdt" is a bad example to compare with "realtek,otto-
> > wdt".
> > The former only specifies the vendor, while the latter refers to the line of
> > SoCs this IP block is used for. Although I see the docs also discourage
> > family
> > compatibles.
> 
> Is M1, M2, M3 not a family? Maybe A series is included too, but if
> there's anyone that maintains some consistency across SoCs, it is
> Apple.
> 
> The docs are based on experience and regret...
> 
> > 
> > If I may ask, what is the rationale for preferring the "older
> > implementation"
> > approach over a "family compatible" to match the common subset of supported
> > features?
> 
> If you create bindings as the SoCs are created, then you don't really
> know what's in a family, only does it work with the existing driver .
> You only know what's in a family after the fact. Things are never that
> clean either.
> 
> I just picked the oldest as that's probably the most well known, least
> likely to need some future change, and would have the oldest OS
> version support.

Thanks for the extra context.

Rustam, will you take it from here to add the two-part compatible for the
RTL9706C? Since you won't need update the driver, I guess a single patch would
do.


Best,
Sander

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Rustam Adilov]

Hello Sander,
On 2026-05-15 08:47, Sander Vanheule wrote:
> Hi Rob,
> 
> On Thu, 2026-05-14 at 15:57 -0500, Rob Herring wrote:
>> On Thu, May 14, 2026 at 11:25 AM Sander Vanheule <sander@svanheule.net> wrote:
>> > 
>> > On Thu, 2026-05-14 at 11:10 -0500, Rob Herring wrote:
>> > > On Tue, May 12, 2026 at 10:48:52PM +0200, Sander Vanheule wrote:
>> > > > Like for the GPIO hardware of the Realtek Otto platform, add a fallback
>> > > > compatible for the watchdog hardware.
>> > > > 
>> > > > For backward compatibility, the binding will still allow current
>> > > > single-compatible devicetrees to work, but new devicetrees, including
>> > > > new compatibles, should use a two-component compatible.
>> > > > 
>> > > > This series serves to address comments regarding the device compatibles
>> > > > for the patches adding RTL9607C watchdog support [1].
>> > > > 
>> > > > [1]
>> > > > https://lore.kernel.org/lkml/20260509163101.722793-1-adilov@disroot.org/
>> > > 
>> > > You misunderstood the discussion (though some came after this). The
>> > > fallback should be one of the existing compatibles (the oldest one), so
>> > > there are no driver changes needed for the OS. Creating a new fallback
>> > > completely misses that point.
>> > 
>> > Using a SoC-specific compatible would mean we should go for something like:
>> >         compatible = "realtek,rtl9706c-wdt", "realtek,rtl8380-wdt";
>> > 
>> > Then that means we can never change our interpretation of how the rtl8380
>> > behaves (we don't have datasheets), because it would also impact the
>> > behavior of
>> > the rtl9706c.
>> 
>> No, at that point you would add the rtl9706c compatible to the driver
>> to distinguish.
>> 
>> You have the same constraint with your generic compatible.
>> 
>> > I also think "apple,wdt" is a bad example to compare with "realtek,otto-
>> > wdt".
>> > The former only specifies the vendor, while the latter refers to the line of
>> > SoCs this IP block is used for. Although I see the docs also discourage
>> > family
>> > compatibles.
>> 
>> Is M1, M2, M3 not a family? Maybe A series is included too, but if
>> there's anyone that maintains some consistency across SoCs, it is
>> Apple.
>> 
>> The docs are based on experience and regret...
>> 
>> > 
>> > If I may ask, what is the rationale for preferring the "older
>> > implementation"
>> > approach over a "family compatible" to match the common subset of supported
>> > features?
>> 
>> If you create bindings as the SoCs are created, then you don't really
>> know what's in a family, only does it work with the existing driver .
>> You only know what's in a family after the fact. Things are never that
>> clean either.
>> 
>> I just picked the oldest as that's probably the most well known, least
>> likely to need some future change, and would have the oldest OS
>> version support.
> 
> Thanks for the extra context.
> 
> Rustam, will you take it from here to add the two-part compatible for the
> RTL9706C? Since you won't need update the driver, I guess a single patch would
> do.

I can for sure, but would you mind clarifying what needs to be done?
From my understanding two-part compatible for RTL9607C would look like
compatible = "realtek,rtl9607-wdt", "realtek,rtl8380-wdt";
But it's only gonna be relevant to OpenWrt for now.

Do i need to patch the realtek,otto-wdt.yaml file in the same way as
your patch 1 here?

Thanks in advance.

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Sander Vanheule]

On Fri, 2026-05-15 at 19:14 +0000, Rustam Adilov wrote:
> Hello Sander,
> On 2026-05-15 08:47, Sander Vanheule wrote:
> > Rustam, will you take it from here to add the two-part compatible for the
> > RTL9706C? Since you won't need update the driver, I guess a single patch
> > would
> > do.
> 
> I can for sure, but would you mind clarifying what needs to be done?
> From my understanding two-part compatible for RTL9607C would look like
> compatible = "realtek,rtl9607-wdt", "realtek,rtl8380-wdt";

As I understand from the maintainers, this is indeed the desired approach.

> But it's only gonna be relevant to OpenWrt for now.
> Do i need to patch the realtek,otto-wdt.yaml file in the same way as
> your patch 1 here?

Yes, you'll need to make a distinction between the new two-part compatible,
while still allowing the old one-part compatible (which then should not be
deprecated). Another binding that implements this is fsl-imx7ulp-wdt.yaml, so
you can also use that style, if you prefer.

Best,
Sander

Re: [PATCH v2 0/2] watchdog: realtek-otto: add fallback compatible

[Krzysztof Kozlowski]

On 14/05/2026 18:25, Sander Vanheule wrote:
> I also think "apple,wdt" is a bad example to compare with "realtek,otto-wdt".
> The former only specifies the vendor, while the latter refers to the line of
> SoCs this IP block is used for. Although I see the docs also discourage family
> compatibles.
> 
> If I may ask, what is the rationale for preferring the "older implementation"
> approach over a "family compatible" to match the common subset of supported
> features?

To add on top of Rob's:
There were already a few cases of generic fallbacks of a few IP blocks
in Qualcomm SoC, which were true for like a few years (50-100 different
SoCs!). So you really thought a generic compatible is generic, matching
entire family or all SoCS.

And then last year they came with a few new ones which are NOT
COMPATIBLE with that generic one.

So let's create another generic fallback? But how do you define it? What
is the generic part there? Even within family you have differences and
in many cases SW people just don't know.

IMO, the generic fallback is fake construct or rather "faith" construct:
I hope these devices will be compatible enough to use that generic
fallback. Hope is not enough and if that's the only thing you got, then
just use specific fallback.

And that's exactly the feedback Qualcomm got for these new "generic"
variants.

Best regards,
Krzysztof