Home
last modified time | relevance | path

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

/linux-2.4.37.9/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 …]
Dsim710.scr107 CLEAR ACK
397 CLEAR ACK
401 CLEAR ACK
404 CLEAR ACK
407 CLEAR ACK
413 CLEAR ACK
421 CLEAR ACK
428 CLEAR ACK
433 CLEAR ACK
448 CLEAR ACK
[all …]
D53c7,8xx.scr165 CLEAR ACK
202 CLEAR ACK
215 CLEAR ACK
245 ; Release ACK on the IDENTIFY message _after_ we've set the synchronous
247 CLEAR ACK
436 CLEAR ACK
712 ; which clears ACK and returns control, or reply_message
839 CLEAR ACK
850 CLEAR ACK
858 CLEAR ACK
[all …]
D53c7xx.scr203 CLEAR ACK
249 CLEAR ACK
261 CLEAR ACK
275 CLEAR ACK
288 CLEAR ACK
338 ; Release ACK on the IDENTIFY message _after_ we've set the synchronous
340 CLEAR ACK
549 CLEAR ACK
863 ; which clears ACK and returns control, or reply_message
1016 CLEAR ACK
[all …]
DREADME.qlogicfas72 that it gets a false ACK causing an extra byte to be inserted into the
74 termination (the ACK can be reflected), or by noise when the chips
DREADME.AM53C97495 received from the SCSI bus without ACK resp. REQ signal.
/linux-2.4.37.9/drivers/sbus/char/
Dvfc_i2c.h12 #define ACK (0x01000000) macro
24 #define CLEAR_I2C_BUS (PIN | ESO | ACK)
25 #define NEGATIVE_ACK ((ESO) & ~ACK)
Dvfc_i2c.c108 WRITE_S1(ENABLE_SERIAL | SELECT(S0) | ACK); in vfc_init_i2c_bus()
122 WRITE_S1(SEND_I2C_STOP | ACK); in vfc_i2c_reset_bus()
165 WRITE_S1(SEND_I2C_STOP | ACK); in vfc_i2c_xmit_addr()
244 WRITE_S1(ACK); in vfc_i2c_recv_byte()
289 WRITE_S1(SEND_I2C_STOP | ACK); in vfc_i2c_recvbuf()
335 WRITE_S1(SEND_I2C_STOP | ACK); in vfc_i2c_sendbuf()
/linux-2.4.37.9/net/ipx/
Daf_spx.c406 case (ACK): in spx_route_skb()
479 case (ACK): /* ACK */ in spx_transmit()
590 case ACK: /* Check Sequence, Should == 1 */ in spx_retransmit_chk()
679 spx_retransmit_chk(pdata, ipxh->spx.ackseq, ACK); in spx_rcv()
700 spx_retransmit_chk(pdata,pdata->rmt_ack, ACK); in spx_rcv()
705 spx_transmit(sk, NULL, ACK, 0); in spx_rcv()
/linux-2.4.37.9/include/net/
Dspx.h69 #define ACK 1 /* Data ACK */ macro
/linux-2.4.37.9/drivers/usb/gadget/
Dgoku_udc.c1624 #define ACK(irqbit) { \ macro
1675 ACK(INT_SUSPEND); in goku_irq()
1712 ACK(INT_USBRESET); in goku_irq()
1723 ACK(INT_SETUP); in goku_irq()
1728 ACK(INT_STATUSNAK|INT_ENDPOINT0); in goku_irq()
1738 ACK(INT_ENDPOINT0); in goku_irq()
1746 ACK(INT_MSTRDEND); in goku_irq()
1752 ACK(INT_MSTWREND); in goku_irq()
1758 ACK(INT_MSTWRTMOUT); in goku_irq()
1792 #undef ACK
/linux-2.4.37.9/Documentation/networking/
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.txt33 | | | | | | (delayed ACK control data)
DNAPI_HOWTO.txt81 There are two types of event register ACK mechanisms.
662 ACK;
/linux-2.4.37.9/drivers/scsi/aic7xxx/
Daic7xxx.seq1119 * it makes sense that the DMA circuitry doesn't ACK when
1444 * Wait for our ACK to go-away on it's own
1597 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1731 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1761 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1767 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1883 mov NONE,SCSIDATL; /* ACK Identify MSG */
1960 * According to Adaptec's documentation, an ACK is not sent on input from
1966 * we send our ACK.
1976 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
[all …]
Daic79xx.seq861 mov NONE, SCSIDAT; /* ACK Byte */
885 mov NONE,SCSIDAT; /*dummy read from latch to ACK*/
924 mov NONE, SCSIDAT; /* ACK Identify MSG */
1142 mov NONE,SCSIDAT; /*dummy read from latch to ACK*/
1194 * an async phase due to our asserted ACK. Each
1216 * An ACK is not sent on input from the target until SCSIDATL is read from.
1221 * data byte on the bus until we send our ACK.
1228 mov NONE,SCSIDAT; /*dummy read from latch to ACK*/
1245 mov NONE,SCSIDAT ret; /*dummy read from latch to ACK*/
Daic79xx.reg3039 * DSP ACK Control
/linux-2.4.37.9/drivers/scsi/aic7xxx_old/
Daic7xxx.seq798 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
970 mov NONE,SCSIDATL; /* ACK Identify MSG */
1018 mvi ARG_1 call inb_next; /* ACK the wide_residue and get */
1044 * According to Adaptec's documentation, an ACK is not sent on input from
1050 * we send our ACK.
1058 mov NONE,SCSIDATL; /*dummy read from latch to ACK*/
1073 mov NONE,SCSIDATL ret; /*dummy read from latch to ACK*/
1102 * the DMA circuitry doesn't ACK when PHASEMIS is active). If we are
/linux-2.4.37.9/Documentation/arm/SA1100/
DSA1100_USB321 IN-DATA-ACK. I figure netlink may rely on this, and not just a
/linux-2.4.37.9/Documentation/input/
Djoystick-parport.txt521 10 | /ACK | Acknowledge
/linux-2.4.37.9/arch/arm/kernel/
Dentry-armv.S467 streq \tmp, [\base, #AIC_EOICR] @ not going to be handled further, then ACK it now.
/linux-2.4.37.9/drivers/net/wan/
Dfarsync.c368 #define ACK 1 /* Positive acknowledgement to PC driver */ macro