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 -- 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
