| Message ID | 20180601082259.17563-1-johan@kernel.org |
|---|---|
| Headers | show |
| Series | gnss: add new GNSS subsystem | expand |
Hi! > 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). 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. > Another possible extension is to add generic 1PPS support. And there's nothing GNSS specific in the patches. Best regards, Pavel
On Fri, Jun 01, 2018 at 11:33:11AM +0200, Pavel Machek wrote: > Hi! > > > 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). > > 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. 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. > 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. > > Another possible extension is to add generic 1PPS support. > > And there's nothing GNSS specific in the patches. I disagree. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 2018-06-01 11:49:59, Johan Hovold wrote: > On Fri, Jun 01, 2018 at 11:33:11AM +0200, Pavel Machek wrote: > > Hi! > > > > > 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). > > > > 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. > > I thought we had this discussion already. I don't remember useful discussion. > 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. 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. > 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? > 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. > > 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. Best regards, Pavel
On Fri, Jun 01, 2018 at 12:26:12PM +0200, Pavel Machek wrote: > On Fri 2018-06-01 11:49:59, Johan Hovold wrote: > > 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. > > > > 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. 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). > > 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? 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. > > 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). > > > 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. Seriously? If you can't be arsed to summarise your use case, why would I bother reading your random user space code? > 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. > 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. 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 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. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! > > 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). 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). > 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 :-). > > > 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. Well, these days AT modems really have separate channels for commands and data. > 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... > > > > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. Thanks, Pavel
Hi Pavel, > Am 01.06.2018 um 18:26 schrieb Pavel Machek <pavel@ucw.cz>: > > 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). --hns -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 2018-06-01 18:37:36, H. Nikolaus Schaller wrote: > Hi Pavel, > > > Am 01.06.2018 um 18:26 schrieb Pavel Machek <pavel@ucw.cz>: > > > > 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). As I said, I do not want to have that discussion at the moment. Transfering position and orientation is easy, transfering some other data (such as sattelites used for fix) might be trickier. Anyway, I'm pretty sure reasonable solution exists; and yes we could use NMEA. Pavel
On Fri, Jun 01, 2018 at 06:26:46PM +0200, Pavel Machek wrote: > Hi! > > > > 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). > > 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. > (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. > > 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. ;) > > > > 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. > > Well, these days AT modems really have separate channels for commands > and data. > > > 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... 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. > > > > > 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. > > > > 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. Waving your hands, saying this will never work, and pointing to some 600 lines of user-space code for an old phone isn't an argument. That is, at best, just you being lazy. > 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. > > > 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. 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. > > > 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. > > > > 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. You're grouping unrelated devices into a new class with the descriptive name "datapipe" (sarcasm). Maybe one day we'll have a QMI subsystem, for example, but until someone determines what that may end up looking like, I think we should stick with the character device and tty abstractions we already have. > > > 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. If that's the concern, we could reconsider naming the raw protocol interface /dev/gnnsraw0 as mentioned above. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! > > 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. > > (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. I thought idea was to switch to the "best" protocol in kernel. > > > 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. ;) I don't. I'll explain why below. > > Well, these days AT modems really have separate channels for commands > > and data. > > > > > 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... > > 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? > And as you already acknowledged, this series does solve a problem we > have today. Yes. I'm not disputing that. > > 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. Umm. Where did you find the hardware overview/protocol overview? > 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. 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. > > 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. 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? > > 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. I prfer /dev/gnssraw0 to /dev/gnss0. Thanks, Pavel
On Tue, Jun 05, 2018 at 11:47:52PM +0200, Pavel Machek wrote: > Hi! > > > > 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. And interfaces also tend to reflect functionality. > > > (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. > > I thought idea was to switch to the "best" protocol in kernel. I'm afraid it's not that simple; the vendor protocols are not always supersets of the data and commands provided by the NMEA modes. Apparently, some data is only available in NMEA mode for SiRF devices, for example, so we need to provide some flexibility here. > > > > 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... > > > > 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? The subsystem would still live under drivers/gnss. If there's ever going to be an in-kernel gpsd, then maybe /dev/gnss0 could have been used for it instead (if a character device is even the right interface). I started off with separating the gnss device itself from the raw interface (cf. hid) to allow for something like that, but the more I looked into this the more it seems I was just over-engineering for something that would never be realised. Take a look at some of the papers on the gpsd site about GNSS protocols and the problem of finding a common representation for all the various devices out there. gpsd itself has already gone through three revisions of its internal representation over the past decades. This does not seem like an exercise we want to repeat in the kernel with its rules about backwards compatibility etc. So at least for the time being, I'm convinced that a raw gnss interface is the right one. > > 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? It looks like Sebastian (and others) once put something together here: https://wiki.maemo.org/N900_Hardware_GPS https://wiki.maemo.org/N900_GPS_Reverse_Engineering > > 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. > > 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. Then of course you also have the issue that all of user space would need to be taught to understand this yet-to-be-conceived generic protocol. > > > 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. > > 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? Again, the gnss subsystem is transport agnostic so /dev/serdev is not an option. gpsd uses the term "raw" for its raw access to the device protocol. Probably best to use "gnssraw" in case this needs to be changed at all. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > 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. Best regards, Pavel
On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > 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. 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. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 2018-06-29 13:46:46, Johan Hovold wrote: > On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > > > 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. > > 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. Pavel
On Fri, Jun 29, 2018 at 02:05:54PM +0200, Pavel Machek wrote: > On Fri 2018-06-29 13:46:46, Johan Hovold wrote: > > On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > > > > > 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. > > > > 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. This is the real gnss subsystem. Get over it. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > 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. 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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 2018-06-29 14:26:00, Greg Kroah-Hartman wrote: > On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > > > 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. > > It looked done to me as there was only a single set of patches, with no > other working patches submitted from anyone else. Is "noone submitted patches on top" sufficient reason to apply the patch? > If this turns out to be a "bad" api, then we can deal with it then, but > for now let's try this out. Series uses /dev/gnss0 , without providing hardware abstraction, blocking place for proper gnss layer. Suggested fix is to to make it "/dev/gnssraw0". How do you propose to fix this after it is merged? Pavel
On Fri 2018-06-29 14:09:14, Johan Hovold wrote: > On Fri, Jun 29, 2018 at 02:05:54PM +0200, Pavel Machek wrote: > > On Fri 2018-06-29 13:46:46, Johan Hovold wrote: > > > On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > > > > > > > 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. > > > > > > 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. > > 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. Pavel
On Mon, Jul 02, 2018 at 09:32:26PM +0200, Pavel Machek wrote: > On Fri 2018-06-29 14:09:14, Johan Hovold wrote: > > On Fri, Jun 29, 2018 at 02:05:54PM +0200, Pavel Machek wrote: > > > On Fri 2018-06-29 13:46:46, Johan Hovold wrote: > > > > On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > > > > > > > > > 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. > > > > > > > > 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. > > > > 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. We have been through this already. > 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. It is still the gnss subsystem with a raw interface to the underlying protocols. As I've said repeatedly, *if* someone ever comes up with a way of abstracting these protocols, and can make the case this is really something we want to handle in the kernel, we would still be using the same drivers for managing power and I/O. Get it? It's the same subsystem, you'd just be adding a second higher-level interface (cf. hiddev and hidraw). So again, all that this comes down to is bike shedding about the device node name. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Johan Changes in v3 - dt-bindings - clarify that "u-blox,extint-gpios" is connected to a device input pin (Rob) - fix space-before-tab whitespace issues (Rob) - use "receiver" instead of "device" in the receiver type documentation for better consistency with the rest of the series Changes in v2 - add device type support (new patch 8/8) - fix one unprotected access to ops->write_raw - add support for optional v_bckp supply to ubx driver - drop unnecessary dev_dbgs (Greg) - simplify open() error path (Greg) - indent function parameters further - use gserial->drvdata to access variable length data - dt-bindings - document required reg property for I2C, SPI and USB bindings (Rob) - use "pin name:" prefix when referring to datasheet names (Rob) - add vendor prefix to sirf gpios (Rob) - add optional u-blox v-bckp supply (Rob) - add optional u-blox extint gpio - minor clean ups - add Rob's Reviewed-by tag (patches 2/8 and 6/8) Johan Hovold (8): gnss: add GNSS receiver subsystem dt-bindings: add generic gnss binding gnss: add generic serial driver dt-bindings: gnss: add u-blox binding gnss: add driver for u-blox receivers dt-bindings: gnss: add sirfstar binding gnss: add driver for sirfstar-based receivers gnss: add receiver type support Documentation/ABI/testing/sysfs-class-gnss | 15 + .../devicetree/bindings/gnss/gnss.txt | 36 ++ .../devicetree/bindings/gnss/sirfstar.txt | 45 ++ .../devicetree/bindings/gnss/u-blox.txt | 44 ++ .../devicetree/bindings/vendor-prefixes.txt | 4 + MAINTAINERS | 8 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/gnss/Kconfig | 43 ++ drivers/gnss/Makefile | 16 + drivers/gnss/core.c | 420 ++++++++++++++++++ drivers/gnss/serial.c | 275 ++++++++++++ drivers/gnss/serial.h | 47 ++ drivers/gnss/sirf.c | 408 +++++++++++++++++ drivers/gnss/ubx.c | 153 +++++++ include/linux/gnss.h | 75 ++++ 16 files changed, 1592 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-gnss create mode 100644 Documentation/devicetree/bindings/gnss/gnss.txt create mode 100644 Documentation/devicetree/bindings/gnss/sirfstar.txt create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt create mode 100644 drivers/gnss/Kconfig create mode 100644 drivers/gnss/Makefile create mode 100644 drivers/gnss/core.c create mode 100644 drivers/gnss/serial.c create mode 100644 drivers/gnss/serial.h create mode 100644 drivers/gnss/sirf.c create mode 100644 drivers/gnss/ubx.c create mode 100644 include/linux/gnss.h