> So far the immediate fix. (If it is applied then a corresponding
> comment should be added to the 2.2.8 lp.h so that nobody will take
> 0x0610 later.)
Yes. Changing LPSTRICT's ioctl number looks to be the right thing to do.
> The first question is: this 2.0.35 behaviour - is it strictly according
> to the specs? Not according to my notes, which say:
There are all different ways of doing this. The six common variations
are:
busy-while-strobe and ack-in-busy
busy-after-strobe ack-after-busy
ack-while-busy
The 'correct' variation according to IEEE is 'busy-while-strobe and
ack-in-busy'. The Centronics standard, on the other hand, is
'busy-after-strobe and ack-after-busy'. It's a can of worms.
Plus, no implementation should really care about this sort of thing,
because it should be handshaking with ack rather than busy. It's on my
to-do list, and the Linux implementation can potentially lose data with
very slow hardware. ISTR some parallel port chipsets do the same thing
though.
> In the 2.0.36 code I do not see any waiting for a definite period
> of time - just strange loops like
> wait = 1000;
> while(wait) wait--;
> with an execution time very much dependent on processor and alignment.
This isn't wrong as such: the wait time is defined to be in processor
cycles. The bug is that wait isn't volatile (is that still true in
2.0.37pre?), although I don't think it actually causes any problems yet.
Tim.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/