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  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, 19 Oct 2014 21:51:27 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Marek Belisko <marek@...delico.com>
Cc:	gregkh@...uxfoundation.org, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, grant.likely@...aro.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	NeilBrown <neilb@...e.de>,
	"H. Nikolaus Schaller" <hns@...delico.com>
Subject: Re: [PATCH 1/2] misc: Add Wi2Wi w2sc0004 gps driver

On Thursday 16 October 2014 22:26:22 Marek Belisko wrote:
> This is a driver for the Wi2Wi GPS modules connected through an UART.
> The tricky part is that the module is turned on or off by an impulse
> on the control line - but it is only possible to get the real state by monitoring
> the UART RX input. Since the kernel can't know in which status the module
> is brought e.g. by a boot loader or after suspend, we need some logic to handle
> this.
> 
> The driver allows two different methods to enable (and power up) GPS:
> a) through rfkill
> b) as a GPIO
> 
> The GPIO enable can be plumbed to other drivers that expect to be able to control
> a GPIO. On the GTA04 board this is the DTR-gpio of the connected UART so that
> opening the UART device enables the receiver and closing it shuts the receiver down.
> 
> Original implementation by Neil Brown, fixes + DT bindings by H. Nikolaus Schaller

I'm not sure if this is a good way to model the device. You say that it's
connected to a UART, but the code itself has no reference to the tty layer
at all. I assume the actual driver is in user space and it would open the
UART and this control device as separate instances handles and then try
to coordinate them. Is that right?

What is the protocol for the GPS driver itself? Is it standardized?
Would it help to have a TTY line discipline for the GPS mode instead
so the power management and startup could be integrated into the serial
port management instead?

	Arnd
--
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/

Powered by blists - more mailing lists