linux-kernel - Re: [PATCH 0/4] UART slave device support

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]

Date:	Fri, 7 Aug 2015 15:01:47 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	NeilBrown <neil@...wn.name>
Cc:	Mark Rutland <mark.rutland@....com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Peter Hurley <peter@...leysoftware.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	Rob Herring <robherring2@...il.com>,
	Pavel Machek <pavel@....cz>,
	Grant Likely <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>,
	GTA04 owners <gta04-owner@...delico.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] UART slave device support - version 4

Hi Neil,

first, this is a *VERY* interesting and much needed patch series,
I intend to look closer at it, and if possible test it with some
(heh) board file device. Would be happy of you put me on CC for these.

On Mon, May 11, 2015 at 3:56 AM, NeilBrown <neil@...wn.name> wrote:

>  When a device is connected to a UART via RS-232 (or similar), there
>  is a DTR line that can be used for power management, and other "modem
>  control" lines.
>
>  On an embedded board, it is very likely that there is no "DTR", and
>  any power management need to be done using some completely separate
>  mechanism.
>
>  So these "slaves" are really just for devices permanently attached to
>  UARTs without a full "RS-232" (or similar) connection.  The driver
>  does all the extra control beyond Tx/Rx.

What is usually happening (and I have seen it in a few places) is that
the SoC has *one* fully featured RS232 with CTS/RTS and even
DTS,DCD,RI and other esoterica, which is intended to be connected to a
host serial port or so, for example if this SoC is to act as a modem
or a fax machine, or if it is to drive one.

Then they often have a few more UART blocks, usually identical, which
only have RxD+TxD available, so they are "just" UARTs.

To complicate things further, you may wonder what happened with
the CTS/RTS (etc) signals from the other blocks. Usually they are there
in the silicon but just routed to dead ends.

To complicate it even further, usually all these pins are placed under
pin control multiplexing, so in an actual electronic design, the
system will mux out CTS/RTS (etc) from the fully featured RS232
blocks and only use them as UARTs anyways.

Then there are those who created real simple RxD/TxD-only UARTs
("yeah lets dump this RS232 legacy crap" / "yeah yeah")
and then realized they want to drive modems ("oh crap, it seemed
like a good idea at the time"). Then they usually take
two GPIO pins for CTS/RTS and drive them as GPIOs using
software and you have a cheap 4-line modem line. This is what
drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.

> I've tested this set and it seems to work ... except that something
>  is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>  tested the GPS driver.  I guess it is time to rebase to -rc3.

You have a hardware taget I see. Which one?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/