On Mon, Feb 23, 2015 at 10:19 AM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > On Mon, Feb 23, 2015 at 11:11:38AM +0200, Timo Kokkonen wrote: > [ ... ] > >> >> After all, we do have already watchdog_init_timeout function that parses the >> watchdog timeout argument from either device tree or from command line. How >> about if we expanded that interface? Maybe have a more generic >> watchdog_init_parmas() or something that parses the generic watchdog >> arguments, either from command line, device tree or ACPI or something. The >> device driver could replace call from watchdog_init_timeout() to >> watchdog_init_params() once it is ready to support other generic parameters, >> such as early-timeout-sec. Then the watchdog driver could do the right thing >> about whether watchdog should be left running or stopped and how long time >> should be given. >> > Good idea. > >> Alternatively, we could also let the watchdog core know a little more about >> the actual watchdog hardware, such as whether the HW is stoppable, whether >> it needs manual pinging by the kernel until user space has taken over. Or Whether the h/w is stoppable or not is certainly a reasonable DT property. The maximum h/w timeout would be too (although that may just be a property of counter size and clock rate). > Yes, all that will be needed. But, still, the stop-gap is that we'll need to > get buyin from the DT folks for the necessary properties. I have had the > outline for the necessary watchdog core implementation in my mind for a long > time, but I just don't have the time (nor the patience, quite frankly) > to get DT buyin. Defining wdog core functionality and behavior has little to do with DT and you don't need buy in. Presumably you care about non-DT platforms as well. Moving more of the intelligence to the core would be a good thing and for the most part should be independent of DT. Rob >> maybe we can just extend the timeout values until the user space has first >> opened it and then shorten the timeout automatically so that it doesn't take >> that long for the device to reset after a crash. Or some other behaviour >> that is common to many users. Suggestions are welcome. >> >> Anyway, that is something that needs to be done to make watchdog core take >> more control over more of the generic watchdog behaviour. It just needs to >> be done so that we don't need to convert all drivers at once. >> > Correct. It should not be that difficult do do that if designed properly. > > Guenter -- 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
