# DF-4556 trigger (hardware recipe)

The bug fires when a native/I2C-over-AUX **read** of >16 bytes receives an
ACK carrying fewer data bytes than requested (short read). The DP 1.2a spec
allows a sink to do this.

Force it on a machine with an AMD GPU (amdgpu DC) + DisplayPort:

1. Use a programmable DP sink (or an FPD-Link/USB-C DP alt-mode test
   dongle with controllable firmware, e.g. an aux emulator built on an
   FT232H + DP plug, or a "bad DP sink" board).
2. Answer every 16-byte EDID-segment / DPCD read with: status=ACK,
   8 data bytes, then let the master retry the remainder.
3. Observe on the host:

       dmesg | grep -i aux

   and read back the assembled EDID/DPCD: the first 8 bytes will be the
   *second* chunk, bytes 8..15 zeroed — while the driver reports the read
   as SUCCEEDED.

Minimal aux emulator answer bytes for a short read (native AUX reply
header 0x00 = ACK-with-8-bytes is `0x0` nibble + count 9 total bytes on
the wire: 1 header + 8 data). The kernel path exercised:

    read_command()                 dce_aux.c:542
      -> process_read_request()    dce_aux.c:480
      -> process_read_reply()      dce_aux.c:417  (offset += 8, len -= 8)
      -> [2nd chunk ACKed 8 bytes]
      -> read_channel_reply()      dce_aux.c:250  (copies to buffer[0..7])
      -> returned buffer = [chunk2 | zeros]

The audit guest has no AMD GPU (Bochs VGA 0x1234:0x1111 — env.txt), so this
recipe could not be executed there; the defect is proven from source.