i2c-tools 4.0

i2c-tools 4.0

[Jean Delvare]

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.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: i2c-tools 4.0

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]


> I have been delaying this for too long, let's release i2c-tools 4.0.

Yay! Thanks, Jean. I've been using the master branch a lot on my
embedded boards. But I'll give it extra attention from now on.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: i2c-tools 4.0

[Robert P. J. Day]

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?

rday

-- 

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

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

Re: i2c-tools 4.0

[Jean Delvare]

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.

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.

-- 
Jean Delvare
SUSE L3 Support

Re: i2c-tools 4.0

[Robert P. J. Day]

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
========================================================================

Re: i2c-tools 4.0

[Jean Delvare]

On jeu., 2017-08-10 at 04:30 -0400, Robert P. J. Day wrote:
> On Thu, 10 Aug 2017, Jean Delvare wrote:
> > 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

You forgot to Cc me :(

> > 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.

No need, I already applied a cleaned up version thereof:

https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/commit/?id=7c1260bd0ee73c392f8c2a5b32b4b7c118011255

-- 
Jean Delvare
SUSE L3 Support

Re: i2c-tools 4.0

[Robert P. J. Day]

On Thu, 10 Aug 2017, Jean Delvare wrote:

> On jeu., 2017-08-10 at 04:30 -0400, Robert P. J. Day wrote:
> > On Thu, 10 Aug 2017, Jean Delvare wrote:
> > > 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
>
> You forgot to Cc me :(

  in my defense, at the time, the README file knew nothing about you.
:-)

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

rday

-- 

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

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

Re: i2c-tools 4.0

[Ondřej Lysoněk]

On 3.8.2017 15:34, Jean Delvare wrote:
> Hi all,
>
> I have been delaying this for too long, let's release i2c-tools 4.0.

Hi,

is there a plan when it will be released? I can't wait to package it in
Fedora :). Thanks!

Best regards
Ondřej Lysoněk

Re: i2c-tools 4.0

[Jean Delvare]

Hi Ondřej,

On Thu, 12 Oct 2017 13:42:43 +0200, Ondřej Lysoněk wrote:
> On 3.8.2017 15:34, Jean Delvare wrote:
> > I have been delaying this for too long, let's release i2c-tools 4.0.  
> 
> is there a plan when it will be released? I can't wait to package it in
> Fedora :). Thanks!

My secret unofficial deadline for this task is set to end of October.

-- 
Jean Delvare
SUSE L3 Support