linux-kernel - Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

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:	Wed, 25 Mar 2015 22:22:30 +0100
From:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>
To:	Pavel Machek <pavel@....cz>
Cc:	NeilBrown <neilb@...e.de>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>, 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>,
	Grant Likely <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>, devicetree@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

Hi,

Am 25.03.2015 um 21:42 schrieb Pavel Machek <pavel@....cz>:

> Hi!
> 
>>> In the case of our GPS, it receives control over the serial connection from
>>> the UART,
>> 
>> Ahem - does it?
>> 
>> AFAIK the chip simply starts to emit NMEA records if powered on. There is no
>> command going over the serial interface to address it or control it.
> 
> Well _most_ GPSes enable you to control them over the serial
> line. (Things like sampling rate, AGPS data upload, …)

Yes, I know.

But is this something the kernel is/must be aware? And
must it be represented by the DT? Or does it have to influence
the way the DT is structured?

Well, if GPS data is presented through iio, these commands must
be handled by some driver.

> 
>>> I think the GPS is “primarily" a uart-attached device.
>> 
>> But not in the same way as an I2C device.
>> 
>> Especially the serial interface is not a bus and not used for signalling and
>> power control. It is payload data (only).
> 
> Serial interface looks a lot like a (point-to-point) bus to
> me. Similar to SATA, for example.

In that sense a gpio looks also a lot like a 1-bit bus...

Anyways, there are no subnodes (clients) of a gpio but the
<&gpiocontroller> pattern is used.

In other words: a driver that wants to control a gpio asks for a
reference of the gpio controller and uses the gpiolib to control it.

In the same way, a driver that wants to use an uart could ask
for a reference to the tty/uart driver and use some functions to
control it (and send commands). So a hypothetical gps-iio
driver could set sampling rate etc.

And it can also ask the tty/uart: „please register me and notify if
some syscall wants you to open() or close() so that I (the driver of
the GPS chip) can turn on power of the GPS chip (and only I know
how to do that - nobody else has to care)“.

I am just playing the Devil's advocate to find out what the really
common principle is and how the DT for clients of a serial interface
should really be represented in a DT in a way that is agnostic to
a specific driver structure, driver functions and user space.

And to find out if we need tty/slaves (as proposed in the title of this
patch series) at all. Or if there is a better way to describe the relation
of the gps chip driver and the tty/uart.

BR,
Nikolaus--
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/