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

[Heiner Kallweit <hkallweit1@gmail.com>]

Am 27.11.2017 um 22:10 schrieb Bartosz Golaszewski:
> 2017-11-27 21:07 GMT+01:00 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.
>>
>>
>>
> 
> I'd like to merge this patch, then a fix for at24mac402 size (please
> take a look at my new attempt, this time I manually adjust the value
> in probe()), then your sanitization patch and then the regmap series.
> The fixes will go to the fixes branch and I'll ask Wolfram to pull
> them soon. The rest together with said fixes will go to the devel
> branch and we'll go from there with updates for 4.16.
> 
> Does that sound ok?
> 
Sounds good. Then I will rebase again based on your patch and send a
updated version of the regmap series tomorrow.

> Thanks,
> Bartosz
>