What You Will Learn

• Why NVMEM providers don’t get their own top-level DT binding
• How child nodes under a provider become individual data cells
• The reg and optional bits cell properties, byte-level and bit-level
• How consumer nodes bind to named cells with nvmem-cells / nvmem-cell-names
• A complete original DT example: an MMIO fuse-box provider and an unrelated consumer node

Prerequisites

• struct nvmem_cell_info and software-declared cells from Lecture 2 of this chapter
• Basic device tree syntax: nodes, reg, #address-cells/#size-cells, phandles

Providers Borrow Their Parent’s Binding

The first thing to internalize is that NVMEM, as a framework, does not define its own device tree binding for the provider node itself. An NVMEM provider is described purely in terms of whatever bus it actually sits on — if it’s an I2C EEPROM, it’s described using the I2C binding as a child of the I2C controller node; if it’s a memory-mapped fuse block, it’s described using the standard reg-based MMIO binding. NVMEM adds exactly one optional property on top of that: a boolean read-only property that marks the whole device as non-writable from the framework’s side.

What NVMEM does define is the meaning of that provider node’s children: every child node under a provider is treated as one data cell — a named region of the provider’s storage.

Cell Properties: reg and bits

A cell without bits simply covers whole bytes as given by reg. A cell with bits narrows that further down to individual bits inside the addressed range — useful for things like a single calibration trim bit packed alongside unrelated flags in the same byte.

An Original Provider Example: MMIO Fuse Box

Consider a fictional SoC fuse block, ep-fuse, mapped at a fixed physical address, exposing a factory-programmed serial number cell and a single-bit “secure boot enabled” flag packed into another byte:

epfuse_serial covers 4 whole bytes starting at offset 0x10 — a plain byte-range cell. The epfuse_secure_flag cell narrows further: it addresses byte offset 0x30, then within that single byte picks out just bit 3, one bit wide. The framework builds an internal nvmem_cell for each child node and adds it to the system-wide cell list automatically — no driver code is needed to declare these cells when they come from DT; only the provider’s reg_read/reg_write callbacks and registration are required in C, as covered in the previous lecture.

Consumer Binding: nvmem-cells and nvmem-cell-names

A completely separate node — the consumer — references these cells by phandle, giving each one a lookup name of its own choosing:

Inside the ep-secmon driver, C code never needs to know that “serial” lives at offset 0x10 in some fuse block — it simply asks for the cell named "serial" through the standard NVMEM consumer API (devm_nvmem_cell_get() / nvmem_cell_read()), and the binding resolves the rest. This indirection is the entire point of the framework: swap the fuse box for a completely different chip on a new board revision, update only the DT, and the consumer driver doesn’t change at all.

Architecture: Why This Split Matters

The provider node owns the physical layout knowledge (offsets, bit positions, bus details). The consumer node owns only logical names. The NVMEM core sits between them, resolving phandles to cells and cells to provider callbacks at runtime — no consumer driver ever calls reg_read directly.

Common Mistakes

• Giving the provider node its own made-up binding. There isn’t one — describe it purely per its parent bus (I2C, SPI, MMIO/syscon), and let NVMEM cell semantics apply only to its children.
• Mismatched nvmem-cells and nvmem-cell-names array lengths. Every phandle in nvmem-cells needs a matching string at the same index in nvmem-cell-names; a length mismatch breaks lookup for cells after the mismatch point.
• Using bits without checking the offset range. The bit offset must be 0-7 — it addresses a position within the byte(s) selected by reg, not an absolute bit address into the whole device.
• Forgetting #address-cells/#size-cells on the provider node. Without them, child cell nodes’ reg properties won’t parse the way you expect.

Best Practices

• Name cell nodes descriptively in DT (serial@10, not cell0@10) — it makes the binding self-documenting when someone reads the board DTS later.
• Keep cell names in nvmem-cell-names stable across board revisions even if the underlying provider or offsets change — that’s the whole benefit of the indirection.
• Reserve bits for genuinely sub-byte fields; if a cell always aligns to whole bytes, leave bits out entirely rather than specifying 0 8.
• Document the read-only property explicitly on provider nodes holding factory-programmed data like serials or calibration trims, so accidental writes fail at the framework level.

Summary / Key Takeaways

• NVMEM providers reuse their parent bus’s DT binding — there is no NVMEM-specific provider binding beyond the optional read-only property.
• Every child node of a provider becomes a data cell; reg is mandatory, bits is optional for sub-byte fields.
• Consumers bind to cells purely by phandle and logical name via nvmem-cells / nvmem-cell-names, staying completely decoupled from physical layout.

Conclusion

Device tree bindings are what turn a working NVMEM provider driver into something the rest of the system can actually discover and use — without them, cells only exist as hardcoded C structures tied to one board. Once you’re comfortable declaring provider nodes, cells, and consumer references, you have the full picture needed to both write new NVMEM providers and wire arbitrary consumer drivers to whatever storage a given board exposes. That completes the practical core of the NVMEM framework in this free linux device drivers course.

Interview Questions

FAQ