On Mon, Jul 27, 2020 at 05:41:04PM +0200, Alexandre Belloni wrote: > On 27/07/2020 16:24:39+0100, Russell King - ARM Linux admin wrote: > > On Mon, Jul 27, 2020 at 04:49:38PM +0200, Alexandre Belloni wrote: > > > On 27/07/2020 10:45:53+0100, Russell King - ARM Linux admin wrote: > > > > > This is but this shouldn't be a DT property as it has to be changed > > > > > dynamically. I'm working on an ioctl interface to change this > > > > > configuration. > > > > > > > > Why does it need to be changed dynamically? If the hardware components > > > > are not fitted to allow the RTC to be safely used without DSM, then > > > > why should userspace be able to disable DSM? > > > > > > For RTCs with a standby mode, you want to be able to return to standby > > > mode. > > > > > > That would happen for example after factory flashing in that common use > > > case: > > > - the board is manufactured > > > - Vbackup is installed, the RTC switches to standby mode > > > - the board is then booted to flash a system, Vprimary is now present, > > > the RTC switches to DSM. > > > > > > At this point, if the board is simply shut down, the RTC will start > > > draining Vbackup before leaving the factory. Instead, we want to be able > > > to return to standby mode until the final user switches the product on > > > for the first time. > > > > I don't think you're understanding what's going on with this proposed > > patch. The cubox-i does work today, and the RTC does survive most > > power-downs. There are situations where it doesn't. > > > > So, let's take your process above. > > > > - the board is manufactured > > - Vbackup is installed, the RTC switches to standby mode > > - the board is then booted to flash a system, Vprimary is now present > > - the board is powered down. the RTC _might_ switch over to battery > > if it notices the power failure in time, or it might not. A random > > sample of units leaving the factory have the RTC in standby mode. > > Others are draining the battery. > > > > I'm not saying what you propose isn't a good idea. I'm questioning > > why we should expose this in the generic kernel on platforms where > > it's likely to end up with the RTC being corrupted. > > > > Note that I didn't say we should expose settings that are not working > but it is a different discussion. It isn't a different discussion - that is exactly what the point of my emails to you all along have been! So, can we please have that discussion, it is pertinent to this patch. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
