| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 May 2015 23:14:19 -0700 From: Guenter Roeck <linux@...ck-us.net> To: Andreas Werner <andy@...nerandy.de> CC: linux-watchdog@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: Window watchdog driver design On 05/14/2015 10:43 PM, Andreas Werner wrote: > On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote: >> On 05/14/2015 07:09 AM, Andreas Werner wrote: >>> On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote: >>>> On 05/14/2015 04:56 AM, Andreas Werner wrote: >>>>> Hi, >>>>> in the next few weeks I need to write a driver for a window wachtdog >>>>> implemented in a CPLD. I have some questions about the design >>>>> of the driver and the best way to write this driver to also be able >>>>> to submit it. >>>>> >>>>> The triggering and configuration of the Watchdog is done by several GPIOs which >>>>> are connected to the CPLD watchdog device. The correct GPIOs are configurable >>>>> using the Device Tree. >>>>> >>>>> 1. Timeout >>>>> The timeout values are defined in ms and start from 20ms to 2560ms. >>>>> The timout is set by 3 GPIOs this means we have only 8 different >>>>> timout values. It is also possible that a future Watchdog CPLD device >>>>> does have different timeout values. >>>>> >>>>> Is it possible to set ms timeouts? It seems that the WDT API does >>>>> only support a resolution of 1sec. >>>>> >>>>> One idea would be to use the API timeout as something like a timeout >>>>> index to set the different values. Of course this needs to be documented. >>>>> >>>>> e.g. >>>>> timeout (API) timeout in device >>>>> 1 20ms >>>>> 2 100ms >>>>> 3 500ms >>>>> ... ... >>>>> >>>>> 2. Upper/Lower Window >>>>> There is currently no support for a windowed watchdog in the wdt core. >>>>> The lower window can be activated by a gpio and its timeout is defined >>>>> as "upper windows timeout/4" >>>>> >>>>> What is the best way to implement those additional settings? Adding additional >>>>> ioctl or export these in sysfs? >>>>> -- >>>> >>>> Sorry for the maybe dumb question, but what is a window watchdog, >>>> and what is the lower window timeout for (assuming the upper window >>>> timeout causes the watchdog to expire) ? >>>> >>>> Guenter >>>> >>> >>> Oh sorry forgot to describe it in more detail. >>> >>> If you have a watchdog window you do not have just one timeout where the watchdog can expire. >>> You have a so called "window" to trigger it within. >>> >>> |<----trig---->| >>> ---lower timeout----------------upper timeout >>> >>> This means you have to trigger the watchdog not to late and not to early. >>> This kind of watchdog is often used in embedded applications or more often >>> in safety cases to fullfil requirements given e.g. by SIL1-SIL4 certifications. >>> >>> The lower timeout is set by a dedicated GPIO and the value will then "Upper timeout / 4". The >>> upper timeout is set by 3 GPIOs to get different timeout values. >>> >> >> Thanks a lot for the explanation. >> >> I would suggest to use a module parameter to enable the "lower timeout" functionality. >> >> Timeouts have to be specified in seconds. >> >> Hope this helps, >> Guenter >> > > Thanks for the answer. > > The module parameter would be ok for me, but it would be better if i can enable/disable > the lower window by the application. > You could try adding a sysfs attribute. > I know that the API defines the timout in seconds but what about ms? Is there no > watchdog out there which has timout values < seconds?. > The ABI is the ABI, it has been there for a long time, and it only supports second intervals. > In my case I can only set 2 timouts (1sec and 2sec) but I need to support all 8 timeout > values. > Kind of strict for a Linux watchdog. Most if not all other timeouts are much higher. The drivers for hardware with low maximum timeout values often implement a two-stage timeout, one handled in the driver that pings the actual hardware timeout, and a soft-timeout to be triggered from user space with a more relaxed timing. > The other thing is that my Watchdog can have differen timeout values depending > on the CPLD and the customer requirements. I can not read out this values, they are > only defined in the specification. > Normally you'd expect such platform specific details to be configured via devicetree or platform data if that is not available (or ACPI, of course). The userspace/kernel ABI/API needs to be standardized, so that user space doesn't need to know implementation details. > This is why i had the idea with the table to only set some "indexes" for the timout > to handle all the cases. > Such an "index" would not be a well defined number. A standard application, such as watchdogd or systemd, would not know what to do with it. After all, the common use case of a watchdog driver is for it to interface with a standard userspace application, so its interface to userspace needs to be well defined. We can not permit "wildcards" such as redefining the meaning of a time interval from seconds to something driver-specific; that would break all kinds of applications. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists