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@xxxxxxxxxxxxx> 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@xxxxxxxxxxx/
> >
> > 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