关于应用程序打开驱动的read直接返回0的有关问题

关于应用程序打开驱动的read直接返回0的问题
最近学习友善的minis3c2440，写了一个串口的字符设备驱动，串口0已经被用于与PC交互了，我写的驱动是串口1的，
1、在驱动函数的read里，我是这样处理的,直接进入睡眠，只有在串口收到数据的时候我才会去唤醒
static serial_read()
{
   wait_event_interruptible(read_waitq,read_wakeup);
   ...
   do something
   ...
}
2、在应用程序中，我先open 获得句柄，属性是 O_RDWR 可读可写 ，接下来我使用read(f_handle,buf,count)
while(run_read)
{
  ret = read(f_handle,buf,count);
  ...
  do something
} 
 但有时候read会直接返回0，但这时候串口的 RX 是为高电平的，而且我在驱动程序的read里使用printk打印信息，发现应用程序的read 根本就没有调用驱动程序里的read
 


这样的情况不是一直出现的，有时候串口就是好的，各方面通信都很正常，但一旦出现应用程序里的read返回0的情况，就会一直返回0 
一直想不明白，求解啊！！
------解决方案--------------------
在应用层添加如下代码
options.c_iflag &= ~(BRKINT 
------解决方案--------------------
 ICRNL 
------解决方案--------------------
 INPCK 
------解决方案--------------------
 ISTRIP 
------解决方案--------------------
 IXON);
 options.c_oflag &= ~OPOST;

 options.c_cflag 
------解决方案--------------------
= CLOCAL 
------解决方案--------------------
 CREAD;

 options.c_lflag &= ~(ICANON 
------解决方案--------------------
 ECHO 
------解决方案--------------------
 ECHOE 
------解决方案--------------------
 ISIG);


------解决方案--------------------
wait_event_interruptible(read_waitq,read_wakeup);这句话有出错处理吗？
如果没有出错处理，可能在串口没有数据的时候，去读串口fifo，设计不好的硬件和驱动会导致fifo的underflow错误，只有复位硬件才能恢复了。
------解决方案--------------------

引用:

Quote: 引用:

既然是你自己写的驱动，返回什么是你自己控制的啊。

这个当然了啊。。关键是应用程序的read他直接返回0,完全没有调用驱动程序中read的感觉，因为我在驱动程序的read中（在wait_event_interruptible前面加了 printk ），做了这样的测试，发现printk没有被执行到!!

没有走到你的read接口，应该是应用打开的设备句柄已经不可用了，即设备句柄与设备对应出错了。此时close都不起作用了。试试能否在kernel强制close 该设备，然后再open试试。