PR/60206 CVS commit: src/sys/arch/sgimips/mace

["Adrian Chadd" <adrian%netbsd.org@localhost>]

The following reply was made to PR port-sgimips/60206; it has been noted by GNATS.

From: "Adrian Chadd" <adrian%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/60206 CVS commit: src/sys/arch/sgimips/mace
Date: Tue, 28 Apr 2026 14:20:33 +0000

 Module Name:	src
 Committed By:	adrian
 Date:		Tue Apr 28 14:20:33 UTC 2026
 
 Modified Files:
 	src/sys/arch/sgimips/mace: macekbc.c
 
 Log Message:
 macekbc: fix byte transmit to properly inhibit clock line first
 
 The PS/2 "specification" requires the controller to inhibit
 the clock line for 100uS before trying to transmit.  This tells
 the device (in this case a bunch of ps/2 mice) to stop transmitting,
 get ready for receive and get ready to send the clock out to the
 controller to send said bits.
 
 The mice in question work fine on the O2 PROM, so it's not a
 hardware issue per se.
 
 After staring at traces with a logic analyser it looks like the
 controller is NOT doing this in hardware - it immediately attempts
 to transmit bytes and if the ps/2 device doesn't handle that,
 it will simply never send out clock pulses for the controller to
 clock the byte out.
 
 So:
 
 * Inhibit the clock line, disable tx/rx entirely
 * wait 100uS for the device to catch up
 * Program the byte to the TX hardware
 * Then re-enable TX/RX; the hardware will then attempt to transmit
   it out with the device supplied clock.
 
 This allows both my "already worked" Wyse PS/2 mice and my
 "didn't work" in NetBSD mice to now probe/detect correctly.
 
 This addresses PR port-sgimips/60206 .
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/sys/arch/sgimips/mace/macekbc.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.