Re: [PATCH 4.19] commit 9a9e295e7c5c0409c020088b0ae017e6c2b7df6e upstream.

[Greg KH <greg@kroah.com>]

On Wed, Jun 26, 2019 at 05:14:16PM +0200, Mark Jonas wrote:
> From: Wang Xin <xin.wang7@cn.bosch.com>
> 
> eeprom: at24: fix unexpected timeout under high load
> 
> Within at24_loop_until_timeout the timestamp used for timeout checking
> is recorded after the I2C transfer and sleep_range(). Under high CPU
> load either the execution time for I2C transfer or sleep_range() could
> actually be larger than the timeout value. Worst case the I2C transfer
> is only tried once because the loop will exit due to the timeout
> although the EEPROM is now ready.
> 
> To fix this issue the timestamp is recorded at the beginning of each
> iteration. That is, before I2C transfer and sleep. Then the timeout
> is actually checked against the timestamp of the previous iteration.
> This makes sure that even if the timeout is reached, there is still one
> more chance to try the I2C transfer in case the EEPROM is ready.
> 
> Example:
> 
> If you have a system which combines high CPU load with repeated EEPROM
> writes you will run into the following scenario.
> 
>  - System makes a successful regmap_bulk_write() to EEPROM.
>  - System wants to perform another write to EEPROM but EEPROM is still
>    busy with the last write.
>  - Because of high CPU load the usleep_range() will sleep more than
>    25 ms (at24_write_timeout).
>  - Within the over-long sleeping the EEPROM finished the previous write
>    operation and is ready again.
>  - at24_loop_until_timeout() will detect timeout and won't try to write.
> 
> Cc: <stable@vger.kernel.org> # 4.19.x

This and the 4.14.y version now queued up, thanks!

greg k-h