> I don't get where you're going with rewriting the driver. You'll end up > with a larger driver doing exactly the same, without taking benefit of > the SMBus emulation layer from i2c-core. If the hardware has a problem > with Quick commands, rewriting the driver won't solve that. Better > intercept that case in the current driver and return an error. Hmm, maybe you are right. I'm a beginner in kernel hacking and I tried to rewrite this driver mainly to learn linux-driver programming. > So what problem are > you trying to solve exactly? Well, when I modprobe the original ocore driver, an i2c slave driver already present under the kernel probe the bus with write-quick command. This command block the controller : http://dl.free.fr/qS2l40o9p (yellow:SDA, green:SCL, pink: interrupt) This problem is normal if I read the datasheet(http://www.opencores.org/cvsweb.shtml/i2c/doc/i2c_specs.pdf), because to send only one byte (address byte) the stop command must be send at the same time that start command. The driver is marked as SMBus emulation compatible : static u32 ocores_func(struct i2c_adapter *adap) { return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL; } But apparently it does not support all SMBus commands, and I can't use i2cdetect to scan the bus. With my new version of the driver, really bigger than original, SMBus commands are supported one by one and I can use i2cdetect to scan the bus: static u32 ocores_func(struct i2c_adapter *adap) { return I2C_FUNC_SMBUS_BYTE_DATA| I2C_FUNC_SMBUS_WORD_DATA| I2C_FUNC_SMBUS_BYTE| I2C_FUNC_SMBUS_QUICK| I2C_FUNC_SMBUS_WRITE_I2C_BLOCK| I2C_FUNC_SMBUS_READ_I2C_BLOCK; } But maybe it's a bad idea to re-write the driver, I will investigate to find another solution. Fabien M -- 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
