1. 30 10月, 2018 4 次提交
    • M
      i2c: uniphier-f: fix race condition when IRQ is cleared · eaba6878
      Masahiro Yamada 提交于
      The current IRQ handler clears all the IRQ status bits when it bails
      out. This is dangerous because it might clear away the status bits
      that have just been set while processing the current handler. If this
      happens, the IRQ event for the latest transfer is lost forever.
      
      The IRQ status bits must be cleared *before* the next transfer is
      kicked.
      
      Fixes: 6a62974b ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      eaba6878
    • M
      i2c: uniphier-f: fix occasional timeout error · 39226aaa
      Masahiro Yamada 提交于
      Currently, a timeout error could happen at a repeated START condition.
      
      For a (non-repeated) START condition, the controller starts sending
      data when the UNIPHIER_FI2C_CR_STA bit is set. However, for a repeated
      START condition, the hardware starts running when the slave address is
      written to the TX FIFO - the write to the UNIPHIER_FI2C_CR register is
      actually unneeded.
      
      Because the hardware is already running before the IRQ is enabled for
      a repeated START, the driver may miss the IRQ event. In most cases,
      this problem does not show up since modern CPUs are much faster than
      the I2C transfer. However, it is still possible that a context switch
      happens after the controller starts, but before the IRQ register is
      set up.
      
      To fix this,
      
       - Do not write UNIPHIER_FI2C_CR for repeated START conditions.
      
       - Enable IRQ *before* writing the slave address to the TX FIFO.
      
       - Disable IRQ for the current CPU while queuing up the TX FIFO;
         If the CPU is interrupted by some task, the interrupt handler
         might be invoked due to the empty TX FIFO before completing the
         setup.
      
      Fixes: 6a62974b ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      39226aaa
    • M
      i2c: uniphier-f: make driver robust against concurrency · f1fdcbbd
      Masahiro Yamada 提交于
      This is unlikely to happen, but it is possible for a CPU to enter
      the interrupt handler just after wait_for_completion_timeout() has
      expired. If this happens, the hardware is accessed from multiple
      contexts concurrently.
      
      Disable the IRQ after wait_for_completion_timeout(), and do nothing
      from the handler when the IRQ is disabled.
      
      Fixes: 6a62974b ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      f1fdcbbd
    • W
  2. 12 10月, 2018 4 次提交
  3. 09 10月, 2018 3 次提交
  4. 07 10月, 2018 7 次提交
  5. 06 10月, 2018 22 次提交