linux-kernel - Re: [Gta04-owner] [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:	Sun, 17 Jan 2016 14:19:12 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	"H. Nikolaus Schaller" <hns@...delico.com>
Cc:	Rob Herring <robh@...nel.org>,
	Vostrikov Andrey <andrey.vostrikov@...entembedded.com>,
	Mark Rutland <mark.rutland@....com>,
	Peter Hurley <peter@...leysoftware.com>,
	Rob Herring <robherring2@...il.com>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>, tomeu@...euvizoso.net,
	NeilBrown <neil@...wn.name>, Arnd Bergmann <arnd@...db.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Marek Belisko <marek@...delico.com>
Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

> When translating the system requirements you have provided and mixing
> with mine, I think we need:
> 
> 1. mechanism to receive characters sent by the peer MCU

Low level driver queue of some kind

> 2. mechanism to send characters to the peer (or a block for firmware download)

Ditto (maybe even netlink)

> 3. mechanism to open/close the UART (even if there is no user space/tty client)

So don't use the tty layer in the first place

> 4. mechanism to set the struct termios of the UART (baud rate etc.)

Can be done without the tty layer.

> 5. mechanism to be notified that user space has opened/closed the tty port or changes mctrl
> 6. mechanism to prevent the tty layer to present a /dev/tty* to user space at all

This sounds the wrong way up entirely.

Instead of trying to make the tty layer do weird stuff, make the driver
present a tty that is only the things that it wants to be exposed as a
tty if any. If there are none then don't use the tty layer at all.

We have lots of interfaces to random MCUs. Many of them talk "serial"
protocols, almost none of them pretend to be the tty layer.

Alan