YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to
binary, that is the bit is set every time the board goes through the
firmware bootstrap sequence. Likewise its calendar manipulation commands
interpret or set the RTC registers unconditionally as binary, never
actually checking what the value of the DM bit is, under the (correct)
assumption that it has been previously set, to indicate the binary mode.
A change to Linux a while ago however introduced a platform-specific
tweak that clears that bit and therefore forces the data mode to BCD.
This causes clock corruption and misinterpretation that has to be fixed up
by user-mode tools in system startup scripts as the initial clock is often
incorrect according to the BCD interpretation forced.
This change removes the hack; a comment included refers to alarm code,
but even if it was broken at one point by requiring the BCD mode, it
should have been trivially corrected and even if not, given how rarely the
alarm feature is used, that was not really a reasonable justification to
break the system clock that is indeed used by virtually everything. And
either way the alarm code has been since fixed anyway.
Signed-off-by: Maciej W. Rozycki <firstname.lastname@example.org>
Please apply -- this ends a long battle trying to track down where the
annoying clock corruption has come from.
diff --git a/arch/mips/mti-malta/malta-platform.c
index 4c35301..80562b8 100644
@@ -138,11 +138,6 @@ static int __init malta_add_devices(void)
- * Set RTC to BCD mode to support current alarm code.
- CMOS_WRITE(CMOS_READ(RTC_CONTROL) & ~RTC_DM_BINARY, RTC_CONTROL);