Am 27.11.2017 um 22:10 schrieb Bartosz Golaszewski: > 2017-11-27 21:07 GMT+01:00 Heiner Kallweit <hkallweit1@xxxxxxxxx>: >> 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. >> >> >> > > 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 >
