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: <20160120174610.1c64239a@lxorguk.ukuu.org.uk>
Date:	Wed, 20 Jan 2016 17:46:10 +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

> The problem is that *I* have no control over user space. But I also don't want
> to say to my users "that is not my problem - get it solved yourself". This does
> not help them.

Stuffing things into the kernel because the user space of a given
platform can't get itself organised isn't helpful to the other billion
plus Linux devices out there.

> And, most device drivers are corner cases since they are special solutions
> for singular platforms.

Actually that is quite a small percentage - and the corner cases hide in
drivers not in the core code, which is really important for
maintainability.

> >> I'm glad - because it raises some hard questions and while I don't agree
> >> with some of your starting points (like needing to "open" a uart without
> >> user space
> 
> If have an idea how to turn off the device at boot time, before any user space
> daemon is running, we can of course ignore that.

Your early user space is responsible for it. If you can't accept that
then I don't see any point continuing the conversation.

> >> But see below as I think your mental model is perhaps wrong
> >> and this is a point of confusion ?
> 
> Maybe you do not accept that I want to keep as low level as reasonable (for me).

It's always "for me". No the kernel project is not "for me"

> >> Both of those techniques work in mainline without kernel changes (at
> >> least on devices where the right gpio sysfs nodes exist
> 
> they do not exist...

For most they do because they are gpio lines so exportable to userspace.

> >> This I think is actually the really hard and interesting part of the
> >> problem. The "tell me about open and close" case is simple and can be
> >> done via tty_port today with minimal extra hooks. There is a small
> >> question about how you set those hooks from a DT binding
> 
> tty has no binding. An UART hardware has. Another reason for me to
> start with UARTs.

Every uart is a tty_port, every non uart is a tty_port. There is no
reason you can't bind to a non uart device. Your current patches create
bindings for the uart layer.

> >> For some hardware that is the only way I know to do this because the
> >> power hungry uart receiver is physically powered down. I would have to
> >> check but I *think* that is true even on a modern x86 PC that supports
> >> wakeups via serial - although it may be well hidden in ACPI and firmware.
> 
> Yes, agreed. But the gpio + interrupt solution was not mainlineable as well.

That I am unsure about - at some point it is going to have to be sorted
because it is increasingly common (if currently mostly invisible)
 
> >> I'm not personally opoosed to the tty slave idea providing it ends up
> >> attached to the tty_port not just uart.
> 
> Well if you can tell us how to handle the data path I have no problems with it
> to attach to the tty level.

If your port is closed you have no data path. If you are using uart you
have no data path because while your patch hooks a helper that some uarts
use some of the time it's optional and a lot of uarts don't use it, so
its not even uart generic.

Alan