On Tue, 24 Apr 2012 15:01:18 +0200, Wolfram Sang wrote: > > > * We should allocate a new functionality flag for it. > > > * We should update the documentation to reflect the two use cases. > > > > That sounds like a good plan. I'll try to get round to it if nobody > > beats me to it. > > Would it make sense to make all four I2C_M_* mangling features seperate > I2C_FUNC_* options? The old I2C_FUNC_PROTOCOL_MANGLING could then be all > four (seperately) exposed mangling features ORed. That's what I was > wondering when looking at the patch. The problem is that the functionality is stored in a 32-bit integer, and we already use 17 bits in it, so every use of extra bits must be pondered. OK, we have 15 free at the moment, but we could need some in the future for new SMBus-style transactions, for example multi-byte addressed block reads and writes. I think the assumption was that mangling requires full control of the bus lines, so a driver would either support all quirks (i2c-algo-bit) or none (everybody else), thus having a single functionality flag. As it seems I2C_M_NOSTART no longer fits the "quirky" category, having a separate flag for it would make sense. But I would leave the rest alone for the time being. -- 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
