]> git.karo-electronics.de Git - karo-tx-linux.git/commit
[media] cec: accept two replies for CEC_MSG_INITIATE_ARC
authorHans Verkuil <hans.verkuil@cisco.com>
Tue, 1 Nov 2016 13:07:17 +0000 (11:07 -0200)
committerMauro Carvalho Chehab <mchehab@s-opensource.com>
Wed, 16 Nov 2016 17:34:55 +0000 (15:34 -0200)
commitf5580d8d6fd07a569e468fca51f435aa5b122fc4
treedc212411330d80b93c3cee35852de78aa5bdb866
parent3074fe4a7da5775bcf31675d6d9e2687c434fef2
[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>
Documentation/media/uapi/cec/cec-ioc-receive.rst
drivers/staging/media/cec/TODO
drivers/staging/media/cec/cec-adap.c