Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

media: cec-ioc-receive.rst: clarify sequence and status fields

Improve the documentation for CEC_RECEIVE/TRANSMIT w.r.t. the
sequence and tx/rx_status fields.

Also remove a duplicate tx_status description.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

authored by

Hans Verkuil and committed by
Mauro Carvalho Chehab
0a1c80c6 d7894721

+26 -23
+26 -23
Documentation/userspace-api/media/cec/cec-ioc-receive.rst
··· 48 48 A received message can be: 49 49 50 50 1. a message received from another CEC device (the ``sequence`` field will 51 - be 0). 52 - 2. the result of an earlier non-blocking transmit (the ``sequence`` field will 53 - be non-zero). 51 + be 0, ``tx_status`` will be 0 and ``rx_status`` will be non-zero). 52 + 2. the transmit result of an earlier non-blocking transmit (the ``sequence`` 53 + field will be non-zero, ``tx_status`` will be non-zero and ``rx_status`` 54 + will be 0). 55 + 3. the reply to an earlier non-blocking transmit (the ``sequence`` field will 56 + be non-zero, ``tx_status`` will be 0 and ``rx_status`` will be non-zero). 54 57 55 58 To send a CEC message the application has to fill in the struct 56 59 :c:type:`cec_msg` and pass it to :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`. ··· 67 64 68 65 If the file descriptor is in non-blocking mode then the transmit will 69 66 return 0 and the result of the transmit will be available via 70 - :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` once the transmit has finished 71 - (including waiting for a reply, if requested). 72 - 73 - The ``sequence`` field is filled in for every transmit and this can be 74 - checked against the received messages to find the corresponding transmit 75 - result. 67 + :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` once the transmit has finished. 68 + If a non-blocking transmit also specified waiting for a reply, then 69 + the reply will arrive in a later message. The ``sequence`` field can 70 + be used to associate both transmit results and replies with the original 71 + transmit. 76 72 77 73 Normally calling :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` when the physical 78 74 address is invalid (due to e.g. a disconnect) will return ``ENONET``. ··· 125 123 - ``sequence`` 126 124 - A non-zero sequence number is automatically assigned by the CEC framework 127 125 for all transmitted messages. It is used by the CEC framework when it queues 128 - the transmit result (when transmit was called in non-blocking mode). This 129 - allows the application to associate the received message with the original 130 - transmit. 126 + the transmit result for a non-blocking transmit. This allows the application 127 + to associate the received message with the original transmit. 128 + 129 + In addition, if a non-blocking transmit will wait for a reply (ii.e. ``timeout`` 130 + was not 0), then the ``sequence`` field of the reply will be set to the sequence 131 + value of the original transmit. This allows the application to associate the 132 + received message with the original transmit. 131 133 * - __u32 132 134 - ``flags`` 133 135 - Flags. See :ref:`cec-msg-flags` for a list of available flags. 134 - * - __u8 135 - - ``tx_status`` 136 - - The status bits of the transmitted message. See 137 - :ref:`cec-tx-status` for the possible status values. It is 0 if 138 - this message was received, not transmitted. 139 136 * - __u8 140 137 - ``msg[16]`` 141 138 - The message payload. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` this is filled in by the ··· 163 162 * - __u8 164 163 - ``rx_status`` 165 164 - The status bits of the received message. See 166 - :ref:`cec-rx-status` for the possible status values. It is 0 if 167 - this message was transmitted, not received, unless this is the 168 - reply to a transmitted message. In that case both ``rx_status`` 169 - and ``tx_status`` are set. 165 + :ref:`cec-rx-status` for the possible status values. 170 166 * - __u8 171 167 - ``tx_status`` 172 168 - The status bits of the transmitted message. See 173 - :ref:`cec-tx-status` for the possible status values. It is 0 if 174 - this message was received, not transmitted. 169 + :ref:`cec-tx-status` for the possible status values. 170 + When calling :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` in non-blocking mode, 171 + this field will be 0 if the transmit started, or non-0 if the transmit 172 + result is known immediately. The latter would be the case when attempting 173 + to transmit a Poll message to yourself. That results in a 174 + :ref:`CEC_TX_STATUS_NACK <CEC-TX-STATUS-NACK>` without ever actually 175 + transmitting the Poll message. 175 176 * - __u8 176 177 - ``tx_arb_lost_cnt`` 177 178 - A counter of the number of transmit attempts that resulted in the