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@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.
> 
> 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.