Am Tue, 14 Jan 2025 16:26:55 +0100 schrieb Johan Hovold <johan@xxxxxxxxxx>: > On Tue, Jan 14, 2025 at 02:05:25PM +0100, Andreas Kemnade wrote: > > Am Tue, 14 Jan 2025 13:14:45 +0100 > > schrieb Johan Hovold <johan@xxxxxxxxxx>: > > > > > > 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. > > I call it primary based on (my understanding of) the architecture, > protocol and chip family. It look to me like the FM, GPS and NFC > functionality is bolted on top of the Bluetooth one for which a protocol > already existed (and which is also used by standalone non-wilink > Bluetooth controllers). > Well, it is a bit of a definition thing. The ti-st (the older driver) stands for shared transport, so sharing multiple things over the same line, by dispatching the TLV structures accordingly to the relevant protocol drivers and at that point you say that some type values are Bluetooth, some are GNSS, some are generic power management + fw download. AFAIK using any approach based on the now-removed ti-st driver, no bluetooth would be needed in kernel for using GPS. How could something be called "bolted on top of Bluetooth" if Bluetooth is not required. But then there are devices with some type values which provide functionality related to Bluetooth. For those the h4_recv_pkt infrastructure is there. And this happens to be also useable for the jobs done by the ti-st driver. So it could be obsoleted and now removed. Probably this h4_recv_pkt stuff could also be used for other non-bluetooth-related stuff. So it is a definition thing if either say regarding that TLV structure: - everything is Bluetooth - some type values are some Bluetooth vendor channels. - these vendor channels include GNSS/FM/whatever or - some type values are Bluetooth - some other are GNSS/FM/whatever - some are some kind of generic management (firmware download, power management). The further is what is reflected by the hci_ll approach, the latter is what is used by the ti-st approach. It is a bit of a headache to forcefully draw in Bluetooth stuff, but as I am using Bluetooth anyway for keyboards, I am not eager to venture on any revive of the ti-st stuff to avoid that Bluetooth dependency Regards, Andreas
