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

On Mon, 18 Jan 2016 22:03:19 +0000
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:

> > > Your user space can do it (as most Android does).
> > 
> > How can it do it in automatically in a standardized way without need for daemon support?
> 
> You don't need to - it can be device specific. In Android it usually is.
> I've never understood why low end devices don't also abstract user space
> descriptions of power control into DT nodes as well as kernel properties ?
> 
Well, on these android devices, they are only intended to run android and
have another abstraction layer where you can hide things.
If doing actions on opening or closing a tty should not be implemented in
kernel space, then an alternative I see would be to at least have proper
rfkill support for bluetooth and gps in kernel. Then userspace can at least
can talk to a standardised interface. So userspace just has to implement
generic things.

That would mean for the kernel drivers needed:


W2CBW003/bluetooth:
   map the rfkill to just a simple regulator

W2SG0004/gps:
   being notified about incoming data
     a) the nice way: getting it from the tty/tty_port layer
 	(but requiring changes at generic kernel code)
        or
     b) the ugly way:
        remux the data line as a gpio and simply look for state
        changes during rfkill call (probably only during unblock)
	The first characters after power on would probably be lost
        toggle a gpio depending on the desired and detected state

Regards,
Andreas

Content of type "application/pgp-signature" skipped