linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Lukas Wunner <lukas@wunner.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	gregkh@linuxfoundation.org, jslaby@suse.com,
	matwey.kornilov@gmail.com, linux-serial@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] serial: 8250: Add rs485 emulation to 8250_dw
Date: Wed, 18 Mar 2020 19:49:08 +0100	[thread overview]
Message-ID: <5640842.EtOnNDtpGh@diego> (raw)
In-Reply-To: <20200318153754.dctd4q7e2fodeqsw@wunner.de>

Hi,

Am Mittwoch, 18. März 2020, 16:37:54 CET schrieb Lukas Wunner:
> 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.

Looking at tty-next I notice that you're right. When I started working
on this I only found the stuff from 2018 I linked to but didn't imagine
that in that exact moment someone else would also work on that area.

So no worries, I'll adapt my code ;-)


> 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.

Thanks for the pointers and also doing all that ground work :-)


> 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.

I'm fine either way - maybe I also get a pointer on what may be a better
approach ;-)

At least DTR as "Data Terminal Ready" did sound somewhat matching for
the "Receive Enable" of RS485 (and it's also the only other output pin
in the mctrl gpio list).


Heiko



  parent reply	other threads:[~2020-03-18 18:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 14:26 [PATCH 0/7] serial: 8250: Add rs485 emulation to 8250_dw Heiko Stuebner
2020-03-18 14:26 ` [PATCH 1/7] serial: 8250: Make em485_rts_after_send() set mctrl according to rts state Heiko Stuebner
2020-03-18 14:26 ` [PATCH 2/7] serial: 8250: add serial_in_poll_timeout helper Heiko Stuebner
2020-03-18 15:09   ` Andy Shevchenko
2020-03-18 14:26 ` [PATCH 3/7] serial: 8250: Handle case port doesn't have TEMT interrupt using em485 Heiko Stuebner
2020-03-18 14:26 ` [PATCH 4/7] serial: 8250: Start rs485 after registering port if rs485 is enabled in probe Heiko Stuebner
2020-03-18 14:26 ` [PATCH 5/7] serial: 8250: handle DTR in rs485 emulation Heiko Stuebner
2020-03-18 14:26 ` [PATCH 6/7] serial: 8250_dw: add em485 support Heiko Stuebner
2020-03-18 15:15   ` Andy Shevchenko
2020-03-18 14:26 ` [PATCH 7/7] serial: 8250_dw: allow enable rs485 at boot time Heiko Stuebner
2020-03-18 15:16   ` Andy Shevchenko
2020-03-18 18:28     ` Heiko Stübner
2020-03-18 18:31       ` Heiko Stübner
2020-03-18 14:43 ` [PATCH 0/7] serial: 8250: Add rs485 emulation to 8250_dw Andy Shevchenko
2020-03-18 15:37   ` Lukas Wunner
2020-03-18 15:54     ` Andy Shevchenko
2020-03-18 18:49     ` Heiko Stübner [this message]
2020-03-19  5:40       ` Lukas Wunner
2020-03-23  8:25         ` Heiko Stübner
2020-03-23 13:17           ` Lukas Wunner
2020-03-23 13:41             ` Andy Shevchenko
2020-03-25 13:41               ` Heiko Stübner
2020-03-25 14:42                 ` Andy Shevchenko
2020-03-18 15:13 ` Andy Shevchenko

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=5640842.EtOnNDtpGh@diego \
    --to=heiko@sntech.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=matwey.kornilov@gmail.com \
    /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).