Bonjour Stéphane, On Mon, 20 Feb 2012 14:01:52 +0100, Stephane Grosjean wrote: > I'm facing a deadlock regarding a timer callback which is only calling > i2c_transfer(), and I wonder if this comes from that call: I first > googled and found that i2c_transfer() may sleep (which is forbidden in > my timer callback) but when I have a look the beginning of the function, > it starts to check if it is in any atomic context, before trying to > acquire a lock... > > So I'm afraid I'm lost and I hope someone will be able to understand to > that question: might i2c_transfer() be used in a timer callback or > should I handle my periodic call to i2c_tranfer() by means of a delayed > work? Depends on the underlying I2C adapter driver. One of the sleep causes is indeed the acquisition of the mutex in i2c_transfer(). However the function then calls a driver specific callback function (adap->algo->master_xfer) which may or may not sleep too depending on the implementation. So if you want your code to be portable, you have to assume that it may sleep, which means you indeed have to use a delayed work. HTH, -- Jean Delvare -- 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
