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: <20250114140525.763b4c33@akair>
Date: Tue, 14 Jan 2025 14:05:25 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Johan Hovold <johan@...nel.org>
Cc: marcel@...tmann.org, luiz.dentz@...il.com, pmenzel@...gen.mpg.de,
 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: [PATCH v4 2/4] Bluetooth: ti-st: Add GNSS subdevice for TI
 Wilink chips

Am Tue, 14 Jan 2025 13:14:45 +0100
schrieb Johan Hovold <johan@...nel.org>:

> > GNSS support is available through
> > channel 9 whilst FM is through channel 8. Add a platform subdevice for
> > GNSS so that a driver for that functionality can be build.  
> 
> > To avoid having
> > useless GNSS devices, do it only when the devicetree node name contains
> > gnss.  
> 
> That's seems like an unorthodox use of device tree. These devices are
> primarily (WiFi and) Bluetooth controllers so should probably not have
> gone about and updated the node names to 'bluetooth-gnss' as you did,
> for example, here:

yes, the matching of the node name is a bit unorthodox. How do you
define primary? The old design with ti-st driver and bluetooth and
other functions on top does not look like anything primary. If you look
at the current situation with the GNSS stuff sitting on to of
bluetooth, the picture is different, but that is implementation. As the
devicetree is describing hardware, having the nodenames describe things
seems like the right way to do.
But I agree with you that the driver should not care about the node
name, but use a boolean property.

Regards,
Andreas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ