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

[Sander Vanheule <sander@svanheule.net>]

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