Searched full:receiving (Results 1 – 25 of 967) sorted by relevance
12345678910>>...39
| /Linux-v5.15/drivers/net/wireless/intel/iwlwifi/cfg/ |
| D | 22000.c | 395 * This device doesn't support receiving BlockAck with a large bitmap
407 * This device doesn't support receiving BlockAck with a large bitmap
477 * This device doesn't support receiving BlockAck with a large bitmap
490 * This device doesn't support receiving BlockAck with a large bitmap
503 * This device doesn't support receiving BlockAck with a large bitmap
515 * This device doesn't support receiving BlockAck with a large bitmap
528 * This device doesn't support receiving BlockAck with a large bitmap
541 * This device doesn't support receiving BlockAck with a large bitmap
553 * This device doesn't support receiving BlockAck with a large bitmap
567 * This device doesn't support receiving BlockAck with a large bitmap
[all …]
|
| /Linux-v5.15/Documentation/networking/device_drivers/ethernet/ti/ |
| D | cpsw.rst | 280 Receiving data rate: 39012 kbps
281 Receiving data rate: 39012 kbps
282 Receiving data rate: 39012 kbps
283 Receiving data rate: 39012 kbps
284 Receiving data rate: 39012 kbps
285 Receiving data rate: 39012 kbps
286 Receiving data rate: 39012 kbps
287 Receiving data rate: 39012 kbps
288 Receiving data rate: 39012 kbps
289 Receiving data rate: 39012 kbps
[all …]
|
| /Linux-v5.15/Documentation/virt/kvm/ |
| D | vcpu-requests.rst | 171 Requesters that want the receiving VCPU to handle new state need to ensure
172 the newly written state is observable to the receiving VCPU thread's CPU
175 request bit. Additionally, on the receiving VCPU thread's side, a
188 When making requests to VCPUs, we want to avoid the receiving VCPU
206 the requesting thread and the receiving VCPU. With the memory barriers we
208 !kvm_request_pending() on its last check and then not receiving an IPI for
260 receiving VCPU, as the final kvm_request_pending() check does for
292 Generally it only makes sense for the receiving VCPU thread to clear a
294 thread and the receiving VCPU thread are executed serially, such as when
298 receiving VCPU thread to handle the request in VCPU RUN. The only current
|
| /Linux-v5.15/drivers/staging/pi433/Documentation/ |
| D | pi433.txt | 44 As soon as an application sets a request for receiving a telegram, the reception
45 configuration set is written to the rf module and it gets set into receiving mode.
49 As soon as the predefined RSSI level is met, a receiving cycle starts. Similar
69 PI433_IOC_RD_RX_CFG - get the receiving parameters from the driver
70 PI433_IOC_WR_RX_CFG - set the receiving parameters
164 The rx configuration is transferred via struct pi433_rx_cfg, the parameterset for receiving. It is …
261 off and the rf chip is used in raw receiving mode. This may be
|
| /Linux-v5.15/drivers/net/ethernet/google/gve/ |
| D | gve_dqo.h | 22 /* Timeout in seconds to wait for a reinjection completion after receiving
28 * prematurely freed for not receiving a valid completion. This should be large
29 * enough to rule out the possibility of receiving the corresponding valid
|
| /Linux-v5.15/include/linux/ |
| D | dccp.h | 32 * b. Client is asked to perform passive-close, by receiving a CloseReq
43 DCCP_PASSIVE_CLOSE = TCP_CLOSE_WAIT, /* any node receiving a Close */
49 DCCP_PASSIVE_CLOSEREQ, /* clients receiving CloseReq */
158 * @dreq_timestamp_echo: the time of receiving the last @dreq_timestamp_echo
237 * @dccps_timestamp_time - time of receiving latest @dccps_timestamp_echo
250 * @dccps_hc_rx_ccid - CCID used for the receiver (or receiving half-connection)
|
| /Linux-v5.15/drivers/virt/ |
| D | Kconfig | 29 receiving the shutdown doorbell from a manager partition.
31 4) A kernel interface for receiving callbacks when a managed
|
| /Linux-v5.15/Documentation/devicetree/bindings/serial/ |
| D | nvidia,tegra194-tcu.txt | 6 for transmitting and one for receiving, that is used to communicate
16 "rx" - Mailbox for receiving data from hardware UART
|
| /Linux-v5.15/drivers/block/drbd/ |
| D | drbd_protocol.h | 69 * On a receiving side without REQ_WRITE_SAME,
214 * guarantee that discard zeroes data, the receiving side would map discard
229 * If we cannot distinguish between zero-out and discard on the receiving
232 * zero-out on the receiving side. But that would potentially do a full
331 * which may be translated to several bio on the receiving side.
344 * Receiving side uses "blkdev_issue_discard()", no need to communicate
|
| /Linux-v5.15/drivers/net/can/cc770/ |
| D | cc770.h | 154 CC770_OBJ_RX0 = 0, /* for receiving normal messages */
155 CC770_OBJ_RX1, /* for receiving normal messages */
156 CC770_OBJ_RX_RTR0, /* for receiving remote transmission requests */
157 CC770_OBJ_RX_RTR1, /* for receiving remote transmission requests */
|
| /Linux-v5.15/Documentation/devicetree/bindings/media/ |
| D | qcom,msm8996-camss.yaml | 100 Input port for receiving CSI data.
131 Input port for receiving CSI data.
155 Input port for receiving CSI data.
179 Input port for receiving CSI data.
|
| D | qcom,sdm845-camss.yaml | 100 Input port for receiving CSI data.
123 Input port for receiving CSI data.
147 Input port for receiving CSI data.
170 Input port for receiving CSI data.
|
| D | qcom,sdm660-camss.yaml | 106 Input port for receiving CSI data.
130 Input port for receiving CSI data.
154 Input port for receiving CSI data.
178 Input port for receiving CSI data.
|
| /Linux-v5.15/drivers/net/wireguard/ |
| D | receive.c | 112 net_dbg_skb_ratelimited("%s: Receiving cookie response from %pISpfsc\n", in wg_receive_handshake_packet()
158 net_dbg_ratelimited("%s: Receiving handshake initiation from peer %llu (%pISpfsc)\n", in wg_receive_handshake_packet()
180 net_dbg_ratelimited("%s: Receiving handshake response from peer %llu (%pISpfsc)\n", in wg_receive_handshake_packet()
258 if (unlikely(!READ_ONCE(keypair->receiving.is_valid) || in decrypt_packet()
259 wg_birthdate_has_expired(keypair->receiving.birthdate, REJECT_AFTER_TIME) || in decrypt_packet()
261 WRITE_ONCE(keypair->receiving.is_valid, false); in decrypt_packet()
286 keypair->receiving.key)) in decrypt_packet()
365 net_dbg_ratelimited("%s: Receiving keepalive packet from peer %llu (%pISpfsc)\n", in wg_packet_consume_data_done()
|
| /Linux-v5.15/Documentation/userspace-api/media/rc/ |
| D | lirc-get-features.rst | 58 This is raw IR driver for receiving. This means that
74 This is a scancode driver for receiving. This means that
179 :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>` can only be used for receiving.
|
| D | lirc-dev-intro.rst | 49 LIRC supports some modes of receiving and sending IR codes, as shown
58 This mode is for both sending and receiving IR.
65 For receiving, you read struct lirc_scancode from the LIRC device.
|
| /Linux-v5.15/drivers/net/wireless/intel/iwlegacy/ |
| D | prph.h | 283 * and whether it's been acknowledged by the receiving station. The device
284 * automatically processes block-acks received from the receiving STA,
294 * at a time, until receiving ACK from receiving station, or reaching
312 * After receiving "Alive" response from uCode, driver must initialize
441 * Driver should clear and initialize the following areas after receiving
457 * Driver should clear this entire area (size 0x80) to 0 after receiving
484 * Driver should clear this entire area (size 0x100) to 0 after receiving
505 * Driver should clear this entire area (size 32 bytes) to 0 after receiving
|
| /Linux-v5.15/drivers/crypto/rockchip/ |
| D | rk3288_crypto.h | 66 /* Block Receiving DMA Start Address Register */
70 /* Block Receiving DMA Length Register */
72 /* Hash Receiving DMA Start Address Register */
74 /* Hash Receiving DMA Length Register */
|
| /Linux-v5.15/drivers/gpu/drm/nouveau/nvkm/falcon/ |
| D | qmgr.h | 15 * corresponding message can be matched. Upon receiving the message, a callback
20 * @callback: callback to call upon receiving matching message
|
| /Linux-v5.15/drivers/hwtracing/stm/ |
| D | Kconfig | 24 The receiving side only needs to be able to decode the MIPI
39 The receiving side must be able to decode this protocol in
|
| /Linux-v5.15/Documentation/userspace-api/media/v4l/ |
| D | vidioc-g-tuner.rst | 127 - receiving mono audio
131 - receiving stereo audio and a secondary audio program
135 - receiving mono or stereo audio, the hardware cannot distinguish
139 - receiving bilingual audio
143 - receiving mono, stereo or bilingual audio
|
| D | ext-ctrls-rf-tuner.rst | 44 to receiving party needs. Driver configures filters to fulfill
88 Is synthesizer PLL locked? RF tuner is receiving given frequency
|
| /Linux-v5.15/drivers/net/wireless/intel/iwlwifi/ |
| D | iwl-prph.h | 137 * and whether it's been acknowledged by the receiving station. The device
138 * automatically processes block-acks received from the receiving STA,
148 * at a time, until receiving ACK from receiving station, or reaching
166 * After receiving "Alive" response from uCode, driver must initialize
|
| /Linux-v5.15/Documentation/networking/ |
| D | gtp.rst | 110 GTP-U uses UDP for transporting PDUs. The receiving UDP port is 2151
162 GTP-U uses UDP for transporting PDU's. The receiving UDP port is 2152
179 * when receiving the local entity is defined by the local
199 Therefore, the receiving side identifies tunnels exclusively based on
|
| /Linux-v5.15/Documentation/scsi/ |
| D | cxgb3i.rst | 20 On receiving, Chelsio S3 h/w computes and verifies the Header and
38 On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP
|
12345678910>>...39
