Re: PLIP transmit timeouts -- any solutions?

In message <1060557141.755.29.camel_at_prophecy.velum>, Christopher Nehren writes:
>
>--=-7MVWKH2AJ0lqXf3q30++
>Content-Type: text/plain
>Content-Transfer-Encoding: quoted-printable
>
>I currently have a PLIP link to an old laptop running Linux (I tried to
>install FreeBSD, but it freezes at the USB detection -- yes, I tried

Try the following patch. I can't remember if all the changes in
this are necessary, but I think I found it fixed problems when
interoperating with a Linux-like PLIP implementation.

If I remember correctly, the PLIP implementation I saw used the
data bits that came in the very first read that had the correct
handshake signal, whereas FreeBSD readers do one extra read after
the handshake to ensure that the signal is stable (i.e. that
implementation used an "unsafe" read and a "safe" write, whereas
FreeBSD's uses a "safe" read and an "unsafe" write). This patch
causes both read and write to be "safe". The removal of the use of
ctxmitl[] seems to be unnecessary.

Ian

Index: if_plip.c
===================================================================
RCS file: /dump/FreeBSD-CVS/src/sys/dev/ppbus/if_plip.c,v
retrieving revision 1.28
diff -u -r1.28 if_plip.c
--- if_plip.c	4 Mar 2003 23:19:54 -0000	1.28
+++ if_plip.c	12 Mar 2003 07:09:43 -0000
_at__at_ -409,12 +409,14 _at__at_
 static __inline int
 clpoutbyte (u_char byte, int spin, device_t ppbus)
 {
-	ppb_wdtr(ppbus, ctxmitl[byte]);
+	ppb_wdtr(ppbus, byte & 0xf);
+	ppb_wdtr(ppbus, (byte & 0xf) | 0x10);
 	while (ppb_rstr(ppbus) & CLPIP_SHAKE)
 		if (--spin == 0) {
 			return 1;
 		}
-	ppb_wdtr(ppbus, ctxmith[byte]);
+	ppb_wdtr(ppbus, ((byte & 0xf0) >> 4) | 0x10);
+	ppb_wdtr(ppbus, ((byte & 0xf0) >> 4));
 	while (!(ppb_rstr(ppbus) & CLPIP_SHAKE))
 		if (--spin == 0) {
 			return 1;