嵌入式Linux驱动中使用printk引发I2C相关内核错误问题求解

核心原因 #

printk本身虽支持在任意内核上下文调用，但会引入不可控的执行延时，这是触发故障的根本原因：

• 你调用printk的驱动read函数，和I2C总线的触控传输流程存在时序依赖，cdns I2C控制器的传输超时阈值极短，printk向console写入日志的操作会将当前线程挂起等待IO完成，这个延时完全足够导致I2C触控传输超时，对应日志里的cdns-i2c e0005000.i2c: timeout waiting on completion报错。
• I2C超时后edt_ft5426驱动的错误处理逻辑未妥善清理中断状态，导致后续中断线程退出时访问了已经被释放的空指针，最终触发irq_finalize_oneshot里的NULL指针解引用panic。

为什么注释printk就正常 #

去掉printk后没有了额外的console写入延时，I2C传输可以在超时阈值内完成，中断状态流转正常，不会触发错误处理分支的逻辑漏洞。

修复方案 #

• 调试阶段如果需要保留日志，将printk的日志级别设置为非console输出级别，让日志只写入内核缓冲区，不实时输出到串口/屏幕，避免引入实时IO延时：

  // 示例，使用KERN_DEBUG级别，默认console日志级别为4，不会实时打印
  printk(KERN_DEBUG "dma_desc_p[MIC_DMA].ready = %d\n", value);
  

  后续可以通过dmesg命令读取缓冲区里的调试日志。
• 不要在持有总线锁、中断处理函数、时序敏感的临界区内调用任何可能引入延时或者主动调度的函数，包括printk。
• 如果read函数运行在触控中断的线程上下文内，需要严格控制函数执行耗时，避免阻塞中断处理流程。

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