aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorFrederic Barrat <fbarrat@linux.ibm.com>2018-11-29 19:17:17 +0100
committerVasant Hegde <hegdevasant@linux.vnet.ibm.com>2018-12-14 11:16:37 +0530
commite5e99d277fc54ed757148a9f93e8c75b223dc7b8 (patch)
treec36f9a9e159d1f0384e943e089411ecdb7adbc90 /doc
parentad92cf94b5f7a2a6c653c0473918b1d51f9f3875 (diff)
downloadskiboot-e5e99d277fc54ed757148a9f93e8c75b223dc7b8.zip
skiboot-e5e99d277fc54ed757148a9f93e8c75b223dc7b8.tar.gz
skiboot-e5e99d277fc54ed757148a9f93e8c75b223dc7b8.tar.bz2
i2c: Fix i2c request hang during opal init if timers are not checked
[Upstream commit 1bd34e4c60c69faeb825ba5f64658941a1422403] If an i2c request cannot go through the first time, because the bus is found in error and need a reset or it's locked by the OCC for example, the underlying i2c implementation is using timers to manage the request. However during opal init, opal pollers may not be called, it depends in the context in which the i2c request is made. If the pollers are not called, the timers are not checked and we can end up with an i2c request which will not move foward and skiboot hangs. Fix it by explicitly checking the timers if we are waiting for an i2c request to complete and it seems to be taking a while. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions