All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.