.../bindings/watchdog/realtek,otto-wdt.yaml | 22 ++++++++++++++----- drivers/watchdog/realtek_otto_wdt.c | 2 ++ 2 files changed, 18 insertions(+), 6 deletions(-)
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
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
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
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
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
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
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.
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
© 2016 - 2026 Red Hat, Inc.