From: dmukhin@xen.org
To: Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech,
julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
sstabellini@kernel.org, dmukhin@ford.com,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v7 02/16] xen/8250-uart: update definitions
Date: Tue, 9 Sep 2025 12:42:49 -0700 [thread overview]
Message-ID: <aMCDOUgqhQMYCjcK@kraken> (raw)
In-Reply-To: <54211c3c-f911-41c3-b4bd-1e27fcc09f93@suse.com>
On Tue, Sep 09, 2025 at 12:05:41PM +0200, Jan Beulich wrote:
> On 08.09.2025 23:11, dmukhin@xen.org wrote:
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
> > @@ -32,6 +32,7 @@
> > #define UART_MCR 0x04 /* Modem control */
> > #define UART_LSR 0x05 /* line status */
> > #define UART_MSR 0x06 /* Modem status */
> > +#define UART_SCR 0x07 /* Scratch pad */
> > #define UART_USR 0x1f /* Status register (DW) */
> > #define UART_DLL 0x00 /* divisor latch (ls) (DLAB=1) */
> > #define UART_DLM 0x01 /* divisor latch (ms) (DLAB=1) */
> > @@ -42,6 +43,8 @@
> > #define UART_IER_ETHREI 0x02 /* tx reg. empty */
> > #define UART_IER_ELSI 0x04 /* rx line status */
> > #define UART_IER_EMSI 0x08 /* MODEM status */
> > +#define UART_IER_MASK \
> > + (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
>
> Here, aiui, ..._MASK covers all known bits. No #define-s for reserved
> ones.
>
> > @@ -51,12 +54,19 @@
> > #define UART_IIR_THR 0x02 /* - tx reg. empty */
> > #define UART_IIR_MSI 0x00 /* - MODEM status */
> > #define UART_IIR_BSY 0x07 /* - busy detect (DW) */
> > +#define UART_IIR_FE 0xc0 /* FIFO enabled (2 bits) */
> >
> > /* FIFO Control Register */
> > #define UART_FCR_ENABLE 0x01 /* enable FIFO */
> > #define UART_FCR_CLRX 0x02 /* clear Rx FIFO */
> > #define UART_FCR_CLTX 0x04 /* clear Tx FIFO */
> > -#define UART_FCR_DMA 0x10 /* enter DMA mode */
> > +#define UART_FCR_DMA 0x08 /* enter DMA mode */
>
> Question is whether we can actually use the source you indicate as
> reference. TL16C550C may already be too different from what a "standard"
> 16550 is (where admittedly it also looks unclear what "standard" would be,
> as I'm unaware of a "canonical" spec).
Yeah, I am not sure there's a "standard" spec for NS16550.
>
> The source I'm looking at says something entirely different. Maybe we're
> better off simply omitting this #define?
All TL16Cx50 I have mentioned, including Synopsys uart databook, say
FCR's "DMA mode select" is Bit 3.
And Linux'es driver defines it as 0x08 (include/uapi/linux/serial_reg.h)
>
> > +#define UART_FCR_RSRVD0 0x10 /* reserved; always 0 */
> > +#define UART_FCR_RSRVD1 0x20 /* reserved; always 0 */
> > +#define UART_FCR_RTB0 0x40 /* receiver trigger bit #0 */
> > +#define UART_FCR_RTB1 0x80 /* receiver trigger bit #1 */
> > +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1)
>
> Continuing from the top comment - here, with the TRG infix, the scope is
> clear, too.
>
> > @@ -98,9 +108,30 @@
> > /* Modem Control Register */
> > #define UART_MCR_DTR 0x01 /* Data Terminal Ready */
> > #define UART_MCR_RTS 0x02 /* Request to Send */
> > -#define UART_MCR_OUT2 0x08 /* OUT2: interrupt mask */
> > +#define UART_MCR_OUT1 0x04 /* Output #1 */
> > +#define UART_MCR_OUT2 0x08 /* Output #2 */
> > #define UART_MCR_LOOP 0x10 /* Enable loopback test mode */
> > +#define UART_MCR_RSRVD0 0x20 /* Reserved #0 */
> > #define UART_MCR_TCRTLR 0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */
> > +#define UART_MCR_RSRVD1 0x80 /* Reserved #1 */
> > +#define UART_MCR_MASK \
> > + (UART_MCR_DTR | UART_MCR_RTS | \
> > + UART_MCR_OUT1 | UART_MCR_OUT2 | \
> > + UART_MCR_LOOP | UART_MCR_TCRTLR)
>
> Here it's again all non-reserved bits. Yet why do we need #define-s for
> the two reserved ones here? (Same question for FCR, even if there's no
> UART_FCR_MASK.)
>
> > +/* Modem Status Register */
> > +#define UART_MSR_DCTS 0x01 /* Change in CTS */
> > +#define UART_MSR_DDSR 0x02 /* Change in DSR */
> > +#define UART_MSR_TERI 0x04 /* Change in RI */
> > +#define UART_MSR_DDCD 0x08 /* Change in DCD */
> > +#define UART_MSR_CTS 0x10
> > +#define UART_MSR_DSR 0x20
> > +#define UART_MSR_RI 0x40
> > +#define UART_MSR_DCD 0x80
> > +#define UART_MSR_CHANGE \
> > + (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD)
> > +#define UART_MSR_STATUS \
> > + (UART_MSR_CTS | UART_MSR_DSR | UART_MSR_RI | UART_MSR_DCD)
>
> Here it's properly two subsets.
>
> > @@ -111,6 +142,7 @@
> > #define UART_LSR_THRE 0x20 /* Xmit hold reg empty */
> > #define UART_LSR_TEMT 0x40 /* Xmitter empty */
> > #define UART_LSR_ERR 0x80 /* Error */
> > +#define UART_LSR_MASK (UART_LSR_OE | UART_LSR_BI)
>
> But what's the deal here? Why would only two of the bits be covered?
>
> Jan
next prev parent reply other threads:[~2025-09-09 19:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 21:11 [PATCH v7 00/16] x86: introduce NS16550-compatible UART emulator dmukhin
2025-09-08 21:11 ` [PATCH v7 01/16] emul/vuart: introduce framework for UART emulators dmukhin
2025-09-10 7:57 ` Mykola Kvach
2025-09-13 18:09 ` dmukhin
2025-09-08 21:11 ` [PATCH v7 02/16] xen/8250-uart: update definitions dmukhin
2025-09-09 10:05 ` Jan Beulich
2025-09-09 19:42 ` dmukhin [this message]
2025-09-10 8:39 ` Mykola Kvach
2025-09-13 17:50 ` dmukhin
2025-09-08 21:11 ` [PATCH v7 03/16] emul/ns16x50: implement emulator stub dmukhin
2025-09-10 10:05 ` Mykola Kvach
2025-09-13 17:29 ` dmukhin
2025-11-14 5:19 ` dmukhin
2025-09-15 10:16 ` Mykola Kvach
2025-11-14 5:28 ` dmukhin
2025-09-08 21:11 ` [PATCH v7 04/16] emul/ns16x50: implement DLL/DLM registers dmukhin
2025-09-10 10:16 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 05/16] emul/ns16x50: implement SCR register dmukhin
2025-09-12 7:23 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 06/16] emul/ns16x50: implement IER/IIR registers dmukhin
2025-09-15 6:00 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 07/16] emul/ns16x50: implement LCR/LSR registers dmukhin
2025-09-15 6:00 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 08/16] emul/ns16x50: implement MCR/MSR registers dmukhin
2025-09-15 6:00 ` Mykola Kvach
2025-09-15 14:49 ` Jan Beulich
2025-09-16 8:00 ` Mykola Kvach
2025-09-16 14:13 ` Jan Beulich
2025-09-08 21:11 ` [PATCH v7 09/16] emul/ns16x50: implement RBR register dmukhin
2025-11-18 6:00 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 10/16] emul/ns16x50: implement THR register dmukhin
2025-11-18 6:00 ` Mykola Kvach
2026-05-14 23:23 ` dmukhin
2025-09-08 21:11 ` [PATCH v7 11/16] emul/ns16x50: implement FCR register (write-only) dmukhin
2025-11-18 6:00 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 12/16] emul/ns16550: implement dump_state() hook dmukhin
2025-11-18 6:00 ` Mykola Kvach
2026-05-14 23:35 ` dmukhin
2025-09-08 21:11 ` [PATCH v7 13/16] emul/ns16x50: add Kconfig options dmukhin
2025-11-18 6:00 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 14/16] x86/domain: enable per-domain I/O port bitmaps dmukhin
2025-11-18 6:00 ` Mykola Kvach
2026-05-14 23:52 ` dmukhin
2025-09-08 21:11 ` [PATCH v7 15/16] xen/domain: allocate d->irq_caps before arch-specific initialization dmukhin
2025-11-18 6:00 ` Mykola Kvach
2025-09-08 21:11 ` [PATCH v7 16/16] emul/ns16x50: implement IRQ emulation via vIOAPIC dmukhin
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=aMCDOUgqhQMYCjcK@kraken \
--to=dmukhin@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=dmukhin@ford.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--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.