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
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
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
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
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
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
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.
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.
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
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
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
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
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.
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.
> > 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
> > 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
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
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
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,
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,
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
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
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
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
On Fri 2018-06-01 18:37:36, H. Nikolaus Schaller wrote:
> Hi Pavel,
>
> > Am 01.06.2018 um 18:26 schrieb Pavel Machek :
> >
> > 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
On Fri 2018-06-01 18:37:36, H. Nikolaus Schaller wrote:
> Hi Pavel,
>
> > Am 01.06.2018 um 18:26 schrieb Pavel Machek :
> >
> > 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
Hi Pavel,
> Am 01.06.2018 um 18:26 schrieb Pavel Machek :
>
> 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
Hi Pavel,
> Am 01.06.2018 um 18:26 schrieb Pavel Machek :
>
> 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
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
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
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
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
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
>
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
>
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
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
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
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
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
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
40 matches
Mail list logo
