- signal POLLIN if there is already data in the FIFO
- send ETIMEDOUT to userspace after 2 seconds if TX IRQ was not received
- handle FIFO overflow
- handle invalid pipes/empty FIFO
- multiple cosmetics (missing static, duplicate define, missing \n)
Save elapsed time before handling I2C in stm32_i2c_sem_waitstop()
This patch follows the same logic as in previous fix to
stm32_i2c_sem_waitdone().
It is possible that a context switch occurs after I2C registers are read
but before elapsed time is saved in stm32_i2c_sem_waitstop(). It is then
possible that the registers were read only once with "elapsed time"
equal 0. When scheduler resumes this thread it is quite possible that
now "elapsed time" will be well above timeout threshold. In that case
the function returns and reports a timeout, even though the registers
were not read "recently".
Fix this by inverting the order of operations in the loop - save elapsed
time before reading registers. This way a context switch anywhere in the
loop will not cause an erroneous "timeout" error.
This patch follows the same logic as in previous fix to
stm32_i2c_sem_waitdone().
It is possible that a context switch occurs after I2C registers are read
but before elapsed time is saved in stm32_i2c_sem_waitstop(). It is then
possible that the registers were read only once with "elapsed time"
equal 0. When scheduler resumes this thread it is quite possible that
now "elapsed time" will be well above timeout threshold. In that case
the function returns and reports a timeout, even though the registers
were not read "recently".
Fix this by inverting the order of operations in the loop - save elapsed
time before reading registers. This way a context switch anywhere in the
loop will not cause an erroneous "timeout" error.
It is possible that a context switch occurs after stm32_i2c_isr() call
but before elapsed time is saved in stm32_i2c_sem_waitdone(). It is then
possible that the handling code was executed only once with "elapsed
time" equal 0. When scheduler resumes this thread it is quite possible
that now "elapsed time" will be well above timeout threshold. In that
case the function returns and reports a timeout, even though the
handling code was not executed "recently".
Fix this by inverting the order of operations in the loop - save elapsed
time before handling I2C. This way a context switch anywhere in the loop
will not cause an erroneous "timeout" error.
