All of lore.kernel.org
 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 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.