* Questions rgd. patch "eeprom: at24: support eeproms that do not auto-rollover reads"
@ 2017-12-08 19:33 Heiner Kallweit
2017-12-08 20:09 ` Sven Van Asbroeck
0 siblings, 1 reply; 4+ messages in thread
From: Heiner Kallweit @ 2017-12-08 19:33 UTC (permalink / raw)
To: Sven Van Asbroeck, Bartosz Golaszewski; +Cc: linux-i2c
Sorry, I saw this patch only now and there my questions / remarks come
quite late. The intention of the change is clear, just the following:
In at24_adjust_read_count() there is the line
remainder = BIT(bits) - offset;
AFAICS we can have the case offset > BIT(bits). Imagine a 8 bit chip
with size 512 (2 addresses) and we try to read a few bytes from
offset 300. Then the line in question doesn't do what it's supposed
to do.
And a more general aspect: If the size is 512 but only 256 byte are
accessible then I doubt it's nice to create a nvmem provider with
size 512. Wouldn't it be better to adjust byte_len to reflect the
accessible size? Then we also wouldn't need the check in
at24_adjust_read_count.
Rgds, Heiner
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Questions rgd. patch "eeprom: at24: support eeproms that do not auto-rollover reads"
2017-12-08 19:33 Questions rgd. patch "eeprom: at24: support eeproms that do not auto-rollover reads" Heiner Kallweit
@ 2017-12-08 20:09 ` Sven Van Asbroeck
2017-12-08 22:19 ` Heiner Kallweit
0 siblings, 1 reply; 4+ messages in thread
From: Sven Van Asbroeck @ 2017-12-08 20:09 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Sven Van Asbroeck, Bartosz Golaszewski, linux-i2c
On Fri, Dec 8, 2017 at 2:33 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> In at24_adjust_read_count() there is the line
> remainder = BIT(bits) - offset;
>
> AFAICS we can have the case offset > BIT(bits). Imagine a 8 bit chip
> with size 512 (2 addresses) and we try to read a few bytes from
> offset 300. Then the line in question doesn't do what it's supposed
> to do.
I don't think offset can be > BIT(bits). In at24_regmap_read(), we have:
at24_client = at24_translate_offset(at24, &offset);
regmap = at24_client->regmap;
client = at24_client->client;
count = at24_adjust_read_count(at24, offset, count);
at24_translate_offset() will translate the general offset to an offset
within a subchip. E.g. offset 300 will be translated to offset 44
into the second subchip.
> And a more general aspect: If the size is 512 but only 256 byte are
> accessible then I doubt it's nice to create a nvmem provider with
> size 512. Wouldn't it be better to adjust byte_len to reflect the
> accessible size? Then we also wouldn't need the check in
> at24_adjust_read_count.
I'm not sure if I understand. Could you clarify a bit Heiner?
If the size is 512 and it's a multi-address chip with 8-bit
addresses, we simply have two 256-byte subchips.
The size is 512. All 512 bytes are accessible.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Questions rgd. patch "eeprom: at24: support eeproms that do not auto-rollover reads"
2017-12-08 20:09 ` Sven Van Asbroeck
@ 2017-12-08 22:19 ` Heiner Kallweit
2017-12-08 22:25 ` Sven Van Asbroeck
0 siblings, 1 reply; 4+ messages in thread
From: Heiner Kallweit @ 2017-12-08 22:19 UTC (permalink / raw)
To: Sven Van Asbroeck; +Cc: Sven Van Asbroeck, Bartosz Golaszewski, linux-i2c
Am 08.12.2017 um 21:09 schrieb Sven Van Asbroeck:
> On Fri, Dec 8, 2017 at 2:33 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> In at24_adjust_read_count() there is the line
>> remainder = BIT(bits) - offset;
>>
>> AFAICS we can have the case offset > BIT(bits). Imagine a 8 bit chip
>> with size 512 (2 addresses) and we try to read a few bytes from
>> offset 300. Then the line in question doesn't do what it's supposed
>> to do.
>
> I don't think offset can be > BIT(bits). In at24_regmap_read(), we have:
>
> at24_client = at24_translate_offset(at24, &offset);
> regmap = at24_client->regmap;
> client = at24_client->client;
> count = at24_adjust_read_count(at24, offset, count);
>
> at24_translate_offset() will translate the general offset to an offset
> within a subchip. E.g. offset 300 will be translated to offset 44
> into the second subchip.
>
Ahh, I see that I misunderstood the issue being addressed by this change.
Forget about my comments and sorry for the noise.
>> And a more general aspect: If the size is 512 but only 256 byte are
>> accessible then I doubt it's nice to create a nvmem provider with
>> size 512. Wouldn't it be better to adjust byte_len to reflect the
>> accessible size? Then we also wouldn't need the check in
>> at24_adjust_read_count.
>
> I'm not sure if I understand. Could you clarify a bit Heiner?
> If the size is 512 and it's a multi-address chip with 8-bit
> addresses, we simply have two 256-byte subchips.
> The size is 512. All 512 bytes are accessible.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Questions rgd. patch "eeprom: at24: support eeproms that do not auto-rollover reads"
2017-12-08 22:19 ` Heiner Kallweit
@ 2017-12-08 22:25 ` Sven Van Asbroeck
0 siblings, 0 replies; 4+ messages in thread
From: Sven Van Asbroeck @ 2017-12-08 22:25 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Sven Van Asbroeck, Bartosz Golaszewski, linux-i2c
On Fri, Dec 8, 2017 at 5:19 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> Ahh, I see that I misunderstood the issue being addressed by this change.
> Forget about my comments and sorry for the noise.
No need to apologize, the more eyeballs the patch gets, the better !
We all misunderstand sometimes :)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-12-08 22:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-08 19:33 Questions rgd. patch "eeprom: at24: support eeproms that do not auto-rollover reads" Heiner Kallweit
2017-12-08 20:09 ` Sven Van Asbroeck
2017-12-08 22:19 ` Heiner Kallweit
2017-12-08 22:25 ` Sven Van Asbroeck
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.