linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Greg KH <greg@kroah.com>, David Miller <davem@davemloft.net>,
	Networking <netdev@vger.kernel.org>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jarod Wilson <jarod@redhat.com>,
	Erik Arfvidson <erik.arfvidson@unisys.com>,
	David Kershner <david.kershner@unisys.com>
Subject: linux-next: manual merge of the staging tree with the net-next tree
Date: Thu, 24 Nov 2016 14:42:38 +1100	[thread overview]
Message-ID: <20161124144238.7dce65bf@canb.auug.org.au> (raw)

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/unisys/include/iochannel.h

between commit:

  d0c2c9973ecd ("net: use core MTU range checking in virt drivers")

from the net-next tree and commit:

  b18f9c676f93 ("staging: unisys: include: fix pound defines")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/unisys/include/iochannel.h
index 9081b3f8779c,c43da782f37e..000000000000
--- a/drivers/staging/unisys/include/iochannel.h
+++ b/drivers/staging/unisys/include/iochannel.h
@@@ -113,10 -117,12 +117,10 @@@ enum net_types 
  
  };
  
- #define		ETH_MIN_DATA_SIZE 46	/* minimum eth data size */
- #define		ETH_MIN_PACKET_SIZE (ETH_HLEN + ETH_MIN_DATA_SIZE)
 -#define ETH_HEADER_SIZE 14	/* size of ethernet header */
 -
+ #define ETH_MIN_DATA_SIZE 46	/* minimum eth data size */
 -#define ETH_MIN_PACKET_SIZE (ETH_HEADER_SIZE + ETH_MIN_DATA_SIZE)
++#define ETH_MIN_PACKET_SIZE (ETH_HLEN + ETH_MIN_DATA_SIZE)
  
- #define		VISOR_ETH_MAX_MTU 16384	/* maximum data size */
 -#define ETH_MAX_MTU 16384	/* maximum data size */
++#define VISOR_ETH_MAX_MTU 16384	/* maximum data size */
  
  #ifndef MAX_MACADDR_LEN
  #define MAX_MACADDR_LEN 6	/* number of bytes in MAC address */
@@@ -286,9 -304,9 +302,9 @@@ struct net_pkt_xmt 
  	int len;	/* full length of data in the packet */
  	int num_frags;	/* number of fragments in frags containing data */
  	struct phys_info frags[MAX_PHYS_INFO];	/* physical page information */
 -	char ethhdr[ETH_HEADER_SIZE];	/* the ethernet header  */
 +	char ethhdr[ETH_HLEN];	/* the ethernet header  */
  	struct {
- 		/* these are needed for csum at uisnic end */
+ 		/* These are needed for csum at uisnic end */
  		u8 valid;	/* 1 = struct is valid - else ignore */
  		u8 hrawoffv;	/* 1 = hwrafoff is valid */
  		u8 nhrawoffv;	/* 1 = nhwrafoff is valid */
@@@ -321,29 -341,41 +339,41 @@@ struct net_pkt_xmtdone 
   */
  #define RCVPOST_BUF_SIZE 4032
  #define MAX_NET_RCV_CHAIN \
 -	((ETH_MAX_MTU + ETH_HEADER_SIZE + RCVPOST_BUF_SIZE - 1) \
 +	((VISOR_ETH_MAX_MTU + ETH_HLEN + RCVPOST_BUF_SIZE - 1) \
  	/ RCVPOST_BUF_SIZE)
  
+ /*
+  * rcv buf size must be large enough to include ethernet data len + ethernet
+  * header len - we are choosing 2K because it is guaranteed to be describable.
+  */
  struct net_pkt_rcvpost {
- 	    /* rcv buf size must be large enough to include ethernet data len +
- 	     * ethernet header len - we are choosing 2K because it is guaranteed
- 	     * to be describable
- 	     */
- 	    struct phys_info frag;	/* physical page information for the */
- 					/* single fragment 2K rcv buf */
- 	    u64 unique_num;
- 	    /* unique_num ensure that receive posts are returned to */
- 	    /* the Adapter which we sent them originally. */
+ 	/* Physical page information for the single fragment 2K rcv buf */
+ 	struct phys_info frag;
+ 
+ 	/*
+ 	 * Ensures that receive posts are returned to the adapter which we sent
+ 	 * them from originally.
+ 	 */
+ 	u64 unique_num;
+ 
  } __packed;
  
+ /*
+  * The number of rcvbuf that can be chained is based on max mtu and size of each
+  * rcvbuf.
+  */
  struct net_pkt_rcv {
- 	/* the number of receive buffers that can be chained  */
- 	/* is based on max mtu and size of each rcv buf */
- 	u32 rcv_done_len;	/* length of received data */
- 	u8 numrcvbufs;		/* number of receive buffers that contain the */
- 	/* incoming data; guest end MUST chain these together. */
- 	void *rcvbuf[MAX_NET_RCV_CHAIN];	/* list of chained rcvbufs */
- 	/* each entry is a receive buffer provided by NET_RCV_POST. */
+ 	u32 rcv_done_len; /* length of received data */
+ 
+ 	/*
+ 	 * numrcvbufs: contain the incoming data; guest side MUST chain these
+ 	 * together.
+ 	 */
+ 	u8 numrcvbufs;
+ 
+ 	void *rcvbuf[MAX_NET_RCV_CHAIN]; /* list of chained rcvbufs */
+ 
+ 	/* Each entry is a receive buffer provided by NET_RCV_POST. */
  	/* NOTE: first rcvbuf in the chain will also be provided in net.buf. */
  	u64 unique_num;
  	u32 rcvs_dropped_delta;

             reply	other threads:[~2016-11-24  3:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-24  3:42 Stephen Rothwell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-10-23  3:47 linux-next: manual merge of the staging tree with the net-next tree Stephen Rothwell
2023-10-23  7:27 ` Greg KH
2021-08-02 23:33 Mark Brown
2021-08-03  8:57 ` Phillip Potter
2021-08-03  9:23   ` Arnd Bergmann
2021-08-09  7:55     ` Stephen Rothwell
2021-08-09 12:46       ` Phillip Potter
2021-08-09 20:00         ` Arnd Bergmann
2021-08-09 21:45           ` Phillip Potter
2019-02-28  4:52 Stephen Rothwell
2019-02-28  7:04 ` Greg KH
2018-03-15  7:35 Stephen Rothwell
2016-12-07  4:04 Stephen Rothwell
2016-12-07  7:02 ` Greg KH
2016-10-21  1:21 Stephen Rothwell
2014-07-16  6:43 Stephen Rothwell
2014-07-16 20:52 ` Greg KH
2014-05-28  8:28 Stephen Rothwell
2014-05-28 15:49 ` Greg KH
2014-03-27  5:09 Stephen Rothwell
2014-03-27 19:14 ` Eric W. Biederman
2014-03-17  8:08 Stephen Rothwell
2014-03-17 18:30 ` Greg KH
2013-05-29  4:14 Stephen Rothwell
2013-05-29  8:03 ` Greg KH
2013-01-23  4:45 Stephen Rothwell
2013-01-23  4:52 ` Greg KH
2011-10-25  8:26 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161124144238.7dce65bf@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=davem@davemloft.net \
    --cc=david.kershner@unisys.com \
    --cc=erik.arfvidson@unisys.com \
    --cc=greg@kroah.com \
    --cc=jarod@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).