From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E811242AA5; Tue, 30 Apr 2024 13:07:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714482446; cv=none; b=QJrXMxJK2dzyrJThXq6b/wjq3iqj0ISTKDPYT8IlP5qLDIdqG+d9I+tacWhHMpo8cy6B5uwSIyVnrIJlqxwnwOQwsFZf1DA/lippVoI/gaLdneBdO3WyMLw/dzfX7qh7+tqTZUOE9sVuBTPrgQqi3mTwspmW90abfIDVLDcq1OM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714482446; c=relaxed/simple; bh=qiB8b8aLGWUB+eW++cRid6E+04uq3CftdA6/Q44apIo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MbbfRYT6A986sTUlDX/L8xuQgRDpUVSEgylVxeCVJQOGFS+w4Q+M2xozDFI3apvvuPscYspkyze8gTOYb2H9E1vpcx7C7gvi7QGwOnPGJ3Ac5XuRD8DV89j8uxQE4KuOF5bPdak5LoY3S8+4oEtO5XvT2AKBjso4VD/BcCyN01s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UBJeq0bb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UBJeq0bb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 751C5C2BBFC; Tue, 30 Apr 2024 13:07:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714482445; bh=qiB8b8aLGWUB+eW++cRid6E+04uq3CftdA6/Q44apIo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UBJeq0bbPN317U9uxx2fIaIucH6xI2Fc7aKbxOwOVV6pLDIovvHFJjiwY9CiiKt0k cMFeGHF/xDFlqhnZISR8MnYp74hPGMrvGK1f67KZC4iCpAtkDYR2QQSvREBPtFphs0 RKeM8Qr85mIh2L33tfOFplIUlzyWOi5TWdJXeU/wCJX9Nr/HM/0viGOTQ7Ohj1VMVL pBbKyNxXASVF42DCSYtwuhTieLO2zyBAwgbzdGCjx5s+EFT1ME4VoUf6M9bEB/9xdE N5Ke11VPDfWk6rUgWK7H0DUmuV/2BNe7QcbuPGY52qi3qCR12fmruRszx9fWUqILfP gGMkL0VEqKaBA== Received: from johan by xi.lan with local (Exim 4.97.1) (envelope-from ) id 1s1nCf-000000007Ur-3g1n; Tue, 30 Apr 2024 15:07:26 +0200 Date: Tue, 30 Apr 2024 15:07:25 +0200 From: Johan Hovold To: Janaki Ramaiah Thota Cc: Luiz Augusto von Dentz , Doug Anderson , Johan Hovold , Marcel Holtmann , 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 Message-ID: References: <20240426155801.25277-1-johan+linaro@kernel.org> <9eebd77b-c070-4260-a979-9b97f14eb5b1@quicinc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9eebd77b-c070-4260-a979-9b97f14eb5b1@quicinc.com> On Tue, Apr 30, 2024 at 06:22:26PM +0530, Janaki Ramaiah Thota wrote: > On 4/30/2024 12:37 PM, Johan Hovold wrote: > > On Mon, Apr 29, 2024 at 01:31:53PM -0400, Luiz Augusto von Dentz wrote: > >> 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. > > > > Yes agree with this point. > BD address should be treated as invalid if it is 00:00:00:00:00:00. We all agree on that. > NVM Tag 2: bd address is default BD address (other than 0), should be > configured as valid address and as its not unique address and it will > be same for all devices so mark it is configured but still allow > user-space to change the address. 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? Johan