Stable Archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Janaki Ramaiah Thota <quic_janathot@quicinc.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Doug Anderson <dianders@chromium.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, quic_mohamull@quicinc.com,
	quic_hbandi@quicinc.com, quic_anubhavg@quicinc.com
Subject: Re: [PATCH] Bluetooth: qca: generalise device address check
Date: Thu, 2 May 2024 12:11:40 +0200	[thread overview]
Message-ID: <ZjNm3OnJ1fdHctaZ@hovoldconsulting.com> (raw)
In-Reply-To: <a09ab4e3-699b-4eb7-bc64-44c9de6db78d@quicinc.com>

On Thu, May 02, 2024 at 12:35:19PM +0530, Janaki Ramaiah Thota wrote:
> On 4/30/2024 6:37 PM, Johan Hovold wrote:

> > But here we disagree. A non-unique address is not a valid one as it will
> > cause collisions if you have more than one such controller.
> > 
> > I understand that this may be convenient/good enough for developers in
> > some cases, but this can hurt end users that do not realise why things
> > break.
> > 
> > And a developer can always configure an address manually or patch the
> > driver as needed for internal use.
> > 
> > Are there any other reasons that makes you want to keep the option to
> > configure the device address through NVM files? I'm assuming you're not
> > relying on patching NVM files to provision device-specific addresses
> > after installation on target?

> We prefer unique address to be flashed on OTP (persistent) memory of
> BT-Chip, which is supported by almost all QC BT-chips.

Yes, that is certainly the best option for everyone.

> If someone is not able to do that/ does not prefer that, they still
> have an option to flash unique address in firmware binary (NVM)file.
> This does not require setting BD address from user space.
> 
> Also until a developer flashes OTP/ keep unique BD-Address in NVM,
> he should be able to run most of the use cases from Device, that's
> why we want to make it as configured.

Ok, but a developer can still do this since they can patch the driver to
disable the check temporarily or, alternatively, just update the
devicetree with a valid unique address.

> In our opinion this provides best Out of box experience.

You can also look into improving support in user space (e.g. bluez) for
providing a valid unique address in a simple text-based configuration
file.

That would be useful for all Linux users and not require having access
to Qualcomm specific tools to update the NVM configuration file (which
could also be in a read-only file system, e.g. on Android).

Johan

  reply	other threads:[~2024-05-02 10:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26 15:58 [PATCH] Bluetooth: qca: generalise device address check Johan Hovold
2024-04-26 17:23 ` Doug Anderson
2024-04-27  9:51   ` Johan Hovold
2024-04-29 10:04     ` Janaki Ramaiah Thota
2024-04-29 14:02       ` Johan Hovold
2024-04-29 14:06         ` Johan Hovold
2024-04-29 17:12         ` Luiz Augusto von Dentz
2024-04-29 17:31           ` Luiz Augusto von Dentz
2024-04-30  7:07             ` Johan Hovold
2024-04-30 12:52               ` Janaki Ramaiah Thota
2024-04-30 13:07                 ` Johan Hovold
2024-04-30 14:04                   ` Luiz Augusto von Dentz
2024-04-30 14:36                     ` Johan Hovold
2024-05-02  7:05                   ` Janaki Ramaiah Thota
2024-05-02 10:11                     ` Johan Hovold [this message]
2024-05-02 17:03                       ` Janaki Ramaiah Thota
2024-05-02 17:32                         ` Luiz Augusto von Dentz
2024-05-03  7:12                           ` Janaki Ramaiah Thota
2024-04-30 14:21     ` Luiz Augusto von Dentz
2024-04-30 14:38       ` Johan Hovold

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=ZjNm3OnJ1fdHctaZ@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=dianders@chromium.org \
    --cc=johan+linaro@kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=quic_anubhavg@quicinc.com \
    --cc=quic_hbandi@quicinc.com \
    --cc=quic_janathot@quicinc.com \
    --cc=quic_mohamull@quicinc.com \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).