i2c-tools 4.0
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,
Signature · 2 lines
Jean Delvare SUSE L3 Support
Quoted 2 lines
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.
Quoted 10 lines · 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/i2cbussesinto 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.
Quoted 6 lines
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
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Hi Robert,
Quoted 19 lines · Robert P. J. Day
Quoted 10 lines · 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/i2cbussesinto 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.Quoted 6 lines
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.
Quoted 7 lines
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?directto 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.
Signature · 2 lines
Jean Delvare SUSE L3 Support
Quoted 30 lines · Jean Delvare
Hi Robert,
Quoted 19 lines · Robert P. J. Day
Quoted 10 lines · 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/i2cbussesinto 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.Quoted 6 lines
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.
Quoted 7 lines
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?directto increase the write sleep time so that one can write multiple bytes with eeprog?
Quoted 6 lines
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
Quoted 8 lines
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
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 11 lines · Robert P. J. Day
Quoted 6 lines · Jean Delvare
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:
You forgot to Cc me :(
Quoted 9 lines
Quoted 8 lines
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.
Quoted 3 lines
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:
Signature · 2 lines
Jean Delvare SUSE L3 Support
Quoted 9 lines · Jean Delvare
Quoted 8 lines · Robert P. J. Day
Quoted 6 lines · Jean Delvare
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.
Quoted 5 lines
Quoted 3 lines
i actually did ask about this very issue last month:
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
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 3 lines · Jean Delvare
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
Hi Ondřej,
Quoted 5 lines · Ondřej Lysoněk
Quoted 1 line · Jean Delvare
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.
Signature · 2 lines
Jean Delvare SUSE L3 Support