[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200318153754.dctd4q7e2fodeqsw@wunner.de>
Date: Wed, 18 Mar 2020 16:37:54 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Heiko Stuebner <heiko@...ech.de>
Cc: gregkh@...uxfoundation.org, jslaby@...e.com,
matwey.kornilov@...il.com, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] serial: 8250: Add rs485 emulation to 8250_dw
On Wed, Mar 18, 2020 at 04:43:20PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 18, 2020 at 03:26:33PM +0100, Heiko Stuebner wrote:
> > This series tries to revive the work of Giulio Benetti from 2018 [0]
> > which seemed to have stalled at that time.
Oh dear. :-( This needs a rebase on current tty-next.
Patch [7/7] is already in tty-next as commit fe7f0fa43cef ("serial:
8250: Support rs485 devicetree properties").
Patch [4/7] likewise. Note that it's not safe to call ->rs485_config()
already in serial8250_register_8250_port() if the driver uses UPF_IOREMAP
because ioremapping happens later via serial8250_config_port() ->
serial8250_request_std_resource(), so you'll get an oops for those
drivers when deasserting RTS early on. Been there... :-(
Patch [6/7]: Ugh, another duplication of the ->rs485_config() callback.
Just use the generic one introduced by commit 283e096ffb70 ("serial:
8250: Deduplicate ->rs485_config() callback") if possible.
The other patches appear to handle chip-specific needs. It's now
possible to implement these in ->rs485_start_tx() and ->rs485_stop_tx()
hooks, as introduced by commit 058bc104f7ca ("serial: 8250: Generalize
rs485 software emulation"). Refer to commit f93bf7589114 ("serial:
8250_bcm2835aux: Support rs485 software emulation") for an example.
The DTR-for-RE thing seems a bit nonstandard, I'm not sure if this is
eligible for mainline or if it's something that should be kept in your
downstream tree. But no harm in submitting it to the list.
Thanks,
Lukas
Powered by blists - more mailing lists