Re: [PATCH v5 00/10] Add RS485 support to DW UART

From: Greg KH <gregkh@linuxfoundation.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-serial@vger.kernel.org, "Jiri Slaby" <jirislaby@kernel.org>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Vicente Bergas" <vicencb@gmail.com>,
	"Johan Hovold" <johan@kernel.org>,
	heiko@sntech.de, giulio.benetti@micronovasrl.com,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v5 00/10] Add RS485 support to DW UART
Date: Tue, 26 Apr 2022 14:49:00 +0200	[thread overview]
Message-ID: <YmfqPMyYLAXw1BNo@kroah.com> (raw)
In-Reply-To: <20220426122448.38997-1-ilpo.jarvinen@linux.intel.com>

On Tue, Apr 26, 2022 at 03:24:38PM +0300, Ilpo Järvinen wrote:
> This patchset adds RS-485 support to the DW UART driver. The patchset
> has two main parts. The first part adds HW support for RS-485 itself
> in various modes of operation and the second part focuses on enabling
> 9th bit addressing mode that can be used on a multipoint RS-485
> communications line.
> 
> To configure multipoint addressing, ADDRB flag is added to termios
> and two new IOCTLs are added into serial core. Lukas Wunner brought up
> during v1 review that if this addressing is only going to be used with
> RS-485, doing it within rs485_config would avoid having to add those
> IOCTLs. There was some counterexample w/o further details mentioned for
> RS-232 usage by Andy Shevchenko. I left the IOCTL approach there but if
> somebody has further input on this, please voice it as it is user-space
> facing API.
> 
> I decided to rewrite the UART_CAP_NOTEMT patch from scratch myself
> based on Uwe Kleine-König's earlier suggestion and include it to this
> series. To make waiting for a single character easy and to avoid
> storing it per purpose in the uart drivers, I decided to add
> frame_time into uart_port. It turned out to beneficial also for serial
> core which had to reverse calculate it from uart_port->timeout). I was
> thinking of removing uart_port->timeout entirely and derive the value
> timeout from frame_time and fifosize where needed but I was not sure
> if that's ok to do lockingwise (not that fifosize is a variable that
> is expected to change so maybe I'm just being too cautious).

I've applied the first 4 now, thanks.

greg k-h