Message-ID: <ZUEJjdfk/vmH8XTR@shell.armlinux.org.uk>
Date:   Tue, 31 Oct 2023 14:05:01 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Théo Lebrun <theo.lebrun@...tlin.com>
Cc:     Hugo Villeneuve <hugo@...ovil.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Gregory CLEMENT <gregory.clement@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
        Tawfik Bayouk <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH 6/6] tty: serial: amba-pl011: Parse bits option as 5, 6,
 7 or 8 in _get_options

On Tue, Oct 31, 2023 at 02:51:45PM +0100, Théo Lebrun wrote:
> On Tue Oct 31, 2023 at 12:22 PM CET, Russell King (Oracle) wrote:
> > On Tue, Oct 31, 2023 at 12:04:11PM +0100, Théo Lebrun wrote:
> > > On Tue Oct 31, 2023 at 11:11 AM CET, Russell King (Oracle) wrote:
> > > > There is no point in supporting 5 or 6 bits for console usage. Think
> > > > about it. What values are going to be sent over the console? It'll be
> > > > ASCII, which requires at _least_ 7-bit. 6-bit would turn alpha
> > > > characters into control characters, punctuation and numbers. 5-bit
> > > > would be all control characters.
> > > >
> > > > So there's no point trying to do anything with 5 or 6 bits per byte,
> > > > and I decided we might as well take that as an error (or maybe a
> > > > case that the hardware has not been setup) and default to 8 bits per
> > > > byte.
> > > 
> > > I see your point. Two things come to mind:
> > > 
> > >  - I added this parsing of 5/6 bits to be symmetrical with
> > >    pl011_set_termios that handles 5/6 properly. Should pl011_set_termios
> > >    be modified then?
> >
> > Why should it? Note that I said above about _console_ usage which is
> > what you were referring to - the early code that sets up the console
> > by either reading the current settings (so that we can transparently
> > use the UART when its handed over already setup by a boot loader).
> >
> > This is completely different to what happens once the kernel is running.
> > Userspace might very well have a reason to set 5 or 6 bits if it wants
> > to communicate with a device that uses those sizes.
> >
> > However, such a device won't be a console for the reasons I outlined
> > above (it will truncate the ASCII characters turning console messages
> > into garbage.)
> 
> I'm not sure I get it. (1) We assume it is a console so it's ASCII so no
> reason to set to 5 or 6 bits per word. But (2) there might be a reason
> to set the UART to 5 or 6 bits, the userspace decides.

Precisely.

> How do the two interact? Say we boot to Linux, userspace configures to 6
> bits because reasons and we reset. At second probe we see a config of 6
> bits per word but assume that can't be logical, even though it is.

I think you're conflating "serial console" with "serial port". A
"serial port" can support multiple different formats, and in this case,
such as 5, 6, 7, and 8 bits. 5 and 6 bits are likely to be a specialised
application which uses a binary protocol, not ASCII.

A "serial console" is one application of a "serial port" and a "serial
console" is used to send ASCII characters, not a binary protocol.

> What makes us suppose at probe that it must be a console?

Sorry, but no, we don't assume every serial port is a serial console.
Unless something has changed since I was involved with the serial
layer, we only read the parameters from a serial port _if_ and only
if that port is being used as a serial console.

TTYs under Linux have a standard initial set of parameters at boot -
9600 baud, 8 bits, etc. The exception to this is if a serial port *is
being used* as a serial console, where these settings are overriden by
the serial console configuration. The reason for that is... imagine
the chaos that would occur if:

- Your boot loader configures (through user configuration) the serial
  port for 115200 baud.
- The boot loader loads the kernel and passes control to it, with
  a command line specifying that this serial port is to be used for
  the serial console, but not specifying any parameters.
- The kernel boots, and starts outputting messages at 115200 baud.
- Userspace starts running, opens /dev/console, and switches the port
  to 9600 baud. Now you have utter garbage being received from the
  serial console.

So, the serial console is special in that regard.

Now, when we configure the serial console, we attempt to:

1) parse the options provided on the console= line to set the serial
port appropriately, or
2) if there are no options, then we attempt to set the serial port to
something sane *for use as a serial console*, which uses ASCII protocol
not some random binary protocol. 5 and 6 bits make no sense here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists