Hi All,
To reduce copying the same code over and over in each watchdog device driver, Alan Cox and myself constructed a new framework/API that consolidates the common watchdog timer driver functions.
This framework/API consists of the following patches:
part 1: Introduction of the WatchDog Timer Driver Core
part 2: Add the basic ioctl functionality
part 3: Add the WDIOC_KEEPALIVE ioctl
part 4: Add the WDIOC_SETOPTIONS ioctl
part 5: Add the WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl
part 6: Add orphan control
part 7: Add the Magic Close feature
part 8: Add the nowayout feature
part 9: Add support for a miscdev parent device
part 10: Add support for extra ioctl calls
Note: I still need to add the minimum and maximum timeout parameters.
(That will become part 11).
Please provide feedback,
Kind regards,
Wim.
On 02/23/11 12:41, Wim Van Sebroeck wrote:
> Hi All,
>
> To reduce copying the same code over and over in each watchdog device driver, Alan Cox and myself constructed a new framework/API that consolidates the common watchdog timer driver functions.
>
> This framework/API consists of the following patches:
> part 1: Introduction of the WatchDog Timer Driver Core
> part 2: Add the basic ioctl functionality
> part 3: Add the WDIOC_KEEPALIVE ioctl
> part 4: Add the WDIOC_SETOPTIONS ioctl
> part 5: Add the WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl
> part 6: Add orphan control
> part 7: Add the Magic Close feature
> part 8: Add the nowayout feature
> part 9: Add support for a miscdev parent device
> part 10: Add support for extra ioctl calls
>
> Note: I still need to add the minimum and maximum timeout parameters.
> (That will become part 11).
Overall, this looks really good IMO. It goes a long way to setting the
stage for cleaning up the watchdog drivers themselves :)
Reviewed-by: Mike Waychison <[email protected]>
Hi Wim,
On Wed, Feb 23, 2011 at 9:41 PM, Wim Van Sebroeck <[email protected]> wrote:
> To reduce copying the same code over and over in each watchdog device driver, Alan Cox and myself constructed a new framework/API that consolidates the common watchdog timer driver functions.
>
> This framework/API consists of the following patches:
> part ?1: Introduction of the WatchDog Timer Driver Core
> part ?2: Add the basic ioctl functionality
> part ?3: Add the WDIOC_KEEPALIVE ioctl
> part ?4: Add the WDIOC_SETOPTIONS ioctl
> part ?5: Add the WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl
> part ?6: Add orphan control
> part ?7: Add the Magic Close feature
> part ?8: Add the nowayout feature
> part ?9: Add support for a miscdev parent device
> part 10: Add support for extra ioctl calls
While looking for efforts to provide a generic driver for gpio driven
watchdog devices, like some simple hardware supervisors, I came into
this patchset RFC, which turned out to be very interesting to me.
Maybe I'm looking into the wrong places, but I could not find any
upstream commit after this RFC.
Since I don't see any real critic from commenters to the approach you
are suggesting, I'd like to know if there still is some
work-in-progress on this.
TIA
Kind regards,
Andrea
Hi Andrea,
> On Wed, Feb 23, 2011 at 9:41 PM, Wim Van Sebroeck <[email protected]> wrote:
> > To reduce copying the same code over and over in each watchdog device driver, Alan Cox and myself constructed a new framework/API that consolidates the common watchdog timer driver functions.
> >
> > This framework/API consists of the following patches:
> > part ?1: Introduction of the WatchDog Timer Driver Core
> > part ?2: Add the basic ioctl functionality
> > part ?3: Add the WDIOC_KEEPALIVE ioctl
> > part ?4: Add the WDIOC_SETOPTIONS ioctl
> > part ?5: Add the WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl
> > part ?6: Add orphan control
> > part ?7: Add the Magic Close feature
> > part ?8: Add the nowayout feature
> > part ?9: Add support for a miscdev parent device
> > part 10: Add support for extra ioctl calls
>
> While looking for efforts to provide a generic driver for gpio driven
> watchdog devices, like some simple hardware supervisors, I came into
> this patchset RFC, which turned out to be very interesting to me.
> Maybe I'm looking into the wrong places, but I could not find any
> upstream commit after this RFC.
> Since I don't see any real critic from commenters to the approach you
> are suggesting, I'd like to know if there still is some
> work-in-progress on this.
I was working on it yesterday and will finish testing today.
So expect a new post this afternoon.
I incorporated the comments I received. Orphan control will not be in (as
long as the watchdog device is registered you can reopen it). And we will
add the minimum and maximum timeout in an extra part.
Kind regards,
Wim.