From: Johan Hovold <johan@kernel.org>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: marcel@holtmann.org, luiz.dentz@gmail.com, pmenzel@molgen.mpg.de,
jirislaby@kernel.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
"Adam Ford" <aford173@gmail.com>,
"Tony Lindgren" <tony@atomide.com>,
tomi.valkeinen@ideasonboard.com,
"Péter Ujfalusi" <peter.ujfalusi@gmail.com>,
robh@kernel.org, hns@goldelico.com
Subject: Re: [PATCH v4 2/4] Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips
Date: Tue, 14 Jan 2025 16:26:55 +0100 [thread overview]
Message-ID: <Z4aCP-r-IUTmyizm@hovoldconsulting.com> (raw)
In-Reply-To: <20250114140525.763b4c33@akair>
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@kernel.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.
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).
> As the
> devicetree is describing hardware, having the nodenames describe things
> seems like the right way to do.
We have serial controllers which also implements a gpio controller, but
no one would expect those to be named 'serial-gpio' for example. But we
can still describe that with a 'gpio-controller' property (and the
compatible string indicates what the device is capable of).
Since these chips do not come without Bluetooth (e.g. only wifi + gps)
and the Bluetooth protocol is used to access the GPS function I think
it makes perfect sense to just leave them named 'bluetooth'. That also
avoids having to add all the permutations of
bluetooth-gnss-fmradio-nfc
etc. (and having to name them such also when there is no gnss antenna
connected).
> But I agree with you that the driver should not care about the node
> name, but use a boolean property.
Johan
next prev parent reply other threads:[~2025-01-14 15:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 18:30 [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips Andreas Kemnade
2024-06-06 18:30 ` [PATCH v4 1/4] gnss: Add AI2 protocol used by some TI combo chips Andreas Kemnade
2025-01-14 12:00 ` Johan Hovold
2024-06-06 18:30 ` [PATCH v4 2/4] Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips Andreas Kemnade
2025-01-14 12:14 ` Johan Hovold
2025-01-14 13:05 ` Andreas Kemnade
2025-01-14 15:26 ` Johan Hovold [this message]
2025-01-14 16:26 ` Andreas Kemnade
2024-06-06 18:30 ` [PATCH v4 3/4] gnss: Add driver for AI2 protocol Andreas Kemnade
2025-01-14 12:33 ` Johan Hovold
2024-06-06 18:30 ` [PATCH RFC v4 4/4] gnss: ai2: replace long sleeps by wait for acks Andreas Kemnade
2025-01-14 12:36 ` Johan Hovold
2024-06-06 20:04 ` [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips Luiz Augusto von Dentz
2024-06-06 20:19 ` Andreas Kemnade
2024-06-08 19:00 ` Adam Ford
2024-06-08 19:20 ` Andreas Kemnade
2024-06-10 23:17 ` Adam Ford
2024-06-11 8:32 ` Andreas Kemnade
2024-09-02 9:22 ` Andreas Kemnade
2024-09-02 9:26 ` Johan Hovold
2024-11-18 9:52 ` Andreas Kemnade
2025-01-14 11:57 ` Johan Hovold
2025-01-14 12:35 ` H. Nikolaus Schaller
2025-01-16 1:10 ` Sebastian Reichel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z4aCP-r-IUTmyizm@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=aford173@gmail.com \
--cc=andreas@kemnade.info \
--cc=gregkh@linuxfoundation.org \
--cc=hns@goldelico.com \
--cc=jirislaby@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=peter.ujfalusi@gmail.com \
--cc=pmenzel@molgen.mpg.de \
--cc=robh@kernel.org \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox