On Mon, Sep 22, 2014 at 1:04 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > >> >> >> + if (msg->len == 0 || msg->len > 255) >> >> >> + return -EINVAL; >> >> > >> >> > Ouch, really? Maybe we should warn the user here. >> >> >> >> Yeah, the transfer length register limits the length to 255. I'll add >> >> a warning here. >> > >> > Please also add this information to the Kconfig description and >> > somewhere at the top of the source file. This is an important flaw which >> > people should easily find out about. >> > >> >> You are referring to the "len <= 255" restriction being the flaw here, >> right? I'll add a note to Kconfig and the driver about that. > > Yes, I meant that. I just remembered we should do something else: > > Remove I2C_FUNC_I2C (because it cannot do endless transfers) from > functionality and simply use I2C_FUNC_SMBUS_I2C_BLOCK which does I2C > like transfers with the SMBus Limit of 32 bytes. It seems PMBus allows > for 255 byte which this HW could support, yet I don't recall we have > support for that size currently. > Just tried this out... With the above change (I2C_FUNC_I2C replaced with I2C_FUNC_SMBUS_I2C_BLOCK) an EEPROM device fails (at24 driver) since it can't do a 16-bit offset when using the SMBUS_I2C_BLOCK transfer. Would you be OK with keeping the I2C_FUNC_I2C capability and documenting the restriction (as per your initial suggestion)? /Anders -- 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