Am 14.12.2012 17:55, schrieb Antti Palosaari: > On 12/14/2012 06:28 PM, Frank Schäfer wrote: >> The em2800 can transfer up to 4 bytes per i2c message. >> All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per >> message. >> >> I2C adapters should never split messages transferred via the I2C >> subsystem >> into multiple message transfers, because the result will almost >> always NOT be >> the same as when the whole data is transferred to the I2C client in a >> single >> message. >> If the message size exceeds the capabilities of the I2C adapter, >> -EOPNOTSUPP >> should be returned. >> >> Signed-off-by: Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> > > >> + if (len < 1 || len > 4) >> + return -EOPNOTSUPP; > > That patch seem to be good for my eyes, but that check for len < 1 is > something I would like to double checked. Generally len = 0 is OK and > is used some cases, probing and sometimes when all registers are read > for example. > > Did you test it returns some error for zero len messages? > First of all: thank you for reviewing the patch ! Yeah, messages with zero length could be used for device detection. But yes, I checked that and it doesn't work. For the em2800 algorithm, it doesn't work because of the way the mesage length is encoded in the first two bytes of register 0x05: 118 buf2[1] = 0x84 + len - 1; Bit 2 is used for read/write, that's why it is 67 b2[5] = 0x80 + len - 1; for writes. The more interesting case is the em28xx i2c algorithm... But zero length messages don't work there, too (at least not with the em2765 and em2820). To be more precise: they SEEM to work, but they don't. Even when there is no i2c device, you get no error (neither from the USB subsystem, nor from the bridge status register). Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
