Handling multiple watchdogs

Handling multiple watchdogs

[Simon Braunschmidt]

Hi

I have two watchdogs on my board that I both want to handle. What would 
be the proper approach in this case?

What I can see currently is that most (all?) watchdogs register as 
chardev 10:130, that breaks when registering more than one.

I work around this in my private tree by something like:

-------8<-----------------

#ifndef WATCHDOG_MINOR
	#define WATCHDOG_MINOR 130
#endif
#define WATCHDOG0_MINOR 212
#define WATCHDOG_NUMDEVS 2

static struct watchdog_dev_id watchdog_possible_devs[] = {
	[0] = {
		.minor = WATCHDOG_MINOR,
		.name = "watchdog",
	},
	[1] = {
		.minor = WATCHDOG0_MINOR,
		.name = "watchdog0",
	},
};

/* watchdogs can also use unusual minor numbers, try them when we fail*/
for (i = 0; i < WATCHDOG_NUMDEVS; i++) {
	wdt_miscdev.minor=watchdog_possible_devs[i].minor;
	wdt_miscdev.name=watchdog_possible_devs[i].name;
	ret = misc_register(&wdt_miscdev);
	if (ret == 0) break;
	printk(KERN_INFO PFX
		"failed to register miscdev on minor=%d (err=%d)\n",
				wdt_miscdev.minor, ret);
}
if (ret != 0) {
	goto unreg_reboot;
}

----------------->8---------

Which gives me an additional watchdog chardevice on 10:212.

This approach is probably not the best, so i am not asking for inclusion 
of such a change. One solution would be to expose the watchdogs 
individually like
/dev/watchdog0, /dev/watchdog1 and so on and to expose a combined 
interface under /dev/watchdog.

I have searched the list and found some related discussion like
http://article.gmane.org/gmane.linux.kernel/398831/match=watchdogs
other threads and
http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-experimental.git;a=summary

, yet it does not seem like this reached mainline so far.

Any sharing of thoughts on the subject would be welcome.

Best Regards
Simon Braunschmidt

Re: Handling multiple watchdogs

[Alan Cox]

On Wed, 22 Jul 2009 17:09:11 +0200
Simon Braunschmidt <sb@emlix.com> wrote:

> Hi
> 
> I have two watchdogs on my board that I both want to handle. What would 
> be the proper approach in this case?

Fixing the watchdog core to create a class of watchdog drivers and
treating the existing /dev/watchdog as a back compatibility hack. It's
been talked about for a very long time but not done, although I believe
Wim had some test code at one point ?

Alan

Re: Handling multiple watchdogs

[Wim Van Sebroeck]

Hi Simon,

> > I have two watchdogs on my board that I both want to handle. What would 
> > be the proper approach in this case?
> 
> Fixing the watchdog core to create a class of watchdog drivers and
> treating the existing /dev/watchdog as a back compatibility hack. It's
> been talked about for a very long time but not done, although I believe
> Wim had some test code at one point ?

The support of multiple watchdog's is not there at this moment. But we will indeed
need it. The embedded platforms (like omap) start to have devices with different
watchdogs that all need to be supported.

To overcome this issue we will indeed need to:
1) make sure that we have the new watchdog core infrastructure going in for 2.6.32.
This new core integrates the common code that we use over and over again. I once
wrote code for it and then Alan had different ideas and thoughts and wrote his updated
code. I reviewed that and I am changing some small bits so that we will have the new
watchdog core version 1. Expect the code to appear in the linux-2.6-watchdog-next tree
in the coming weeks (I first did some pre-cleanup stuff).
2) Then we will need a dicussion on how we will support multiple watchdog's with this
new framework. My feeling is that the /dev/watchdog* solution is not the right way to go.
I think a sysfs interface will be better. This sysfs interface would then be added to the
core version (and makes "core version 2").
I once wrote the first basis of this sysfs interface (based on rusty's input I believe).
I need to check if I still have it after the hard-disk crash I had almost a year ago.

I hope this gives you an idea about how we are proceeding with the watchdog devices driver core
and what we are trying to do (and OK i'm slower than other maintainers but I'm doing this all
in my own time and for free and thus my priority's are different...). 

Kind regards,
Wim.

(Note: for completeness; I know that the following drivers have a "non-standard"
watchdog part: drivers/watchdog/cpwd.c drivers/hwmon/fschmd.c).

Re: Handling multiple watchdogs

[Alan Cox]

> 1) make sure that we have the new watchdog core infrastructure going in for 2.6.32.
> This new core integrates the common code that we use over and over again. I once
> wrote code for it and then Alan had different ideas and thoughts and wrote his updated
> code. I reviewed that and I am changing some small bits so that we will have the new

What is the status of this ? I was thinking it had been a while but it
seems to be 18 months ago..

Alan

Re: Handling multiple watchdogs

[Wim Van Sebroeck]

Hi Alan,

> > 1) make sure that we have the new watchdog core infrastructure going in for 2.6.32.
> > This new core integrates the common code that we use over and over again. I once
> > wrote code for it and then Alan had different ideas and thoughts and wrote his updated
> > code. I reviewed that and I am changing some small bits so that we will have the new
> 
> What is the status of this ? I was thinking it had been a while but it
> seems to be 18 months ago..

I did that dev_* fix as we agreed on sunday.
I will sent out the code (for additional comments) out tonight to linux-kernel and linux-watchdog mailing lists.
Aiming to get it in for 2.6.39.

Code can allready be looked at, at:
http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-next.git;a=shortlog;h=refs/heads/generic-watchdog

Open issues: get min adn max timeout in so that the generic code can check the boundarys.
Need to think about MAGIC_CLOSE_FEATURE. There seem to be people that are surprised that if you do a cat /dev/watchdog that the system reboots. Whiwh is normal: it's an open with a close without the magic character. One solution I see is to add a module_param that can disable magic_close_feature. Default will be on though).

And after that we can consider the read function that you proposed.

And then we need to go for the sysfs interface so that we can support multiple watchdogs via sysfs.

Kind regards,
Wim.