Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 9eed2867 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 

* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [DCCP]: Update documentation references.
  [ATM] horizon: read_bia() needs to be __devinit
  [NETFILTER]: Fix ip6_tables extension header bypass bug
  [NETFILTER]: Fix ip6_tables protocol bypass bug
  [XFRM]: Fix xfrm_state accounting
  [IPV4] ipconfig: fix RARP ic_servaddr breakage
parents 2099c99e 0e64e94e

drivers/atm/horizon.c

+1 −1
Original line number Diff line number Diff line
@@ -1789,7 +1789,7 @@ static inline void CLOCK_IT (const hrz_dev *dev, u32 ctrl) 
	WRITE_IT_WAIT(dev, ctrl | SEEPROM_SK);

}



static u16 __init read_bia (const hrz_dev * dev, u16 addr)

static u16 __devinit read_bia (const hrz_dev * dev, u16 addr)

{

  u32 ctrl = rd_regl (dev, CONTROL_0_REG);

net/dccp/Kconfig

+3 −3
Original line number Diff line number Diff line
@@ -4,15 +4,15 @@ menu "DCCP Configuration (EXPERIMENTAL)" 
config IP_DCCP

	tristate "The DCCP Protocol (EXPERIMENTAL)"

	---help---

	  Datagram Congestion Control Protocol

	  Datagram Congestion Control Protocol (RFC 4340)



	  From draft-ietf-dccp-spec-11 <http://www.icir.org/kohler/dcp/draft-ietf-dccp-spec-11.txt>.

	  From http://www.ietf.org/rfc/rfc4340.txt:



	  The Datagram Congestion Control Protocol (DCCP) is a transport

	  protocol that implements bidirectional, unicast connections of

	  congestion-controlled, unreliable datagrams. It should be suitable

	  for use by applications such as streaming media, Internet telephony,

	  and on-line games

	  and on-line games.



	  To compile this protocol support as a module, choose M here: the

	  module will be called dccp.

net/dccp/ackvec.c

+6 −6
Original line number Diff line number Diff line
@@ -113,7 +113,7 @@ int dccp_insert_option_ackvec(struct sock *sk, struct sk_buff *skb) 


	memcpy(to, from, len);

	/*

	 *	From draft-ietf-dccp-spec-11.txt:

	 *	From RFC 4340, A.2:

	 *

	 *	For each acknowledgement it sends, the HC-Receiver will add an

	 *	acknowledgement record.  ack_seqno will equal the HC-Receiver
@@ -224,7 +224,7 @@ static inline int dccp_ackvec_set_buf_head_state(struct dccp_ackvec *av, 
}



/*

 * Implements the draft-ietf-dccp-spec-11.txt Appendix A

 * Implements the RFC 4340, Appendix A

 */

int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk,

		    const u64 ackno, const u8 state)
@@ -237,7 +237,7 @@ int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk, 
	 * We may well decide to do buffer compression, etc, but for now lets

	 * just drop.

	 *

	 * From Appendix A:

	 * From Appendix A.1.1 (`New Packets'):

	 *

	 *	Of course, the circular buffer may overflow, either when the

	 *	HC-Sender is sending data at a very high rate, when the
@@ -274,9 +274,9 @@ int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk, 
		/*

		 * A.1.2.  Old Packets

		 *

		 *	When a packet with Sequence Number S arrives, and

		 *	S <= buf_ackno, the HC-Receiver will scan the table

		 *	for the byte corresponding to S. (Indexing structures

		 *	When a packet with Sequence Number S <= buf_ackno

		 *	arrives, the HC-Receiver will scan the table for

		 *	the byte corresponding to S. (Indexing structures

		 *	could reduce the complexity of this scan.)

		 */

		u64 delta = dccp_delta_seqno(ackno, av->dccpav_buf_ackno);

net/dccp/ackvec.h

+1 −2
Original line number Diff line number Diff line
@@ -28,8 +28,7 @@ 


/** struct dccp_ackvec - ack vector

 *

 * This data structure is the one defined in the DCCP draft

 * Appendix A.

 * This data structure is the one defined in RFC 4340, Appendix A.

 *

 * @dccpav_buf_head - circular buffer head

 * @dccpav_buf_tail - circular buffer tail

net/dccp/ccids/Kconfig

+8 −9
Original line number Diff line number Diff line
@@ -22,11 +22,11 @@ config IP_DCCP_CCID2 
	  for lost packets, would prefer CCID 2 to CCID 3.  On-line games may

	  also prefer CCID 2.



	  CCID 2 is further described in:

	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid2-10.txt

	  CCID 2 is further described in RFC 4341,

	  http://www.ietf.org/rfc/rfc4341.txt



	  This text was extracted from:

	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt

	  This text was extracted from RFC 4340 (sec. 10.1),

	  http://www.ietf.org/rfc/rfc4340.txt



	  If in doubt, say M.
@@ -53,15 +53,14 @@ config IP_DCCP_CCID3 
	  suitable than CCID 2 for applications such streaming media where a

	  relatively smooth sending rate is of importance.



	  CCID 3 is further described in:



	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid3-11.txt.

	  CCID 3 is further described in RFC 4342,

	  http://www.ietf.org/rfc/rfc4342.txt



	  The TFRC congestion control algorithms were initially described in

	  RFC 3448.



	  This text was extracted from:

	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt

	  This text was extracted from RFC 4340 (sec. 10.2),

	  http://www.ietf.org/rfc/rfc4340.txt

	  

	  If in doubt, say M.