linux-next: manual merge of the staging tree with the net-next tree

linux-next: manual merge of the staging tree with the net-next tree

[Mark Brown]

Hi all,

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

  drivers/staging/r8188eu/include/rtw_android.h
  drivers/staging/r8188eu/os_dep/rtw_android.c

between commit:

  89939e890605 ("staging: rtlwifi: use siocdevprivate")

from the net-next tree and commit:

  2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver")

from the staging tree.

I fixed it up using the net-next version 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.

Re: linux-next: manual merge of the staging tree with the net-next tree

[Phillip Potter]

On Tue, 3 Aug 2021 at 00:33, Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the staging tree got conflicts in:
>
>   drivers/staging/r8188eu/include/rtw_android.h
>   drivers/staging/r8188eu/os_dep/rtw_android.c
>
> between commit:
>
>   89939e890605 ("staging: rtlwifi: use siocdevprivate")
>
> from the net-next tree and commit:
>
>   2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver")
>
> from the staging tree.
>
> I fixed it up using the net-next version 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.

Dear Mark,

Thank you for your e-mail - not sure what is going on here as the
r8188eu files are totally new - the net-next commit is touching files
from a different directory (rtl8188eu) so perhaps it is getting
confused and considering it a rename or similar? Regardless, all
commits for r8188eu subdirectory should come from staging, as it is a
different driver.

Regards,
Phil

Re: linux-next: manual merge of the staging tree with the net-next tree

[Arnd Bergmann]

On Tue, Aug 3, 2021 at 10:57 AM Phillip Potter <phil@philpotter.co.uk> wrote:
> On Tue, 3 Aug 2021 at 00:33, Mark Brown <broonie@kernel.org> wrote:
>
> Thank you for your e-mail - not sure what is going on here as the
> r8188eu files are totally new - the net-next commit is touching files
> from a different directory (rtl8188eu) so perhaps it is getting
> confused and considering it a rename or similar? Regardless, all
> commits for r8188eu subdirectory should come from staging, as it is a
> different driver.

In net-next, the .ndo_do_ioctl() callback behaves differently, as it no
longer gets called from user space. If you have any
SIOCDEVPRIVATE ioctls in the driver, those need to be
moved over to the new .ndo_siocdevprivate callback, while any
nonstandard ioctl commands outside of that range can just be
removed.

       Arnd

Re: linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

Hi all,

On Tue, 3 Aug 2021 11:23:29 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Aug 3, 2021 at 10:57 AM Phillip Potter <phil@philpotter.co.uk> wrote:
> > On Tue, 3 Aug 2021 at 00:33, Mark Brown <broonie@kernel.org> wrote:
> >
> > Thank you for your e-mail - not sure what is going on here as the
> > r8188eu files are totally new - the net-next commit is touching files
> > from a different directory (rtl8188eu) so perhaps it is getting
> > confused and considering it a rename or similar? Regardless, all
> > commits for r8188eu subdirectory should come from staging, as it is a
> > different driver.  
> 
> In net-next, the .ndo_do_ioctl() callback behaves differently, as it no
> longer gets called from user space. If you have any
> SIOCDEVPRIVATE ioctls in the driver, those need to be
> moved over to the new .ndo_siocdevprivate callback, while any
> nonstandard ioctl commands outside of that range can just be
> removed.

So, can that be done in the staging tree as it is, or does Greg need to
merge (part of) the net-next tree?  Or will someone just supply me with
a reasonable merge resolution patch?  Or does Greg reset the staging
tree to 5c872e1d2595 and try again next time?  Or similar for Dave
(revert Arnd's work)?

Currently it is a mess in linux-next and probably will not work even
though it does build.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Phillip Potter]

On Mon, 9 Aug 2021 at 08:55, Stephen Rothwell <sfr@rothwell.id.au> wrote:
>
> Hi all,
>
> On Tue, 3 Aug 2021 11:23:29 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Aug 3, 2021 at 10:57 AM Phillip Potter <phil@philpotter.co.uk> wrote:
> > > On Tue, 3 Aug 2021 at 00:33, Mark Brown <broonie@kernel.org> wrote:
> > >
> > > Thank you for your e-mail - not sure what is going on here as the
> > > r8188eu files are totally new - the net-next commit is touching files
> > > from a different directory (rtl8188eu) so perhaps it is getting
> > > confused and considering it a rename or similar? Regardless, all
> > > commits for r8188eu subdirectory should come from staging, as it is a
> > > different driver.
> >
> > In net-next, the .ndo_do_ioctl() callback behaves differently, as it no
> > longer gets called from user space. If you have any
> > SIOCDEVPRIVATE ioctls in the driver, those need to be
> > moved over to the new .ndo_siocdevprivate callback, while any
> > nonstandard ioctl commands outside of that range can just be
> > removed.
>
> So, can that be done in the staging tree as it is, or does Greg need to
> merge (part of) the net-next tree?  Or will someone just supply me with
> a reasonable merge resolution patch?  Or does Greg reset the staging
> tree to 5c872e1d2595 and try again next time?  Or similar for Dave
> (revert Arnd's work)?
>
> Currently it is a mess in linux-next and probably will not work even
> though it does build.
>
> --
> Cheers,
> Stephen Rothwell

Dear Stephen,

Happy to try and provide a merge resolution patch if that is easier?
Will be this evening UK time though.

Regards,
Phil

Re: linux-next: manual merge of the staging tree with the net-next tree

[Arnd Bergmann]

On Mon, Aug 9, 2021 at 2:48 PM Phillip Potter <phil@philpotter.co.uk> wrote:
> On Mon, 9 Aug 2021 at 08:55, Stephen Rothwell <sfr@rothwell.id.au> wrote:
> > On Tue, 3 Aug 2021 11:23:29 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > So, can that be done in the staging tree as it is, or does Greg need to
> > merge (part of) the net-next tree?  Or will someone just supply me with
> > a reasonable merge resolution patch?  Or does Greg reset the staging
> > tree to 5c872e1d2595 and try again next time?  Or similar for Dave
> > (revert Arnd's work)?
> >
> > Currently it is a mess in linux-next and probably will not work even
> > though it does build.
> >
>
> Happy to try and provide a merge resolution patch if that is easier?
> Will be this evening UK time though.

Most likely there is no user space that actually wants this function at all,
so I think the easiest way would be to remove all of rtw_ioctl in the
staging tree version of this driver.

        Arnd

Re: linux-next: manual merge of the staging tree with the net-next tree

[Phillip Potter]

On Mon, 9 Aug 2021 at 21:00, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Aug 9, 2021 at 2:48 PM Phillip Potter <phil@philpotter.co.uk> wrote:
> > On Mon, 9 Aug 2021 at 08:55, Stephen Rothwell <sfr@rothwell.id.au> wrote:
> > > On Tue, 3 Aug 2021 11:23:29 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > So, can that be done in the staging tree as it is, or does Greg need to
> > > merge (part of) the net-next tree?  Or will someone just supply me with
> > > a reasonable merge resolution patch?  Or does Greg reset the staging
> > > tree to 5c872e1d2595 and try again next time?  Or similar for Dave
> > > (revert Arnd's work)?
> > >
> > > Currently it is a mess in linux-next and probably will not work even
> > > though it does build.
> > >
> >
> > Happy to try and provide a merge resolution patch if that is easier?
> > Will be this evening UK time though.
>
> Most likely there is no user space that actually wants this function at all,
> so I think the easiest way would be to remove all of rtw_ioctl in the
> staging tree version of this driver.
>
>         Arnd

Sounds good. I will put something together to take out rtw_ioctl in
that case, and submit through Greg/linux-staging. Many thanks.

Regards,
Phil

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Mon, Oct 23, 2023 at 02:47:20PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/qlge/qlge_devlink.c
> 
> between commit:
> 
>   3465915e9985 ("staging: qlge: devlink health: use retained error fmsg API")
> 
> from the net-next tree and commit:
> 
>   875be090928d ("staging: qlge: Retire the driver")
> 
> from the staging tree.
> 
> I fixed it up (I just deleted the file) 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.

Wonderful, thanks for deleting the file.

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi all,

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

  drivers/staging/qlge/qlge_devlink.c

between commit:

  3465915e9985 ("staging: qlge: devlink health: use retained error fmsg API")

from the net-next tree and commit:

  875be090928d ("staging: qlge: Retire the driver")

from the staging tree.

I fixed it up (I just deleted the file) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Thu, Feb 28, 2019 at 03:52:01PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/fsl-dpaa2/ethsw/ethsw.c
> 
> between commit:
> 
>   570b68c8ddde ("staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_SET")
> 
> from the net-next tree and commit:
> 
>   11f27765f611 ("staging: fsl-dpaa2: ethsw: Add missing netdevice check")
> 
> from the staging tree.
> 
> I fixed it up (the former is a superset of the latter) 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.

Looks good to me, thanks!

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Hi all,

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

  drivers/staging/fsl-dpaa2/ethsw/ethsw.c

between commit:

  570b68c8ddde ("staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_ATTR_SET")

from the net-next tree and commit:

  11f27765f611 ("staging: fsl-dpaa2: ethsw: Add missing netdevice check")

from the staging tree.

I fixed it up (the former is a superset of the latter) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Hi all,

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

  drivers/staging/irda/net/af_irda.c

between commit:

  9b2c45d479d0 ("net: make getname() functions return length rather than use int* parameter")

from the net-next tree and commit:

  d64c2a76123f ("staging: irda: remove the irda network stack and drivers")

from the staging tree.

I fixed it up (I just removed the file) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Wed, Dec 07, 2016 at 03:04:47PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/slicoss/slicoss.c
> 
> between commit:
> 
>   a52ad514fdf3 ("net: deprecate eth_change_mtu, remove usage")
> 
> from the net-next tree and commit:
> 
>   0af72df267f2 ("staging: slicoss: remove the staging driver")
> 
> from the staging tree.
> 
> I fixed it up (I just removed the file) 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.

Thanks, we did coordinate this :)

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/staging/slicoss/slicoss.c

between commit:

  a52ad514fdf3 ("net: deprecate eth_change_mtu, remove usage")

from the net-next tree and commit:

  0af72df267f2 ("staging: slicoss: remove the staging driver")

from the staging tree.

I fixed it up (I just removed the file) 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

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

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;

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/staging/wlan-ng/p80211netdev.c

between commit:

  9c22b4a34edd ("net: use core MTU range checking in wireless drivers")

from the net-next tree and commit:

  84ad1efa7d2b ("staging: wlan-ng: fix block comment warnings in p80211netdev.c")

from the staging tree.

I fixed it up (the former removed the code updates by the latter, so I
just did that) 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

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Wed, Jul 16, 2014 at 04:43:22PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/cxt1e1/linux.c between commit c835a6773314 ("net: set
> name_assign_type in alloc_netdev()") from the net-next tree and commit
> 14b596c9d80b ("staging: cxt1e1: remove driver") from the staging tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary (no action is required).

That is fine, thanks.

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/cxt1e1/linux.c between commit c835a6773314 ("net: set
name_assign_type in alloc_netdev()") from the net-next tree and commit
14b596c9d80b ("staging: cxt1e1: remove driver") from the staging tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Wed, May 28, 2014 at 06:28:24PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/rtl8821ae/core.c between commit 77be2c54c5bd
> ("mac80211: add vif to flush call") from the net-next tree and commit
> 0cd05ba54a53 ("staging: rtl8821ae: core.c: Remove version specific
> code") from the staging tree.
> 
> I fixed it up (the former is a suberset of the latter for this
> particular conflict) and can carry the fix as necessary (no action is
> required).

Sounds good, thanks.

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/rtl8821ae/core.c between commit 77be2c54c5bd
("mac80211: add vif to flush call") from the net-next tree and commit
0cd05ba54a53 ("staging: rtl8821ae: core.c: Remove version specific
code") from the staging tree.

I fixed it up (the former is a suberset of the latter for this
particular conflict) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Eric W. Biederman]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/wlags49_h2/wl_netdev.c between commit 8d4ade284a41
> ("wlags49_h2: Call dev_kfree/consume_skb_any instead of dev_kfree_skb")
> from the net-next tree and commit fed3ffd8f7ef ("staging: wlags49_h2:
> reindent wl_netdev.c") (and maybe others) from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

That looks like the correct resolution.  Thanks,

Eric

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 10620 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/wlags49_h2/wl_netdev.c between commit 8d4ade284a41
("wlags49_h2: Call dev_kfree/consume_skb_any instead of dev_kfree_skb")
from the net-next tree and commit fed3ffd8f7ef ("staging: wlags49_h2:
reindent wl_netdev.c") (and maybe others) from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/wlags49_h2/wl_netdev.c
index 69bc0a01ae14,77e4be21e44b..000000000000
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@@ -626,103 -605,105 +605,105 @@@ void wl_tx_timeout(struct net_device *d
   *      1 on error
   *
   ******************************************************************************/
- int wl_send( struct wl_private *lp )
+ int wl_send(struct wl_private *lp)
  {
  
-     int                 status;
-     DESC_STRCT          *desc;
-     WVLAN_LFRAME        *txF = NULL;
-     struct list_head    *element;
-     int                 len;
+ 	int status;
+ 	DESC_STRCT *desc;
+ 	WVLAN_LFRAME *txF = NULL;
+ 	struct list_head *element;
+ 	int len;
      /*------------------------------------------------------------------------*/
  
-     if( lp == NULL ) {
-         DBG_ERROR( DbgInfo, "Private adapter struct is NULL\n" );
-         return FALSE;
-     }
-     if( lp->dev == NULL ) {
-         DBG_ERROR( DbgInfo, "net_device struct in wl_private is NULL\n" );
-         return FALSE;
-     }
- 
-     /* Check for the availability of FIDs; if none are available, don't take any
-        frames off the txQ */
-     if( lp->hcfCtx.IFB_RscInd == 0 ) {
-         return FALSE;
-     }
- 
-     /* Reclaim the TxQ Elements and place them back on the free queue */
-     if( !list_empty( &( lp->txQ[0] ))) {
-         element = lp->txQ[0].next;
- 
-         txF = (WVLAN_LFRAME * )list_entry( element, WVLAN_LFRAME, node );
-         if( txF != NULL ) {
-             lp->txF.skb  = txF->frame.skb;
-             lp->txF.port = txF->frame.port;
- 
-             txF->frame.skb  = NULL;
-             txF->frame.port = 0;
- 
-             list_del( &( txF->node ));
-             list_add( element, &( lp->txFree ));
- 
-             lp->txQ_count--;
- 
-             if( lp->txQ_count < TX_Q_LOW_WATER_MARK ) {
-                 if( lp->netif_queue_on == FALSE ) {
-                     DBG_TX( DbgInfo, "Kickstarting Q: %d\n", lp->txQ_count );
-                     netif_wake_queue( lp->dev );
-                     WL_WDS_NETIF_WAKE_QUEUE( lp );
-                     lp->netif_queue_on = TRUE;
-                 }
-             }
-         }
-     }
- 
-     if( lp->txF.skb == NULL ) {
-         return FALSE;
-     }
- 
-     /* If the device has resources (FIDs) available, then Tx the packet */
-     /* Format the TxRequest and send it to the adapter */
-     len = lp->txF.skb->len < ETH_ZLEN ? ETH_ZLEN : lp->txF.skb->len;
- 
-     desc                    = &( lp->desc_tx );
-     desc->buf_addr          = lp->txF.skb->data;
-     desc->BUF_CNT           = len;
-     desc->next_desc_addr    = NULL;
- 
-     status = hcf_send_msg( &( lp->hcfCtx ), desc, lp->txF.port );
- 
-     if( status == HCF_SUCCESS ) {
-         lp->dev->trans_start = jiffies;
- 
-         DBG_TX( DbgInfo, "Transmit...\n" );
- 
-         if( lp->txF.port == HCF_PORT_0 ) {
-             lp->stats.tx_packets++;
-             lp->stats.tx_bytes += lp->txF.skb->len;
-         }
+ 	if (lp == NULL) {
+ 		DBG_ERROR(DbgInfo, "Private adapter struct is NULL\n");
+ 		return FALSE;
+ 	}
+ 	if (lp->dev == NULL) {
+ 		DBG_ERROR(DbgInfo, "net_device struct in wl_private is NULL\n");
+ 		return FALSE;
+ 	}
+ 
+ 	/*
+ 	 * Check for the availability of FIDs; if none are available,
+ 	 * don't take any frames off the txQ
+ 	 */
+ 	if (lp->hcfCtx.IFB_RscInd == 0)
+ 		return FALSE;
+ 
+ 	/* Reclaim the TxQ Elements and place them back on the free queue */
+ 	if (!list_empty(&(lp->txQ[0]))) {
+ 		element = lp->txQ[0].next;
+ 
+ 		txF = (WVLAN_LFRAME *) list_entry(element, WVLAN_LFRAME, node);
+ 		if (txF != NULL) {
+ 			lp->txF.skb = txF->frame.skb;
+ 			lp->txF.port = txF->frame.port;
+ 
+ 			txF->frame.skb = NULL;
+ 			txF->frame.port = 0;
+ 
+ 			list_del(&(txF->node));
+ 			list_add(element, &(lp->txFree));
+ 
+ 			lp->txQ_count--;
+ 
+ 			if (lp->txQ_count < TX_Q_LOW_WATER_MARK) {
+ 				if (lp->netif_queue_on == FALSE) {
+ 					DBG_TX(DbgInfo, "Kickstarting Q: %d\n",
+ 					       lp->txQ_count);
+ 					netif_wake_queue(lp->dev);
+ 					WL_WDS_NETIF_WAKE_QUEUE(lp);
+ 					lp->netif_queue_on = TRUE;
+ 				}
+ 			}
+ 		}
+ 	}
+ 
+ 	if (lp->txF.skb == NULL)
+ 		return FALSE;
+ 
+ 	/* If the device has resources (FIDs) available, then Tx the packet */
+ 	/* Format the TxRequest and send it to the adapter */
+ 	len = lp->txF.skb->len < ETH_ZLEN ? ETH_ZLEN : lp->txF.skb->len;
+ 
+ 	desc = &(lp->desc_tx);
+ 	desc->buf_addr = lp->txF.skb->data;
+ 	desc->BUF_CNT = len;
+ 	desc->next_desc_addr = NULL;
+ 
+ 	status = hcf_send_msg(&(lp->hcfCtx), desc, lp->txF.port);
+ 
+ 	if (status == HCF_SUCCESS) {
+ 		lp->dev->trans_start = jiffies;
+ 
+ 		DBG_TX(DbgInfo, "Transmit...\n");
  
+ 		if (lp->txF.port == HCF_PORT_0) {
+ 			lp->stats.tx_packets++;
+ 			lp->stats.tx_bytes += lp->txF.skb->len;
+ 		}
  #ifdef USE_WDS
-         else
-         {
-             lp->wds_port[(( lp->txF.port >> 8 ) - 1)].stats.tx_packets++;
-             lp->wds_port[(( lp->txF.port >> 8 ) - 1)].stats.tx_bytes += lp->txF.skb->len;
-         }
+ 		else {
+ 			lp->wds_port[((lp->txF.port >> 8) -
+ 				      1)].stats.tx_packets++;
+ 			lp->wds_port[((lp->txF.port >> 8) -
+ 				      1)].stats.tx_bytes += lp->txF.skb->len;
+ 		}
  
- #endif  /* USE_WDS */
+ #endif /* USE_WDS */
  
-         /* Free the skb and perform queue cleanup, as the buffer was
-             transmitted successfully */
-         dev_consume_skb_any( lp->txF.skb );
+ 		/* Free the skb and perform queue cleanup, as the buffer was
+ 		   transmitted successfully */
 -		dev_kfree_skb(lp->txF.skb);
++		dev_consume_skb_any(lp->txF.skb);
  
-         lp->txF.skb = NULL;
-         lp->txF.port = 0;
-     }
+ 		lp->txF.skb = NULL;
+ 		lp->txF.port = 0;
+ 	}
+ 
+ 	return TRUE;
+ }				/* wl_send */
  
-     return TRUE;
- } // wl_send
  /*============================================================================*/
  
  /*******************************************************************************
@@@ -1695,70 -1715,71 +1715,71 @@@ void wl_wds_netif_carrier_off(struct wl
   *      1 on error
   *
   ******************************************************************************/
- int wl_send_dma( struct wl_private *lp, struct sk_buff *skb, int port )
+ int wl_send_dma(struct wl_private *lp, struct sk_buff *skb, int port)
  {
-     int         len;
-     DESC_STRCT *desc = NULL;
-     DESC_STRCT *desc_next = NULL;
+ 	int len;
+ 	DESC_STRCT *desc = NULL;
+ 	DESC_STRCT *desc_next = NULL;
      /*------------------------------------------------------------------------*/
  
-     if( lp == NULL ) {
-         DBG_ERROR( DbgInfo, "Private adapter struct is NULL\n" );
-         return FALSE;
-     }
+ 	if (lp == NULL) {
+ 		DBG_ERROR(DbgInfo, "Private adapter struct is NULL\n");
+ 		return FALSE;
+ 	}
  
-     if( lp->dev == NULL ) {
-         DBG_ERROR( DbgInfo, "net_device struct in wl_private is NULL\n" );
-         return FALSE;
-     }
+ 	if (lp->dev == NULL) {
+ 		DBG_ERROR(DbgInfo, "net_device struct in wl_private is NULL\n");
+ 		return FALSE;
+ 	}
  
-     /* AGAIN, ALL THE QUEUEING DONE HERE IN I/O MODE IS NOT PERFORMED */
+ 	/* AGAIN, ALL THE QUEUEING DONE HERE IN I/O MODE IS NOT PERFORMED */
  
-     if( skb == NULL ) {
-         DBG_WARNING (DbgInfo, "Nothing to send.\n");
-         return FALSE;
-     }
+ 	if (skb == NULL) {
+ 		DBG_WARNING(DbgInfo, "Nothing to send.\n");
+ 		return FALSE;
+ 	}
  
-     len = skb->len;
+ 	len = skb->len;
  
-     /* Get a free descriptor */
-     desc = wl_pci_dma_get_tx_packet( lp );
+ 	/* Get a free descriptor */
+ 	desc = wl_pci_dma_get_tx_packet(lp);
  
-     if( desc == NULL ) {
-         if( lp->netif_queue_on == TRUE ) {
-             netif_stop_queue( lp->dev );
-             WL_WDS_NETIF_STOP_QUEUE( lp );
-             lp->netif_queue_on = FALSE;
+ 	if (desc == NULL) {
+ 		if (lp->netif_queue_on == TRUE) {
+ 			netif_stop_queue(lp->dev);
+ 			WL_WDS_NETIF_STOP_QUEUE(lp);
+ 			lp->netif_queue_on = FALSE;
  
-             dev_kfree_skb_any( skb );
-             return 0;
-         }
-     }
 -			dev_kfree_skb(skb);
++			dev_kfree_skb_any(skb);
+ 			return 0;
+ 		}
+ 	}
+ 
+ 	SET_BUF_CNT(desc, /*HCF_DMA_FD_CNT */ HFS_ADDR_DEST);
+ 	SET_BUF_SIZE(desc, HCF_DMA_TX_BUF1_SIZE);
  
-     SET_BUF_CNT( desc, /*HCF_DMA_FD_CNT*/HFS_ADDR_DEST );
-     SET_BUF_SIZE( desc, HCF_DMA_TX_BUF1_SIZE );
+ 	desc_next = desc->next_desc_addr;
  
-     desc_next = desc->next_desc_addr;
+ 	if (desc_next->buf_addr == NULL) {
+ 		DBG_ERROR(DbgInfo, "DMA descriptor buf_addr is NULL\n");
+ 		return FALSE;
+ 	}
  
-     if( desc_next->buf_addr == NULL ) {
-         DBG_ERROR( DbgInfo, "DMA descriptor buf_addr is NULL\n" );
-         return FALSE;
-     }
+ 	/* Copy the payload into the DMA packet */
+ 	memcpy(desc_next->buf_addr, skb->data, len);
  
-     /* Copy the payload into the DMA packet */
-     memcpy( desc_next->buf_addr, skb->data, len );
+ 	SET_BUF_CNT(desc_next, len);
+ 	SET_BUF_SIZE(desc_next, HCF_MAX_PACKET_SIZE);
  
-     SET_BUF_CNT( desc_next, len );
-     SET_BUF_SIZE( desc_next, HCF_MAX_PACKET_SIZE );
+ 	hcf_dma_tx_put(&(lp->hcfCtx), desc, 0);
  
-     hcf_dma_tx_put( &( lp->hcfCtx ), desc, 0 );
+ 	/* Free the skb and perform queue cleanup, as the buffer was
+ 	   transmitted successfully */
 -	dev_kfree_skb(skb);
++	dev_consume_skb_any(skb);
  
-     /* Free the skb and perform queue cleanup, as the buffer was
-             transmitted successfully */
-     dev_consume_skb_any( skb );
+ 	return TRUE;
+ }				/* wl_send_dma */
  
-     return TRUE;
- } // wl_send_dma
  /*============================================================================*/
  
  /*******************************************************************************

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Mon, Mar 17, 2014 at 07:08:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/wlan-ng/cfg80211.c between commit 3ead0d2e220e ("wlan-ng:
> fixup staging driver for removal of ieee80211_dsss_chan_to_freq") from
> the net-next tree and commit 4e5e9d7c66f0 ("staging: wlan-ng: replace
> function ieee80211_dsss_chan_to_freq()") from the staging tree.
> 
> I fixed it up (I used the staging tree version) and can carry the fix as
> necessary (no action is required).

Thanks, that sounds correct.

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/wlan-ng/cfg80211.c between commit 3ead0d2e220e ("wlan-ng:
fixup staging driver for removal of ieee80211_dsss_chan_to_freq") from
the net-next tree and commit 4e5e9d7c66f0 ("staging: wlan-ng: replace
function ieee80211_dsss_chan_to_freq()") from the staging tree.

I fixed it up (I used the staging tree version) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Wed, May 29, 2013 at 02:14:22PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/silicom/bpctl_mod.c between commit 351638e7deee ("net:
> pass info struct via netdevice notifier") from the net-next tree and
> commit f84b075178b4 ("Staging: silicom: Fixed error 'do not initialise
> statics to 0 or NULL'") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

The fix looks great, thanks.

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/silicom/bpctl_mod.c between commit 351638e7deee ("net:
pass info struct via netdevice notifier") from the net-next tree and
commit f84b075178b4 ("Staging: silicom: Fixed error 'do not initialise
statics to 0 or NULL'") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/silicom/bpctl_mod.c
index c8ddb99,3082ba9..0000000
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@@ -133,8 -133,8 +133,8 @@@ static unsigned long str_to_hex(char *p
  static int bp_device_event(struct notifier_block *unused,
  			   unsigned long event, void *ptr)
  {
 -	struct net_device *dev = ptr;
 +	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
- 	static bpctl_dev_t *pbpctl_dev = NULL, *pbpctl_dev_m = NULL;
+ 	static bpctl_dev_t *pbpctl_dev, *pbpctl_dev_m;
  	int dev_num = 0, ret = 0, ret_d = 0, time_left = 0;
  	/* printk("BP_PROC_SUPPORT event =%d %s %d\n", event,dev->name, dev->ifindex ); */
  	/* return NOTIFY_DONE; */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the net-next tree

[Greg KH]

On Wed, Jan 23, 2013 at 03:45:25PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/et131x/et131x.c between commit f9a8f83b04e0 ("net: phy:
> remove flags argument from phy_{attach, connect, connect_direct}") from
> the net-next tree and commit 26ef1021c1c7 ("staging: et131x: Modify block
> comments to fit with networking style") from the staging tree.
> 
> I fixed it up (the former adjusted the white space in the same was as the
> latter, so I used thet) and can carry the fix as necessary (no action is
> required).

That sounds good to me, thanks.

greg k-h

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/et131x/et131x.c between commit f9a8f83b04e0 ("net: phy:
remove flags argument from phy_{attach, connect, connect_direct}") from
the net-next tree and commit 26ef1021c1c7 ("staging: et131x: Modify block
comments to fit with networking style") from the staging tree.

I fixed it up (the former adjusted the white space in the same was as the
latter, so I used thet) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the staging tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/et131x/et1310_tx.c drivers/staging/et131x/et131x_netdev.c
between commits afc4b13df143 ("net: remove use of ndo_set_multicast_list
in drivers"), bf3f1a6081aa ("et131x: convert to SKB paged frag API") and
5d6bcdfe38ce ("net: use DMA_x_DEVICE and dma_mapping_error with
skb_frag_dma_map") from the net-next tree and commit d2796743cba2
("staging: et131x: Put all .c files into one big file") from the staging
tree.

The latter removed these files, so I did that but more fixup is proably
needed.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]