linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHCN7xL-HjK4WGVB7xHxWjAR0h7U6SLViLfWgur7Vc-bvf43+w@mail.gmail.com>
Date:   Mon, 27 Nov 2023 08:03:24 -0600
From:   Adam Ford <aford173@...il.com>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com,
        johan@...nel.org, arnd@...db.de, gregkh@...uxfoundation.org,
        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: Re: [RFC PATCH 0/3] bluetooth/gnss: GNSS support for TiWi chips

On Sun, Nov 26, 2023 at 1:47 PM Andreas Kemnade <andreas@...nade.info> wrote:
>
> 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.

Can you tell me which WiLink chip this uses?

I'd like to try it on the WL1283, but I want to understand which
WiLink chips you're targeting.

adam
>
> 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
>
>