Re: [PATCH 1/2] dt-bindings: misc: add binding for generic ripple counter

[Rob Herring <robh@kernel.org>]

On Mon, Mar 08, 2021 at 09:02:29PM +0100, Rasmus Villemoes wrote:
> On 08/03/2021 18.21, Rob Herring wrote:
> > On Fri, Feb 26, 2021 at 03:14:10PM +0100, Rasmus Villemoes wrote:
> >> While a ripple counter can not usually be interfaced with (directly)
> >> from software, it may still be a crucial component in a board
> >> layout. To prevent its input clock from being disabled by the clock
> >> core because it apparently has no consumer, one needs to be able to
> >> represent that consumer in DT.
> > 
> > I'm okay with this as it is describing h/w, but we already 
> > 'protected-clocks' property which should work.
> 
> Hm. Unless
> https://lore.kernel.org/lkml/20200903040015.5627-2-samuel@sholland.org/
> gets merged, I don't see how this would work out-of-the-box.

Hum, no really clear what the hold up is there given it seems it was 
asked for. Letting it sit for 5 months is certainly not the way 
to get it merged. Anyways, that's the kernel's problem, not mine as far 
as DT bindings are concerned.

> 
> Note that I sent a completely different v2, which made the gpio-wdt the
> clock consumer based on feedback from Guenter and Arnd, but that v2
> isn't suitable for our case because it post-poned handling of the
> watchdog till after i2c is ready, which is too late. Somewhat similar to
> https://lore.kernel.org/lkml/20210222171247.97609-2-sebastian.reichel@collabora.com/
> it seems.

Now at that one in my queue... I think 'protected-clocks' is the best 
way to avoid any driver probe ordering issues. It's the only thing that 
really captures don't turn off this clock. The ripple counter binding 
doesn't really capture that or what it is related to. Also, the 
ripple-counter driver could be a module and you'd still have the same 
issue as v2.

> >> +
> >> +Required properties:
> >> +- compatible: Must be "linux,ripple-ctr".
> > 
> > Nothing linux specific about this.
> 
> True, but I was following the lead of the existing gpio-wdt binding. Is
> there some other "vendor" name one can and should use for completely
> generic and simple components like these? "generic"?

Most 'generic' and GPIO based interfaces have no vendor prefix.

Rob