Chapter 12: Leveraging the NVMEM Framework

The NVMEM (Non-Volatile MEMory) framework is the kernel layer to handle non-volatile storage, such as EEPROM, eFuse, and so on. The drivers for these devices used to be stored in drivers/misc/, where most of the time each one had to implement its own API to handle identical functionalities, either for kernel users or to expose its content to user space. It turned out that these drivers seriously lacked abstraction code. Moreover, the increasing support for the number of these devices in the kernel led to a lot of code duplication.

The introduction of this framework in the kernel aims at solving these previously mentioned issues. It also introduces DT representation for consumer devices to get the data they require (MAC addresses, SoC/revision ID, part numbers, and so on) from the NVMEM. We will begin this chapter by introducing NVMEM data structures, which are mandatory to walk through the framework, and then we will look at the NVMEM provider...

Technical requirements

The following are prerequisites for this chapter:

• C programming skills
• Kernel programming and device driver development skills
• Linux kernel v4.19.X sources, available at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/refs/tags

Introducing NVMEM data structures and APIs

NVMEM is a small framework with a reduced set of APIs and data structures. In this section, we will introduce those APIs and data structures, as well as the concept of a cell, which is the base of this framework.

NVMEM is based on the producer/consumer pattern, just like the clock framework described in Chapter 4, Storming the Common Clock Framework. There is a single driver for the NVMEM device, exposing the device cells so that they can be accessed and manipulated by consumer drivers. While the NVMEM device driver must include <linux/nvmem-provider.h>, consumers have to include <linux/nvmem-consumer.h>. This framework has only a few data structures, among which is struct nvmem_device, which looks as follows:

struct nvmem_device {
    const char  *name;
    struct module *owner;
    struct device dev;
    int stride;
   ...

Writing the NVMEM provider driver

The provider is the one exposing the device memory so that other drivers (the consumers) can access it. The main tasks of these drivers are as follows:

• Providing suitable NVMEM configuration with respect to the device’s datasheet, along with the routines allowing you to access the memory
• Registering the device with the system
• Providing device tree binding documentation

That is all the provider has to do. Most (the rest) of the mechanism/logic is handled by the NVMEM framework’s code.

NVMEM device (un)registration

Registering/unregistering the NVMEM device is actually part of the provider-side driver, which can use the nvmem_register()/nvmem_unregister() functions, or their managed versions, devm_nvmem_register()/devm_nvmem_unregister():

struct nvmem_device *nvmem_register(const                      ...

NVMEM consumer driver APIs

NVMEM consumers are drivers who access the storage exposed by the producer. These drivers can pull the NVMEM consumer API by including <linux/nvmem-consumer.h>, which will bring the following cell-based APIs in:

struct nvmem_cell *nvmem_cell_get(struct device *dev,
                                  const char *name);
struct nvmem_cell *devm_nvmem_cell_get(struct device *dev,
                                       const char *name);
void nvmem_cell_put(struct nvmem_cell *cell);
void devm_nvmem_cell_put(struct device *dev,
           &...

Summary

In this chapter, we went through the NVMEM framework implementation in the Linux kernel. We introduced its APIs from the producer side as well as from the consumer side, and also discussed how to use it from user space. I have no doubt that these devices have their place in the embedded world.

In the next chapter, we will address the issue of reliability by means of watchdog devices, discussing how to set up these devices and writing their Linux kernel drivers.