From: "Roger Pau Monné" <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v2 1/4] x86/time: CMOS RTC may run in binary mode
Date: Wed, 2 Sep 2026 11:17:36 +0200 [thread overview]
Message-ID: <apfpsDOuYZ4RGyhW@macbook.local> (raw)
In-Reply-To: <6dd4c596-aebd-4488-94da-35fb9d85d6ac@suse.com>
On Wed, Sep 02, 2026 at 11:02:43AM +0200, Jan Beulich wrote:
> On 02.09.2026 10:04, Roger Pau Monné wrote:
> > On Thu, Jul 02, 2026 at 11:29:11AM +0200, Jan Beulich wrote:
> >> --- a/docs/misc/xen-command-line.pandoc
> >> +++ b/docs/misc/xen-command-line.pandoc
> >> @@ -339,6 +339,14 @@ parameter to "stable:socket".
> >> Specify the event count threshold for raising Corrected Machine Check
> >> Interrupts. Specifying zero disables CMCI handling.
> >>
> >> +### cmos-rtc-bcd (x86)
> >> +> `= <boolean>`
> >> +
> >> +> Default: `false`
> >> +
> >> +Flag to indicate the CMOS Real Time Clock uses BCD mode irrespective of
> >> +control register B indicating binary mode.
> >> +
> >
> > Likely too late for it now, but I get the feeling we should have
> > introduced a cmos option, with rtc-bcd and rtc-probe as boolean sub
> > options:
> >
> > cmos = [ rtc-probe, rtc-bcd ]
>
> I was thinking the same - would be nice, but here we are.
>
> >> @@ -1353,6 +1356,48 @@ static bool __init cmos_rtc_probe(void)
> >> return false;
> >> }
> >>
> >> +static inline bool __init attr_const is_bcd(unsigned int x)
> >> +{
> >> + return (x & 0xf) < 10 && (x >> 4) < 10;
> >> +}
> >> +
> >> +static void __init cmos_rtc_probe_bcd(void)
> >> +{
> >> + bool bcd;
> >> + unsigned long flags;
> >> +
> >> + if ( opt_cmos_rtc_bcd )
> >> + return;
> >> +
> >> + spin_lock_irqsave(&rtc_lock, flags);
> >> + bcd = !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY);
> >> + spin_unlock_irqrestore(&rtc_lock, flags);
> >> +
> >> + if ( bcd )
> >> + return;
> >> +
> >> + for ( unsigned int seclo = 0; ; )
> >> + {
> >> + struct rtc_time rtc;
> >> +
> >> + if ( !__get_cmos_time(&rtc) ||
> >> + !is_bcd(rtc.sec) ||
> >> + !is_bcd(rtc.min) ||
> >> + !is_bcd(rtc.hour) ||
> >> + !is_bcd(rtc.day) ||
> >> + !is_bcd(rtc.mon) )
> >> + return;
> >> +
> >> + if ( seclo > (rtc.sec & 0xf) )
> >> + break;
> >> +
> >> + seclo = rtc.sec & 0xf;
> >
> > Is there a risk of this loop triggering the watchdog, and hence we
> > should process softirqs in the loop? (or otherwise have some kind of
> > hard loop stop after certain iterations / time)
> >
> > Oh, I now see the mention in the commit message and also note this is
> > done ahead of SMP and also ahead of the watchdog being enabled, hence
> > it can't trigger the watchdog.
>
> Right. I can't conclude whether you're asking for any change here, as
> there also was no ack.
Hehe, I guess I was probing whether you wanted to do anything about
the proliferation of cmos related top-level options.
Acked-by: Roger Pau Monné <roger@xenproject.org>
Albeit I think it would be nice to introduce a common cmos option in a
future patch and deprecate the separate top-level ones.
Thanks, Roger.
next prev parent reply other threads:[~2026-09-02 9:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 9:25 [PATCH v2 0/4] x86/time: CMOS RTC century byte Jan Beulich
2026-07-02 9:29 ` [PATCH v2 1/4] x86/time: CMOS RTC may run in binary mode Jan Beulich
2026-07-28 14:25 ` Roger Pau Monné
2026-09-02 8:04 ` Roger Pau Monné
2026-09-02 9:02 ` Jan Beulich
2026-09-02 9:17 ` Roger Pau Monné [this message]
2026-07-02 9:30 ` [PATCH v2 2/4] time: shorten year determination loop Jan Beulich
2026-07-28 15:02 ` Roger Pau Monné
2026-09-02 8:05 ` Roger Pau Monné
2026-07-02 9:30 ` [PATCH v2 3/4] x86/vRTC: the use_timer field is a boolean one Jan Beulich
2026-07-29 7:47 ` Roger Pau Monné
2026-09-02 8:05 ` Roger Pau Monné
2026-07-02 9:31 ` [PATCH v2 4/4] x86/vRTC: support century field Jan Beulich
2026-07-29 8:45 ` Roger Pau Monné
2026-09-02 8:07 ` Roger Pau Monné
2026-09-02 9:20 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apfpsDOuYZ4RGyhW@macbook.local \
--to=roger@xenproject.org \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=teddy.astie@vates.tech \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.