Home
last modified time | relevance | path

Searched refs:ACK (Results 1 – 38 of 38) sorted by relevance

/linux-4.1.27/drivers/scsi/
D53c700.scr181 CLEAR ACK
195 CLEAR ACK
199 CLEAR ACK
208 CLEAR ACK
212 CLEAR ACK
216 CLEAR ACK
220 CLEAR ACK
224 CLEAR ACK
232 CLEAR ACK
240 CLEAR ACK
[all …]
D53c700_d.h_shipped238 CLEAR ACK
267 CLEAR ACK
280 CLEAR ACK
313 CLEAR ACK
326 CLEAR ACK
339 CLEAR ACK
352 CLEAR ACK
365 CLEAR ACK
382 CLEAR ACK
399 CLEAR ACK
[all …]
/linux-4.1.27/Documentation/
Dmd-cluster.txt80 ACK:CR ACK:CR ACK:CR
85 TOKEN:EX ACK:CR ACK:CR
87 ACK:CR
95 sender try to get EX of ACK
98 [ triggered by bast of ACK ]
103 receiver release ACK
108 ACK:EX
110 4. triggered by grant of EX on ACK (indicating all receivers have processed
112 sender down-convert ACK from EX to CR
116 receiver get CR of ACK
[all …]
Dmailbox.txt58 /* An ACK to our last sample sent */
64 /* Remote f/w sends only ACK packets on this channel */
Dstable_kernel_rules.txt96 - The sender will receive an ACK when the patch has been accepted into the
109 - The review committee has 48 hours in which to ACK or NAK the patch.
Dkernel-parameters.txt2552 waiting for the ACK, so if this is set too high
/linux-4.1.27/Documentation/zh_CN/
Dstable_kernel_rules.txt46 - 如果补丁被接受到队列里,发送者会收到一个ACK回复,如果没有被接受,收
56 - 审查委员会有48小时的时间,用来决定给该补丁回复ACK还是NAK。
60 - 在审查周期结束的时候,那些得到ACK回应的补丁将会被加入到最新的稳定版
/linux-4.1.27/Documentation/ja_JP/
Dstable_kernel_rules.txt55 - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
70 - レビュー委員会は 48時間の間に ACK か NAK を出す。
74 - レビューサイクルの最後に、ACK を受けたパッチは最新の -stable リリー
/linux-4.1.27/Documentation/input/
Dwalkera0701.txt26 / O 4 3 O \ pin 3 (GND) LED ________________ 10 ACK
49 Driver use interrupt from parport ACK input bit to measure pulse length
80 (Warning, pulses on ACK are inverted by transistor, irq is raised up on sync
Djoystick-parport.txt530 10 | /ACK | Acknowledge
/linux-4.1.27/Documentation/i2c/
Dslave-interface143 About ACK/NACK
146 It is good behaviour to always ACK the address phase, so the master knows if a
148 state being busy is troublesome. SMBus demands to always ACK the address phase,
150 automatically ACK when detecting their slave addresses, so there is no option
154 Currently, there is no slave event to report if the master did ACK or NACK a
Dfault-codes86 of a transfer didn't get an ACK. While it might just mean
/linux-4.1.27/Documentation/networking/
Drxrpc.txt146 (*) Calls use ACK packets to handle reliability. Data packets are also
150 A hard-ACK indicates to the far side that all the data received to a point
151 has been received and processed; a soft-ACK indicates that the data has
153 not discard any transmittable packets until they've been hard-ACK'd.
155 (*) Reception of a reply data packet implicitly hard-ACK's all the data
159 received and the final hard-ACK on the last packet of the reply has
197 (*) ACK'ing is handled by the protocol driver automatically, including ping
236 the reply is transmitted with one or more sendmsgs, and then the final ACK
322 RXRPC_ACK -rt n/a Final ACK received
349 This is delivered to a server application to indicate that the final ACK
[all …]
DPLIP.txt141 D3->ACK 5 - 10 10 - 5
176 INIT -> ACK 16 - 10
204 That raises the ACK line, triggering an interrupt in the receiving
205 machine. The receiving machine disables interrupts and raises its own ACK
Dproc_net_tcp.txt34 | | | | | | (delayed ACK control data)
Dmac80211-injection.txt29 an ACK even if it is a unicast frame
Dnf_conntrack-sysctl.txt131 received an (acceptable) ACK from the destination. If this number
Dieee802154.txt47 comparation, automagic ACK handling, address matching, etc.
Drds.txt197 ACK and retransmit handling
Dip-sysctl.txt674 Limits number of Challenge ACK sent per second, as recommended
1769 a listening sctp socket to a connecting client in the INIT-ACK chunk.
/linux-4.1.27/arch/mn10300/kernel/
Dsmp-low.S66 movbu d2,(GxICR(FLUSH_CACHE_IPI)) # ACK the interrupt
Dmn10300-serial-low.S71 movbu d2,(e3) # ACK the interrupt
118 movbu d2,(e3) # ACK the interrupt
Dgdb-io-serial-low.S61 movbu d2,(XIRQxICR(GDBPORT_SERIAL_IRQ)) # ACK the interrupt
Dgdb-io-ttysm-low.S57 movbu d2,(GxICR(SCgRXIRQ)) # ACK the interrupt
/linux-4.1.27/drivers/usb/gadget/udc/
Dgoku_udc.c1502 #define ACK(irqbit) { \ macro
1553 ACK(INT_SUSPEND); in goku_irq()
1590 ACK(INT_USBRESET); in goku_irq()
1601 ACK(INT_SETUP); in goku_irq()
1606 ACK(INT_STATUSNAK|INT_ENDPOINT0); in goku_irq()
1616 ACK(INT_ENDPOINT0); in goku_irq()
1624 ACK(INT_MSTRDEND); in goku_irq()
1630 ACK(INT_MSTWREND); in goku_irq()
1636 ACK(INT_MSTWRTMOUT); in goku_irq()
1670 #undef ACK
/linux-4.1.27/drivers/net/wireless/ath/ath9k/
DKconfig98 bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
102 This option enables ath9k dynamic ACK timeout estimation algorithm
103 based on ACK frame RX timestamp, TX frame timestamp and frame
/linux-4.1.27/Documentation/scsi/
Dqlogicfas.txt71 that it gets a false ACK causing an extra byte to be inserted into the
73 termination (the ACK can be reflected), or by noise when the chips
/linux-4.1.27/drivers/media/pci/bt8xx/
Ddst_common.h95 #define ACK 0xff macro
Ddst.c1103 if (reply != ACK) { in dst_get_device_id()
1252 if (reply != ACK) { in dst_command()
1423 if (reply != ACK) { in dst_write_tuna()
/linux-4.1.27/drivers/usb/serial/
Dgarmin_gps.c111 #define ACK 0x06 macro
356 *ptr++ = ACK; in gsp_send_ack()
357 cksum += ACK; in gsp_send_ack()
523 if (data == ACK) { in gsp_receive()
524 ack_or_nak_seen = ACK; in gsp_receive()
/linux-4.1.27/Documentation/spi/
Dbutterfly66 IRQ = J402.PF4 = pin 10/S6,ACK
/linux-4.1.27/Documentation/pps/
Dpps.txt30 Carrier Detect pin) or to a parallel port (ACK-pin) or to a special
212 10 ACK * ------*
/linux-4.1.27/drivers/scsi/aic7xxx/
Daic7xxx.seq1120 * it makes sense that the DMA circuitry doesn't ACK when
1445 * Wait for our ACK to go-away on it's own
1598 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1732 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1762 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1768 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1884 mov NONE,SCSIDATL; /* ACK Identify MSG */
1961 * According to Adaptec's documentation, an ACK is not sent on input from
1967 * we send our ACK.
1977 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
[all …]
Daic79xx.seq1054 mov NONE, SCSIDAT; /* ACK Byte */
1078 mov NONE,SCSIDAT; /*dummy read from latch to ACK*/
1117 mov NONE, SCSIDAT; /* ACK Identify MSG */
1352 mov NONE,SCSIDAT; /*dummy read from latch to ACK*/
1399 * an async phase due to our asserted ACK. Each
1421 * An ACK is not sent on input from the target until SCSIDATL is read from.
1426 * data byte on the bus until we send our ACK.
1433 mov NONE,SCSIDAT; /*dummy read from latch to ACK*/
1450 mov NONE,SCSIDAT ret; /*dummy read from latch to ACK*/
Daic79xx.reg3228 * DSP ACK Control
/linux-4.1.27/drivers/isdn/icn/
Dicn.c721 #warning TODO test headroom or use skb->nb to flag ACK in icn_sendbuf()
/linux-4.1.27/net/ipv4/
DKconfig520 increase the congestion window by when an ACK is received.
/linux-4.1.27/drivers/net/wan/
Dfarsync.c369 #define ACK 1 /* Positive acknowledgement to PC driver */ macro