Hi Arnd, > > > > +#include <linux/platform_device.h> > > > > + > > > > +/* Hardware heartbeat in seconds */ > > > > +#define WDT_HW_HEARTBEAT 2 > > > > + > > > > +/* Timer heartbeat (500ms) */ > > > > +#define WDT_HEARTBEAT (HZ/2) /* should be <= ((WDT_HW_HEARTBEAT*HZ)/2) */ > > > > + > > > > +/* User land timeout */ > > > > +#define WDT_TIMEOUT 15 > > > > +static int timeout = WDT_TIMEOUT; > > > > +module_param(timeout, int, 0); > > > > +MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds. " > > > > + "(default = " __MODULE_STRING(WDT_TIMEOUT) ")"); > > > > > > Should the module parameter really be part of each individual driver? > > > It would be nice if that can be moved into the core as well. > > > > Yes, the module parameter is needed for each individual driver. > > If we go for supporting multiple watchdog devices, then we will have to support > > different timeout values. The timeout ranges also differ for different devices. > > Ok, but you'd still have to worry about a single driver supporting multiple > distinct devices that each want a separate timeout, right? If it's a single driver that supports different devices (say an SuperIO controller with several watchdog timers and different GPIO output's), then I still presume that the timeout range for these different devices will be the same. But I can indeed imagine that these timers will be used for monitoring different "processes" that will have different latency and timeout values. > OTOH, we can still find a solution when it ever gets to the point of > supporting multiple devices. Yep, if we support different watchdog devices, then we will need something to change the default value anyway (like the ioctl does now for a single instance). Kind regards, Wim. -- 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