【安卓驱动重启问题记录】

问题场景：

reboot 测试10000次，15台机器意外进入recovery mode，异常概率：1/8000

问题分析

Step1:对比正常关机log

Step2:正常的开机下pdn1标记位会被清除

Step3:清除标记位后，就可以正常加载bootlogo
Step4:对比异常关机log

Step5:发现pdn1标志没有被清掉

Step6: 异常log，加载的是recover.img，进入了recovery

重启后，可以从mtklogger缓冲区看到异常
1.串口记录不了异常时场景
2.Last_1_boot_normal是MTKLOGGER APK 重启后从缓冲区抓取异常现场
3.发现有大量GPIO78警报
4.GPIO78 是USB VBUS enable pin ，如下

出现潜在并发源：

1.drivers/extcon/mediatek/usb-iddig.c 中断调用

2.drivers/extcon/mediatek/usb-tcpc.c 中断回调

3.drivers/extcon/mediatek/usb-iddig.c 独立线程

资源调用链则是mt_vbus_on -> usb_otg_set_bus ->pinctrl_select_state -> Pinctrl_commit_state -> list_for_each_entry

list_for_each_entry(setting, &p->state->settings, node) 语句中，该宏的功能是：

遍历 p->state->settings 链表的每一个节点。
将每个节点对应的容器结构体（即 pinctrl_setting）指针赋值给变量 setting。
通过 setting->node 获取链表节点的位置信息，完成整个链表的遍历

解决方案：

在临界区加锁，即访问共享资源的代码段，某一时刻只能单一执行线程或者中断持有，确保临界区原子执行，不可分割
原来的

改后：

一些收获吧：用锁来保护共享资源顺理成章

但是辨认出真正需要共享的数据和相应的临界区，才是真正有挑战性的地方。

最开始设计代码的时候就要考虑加入锁，而不是异常时才想到。如果代码已经写好了，再在其中找到需要上锁的部分并向其中追加锁，是非常困难的。因此，在编写内核代码的开始阶段就要发现潜在的并发源，并设计恰当的锁。