linux-kernel - [RFC PATCH 0/3] bluetooth/gnss: GNSS support for TiWi chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Nov 2023 20:18:37 +0100
From:   Andreas Kemnade <andreas@...nade.info>
To:     marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com,
        johan@...nel.org, arnd@...db.de, gregkh@...uxfoundation.org,
        andreas@...nade.info, linux-bluetooth@...r.kernel.org,
        linux-kernel@...r.kernel.org, tomi.valkeinen@...asonboard.com,
        Tony Lindgren <tony@...mide.com>,
        Péter Ujfalusi <peter.ujfalusi@...il.com>,
        robh@...nel.org
Subject: [RFC PATCH 0/3] bluetooth/gnss: GNSS support for TiWi chips

Some of these chips have GNSS support. In some vendor kernels
a driver on top of misc/ti-st can be found providing a /dev/tigps
device which speaks the secretive Air Independent Interface (AI2) protocol.
Implement something comparable as a GNSS interface.

With some userspace tools a proof-of-concept can be shown. A position
can be successfully read out.  Basic properties of the protocol are
understood.

This was tested on the Epson Moverio BT-200.

This is sent out as an early RFC to ensure I am going onto the right
track:

So the main questions I see:
- is the approach right to abandon drivers/misc/ti-st?

- Output at /dev/gnssX:
  AI2 vs. NMEA
  The chip can be configured into sending AI2-encapsulated NMEA,
  or proving data in a binary format.
  Some research has to be done yet for the details.
  A pile of logs is waiting for further analysis...

  Arguments for/against NMEA:
  + Userspace is prepared to handle it
  + Power management can be easily done by the kernel
  - Less functionality can be used.

  Arguments for/against AI2:
  + Full functionality can be accessed from userspace (incl. A-GPS,
    maybe raw satellite data)
  - Userspace has to behave to have proper power management
  - No freely (not even as in beer) tool available to fully use AI2,
    so there will be only a real advantage after long "French Cafe"
    sessions.

More detailed tings:
  - Some live cycle management is left out. Since it depends
    on the decisions above, I have not put much thought into it.
  - Should some pieces go into drivers/gnss?
  - detection for GNSS availability: For now the node name is
    used. But the device should be there if the chip supports it
    and things are wired up properly.

Andreas Kemnade (3):
  gnss: Add AI2 protocol used by some TI combo chips.
  bluetooth: ti-st: add GNSS support for TI Wilink chips
  drivers: misc: ti-st: begin to deorbit

 drivers/bluetooth/hci_ll.c | 154 ++++++++++++++++++++++++++++++++++++-
 drivers/gnss/core.c        |   1 +
 drivers/misc/ti-st/Kconfig |   2 +-
 include/linux/gnss.h       |   1 +
 4 files changed, 156 insertions(+), 2 deletions(-)

-- 
2.39.2