* [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602
@ 2017-11-27 19:46 Heiner Kallweit
2017-11-27 19:59 ` Heiner Kallweit
2017-11-29 14:57 ` Bartosz Golaszewski
0 siblings, 2 replies; 6+ messages in thread
From: Heiner Kallweit @ 2017-11-27 19:46 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-i2c
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602
2017-11-27 19:46 [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602 Heiner Kallweit
@ 2017-11-27 19:59 ` Heiner Kallweit
2017-11-27 20:07 ` Heiner Kallweit
2017-11-29 14:57 ` Bartosz Golaszewski
1 sibling, 1 reply; 6+ messages in thread
From: Heiner Kallweit @ 2017-11-27 19:59 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-i2c
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602
2017-11-27 19:59 ` Heiner Kallweit
@ 2017-11-27 20:07 ` Heiner Kallweit
2017-11-27 21:10 ` Bartosz Golaszewski
0 siblings, 1 reply; 6+ messages in thread
From: Heiner Kallweit @ 2017-11-27 20:07 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-i2c
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602
2017-11-27 20:07 ` Heiner Kallweit
@ 2017-11-27 21:10 ` Bartosz Golaszewski
2017-11-27 21:47 ` Heiner Kallweit
0 siblings, 1 reply; 6+ messages in thread
From: Bartosz Golaszewski @ 2017-11-27 21:10 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: linux-i2c
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602
2017-11-27 21:10 ` Bartosz Golaszewski
@ 2017-11-27 21:47 ` Heiner Kallweit
0 siblings, 0 replies; 6+ messages in thread
From: Heiner Kallweit @ 2017-11-27 21:47 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-i2c
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602
2017-11-27 19:46 [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602 Heiner Kallweit
2017-11-27 19:59 ` Heiner Kallweit
@ 2017-11-29 14:57 ` Bartosz Golaszewski
1 sibling, 0 replies; 6+ messages in thread
From: Bartosz Golaszewski @ 2017-11-29 14:57 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: linux-i2c
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!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-29 14:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-27 19:46 [PATCH v2] eeprom: at24: fix reading from 24MAC402/24MAC602 Heiner Kallweit
2017-11-27 19:59 ` Heiner Kallweit
2017-11-27 20:07 ` Heiner Kallweit
2017-11-27 21:10 ` Bartosz Golaszewski
2017-11-27 21:47 ` Heiner Kallweit
2017-11-29 14:57 ` Bartosz Golaszewski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.