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). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
