因为我要复习下linux驱动。实现一个小麻雀。
复习目标：
1.驱动框架
2.常用通过设备树获取信息的of函数
3.io模型（先用休眠唤醒的阻塞方式仅实现read）
4.添加锁，添加中断（暂不加timer软中断的按键滤波，无需下半部的thread）。
只有read+中断。那么需求互斥锁进行write同步了。只要原子锁即可。

一，驱动加载完，app运行正确

image.png

二，驱动卸载第二次加载后，显示加载错误，irq未分配中断号

image.png
解决方法：
步骤1：
先查看/proc/interrups加载和卸载是否正确。结果正确。
步骤2：
通过报错提示关键字在内核源码搜索到irq_of_parse_and_map函数报出的问题。
步骤3：
通过打印内核信息来查看原因
image.png
image.png
步骤4：
进行分析：原因是irq在加载一次后变成了both边沿触发。而我设备树中添加的type=1是上升沿触发。
为什么会变成both呢？
步骤5：
修改驱动bug，request_irq的第三个参数，我传入的是IRQF_TRIGGER_FALLING|IRQF_TRIGGER_RISING。所以both是我驱动中添加的，改成仅上升沿后。测试通过，多次反复加载卸载都正常。

三，思考

irq_of_parse_and_map的原理是当前实际的trigger和设备树的对比，然后分配中断号。我还以为直接从设备树获取呢？所以通过此代码我觉得设备树中我因为配置化为IRQ_TYPE_NONE。
另外一个问题，irq_free后怎么还有残留信息没有reset中断状态。导致再次加载读取当前type=3？暂时没有时间去分析源码。

四，小结

好吧，了解了这样的坑后，下次使用需要注意。设备树的中断方式要和irq请求配置信息一致。