On Thu, May 5, 2011 at 8:28 AM, Steven Toth <stoth@xxxxxxxxxxxxxx> wrote: > Mauro, > >> Subject: [media] cx24116: add config option to split firmware download >> Author: Antti Palosaari <crope@xxxxxx> >> Date: Wed Apr 27 21:03:07 2011 -0300 >> >> It is very rare I2C adapter hardware which can provide 32kB I2C write >> as one write. Add .i2c_wr_max option to set desired max packet size. >> Split transaction to smaller pieces according to that option. > > This is none-sense. I'm naking this patch, please unqueue, regress or whatever. > > The entire point of the i2c message send is that the i2c drivers know > nothing about the host i2c implementation, and they should not need > to. I2C SEND and RECEIVE are abstract and require no knowledge of the > hardware. This is dangerous and generates non-atomic register writes. > You cannot guarantee that another thread isn't reading/writing to > other registers in the part - breaking the driver. > > Please fix the host controller to split the i2c messages accordingly > (and thus keeping the entire transaction atomic). > > This is the second time I've seen the 'fix' to a problem by patching > the i2c driver. Fix the i2c bridge else we'll see this behavior > spreading to multiple i2c driver. It's just wrong. I tend to agree with Steven on this one. That said, these sorts of things usually get introduced in cases where the i2c master is not well enough understood to know how to split the transactions and still preserve the repeat start (common with reverse engineered drivers). It can also occur in cases where there really is a hardware limitation that prevents the caller from making multiple requests to the chip while not sending the stop bit (although this is less common). Do we know this to be the case with the anysee bridge? Is this a reverse engineered device? Is there documentation/datasheets to reference? Do we know if this is an issue with the i2c master driver not being fully baked, or if it's a hardware limitation? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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