Re: [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602

[Heiner Kallweit <hkallweit1@gmail.com>]

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@gmail.com>
>> ---
>> 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.