Home
last modified time | relevance | path

Searched full:receiving (Results 1 – 25 of 1485) sorted by relevance

12345678910>>...60

/OK3568_Linux_fs/kernel/drivers/net/wireless/intel/iwlwifi/cfg/
H A D22000.c320 * This device doesn't support receiving BlockAck with a large bitmap
332 * This device doesn't support receiving BlockAck with a large bitmap
382 * This device doesn't support receiving BlockAck with a large bitmap
395 * This device doesn't support receiving BlockAck with a large bitmap
408 * This device doesn't support receiving BlockAck with a large bitmap
420 * This device doesn't support receiving BlockAck with a large bitmap
433 * This device doesn't support receiving BlockAck with a large bitmap
446 * This device doesn't support receiving BlockAck with a large bitmap
458 * This device doesn't support receiving BlockAck with a large bitmap
472 * This device doesn't support receiving BlockAck with a large bitmap
[all …]
/OK3568_Linux_fs/kernel/Documentation/networking/device_drivers/ethernet/ti/
H A Dcpsw.rst280 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 …]
/OK3568_Linux_fs/kernel/Documentation/virt/kvm/
H A Dvcpu-requests.rst169 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
/OK3568_Linux_fs/kernel/drivers/staging/pi433/Documentation/
H A Dpi433.txt44 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
/OK3568_Linux_fs/kernel/include/linux/
H A Ddccp.h32 * 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)
/OK3568_Linux_fs/kernel/drivers/crypto/rockchip/
H A Drk_crypto_v1_reg.h56 /* Block Receiving DMA Start Address Register */
60 /* Block Receiving DMA Length Register */
62 /* Hash Receiving DMA Start Address Register */
64 /* Hash Receiving DMA Length Register */
H A Drk3288_crypto.h65 /* 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 */
/OK3568_Linux_fs/kernel/drivers/block/drbd/
H A Ddrbd_protocol.h69 * 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
/OK3568_Linux_fs/kernel/drivers/net/wireguard/
H A Dreceive.c112 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()
259 if (unlikely(!READ_ONCE(keypair->receiving.is_valid) || in decrypt_packet()
260 wg_birthdate_has_expired(keypair->receiving.birthdate, REJECT_AFTER_TIME) || in decrypt_packet()
262 WRITE_ONCE(keypair->receiving.is_valid, false); in decrypt_packet()
287 keypair->receiving.key)) in decrypt_packet()
366 net_dbg_ratelimited("%s: Receiving keepalive packet from peer %llu (%pISpfsc)\n", in wg_packet_consume_data_done()
/OK3568_Linux_fs/kernel/drivers/net/wireless/intel/iwlegacy/
H A Dprph.h283 * 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
/OK3568_Linux_fs/kernel/drivers/net/can/cc770/
H A Dcc770.h154 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 */
/OK3568_Linux_fs/buildroot/dl/qt5location/git/src/plugins/position/geoclue2/
H A Dorg.freedesktop.GeoClue2.Client.xml84 org.freedesktop.GeoClue2.Client.Start() and receiving location updates.
95 Start receiving events about the current location. Applications should
104 Stop receiving events about the current location.
/OK3568_Linux_fs/prebuilts/gcc/linux-x86/arm/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/bits/
H A Dfcntl-linux.h179 # define F_SETOWN __F_SETOWN /* Get owner (process receiving SIGIO). */
180 # define F_GETOWN __F_GETOWN /* Set owner (process receiving SIGIO). */
188 # define __F_SETOWN_EX 15 /* Get owner (thread receiving SIGIO). */
189 # define __F_GETOWN_EX 16 /* Set owner (thread receiving SIGIO). */
195 # define F_SETOWN_EX __F_SETOWN_EX /* Get owner (thread receiving SIGIO). */
196 # define F_GETOWN_EX __F_GETOWN_EX /* Set owner (thread receiving SIGIO). */
/OK3568_Linux_fs/prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/usr/include/bits/
H A Dfcntl-linux.h179 # define F_SETOWN __F_SETOWN /* Get owner (process receiving SIGIO). */
180 # define F_GETOWN __F_GETOWN /* Set owner (process receiving SIGIO). */
188 # define __F_SETOWN_EX 15 /* Get owner (thread receiving SIGIO). */
189 # define __F_GETOWN_EX 16 /* Set owner (thread receiving SIGIO). */
195 # define F_SETOWN_EX __F_SETOWN_EX /* Get owner (thread receiving SIGIO). */
196 # define F_GETOWN_EX __F_GETOWN_EX /* Set owner (thread receiving SIGIO). */
/OK3568_Linux_fs/kernel/drivers/virt/
H A DKconfig29 receiving the shutdown doorbell from a manager partition.
31 4) A kernel interface for receiving callbacks when a managed
/OK3568_Linux_fs/kernel/Documentation/userspace-api/media/rc/
H A Dlirc-get-features.rst58 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.
H A Dlirc-dev-intro.rst49 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.
/OK3568_Linux_fs/kernel/Documentation/devicetree/bindings/serial/
H A Dnvidia,tegra194-tcu.txt6 for transmitting and one for receiving, that is used to communicate
16 "rx" - Mailbox for receiving data from hardware UART
/OK3568_Linux_fs/kernel/Documentation/userspace-api/media/v4l/
H A Dvidioc-g-tuner.rst127 - 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
/OK3568_Linux_fs/kernel/drivers/gpu/drm/nouveau/nvkm/falcon/
H A Dqmgr.h15 * corresponding message can be matched. Upon receiving the message, a callback
20 * @callback: callback to call upon receiving matching message
/OK3568_Linux_fs/kernel/drivers/hwtracing/stm/
H A DKconfig24 The receiving side only needs to be able to decode the MIPI
39 The receiving side must be able to decode this protocol in
/OK3568_Linux_fs/kernel/drivers/char/ipmi/
H A Dkcs_bmc.h15 * BMC is receiving a WRITE_START command from system software.
17 * BMC is receiving a data byte from system software.
/OK3568_Linux_fs/kernel/drivers/clk/qcom/
H A Dgdsc.h25 * @en_rest_wait_val: transition delay value for receiving enr ack signal
26 * @en_few_wait_val: transition delay value for receiving enf ack signal
/OK3568_Linux_fs/kernel/drivers/staging/media/tegra-video/
H A Dvi.h129 * 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
/OK3568_Linux_fs/kernel/Documentation/networking/
H A Dgtp.rst110 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

12345678910>>...60