Thread (22 messages) flat view 22 messages, 7 authors, 2022-03-05

Re: [PATCH 0/2] add ripple counter dt binding and driver

From: Guenter Roeck <linux@roeck-us.net>
Date: 2021-02-26 19:54:19
Also in: linux-clk, linux-watchdog, lkml

On 2/26/21 8:35 AM, Rasmus Villemoes wrote:
On 26/02/2021 15.35, Arnd Bergmann wrote:
quoted
On Fri, Feb 26, 2021 at 3:14 PM Rasmus Villemoes
[off-list ref] wrote:
quoted
So I'm thinking that the proper way to handle this is to be able to
represent that ripple counter as a clock consumer in DT and have a
driver do the clk_prepare_enable(), even if that driver doesn't and
can't do anything else. But I'm certainly open to other suggestions.
How about adding support for the optional clock to the gpio_wdt driver,
would that work?
I think it would _work_ (all I need is some piece of code doing the
clock_prepare_enable(), and until now we've just stashed that in some
otherwise unrelated out-of-tree driver, but we're trying to get rid of
that one), but the watchdog chip isn't really the consumer of the clock
signal, so in-so-far as DT is supposed to describe the hardware, I don't
think it's appropriate.

OTOH, one could argue that the watchdog chip and the ripple counter
together constitute the watchdog circuit.

Cc += watchdog maintainers. Context: I have a gpio-wdt which can
unfortunately effectively be disabled by disabling a clock output, and
that happens automatically unless the clock has a consumer in DT. But
the actual consumer is not the gpio-wdt.
Please see
https://lore.kernel.org/lkml/20210226141411.2517368-1-linux@rasmusvillemoes.dk/ (local)
for the original thread.
Sorry, I am missing something. If the watchdog is controlled by the clock,
it is a consumer of that clock. What else does "consumer" mean ? And why
not just add optional clock support to the gpio_wdt driver ?

Guenter
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help