On Wed, Jul 20, 2016 at 8:38 AM, Alexandre Belloni
[off-list ref] wrote:

On 20/07/2016 at 07:36:55 -0700, Andrey Smirnov wrote :

quoted

On Wed, Jul 20, 2016 at 2:02 AM, Alexandre Belloni
[off-list ref] wrote:

quoted

On 19/07/2016 at 16:56:56 -0700, Andrey Smirnov wrote :

quoted

quoted

quoted

I don't see any value in doing that, could you give me a realistic
example of a scenario in which a user would want to spend some of
uptime with RTC oscillator fault detection/glitch filtering disabled
and then enable it?

Well, the issue is not being dynamic, it is differentiating between
hardware description and user configuration. Configuration must not be in
DT.

Why? And I don't mean in a generic sense, but in this particular case.
What is gained by not having this bit of configuration, whose only
consumer is the driver, in the device tree file?

Because configuration doesn't belong to DT. DT is about hardware
description, not configuration.

That doesn't really answer my question. You just re-iterating some
maxim without explaining what is the point behind applying it.

Well, that is from the device tree specification and how the device tree
maintainers want it...

And yet, we have whole subsystems such as "nvmem" and I am sure plenty
of other smaller examples where that maxim is being applied very lax
if at all. So it seems people can and do make compromises regarding
the "no configuration in DT" rule if pros of doing so outweighs the
cons.

Andrey

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.