linux-kernel - Re: GPIO-driven RTS on TI hardware with 8250

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: <5699870E.8080804@hurleysoftware.com>
Date:	Fri, 15 Jan 2016 15:55:58 -0800
From:	Peter Hurley <peter@...leysoftware.com>
To:	Ильяс Гасанов 
	<torso.nafi@...il.com>, "Matwey V. Kornilov" <matwey@....msu.ru>
Cc:	Andy Shevchenko <andy.shevchenko@...il.com>,
	Russell King <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: GPIO-driven RTS on TI hardware with 8250_omap driver

On 12/27/2015 04:47 AM, Andy Shevchenko wrote:
> +Peter, Russell, and Matwey.
> 
> I suggest you to ask people I added to the Cc list.
> 
> On Sat, Dec 26, 2015 at 6:17 PM, Ильяс Гасанов <torso.nafi@...il.com> wrote:
>> Hello.
>>
>> We are upgrading to the 4.1.x kernel for our smart metering appliance
>> project, which is based on TI's Sitara hardware (AM335x SoC), and I
>> decided to switch from omap-serial legacy driver to the newer
>> 8250-based one. It marginally increases throughput efficiency, CPU
>> cycle wise, among other goodies, but I'm looking to implement a rather
>> important feature that is present in the legacy driver, but the newer
>> one is lacking.
>>
>> Namely, our project makes use of RS232<->RS485 converters, which in
>> turn need to consume RTS signals to switch between Rx and Tx modes at
>> the RS485 side, due to the bus variant we use being half-duplex.
>> However, the already manufactured hardware is already designed to make
>> the use of certain pins to take the RTS signal from, which can only be
>> configured as GPIO for that purpose (in other words, no "native" UART
>> RTS) - and basically redesigning the h/w configuration now is
>> definitely out of question. The omap-serial driver already provides
>> FDT options for that, named "rts-gpio", "rs485-rts-active-high" etc.
>>
>> As far as I could ascertain, the 8250_omap driver (as well as the 8250
>> framework itself) at the moment lacks the means to make use of GPIO
>> pins for that purpose. While trying to implement it myself, I noticed
>> that the legacy driver has it made in a comparably straightforward
>> approach, via dispatching the code to switch the pin in its .start_tx
>> and .stop_tx handlers, and some timing adjustments. Unfortunately, the
>> situation with 8250-based drivers is different - the aforementioned
>> handlers are provided by the 8250_core module and are common for all
>> drivers within the framework.
>>
>> At first, I thought that implementing such feature for the 8250
>> framework itself sounds like a good idea, but after reading this
>> particular post:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271377.html
>> I decided to comply with the point of view specified there. However,
>> I'm not that familiar with the 8250 framework internals (or serial
>> internals at all, for that matter), and my time is quite short, so I
>> would appreciate much any useful directions on how to do it
>> hardware-specific style, which functions/structs/handlers to use, etc.

Please use the helpers in serial_mctrl_gpio.c if you try this.

And please build on top of Matwey's patches, as those will likely be
the rs485 implementation for the 8250_omap driver soon.


>> Of particular interest is the following part:
>>
>>> I don't care whether the drive does it via serial_out magic or a more explicit hook but it doesn't belong here in core code.
>>
>> Any ideas/clarifications on what might be meant on that part?

What Alan means here is encapsulate gpio-as-RTS where RTS is actually
read/written rather than all over the the code.

Regards,
Peter Hurley