Re: [PATCH 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
Andrew Lunn <[email protected]> Wed, 29 Apr 2026 15:15:34 +0200
| Newsgroups | org.infradead.lists.ath10k,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-block,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mmc,org.kernel.vger.linux-wireless,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Apr 29, 2026 at 10:53:13AM +0200, Bartosz Golaszewski wrote: > On Tue, Apr 28, 2026 at 4:23 PM Loic Poulain > <[email protected]> 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 <[email protected]> > > --- > > 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