[media] cec: accept two replies for CEC_MSG_INITIATE_ARC

The CEC_MSG_INITIATE_ARC message is special since it is the ONLY
CEC message that accepts two possible valid replies:

CEC_MSG_REPORT_ARC_INITIATED and CEC_MSG_REPORT_ARC_TERMINATED.

So if the transmitted message is CEC_MSG_INITIATE_ARC and the remote
side replied with CEC_MSG_REPORT_ARC_INITIATED or CEC_MSG_REPORT_ARC_TERMINATED,
then a msg->reply value of CEC_MSG_REPORT_ARC_INITIATED or
CEC_MSG_REPORT_ARC_TERMINATED will match either reply.

I thought about either adding a second reply2 field, but that's ugly
for all other messages that have only one reply, and what if in the
future a new message is added that can have three replies?

Another option would be to add a cec_msg flag, but really, the combination
of CEC_MSG_REPORT_ARC_INITIATED and a reply value of one of the two
possible replies already functions as a flag.

Another advantage of this approach is that it is safe to re-use a
cec_msg struct. No need to zero a flags field or a reply2 field.

So since this really is an exception in the CEC specification, I
decided to implement it as an exception as well.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2 files changed, 13 insertions, 14 deletions

diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO
index ce69001b04280..5a4cfdf8d15ec 100644
--- a/drivers/staging/media/cec/TODO
+++ b/drivers/staging/media/cec/TODO
@@ -1,18 +1,5 @@
-The reason why cec.c is still in staging is that I would like
-to have a bit more confidence in the uABI. The kABI is fine,
-no problem there, but I would like to let the public API mature
-a bit.
+TODOs:
 
-Once I'm confident that I didn't miss anything then the cec.c source
-can move to drivers/media and the linux/cec.h and linux/cec-funcs.h
-headers can move to uapi/linux and added to uapi/linux/Kbuild to make
-them public.
-
-Hopefully this will happen later in 2016.
-
-Other TODOs:
-
-- There are two possible replies to CEC_MSG_INITIATE_ARC. How to handle that?
 - Should CEC_LOG_ADDR_TYPE_SPECIFIC be replaced by TYPE_2ND_TV and TYPE_PROCESSOR?
   And also TYPE_SWITCH and TYPE_CDC_ONLY in addition to the TYPE_UNREGISTERED?
   This should give the framework more information about the device type
diff --git a/drivers/staging/media/cec/cec-adap.c b/drivers/staging/media/cec/cec-adap.c
index 93b53e602e48e..a65d8667b78e3 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -958,6 +958,18 @@ void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg)
 		list_for_each_entry(data, &adap->wait_queue, list) {
 			struct cec_msg *dst = &data->msg;
 
+			/*
+			 * The *only* CEC message that has two possible replies
+			 * is CEC_MSG_INITIATE_ARC.
+			 * In this case allow either of the two replies.
+			 */
+			if (!abort && dst->msg[1] == CEC_MSG_INITIATE_ARC &&
+			    (cmd == CEC_MSG_REPORT_ARC_INITIATED ||
+			     cmd == CEC_MSG_REPORT_ARC_TERMINATED) &&
+			    (dst->reply == CEC_MSG_REPORT_ARC_INITIATED ||
+			     dst->reply == CEC_MSG_REPORT_ARC_TERMINATED))
+				dst->reply = cmd;
+
 			/* Does the command match? */
 			if ((abort && cmd != dst->msg[1]) ||
 			    (!abort && cmd != dst->reply))