A case of watchdog+LED shared GPIO pin

A case of watchdog+LED shared GPIO pin

[Ильяс Гасанов]

Hello,

We (the development team at my current employer company) are having a
specific case of hardware configuraton. Namely, the same GPIO pin is
used for both watchdog keepalive signaling and status LED blinking.
The thing is, there are multiple blinking frequency modes for this
LED, each with its own meaning (i.e. system/firmware states), so
there's a need for changing the frequency/period dynamically from
userspace.

Previously I've done the thing implementing the timer period
configuration by updating a special sysfs file with new values in the
gpio_wdt driver. However since recently (commit 03bca15 in the kernel
Git repo) the timer has been swapped out with the keepalive callback
thing, which, as far as I can tell, supports updating the timeout
period via the WDIOC_SETTIMEOUT ioctl. However this ioctl is
insufficient for our purposes, in the sense that its minimum
resolution is 1 whole second, while we need a 100 millisecond
granularity at the very most.

I could also simply disable the gpio_wdt altogether and just use a LED
trigger driven configuration, but I highly doubt this would be a wise
thing, since the whole point of the watchdog is monitoring
responsiveness of the userspace. Also I gather that controlling the
GPIO entirely from a userspace process is rather undesirable, too, as
it might lead to confusing latencies sometimes, for a start.

I'd like to hear your opinions on the preferred way(s) of implementing
this for our product hardware on the most recent kernels, which could
be sent to upstream to secure further backwards compatibility.

Sincerely,
Ilyas

Re: A case of watchdog+LED shared GPIO pin

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Hi!

> We (the development team at my current employer company) are having a
> specific case of hardware configuraton. Namely, the same GPIO pin is
> used for both watchdog keepalive signaling and status LED blinking.
> The thing is, there are multiple blinking frequency modes for this
> LED, each with its own meaning (i.e. system/firmware states), so
> there's a need for changing the frequency/period dynamically from
> userspace.
> 
> Previously I've done the thing implementing the timer period
> configuration by updating a special sysfs file with new values in the
> gpio_wdt driver. However since recently (commit 03bca15 in the kernel
> Git repo) the timer has been swapped out with the keepalive callback
> thing, which, as far as I can tell, supports updating the timeout
> period via the WDIOC_SETTIMEOUT ioctl. However this ioctl is
> insufficient for our purposes, in the sense that its minimum
> resolution is 1 whole second, while we need a 100 millisecond
> granularity at the very most.
> 
> I could also simply disable the gpio_wdt altogether and just use a LED
> trigger driven configuration, but I highly doubt this would be a wise
> thing, since the whole point of the watchdog is monitoring
> responsiveness of the userspace. Also I gather that controlling the
> GPIO entirely from a userspace process is rather undesirable, too, as
> it might lead to confusing latencies sometimes, for a start.
> 
> I'd like to hear your opinions on the preferred way(s) of implementing
> this for our product hardware on the most recent kernels, which could
> be sent to upstream to secure further backwards compatibility.

Improving WDIOC_SETTIMEOUT is obvious solution. I'd go for that.

But actually, controlling GPIO entirely from userspace should work
well, too. User is not going to notice the jitter in miliseconds...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: A case of watchdog+LED shared GPIO pin

[Ильяс Гасанов]

2018-03-04 22:19 GMT+03:00 Pavel Machek <pavel@ucw.cz>:
> Improving WDIOC_SETTIMEOUT is obvious solution. I'd go for that.

Question is, then, - how to do it in a backwards-compatible manner?
There is very likely to be some userspace software out there which
relies on the assumption of the currently used whole seconds semantics
being in effect.

Add a new millisecond argument? But how to detect its presence in the handler?

Introduce a new ioctl? But how to do it neatly and reasonably?

> But actually, controlling GPIO entirely from userspace should work
> well, too. User is not going to notice the jitter in miliseconds...

>From my experience, sometimes a heavy load on the CPU by other
processes may cause quite noticeable lags, and it's hard to make sure
that our other developers would nice up their processes to give the
LED blinker enough 'priority'. Also, that doesn't factor in the time
between the boot and the process startup, since in our configuration
the 'system' processes such as watchdog are run way earlier than the
'appliance' processes, however the former may be in a read-only
squashfs partition which is a pain to update. But I'd like to have it
up and running as soon as possible, so...

Re: A case of watchdog+LED shared GPIO pin

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Sun 2018-03-04 22:45:35, Ильяс Гасанов wrote:
> 2018-03-04 22:19 GMT+03:00 Pavel Machek <pavel@ucw.cz>:
> > Improving WDIOC_SETTIMEOUT is obvious solution. I'd go for that.
> 
> Question is, then, - how to do it in a backwards-compatible manner?
> There is very likely to be some userspace software out there which
> relies on the assumption of the currently used whole seconds semantics
> being in effect.
> 
> Add a new millisecond argument? But how to detect its presence in the handler?
> 
> Introduce a new ioctl? But how to do it neatly and reasonably?

New ioctl. Start from the old one. Keep it neat :-). Negotiate with wd
maintainers if that's ok with them, first.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: A case of watchdog+LED shared GPIO pin

[Guenter Roeck]

On Sun, Mar 04, 2018 at 07:26:56PM +0300, Ильяс Гасанов wrote:
> Hello,
> 
> We (the development team at my current employer company) are having a
> specific case of hardware configuraton. Namely, the same GPIO pin is
> used for both watchdog keepalive signaling and status LED blinking.
> The thing is, there are multiple blinking frequency modes for this
> LED, each with its own meaning (i.e. system/firmware states), so
> there's a need for changing the frequency/period dynamically from
> userspace.
> 
> Previously I've done the thing implementing the timer period
> configuration by updating a special sysfs file with new values in the
> gpio_wdt driver. However since recently (commit 03bca15 in the kernel
> Git repo) the timer has been swapped out with the keepalive callback
> thing, which, as far as I can tell, supports updating the timeout
> period via the WDIOC_SETTIMEOUT ioctl. However this ioctl is
> insufficient for our purposes, in the sense that its minimum
> resolution is 1 whole second, while we need a 100 millisecond
> granularity at the very most.
> 
> I could also simply disable the gpio_wdt altogether and just use a LED
> trigger driven configuration, but I highly doubt this would be a wise
> thing, since the whole point of the watchdog is monitoring
> responsiveness of the userspace. Also I gather that controlling the
> GPIO entirely from a userspace process is rather undesirable, too, as
> it might lead to confusing latencies sometimes, for a start.
> 
> I'd like to hear your opinions on the preferred way(s) of implementing
> this for our product hardware on the most recent kernels, which could
> be sent to upstream to secure further backwards compatibility.
> 

Using the same GPIO pin for both watchdog and LEDs seems odd. I don't
have a useful idea how to address your problem, sorry.

Guenter