LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org> To: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hovold <johan@kernel.org>, Sebastian Reichel <sebastian.reichel@collabora.co.uk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Andreas Kemnade <andreas@kemnade.info>, Arnd Bergmann <arnd@arndb.de>, "H . Nikolaus Schaller" <hns@goldelico.com>, Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>, devicetree@vger.kernel.org Subject: Re: [PATCH 0/7] gnss: add new GNSS subsystem Date: Wed, 30 May 2018 12:26:39 +0200 [thread overview] Message-ID: <20180530102639.GC3259@localhost> (raw) In-Reply-To: <0EFEDDD9-C21B-458B-884D-FC23F3D38B94@holtmann.org> Hi Marcel, Sorry about the late reply. I got side-tracked with other things. On Tue, May 08, 2018 at 10:03:57PM +0200, Marcel Holtmann wrote: > Hi Johan, > > >>>>>> 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). > >>>>> > >>>>> One problem I see here would be that the driver does not necessarily > >>>>> know either what protocol is currently being used. Some devices have > >>>>> boot-pins which can be used to configure the initial protocol used (and > >>>>> this could perhaps be reflected in DT), but this can often later be > >>>>> changed (by user space) and even be made persistent using battery-backed > >>>>> ram or eeproms. > >>>>> > >>>>> Also note that at least u-blox devices supports having more than one > >>>>> protocol active on the same port... > >>>> > >>>> as long as userspace can determine that it is GNSS hardware and what > >>>> hardware it is, then you deal with the rest in userspace. > >>> > >>> Yeah, I think that will do for now. > >> > >> I forgot to mention that this part should be simple. So providing a > >> DEVTYPE attribute that can be easily associated to the /dev/gnssX > >> nodes is a must have here. Doing complex mapping of USB or DT layouts > >> to figure out this is NMEA vs some vendor vs I need extra code to > >> change the mode etc. > > > > Yes, as I mentioned in the cover letter some kind of generic interface > > for identifying the device type (and its features) should be defined > > eventually. > > I think this needs to be present from the start. Half backed > subsystems are dangerous. And I really want to avoid hacking in > userspace to figure out details about the hardware. Fair enough. I've now added support for determining the GNSS type, which reflects the protocol(s) supported by the device and which should allow, for example, the gpsd protocol probing hack to be dropped. Currently, there are three types defined: "NMEA" NMEA 0183 "SiRF" SiRF Binary "UBX" UBX Note that both SiRF and UBX type devices typically support a subset of NMEA 0183 with vendor extensions (e.g. to allow switching to the vendor protocol). > > Note that this is not necessarily something that is needed from the > > start however as, for example, gpsd implements protocol detection. > > That might be, but that is a total hack. Lets get this right from the > get-go. I agree; it's horrid. Thanks, Johan
prev parent reply other threads:[~2018-05-30 10:26 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-24 16:34 [PATCH 0/7] gnss: add new GNSS subsystem Johan Hovold 2018-04-24 16:34 ` [PATCH 1/7] gnss: add GNSS receiver subsystem Johan Hovold 2018-04-25 8:56 ` Greg Kroah-Hartman 2018-04-25 10:56 ` Johan Hovold 2018-04-25 12:23 ` Johan Hovold 2018-04-29 13:35 ` Greg Kroah-Hartman 2018-05-02 7:57 ` Johan Hovold 2018-04-24 16:34 ` [PATCH 2/7] dt-bindings: add generic gnss binding Johan Hovold 2018-04-25 18:26 ` Rob Herring 2018-04-24 16:34 ` [PATCH 3/7] gnss: add generic serial driver Johan Hovold 2018-04-25 8:57 ` Greg Kroah-Hartman 2018-04-25 10:58 ` Johan Hovold 2018-04-25 9:00 ` Greg Kroah-Hartman 2018-04-25 11:05 ` Johan Hovold 2018-04-24 16:34 ` [PATCH 4/7] dt-bindings: gnss: add u-blox binding Johan Hovold 2018-04-25 18:16 ` Rob Herring 2018-04-26 9:10 ` Johan Hovold 2018-05-01 14:05 ` Rob Herring 2018-05-02 8:16 ` Johan Hovold 2018-05-02 13:16 ` Rob Herring 2018-05-07 9:06 ` Johan Hovold 2018-05-03 9:35 ` H. Nikolaus Schaller 2018-05-03 18:50 ` Andreas Kemnade 2018-05-04 5:16 ` H. Nikolaus Schaller 2018-05-04 11:42 ` Sebastian Reichel 2018-05-04 12:04 ` H. Nikolaus Schaller 2018-05-04 13:37 ` Sebastian Reichel 2018-05-04 14:29 ` Tony Lindgren 2018-05-07 10:07 ` Johan Hovold 2018-05-07 10:01 ` Johan Hovold 2018-05-07 15:45 ` Tony Lindgren 2018-05-07 16:34 ` Johan Hovold 2018-05-07 17:50 ` Tony Lindgren 2018-05-08 6:58 ` Johan Hovold 2018-05-08 15:22 ` Tony Lindgren 2018-05-08 15:47 ` Tony Lindgren 2018-05-08 15:54 ` Tony Lindgren 2018-05-08 16:49 ` Tony Lindgren 2018-05-09 13:10 ` OMAP serial runtime PM and autosuspend (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding)) Johan Hovold 2018-05-09 13:57 ` Tony Lindgren 2018-05-17 10:09 ` Johan Hovold 2018-05-17 17:10 ` Tony Lindgren 2018-05-21 13:48 ` Johan Hovold 2018-05-21 15:48 ` Tony Lindgren 2018-05-24 9:17 ` Johan Hovold 2018-05-24 13:32 ` Tony Lindgren 2018-05-25 14:02 ` Johan Hovold 2018-05-08 15:56 ` [PATCH 4/7] dt-bindings: gnss: add u-blox binding Sebastian Reichel 2018-05-09 9:18 ` Serdev runtime PM (was: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding) Johan Hovold 2018-05-09 9:49 ` Johan Hovold 2018-05-09 14:05 ` Tony Lindgren 2018-05-17 10:25 ` Johan Hovold 2018-05-07 9:47 ` [PATCH 4/7] dt-bindings: gnss: add u-blox binding Johan Hovold 2018-04-24 16:34 ` [PATCH 5/7] gnss: add driver for u-blox receivers Johan Hovold 2018-04-24 16:34 ` [PATCH 6/7] dt-bindings: gnss: add sirfstar binding Johan Hovold 2018-04-25 18:25 ` Rob Herring 2018-04-26 9:12 ` Johan Hovold 2018-04-24 16:34 ` [PATCH 7/7] gnss: add driver for sirfstar-based receivers Johan Hovold 2018-04-24 17:40 ` [PATCH 0/7] gnss: add new GNSS subsystem H. Nikolaus Schaller 2018-04-24 17:50 ` Johan Hovold 2018-04-24 19:44 ` H. Nikolaus Schaller 2018-04-25 8:11 ` Johan Hovold 2018-04-26 10:10 ` H. Nikolaus Schaller 2018-04-26 18:21 ` Johan Hovold 2018-04-24 20:13 ` Pavel Machek 2018-04-24 20:59 ` Andreas Kemnade 2018-04-25 7:32 ` Johan Hovold 2018-04-25 6:49 ` Marcel Holtmann 2018-04-25 7:24 ` Johan Hovold 2018-04-24 20:38 ` Pavel Machek 2018-04-25 6:26 ` Pavel Machek 2018-04-25 6:51 ` Johan Hovold 2018-04-25 8:48 ` Greg Kroah-Hartman 2018-04-25 10:31 ` Johan Hovold 2018-05-04 13:27 ` Sebastian Reichel 2018-05-04 20:03 ` Pavel Machek 2018-05-05 17:28 ` Sebastian Reichel 2018-05-05 21:11 ` Pavel Machek 2018-05-06 6:47 ` Marcel Holtmann 2018-05-07 10:20 ` Johan Hovold 2018-05-07 19:06 ` Marcel Holtmann 2018-05-08 7:01 ` Johan Hovold 2018-05-08 7:49 ` Marcel Holtmann 2018-05-08 12:48 ` Johan Hovold 2018-05-08 20:03 ` Marcel Holtmann 2018-05-30 10:26 ` Johan Hovold [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180530102639.GC3259@localhost \ --to=johan@kernel.org \ --cc=andreas@kemnade.info \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=hns@goldelico.com \ --cc=linux-kernel@vger.kernel.org \ --cc=marcel@holtmann.org \ --cc=mark.rutland@arm.com \ --cc=pavel@ucw.cz \ --cc=robh+dt@kernel.org \ --cc=sebastian.reichel@collabora.co.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).