]> git.ipfire.org Git - thirdparty/qemu.git/commit
dp8393x: Store CAM registers as 16-bit
authorPhilippe Mathieu-Daudé <f4bug@amsat.org>
Sat, 3 Jul 2021 13:42:51 +0000 (15:42 +0200)
committerPhilippe Mathieu-Daudé <f4bug@amsat.org>
Sun, 11 Jul 2021 20:29:54 +0000 (22:29 +0200)
commit8ac2ffb584590b0398ae4e1a08a0b5d209b6f250
tree5d3143c39953c0e04ec16e12c7bcc517a46933ff
parent67b38ddfe58cbfb7c9c4a8d8b7efdc3fe7def41f
dp8393x: Store CAM registers as 16-bit

Per the DP83932C datasheet from July 1995:

  4.0 SONIC Registers
  4.1 THE CAM UNIT

    The Content Addressable Memory (CAM) consists of sixteen
    48-bit entries for complete address filtering of network
    packets. Each entry corresponds to a 48-bit destination
    address that is user programmable and can contain any
    combination of Multicast or Physical addresses. Each entry
    is partitioned into three 16-bit CAM cells accessible
    through CAM Address Ports (CAP 2, CAP 1 and CAP 0) with
    CAP0 corresponding to the least significant 16 bits of
    the Destination Address and CAP2 corresponding to the
    most significant bits.

Store the CAM registers as 16-bit as it simplifies the code.

Having now the CAM registers as arrays of 3 uint16_t, we can avoid
using the VMSTATE_BUFFER_UNSAFE macro by using VMSTATE_UINT16_2DARRAY
which is more appropriate. This breaks the migration stream however.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Tested-by: Finn Thain <fthain@linux-m68k.org>
Message-Id: <20210710174954.2577195-5-f4bug@amsat.org>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
hw/net/dp8393x.c