Re: [PATCH v8 0/9] Support for block device NVMEM providers
Ulf Hansson <[email protected]>
| Newsgroups | org.kernel.vger.linux-block,org.infradead.lists.ath10k,org.kernel.vger.linux-arm-msm,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 | <CAPx+jO8-9YSJtXNfnTrUX_JiCyddXHn=wHek9=c99+fNp22Zog@mail.gmail.com> |
On Wed, Jul 22, 2026 at 3:56 PM Srinivas Kandagatla <[email protected]> wrote: > > > > On 7/3/26 2:45 PM, Loic Poulain wrote: > > On embedded devices, it is common for factory provisioning to store > > device-specific information, such as Ethernet or WiFi MAC addresses, > > in a dedicated area of an eMMC partition. This avoids the need for > > and additional EEPROM/OTP and leverages the persistence of eMMC. > > > > One example is the Arduino UNO-Q, where the WiFi MAC address and the > > Bluetooth Device address are stored in the eMMC Boot1 partition. > > > > Until now, accessing this information required a custom bootloader > > to read the data and inject it into the Device Tree before handing > > control over to the kernel. This approach is fragile and leads to > > device-specific workarounds. > > > > Rather than adding a new NVMEM provider specifically to the eMMC > > subsystem, the new support operates at the block layer, allowing any > > block device to behave like other non-volatile memories such as EEPROM > > or OTP. > > > > This series builds on earlier work by Daniel Golle that enables block > > devices to act as NVMEM providers: > > https://lore.kernel.org/all/6061aa4201030b9bb2f8d03ef32a564fdb786ed1.1709667858.git.daniel@makrotopia.org/ > > > > It also introduces an NVMEM layout description for the Arduino UNO-Q, > > allowing device-specific data stored in the eMMC Boot1 partition to > > be accessed in a standard way. > > > > WiFi and Ethernet already support retrieving MAC addresses from NVMEM. > > Bluetooth requires similar support, which is also addressed. > > > > Note that this is currently limited to MMC-backed block devices, as > > only the MMC core associates a firmware node with the block device > > (add_disk_fwnode). This can be easily extended in the future to > > support additional block drivers. > > > > Signed-off-by: Loic Poulain <[email protected]> > > What is the merge strategy here, Am happy to take it via nvmem tree if > all the non nvmem patches are acked or reviewed-by. I am planning to pick up patch1 (dt), but waiting until all the complete series is ready to go. [...] Kind regards Uffe