Re: [RFC] improve binding for linux,wdt-gpio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hello Guenter,

On Thu, Jul 30, 2015 at 12:25:07AM -0700, Guenter Roeck wrote:
> On 07/29/2015 11:59 PM, Uwe Kleine-König wrote:
> >On Wed, Jul 29, 2015 at 08:49:23AM -0700, Guenter Roeck wrote:
> >>On 07/29/2015 12:35 AM, Uwe Kleine-König wrote:
> >>>>always-running is meant to indicate that the watchdog can not be stopped
> >>>>(meaning a timer has to be used to send keepalives while the watchdog
> >>>>device is closed). The documentation specifically states that.
> >>>>
> >>>>	"If the watchdog timer cannot be disabled ..."
> >>>>
> >>>>How would you express that condition without always-running or a similar
> >>>>attribute ?  I am also not sure how that relates to hw_algo; I thought
> >>>>those properties are orthogonal.
> >>>For hw_algo = "level" the inactive level of the gpio disables the
> >>>watchdog (and resets the counter). So always-running doesn't make sense
> >>>for this type.
> >>>
> >>That is not what is currently implemented. "level" just means that
> >I'm not talking (yet) about the implementation.
> >>the watchdog is pinged using a -high-low-high- or -low-high-low-
> >>sequence, while toggle means that the level is changed with each
> >>ping (-low-(wait)-high-(wait)-low-(wait)-high-...).
> >Currently the document tells us:
> >
> >	hw_algo: [...]
> >	- level: Low or high level starts counting WDT timeout, the
> >	  opposite level disables the WDT.
> >
> >So similar to the "toggle" description there is some behaviour about
> >being disabled in certain states implied.
> >
> 
> It might be that you put too much emphasis on the documentation and
> little or none on the code. We already established that the documentation
> is less than perfect. It might make sense to clean up the documentation
> first to ensure that it matches what it is actually meant to document.
I'm not sure you wrote here what you intended to write?!
 
> Sure, I understand, the devicetree bindings are supposed to be
> implementation independent. We all know that this is an ideal view
> which often does not match reality, as the code tends to be written
> first and the devicetree bindings tend to be an afterthought.
I think for drivers that work with a single type of device it works well
the other way round. But for something as generic as a gpio watchdog
that is supposed to drive several different types of devices I think
agreeing on which way to go is more time saving than to come up with an
implementation first that then needs change on feedback.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux