Questions about i2c_transfer() usage in timer context...

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?

Bonjour Stéphane,

Quoted 11 lines · Stephane Grosjean

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,

Quoted 3 lines · Jean Delvare

Quoted 1 line · Stephane Grosjean

I'm facing a deadlock regarding a timer callback...

Quoted 5 lines

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.

Indeed. A fair number of the i2c transfer functions I have encountered call schedule_work() or equivalent, and/or wait_for_completion().

The low-level transfer function implementations are entirely platform-dependent, and often lean heavily on the assumption that they aren't called in atomic contexts. So in addition to driving architecture decisions in your code which calls them, they can also have implications for real-time performance.

None of the above is a complaint, mind you. Just observations. :)