title: How an I2c read as well as write operation in "handler function" of request_threaded_irq affects the driver as a whole.?
body: <p>I have a driver code with handler function and thread function of request_threaded_irq similar to this:</p>
  
  <pre><code>irq-handler fn()
  {
        /*disable device interrupt*/
        i2c read from register;
        set disable bit to client-device-interrupt 
        i2c write back;
        return IRQ_WAKe_THREAD;
  }
  
  
  
  irq-thread fn()
  {
        i2c read from register;
        ....
        ....
        /*enable device interrupt*/
        i2c read from register;
        set enable bit to client-device-interrupt 
        i2c write back;
        /*Rest of the operation*/
        ..........
        ..........
        return IRQ_HANDLED;
  }
  </code></pre>
  
  <p>I have few question with respect to above implentation.</p>
  
  <ol>
  <li><p>Will 2 i2c operation in "handler fn" takes considerable amount of time.?</p></li>
  <li><p>Should I need to make bit manipulation in "handler fn" atomic?</p></li>
  <li><p>Should I move the operation performed till "enable device interrupt" from "thread fn" to "handler fn"(this would cost me 4 more i2c operation and one bit manipulation exactly) ? - reason being chances are there that i can miss interrupt as per above code implementation.</p></li>
  <li><p>If I do so(as per question 3). how does it affects the other device interrupts.(<strong>as I have a basic doubt whether "handler fn" in hard IRQ context operates with interrupts disabled</strong>)</p></li>
  </ol>
  
  <p>Please provide me a good and optimum solution for the above scenario.</p>
  
  <p>Thanks in advance.</p>