The at24 eeproms are 2 byte devices that return 0xff when they are read from with a partial (1-byte) address written. This distinction was found comparing model behavior to real hardware testing.
Tested: `i2ctransfer -f -y 45 w1@85 0 r1` returns 0xff instead of next byte Signed-off-by: Patrick Venture <vent...@google.com> Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com> --- v2: Reordered the event switch to remove explicit branch and use fallthrough. --- hw/nvram/eeprom_at24c.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c index af6f5dbb99..b956b8e2b2 100644 --- a/hw/nvram/eeprom_at24c.c +++ b/hw/nvram/eeprom_at24c.c @@ -58,9 +58,10 @@ int at24c_eeprom_event(I2CSlave *s, enum i2c_event event) switch (event) { case I2C_START_SEND: - case I2C_START_RECV: case I2C_FINISH: ee->haveaddr = 0; + /* fallthrough */ + case I2C_START_RECV: DPRINTK("clear\n"); if (ee->blk && ee->changed) { int len = blk_pwrite(ee->blk, 0, ee->mem, ee->rsize, 0); @@ -84,6 +85,10 @@ uint8_t at24c_eeprom_recv(I2CSlave *s) EEPROMState *ee = AT24C_EE(s); uint8_t ret; + if (ee->haveaddr == 1) { + return 0xff; + } + ret = ee->mem[ee->cur]; ee->cur = (ee->cur + 1u) % ee->rsize; -- 2.34.1.307.g9b7440fafd-goog