What You Will Learn

Prerequisites

What Is a Multi-Function Device?

A multi-function device is a single piece of silicon that physically looks like one chip, but logically behaves like several independent devices. A power-management IC is the textbook example: it might contain a battery charger, a set of voltage regulators, a real-time clock, and a handful of GPIO lines, all reachable through one shared I2C or SPI bus, and often through one shared register map.

Without a dedicated subsystem, every driver author would end up re-inventing the same plumbing: who talks to the bus first, how IRQs from the chip are demultiplexed to the right sub-function, and how each sub-function gets its own platform_device so that the existing regulator, rtc, or gpio subsystems can bind their normal drivers to it. The MFD subsystem, implemented in drivers/mfd/mfd-core.c, solves exactly this problem.

The mfd_cell Structure

Each sub-function of an MFD chip is described to the kernel using one struct mfd_cell entry, defined in include/linux/mfd/core.h. The core driver builds an array of these cells — one per sub-function — and hands the whole array to the MFD core in a single call.

struct mfd_cell {
	const char		*name;
	int			id;
	const char		*devname;

	int			(*enable)(struct platform_device *dev);
	int			(*disable)(struct platform_device *dev);

	int			(*suspend)(struct platform_device *dev);
	int			(*resume)(struct platform_device *dev);

	void			*platform_data;
	size_t			pdata_size;

	const struct software_node *swnode;

	const char		*of_compatible;
	u64			of_reg;
	bool			use_of_reg;

	int			num_resources;
	const struct resource	*resources;

	bool			ignore_resource_conflicts;

	bool			pm_runtime_no_callbacks;
};

Registering Cells: mfd_add_devices() and devm_mfd_add_devices()

Once the cell array is ready, the core driver registers every cell in one shot. The managed variant is preferred in modern drivers because the sub-devices are automatically unregistered when the parent device is removed.

int devm_mfd_add_devices(struct device *dev, int id,
			  const struct mfd_cell *cells, int n_devs,
			  struct resource *mem_base,
			  int irq_base, struct irq_domain *domain);

The plain, non-managed version has the same signature but is called mfd_add_devices(), and it must be paired with an explicit mfd_remove_devices() call in the driver’s remove path.

Original Coding Example: ep_mfd_demo

The following driver is an original teaching example built for this course. It models a tiny fictional PMIC that exposes two sub-functions: an LED cell and a misc-status cell, matched purely on the of_compatible string so no device tree changes are required for this lecture.

// ep_mfd_demo.c — original EmbeddedPathashala MFD core driver example
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/mfd/core.h>

static const struct mfd_cell ep_mfd_cells[] = {
	{
		.name          = "ep-mfd-led",
		.of_compatible = "ep,mfd-led",
	},
	{
		.name          = "ep-mfd-status",
		.of_compatible = "ep,mfd-status",
	},
};

static int ep_mfd_probe(struct platform_device *pdev)
{
	int ret;

	dev_info(&pdev->dev, "ep_mfd_demo: registering %zu cells\n",
		 ARRAY_SIZE(ep_mfd_cells));

	ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
				    ep_mfd_cells, ARRAY_SIZE(ep_mfd_cells),
				    NULL, 0, NULL);
	if (ret) {
		dev_err(&pdev->dev, "failed to add mfd cells: %d\n", ret);
		return ret;
	}

	dev_info(&pdev->dev, "ep_mfd_demo: probe complete\n");
	return 0;
}

static const struct of_device_id ep_mfd_of_match[] = {
	{ .compatible = "ep,mfd-demo" },
	{ }
};
MODULE_DEVICE_TABLE(of, ep_mfd_of_match);

static struct platform_driver ep_mfd_driver = {
	.driver = {
		.name           = "ep-mfd-demo",
		.of_match_table = ep_mfd_of_match,
	},
	.probe = ep_mfd_probe,
};
module_platform_driver(ep_mfd_driver);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("EmbeddedPathashala MFD subsystem teaching driver");

Build and Run Steps

# Kbuild file for an out-of-tree module
obj-m += ep_mfd_demo.o

# Build against the running kernel headers
make -C /lib/modules/$(uname -r)/build M=$PWD modules

# Load the module (probe is triggered via a matching platform device)
sudo insmod ep_mfd_demo.ko

# Watch the kernel log
dmesg | tail -5

# Unload
sudo rmmod ep_mfd_demo

Expected dmesg Output

[  102.441823] ep_mfd_demo: registering 2 cells
[  102.441917] ep_mfd_demo: probe complete

Because both cells use of_compatible matching only, no separate driver is bound in this lecture — you will see the platform devices appear under /sys/bus/platform/devices/ once a matching device tree node with two child nodes is present, which we build in the next lecture on device tree binding.

Common Mistakes

Best Practices

Real-World Use Cases

MFD drivers are everywhere in embedded Linux: PMIC drivers such as da9055, tps65086, and axp20x use exactly this pattern to expose regulator, RTC, and GPIO cells from one chip. Audio codecs that bundle a mixer and a jack-detection block, and SoC “top-level” companion chips on set-top boxes, follow the same design.

Summary / Key Takeaways

Conclusion

The MFD subsystem is a small but elegant piece of the Linux driver model: rather than inventing a new binding mechanism for every multi-function chip, it reuses the existing platform device infrastructure and simply automates the bookkeeping of splitting one device into many. In the next lecture of this free linux kernel development course, we describe these same cells in the device tree so the kernel can match them automatically on boot.

Frequently Asked Questions