On Sun, 28 Oct 2012 17:25:19 +0200, Frank Schäfer wrote: > Am 28.10.2012 17:33, schrieb Jean Delvare: > > Most I2C_FUNC_* flags actual refer to the smbus_xfer method. A driver > > implementing master_xfer is typically fully I2C capable and can thus > > run almost any I2C or SMBus transaction. Such a driver will set > > functionality flags to I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL. The rest of > > the flags are for SMBus-only controllers. Each flag basically > > corresponds to an i2c_smbus_*() function, which in turn corresponds to > > the combination of an SMBus transaction type or size and a direction > > (read or write). > > > > The mapping between i2c_smbus_*() functions and functionality flags is > > rather obvious, but for clarity I'll update > > Documentation/i2c/smbus-protocol to mention it. Patch follows. > > > > Also see Documentation/i2c/functionality for a detailed explanation of > > how functionality flags work both on the I2C/SMBus adapter driver and > > the I2C device driver sides. > > Ok, so the functionality flags describe whats possible when using the > smbus functions. > That's a bit confusing/misleading if the adapter driver doesn't > implement the smbus_xfer function in struct i2c_algorithm. > And if the i2c adapter / master_xfer fcn has some restrictions (e.g. > data length), things are getting complicated. Yes, this is correct. > I2C_FUNC_SMBUS functionality flags are sufficiently documented, but what > about I2C_FUNC_I2C ? I2C_FUNC_I2C means that you can call i2c_transfer, i2c_master_send and i2c_master_recv on the I2C adapter. > Should this be set always if there is a master_xfer function or only if > the adapter is fully i2c compliant (and what does "fully i2c compliant" > mean ?) ? If i2c_transfer() has a chance to succeed for any transaction type not covered by I2C_FUNC_SMBUS_* flags, then I2C_FUNC_I2C should be set. So yes, you are right, I2C_FUNC_I2C is set if and only if master_xfer is implemented. In theory, "fully I2C compliant" means that i2c_transfer() would succeed regardless of the message set passed (unless protocol mangling flags are used.) In practice, it is still OK to set I2C_FUNC_I2C if the controller has limitations, as long as these limitations are less restrictive than SMBus. > To summarize: there is no possibilty to determine the maximum i2c data > length when using the i2c_xfer functions directly. It's basically try > and error and if the message is too long, the adapters should return > -EOPNOTSUPP. Yes, this is correct. I2C_FUNC_* flags aren't fine-grained enough to describe all cases, so they should be used as a way for device driver to exclude transactions which aren't supported at all, but they may still have to deal with -EOPNOTSUPP on supported transactions. This is handled on a case-by-case basis. It could be argued that the I2C_FUNC_* flags aren't really necessary and drivers could simply try what they need and deal with -EOPNOTSUPP afterward. This is correct but it would probably make the driver code more complex in most cases. -- Jean Delvare -- 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
