Searched full:receiving (Results 1 – 25 of 913) sorted by relevance
12345678910>>...37
| /Linux-v5.10/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.10/drivers/net/wireless/intel/iwlwifi/cfg/ |
| D | 22000.c | 317 * This device doesn't support receiving BlockAck with a large bitmap
329 * This device doesn't support receiving BlockAck with a large bitmap
378 * This device doesn't support receiving BlockAck with a large bitmap
392 * This device doesn't support receiving BlockAck with a large bitmap
404 * This device doesn't support receiving BlockAck with a large bitmap
418 * This device doesn't support receiving BlockAck with a large bitmap
430 * This device doesn't support receiving BlockAck with a large bitmap
444 * This device doesn't support receiving BlockAck with a large bitmap
457 * This device doesn't support receiving BlockAck with a large bitmap
470 * This device doesn't support receiving BlockAck with a large bitmap
[all …]
|
| /Linux-v5.10/Documentation/virt/kvm/ |
| D | vcpu-requests.rst | 169 Requesters that want the receiving VCPU to handle new state need to ensure
170 the newly written state is observable to the receiving VCPU thread's CPU
173 request bit. Additionally, on the receiving VCPU thread's side, a
186 When making requests to VCPUs, we want to avoid the receiving VCPU
204 the requesting thread and the receiving VCPU. With the memory barriers we
206 !kvm_request_pending() on its last check and then not receiving an IPI for
258 receiving VCPU, as the final kvm_request_pending() check does for
290 Generally it only makes sense for the receiving VCPU thread to clear a
292 thread and the receiving VCPU thread are executed serially, such as when
296 receiving VCPU thread to handle the request in VCPU RUN. The only current
|
| /Linux-v5.10/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.10/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.10/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.10/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.10/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.10/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.10/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.10/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.10/drivers/crypto/rockchip/ |
| D | rk3288_crypto.h | 65 /* Block Receiving DMA Start Address Register */
69 /* Block Receiving DMA Length Register */
71 /* Hash Receiving DMA Start Address Register */
73 /* Hash Receiving DMA Length Register */
|
| /Linux-v5.10/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.10/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.10/drivers/char/ipmi/ |
| D | kcs_bmc.h | 15 * BMC is receiving a WRITE_START command from system software.
17 * BMC is receiving a data byte from system software.
|
| /Linux-v5.10/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.10/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.10/drivers/staging/media/tegra-video/ |
| D | vi.h | 129 * the hardware. On receiving frame start event, it wakes up
135 * This thread is woken up by kthread_start_capture on receiving
138 * data to the memory. On receiving MW_ACK_DONE event, buffer is
|
| /Linux-v5.10/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.10/drivers/misc/habanalabs/include/common/ |
| D | cpucp_if.h | 85 * Upon receiving the interrupt (#121), CpuCP will read the message from the
105 * After receiving this packet the embedded CPU must NOT issue PCI
111 * After receiving this packet the embedded CPU is allowed to issue PCI
171 * The packet is sent after receiving an interrupt and printing its
|
| /Linux-v5.10/Documentation/driver-api/ |
| D | sync_file.rst | 40 userspace we call these fence(s) 'in-fences'. Receiving in-fences means that
68 Receiving Sync Files from Userspace
|
| /Linux-v5.10/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
|
| /Linux-v5.10/Documentation/bpf/ |
| D | prog_sk_lookup.rst | 23 1. receiving connections on a range of IP addresses, e.g. 192.0.2.0/24, when
26 2. receiving connections on all or a wide range of ports, i.e. an L7 proxy use
|
12345678910>>...37
