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 wrot
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 ke
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 interface
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. Th
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 th
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. Th
> > 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 h
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 ot
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, provi
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 h
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 ri
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 b
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 hig
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 ac
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 t
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
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-process
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 (rpm
20 matches
Mail list logo
