Raspberry Pi I2C implementation still broken?

["William D. Jones" <thor0505%comcast.net@localhost>]

Hello all,

According to the following bug report:
http://gnats.netbsd.org/48855,

and mailing list posts:
https://mail-index.netbsd.org/port-arm/2013/01/17/msg001714.html
https://mail-index.netbsd.org/netbsd-bugs/2014/06/21/msg037157.html

Either the IOCTL or I2C driver the Raspberry Pi I2C implementation is 
broken. I believe I may have found another bug in the implementation by 
trying to read/write an I2C EEPROM using IOCTL, but I'm guessing it is 
related to the already existing IOCTL issues that cause writes to always 
succeed. It's also possible my sample code is wrong :P. So, before I file a 
problem report: Has there been any progress in fixing the above I2C write 
errors?

If I can determine this is a separate bug, I'll use this post as the basis 
for a problem report. Linked is some sample code I wrote that reads and 
writes an Atmel EEPROM using IOTCL: 
https://gist.github.com/cr1901/5fa37836788a52236c8e . The particular 
EEPROM's datasheet is here: http://www.atmel.com/devices/AT24HC04B.aspx . 
Searching for any reference to "stretching" in the datasheet returns no 
results. So I think I can eliminate the known bug in Broadcom's I2C 
implementation, as described here: 
https://github.com/raspberrypi/linux/issues/254 .

Specifically, the written data to the EEPROM is being garbled when sent, but 
the EEPROM successfully enters its write phase (i.e. cmdbuf/cmdlen in IOCTL 
are being sent properly). I have confirmed this by writing and reading the 
EEPROM sequentially without a 5ms delay, and IOCTL correctly fails, as 
during an internal write, the EEPROM does not respond to any inputs. Reads, 
as far as I can tell, succeed- new EEPROMs always return 0xFF for each 
address prior to write, and return the garbage data written for 
already-programmed EEPROMs. Perhaps I'm using the IOCTL interface 
incorrectly?

As always, thanks for any assistance. I'm not in a position to test/write a 
driver patch for the RPi, but I'll take a look at the code anyway.

Sincerely,

--
William D. Jones