In theory, yes, you can. The I2c protocol is a very "flexible" protocol, both in speed as well as in length.
If a slow device can't cope with the speed of a faster device, the slow device is allowed to "slow down" the fast device by keeping the clock signal low for as long as it's needed. In theory forever, but in practice it would be unwise not to put some kind of time-out mechanism on the I2c master. For instance, "try to send or receive max. 5 times data from the addressee". As long as the clock is held low, nobody else can start a communication on the I2c bus. So far concerning the speed part.
Regarding the length part, also here I2c can have an "infinitive" amount of bytes that can be sent/received over the bus. The only two "markers" that are important and relevant to identify an I2c communication, are the start and stop combination. In between, you can have an endless amount of bytes sent over the bus. But also here, common sense is to be used.
First off, I don't know of any device that would take 64k of bytes (to take your number) as data. The largest consumers (I2c devices) I've seen so far, took a couple of hundred bytes as data. But such devices are really very, very rare. On average, an I2c device takes from one to maximum a couple of bytes of data traffic, both reading and writing.
So, the datatype short
for the field len
in the structure struct i2c_msg
is more than large enough to cover all possible current and future I2c communications.
More information can be found here (spec) and here (manual).