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

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

[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;
-- 
2.15.0

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

[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.

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

[Heiner Kallweit]

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.

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

[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?

Thanks,
Bartosz

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

[Heiner Kallweit]

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
> 

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

[Bartosz Golaszewski]

2017-11-27 20:46 GMT+01:00 Heiner Kallweit <hkallweit1@gmail.com>:
> 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;
> --
> 2.15.0
>

Applied to at24/fixes, thanks!