Here is what system-call behaviour I was expecting from the position of a user space developer. You can then say whether it is impossible, incorrect or inefficient. When I found that the read() was failing I at once suspected that a write() was not finished at the time of the call. So I added the O_SYNC flag to the open() call. (The man says: O_SYNC - The file is opened for synchronous I/O. Any write()s on the resulting file descriptor will block the calling process until the data has been physically written to the underlying hardware.) But obviously this didn't fix the issue. Correct me if I'm wrong but I would expect from a synchronous write() call to NOT finish before the data has been "phisically written". And in this case of course the read operation wouldn't need a waiting loop. What do you think? Regards, Aleks 2009/11/6 Wolfram Sang <w.sang@xxxxxxxxxxxxxx>: > >> This makes a lot of sense. When a write operation is in progress, the >> EEPROM is busy and may not ack its address. Whether the request is >> another write or a read probably doesn't make a difference, a nack is a >> nack. So the same waiting loop that we have for writes, is certainly >> needed for reads as well. Shouldn't be too difficult. Any volunteer? I >> can review the patch when it's done. > > If nobody is faster ;), I will do it this weekend. > > -- > Pengutronix e.K. | Wolfram Sang | > Industrial Linux Solutions | http://www.pengutronix.de/ | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkr0G0EACgkQD27XaX1/VRsWPgCgr43owCqfBvtuQHtCz5bY9nZg > rT0An26MIi9s6NobqIAeKgDKWvky9/pp > =0Jrc > -----END PGP SIGNATURE----- > > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
