Roflin
88d05988b5
Records why supporting both command-space forms is a single decoder rather than two paths, and where that abstraction genuinely stops. The unification: Swiss's "4-byte transfer" is not a second protocol. From the device's side it is the same 2-byte header followed by a data phase that happens to be 2 bytes (00, val) instead of 1 (val). Command space was the last place still assuming a fixed transfer length, which register space already avoids. Both rules are length-agnostic -- last data byte wins, fill the first two data slots -- so there is no driver detection, no mode flag, and with comments stripped the words "Swiss" and "libogc" do not appear in the RTL. The limit, which is real but inert: a 2-byte data phase means "pad + value" (Swiss) or "two consecutive registers" (libogc2), and those cannot be told apart on the wire. libogc2 does do multi-byte command writes -- bba_cmd_outs(0x04, &priv->devid, 2) runs unconditionally in its init -- so last byte wins is wrong for those and auto-increment is wrong for Swiss. It does not matter today because the only command registers implemented are 0x02 (IMR) and 0x03 (IR), which both drivers access one byte at a time, while libogc2's multi-byte accesses target 0x04/0x05 and 0x08/0x09, none of which are decoded. If 0x04/0x05 are ever implemented the fix is per-register width knowledge, not a driver mode -- noted so nobody resolves it by sniffing transfer length. Also records that the challenge/response handshake must NOT be implemented: libogc2 reads a 4-byte challenge from command reg 0x08 and writes the response to 0x09, but only when the DEVICE raises status bit 0x10 in command reg 0x03. It is device-initiated, we never set that bit, so the path cannot be entered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>