Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4073-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 25 Apr 2024 18:13:55 +0200
From: Johan Hovold <johan@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Janaki Ramaiah Thota <quic_janathot@quicinc.com>,
	Johan Hovold <johan+linaro@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Matthias Kaehlcke <mka@chromium.org>,
	linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>
Subject: Re: [PATCH] Bluetooth: qca: fix invalid device address check
Message-ID: <ZiqBQ3r3gRk2HBir@hovoldconsulting.com>
References: <20240416091509.19995-1-johan+linaro@kernel.org>
 <CAD=FV=UBHvz2S5bd8eso030-E=rhbAypz_BnO-vmB1vNo+4Uvw@mail.gmail.com>
 <Zid6lfQMlDp3HQ67@hovoldconsulting.com>
 <CAD=FV=XoBwYmYGTdFNYMtJRnm6VAGf+-wq-ODVkxQqN3XeVHBw@mail.gmail.com>
 <ZioW9IDT7B4sas4l@hovoldconsulting.com>
 <CAD=FV=X5DGd9E40rve7bV7Z1bZx+oO0OzjsygEGQz-tJ=XbKBg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD=FV=X5DGd9E40rve7bV7Z1bZx+oO0OzjsygEGQz-tJ=XbKBg@mail.gmail.com>

On Thu, Apr 25, 2024 at 11:22:50PM +0800, Doug Anderson wrote:

> Quick question. I haven't spent lots of time digging into the
> Bluetooth subsystem, but it seems like if the device tree property is
> there it should take precedence anyway, shouldn't it? In other words:
> if we think there is built-in storage for the MAC address but we also
> see a device tree property then we need to decide which of the two we
> are going to use. Are there any instances where there's a bogus DT
> property and we want the built-in storage to override it?

I guess we could decide to implement something like that, but note that
a devicetree may have an all-zero address defined by default which the
boot firmware may or may not fill in.

So we can't just use the presence of the address property as an
indication that the device has an address, but we could of course parse
it and see if it's non-zero first. (Actually, I think this bit about
checking for a non-zero address is already implemented.)

Note however that we still need to determine when the controller address
is invalid for the common case where there is no devicetree property and
user space needs to provide an address before the controller can be used.

Johan