Commit ac479b51 authored by Hans Verkuil's avatar Hans Verkuil Committed by Mauro Carvalho Chehab

media: cec: check 'transmit_in_progress', not 'transmitting'

Currently wait_event_interruptible_timeout is called in cec_thread_func()
when adap->transmitting is set. But if the adapter is unconfigured
while transmitting, then adap->transmitting is set to NULL. But the
hardware is still actually transmitting the message, and that's
indicated by adap->transmit_in_progress and we should wait until that
is finished or times out before transmitting new messages.

As the original commit says: adap->transmitting is the userspace view,
adap->transmit_in_progress reflects the hardware state.

However, if adap->transmitting is NULL and adap->transmit_in_progress
is true, then wait_event_interruptible is called (no timeout), which
can get stuck indefinitely if the CEC driver is flaky and never marks
the transmit-in-progress as 'done'.

So test against transmit_in_progress when deciding whether to use
the timeout variant or not, instead of testing against adap->transmitting.
Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 32804fcb ("media: cec: keep track of outstanding transmits")
Cc: <stable@vger.kernel.org>      # for v4.19 and up
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
parent 95c29d46
...@@ -465,7 +465,7 @@ int cec_thread_func(void *_adap) ...@@ -465,7 +465,7 @@ int cec_thread_func(void *_adap)
bool timeout = false; bool timeout = false;
u8 attempts; u8 attempts;
if (adap->transmitting) { if (adap->transmit_in_progress) {
int err; int err;
/* /*
...@@ -500,7 +500,7 @@ int cec_thread_func(void *_adap) ...@@ -500,7 +500,7 @@ int cec_thread_func(void *_adap)
goto unlock; goto unlock;
} }
if (adap->transmitting && timeout) { if (adap->transmit_in_progress && timeout) {
/* /*
* If we timeout, then log that. Normally this does * If we timeout, then log that. Normally this does
* not happen and it is an indication of a faulty CEC * not happen and it is an indication of a faulty CEC
...@@ -509,14 +509,18 @@ int cec_thread_func(void *_adap) ...@@ -509,14 +509,18 @@ int cec_thread_func(void *_adap)
* so much traffic on the bus that the adapter was * so much traffic on the bus that the adapter was
* unable to transmit for CEC_XFER_TIMEOUT_MS (2.1s). * unable to transmit for CEC_XFER_TIMEOUT_MS (2.1s).
*/ */
pr_warn("cec-%s: message %*ph timed out\n", adap->name, if (adap->transmitting) {
adap->transmitting->msg.len, pr_warn("cec-%s: message %*ph timed out\n", adap->name,
adap->transmitting->msg.msg); adap->transmitting->msg.len,
adap->transmitting->msg.msg);
/* Just give up on this. */
cec_data_cancel(adap->transmitting,
CEC_TX_STATUS_TIMEOUT);
} else {
pr_warn("cec-%s: transmit timed out\n", adap->name);
}
adap->transmit_in_progress = false; adap->transmit_in_progress = false;
adap->tx_timeouts++; adap->tx_timeouts++;
/* Just give up on this. */
cec_data_cancel(adap->transmitting,
CEC_TX_STATUS_TIMEOUT);
goto unlock; goto unlock;
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment