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

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

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:
> >> ... outside of __get_cmos_time()'s locked region. There's no need to hold
> >> the lock for these computations.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > 
> > Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Thanks.
> 
> > I had the same thought about moving the conversion out of the locked
> > region when reviewing the previous patch.
> > 
> > As noted in the previous patch, we should move the conversion of the
> > century field with the rest?
> 
> As said there, no, I don't think so.
> 
> >> ---
> >> 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.

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?

Thanks, Roger.