On Fri, Jun 01, 2018 at 10:22:51AM +0200, Johan Hovold wrote: > This series adds a new subsystem for GNSS receivers (e.g. GPS > receivers). > > While GNSS receivers are typically accessed using a UART interface they > often also support other I/O interfaces such as I2C, SPI and USB, while > yet other devices use iomem or even some form of remote-processor > messaging (rpmsg). > > The new GNSS subsystem abstracts the underlying interface and provides a > new "gnss" class type, which exposes a character-device interface (e.g. > /dev/gnss0) to user space. This allows GNSS receivers to have a > representation in the Linux device model, something which is important > not least for power management purposes and which also allows for easy > detection and identification of GNSS devices. > > Note that the character-device interface provides raw access to whatever > protocol the receiver is (currently) using, such as NMEA 0183, UBX or > SiRF Binary. These protocols are expected to be continued to be handled > by user space for the time being, even if some hybrid solutions are also > conceivable (e.g. to have kernel drivers issue management commands). > > This will still allow for better platform integration by allowing GNSS > devices and their resources (e.g. regulators and enable-gpios) to be > described by firmware and managed by kernel drivers rather than > platform-specific scripts and services. > > While the current interface is kept minimal, it could be extended using > IOCTLs, sysfs or uevents as needs and proper abstraction levels are > identified and determined (e.g. for device and feature identification). > > Another possible extension is to add generic 1PPS support. > > I decided to go with a custom character-device interface rather than > pretend that these abstract GNSS devices are still TTY devices (e.g. > /dev/ttyGNSS0). Obviously, modifying line settings or reading modem > control signals does not make any sense for a device using, say, a > USB (not USB-serial) or iomem interface. This also means, however, that > user space would no longer be able to set the line speed to match a new > port configuration that can be set using the various GNSS protocols when > the underlying interface is indeed a UART; instead this would need to be > taken care of by the driver. > > Also note that writes are always synchronous instead of requiring user > space to call tcdrain() after every command. > > This all seems to work well-enough (e.g. with gpsd), but please let me > know if I've overlooked something which would indeed require a TTY > interface instead. > > I have implemented drivers for receivers based on two common GNSS > chipsets; SiRFstar and u-blox. Due to lack of hardware, the sirf driver > has been tested using a mockup device and a USB-serial-based SiRFstar IV > GPS (using out-of-tree USB-serial code). [ Let me know if you've got any > evaluation kits to spare. ] The ubx driver has been tested using a > u-blox 8 GNSS evaluation kit (thanks u-blox!). > > 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. This all looks great. Thanks for doing this work and adding a new subsystem for something that has been asked for for many years. All now merged in my tree, nice job! greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
