多功能PMU设备的Linux MFD驱动架构合理性及优化问询

我有一款定制化/复杂的电源管理单元（PMU），它以带16位寄存器的I2C从设备形式对外提供功能，并具备中断输出信号。该PMU还拥有GPIO功能，中断用于通知Linux内核（I2C主设备）因GPIO输入状态变化而读取寄存器。

目前我将可正常运行的驱动结构划分为：

./include/linux/mfd/mypmu.h
./drivers/gpio/gpio-mypmu.c
./drivers/mfd/mypmu-core.c
./drivers/mfd/mypmu-regmap.c
./drivers/mfd/mypmu-i2c.c

三个文件中分别调用MODULE_DESCRIPTION宏：

./drivers/gpio/gpio-mypmu.c:MODULE_DESCRIPTION("GPIO interface for MYPMU");
./drivers/mfd/mypmu-core.c:MODULE_DESCRIPTION("MYMU device");
./drivers/mfd/mypmu-i2c.c:MODULE_DESCRIPTION("MYPMU_I2C");

拆分三个独立模块的原因是根据所属内核子系统采用不同的注册方式：

./drivers/gpio/gpio-mypmu.c:platform_driver_register(&mypmu_gpio_driver);
./drivers/mfd/mypmu-core.c:platform_set_drvdata(*pdev, mypmu);
./drivers/mfd/mypmu-i2c.c:i2c_add_driver(&mypmu_i2c_driver);

这主要是模仿其他单功能驱动代码的“盲目照搬”做法。现提出以下问题：

1. 为一个设备驱动使用三个模块是否符合常规？是否存在可在多个Linux子系统（如GPIO和I2C）中注册单个驱动的方法？
2. 驱动能否不位于drivers/gpio目录下却出现在/sys/class/gpio中？
3. 是否有更优的MFD驱动结构方案？

问题解答 #

1. 多模块驱动是否符合常规及单模块跨子系统注册的可行性 #

用三个模块实现一款PMU驱动是符合Linux内核驱动规范的，尤其是对于MFD（多功能设备）来说，拆分核心功能、总线适配、子功能驱动是标准做法。MFD框架的核心思路就是把多功能设备拆分成独立的子驱动，各自对应内核的不同子系统（比如GPIO、电源管理等），这样既符合内核子系统的分工，也便于维护和扩展。

至于单模块跨多个子系统注册：技术上可以实现——你可以在一个内核模块里同时调用i2c_add_driver和platform_driver_register，甚至注册GPIO子系统相关接口。但这种做法不推荐，因为会打破内核子系统的模块化分工，导致驱动耦合度高，后续维护、调试和扩展都会变得困难，也不符合内核驱动的编码惯例。

2. 驱动目录位置与/sys/class/gpio的关系 #

完全可以。驱动文件的存放目录是内核源码的组织规范，而/sys/class/gpio是sysfs中GPIO类的统一入口，只要你的驱动正确调用了GPIO子系统的注册接口（比如gpiochip_add），不管驱动源码放在哪个目录下，对应的GPIO控制器都会出现在/sys/class/gpio中。

比如很多MFD设备的GPIO子驱动会放在drivers/mfd目录下，只要正确实现GPIO chip的注册逻辑，一样会在sysfs中生成对应的GPIO节点。

3. 更优的MFD驱动结构方案 #

当前的结构已经比较接近标准MFD驱动的架构，但可以做以下优化：

• 合并核心与总线适配逻辑：可以把mypmu-i2c.c和mypmu-core.c的部分逻辑合并，让I2C驱动作为MFD的总线适配层，负责探测设备、初始化regmap，然后注册MFD核心设备，再由MFD框架枚举子设备（比如GPIO子设备）。
• 利用MFD框架的子设备注册机制：不要手动注册GPIO平台驱动，而是在MFD核心初始化时，通过mfd_add_devices函数注册GPIO子设备，让GPIO子驱动通过平台总线匹配的方式被加载。这种方式更符合MFD框架的设计，能更好地管理设备的生命周期。
• 统一regmap管理：确保mypmu-regmap.c中的regmap配置被核心层统一管理，所有子驱动通过核心层提供的接口访问寄存器，避免直接操作I2C总线，提升代码的安全性和可维护性。

标准的MFD驱动结构通常是：

1. 总线适配层（如mypmu-i2c.c）：负责与I2C总线交互，探测设备，初始化硬件，创建regmap实例。
2. 核心层（如mypmu-core.c）：负责管理设备的全局状态，提供寄存器访问接口，通过MFD框架注册子设备（GPIO、电源管理等）。
3. 子功能驱动（如gpio-mypmu.c）：通过平台总线匹配MFD核心注册的子设备，实现对应子系统的功能（如GPIO控制器逻辑）。

内容的提问来源于stack exchange，提问作者fadedbee