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]
Date: Mon, 29 Jan 2024 21:53:48 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com,
 johan@...nel.org, jirislaby@...nel.org, gregkh@...uxfoundation.org,
 linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org, Adam Ford
 <aford173@...il.com>, Tony Lindgren <tony@...mide.com>,
 tomi.valkeinen@...asonboard.com, Péter Ujfalusi
 <peter.ujfalusi@...il.com>, robh@...nel.org, hns@...delico.com
Subject: Re: [RFC PATCH v2 3/3] gnss: Add driver for AI2 protocol

On Mon, 29 Jan 2024 08:53:27 +0100
Paul Menzel <pmenzel@...gen.mpg.de> wrote:

> Dear Andreas,
> 
> 
> Thank you for your patch.
> 
> 
> Am 28.01.24 um 18:33 schrieb Andreas Kemnade:
> > Add a driver for the Air Independent Interface protocol used by some TI
> > Wilink combo chips. Per default, send out just NMEA to userspace and turn
> > on/off things at open()/close() but keep the door open for any
> > sophisticated development regarding the AI2 protocol by having a kernel
> > parameter to turn it into raw mode resembling /dev/tigps provided by some
> > TI vendor kernels.  
> 
> It’d be great, if you could add the name the kernel parameter *ai2raw*, 
> and also document at least one of these vendor kernels.
> 
> Could you give a high level overview of the driver design?
> 
basically I rely on the hci_ll stuff for doing wakeup and initializing
the firmware. So I queue up there another sort of TLV construction besides
the Bluetooth packets using the hci_dev infrastructure and offload all the
GNSS specific handling to a platform subdevice.
So in raw AI2 mode, the input is just en/decapsulated into GPS_CH9_OP_READ/WRITE
packets and sent/recv via the hci queuing system (gnss_recv_frame() / ai2_send_frame()).

On top of that in NMEA mode, proper intialization is done at
open()/close(). The commands are in ai2_compose_frame() prepared by adding
checksums, escaping any occurance of 0x10 and adding start/end markes()
In the rx path, the mechanism works the other way round and if the packet
is an NMEA report it is sent to userspace.

> What device did you test with?
>
As said in 0/3 I am testing with an Epson Moverio BT-200 containing
a WL1283.

Regards,
Andreas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ