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:   Fri, 4 May 2018 22:03:15 +0200
From:   Pavel Machek <pavel@....cz>
To:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Andreas Kemnade <andreas@...nade.info>,
        Arnd Bergmann <arnd@...db.de>,
        "H . Nikolaus Schaller" <hns@...delico.com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/7] gnss: add new GNSS subsystem

Hi!

> > Finally, note that documentation (including kerneldoc) remains to be
> > written, but hopefully this will not hinder review given that the
> > current interfaces are fairly self-describing.
> 
> Great work. I like your design decisions. I have quite a few devices
> with have non-serial based GPS peripherals using binary protocols (*).
> As far as I can see it should be possible to add support for those.
> 
> I have one concern, though. While providing raw data by
> default is fine generally, it is a problem with device
> auto-discovery. I think there should be some IOCTL from
> the start, that can be used to inform userspace about
> the raw protocol being used (i.e. "NMEA"). I fear, that
> userspace may start to just assume raw = NMEA without
> having this (especially since all initial drivers provide
> NMEA).

Yep, that would be nice.

> (*) I have those in mind:
> 
> Nokia N900: The phone has GPS integrated into the modem and uses
> ISI encapsulated data. The protocol has been reverse engineered
> and it should be possible to write a kernel driver for handling
> the GPS packets and dumping the raw data to /dev/gnss0. I don't
> think this is particularly useful without a non-raw interface,
> though. It would still require a custom userspace implementation.

Actually... in this case it would be nice to do the protocol
processing in kernel and just present reasonable interface to
userland... or maybe NMEA.

> Droid 4: GPS is similar to N900, but different protocol and QMI
> encapsulated. This one also has known protocol with userspace
> implementation. I did not yet have a detailed look, if its possible
> to (un)wrap this in the kernel.

So, this is actually NMEA over QMI. I do have patches libqmi that
provides NMEA on stdout.

But there seems to be another possibile interface (yes, that modem is
crazy, and you can talk to it over few different interfaces), and
that's NMEA over GSM07.10. That one should be feasible to decode in
kernel and just provide NMEA to userland.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ