Re: [PATCH 2/5] x86/time: move BCD_TO_BIN() uses

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, May 13, 2026 at 05:15:41PM +0200, Jan Beulich wrote:
> On 13.05.2026 16:58, Roger Pau Monné wrote:
> > On Wed, May 13, 2026 at 12:39:46PM +0200, Jan Beulich wrote:
> >> On 13.05.2026 10:56, Roger Pau Monné wrote:
> >>> On Tue, May 12, 2026 at 04:59:03PM +0200, Jan Beulich wrote:
> >>>> ---
> >>>> How come RTC_ALWAYS_BCD is compile-time constant 1? And then even with an
> >>>> inverted comment? Looks like we've inherited this from Linux, and even in
> >>>> Linus'es current tree it's still this same way. Yet all half-way recent
> >>>> chipsets I'm aware of properly implement the DM bit in reg B. Might this
> >>>> be another 32-bit leftover?
> >>>
> >>> *shrugs* I don't know.  Seems like Linux is still doing it, so it's
> >>> likely safer for us to continue doing it also?  We had no reports of
> >>> it being problematic, albeit one could argue it would be best to
> >>> prevent such reports by doing the right thing.
> >>
> >> That's my point. If we did this as specified, we'd unbreak systems with the
> >> DM bit set correctly, but we'd break (hypothetical) systems with it bogusly
> >> set. Like with a few other fixes, perhaps we should correct it, but provide
> >> a command line option to restore old behavior?
> > 
> > Possibly, but I would do after 4.22 has branched, just in case.
> 
> Of course.
> 
> > One thing I've noticed, is that Xen don't attempts to set
> > RTC_DM_BINARY in REG_B, shouldn't it try to set the bit when probing
> > for the CMOS?  Since it assumes BCD mode it should at least try to set
> > it?
> 
> For one - don't you mean "clear it"? But then - no, that bit is purely
> informational aiui. Changing it won't alter what the date/time registers
> hold (only how they're updated). Hence by fiddling with it we'd corrupt
> information (breaking OSes which properly respect the bit).

Yes, sorry, clear it.  The (possibly very outdated) specification I
have contains:

DM – The data mode (DM) bit indicates whether time
and calendar updates are to use binary or BCD formats. The
DM bit is written by the processor program and maybe read
by the program, but is not modified by any internal functions
or RESET. A "1" in DM signifies binary data, while a "0" in
DM specifies binary-coded-decimal (BCD) data.

To me the "DM bit is written by the processor program" reads as if it
could be set by the OS, but maybe that just means the bit is writable,
but it doesn't affect the format of the field really.

Thanks, Roger.