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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.05.2026 21:08, Roger Pau Monné wrote:
> 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.

Well, it does affect the format of the field, but not right when the bit
is written. Aiui it will have an effect when the next update cycle runs,
as then the right kind of arithmetic (BCD or binary) need to be applied
by the chip (or what was a separate chip back at the time when those
specs were written). (The other "written by the processor program" of
course applies when date/time are fully updated. At that point the OS
can pick DM to its liking, and it would then better store the date/time
fields in the respective format.)

Jan