/linux/Documentation/ABI/testing/ |
H A D | debugfs-scmi-raw | 13 (receiving an EOF at each message boundary). 31 (receiving an EOF at each message boundary). 47 (receiving an EOF at each message boundary). 67 (receiving an EOF at each message boundary). 77 Each read gives back one message at time (receiving an EOF at 88 Each read gives back one message at time (receiving an EOF at 118 (receiving an EOF at each message boundary). 145 (receiving an EOF at each message boundary). 171 (receiving an EOF at each message boundary). 200 (receiving an EOF at each message boundary).
|
/linux/Documentation/devicetree/bindings/serial/ |
H A D | nvidia,tegra194-tcu.yaml | 17 for transmitting and one for receiving, that is used to communicate 39 List of phandles to mailbox channels used for receiving and 42 - description: mailbox for receiving data from hardware UART
|
/linux/Documentation/virt/kvm/ |
H A 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
|
/linux/drivers/net/ethernet/google/gve/ |
H A D | gve_dqo.h | 23 /* Timeout in seconds to wait for a reinjection completion after receiving 29 * prematurely freed for not receiving a valid completion. This should be large 30 * enough to rule out the possibility of receiving the corresponding valid
|
/linux/drivers/media/platform/renesas/rzg2l-cru/ |
H A D | Kconfig | 20 tristate "RZ/G2L Camera Receiving Unit (CRU) Driver" 29 Support for Renesas RZ/G2L (and alike SoC's) Camera Receiving
|
/linux/drivers/block/drbd/ |
H A 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 333 * which may be translated to several bio on the receiving side. 346 * Receiving side uses "blkdev_issue_discard()", no need to communicate
|
/linux/Documentation/devicetree/bindings/sound/ |
H A D | rockchip,rk3576-sai.yaml | 76 rockchip,sai-rx-route = <3> would mean sdi3 is receiving from data0, and 77 that there is only one receiving lane. 78 This property's absence is to be understood as only one receiving lane
|
/linux/drivers/net/wireguard/ |
H A D | receive.c | 105 net_dbg_skb_ratelimited("%s: Receiving cookie response from %pISpfsc\n", in wg_receive_handshake_packet() 151 net_dbg_ratelimited("%s: Receiving handshake initiation from peer %llu (%pISpfsc)\n", in wg_receive_handshake_packet() 173 net_dbg_ratelimited("%s: Receiving handshake response from peer %llu (%pISpfsc)\n", in wg_receive_handshake_packet() 252 if (unlikely(!READ_ONCE(keypair->receiving.is_valid) || in decrypt_packet() 253 wg_birthdate_has_expired(keypair->receiving.birthdate, REJECT_AFTER_TIME) || in decrypt_packet() 255 WRITE_ONCE(keypair->receiving.is_valid, false); in decrypt_packet() 280 keypair->receiving.key)) in decrypt_packet() 359 net_dbg_ratelimited("%s: Receiving keepalive packet from peer %llu (%pISpfsc)\n", in wg_packet_consume_data_done()
|
/linux/drivers/net/can/cc770/ |
H A 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/Documentation/userspace-api/media/rc/ |
H A 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 161 :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>` can only be used for receiving.
|
H A 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/drivers/virt/ |
H A D | Kconfig | 39 receiving the shutdown doorbell from a manager partition. 41 4) A kernel interface for receiving callbacks when a managed
|
/linux/drivers/net/wireless/intel/iwlegacy/ |
H A 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/drivers/crypto/rockchip/ |
H A D | rk3288_crypto.h | 67 /* Block Receiving DMA Start Address Register */ 71 /* Block Receiving DMA Length Register */ 73 /* Hash Receiving DMA Start Address Register */ 75 /* Hash Receiving DMA Length Register */
|
/linux/drivers/gpu/drm/nouveau/nvkm/falcon/ |
H A 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/drivers/hwtracing/stm/ |
H A D | Kconfig | 23 The receiving side only needs to be able to decode the MIPI 38 The receiving side must be able to decode this protocol in
|
/linux/Documentation/devicetree/bindings/arm/tegra/ |
H A D | nvidia,tegra234-cbb.yaml | 28 and prints debug information about failed transaction on receiving 31 Security Group etc on receiving error notification.
|
/linux/tools/testing/selftests/net/ |
H A D | broadcast_ether_dst.sh | 44 # tcpdump will exit after receiving a single packet 55 # wait for tcpdump for exit after receiving packet
|
/linux/Documentation/userspace-api/media/v4l/ |
H A 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
|
H A 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/drivers/gpu/drm/sprd/ |
H A D | sprd_dsi.h | 108 /* enable receiving frame ack packets - for video mode */ 110 /* enable receiving tear effect ack packets - for cmd mode */
|
/linux/Documentation/admin-guide/media/ |
H A D | starfive_camss.rst | 42 - MIPI: The MIPI interface, receiving data from a MIPI CSI-2 camera sensor. 44 - Parallel: The parallel interface, receiving data from a parallel sensor.
|
/linux/Documentation/networking/ |
H A 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/drivers/staging/rtl8723bs/include/ |
H A D | wifi.h | 424 …P2P_STATE_RECV_INVITE_REQ_MATCH = 12, /* receiving the P2P Invitation request and match with the… 428 P2P_STATE_RX_INVITE_RESP_OK = 16, /* Receiving the P2P Invitation response */ 429 …P2P_STATE_RECV_INVITE_REQ_DISMATCH = 17, /* receiving the P2P Invitation request and mismatch wit… 430 …P2P_STATE_RECV_INVITE_REQ_GO = 18, /* receiving the P2P Invitation request and this wifi is GO.… 431 …P2P_STATE_RECV_INVITE_REQ_JOIN = 19, /* receiving the P2P Invitation request to join an existin… 433 …P2P_STATE_RX_INFOR_NOREADY = 21, /* receiving p2p negotiation response with information is not …
|
/linux/Documentation/driver-api/ |
H A D | sync_file.rst | 40 userspace we call these fence(s) 'in-fences'. Receiving in-fences means that 68 Receiving Sync Files from Userspace
|