gnss: add new GNSS subsystem

Add binding for u-blox GNSS receivers.

Note that the u-blox product names encodes form factor (e.g. "neo"), chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and chipset is used for the compatible strings (for now).

Signed-off-by Johan Hovold <[email protected]>

---
 .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

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).

Another possible extension is to add generic 1PPS support.

Hi!

Quoted 15 lines

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.

Quoted 5 lines

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).

So.. while you did good work on serial power management, this is grossly misnamed. There's nothing GNSS specific in the code, and you are not presenting consistent interface to the userland.

This is _not_ GNSS subsystem. This is serial power management subsystem, or something like that. GPS/GNSS subsystem will need to be built on top of this.

This will never handle devices like Nokia N900, where GPS is connected over netlink.

Quoted 1 line

Another possible extension is to add generic 1PPS support.

And there's nothing GNSS specific in the patches.

Quoted 27 lines · Pavel Machek

Hi!

Quoted 15 lines

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.

Quoted 5 lines

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).

So.. while you did good work on serial power management, this is grossly misnamed. There's nothing GNSS specific in the code, and you are not presenting consistent interface to the userland.

Quoted 3 lines

This is _not_ GNSS subsystem. This is serial power management subsystem, or something like that. GPS/GNSS subsystem will need to be built on top of this.

I thought we had this discussion already.

This series adds an abstraction for GNSS receivers so that they can be detected by userspace without resorting to probing hacks. That is GNSS specific.

Furthermore, (since v2) we export a GNSS receiver type, which allows further protocol detection hacks to be dropped, something which is also GNSS specific.

The two drivers and library added are for GNSS devices and their specific power management needs, while a random serial-connected device may need to manage power differently. Also GNSS specific.

Finally, the GNSS subsystem is clearly not serial (as in UART) specific and works just as fine with I2C, SPI, USB, iomem, rproc or whatever interface the GNSS uses.

Quoted 2 lines

This will never handle devices like Nokia N900, where GPS is connected over netlink.

Marcel already suggested adding a ugnss interface, which would allow feeding GNSS data through the generic GNSS interface from user space for use cases where it's not (yet) feasible to implement a kernel driver.

Quoted 6 lines · Johan Hovold

On Fri, Jun 01, 2018 at 11:33:11AM +0200, Pavel Machek wrote:

This series adds an abstraction for GNSS receivers so that they can be detected by userspace without resorting to probing hacks. That is GNSS specific.

Quoted 3 lines

Furthermore, (since v2) we export a GNSS receiver type, which allows further protocol detection hacks to be dropped, something which is also GNSS specific.

So you have serial line + pm + protocol type. Nothing GNSS specific really, it would be useful to (for example) say this is modem with AT commands. Or this is QMI modem.

Quoted 3 lines

The two drivers and library added are for GNSS devices and their specific power management needs, while a random serial-connected device may need to manage power differently. Also GNSS specific.

Or maybe it will need to manager power in the same way. How would the AT modem be different?

Quoted 3 lines

Finally, the GNSS subsystem is clearly not serial (as in UART) specific and works just as fine with I2C, SPI, USB, iomem, rproc or whatever interface the GNSS uses.

Ok, true. It is "we pass tty-like data across". Again, it would be useful for AT commands, too, and yes, they go over serials and usbs and more, too.

Quoted 7 lines

Quoted 2 lines

This will never handle devices like Nokia N900, where GPS is connected over netlink.

Marcel already suggested adding a ugnss interface, which would allow feeding GNSS data through the generic GNSS interface from user space for use cases where it's not (yet) feasible to implement a kernel driver.

Yes, and ugnss would be at wrong layer for N900. First, lets take a look at N900 gps driver:
https://github.com/postmarketOS/gps-nokia-n900

Got it? I'll eventually like to see it in the kernel, but your "GNSS" subsystem is unsuitable for it, as it does not talk well-known protocol.

I'd like to see "datapipe" devices (what you currently call GNSS) and "gps" devices, which would have common interface to the userland.

N900 would not have any datapipe devices, but would have /dev/gps0 exposing common GPS interface.

Droid4 would have /dev/datapipe0 (usb, AT protocol), /dev/datapipe1 (usb, QMI protocol), /dev/datapipe2 (gsmtty over serial, custom AT protocol), /dev/datapipe3 (gsmtty over serial, NMEA wrapped in AT protocol) (and more, it is complex hardware). And if we really wanted, we'd have /dev/gps0, too, exposing common GPS interface.

Your devices would have /dev/datapipe0 with sirf or ublox or nmea protocol. In we really wanted, we'd have /dev/gps0, too, again, exposing common GPS interface.

I believe we really want to use your code for AT commands, too. And we really should keep GNSS/GPS names for future layer that actually provides single interface for userland.

Quoted 3 lines

So you have serial line + pm + protocol type. Nothing GNSS specific really, it would be useful to (for example) say this is modem with AT commands. Or this is QMI modem.

It's a matter of finding the right abstraction level. A user space location service will now have easy access to the class of devices it cares about, without having to go through a list of other random devices which happen to use a similar underlying interface (e.g. a modem or whatever).

Point is, you can't write a subsystem for everything. If it later turns out some part of the code can be shared internally, fine.

Quoted 7 lines

Quoted 3 lines

Finally, the GNSS subsystem is clearly not serial (as in UART) specific and works just as fine with I2C, SPI, USB, iomem, rproc or whatever interface the GNSS uses.

Ok, true. It is "we pass tty-like data across". Again, it would be useful for AT commands, too, and yes, they go over serials and usbs and more, too.

Modems and GNSS devices would have different characteristics for buffers and throughput for starters.

The GNSS interface uses a synchronous writes for commands to the receiver, something which may not be appropriate for an outgoing data channel, for example.

As mentioned in the cover letter, we may eventually want to add support for some kinds of configuration from within the kernel (e.g. protocol and line speed changes).

Quoted 13 lines

Quoted 8 lines

Quoted 3 lines

This will never handle devices like Nokia N900, where GPS is connected over netlink.

Marcel already suggested adding a ugnss interface, which would allow feeding GNSS data through the generic GNSS interface from user space for use cases where it's not (yet) feasible to implement a kernel driver.

Yes, and ugnss would be at wrong layer for N900. First, lets take a look at N900 gps driver:
https://github.com/postmarketOS/gps-nokia-n900

Quoted 3 lines

Got it? I'll eventually like to see it in the kernel, but your "GNSS" subsystem is unsuitable for it, as it does not talk well-known protocol.

Seriously? If you can't be arsed to summarise your use case, why would I bother reading your random user space code?

Quoted 2 lines

I'd like to see "datapipe" devices (what you currently call GNSS) and "gps" devices, which would have common interface to the userland.

You keep talking about this "gps" interface, which based on your earlier comments I assume you mean a NMEA 0183 interface? Again, converting a vendor-specific binary protocol may not be feasible. Please try to be more be specific.

Quoted 9 lines

N900 would not have any datapipe devices, but would have /dev/gps0 exposing common GPS interface.

Droid4 would have /dev/datapipe0 (usb, AT protocol), /dev/datapipe1 (usb, QMI protocol), /dev/datapipe2 (gsmtty over serial, custom AT protocol), /dev/datapipe3 (gsmtty over serial, NMEA wrapped in AT protocol) (and more, it is complex hardware). And if we really wanted, we'd have /dev/gps0, too, exposing common GPS interface.

Quoted 3 lines

Your devices would have /dev/datapipe0 with sirf or ublox or nmea protocol. In we really wanted, we'd have /dev/gps0, too, again, exposing common GPS interface.

This does not seem like the right abstraction level and doesn't appear to provide much more than what we currently have with ttys.

Quoted 3 lines

I believe we really want to use your code for AT commands, too. And we really should keep GNSS/GPS names for future layer that actually provides single interface for userland.

Specifics, please. What would such an interface look like? I'm pretty sure, we do not want to move every GNSS middleware protocol handler into the kernel.

Am 01.06.2018 um 18:26 schrieb Pavel Machek <[email protected]>:

NMEA would not be my first choice, really. I'd propose something very similar to existing /dev/input/eventX, but with wider data types.

Hi Pavel,

Quoted 4 lines

Am 01.06.2018 um 18:26 schrieb Pavel Machek <[email protected]>:

NMEA would not be my first choice, really. I'd propose something very similar to existing /dev/input/eventX, but with wider data types.

Since even Rome wasn't built in a day, my first choice is NMEA, but I am open to anything on higher level to come second.

What about iio?

It is quite flexible and extensible and GNSS coordinates are a not very different from accelerometer, gyroscope or compass data as all of them describe the position and orientation, maybe speed of the device these things are built into (at least for mobile devices).

Hi!

Quoted 4 lines

Quoted 3 lines

So you have serial line + pm + protocol type. Nothing GNSS specific really, it would be useful to (for example) say this is modem with AT commands. Or this is QMI modem.

Quoted 5 lines

It's a matter of finding the right abstraction level. A user space location service will now have easy access to the class of devices it cares about, without having to go through a list of other random devices which happen to use a similar underlying interface (e.g. a modem or whatever).

udev solves device discovery pretty well; I don't think that's good thing to optimize for.

(And.. I'd really prefer /dev/nmeaX and /dev/sirfX in that situation; and yes that makes it _even easier_ for location service to find right devices).

Quoted 2 lines

Point is, you can't write a subsystem for everything. If it later turns out some part of the code can be shared internally, fine.

True. But you can pick reasonable name for the subsystem :-).

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

Finally, the GNSS subsystem is clearly not serial (as in UART) specific and works just as fine with I2C, SPI, USB, iomem, rproc or whatever interface the GNSS uses.

Ok, true. It is "we pass tty-like data across". Again, it would be useful for AT commands, too, and yes, they go over serials and usbs and more, too.

Quoted 6 lines

Modems and GNSS devices would have different characteristics for buffers and throughput for starters.

The GNSS interface uses a synchronous writes for commands to the receiver, something which may not be appropriate for an outgoing data channel, for example.

Well, these days AT modems really have separate channels for commands and data.

Quoted 3 lines

As mentioned in the cover letter, we may eventually want to add support for some kinds of configuration from within the kernel (e.g. protocol and line speed changes).

I believe we'll eventually want "real" GPS drivers, with common interface. input was in this situation before...

Quoted 16 lines

Quoted 15 lines

Quoted 7 lines

Quoted 2 lines

This will never handle devices like Nokia N900, where GPS is connected over netlink.

Marcel already suggested adding a ugnss interface, which would allow feeding GNSS data through the generic GNSS interface from user space for use cases where it's not (yet) feasible to implement a kernel driver.

Yes, and ugnss would be at wrong layer for N900. First, lets take a look at N900 gps driver:
https://github.com/postmarketOS/gps-nokia-n900

Got it? I'll eventually like to see it in the kernel, but your "GNSS" subsystem is unsuitable for it, as it does not talk well-known protocol.

Quoted 2 lines

Seriously? If you can't be arsed to summarise your use case, why would I bother reading your random user space code?

You are trying to push subsystem to kernel. I believe asking you to do little research is not unexpected.

Anyway, it is trivial binary protocol over packets that are used for modem communication. Handling it is like 40? lines of code.

Quoted 7 lines

Quoted 2 lines

I'd like to see "datapipe" devices (what you currently call GNSS) and "gps" devices, which would have common interface to the userland.

You keep talking about this "gps" interface, which based on your earlier comments I assume you mean a NMEA 0183 interface? Again, converting a vendor-specific binary protocol may not be feasible. Please try to be more be specific.

I'm pretty sure we should have one protocol for communicating position data to userland. I don't want to go into details at the moment, as they are not important at the moment (and we could spend lot of time discussing details).

NMEA would not be my first choice, really. I'd propose something very similar to existing /dev/input/eventX, but with wider data types.

Quoted 13 lines

Quoted 12 lines

N900 would not have any datapipe devices, but would have /dev/gps0 exposing common GPS interface.

Droid4 would have /dev/datapipe0 (usb, AT protocol), /dev/datapipe1 (usb, QMI protocol), /dev/datapipe2 (gsmtty over serial, custom AT protocol), /dev/datapipe3 (gsmtty over serial, NMEA wrapped in AT protocol) (and more, it is complex hardware). And if we really wanted, we'd have /dev/gps0, too, exposing common GPS interface.

Your devices would have /dev/datapipe0 with sirf or ublox or nmea protocol. In we really wanted, we'd have /dev/gps0, too, again, exposing common GPS interface.

Quoted 2 lines

This does not seem like the right abstraction level and doesn't appear to provide much more than what we currently have with ttys.

I don't see what you are saying here. I've described your proposal but replaced /dev/gnss0 with /dev/datapipe0.

Quoted 7 lines

Quoted 3 lines

I believe we really want to use your code for AT commands, too. And we really should keep GNSS/GPS names for future layer that actually provides single interface for userland.

Specifics, please. What would such an interface look like? I'm pretty sure, we do not want to move every GNSS middleware protocol handler into the kernel.

Maybe we don't want to move _every_ GNSS protocol handler into kernel, but I'm pretty sure we need to move _some_ of them there. It is certainly best place for Nokia N900's protocol.

And I'm trying to make sure we have suitable names available when that happens.

Quoted 2 lines

udev solves device discovery pretty well; I don't think that's good thing to optimize for.

It's about grouping related devices together, devices which share some common functionality. In this case, providing location data from some satellite system. I really don't understand how you can find having a class type named "gnss" for this to be controversial in any way.

Quoted 3 lines

(And.. I'd really prefer /dev/nmeaX and /dev/sirfX in that situation; and yes that makes it _even easier_ for location service to find right devices).

As I've already explained, you may not know which protocol is currently active when the device start and you typically switch from NMEA to a vendor protocol during runtime (e.g. for configuration or to access raw GNSS data).

Trying to encode the GNSS protocol in the character-device node name is just a bad idea.

Quoted 4 lines

Quoted 2 lines

Point is, you can't write a subsystem for everything. If it later turns out some part of the code can be shared internally, fine.

True. But you can pick reasonable name for the subsystem :-).

I find naming a subsystem for GNSS receivers "gnss" to be very reasonable. ;)

Quoted 7 lines

Well, these days AT modems really have separate channels for commands and data.

Quoted 3 lines

As mentioned in the cover letter, we may eventually want to add support for some kinds of configuration from within the kernel (e.g. protocol and line speed changes).

Quoted 2 lines

I believe we'll eventually want "real" GPS drivers, with common interface. input was in this situation before...

As we also already discussed, there's nothing preventing you from trying to move gpsd into the kernel later. I doubt this is something we want, and it may turn out not to be feasible for other reasons.

And as you already acknowledged, this series does solve a problem we have today.

Quoted 2 lines

Anyway, it is trivial binary protocol over packets that are used for modem communication. Handling it is like 40? lines of code.

Ok, so I did read the damn thing along with the overview of the N900 GPS hardware and reverse-engineered protocol (why didn't you point me to those instead?) and I'm still not sure what the point you're trying to make is.

The n900 service you link to above, parses phonet data, does some *floating point* calculations and generates NMEA sentences which it feeds to a pseudo terminal whose slave side is opened by gpsd.

That NMEA data could just as easily be fed through a different kernel subsystem, namely gnss instead of tty, where it could be accessed through a common interface (for now, a raw gnss interface, with some associated meta data). [ And from what I can tell, ugnss would also allow you to get rid of some hacks related to finding out when the GNSS is opened and needs to be powered on. ]

So the ugnss interface looks like it will work for N900 just as it will for other phones.

Quoted 2 lines

NMEA would not be my first choice, really. I'd propose something very similar to existing /dev/input/eventX, but with wider data types.

Fine, you pursue that idea if you want then. I can see many problems with trying to so, but the point is, this series doesn't prevent you from doing so.

If you think you'll one day be able to parse and repackage the various vendor protocols within the kernel, you can consider the raw gnss interface as an intermediate step (which may continue to exist in parallel just as say hidraw).

As I've already mentioned, I considered naming the device nodes /dev/gnssraw0 partly because it would leave /dev/gnss namespace free for any such future development. I ultimately found that idea to be too implausible for it to be worth the potential confusion arising from the fact that "raw" GNSS data is already has an established meaning.

But in the end, this is just name bike shedding.

Quoted 6 lines

Maybe we don't want to move _every_ GNSS protocol handler into kernel, but I'm pretty sure we need to move _some_ of them there. It is certainly best place for Nokia N900's protocol.

And I'm trying to make sure we have suitable names available when that happens.

If that's the concern, we could reconsider naming the raw protocol interface /dev/gnnsraw0 as mentioned above.

Hi!

Quoted 7 lines

Quoted 2 lines

udev solves device discovery pretty well; I don't think that's good thing to optimize for.

It's about grouping related devices together, devices which share some common functionality. In this case, providing location data from some satellite system. I really don't understand how you can find having a class type named "gnss" for this to be controversial in any way.

We normally group devices by interface, not by functionality.

Quoted 9 lines

Quoted 3 lines

(And.. I'd really prefer /dev/nmeaX and /dev/sirfX in that situation; and yes that makes it _even easier_ for location service to find right devices).

As I've already explained, you may not know which protocol is currently active when the device start and you typically switch from NMEA to a vendor protocol during runtime (e.g. for configuration or to access raw GNSS data).

Quoted 2 lines

Trying to encode the GNSS protocol in the character-device node name is just a bad idea.

I thought idea was to switch to the "best" protocol in kernel.

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

As mentioned in the cover letter, we may eventually want to add support for some kinds of configuration from within the kernel (e.g. protocol and line speed changes).

I believe we'll eventually want "real" GPS drivers, with common interface. input was in this situation before...

Quoted 3 lines

As we also already discussed, there's nothing preventing you from trying to move gpsd into the kernel later. I doubt this is something we want, and it may turn out not to be feasible for other reasons.

Well -- I believe we want "gpsd in kernel". If you take /dev/gnss0 and drivers/gnss now, where do I put them?

Quoted 4 lines

Ok, so I did read the damn thing along with the overview of the N900 GPS hardware and reverse-engineered protocol (why didn't you point me to those instead?) and I'm still not sure what the point you're trying to make is.

Umm. Where did you find the hardware overview/protocol overview?

Quoted 11 lines

The n900 service you link to above, parses phonet data, does some *floating point* calculations and generates NMEA sentences which it feeds to a pseudo terminal whose slave side is opened by gpsd.

That NMEA data could just as easily be fed through a different kernel subsystem, namely gnss instead of tty, where it could be accessed through a common interface (for now, a raw gnss interface, with some associated meta data). [ And from what I can tell, ugnss would also allow you to get rid of some hacks related to finding out when the GNSS is opened and needs to be powered on. ]

Quoted 2 lines

So the ugnss interface looks like it will work for N900 just as it will for other phones.

Not NMEA please. First, NMEA has strange format of latitude/longitude -- that's those calculations IIRC. NMEA has other problems, too -- like not atomically providing speeds and accuracies. Plus it is crazy text protoco with CRCs.

Quoted 18 lines

Quoted 2 lines

NMEA would not be my first choice, really. I'd propose something very similar to existing /dev/input/eventX, but with wider data types.

Fine, you pursue that idea if you want then. I can see many problems with trying to so, but the point is, this series doesn't prevent you from doing so.

If you think you'll one day be able to parse and repackage the various vendor protocols within the kernel, you can consider the raw gnss interface as an intermediate step (which may continue to exist in parallel just as say hidraw).

As I've already mentioned, I considered naming the device nodes /dev/gnssraw0 partly because it would leave /dev/gnss namespace free for any such future development. I ultimately found that idea to be too implausible for it to be worth the potential confusion arising from the fact that "raw" GNSS data is already has an established meaning.

Quoted 1 line

But in the end, this is just name bike shedding.

So I agree /dev/gnssraw is not great. But /dev/gnss is even worse. And yes, it is "just" a naming, but it will be impossible to fix later.

/dev/serdev? /dev/gnssproto?

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.

Quoted 4 lines

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!

Quoted 8 lines

Quoted 4 lines

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.

Quoted 1 line

All now merged in my tree, nice job!

I don't think discussion was finished on this one.

In particular, we agreed that /dev/gnssrawX would be better device name, so that we still have place where to put proper abstraction layer in future.

Quoted 12 lines · Pavel Machek

Quoted 9 lines

Quoted 4 lines

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!

I don't think discussion was finished on this one.

Quoted 3 lines

In particular, we agreed that /dev/gnssrawX would be better device name, so that we still have place where to put proper abstraction layer in future.

I did not agree with you on that. I said we could consider that name if this was to be changed at all, which I do not think is necessary for the reasons spelled out in this thread.

Quoted 17 lines · Johan Hovold

Quoted 15 lines · Pavel Machek

Quoted 9 lines

Quoted 4 lines

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!

I don't think discussion was finished on this one.

In particular, we agreed that /dev/gnssrawX would be better device name, so that we still have place where to put proper abstraction layer in future.

Quoted 3 lines

I did not agree with you on that. I said we could consider that name if this was to be changed at all, which I do not think is necessary for the reasons spelled out in this thread.

So, again: there's nothing gnss specific in those patches. It does not know about the format of the data passed around. (Best you can claim that somehow data flow characteristics are unique to gnss.) And this takes namespace needed for real gnss subsystem. Please don't do it.

Quoted 22 lines · Pavel Machek

Quoted 20 lines · Johan Hovold

Quoted 8 lines · Pavel Machek

Quoted 8 lines

Quoted 4 lines

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.

Quoted 7 lines

Quoted 1 line

All now merged in my tree, nice job!

I don't think discussion was finished on this one.

In particular, we agreed that /dev/gnssrawX would be better device name, so that we still have place where to put proper abstraction layer in future.

I did not agree with you on that. I said we could consider that name if this was to be changed at all, which I do not think is necessary for the reasons spelled out in this thread.

Quoted 4 lines

So, again: there's nothing gnss specific in those patches. It does not know about the format of the data passed around. (Best you can claim that somehow data flow characteristics are unique to gnss.) And this takes namespace needed for real gnss subsystem. Please don't do it.

This is the real gnss subsystem. Get over it.

Quoted 28 lines · Johan Hovold

Quoted 26 lines · Pavel Machek

Quoted 13 lines · Johan Hovold

Quoted 12 lines · Pavel Machek

Quoted 9 lines

Quoted 4 lines

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!

I don't think discussion was finished on this one.

Quoted 7 lines

Quoted 3 lines

In particular, we agreed that /dev/gnssrawX would be better device name, so that we still have place where to put proper abstraction layer in future.

I did not agree with you on that. I said we could consider that name if this was to be changed at all, which I do not think is necessary for the reasons spelled out in this thread.

So, again: there's nothing gnss specific in those patches. It does not know about the format of the data passed around. (Best you can claim that somehow data flow characteristics are unique to gnss.) And this takes namespace needed for real gnss subsystem. Please don't do it.

Quoted 1 line

This is the real gnss subsystem. Get over it.

Congratulations. You have created gnss subsystem that has 0 lines of code that are gnss-specific.

This is not real gnss subsystem. This is pipe that passes data, similar to /dev/psaux or mouse on /dev/ttyS0. Sooner or later, real gnss subsystem (with unified interface) will be needed, as it was for input, and this "pipe and gpio" thing should not hog required namespace.

Quoted 9 lines

Quoted 4 lines

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!

I don't think discussion was finished on this one.

Quoted 8 lines · Pavel Machek

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

Quoted 1 line

All now merged in my tree, nice job!

I don't think discussion was finished on this one.

It looked done to me as there was only a single set of patches, with no other working patches submitted from anyone else.

If this turns out to be a "bad" api, then we can deal with it then, but for now let's try this out.