wireguard-openbsd/sys/arch/sgi/dev/iockbc.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/sgi/dev/iockbc.c?h=jd%2Fqueueboosts 2019-10-17T13:42:15Z sgi: iockbc(4), mkbc(4): tsleep(9) -> tsleep_nsec(9); ok kn@ visa@ 2019-10-17T13:42:15Z cheloha cheloha@openbsd.org 2019-10-17T13:42:15Z urn:sha1:0ebfbcdd6d9c90e3bd0a12f258a79748ad092b98 no md code wants lockmgr locks, so no md code needs to include sys/lock.h 2015-02-11T07:05:39Z dlg dlg@openbsd.org 2015-02-11T07:05:39Z urn:sha1:d3b1d173f07835f2d78b379d23a5946ce16b055a with and ok miod@ Force clock clamping after one byte received instead of three. There are still 2013-12-29T18:31:50Z miod miod@openbsd.org 2013-12-29T18:31:50Z urn:sha1:6008bd34eb30582a763ba9dc745d3317ce8c6871 circumstances where the pckbc code gets confused otherwise, on *some* controllers. Instead of deciding which iockbc port is the keyboard port, and which one is the 2013-12-25T21:01:01Z miod miod@openbsd.org 2013-12-25T21:01:01Z urn:sha1:07eb5baf9161566c9a1a82efdaa97df238f53a8f mouse port, depending upon the system time, match what the prom is doing and actually probe for a keyboard on both ports, and decide the first port with a keyboard is the keyboard port. If no keyboard is found, but a mouse is found, decide the keyboard port is the empty one. If no device is found, then we can try and pick the defaults, depending upon the system we are running on, as this used to be the case (i.e. coping with Fuel having keyboard on port 1 and mouse on port 0 when connecting devices according to the chassis' markings). This is necessary because different IO9 board revisions on Tezro come with different wirings, and we can not tell these boards apart. Discussed with "nullnilaki" (nullnilaki on gmail) who is the lucky owner of an Onyx 350 with correct wiring and a Tezro with inverted wiring. Tested on Octane and Fuel with all combinations of devices connected (mouse only, keyboard only, keyboard and mouse) in both ports, glass and serial console. XXX We probably want to allow for more pckbd attachment flexibility on non-x86 XXX platforms eventually (at least where the PS/2 slots are really independent, XXX so that we can attach pckbd to any port and better cope with human error XXX when connecting devices. simplify pckbc_xt_translation() 2012-08-10T17:49:31Z shadchin shadchin@openbsd.org 2012-08-10T17:49:31Z urn:sha1:f73481ae70de41e70420d20264fed20af059e1a7 * call only for set translation on (once in /sys/dev/pckbd.c) therefore we can delete unused code. * change behavior (more standard) - return zero on success ok miod@ removed slot argument of function pckbd_cnattach 2010-12-03T18:29:56Z shadchin shadchin@openbsd.org 2010-12-03T18:29:56Z urn:sha1:6b1675bfbd934bb295e913c1b499a101e9211645 because it is always PCKBC_KBD_SLOT ok miod@, krw@ Obtain struct sgi_device_location for the console input and output devices, 2010-04-06T19:12:26Z miod miod@openbsd.org 2010-04-06T19:12:26Z urn:sha1:206288b28ca300a95af5ae130f15c654b2b70b72 and compare against them when attaching potential console drivers, to figure out whether they indeed are acting are console devices or not. Allow iockbc(4) and odysseey(4) to act as console devices and attach early; 2010-03-07T13:44:24Z miod miod@openbsd.org 2010-03-07T13:44:24Z urn:sha1:29c3a013491fb0d60606425c060d8ee29b1593cc this gives us working glass console on Fuel, as well as on Octane systems with Odyssey graphics. Joint work with jsing@ Add glue to attach iockbc(4) to iof(4) as well. Tested by deraadt@ 2009-11-18T19:03:21Z miod miod@openbsd.org 2009-11-18T19:03:21Z urn:sha1:d78605772a7a86e2e9ec13a65105e000f51a0794 Let ioc(4) pass the information whether it is an onboard device or not, to its 2009-11-11T15:56:41Z miod miod@openbsd.org 2009-11-11T15:56:41Z urn:sha1:0598e3ad4c1a4ce3024056fffb831a068f9337bb subdevices; use this on iockbc to only perform the fuel workaround on the onboard ioc.