lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6241816.LpgjcNKrfa@diego>
Date:   Mon, 23 Mar 2020 09:25:57 +0100
From:   Heiko Stübner <heiko@...ech.de>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        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

Hi,

Am Donnerstag, 19. März 2020, 06:40:34 CET schrieb Lukas Wunner:
> On Wed, Mar 18, 2020 at 07:49:08PM +0100, Heiko Stübner wrote:
> > 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.
> 
> There are some more patches in the pipeline for the next cycle
> to add support for an rs485 bus termination GPIO.  They're on
> the tip of this branch:
> 
> https://github.com/RevolutionPi/linux/commits/revpi-4.19
> 
> Just so you know in advance and duplicate work is avoided.

do you plan on submitting these soonish? Because looking at your
termination-gpio change makes me want to do something similar for
my RE-gpio ... instead of trying to mangle this into the DTR thingy.


> > > 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).
> 
> Some UARTs allow disabling the receiver, this can be taken advantage of
> to implement half-duplex mode.  It's what I did in 8250_bcm2835aux.c.
> 
> On the Revolution Pi devices, !RE is usually connected to ground, so
> reception is always enabled and it cannot be disabled in software
> except by turning off the UART receiver.
> 
> There are also boards out there which connect !RE to RTS.  Then only
> half-duplex mode is supported by the hardware and there's no way for
> software to work around it.

yep and on our board we have DE and RE on separate gpios, so I guess
it makes sense to use that pin how it was intended ;-) .

So I guess having that as rs485-re-gpios property might be the best way.


Heiko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ