What You Will Learn

Prerequisites

Why Syscon Exists

Many SoCs have a block of miscellaneous registers that configure unrelated features — pin muxing bits, reset lines, clock gating, boot-mode straps — packed together in one MMIO region simply because that is how the silicon was laid out. None of these bits belong to one cohesive “device” in the driver-model sense, so writing a dedicated subsystem driver for them makes no sense. The syscon framework, implemented in drivers/mfd/syscon.c, solves this by wrapping the region in a plain regmap that any other driver in the kernel can look up and share safely.

The Syscon Lookup API

The header for consumers is <linux/mfd/syscon.h>, and since it is regmap-based you also need <linux/regmap.h>. Three lookup styles cover most use cases:

Every lookup function returns a normal struct regmap *, so once you have it, every regmap read/write helper from the earlier regmap lectures works unchanged.

The simple-mfd Binding

When an MFD node’s only job is to expose its register range to its own children through a shared regmap — no enable/disable hooks, no interrupt demultiplexing, nothing beyond “share this address range” — you don’t need a custom core driver at all. Adding "simple-mfd" alongside your vendor compatible string tells the generic simple-mfd driver to create a regmap for the node and register every child node as its own platform device automatically.

/* ep-syscon-demo.dtsi — original EmbeddedPathashala teaching overlay */
soc {
	#address-cells = <1>;
	#size-cells = <1>;

	ep_syscon: system-controller@1c000000 {
		compatible = "ep,ep-syscon", "simple-mfd", "syscon";
		reg = <0x1c000000 0x1000>;
	};

	ep_consumer: ep-consumer@0 {
		compatible = "ep,ep-consumer";
		ep-syscon = <&ep_syscon>;
	};
};

Listing "syscon" as a compatible fallback is what lets syscon_regmap_lookup_by_phandle() find this exact node; listing "simple-mfd" is what tells the kernel to auto-register any children of this node without a custom core driver.

Original Coding Example: ep_syscon_demo

This consumer driver looks up the syscon regmap through the ep-syscon phandle property and reads one 32-bit register from it at probe time.

// ep_syscon_demo.c — original EmbeddedPathashala syscon consumer example
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
#include <linux/of.h>

#define EP_STATUS_REG_OFFSET   0x04

static int ep_syscon_probe(struct platform_device *pdev)
{
	struct device *dev = &pdev->dev;
	struct regmap *regmap;
	u32 val;
	int ret;

	regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "ep-syscon");
	if (IS_ERR(regmap)) {
		dev_err(dev, "failed to get syscon regmap: %ld\n",
			PTR_ERR(regmap));
		return PTR_ERR(regmap);
	}

	ret = regmap_read(regmap, EP_STATUS_REG_OFFSET, &val);
	if (ret) {
		dev_err(dev, "regmap_read failed: %d\n", ret);
		return ret;
	}

	dev_info(dev, "ep_syscon_demo: status register = 0x%08x\n", val);
	return 0;
}

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

static struct platform_driver ep_syscon_driver = {
	.driver = {
		.name           = "ep-syscon-demo",
		.of_match_table = ep_syscon_of_match,
	},
	.probe = ep_syscon_probe,
};
module_platform_driver(ep_syscon_driver);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("EmbeddedPathashala syscon regmap consumer example");

Build and Run Steps

obj-m += ep_syscon_demo.o
make -C /lib/modules/$(uname -r)/build M=$PWD modules

sudo insmod ep_syscon_demo.ko
dmesg | tail -3
sudo rmmod ep_syscon_demo

Expected dmesg Output

[  340.221100] ep_syscon_demo: status register = 0x00000000

On real hardware this value reflects whatever the actual system-controller register contains; on a QEMU or emulated platform without backing memory for that offset it commonly reads back as zero, which is still a successful demonstration of the lookup-and-read path.

simple-mfd vs a Custom Core Driver

Common Mistakes

Best Practices

Real-World Use Cases

Reset controllers, pin controllers, and clock drivers on many ARM SoCs read and write shared “system control” registers through exactly this syscon pattern rather than mapping the same physical memory twice from two separate drivers.

Summary / Key Takeaways

Conclusion

Across this three-lecture mini-series you moved from a full custom MFD core driver, through device tree binding, to the zero-conf syscon/simple-mfd shortcut — covering the complete spectrum of multi-function device support in the modern Linux kernel. This closes out the MFD subsystem chapter of the free linux kernel development course.

Frequently Asked Questions