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

[Jan Beulich <jbeulich@xxxxxxxx>]

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).

Jan