Re: [PATCH] Bluetooth: qca: generalise device address check

[Janaki Ramaiah Thota]

Hi Johan,

On 5/2/2024 3:41 PM, Johan Hovold wrote:
> 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.

If a developer has to patch a code/update device-tree, that is not
a "out of box" experience. By "out of box" we meant, things should
work without much changes required.

> 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.

We don't think putting a must-have dependency in user space is the
right thing to do, especially when we own a code in kernel space.

> 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).

Having a non-unique valid address allows a developer to handle all
scenarios where he/she is dealing with DUT + commercial device and
in such case, default BD-Address from nvm file should also be okay.
Only when 2/more similar devices are in the mix, they need unique
address. In that case we are providing end developers with a NVM
utility(part of Qcom build Not open source tool)to change this
default BD-Address.

> Johan

-Janaki Ram