Searched full:reply (Results 1 – 25 of 107) sorted by relevance
12345
| /Documentation/userspace-api/media/cec/ |
| D | cec-ioc-receive.rst | 55 3. the reply to an earlier non-blocking transmit (the ``sequence`` field will
64 of 2-byte messages). Note that the CEC kernel framework will also reply
71 If a non-blocking transmit also specified waiting for a reply, then
72 the reply will arrive in a later message. The ``sequence`` field can
115 filled in by the driver with the length of the reply message if ``reply`` was set.
122 then it will be replaced by 1000 if the ``reply`` is non-zero or
123 ignored if ``reply`` is 0.
131 In addition, if a non-blocking transmit will wait for a reply (ii.e. ``timeout``
132 was not 0), then the ``sequence`` field of the reply will be set to the sequence
143 the payload of the reply message if ``timeout`` was set.
[all …]
|
| /Documentation/netlink/specs/ |
| D | devlink.yaml | 1245 reply: &get-reply
1253 reply: *get-reply
1269 reply:
1275 reply:
1314 reply:
1372 reply: &sb-get-reply
1378 reply: *sb-get-reply
1395 reply: &sb-pool-get-reply
1401 reply: *sb-pool-get-reply
1437 reply: &sb-port-pool-get-reply
[all …]
|
| D | nfsd.yaml | 135 reply:
167 reply:
187 reply:
204 reply:
221 reply:
|
| D | ethtool.yaml | 22 entries: [ compact-bitsets, omit-reply, stats ]
1157 reply:
1172 reply:
1204 reply:
1240 reply:
1260 reply:
1288 reply:
1317 reply:
1338 reply:
1354 reply:
[all …]
|
| D | netdev.yaml | 512 reply: &dev-all
520 reply: *dev-all
546 reply: &pp-reply
556 reply: *pp-reply
584 reply: &pp-stats-reply
599 reply: *pp-stats-reply
613 reply: &queue-get-op
624 reply: *queue-get-op
633 reply: &napi-get-op
643 reply: *napi-get-op
[all …]
|
| D | team.yaml | 158 # Actually it only reply the team netlink family
159 reply:
175 reply: *option_attrs
188 reply: *option_attrs
201 reply: &port_attrs
|
| D | binder.yaml | 49 name: is-reply
51 doc: When present, indicates the failed transaction is a reply.
85 - is-reply
|
| D | nlctrl.yaml | 180 reply: &all-attrs
191 reply: *all-attrs
203 reply:
|
| D | fou.yaml | 129 reply: *all_attrs
132 reply: *all_attrs
|
| D | dpll.yaml | 417 reply:
434 reply: &dev-attrs
447 reply: *dev-attrs
494 reply:
517 reply: &pin-attrs
541 reply: *pin-attrs
|
| D | nftables.yaml | 173 - reply
1158 reply:
1192 reply:
1236 reply:
1280 reply:
1294 reply:
1338 reply:
1382 reply:
1396 reply:
1430 reply:
[all …]
|
| D | tcp_metrics.yaml | 145 reply: &all_attrs
158 reply: *all_attrs
|
| D | mptcp_pm.yaml | 303 reply:
307 reply:
338 reply:
|
| /Documentation/w1/ |
| D | w1-netlink.rst | 76 command request. One reply is generated exactly for one w1_netlink_cmd
77 read request. Replies are not combined when sent - i.e. typical reply
109 reply::
141 structure) will be 'acked' by the w1 core. Format of the reply is the same
147 If reply is generated for master or root command (which do not have
148 w1_netlink_cmd attached), reply will contain only cn_msg and w1_netlink_msg
157 Status reply is generated for every w1_netlink_cmd embedded in the
159 reply will be generated for the w1_netlink_msg.
176 If command requires reply (like read command) it is sent on command completion.
191 Sequence number for reply is the same as was in request, and
|
| /Documentation/ABI/testing/ |
| D | debugfs-olpc | 11 CC is the (hex) command, N is the count of expected reply bytes, and A A A A
15 a command. Hex reply bytes will be returned, *whether or not* they came from
|
| /Documentation/filesystems/ |
| D | fuse-io.rst | 15 FUSE_OPEN reply.
19 mmap, the FUSE_DIRECT_IO_ALLOW_MMAP flag may be enabled in the FUSE_INIT reply.
28 FUSE_INIT reply.
|
| /Documentation/i2c/ |
| D | i2c-address-translators.rst | 74 keeps clock stretched on bus A waiting for reply
77 - ATR chip stops clock stretching and forwards reply on bus A,
79 - ATR driver receives the reply, rewrites messages with address 0x10
81 - Slave X driver gets back the msgs[], with reply and address 0x10
|
| /Documentation/userspace-api/media/dvb/ |
| D | fe-diseqc-recv-slave-reply.rst | 13 FE_DISEQC_RECV_SLAVE_REPLY - Receives reply from a DiSEqC 2.0 command
34 Receives reply from a DiSEqC 2.0 command.
|
| D | frontend_fcalls.rst | 19 fe-diseqc-recv-slave-reply
|
| /Documentation/networking/device_drivers/can/ |
| D | can327.rst | 170 Once a frame has been sent and wait-for-reply mode is on (``ATR1``,
171 configured on ``listen-only=off``), or when the reply timeout expires
211 "receive reply" mode, in which it *does* ACK any received frames.
213 or the receive reply timeout runs out, the ELM327 will end reply
238 However, they do send ACKs while waiting for a reply immediately
282 The ELM327 will reply with OK when a command is understood, and with ?
|
| /Documentation/userspace-api/netlink/ |
| D | genetlink-legacy.rst | 144 ``reply`` sections of the operations (if an operation has both ``do``
147 only allocates a ``reply`` (i.e. a "from-kernel" ID). Let's look
158 reply:
291 on how the parsing should be implemented (parse into a single reply
|
| /Documentation/core-api/ |
| D | netlink.rst | 33 Older families do not reply to all of the commands, especially NEW / ADD
39 Specifically NEW and ADD commands should reply with information identifying
|
| /Documentation/networking/ |
| D | rxrpc.rst | 61 receives a blob (the reply), and the server receives the request and then
62 transmits the reply.
127 which the service receives; then the service transmits the reply data
155 (#) Reception of a reply data packet implicitly hard-ACK's all the data
158 (#) An call is complete when the request has been sent, the reply has been
159 received and the final hard-ACK on the last packet of the reply has
212 followed by the reply being received with one or more recvmsgs.
235 the reply is transmitted with one or more sendmsgs, and then the final ACK
615 (6) The reply data will then be posted to the server socket for recvmsg() to
616 pick up. MSG_MORE will be flagged by recvmsg() if there's more reply data
[all …]
|
| D | ethtool-netlink.rst | 53 Each request or reply message contains a nested attribute with common header.
75 ``ETHTOOL_FLAG_COMPACT_BITSETS`` use compact format bitsets in reply
76 ``ETHTOOL_FLAG_OMIT_REPLY`` omit optional reply (_SET and _ACT)
103 request) or at least a second request (when the bitset is in a reply). This is
171 In requests, application can use either form. Form used by kernel in reply is
186 ``_GET_REPLY`` kernel reply to a ``GET`` request
187 ``_SET_REPLY`` kernel reply to a ``SET`` request
188 ``_ACT_REPLY`` kernel reply to an ``ACT`` request
255 ``ETHTOOL_MSG_FEATURES_SET_REPLY`` optional reply to FEATURES_SET
312 ``ETHTOOL_FLAG_OMIT_REPLY`` flag in request header), the reply takes form of
[all …]
|
| /Documentation/admin-guide/blockdev/ |
| D | nbd.rst | 11 request over TCP to the server, which will reply with the data read.
|
12345