Received-SPF: pass (google.com: domain of linux-kernel+bounces-162759-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240426155801.25277-1-johan+linaro@kernel.org>
 <CAD=FV=V-pG9+5fLonNvydmjS=ziUFUHAyF8T7YTkEHiO405aSA@mail.gmail.com>
 <ZizKmtcUIYAMpvOQ@hovoldconsulting.com> <dbba45d2-f955-4d3a-aeab-26b0900d5823@quicinc.com>
 <Zi-ohCWv58d2h5VM@hovoldconsulting.com> <CABBYNZJyqrNKebwPPPqjOAdrkpBJ0fqHyD2iVtypeQKCDcL+AQ@mail.gmail.com>
In-Reply-To: <CABBYNZJyqrNKebwPPPqjOAdrkpBJ0fqHyD2iVtypeQKCDcL+AQ@mail.gmail.com>
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date: Mon, 29 Apr 2024 13:31:53 -0400
Message-ID: <CABBYNZJyRR9FA7TYN4+aWMtG9FPUBWMvCtMNUfvaEzxVcYOt-g@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: qca: generalise device address check
To: Johan Hovold <johan@kernel.org>
Cc: Janaki Ramaiah Thota <quic_janathot@quicinc.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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Apr 29, 2024 at 1:12=E2=80=AFPM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 29, 2024 at 10:02=E2=80=AFAM Johan Hovold <johan@kernel.org> =
wrote:
> >
> > Hi Janaki,
> >
> > Please avoid top and remember to trim unnecessary context when replying
> > to the mailing lists.
> >
> > On Mon, Apr 29, 2024 at 03:34:32PM +0530, Janaki Ramaiah Thota wrote:
> >
> > > Having a default BDA list from NVM BDA tag value will prevent develop=
ers
> > > from using the device if there is no user space app(In Fluoride) to s=
et
> > > the BDA. Therefore, we are requesting to use default address check pa=
tch,
> > > so that developer can change the NVM BDA to make use of the device.
> >
> > But a developer on such an old platform that can patch and replace the
> > NVM configuration file should also be able to just disable the check in
> > the driver right (e.g. by commenting out the call to
> > qca_check_bdaddr())?
> >
> > >   List Of default Addresses:
> > >   ---------------------------------------------------------
> > > |       BDA          |      Chipset                       |
> > >   ---------------------------------------------------------
> > > | 39 80 10 00 00 20  |  WCN3988 with ROM Version 0x0200   |
> > >   ---------------------------------------------------------
> > > | 39 80 12 74 08 00  |  WCN3988 with ROM Version 0x0201   |
> > >   ---------------------------------------------------------
> > > | 39 90 21 64 07 00  |  WCN3990                           |
> > >   ---------------------------------------------------------
> > > | 39 98 00 00 5A AD  |  WCN3991                           |
> > >   ---------------------------------------------------------
> > > | 00 00 00 00 5A AD  |  QCA DEFAULT                       |
> > >   ---------------------------------------------------------
> >
> > What about WCN6750 and 64:90:00:00:5a:ad?
> >
> > And then there's currently also:
> >
> > > > bluetooth hci0: bd_addr =3D 61:47:aa:31:22:14 (qca/nvm_00130300.bin=
)
> > > > bluetooth hci0: bd_addr =3D 61:47:aa:32:44:07 (qca/nvm_00130302.bin=
)
> >
> > Which controllers use these configurations?
>
> These are not unique addresses though, we can't just have addresses by
> chipset address mapping logic as that would cause address clashes over
> the air, e.g. if there are other devices with the same chipset in the
> vicinity.

I see where this is going now, the firmware actually contain these
duplicated addresses which then are checked and cause
HCI_QUIRK_USE_BDADDR_PROPERTY then the tries
hci_dev_get_bd_addr_from_property which loads the local-bd-address
property from the parente device (SOC?), btw that could also have an
invalid/duplicated address.

Anyway the fact that firmware loading itself is programming a
potentially duplicated address already seems wrong enough to me,
either it shall leave it as 00... or set a valid address otherwise we
always risk missing yet another duplicate address being introduced and
then used over the air causing all sorts of problems for users.

So to be clear, QCA firmware shall never attempt to flash anything
other than 00:00:00:00:00:00 if you don't have a valid and unique
identity address, so we can get rid of this table altogether.

ps: If the intention is to have these addresses for testing then these
firmwares files shall probably be kept private, since as explained
above the use of duplicated addresses will cause problems to users who
have no idea they have to be changed.

>
> --
> Luiz Augusto von Dentz


--=20
Luiz Augusto von Dentz