Re: i2c-tools 4.0

["Robert P. J. Day" <rpjday@crashcourse.ca>]

On Thu, 10 Aug 2017, Jean Delvare wrote:

> Hi Robert,
>
> On Tue, 8 Aug 2017 13:59:49 -0400 (EDT), Robert P. J. Day wrote:
> > On Thu, 3 Aug 2017, Jean Delvare wrote:
> >
> > > Hi all,
> > >
> > > I have been delaying this for too long, let's release i2c-tools 4.0. I
> > > know that there are still a few things which I wanted to include in it
> > > which aren't ready (specifically, merging (parts of) tools/i2cbusses
> > > into the library, and documenting the API), but apparently I can't find
> > > the time for them. So I have come to the conclusion that we should
> > > release what we have, and build incrementally on top of it after it has
> > > been adopted by distributions.
> > >
> > > Therefore I would like to ask everyone to give good testing to the
> > > master branch of:
> > >
> > > https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/
> > >
> > > because it will become i2c-tools 4.0 in a near future.
> >
> >   is it too late to suggest this patch:
> >
> > https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html
> > https://share.toradex.com/s07bedxtxfdc4wj?direct
> >
> > to increase the write sleep time so that one can write multiple
> > bytes with eeprog?
>
> Thanks for the report. I wonder why people always wait for
> announcements of imminent releases to report bugs ;-) Bugs have to
> be fixed anyway, before or after a release doesn't really make a
> difference, as there were other releases before and there will be
> other releases later. Distributions will cherry pick individual
> commits for backport as needed.

  i actually did ask about this very issue last month:

http://marc.info/?l=linux-i2c&m=150109384702585&w=2

> Back to the bug itself, the fix will clearly slow down the writes
> for some users. I'm not so worried as writing to EEPROMs isn't a
> frequent operation and better safe than sorry. So I can apply it,
> but for the long term I think this is calling for either a command
> line parameter (to let the user decide of the sleep time) or a retry
> loop (this is what the at24 kernel driver is doing.) If anyone wants
> to provide a patch implementing either solution, I'll be happy to
> review it.

  if the patch referred to above still applies cleanly, i can just
submit that later today. i understand that it will slow down writes;
on the other hand, without it, multi-byte writes simply won't work.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================