I left mixed case identifiers for another commit.
arch/arm/src/imxrt/imxrt_lcd.c:142:13: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:143:13: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:147:39: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:157:17: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:162:39: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:173:39: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:184:39: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:195:39: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:208:17: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:210:17: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:212:17: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:214:17: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:514:11: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:514:23: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:514:33: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:519:11: error: Mixed case identifier found
arch/arm/src/imxrt/imxrt_lcd.c:519:23: error: Mixed case identifier found
modify the return value according to posix standard
Change-Id: I6e32a8f7a5cac85fe7a395a8115710fdff61d985
Signed-off-by: dongjiuzhu <dongjiuzhu1@xiaomi.com>
RFC2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
...
3. Fast Retransmit
Modifications to the congestion avoidance algorithm were proposed in
1990 [3]. Before describing the change, realize that TCP may
generate an immediate acknowledgment (a duplicate ACK) when an out-
of-order segment is received (Section 4.2.2.21 of [1], with a note
that one reason for doing so was for the experimental fast-
retransmit algorithm). This duplicate ACK should not be delayed.
The purpose of this duplicate ACK is to let the other end know that a
segment was received out of order, and to tell it what sequence
number is expected.
Since TCP does not know whether a duplicate ACK is caused by a lost
segment or just a reordering of segments, it waits for a small number
of duplicate ACKs to be received. It is assumed that if there is
just a reordering of the segments, there will be only one or two
duplicate ACKs before the reordered segment is processed, which will
then generate a new ACK. If three or more duplicate ACKs are
received in a row, it is a strong indication that a segment has been
lost. TCP then performs a retransmission of what appears to be the
missing segment, without waiting for a retransmission timer to
expire.
Change-Id: Ie2cbcecab507c3d831f74390a6a85e0c5c8e0652
Signed-off-by: chao.an <anchao@xiaomi.com>
Also add custom board build with absolute path support in addtion
to relative path.
Change-Id: I01bcb0b79db9e245484540c714036c64234b3656
Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>
