针对你不想修改驱动源代码的需求，这里整理了几个更落地的方案，帮你完成测试：

1. User Mode Linux (UML) + 伪终端模拟硬件 #

User Mode Linux是运行在用户空间的完整Linux内核实例，完全能满足驱动测试需求：

• 先编译支持UML的内核，确保开启CONFIG_SERIAL_DIGICOLOR和CONFIG_UML相关配置项
• 启动UML时，通过命令行参数把虚拟的digicolor-usart设备映射到主机的伪终端（PTY）
• 主机端用minicom或screen连接对应的PTY设备，就能直接和UML内的digicolor-usart驱动进行收发数据测试
• 这个方案完全不需要修改驱动代码，只需要配置内核启动参数和主机端工具即可

2. 内核虚拟平台设备 + Debugfs/Sysfs寄存器模拟 #

借助Linux的平台设备框架，注册一个虚拟的digicolor-usart设备，用debugfs/sysfs模拟寄存器交互：

• 编写一个几十行的小型内核辅助模块，初始化时调用platform_device_register()注册一个符合digicolor-usart设备属性的虚拟设备
• 在辅助模块里把寄存器的读写操作映射到debugfs的文件节点
• 加载目标驱动后，驱动会自动绑定到这个虚拟设备，你可以通过读写debugfs文件来模拟硬件寄存器的状态变化，测试驱动的各类逻辑
• 全程无需修改digicolor-usart.c的代码

3. 轻量扩展QEMU设备模型 #

虽然QEMU原生不支持digicolor-usart，但编写极简的自定义设备模型工作量其实很小：

• 参考QEMU现有串口设备（比如pl011）的代码，编写一个简化版的digicolor-usart模型，只实现核心的寄存器读写、数据收发逻辑，把数据转发到主机的PTY或串口
• 把这个模型编译为QEMU模块，启动QEMU时加载该模块并指定虚拟设备地址
• 这个方案一次开发后可重复使用，比修改驱动代码模拟寄存器更具长期价值

4. KUnit单元测试（最小化代码修改） #

如果能接受极少量的非侵入式修改，KUnit是内核官方的单元测试框架：

• 仅在digicolor-usart.c中为核心函数（比如digicolor_usart_probe、digicolor_usart_put_char）添加KUnit测试用例，用模拟的struct uart_port结构体替代真实硬件
• 编译内核时开启CONFIG_KUNIT，运行测试用例即可验证驱动逻辑的正确性
• 这类修改非常局限，不会影响驱动的正常功能，测试用例还能作为代码的一部分长期维护

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