Am 27.11.2017 um 20:59 schrieb Heiner Kallweit: > Am 27.11.2017 um 20:46 schrieb Heiner Kallweit: >> Chip datasheet mentions that word addresses other than the actual >> start position of the MAC delivers undefined results. So fix this. >> Current implementation doesn't work due to this wrong offset. >> >> Fixes: 0b813658c115 "eeprom: at24: add support for at24mac series" >> Signed-off-by: Heiner Kallweit <hkallweit1@xxxxxxxxx> >> --- >> v2: >> - extended commit message >> --- >> drivers/misc/eeprom/at24.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c >> index e0b4b36ef..00d602be7 100644 >> --- a/drivers/misc/eeprom/at24.c >> +++ b/drivers/misc/eeprom/at24.c >> @@ -425,7 +425,8 @@ static ssize_t at24_eeprom_read_mac(struct at24_data *at24, char *buf, >> memset(msg, 0, sizeof(msg)); >> msg[0].addr = client->addr; >> msg[0].buf = addrbuf; >> - addrbuf[0] = 0x90 + offset; >> + /* EUI-48 starts from 0x9a, EUI-64 from 0x98 */ >> + addrbuf[0] = 0xa0 - at24->chip.byte_len + offset; >> msg[0].len = 1; >> msg[1].addr = client->addr; >> msg[1].flags = I2C_M_RD; >> > Are you going to apply this patch also before my other patch series? > Then I will consider this too when re-basing. > To answer my own question: As long as we don't have a good enough patch to fix byte_len for 24mac402 this patch doesn't make sense. Then, what we could do: For stable, create a patch based on the current code. For next, we could replace the magic values with a proper struct already.
