From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 9FD7D3C8731; Wed, 29 Apr 2026 13:16:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777468568; cv=none; b=AWAYuFTx3tf0l7htUbPKun2e5KXv+YsxaoZxAeEnVPDrAmYgIyy6M9v6GetEVnMjSOQz5N9tHwCr8FsW9V1U6T+J6q77C3mJKHaA6N33pQ83r/UD0nEsGxnC6qsVc+eCAocUcJ6disl78XqLmjt13TXMhm7xe7HlOSCivcJD7AA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777468568; c=relaxed/simple; bh=bQN4HvhkFbObokdtlU0dNRRj8LRd1IT4TuaGdxzdS1Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TBUQYLCZXW+iU73wefYmFO4j29hSU5WtBJKLojigwwo1vJSNExxPNKmOKq8GbVvLmpyJktezB9ahgNKujHMSOdHotzykhRy0q7c+YMs4CY63svFBCopysLeJmK+2NJWJp/6IKc+toZGGQc24bvOXC7VhCz0rITLhPDkUZ5PJ5ZY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=nyhjsUce; arc=none smtp.client-ip=156.67.10.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="nyhjsUce" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Content-Disposition: In-Reply-To:References; bh=00CFuie/XpWwEcDph5j08NpwMgP7MNQHVTxW7dFgKvc=; b=ny hjsUcehLWZHWmuH2QESULtjCVCzsB1GVU/3RY7G8eO0LlZxg2TwHfvVGmvv68h2hOgOqaMx5j3zMi ZWKXOP8J7vwKYMWMmgN0+IHllH8GYfSvIlBNQPz8hcfTPChEK7Rq6H+eqMH7z5vy7LUOO6ooCm6Qn PGTItSJjEk8NOks=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1wI4lK-000XF0-0n; Wed, 29 Apr 2026 15:15:34 +0200 Date: Wed, 29 Apr 2026 15:15:34 +0200 From: Andrew Lunn To: Bartosz Golaszewski Cc: Loic Poulain , Ulf Hansson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , Konrad Dybcio , Jens Axboe , Johannes Berg , Jeff Johnson , Marcel Holtmann , Luiz Augusto von Dentz , Balakrishna Godavarthi , Rocky Liao , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org, daniel@makrotopia.org Subject: Re: [PATCH 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval Message-ID: References: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com> <20260428-block-as-nvmem-v1-7-6ad23e75190a@oss.qualcomm.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Apr 29, 2026 at 10:53:13AM +0200, Bartosz Golaszewski wrote: > On Tue, Apr 28, 2026 at 4:23 PM Loic Poulain > wrote: > > > > Some devices store the Bluetooth BD address in non-volatile > > memory, which can be accessed through the NVMEM framework. > > Similar to Ethernet or WiFi MAC addresses, add support for > > reading the BD address from a 'local-bd-address' NVMEM cell. > > > > As with the device-tree provided BD address, add a quirk to > > indicate whether a device or platform should attempt to read > > the address from NVMEM when no valid in-chip address is present. > > Also add a quirk to indicate if the address is stored in > > big-endian byte order. > > > > Signed-off-by: Loic Poulain > > --- > > Is there any reason why we can't extend the existing > of_get_mac_address() with another property name and use it here? It > already has support for mac addresses from nvmem. Does it even need to be a different property name? Is a bluetooth MAC address somehow different to an Ethernet MAC address? Isn't it just a EUI-48, independent of it being Ethernet, Bluetooth, wifi, fddi, token ring, homing pigeon? Andrew