Hi,
According to the read(2) manpage, 0 byte reads should return 0 without
blocking, but pp_read in ppdev.c doesn't (not on my hardware at least).
Worse, it blocks indefinately in the while loop, waiting for bytes_read
!= 0.
The reason I noticed is that our scanner driver is using 0 byte reads to
detect if libieee1284 will return ENOTIMPL on an ECP mode read.. and the
easiest way to do that was calling read() with length 0 on the fd
associated with the dev/parport device. It works on most peoples'
hardware, but not mine it seems... (I haven't fully investigated why it
ever works anywhere.. by the look of the while loop, it should never
return ever!)
I propose the following simple patch (against the current version of
ppdev.c in bkbits) to fix the problem, although it does expose other
problems on my hardware (the driver goes on to read the scanner ID
string fine, but error away after that).. these are the next thing on my
agenda..
Cheers,
- Matthew Duggan
http://canon-fb330p.sourceforge.net/
------------------------
--- ppdev.bkbits.c Sat Jun 29 16:43:29 2002
+++ ppdev.c Sat Jun 29 16:46:17 2002
@@ -118,6 +118,8 @@
return -EINVAL;
}
+ if (count == 0) return 0;
+
kbuffer = kmalloc(min_t(size_t, count, PP_BUFFER_SIZE),
GFP_KERNEL);
if (!kbuffer) {
return -ENOMEM;
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Sat Jun 29 2002 - 03:06:21 EDT