On Tue, Dec 05, 2017 at 09:14:22AM +0100, Bartosz Golaszewski wrote:
> 2017-12-05 8:44 GMT+01:00 Sakari Ailus :
> > On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
> >> > If this is truly specific to at24, then vendor prefix would be
> >> > appropriate,
> >> > plus it'd go to an
2017-12-05 8:44 GMT+01:00 Sakari Ailus :
> On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
>> > If this is truly specific to at24, then vendor prefix would be appropriate,
>> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
>> > remove the above sente
On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
> > If this is truly specific to at24, then vendor prefix would be appropriate,
> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
> > remove the above sentence. I guess the latter?
>
> Yes, no-read-rol
> If this is truly specific to at24, then vendor prefix would be appropriate,
> plus it'd go to an at24 specific binding file. However if it isn't I'd just
> remove the above sentence. I guess the latter?
Yes, no-read-rollover is truly specific to at24.c, because it applies only
to i2c multi-addre
Hi Sven,
On Mon, Dec 04, 2017 at 10:36:18AM -0500, Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck
>
> Some multi-address eeproms in the at24 family may not automatically
> roll-over reads to the next slave address. On those eeproms, reads
> that straddle slave boundaries will not work correc
From: Sven Van Asbroeck
Some multi-address eeproms in the at24 family may not automatically
roll-over reads to the next slave address. On those eeproms, reads
that straddle slave boundaries will not work correctly.
Solution:
Mark such eeproms with a flag that prevents reads straddling
slave boun
6 matches
Mail list logo
