[OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Maxin B. John]

Hi,
On Mon, Jul 31, 2017 at 03:50:17PM +0300, Maxin B. John wrote:
> Hi,
> 
> On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpjday at crashcourse.ca wrote:
> > 
<snip>
> > 
> >   well, here's a possible conundrum ... in that same package (i2c-tools),
> > there appears to be an *obvious* flaw in that the "eeprog" utility uses a
> > sleep that is far too short for proper operation, as described here:
> > 
> > https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html
> > 
> > there is a link to a patch on that page that simply cranks up a few sleep
> > calls from 10usec to 5msec, which apparently solves the problem. i've been
> > involved in a discussion on the i2c-tools mailing list about this very
> > issue after i tripped over it, but there seems to be little enthusiasm on
> > that list for "fixing" this -- i was told that people use the kernel driver
> > instead and access via /sys rather than calling "eeprog".
> 
> dl.lm-sensors.org has been down for a while and doesn't show any positive signs that
> it will be back in near future. One possibility will be to use the unofficial mirrors
> listed below and upgrade to version 3.1.2

Sorry, I meant to use the most recent version (we already have the latest released verion - 3.1.2) 

> 1. https://fossies.org/linux/misc/
> 2. http://jdelvare.nerim.net/mirror/i2c-tools/
> 
> >   so, from my perspective, this should definitely be fixed so that "eeprog"
> > functions properly, but it's not clear upstream is all that interested in it.
> > what would the protocol be here?
> 
> Since this genuinely fixes an error, we should be able to include this patch with:
> "Inappropriate [bug workaround]" status. 
> 
> > rday
> 
> Best Regards,
> Maxin