> Fix #1 looks fine. > Fix #2 (test_bus) I'm sure is an improvement. > If you are really motivated, try fixing the printk's for debug=1. > As I recall from long ago some of them are not correct. Could be a feature. Maybe the author considered that someone askin for the test shouldn't have to also set i2c_debug in order to see the result of the test. My opinion is that I would rather do the test as the default (that is, default to bit_test=1) and not show anything about it unless i2c_debug>=1. The reason why I suggest this should be the default is that I plan to write a unified i2c-over-parport driver as a replacement for the 5 different drivers out there. Idealy, that driver would be able to autodetect which kind of parallel port adapter is present. This can't be done without bit_test=1 as far as I can tell. So, unless bit_test is likely to cause trouble (shouldn't since we check the bus isn't busy) I would like it to be the default. This also solves other problems, such as sensors-detect taking forever to scan i2c-matroxfb busses with non DDC-compliant monitor plugged-in. > If you want to be truly frightened try debug=9. I don't want to be frightened. I already live right in front of a graveyard, that's enough ;) > The actual cycle time is 2/3 of advertised (yes it's 3 states total, > not 2 or 4). I guess you mean 3/2 of advertised. If I read you (and the code) carefully, this means that SCL isn't a square signal, is it? Does this really comply with the I2C standard? (Just took a look at TODO... Let me be clear. All this stuff is way beyond me.) -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
