linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Henrie <alexh@vpitech.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Johan Hovold <johan@kernel.org>,
	linux-usb@vger.kernel.org, alexhenrie24@gmail.com,
	Sergey Shtylyov <s.shtylyov@omp.ru>,
	Greg KH <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] USB: serial: cp210x: map B0 to B9600
Date: Mon, 28 Nov 2022 11:38:36 -0700	[thread overview]
Message-ID: <6063376.lOV4Wx5bFT@demeter> (raw)
In-Reply-To: <Y4T7+am39O2XNLZZ@shell.armlinux.org.uk>

On Monday, November 28, 2022 11:20:41 AM MST Russell King (Oracle) wrote:
> What exactly do you think should be done when a baud rate of zero is
> requested?

I see two reasonable options: Leave the baud rate alone, or reset it to the 
default (i.e. 9600). In my opinion, either of those options is just fine.

> The fact of the matter is that at hardware level, the UART takes a
> clock, and divides that down. To get to a baud rate of zero, one
> would need an infinitely large divisor, which (a) is impossible to
> program into the hardware and (b) would trigger a divide-by-zero
> error in the kernel. So, we have to choose something.
> 
> That decision was made before my time, when Ted Ts'o was maintaining
> what was the original serial.c 8250-based driver, and the behaviour
> he adopted was to set a baud rate of 9600 when B0 was requested,
> which is reasonable - 9600 baud is the default setting.
> 
> POSIX (which is what we use to define the behaviour of the TTY layer,
> or at least what we _used_ to) doesn't specify the behaviour of B0
> as the output rate, other than it shall cause the model control lines
> to be deasserted. What baud rate you get on the line is unspecified,
> and thus left up to the implementation.
> 
> So basically, 9600 baud for B0 is the behaviour of the 8250 driver
> going back to the very early Linux versions and that has become the
> standard Linux implementation shared by a great many serial drivers.
> In effect, it's almost a de-facto standard.

That is really interesting, thanks for the explanation! I like the idea of 
having consistent behavior across the Linux serial drivers, so it seems to me 
that mapping B0 to B9600 in all drivers is the way to go.

-Alex



  reply	other threads:[~2022-11-28 18:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-26  3:58 [PATCH] USB: serial: cp210x: map B0 to B9600 Alex Henrie
2022-11-26  7:10 ` Greg KH
2022-11-28 18:06   ` Alex Henrie
2022-11-26 10:34 ` Sergey Shtylyov
2022-11-28 14:41 ` Johan Hovold
2022-11-28 18:08   ` Alex Henrie
2022-11-28 18:20     ` Russell King (Oracle)
2022-11-28 18:38       ` Alex Henrie [this message]
2022-11-29 14:15     ` Johan Hovold
2022-11-29 17:48       ` Alex Henrie
2022-11-28 18:12 ` [PATCH v2] " Alex Henrie

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=6063376.lOV4Wx5bFT@demeter \
    --to=alexh@vpitech.com \
    --cc=alexhenrie24@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=s.shtylyov@omp.ru \
    /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 NNTP newsgroup(s).