On 02/02/2015 09:33 PM, Wolfram Sang wrote:
Ok, this may eventually work ok for now, but a further change at the I2C
core could easily break it. So, we need to double check about such
patch with the I2C maintainer.
Jean,
Are you ok with such patch? If so, please ack.
Jean handed over I2C to me in late 2012 :)
Basic problem here is that I2C-mux itself is controlled by same I2C device
which implements I2C adapter for tuner.
Here is what connections looks like:
___________ ____________ ____________
| USB IF | | demod | | tuner |
|-----------| |------------| |------------|
| |--I2C--|-----/ -----|--I2C--| |
|I2C master | | I2C mux | | I2C slave |
|___________| |____________| |____________|
So when tuner is called via I2C, it needs recursively call same I2C adapter
which is already locked. More elegant solution would be indeed nice.
So, AFAIU this is the same problem that I2C based mux devices have (like
drivers/i2c/muxes/i2c-mux-pca954x.c)? They also use the unlocked
transfers...
But those are all called with the lock for the adapter being held. I'm not
convinced this is the same for this patch. This patch seems to add a device
mutex which protects against concurrent access to the bus with the device
itself, but not against concurrent access with other devices on the same bus.
--
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
