On Wed, 13 May 2015, James Hogan wrote: > On Malta, the RTC is forced into binary coded decimal (BCD) mode during > init, even if the bootloader put it into binary mode (as YAMON does). > This can result in the RTC seconds being an invalid BCD (e.g. > 0x1a..0x1f) for up to 6 seconds. Sigh. No sooner I had fixed the breakage (with 636221b8 and a fat comment) it got put back (with a87ea88d). Even though it's easily spotted as it breaks the system time (all the fields, including the date too, not only the seconds!) across a reboot due to YAMON eagerly switching the mode back. And that'd be the first item I'd check when validating a change touching the RTC. Is there an actual need to reinitialise the RTC at all? The RTC registers are readable, so the current configuration can be obtained, the RTC driver copes with any valid arrangement, so can any other code using the clock as a reference. YAMON OTOH is not as flexible, its clock management commands expect the format the monitor itself set the chip to, so I think the kernel has to respect that (just as it doesn't randomly flip bits in the RTC on x86 PCs for example). So unless proven otherwise I'll ask for `init_rtc' to be dropped altogether and any changes required made to `estimate_frequencies' instead. Which I believe you already did with 2/2. Maciej
