Guenter, On Tue, 29 Dec 2015 09:28:48 -0800, Guenter Roeck wrote: > Probem with SBSA and pretimeout is two-fold. First, it adds a quite a bit of > complexity to the driver, second, it adds a lot of risk to the driver. > Reason is that this is not one specific watchdog, but a watchdog implementation > based on a standard which, in my opinion, is less than well thought out > and leaves a lot of ambiguity when it comes to implementation details. I agree that calling the SBSA watchdog specification a "specification" is a strong word. At least in the version I have, it's 4-5 pages of somewhat random thoughts on what a standardized watchdog could look like, but not a very well-defined specification that guarantees that all implementations will behave in the same way. > The more functionality is used, the higher the risk that some implementation > won't work. Maybe we should enforce that all users of the driver use two Device Tree compatible strings: compatible = "<vendor>,sbsa-gwdt", "arm,sbsa-gwdt"; So that the SBSA watchdog driver can implement vendor specific quirks if needed. Though it is true that the HW has some identification registers that should allow to differentiate between the implementation. > I think we should stick with the basic implemementation and not support > pretimeout at all with the SBSA driver. If the maximum timeout is insufficient, > there are two options: Use the soft-timeout handled by the watchdog core, > which will hopefully make it for 4.6, or live with it. For now, I'm personally fine with a SBSA driver that does not support the pretimeout. Is anyone working on submitting something like this ? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
