On 21/06/2016 at 15:49:04 -0500, Rob Herring wrote : > So wouldn't you want to set one mode while running and the lower power > mode while suspended? I'm trying to understand the frequency of changing > this. If it is always one setting for a board, then yes it belongs in > DT. If it is a user decision, then it probably shouldn't be in DT. > > Seeing as these are reused, I've probably already had this discussion... >
I would agree with Rob here. It may be better to provide a sysfs interface to configure that particular behavior. This is usually ok because the use case is: - the RTC is not configured, time has never been set - time is set for the first time - the user can set the oscillator mode/detection/... - on subsequent reboots, the mode is kept alongside the time and date I would advise against trying to set a mode automatically in the driver because you may have unexpected power cuts and it may then let the RTC consume more power than what you really want. > > > They should have vendor prefix and be explicit that they are boolean. > > > > I was trying to be consistent with ds1339 and ds1390 bindings which do > > not have vendor prefixes. Will fix in v2. > > Okay, then they are fine if you are using existing properties. Perhaps > these should all be in a common binding doc though. > I'll try to collect the existing common properties and write that doc this week. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
