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]

Message-ID: <20160117193849.69d00c28@lxorguk.ukuu.org.uk>
Date:	Sun, 17 Jan 2016 19:38:49 +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

> 3. mechanism to open/close the UART by the peer driver (for power management of the
> UART), even if it there is a user-space tty client for the same UART which might or might
> not be open at any time. Manage that in an optimal way.

Power management doesn't have to go via the uart layer. You can even
manage it via the existing sysfs power interfaces (and some Android
devices do in fact do exactly that either by controlling the uart pm or
using a gpio line). Not pretty either but means people are only peeing
in their own backyard. What goes into the kernel costs *everyone*, what
goes in device user space costs only the perpetrator.

It would help to rewind and understand what your needs are not what your
implementation as it stands is. Why can't you just use hciattach like
everyone else ? Improving the PM logic by refining the existing hci
ldisc to be power smart so everyone benefits from any improvement might
be a useful other discussion.

The 8686 is already working in serial mode  with no kernel hackery on
other boards.

> For the GPS chip I am only interested in mctrl and if characters are received. But
> I still want them to arrive at user space through a standard tty interface. So a solution
> that does not interwork and cooperate with the tty layer is not a useable solution for
> my requirements.

Why does it matter how they arrive so long as your user space can
interpret it correctly. Or is your user space some proprietary blob you
can't change ?

Them arriving by a tty interface is fine - no issue with that providing
it doesn't need to mess up core code.

> The reason appears to sit here:
> 
> http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725
> 
> This means that as soon as some UART is successfully probed, a new tty
> interface is created for it. So we simply have to optionally disable it. This is
> described by requirement 6.

You can just report EBUSY in your open method. You don't need to touch
the serial core layer. It's quite sufficient to do

	if (busy)
		return -EBUSY;

at the top of your uart open method.

> UART drivers we have and work with any of them. This is why I think
> serial-core and struct uart_port is the right level. Even if it looks like a hack.

Your "looks like" instinct is IMHO bang on - looks like a hack, is a
hack. It's also unnecessary as you can hide it in your open method if you
must do that.

> So please wait until I have updated the patch set of our proposal. Then you
> can see that we do not directly touch the tty layer.

The uart layer is part of the tty layer. It's just a glue library to make
writing some tty drivers a bit easier. It's tied deeply to the tty_port
implementation. One day it might even cease to exist replaced by more
generic tty_port helpers.

The tty layer is also an *abstract* concept. There is no real world tie
between physical collections of shift registers that dribble bits to one
another and tty devices in the kernel. You only need a tty driver for
certain types of user interaction.

Alan