记一次不愉快的bug修复

问题是这样的

带spi master的cpu，外接了3个slave，fpga，dpll，flash

访问3个外设，内核里是靠锁来实现互斥的，而加锁解锁是在用户空间通过ioctl来实现

比如我要访问fpga

open(/dev/spi)

ioctl(OPER_FPGA) //mutex_spi lock

read/write

ioctl(OPER_FPGA_DONE) //mutex_spi unlock

访问dpll

open(/dev/spi)

ioctl(OPER_DPLL) //mutex_spi lock

read/write

ioctl(OPER_DPLL_DONE) //mutex_spi unlock

我承认，这种方式很烂，但前人做成这样，上层的app一直这样用。（我已经在打算将锁移到read/write里面，通过传人read/write的buff来区分上锁）

这样如果在read/write的过程中，Ctrl+C会使进程进入disksleep，死锁在那

那么bug来了，躲不过的

忽然有一天，有人说，写flash失败，而且感觉就像死在那

通过验证，只起kernel，不起app，没有问题，一旦app起来了，写flash一定会失败

关于锁啊，spi这块我已经很熟了，而且用了许久没问题，怎么就忽然出现这个问题呢

有人发话，一定是内核中spi资源冲突的问题，你去查吧

好，那就查吧，虽然对这一块有信心，但我也不能保证不是内核的问题

然后开始研究flash时序，追踪写flash的过程，结果是flash写进一部分后，再也读不出，写不进

懵了...有锁锁着，不应该有冲突，想到一点，flash的片选是通过gpio来选的，难道有人改了gpio？

然而并没有...(打印出问题时gpio的value)

内核这块走不通，我便开始扣app，一个进程一个进程的起，终于定位到一个叫emd.exe的进程

但了解到这个进程就是设备管理，会不断访问fpga，难道真是资源冲突？我不信，看这个进程访问fpga时的代码

尼玛...

open(/dev/spi)

ioctl(OPER_FPGA_DONE) //mutex_spi unlock

ioctl(OPER_FPGA) //mutex_spi lock

read/write

ioctl(OPER_FPGA_DONE) //mutex_spi unlock

ioctl(OPER_FPGA_DONE) //mutex_spi unlock

close

有人为了调试方便（会经常用到Ctrl+C），减少进程进入disksleep的概率，来了这一出

找到罪魁祸首，就是把问题推给内核的人，唉，有没有考虑过做内核的感受啊

你这样改，我还要锁干啥，干啥，啊？！