From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin-patches@cygwin.com
Subject: Re: fhandler_serial.cc: MARK and SPACE parity for serial port
Date: Thu, 28 Jan 2021 11:45:46 -0700 [thread overview]
Message-ID: <a4cffe34-479b-d787-cc28-4bc03121304e@SystematicSw.ab.ca> (raw)
In-Reply-To: <6c0a481b-b6fb-0a7e-66ef-36e1941397bb@SystematicSw.ab.ca>
On 2021-01-28 10:17, Brian Inglis wrote:
> On 2021-01-28 03:14, Corinna Vinschen via Cygwin-patches wrote:
>> On Jan 28 11:08, Corinna Vinschen via Cygwin-patches wrote:
>>> Hi Marek,
>>> thanks for the patch. [...]
>>>> index 17e8d83a3..933851c21 100644
>>>> --- a/winsup/cygwin/include/sys/termios.h
>>>> +++ b/winsup/cygwin/include/sys/termios.h
>>>> @@ -185,6 +185,7 @@ POSIX commands */
>>>> #define PARODD 0x00200
>>>> #define HUPCL 0x00400
>>>> #define CLOCAL 0x00800
>>>> +#define CMSPAR 0x40000000 /* Mark or space (stick) parity. */
>>
>> Why did you choose such a big value here? Wouldn't it be nicer just to
>> follow up with
>>
>> #define CMSPAR 0x10000
>>
>> or am I missing something here?
>
> GLIBC/Linux compatibility:
> https://sourceware.org/git/?p=glibc.git&a=search&h=HEAD&st=grep&s=define+CMSPAR
>
> sysdeps/unix/sysv/linux/alpha/bits/termios-baud.h
> 23 #ifdef __USE_MISC
> 24 # define CBAUD 0000037
> 25 # define CBAUDEX 0000000
> 26 # define CMSPAR 010000000000 /* mark or space (stick) parity */
> 27 # define CRTSCTS 020000000000 /* flow control */
> 28 #endif
> sysdeps/unix/sysv/linux/bits/termios-baud.h
> 23 #ifdef __USE_MISC
> 24 # define CBAUD 000000010017 /* Baud speed mask (not in POSIX). */
> 25 # define CBAUDEX 000000010000 /* Extra baud speed mask, included in CBAUD.
> 26 (not in POSIX). */
> 27 # define CIBAUD 002003600000 /* Input baud rate (not used). */
> 28 # define CMSPAR 010000000000 /* Mark or space (stick) parity. */
> 29 # define CRTSCTS 020000000000 /* Flow control. */
> 30 #endif
> sysdeps/unix/sysv/linux/powerpc/bits/termios-baud.h
> 23 #ifdef __USE_MISC
> 24 # define CBAUD 0000377
> 25 # define CBAUDEX 0000020
> 26 # define CMSPAR 010000000000 /* mark or space (stick) parity */
> 27 # define CRTSCTS 020000000000 /* flow control */
> 28 #endif
> sysdeps/unix/sysv/linux/sparc/bits/termios-baud.h
> 23 #ifdef __USE_MISC
> 24 # define CBAUD 0x0000100f
> 25 # define CBAUDEX 0x00001000
> 26 # define CIBAUD 0x100f0000 /* input baud rate (not used) */
> 27 # define CMSPAR 0x40000000 /* mark or space (stick) parity */
> 28 # define CRTSCTS 0x80000000 /* flow control */
> 29 #endif
>
>> Also, on second thought I think CMSPAR should follow CRTSCTS, a few
>> lines below, because of its numerical value higher than CRTSCTS.
>
> GLIBC/Linux normally has it lower:
> $ grep -C2 'define\s\+CMSPAR' /usr/include/**/*.h
> /usr/include/asm-generic/termbits.h:
> #define B4000000 0010017
> #define CIBAUD 002003600000 /* input baud rate */
> #define CMSPAR 010000000000 /* mark or space (stick) parity */
> #define CRTSCTS 020000000000 /* flow control */
>
> --
> /usr/include/i386-linux-gnu/bits/termios.h:
> #ifdef __USE_MISC
> # define CIBAUD 002003600000 /* input baud rate (not used) */
> # define CMSPAR 010000000000 /* mark or space (stick) parity */
> # define CRTSCTS 020000000000 /* flow control */
> #endif
Linux may have inherited this from early Unix, UART, or serial I/O mux docs as
they use octal, support split input/output speeds, are 16 bit aligned, and some
of the fields are direct from UART register docs:
3:0 output baud rate enum
6:4 output data and stop bit lengths in UART line control register low bits
11:7 output parity and other control and/or status
12 output baud rate high speed extension
15:13 unused
19:16 input baud rate enum
22:20 input data and stop bit lengths in UART line control register low bits
27:23 input parity and other control and/or status
28 input baud rate high speed extension
29 unused
30 mark or space (stick) parity
31 flow control
Cygwin currently supports only up to B3000000 0x100f and cannot easily support:
#define B3500000 0010016
#define B4000000 0010017
as bit 3 is already and differently used.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
next prev parent reply other threads:[~2021-01-28 18:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-27 20:30 Marek Smetana
2021-01-28 10:08 ` Corinna Vinschen
2021-01-28 10:14 ` Corinna Vinschen
2021-01-28 17:17 ` Brian Inglis
2021-01-28 18:45 ` Brian Inglis [this message]
2021-01-29 22:06 ` Marek Smetana
2021-02-01 9:40 ` Corinna Vinschen
2021-02-01 21:26 ` Marek Smetana
2021-02-02 5:28 ` Brian Inglis
2021-02-02 9:44 ` Corinna Vinschen
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=a4cffe34-479b-d787-cc28-4bc03121304e@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin-patches@cygwin.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).