diff options
author | Hans Verkuil <hans.verkuil@cisco.com> | 2016-11-01 11:07:17 -0200 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@s-opensource.com> | 2016-11-16 15:34:55 -0200 |
commit | f5580d8d6fd07a569e468fca51f435aa5b122fc4 (patch) | |
tree | dc212411330d80b93c3cee35852de78aa5bdb866 /Documentation | |
parent | 3074fe4a7da5775bcf31675d6d9e2687c434fef2 (diff) | |
download | linux-stable-f5580d8d6fd07a569e468fca51f435aa5b122fc4.tar.gz linux-stable-f5580d8d6fd07a569e468fca51f435aa5b122fc4.tar.bz2 linux-stable-f5580d8d6fd07a569e468fca51f435aa5b122fc4.zip |
[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>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/media/uapi/cec/cec-ioc-receive.rst | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst b/Documentation/media/uapi/cec/cec-ioc-receive.rst index b4dffd2f7dfa..bdf015b1d1dc 100644 --- a/Documentation/media/uapi/cec/cec-ioc-receive.rst +++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst @@ -142,6 +142,14 @@ result. Feature Abort reply. In this case ``rx_status`` will either be set to :ref:`CEC_RX_STATUS_TIMEOUT <CEC-RX-STATUS-TIMEOUT>` or :ref:`CEC_RX_STATUS_FEATURE_ABORT <CEC-RX-STATUS-FEATURE-ABORT>`. + + If the transmitter message is ``CEC_MSG_INITIATE_ARC`` then the ``reply`` + values ``CEC_MSG_REPORT_ARC_INITIATED`` and ``CEC_MSG_REPORT_ARC_TERMINATED`` + are processed differently: either value will match both possible replies. + The reason is that the ``CEC_MSG_INITIATE_ARC`` message is the only CEC + message that has two possible replies other than Feature Abort. The + ``reply`` field will be updated with the actual reply so that it is + synchronized with the contents of the received message. * - __u8 - ``rx_status`` - The status bits of the received message. See |