On Tue, Jun 21, 2016 at 7:34 PM, Andrey Smirnov <andrew.smirnov@xxxxxxxxx> wrote: > On Tue, Jun 21, 2016 at 2:07 PM, Alexandre Belloni > <alexandre.belloni@xxxxxxxxxxxxxxxxxx> wrote: >> 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. > > 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? > >> 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/... > > Unfortunately exposing that feature using sysfs gives you a leaky > abstraction and your userspace instead of using a generic RTC starts > using DS1341 RTC. So to accommodate for that a user would have to: > > a) Write + integrate a userspace tool to set the mode (which IMHO is > decided upon once and doesn't change) > b) If a board design is new and there's a chance of moving this chip > to a different I2C bus, the code above would have to account for that > and not hardcore sysfs path > c) If board's BSP is intended to be used in multiple generations of a > product, not all of which would use DS1341, it would be necessary to > accommodate for that by either more code in the tool or an additional > BSP build configuration variant > >> - on subsequent reboots, the mode is kept alongside the time and date >> > > This assumes that your bootloader leaves those mode bits alone. > >> 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. >> > > I fell like I am not understanding you correctly. Why would moving > configuration decision logic into userspace improve the situation in > case of unexpected power loss? > > Andrey Alexandre, what's the status of this discussion/patchset? Would it be more acceptable if I dropped all of the refactoring and just kept the code adding new feature + DT binding for it? I am more than happy to drop all but essential parts of the patches if that would allow us to make progress. Thank you, Andrey -- 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
