linux-next: manual merge of the staging tree with the staging.current tree

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/industrialio-event.c between commit cadc2125e140 ("iio: fix:
Keep a reference to the IIO device for open file descriptors") from the
staging.current tree and commit a646fbf0fd11 ("iio: use anon_inode_getfd
() with O_CLOEXEC flag") 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/iio/industrialio-event.c
index 6be65ef,2390e3d..0000000
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@@ -163,10 -158,8 +163,10 @@@ int iio_event_getfd(struct iio_dev *ind
  		return -EBUSY;
  	}
  	spin_unlock_irq(&ev_int->wait.lock);
 -	fd = anon_inode_getfd("iio:event",
 -				&iio_event_chrdev_fileops, ev_int, O_RDONLY | O_CLOEXEC);
 +	iio_device_get(indio_dev);
 +
 +	fd = anon_inode_getfd("iio:event", &iio_event_chrdev_fileops,
- 				indio_dev, O_RDONLY);
++				indio_dev, O_RDONLY | O_CLOEXEC);
  	if (fd < 0) {
  		spin_lock_irq(&ev_int->wait.lock);
  		__clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);

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

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

[Jonathan Cameron]

Thanks Stephen.

Sorry Greg, I meant to mention these two would occur but clean forgot when sending that pull request.

Both are are correctly merged by Stephen.

Jonathan



Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>Hi Greg,
>
>Today's linux-next merge of the staging tree got a conflict in
>drivers/iio/industrialio-event.c between commit cadc2125e140 ("iio:
>fix:
>Keep a reference to the IIO device for open file descriptors") from the
>staging.current tree and commit a646fbf0fd11 ("iio: use
>anon_inode_getfd
>() with O_CLOEXEC flag") from the staging tree.
>
>I fixed it up (see below) and can carry the fix as necessary (no action
>is required).

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/staging/vc04_services/include/linux/raspberrypi/vchiq.h

between commit:

  7d83299351fe ("staging: vchiq_arm: fix enum vchiq_status return types")

from the staging.current tree and commit:

  3ba317227aa4 ("staging: vc04_services: Replace vchiq_status return type to int")

from the staging tree.

Thanks for the heads up.

I fixed it up (I just used 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 staging.current tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/staging/r8188eu/os_dep/ioctl_linux.c

between commit:

  96f0a54e8e65 ("staging: r8188eu: Fix warning of array overflow in ioctl_linux.c")

from the staging.current tree and commit:

  ac663ae22f02 ("staging: r8188eu: replace FIELD_OFFSET with offsetof")

from the staging tree.

I fixed it up (I just used 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 --]

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

[Greg KH]

On Tue, Jun 14, 2022 at 12:24:48PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/r8188eu/os_dep/ioctl_linux.c
> 
> between commit:
> 
>   96f0a54e8e65 ("staging: r8188eu: Fix warning of array overflow in ioctl_linux.c")
> 
> from the staging.current tree and commit:
> 
>   ac663ae22f02 ("staging: r8188eu: replace FIELD_OFFSET with offsetof")
> 
> from the staging tree.
> 
> I fixed it up (I just used 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.

Thanks, I'll resolve this when the staging-linus branch goes to Linus in
a few days.

greg k-h

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

[Greg KH]

On Tue, Jun 14, 2022 at 12:24:48PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/r8188eu/os_dep/ioctl_linux.c
> 
> between commit:
> 
>   96f0a54e8e65 ("staging: r8188eu: Fix warning of array overflow in ioctl_linux.c")
> 
> from the staging.current tree and commit:
> 
>   ac663ae22f02 ("staging: r8188eu: replace FIELD_OFFSET with offsetof")
> 
> from the staging tree.
> 
> I fixed it up (I just used 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.

Should now be resolved, thanks.

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/staging/r8188eu/os_dep/ioctl_linux.c

between commit:

  aa3233ea7bdb ("staging: r8188eu: fix -Wrestrict warnings")

from the staging.current tree and commit:

  7bdedfef085b ("staging: r8188eu: Remove mp, a.k.a. manufacturing process, code")

from the staging tree.

I fixed it up (the latter removed the code updated by the former, so I
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

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

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

[Greg KH]

On Wed, Sep 22, 2021 at 12:45:30PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/r8188eu/os_dep/ioctl_linux.c
> 
> between commit:
> 
>   aa3233ea7bdb ("staging: r8188eu: fix -Wrestrict warnings")
> 
> from the staging.current tree and commit:
> 
>   7bdedfef085b ("staging: r8188eu: Remove mp, a.k.a. manufacturing process, code")
> 
> from the staging tree.
> 
> I fixed it up (the latter removed the code updated by the former, so I
> 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.

Thanks, I'll resolve this when merging the branches together :)

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/staging/vt6656/main_usb.c

between commit:

  664ba5180234 ("staging: vt6656: Fix calling conditions of vnt_set_bss_mode")

from the staging.current tree and commit:

  463288b98190 ("staging: vt6556: vnt_rf_setpower convert to use ieee80211_channel.")

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/vt6656/main_usb.c
index 5f78cad3b647,3c76d3cb5bbe..000000000000
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@@ -743,13 -740,8 +736,12 @@@ static void vnt_bss_info_changed(struc
  		vnt_update_pre_ed_threshold(priv, false);
  	}
  
 +	if (changed & (BSS_CHANGED_BASIC_RATES | BSS_CHANGED_ERP_PREAMBLE |
 +		       BSS_CHANGED_ERP_SLOT))
 +		vnt_set_bss_mode(priv);
 +
- 	if (changed & BSS_CHANGED_TXPOWER)
- 		vnt_rf_setpower(priv, priv->current_rate,
- 				conf->chandef.chan->hw_value);
+ 	if (changed & (BSS_CHANGED_TXPOWER | BSS_CHANGED_BANDWIDTH))
+ 		vnt_rf_setpower(priv, conf->chandef.chan);
  
  	if (changed & BSS_CHANGED_BEACON_ENABLED) {
  		dev_dbg(&priv->usb->dev,

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

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

[Greg KH]

On Fri, Apr 24, 2020 at 03:15:46PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/vt6656/main_usb.c
> 
> between commit:
> 
>   664ba5180234 ("staging: vt6656: Fix calling conditions of vnt_set_bss_mode")
> 
> from the staging.current tree and commit:
> 
>   463288b98190 ("staging: vt6556: vnt_rf_setpower convert to use ieee80211_channel.")
> 
> 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/vt6656/main_usb.c
> index 5f78cad3b647,3c76d3cb5bbe..000000000000
> --- a/drivers/staging/vt6656/main_usb.c
> +++ b/drivers/staging/vt6656/main_usb.c
> @@@ -743,13 -740,8 +736,12 @@@ static void vnt_bss_info_changed(struc
>   		vnt_update_pre_ed_threshold(priv, false);
>   	}
>   
>  +	if (changed & (BSS_CHANGED_BASIC_RATES | BSS_CHANGED_ERP_PREAMBLE |
>  +		       BSS_CHANGED_ERP_SLOT))
>  +		vnt_set_bss_mode(priv);
>  +
> - 	if (changed & BSS_CHANGED_TXPOWER)
> - 		vnt_rf_setpower(priv, priv->current_rate,
> - 				conf->chandef.chan->hw_value);
> + 	if (changed & (BSS_CHANGED_TXPOWER | BSS_CHANGED_BANDWIDTH))
> + 		vnt_rf_setpower(priv, conf->chandef.chan);
>   
>   	if (changed & BSS_CHANGED_BEACON_ENABLED) {
>   		dev_dbg(&priv->usb->dev,


Thanks, that looks correct, I'll handle this when the staging.linus
branch goes to Linus in a few days.

greg k-h

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

[Greg KH]

On Fri, Apr 24, 2020 at 08:45:55AM +0200, Greg KH wrote:
> On Fri, Apr 24, 2020 at 03:15:46PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the staging tree got a conflict in:
> > 
> >   drivers/staging/vt6656/main_usb.c
> > 
> > between commit:
> > 
> >   664ba5180234 ("staging: vt6656: Fix calling conditions of vnt_set_bss_mode")
> > 
> > from the staging.current tree and commit:
> > 
> >   463288b98190 ("staging: vt6556: vnt_rf_setpower convert to use ieee80211_channel.")
> > 
> > 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/vt6656/main_usb.c
> > index 5f78cad3b647,3c76d3cb5bbe..000000000000
> > --- a/drivers/staging/vt6656/main_usb.c
> > +++ b/drivers/staging/vt6656/main_usb.c
> > @@@ -743,13 -740,8 +736,12 @@@ static void vnt_bss_info_changed(struc
> >   		vnt_update_pre_ed_threshold(priv, false);
> >   	}
> >   
> >  +	if (changed & (BSS_CHANGED_BASIC_RATES | BSS_CHANGED_ERP_PREAMBLE |
> >  +		       BSS_CHANGED_ERP_SLOT))
> >  +		vnt_set_bss_mode(priv);
> >  +
> > - 	if (changed & BSS_CHANGED_TXPOWER)
> > - 		vnt_rf_setpower(priv, priv->current_rate,
> > - 				conf->chandef.chan->hw_value);
> > + 	if (changed & (BSS_CHANGED_TXPOWER | BSS_CHANGED_BANDWIDTH))
> > + 		vnt_rf_setpower(priv, conf->chandef.chan);
> >   
> >   	if (changed & BSS_CHANGED_BEACON_ENABLED) {
> >   		dev_dbg(&priv->usb->dev,
> 
> 
> Thanks, that looks correct, I'll handle this when the staging.linus
> branch goes to Linus in a few days.

This should now all be resolved in my staging.next branch.

thanks,

greg k-h

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

[Stephen Rothwell]

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

Hi Greg,

On Tue, 28 Apr 2020 14:15:45 +0200 Greg KH <greg@kroah.com> wrote:
>
> This should now all be resolved in my staging.next branch.

Yep, thanks.

-- 
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 staging.current tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/staging/isdn/gigaset/usb-gigaset.c

between commits:

  53f35a39c386 ("staging: gigaset: fix general protection fault on probe")
  84f60ca7b326 ("staging: gigaset: fix illegal free on probe errors")
  ed9ed5a89acb ("staging: gigaset: add endpoint-type sanity check")

from the staging.current tree and commit:

  f10870b05d5e ("staging: remove isdn capi 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 staging.current tree

[Greg KH]

On Fri, Dec 13, 2019 at 12:05:34PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/isdn/gigaset/usb-gigaset.c
> 
> between commits:
> 
>   53f35a39c386 ("staging: gigaset: fix general protection fault on probe")
>   84f60ca7b326 ("staging: gigaset: fix illegal free on probe errors")
>   ed9ed5a89acb ("staging: gigaset: add endpoint-type sanity check")
> 
> from the staging.current tree and commit:
> 
>   f10870b05d5e ("staging: remove isdn capi 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.

Thanks, I knew this would happen :)

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/iio/industrialio-buffer.c

between commit:

  20ea39ef9f2f ("iio: Fix scan mask selection")

from the staging.current tree and commit:

  3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")

from the staging tree.

I fixed it up (I just used the staging tree 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.

-- 
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 staging.current tree

[Jonathan Cameron]

On Mon, 8 Apr 2019 13:02:12 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/iio/industrialio-buffer.c
> 
> between commit:
> 
>   20ea39ef9f2f ("iio: Fix scan mask selection")
> 
> from the staging.current tree and commit:
> 
>   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> 
> from the staging tree.
> 
> I fixed it up (I just used the staging tree 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.
> 
Thanks Stephen,

That is the correct resolution.

Jonathan

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

[Andy Shevchenko]

On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:02:12 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the staging tree got a conflict in:
> > 
> >   drivers/iio/industrialio-buffer.c
> > 
> > between commit:
> > 
> >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > 
> > from the staging.current tree and commit:
> > 
> >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > 
> > from the staging tree.
> > 
> > I fixed it up (I just used the staging tree 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.
> > 
> Thanks Stephen,
> 
> That is the correct resolution.

I think it still misses the following fix:

diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
index 3c7e7380d1c3..9c2d0c97ed24 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -320,7 +320,7 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev,
 	const unsigned long *mask;
 	unsigned long *trialmask;
 
-	trialmask = bitmap_alloc(indio_dev->masklength, GFP_KERNEL);
+	trialmask = bitmap_zalloc(indio_dev->masklength, GFP_KERNEL);
 	if (trialmask == NULL)
 		return -ENOMEM;
 	if (!indio_dev->masklength) {


-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

On Mon, 8 Apr 2019 13:01:21 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:
> > On Mon, 8 Apr 2019 13:02:12 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >   
> > > Hi all,
> > > 
> > > Today's linux-next merge of the staging tree got a conflict in:
> > > 
> > >   drivers/iio/industrialio-buffer.c
> > > 
> > > between commit:
> > > 
> > >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > > 
> > > from the staging.current tree and commit:
> > > 
> > >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > > 
> > > from the staging tree.
> > > 
> > > I fixed it up (I just used the staging tree 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.
> > >   
> > Thanks Stephen,
> > 
> > That is the correct resolution.  
> 
> I think it still misses the following fix:
> 
Hi Andy,

Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
The two masks are the same length so I don't think we have a problem with this one.
Am I missing something?

Jonathan


> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> index 3c7e7380d1c3..9c2d0c97ed24 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -320,7 +320,7 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev,
>  	const unsigned long *mask;
>  	unsigned long *trialmask;
>  
> -	trialmask = bitmap_alloc(indio_dev->masklength, GFP_KERNEL);
> +	trialmask = bitmap_zalloc(indio_dev->masklength, GFP_KERNEL);
>  	if (trialmask == NULL)
>  		return -ENOMEM;
>  	if (!indio_dev->masklength) {
> 
> 

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

[Andy Shevchenko]

On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:01:21 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:
> > > On Mon, 8 Apr 2019 13:02:12 +1000
> > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > > > Today's linux-next merge of the staging tree got a conflict in:
> > > > 
> > > >   drivers/iio/industrialio-buffer.c
> > > > 
> > > > between commit:
> > > > 
> > > >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > > > 
> > > > from the staging.current tree and commit:
> > > > 
> > > >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > > > 
> > > > from the staging tree.
> > > > 
> > > > I fixed it up (I just used the staging tree 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.
> > > >   
> > > Thanks Stephen,
> > > 
> > > That is the correct resolution.  
> > 
> > I think it still misses the following fix:

> Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
> The two masks are the same length so I don't think we have a problem with this one.
> Am I missing something?

Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything.

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

On Mon, 8 Apr 2019 13:34:37 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote:
> > On Mon, 8 Apr 2019 13:01:21 +0300
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:  
> > > > On Mon, 8 Apr 2019 13:02:12 +1000
> > > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> 
> > > > > Today's linux-next merge of the staging tree got a conflict in:
> > > > > 
> > > > >   drivers/iio/industrialio-buffer.c
> > > > > 
> > > > > between commit:
> > > > > 
> > > > >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > > > > 
> > > > > from the staging.current tree and commit:
> > > > > 
> > > > >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > > > > 
> > > > > from the staging tree.
> > > > > 
> > > > > I fixed it up (I just used the staging tree 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.
> > > > >     
> > > > Thanks Stephen,
> > > > 
> > > > That is the correct resolution.    
> > > 
> > > I think it still misses the following fix:  
> 
> > Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
> > The two masks are the same length so I don't think we have a problem with this one.
> > Am I missing something?  
> 
> Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything.
> 
Good point.  I'm don't think it ever did.  

Alex, any thoughts?

Jonathan

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

[Andy Shevchenko]

On Mon, Apr 08, 2019 at 01:01:51PM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:34:37 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote:
> > > On Mon, 8 Apr 2019 13:01:21 +0300
> > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> > > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:  
> > > > > On Mon, 8 Apr 2019 13:02:12 +1000
> > > > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:  

> > > > > That is the correct resolution.    
> > > > 
> > > > I think it still misses the following fix:  
> > 
> > > Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
> > > The two masks are the same length so I don't think we have a problem with this one.
> > > Am I missing something?  
> > 
> > Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything.
> > 
> Good point.  I'm don't think it ever did.  
> 
> Alex, any thoughts?

I have a thought that it might be possible that somewhere code is still broken,
i.e. accessing bitmap behind the size (for example, iterating by unsigned long
without bitmap size being aligned to size of unsigned long).

If this is a case, the mentioned patch has a symptomatic healing and not fixing
a root cause.

-- 
With Best Regards,
Andy Shevchenko

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

[Alexandru Ardelean]

On Tue, Apr 9, 2019 at 6:40 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Apr 08, 2019 at 01:01:51PM +0100, Jonathan Cameron wrote:
> > On Mon, 8 Apr 2019 13:34:37 +0300
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote:
> > > > On Mon, 8 Apr 2019 13:01:21 +0300
> > > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:
> > > > > > On Mon, 8 Apr 2019 13:02:12 +1000
> > > > > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > > > > > That is the correct resolution.
> > > > >
> > > > > I think it still misses the following fix:
> > >
> > > > Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
> > > > The two masks are the same length so I don't think we have a problem with this one.
> > > > Am I missing something?
> > >
> > > Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything.
> > >
> > Good point.  I'm don't think it ever did.
> >
> > Alex, any thoughts?
>

Hey,

This seems to have been in the context of our tree.
We have this patch:
https://github.com/analogdevicesinc/linux/commit/81d00795b1537

That removes bitmap_copy() .
See here:
https://github.com/analogdevicesinc/linux/commit/81d00795b1537#diff-0a87744ce945d2c1c89ea19f21fb35bbL397

This change is not upstreamed yet.
I guess I am slowly going nuts with trying to sync multiple trees [
our master, upstream IIO & some internal temp-branches ].

To give a bit of background: we've noticed this weird behavior while
testing a AD7193 chip with the AD7192 driver and some weird things
were happening.
At the time, this patch seemed easy to send upstream, so I sent it.

Sorry for the noise.

I guess the conclusion is, that in the context of the mainline IIO
tree, commit 20ea39ef9f2f is not needed.

Thanks
Alex

> I have a thought that it might be possible that somewhere code is still broken,
> i.e. accessing bitmap behind the size (for example, iterating by unsigned long
> without bitmap size being aligned to size of unsigned long).
>
> If this is a case, the mentioned patch has a symptomatic healing and not fixing
> a root cause.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/iio/adc/meson_saradc.c

between commit:

  d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs")

from the staging.current tree and commit:

  930df4d853a8 ("iio: adc: meson-saradc: remove irrelevant clock "sana"")

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/iio/adc/meson_saradc.c
index 36047147ce7c,f0b6502a8904..000000000000
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@@ -762,9 -732,8 +755,7 @@@ static int meson_sar_adc_hw_enable(stru
  err_adc_clk:
  	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
  			   MESON_SAR_ADC_REG3_ADC_EN, 0);
 -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
 -			   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
 +	meson_sar_adc_set_bandgap(indio_dev, false);
- 	clk_disable_unprepare(priv->sana_clk);
- err_sana_clk:
  	clk_disable_unprepare(priv->core_clk);
  err_core_clk:
  	regulator_disable(priv->vref);
@@@ -787,10 -756,9 +778,9 @@@ static int meson_sar_adc_hw_disable(str
  
  	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG3,
  			   MESON_SAR_ADC_REG3_ADC_EN, 0);
 -	regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
 -			   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
 +
 +	meson_sar_adc_set_bandgap(indio_dev, false);
  
- 	clk_disable_unprepare(priv->sana_clk);
  	clk_disable_unprepare(priv->core_clk);
  
  	regulator_disable(priv->vref);

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

[Greg KH]

On Mon, Dec 04, 2017 at 12:50:45PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/iio/adc/meson_saradc.c
> 
> between commit:
> 
>   d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs")
> 
> from the staging.current tree and commit:
> 
>   930df4d853a8 ("iio: adc: meson-saradc: remove irrelevant clock "sana"")
> 
> 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.

Thanks for the notification, merge looks correct to me, Jonathan?

greg k-h

RE: linux-next: manual merge of the staging tree with the staging.current tree

[Jonathan Cameron]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: 04 December 2017 09:10
> To: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Xingyu Chen <xingyu.chen@amlogic.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>; Martin Blumenstingl
> <martin.blumenstingl@googlemail.com>
> Subject: Re: linux-next: manual merge of the staging tree with the
> staging.current tree
> 
> On Mon, Dec 04, 2017 at 12:50:45PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got a conflict in:
> >
> >   drivers/iio/adc/meson_saradc.c
> >
> > between commit:
> >
> >   d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on
> older SoCs")
> >
> > from the staging.current tree and commit:
> >
> >   930df4d853a8 ("iio: adc: meson-saradc: remove irrelevant clock "sana"")
> >
> > 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.
> 
> Thanks for the notification, merge looks correct to me, Jonathan?
> 
> greg k-h

Looks right to me. Sorry about that - I should have noticed this one!

Thanks Stephen,

Jonathan

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

[Greg KH]

On Mon, Dec 04, 2017 at 12:50:45PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/iio/adc/meson_saradc.c
> 
> between commit:
> 
>   d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs")
> 
> from the staging.current tree and commit:
> 
>   930df4d853a8 ("iio: adc: meson-saradc: remove irrelevant clock "sana"")
> 
> 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.

This should now be resolved in my staging-next branch.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/staging/Kconfig
  drivers/staging/Makefile

between commit:

  dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")

from the staging.current tree and commit:

  874bcba65f9a ("staging: pi433: New driver")

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/Kconfig
index ef28a1cb64ae,fdf060c4c494..000000000000
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@@ -110,6 -110,6 +110,8 @@@ source "drivers/staging/ccree/Kconfig
  
  source "drivers/staging/typec/Kconfig"
  
 +source "drivers/staging/vboxvideo/Kconfig"
 +
+ source "drivers/staging/pi433/Kconfig"
+ 
  endif # STAGING
diff --cc drivers/staging/Makefile
index 2918580bdb9e,998f6441e3aa..000000000000
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@@ -44,4 -44,4 +44,5 @@@ obj-$(CONFIG_KS7010)		+= ks7010
  obj-$(CONFIG_GREYBUS)		+= greybus/
  obj-$(CONFIG_BCM2835_VCHIQ)	+= vc04_services/
  obj-$(CONFIG_CRYPTO_DEV_CCREE)	+= ccree/
 +obj-$(CONFIG_DRM_VBOXVIDEO)	+= vboxvideo/
+ obj-$(CONFIG_PI433)		+= pi433/

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

[Greg KH]

On Wed, Jul 19, 2017 at 01:07:28PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/Kconfig
>   drivers/staging/Makefile
> 
> between commit:
> 
>   dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
> 
> from the staging.current tree and commit:
> 
>   874bcba65f9a ("staging: pi433: New driver")
> 
> 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.

Yeah, I know this is going to happen, I'll be fixing it up when
staging-linus gets into Linus's tree.

thanks,

greg k-h

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

[Marcus Wolf]

Hi Greg,
 
I am surprised and happy about getting all the feedback and ideas how to
improve. Wow!
 
Can you tell me, how this is going on? Do I need to collect all those patches,
evaluate and test them or is it done automatically?
 
Do you perhaps need diffrent kind of help from me?
 
Concerning the error on M68k and the warning on sh I have an idea, but I am not
100% sure how to fix that. If I need to find a solution I would appreciate
having the option to have a short discusion with someone a little bit more
experienced....
 
Cheers,
 
Marcus

> Greg KH <greg@kroah.com> hat am 19. Juli 2017 um 08:07 geschrieben:
>
>
> On Wed, Jul 19, 2017 at 01:07:28PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got conflicts in:
> >
> > drivers/staging/Kconfig
> > drivers/staging/Makefile
> >
> > between commit:
> >
> > dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
> >
> > from the staging.current tree and commit:
> >
> > 874bcba65f9a ("staging: pi433: New driver")
> >
> > 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.
>
> Yeah, I know this is going to happen, I'll be fixing it up when
> staging-linus gets into Linus's tree.
>
> thanks,
>
> greg k-h
>

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

[Greg KH]

On Wed, Jul 19, 2017 at 10:30:43AM +0200, Marcus Wolf wrote:
> Hi Greg,
>  
> I am surprised and happy about getting all the feedback and ideas how to
> improve. Wow!
>  
> Can you tell me, how this is going on? Do I need to collect all those patches,
> evaluate and test them or is it done automatically?

If you want to collect and test, that's great, otherwise I'll just take
them like any other staging patch and apply them to my tree.  If you can
review them and reply with a:
	Reviewed-by: your name <email@...>
I'll be glad to add that to the patches when I apply them.

> Concerning the error on M68k and the warning on sh I have an idea, but I am not
> 100% sure how to fix that. If I need to find a solution I would appreciate
> having the option to have a short discusion with someone a little bit more
> experienced....

I don't remember what the warning is, perhaps respond to the thread that
it showed up in?

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/staging/greybus/timesync_platform.c

between commit:

  b17c1bba9cec ("staging: greybus: timesync: validate platform state callback")

from the staging.current tree and commit:

  bdfb95c4baab ("staging: greybus: remove timesync protocol support")

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 staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/iio/industrialio-trigger.c

between commit:

  995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func")

from the staging.current tree and commit:

  ef2d71d6b7fb ("iio: triggers: Make trigger ops structure explicitly non optional.")

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/iio/industrialio-trigger.c
index 0c52dfe64977,672911293987..000000000000
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@@ -220,14 -217,15 +223,14 @@@ static int iio_trigger_attach_poll_func
  	ret = request_threaded_irq(pf->irq, pf->h, pf->thread,
  				   pf->type, pf->name,
  				   pf);
 -	if (ret < 0) {
 -		module_put(pf->indio_dev->info->driver_module);
 -		return ret;
 -	}
 +	if (ret < 0)
 +		goto out_put_irq;
  
 +	/* Enable trigger in driver */
- 	if (trig->ops && trig->ops->set_trigger_state && notinuse) {
+ 	if (trig->ops->set_trigger_state && notinuse) {
  		ret = trig->ops->set_trigger_state(trig, true);
  		if (ret < 0)
 -			module_put(pf->indio_dev->info->driver_module);
 +			goto out_free_irq;
  	}
  
  	return ret;

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

[Jonathan Cameron]

On 14/06/16 06:04, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/iio/industrialio-trigger.c
> 
> between commit:
> 
>   995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func")
> 
> from the staging.current tree and commit:
> 
>   ef2d71d6b7fb ("iio: triggers: Make trigger ops structure explicitly non optional.")
> 
> 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.
> 
Thanks Stephen,

Looks great.

Jonathan

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/iio/magnetometer/ak8975.c

between commit:

  05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning")

from the staging.current tree and commit:

  97eacb9166f4 ("iio:ak8975: add mounting matrix support")

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/iio/magnetometer/ak8975.c
index 0e931a9a1669,dbf066129a04..000000000000
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@@ -732,11 -851,13 +851,13 @@@ static int ak8975_probe(struct i2c_clie
  	int eoc_gpio;
  	int err;
  	const char *name = NULL;
 -	enum asahi_compass_chipset chipset;
 +	enum asahi_compass_chipset chipset = AK_MAX_TYPE;
+ 	const struct ak8975_platform_data *pdata =
+ 		dev_get_platdata(&client->dev);
  
  	/* Grab and set up the supplied GPIO. */
- 	if (client->dev.platform_data)
- 		eoc_gpio = *(int *)(client->dev.platform_data);
+ 	if (pdata)
+ 		eoc_gpio = pdata->eoc_gpio;
  	else if (client->dev.of_node)
  		eoc_gpio = of_get_gpio(client->dev.of_node, 0);
  	else

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

[Jonathan Cameron]

On 27 April 2016 05:54:00 BST, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>Hi Greg,
>
>Today's linux-next merge of the staging tree got a conflict in:
>
>  drivers/iio/magnetometer/ak8975.c
>
>between commit:
>
>  05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning")
>
>from the staging.current tree and commit:
>
>  97eacb9166f4 ("iio:ak8975: add mounting matrix support")
>
>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.

Hi Stephen,

Sorry, I clearly failed to check my own trees didn't clash before sending the pull to Greg.

Fix looks good, thanks

Jonathan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/iio/gyro/bmg160_core.c

between commit:

  b475c59b113d ("iio: gyro: bmg160: fix buffer read values")

from the staging.current tree and commit:

  7e3d1eb123d8 ("iio: accel: bmg160: optimize transfers in trigger handler")

from the staging tree.

I fixed it up (I used the version from the staging tree) 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 staging.current tree

[Greg KH]

On Tue, Apr 05, 2016 at 01:03:26PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/iio/gyro/bmg160_core.c
> 
> between commit:
> 
>   b475c59b113d ("iio: gyro: bmg160: fix buffer read values")
> 
> from the staging.current tree and commit:
> 
>   7e3d1eb123d8 ("iio: accel: bmg160: optimize transfers in trigger handler")
> 
> from the staging tree.
> 
> I fixed it up (I used the version from the staging tree) 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.

Jonathan warned me about this, thanks for resolving it in your tree.
I'll fix it up in mine once they merge back together in a few weeks.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

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

  drivers/staging/panel/panel.c

between commit:

  b64a1cbef6df ("Revert "Staging: panel: usleep_range is preferred over udelay"")

from the staging.current tree and commit:

  df44f1504b4d ("staging: panel: remove warnings line over 80 characters")

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

[Greg KH]

On Mon, Feb 01, 2016 at 02:45:21PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/panel/panel.c
> 
> between commit:
> 
>   b64a1cbef6df ("Revert "Staging: panel: usleep_range is preferred over udelay"")
> 
> from the staging.current tree and commit:
> 
>   df44f1504b4d ("staging: panel: remove warnings line over 80 characters")
> 
> from the staging tree.
> 
> I fixed it up (I used the staging.current version) and can carry the fix as necessary (no action
> is required).

Thanks, I'll resolve it as well when I merge 4.5-rc2 into this branch.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/adc/Kconfig between commit bbc28134e915 ("iio: adc: Nothing
in ADC should be a bool CONFIG") from the staging.current tree and commit
9ef080ec0c5e ("iio: adc: Fix exynos_adc dependencies") 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/iio/adc/Kconfig
index 24c28e3f93a3,6cbf34a90c04..000000000000
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@@ -106,8 -117,8 +117,8 @@@ config AT91_AD
  	  Say yes here to build support for Atmel AT91 ADC.
  
  config EXYNOS_ADC
 -	bool "Exynos ADC driver support"
 +	tristate "Exynos ADC driver support"
- 	depends on OF
+ 	depends on ARCH_EXYNOS || (OF && COMPILE_TEST)
  	help
  	  Core support for the ADC block found in the Samsung EXYNOS series
  	  of SoCs for drivers such as the touchscreen and hwmon to use to share

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

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

[Greg KH]

On Thu, May 01, 2014 at 02:37:26PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/iio/adc/Kconfig between commit bbc28134e915 ("iio: adc: Nothing
> in ADC should be a bool CONFIG") from the staging.current tree and commit
> 9ef080ec0c5e ("iio: adc: Fix exynos_adc dependencies") from the staging
> tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks.

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got conflicts in
drivers/staging/rtl8723au/core/rtw_ieee80211.c,
drivers/staging/rtl8723au/core/rtw_mlme_ext.c,
drivers/staging/rtl8723au/core/rtw_p2p.c and
drivers/staging/rtl8723au/core/rtw_wlan_util.c between commit
f5d197b614d8 ("staging: rtl8723au: Fix buffer overflow in rtw_get_wfd_ie
()") from the staging.current tree and various commits from the staging
tree.

I fixed it up (I just use dthe version from the staging tree) 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 staging.current tree

[Greg KH]

On Thu, Apr 17, 2014 at 02:31:37PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got conflicts in
> drivers/staging/rtl8723au/core/rtw_ieee80211.c,
> drivers/staging/rtl8723au/core/rtw_mlme_ext.c,
> drivers/staging/rtl8723au/core/rtw_p2p.c and
> drivers/staging/rtl8723au/core/rtw_wlan_util.c between commit
> f5d197b614d8 ("staging: rtl8723au: Fix buffer overflow in rtw_get_wfd_ie
> ()") from the staging.current tree and various commits from the staging
> tree.
> 
> I fixed it up (I just use dthe version from the staging tree) 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 staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/cxt1e1/linux.c between commit 084b6e7765b9
("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
remove space between function name and parenthesis") and a couple of
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/cxt1e1/linux.c
index 79206cb3fb94,579e68e3dece..000000000000
--- a/drivers/staging/cxt1e1/linux.c
+++ b/drivers/staging/cxt1e1/linux.c
@@@ -861,79 -876,78 +876,80 @@@ c4_ioctl(struct net_device *ndev, struc
  #endif
  
  #if 0
-     pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
-             _IOC_DIR (iocmd), _IOC_TYPE (iocmd), _IOC_NR (iocmd),
-             _IOC_SIZE (iocmd));
+ 	pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
+ 		_IOC_DIR(iocmd), _IOC_TYPE(iocmd), _IOC_NR(iocmd),
+ 		_IOC_SIZE(iocmd));
  #endif
-     iolen = _IOC_SIZE (iocmd);
-     if (iolen > sizeof(arg))
-         return -EFAULT;
-     data = ifr->ifr_data + sizeof (iocmd);
-     if (copy_from_user (&arg, data, iolen))
-         return -EFAULT;
- 
-     ret = 0;
-     switch (iocmd)
-     {
-     case SBE_IOC_PORT_GET:
-         //pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
-         ret = do_get_port (ndev, data);
-         break;
-     case SBE_IOC_PORT_SET:
-         //pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
-         ret = do_set_port (ndev, data);
-         break;
-     case SBE_IOC_CHAN_GET:
-         //pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
-         ret = do_get_chan (ndev, data);
-         break;
-     case SBE_IOC_CHAN_SET:
-         //pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
-         ret = do_set_chan (ndev, data);
-         break;
-     case C4_DEL_CHAN:
-         //pr_info(">> C4_DEL_CHAN Ioctl...\n");
-         ret = do_del_chan (ndev, data);
-         break;
-     case SBE_IOC_CHAN_NEW:
-         ret = do_create_chan (ndev, data);
-         break;
-     case SBE_IOC_CHAN_GET_STAT:
-         ret = do_get_chan_stats (ndev, data);
-         break;
-     case SBE_IOC_LOGLEVEL:
-         ret = do_set_loglevel (ndev, data);
-         break;
-     case SBE_IOC_RESET_DEV:
-         ret = do_reset (ndev, data);
-         break;
-     case SBE_IOC_CHAN_DEL_STAT:
-         ret = do_reset_chan_stats (ndev, data);
-         break;
-     case C4_LOOP_PORT:
-         ret = do_port_loop (ndev, data);
-         break;
-     case C4_RW_FRMR:
-         ret = do_framer_rw (ndev, data);
-         break;
-     case C4_RW_MSYC:
-         ret = do_musycc_rw (ndev, data);
-         break;
-     case C4_RW_PLD:
-         ret = do_pld_rw (ndev, data);
-         break;
-     case SBE_IOC_IID_GET:
-         ret = (iolen == sizeof (struct sbe_iid_info)) ? c4_get_iidinfo (ci, &arg.u.iip) : -EFAULT;
-         if (ret == 0)               /* no error, copy data */
-             if (copy_to_user (data, &arg, iolen))
-                 return -EFAULT;
-         break;
-     default:
-         //pr_info(">> c4_ioctl: EINVAL - unknown iocmd <%x>\n", iocmd);
-         ret = -EINVAL;
-         break;
-     }
-     return mkret (ret);
+ 	iolen = _IOC_SIZE(iocmd);
++	if (iolen > sizeof(arg))
++		return -EFAULT;
+ 	data = ifr->ifr_data + sizeof(iocmd);
+ 	if (copy_from_user(&arg, data, iolen))
+ 		return -EFAULT;
+ 
+ 	ret = 0;
+ 	switch (iocmd)
+ 	{
+ 	case SBE_IOC_PORT_GET:
+ 		//pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
+ 		ret = do_get_port(ndev, data);
+ 		break;
+ 	case SBE_IOC_PORT_SET:
+ 		//pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
+ 		ret = do_set_port(ndev, data);
+ 		break;
+ 	case SBE_IOC_CHAN_GET:
+ 		//pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
+ 		ret = do_get_chan(ndev, data);
+ 		break;
+ 	case SBE_IOC_CHAN_SET:
+ 		//pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
+ 		ret = do_set_chan(ndev, data);
+ 		break;
+ 	case C4_DEL_CHAN:
+ 		//pr_info(">> C4_DEL_CHAN Ioctl...\n");
+ 		ret = do_del_chan(ndev, data);
+ 		break;
+ 	case SBE_IOC_CHAN_NEW:
+ 		ret = do_create_chan(ndev, data);
+ 		break;
+ 	case SBE_IOC_CHAN_GET_STAT:
+ 		ret = do_get_chan_stats(ndev, data);
+ 		break;
+ 	case SBE_IOC_LOGLEVEL:
+ 		ret = do_set_loglevel(ndev, data);
+ 		break;
+ 	case SBE_IOC_RESET_DEV:
+ 		ret = do_reset(ndev, data);
+ 		break;
+ 	case SBE_IOC_CHAN_DEL_STAT:
+ 		ret = do_reset_chan_stats(ndev, data);
+ 		break;
+ 	case C4_LOOP_PORT:
+ 		ret = do_port_loop(ndev, data);
+ 		break;
+ 	case C4_RW_FRMR:
+ 		ret = do_framer_rw(ndev, data);
+ 		break;
+ 	case C4_RW_MSYC:
+ 		ret = do_musycc_rw(ndev, data);
+ 		break;
+ 	case C4_RW_PLD:
+ 		ret = do_pld_rw(ndev, data);
+ 		break;
+ 	case SBE_IOC_IID_GET:
+ 		ret = (iolen == sizeof(struct sbe_iid_info)) ?
+ 		       c4_get_iidinfo(ci, &arg.u.iip) : -EFAULT;
+ 		if (ret == 0)               /* no error, copy data */
+ 			if (copy_to_user(data, &arg, iolen))
+ 				return -EFAULT;
+ 		break;
+ 	default:
+ 		//pr_info(">> c4_ioctl: EINVAL - unknown iocmd <%x>\n", iocmd);
+ 		ret = -EINVAL;
+ 		break;
+ 	}
+ 	return mkret(ret);
  }
  
  static const struct net_device_ops c4_ops = {

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

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

[Greg KH]

On Thu, Mar 06, 2014 at 04:06:49PM +1100, 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 084b6e7765b9
> ("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
> from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
> remove space between function name and parenthesis") and a couple of
> others from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks, that looks good.

greg k-h

> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc drivers/staging/cxt1e1/linux.c
> index 79206cb3fb94,579e68e3dece..000000000000
> --- a/drivers/staging/cxt1e1/linux.c
> +++ b/drivers/staging/cxt1e1/linux.c
> @@@ -861,79 -876,78 +876,80 @@@ c4_ioctl(struct net_device *ndev, struc
>   #endif
>   
>   #if 0
> -     pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
> -             _IOC_DIR (iocmd), _IOC_TYPE (iocmd), _IOC_NR (iocmd),
> -             _IOC_SIZE (iocmd));
> + 	pr_info("c4_ioctl: iocmd %x, dir %x type %x nr %x iolen %d.\n", iocmd,
> + 		_IOC_DIR(iocmd), _IOC_TYPE(iocmd), _IOC_NR(iocmd),
> + 		_IOC_SIZE(iocmd));
>   #endif
> -     iolen = _IOC_SIZE (iocmd);
> -     if (iolen > sizeof(arg))
> -         return -EFAULT;
> -     data = ifr->ifr_data + sizeof (iocmd);
> -     if (copy_from_user (&arg, data, iolen))
> -         return -EFAULT;
> - 
> -     ret = 0;
> -     switch (iocmd)
> -     {
> -     case SBE_IOC_PORT_GET:
> -         //pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
> -         ret = do_get_port (ndev, data);
> -         break;
> -     case SBE_IOC_PORT_SET:
> -         //pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
> -         ret = do_set_port (ndev, data);
> -         break;
> -     case SBE_IOC_CHAN_GET:
> -         //pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
> -         ret = do_get_chan (ndev, data);
> -         break;
> -     case SBE_IOC_CHAN_SET:
> -         //pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
> -         ret = do_set_chan (ndev, data);
> -         break;
> -     case C4_DEL_CHAN:
> -         //pr_info(">> C4_DEL_CHAN Ioctl...\n");
> -         ret = do_del_chan (ndev, data);
> -         break;
> -     case SBE_IOC_CHAN_NEW:
> -         ret = do_create_chan (ndev, data);
> -         break;
> -     case SBE_IOC_CHAN_GET_STAT:
> -         ret = do_get_chan_stats (ndev, data);
> -         break;
> -     case SBE_IOC_LOGLEVEL:
> -         ret = do_set_loglevel (ndev, data);
> -         break;
> -     case SBE_IOC_RESET_DEV:
> -         ret = do_reset (ndev, data);
> -         break;
> -     case SBE_IOC_CHAN_DEL_STAT:
> -         ret = do_reset_chan_stats (ndev, data);
> -         break;
> -     case C4_LOOP_PORT:
> -         ret = do_port_loop (ndev, data);
> -         break;
> -     case C4_RW_FRMR:
> -         ret = do_framer_rw (ndev, data);
> -         break;
> -     case C4_RW_MSYC:
> -         ret = do_musycc_rw (ndev, data);
> -         break;
> -     case C4_RW_PLD:
> -         ret = do_pld_rw (ndev, data);
> -         break;
> -     case SBE_IOC_IID_GET:
> -         ret = (iolen == sizeof (struct sbe_iid_info)) ? c4_get_iidinfo (ci, &arg.u.iip) : -EFAULT;
> -         if (ret == 0)               /* no error, copy data */
> -             if (copy_to_user (data, &arg, iolen))
> -                 return -EFAULT;
> -         break;
> -     default:
> -         //pr_info(">> c4_ioctl: EINVAL - unknown iocmd <%x>\n", iocmd);
> -         ret = -EINVAL;
> -         break;
> -     }
> -     return mkret (ret);
> + 	iolen = _IOC_SIZE(iocmd);
> ++	if (iolen > sizeof(arg))
> ++		return -EFAULT;
> + 	data = ifr->ifr_data + sizeof(iocmd);
> + 	if (copy_from_user(&arg, data, iolen))
> + 		return -EFAULT;
> + 
> + 	ret = 0;
> + 	switch (iocmd)
> + 	{
> + 	case SBE_IOC_PORT_GET:
> + 		//pr_info(">> SBE_IOC_PORT_GET Ioctl...\n");
> + 		ret = do_get_port(ndev, data);
> + 		break;
> + 	case SBE_IOC_PORT_SET:
> + 		//pr_info(">> SBE_IOC_PORT_SET Ioctl...\n");
> + 		ret = do_set_port(ndev, data);
> + 		break;
> + 	case SBE_IOC_CHAN_GET:
> + 		//pr_info(">> SBE_IOC_CHAN_GET Ioctl...\n");
> + 		ret = do_get_chan(ndev, data);
> + 		break;
> + 	case SBE_IOC_CHAN_SET:
> + 		//pr_info(">> SBE_IOC_CHAN_SET Ioctl...\n");
> + 		ret = do_set_chan(ndev, data);
> + 		break;
> + 	case C4_DEL_CHAN:
> + 		//pr_info(">> C4_DEL_CHAN Ioctl...\n");
> + 		ret = do_del_chan(ndev, data);
> + 		break;
> + 	case SBE_IOC_CHAN_NEW:
> + 		ret = do_create_chan(ndev, data);
> + 		break;
> + 	case SBE_IOC_CHAN_GET_STAT:
> + 		ret = do_get_chan_stats(ndev, data);
> + 		break;
> + 	case SBE_IOC_LOGLEVEL:
> + 		ret = do_set_loglevel(ndev, data);
> + 		break;
> + 	case SBE_IOC_RESET_DEV:
> + 		ret = do_reset(ndev, data);
> + 		break;
> + 	case SBE_IOC_CHAN_DEL_STAT:
> + 		ret = do_reset_chan_stats(ndev, data);
> + 		break;
> + 	case C4_LOOP_PORT:
> + 		ret = do_port_loop(ndev, data);
> + 		break;
> + 	case C4_RW_FRMR:
> + 		ret = do_framer_rw(ndev, data);
> + 		break;
> + 	case C4_RW_MSYC:
> + 		ret = do_musycc_rw(ndev, data);
> + 		break;
> + 	case C4_RW_PLD:
> + 		ret = do_pld_rw(ndev, data);
> + 		break;
> + 	case SBE_IOC_IID_GET:
> + 		ret = (iolen == sizeof(struct sbe_iid_info)) ?
> + 		       c4_get_iidinfo(ci, &arg.u.iip) : -EFAULT;
> + 		if (ret == 0)               /* no error, copy data */
> + 			if (copy_to_user(data, &arg, iolen))
> + 				return -EFAULT;
> + 		break;
> + 	default:
> + 		//pr_info(">> c4_ioctl: EINVAL - unknown iocmd <%x>\n", iocmd);
> + 		ret = -EINVAL;
> + 		break;
> + 	}
> + 	return mkret(ret);
>   }
>   
>   static const struct net_device_ops c4_ops = {

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

[Greg KH]

On Thu, Mar 06, 2014 at 04:06:49PM +1100, 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 084b6e7765b9
> ("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
> from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
> remove space between function name and parenthesis") and a couple of
> others from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Now fixed in my tree, thanks.

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
include/linux/hid-sensor-ids.h between commit 751d17e23a9f ("iio:
hid-sensors: Fix power and report state") from the staging.current tree
and commit 64528d03d723 ("iio: hid-sensors: accelerometer: Add
sensitivity") 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 include/linux/hid-sensor-ids.h
index 8323775ac21d,4cc165887b09..000000000000
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@@ -117,16 -121,8 +121,20 @@@
  #define HID_USAGE_SENSOR_PROP_REPORT_STATE			0x200316
  #define HID_USAGE_SENSOR_PROY_POWER_STATE			0x200319
  
 +/* Power state enumerations */
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_UNDEFINED_ENUM		0x00
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D0_FULL_POWER_ENUM		0x01
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D1_LOW_POWER_ENUM		0x02
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D2_STANDBY_WITH_WAKE_ENUM	0x03
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D3_SLEEP_WITH_WAKE_ENUM	0x04
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D4_POWER_OFF_ENUM		0x05
 +
 +/* Report State enumerations */
 +#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM		0x00
 +#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM		0x01
 +
+ /* Per data field properties */
+ #define HID_USAGE_SENSOR_DATA_MOD_NONE					0x00
+ #define HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS		0x1000
+ 
  #endif

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

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got conflicts in
drivers/staging/tidspbridge/pmgr/cmm.c,
drivers/staging/tidspbridge/pmgr/dbll.c,
drivers/staging/tidspbridge/pmgr/dev.c,
drivers/staging/tidspbridge/pmgr/dmm.c and
drivers/staging/tidspbridge/pmgr/dspapi.c between commit cb45065428b7
("staging: delete tidspbridge driver") from the staging.current tree and
various commits from the staging tree.

I just removed the files 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 staging.current tree

[Greg KH]

On Wed, Nov 27, 2013 at 01:01:44PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got conflicts in
> drivers/staging/tidspbridge/pmgr/cmm.c,
> drivers/staging/tidspbridge/pmgr/dbll.c,
> drivers/staging/tidspbridge/pmgr/dev.c,
> drivers/staging/tidspbridge/pmgr/dmm.c and
> drivers/staging/tidspbridge/pmgr/dspapi.c between commit cb45065428b7
> ("staging: delete tidspbridge driver") from the staging.current tree and
> various commits from the staging tree.
> 
> I just removed the files and can carry the fix as necessary (no action
> is required).

Thanks, that is the correct thing.

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/industrialio-buffer.c between commit d66e0452bf6b ("iio: Fix
crash when scan_bytes is computed with active_scan_mask == NUL") from the
staging.current tree and commit 705ee2c98a37 ("iio:buffer: Simplify
iio_buffer_is_active()") 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/iio/industrialio-buffer.c
index 2710f72,2361fbc..0000000
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@@ -546,16 -521,9 +540,16 @@@ int iio_update_buffers(struct iio_dev *
  			 * Roll back.
  			 * Note can only occur when adding a buffer.
  			 */
- 			list_del(&insert_buffer->buffer_list);
+ 			list_del_init(&insert_buffer->buffer_list);
 -			indio_dev->active_scan_mask = old_mask;
 -			success = -EINVAL;
 +			if (old_mask) {
 +				indio_dev->active_scan_mask = old_mask;
 +				success = -EINVAL;
 +			}
 +			else {
 +				kfree(compound_mask);
 +				ret = -EINVAL;
 +				goto error_ret;
 +			}
  		}
  	} else {
  		indio_dev->active_scan_mask = compound_mask;

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

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

[Jonathan Cameron]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>Hi Greg,
>
>Today's linux-next merge of the staging tree got a conflict in
>drivers/iio/industrialio-buffer.c between commit d66e0452bf6b ("iio:
>Fix
>crash when scan_bytes is computed with active_scan_mask == NUL") from
>the
>staging.current tree and commit 705ee2c98a37 ("iio:buffer: Simplify
>iio_buffer_is_active()") from the staging tree.
>
>I fixed it up (see below) and can carry the fix as necessary (no action
>is required).

Thanks Stephen.

The merge is correct.

Jonathan

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/comedi/drivers/amplc_dio200.c between commit dfb2540e91e1
("staging: comedi: amplc_dio200: fix possible NULL deref during detach")
from the staging.current tree and commit 71b3e9e8dc21 ("staging: comedi:
amplc_dio200: support memory-mapped I/O") from the staging tree.

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

[Ian Abbott]

On 2012-10-25 03:19, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/comedi/drivers/amplc_dio200.c between commit dfb2540e91e1
> ("staging: comedi: amplc_dio200: fix possible NULL deref during detach")
> from the staging.current tree and commit 71b3e9e8dc21 ("staging: comedi:
> amplc_dio200: support memory-mapped I/O") from the staging tree.
>
> I fixed it up (the latter is a superset of the former) and can carry the
> fix as necessary (no action is required).

Sorry, I remember editing that while rebasing my patches.  I think I 
must have assumed the NULL deref patch had already been applied to 
Greg's "staging-next" branch, but it had in fact it had only been 
applied to his "staging-linus" branch.  I was editing various other bits 
while rebasing that patch series, so I never noticed that particular 
edit as being a conflict.

Apologies for the inconvenience it caused you.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@mev.co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/brcm80211/brcmfmac/wl_iw.c between commit e1c78de9a462
("staging: brcm80211: fix for 'multiple definition of wl_msg_level' build
err") from the staging.current tree and commit 8817f75429a1 ("staging:
brcm80211: removed wl_ (vendor specific acronym)") from the staging tree.

I fixed it up (using the latter change) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Greg KH]

On Thu, Jun 09, 2011 at 04:58:08PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/brcm80211/brcmfmac/wl_iw.c between commit e1c78de9a462
> ("staging: brcm80211: fix for 'multiple definition of wl_msg_level' build
> err") from the staging.current tree and commit 8817f75429a1 ("staging:
> brcm80211: removed wl_ (vendor specific acronym)") from the staging tree.
> 
> I fixed it up (using the latter change) and can carry the fix as
> necessary.

Thanks for the fix, it sounds correct.

greg k-h

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

[Greg KH]

On Thu, Jun 09, 2011 at 11:41:43AM -0700, Greg KH wrote:
> On Thu, Jun 09, 2011 at 04:58:08PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/staging/brcm80211/brcmfmac/wl_iw.c between commit e1c78de9a462
> > ("staging: brcm80211: fix for 'multiple definition of wl_msg_level' build
> > err") from the staging.current tree and commit 8817f75429a1 ("staging:
> > brcm80211: removed wl_ (vendor specific acronym)") from the staging tree.
> > 
> > I fixed it up (using the latter change) and can carry the fix as
> > necessary.
> 
> Thanks for the fix, it sounds correct.

This should now be resolved.

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/usbip/stub_dev.c between commit d3ac07788017 ("staging:
usbip: bugfix prevent driver unbind") from the staging.current tree and
commit d012c2a5aca1 ("staging: usbip: stub_dev.c: move stub_driver
definition and update driver name") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/usbip/stub_dev.c
index 8cbea42,e26b2ee..0000000
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@@ -546,19 -524,9 +524,28 @@@ static void stub_disconnect(struct usb_
  	}
  }
  
 +/* 
 + * Presence of pre_reset and post_reset prevents the driver from being unbound
 + * when the device is being reset
 + */
 + 
 +int stub_pre_reset(struct usb_interface *interface)
 +{
 +	dev_dbg(&interface->dev, "pre_reset\n");
 +	return 0;
 +}
 +
 +int stub_post_reset(struct usb_interface *interface)
 +{
 +	dev_dbg(&interface->dev, "post_reset\n");
 +	return 0;
 +}
++
+ struct usb_driver stub_driver = {
+ 	.name		= "usbip-host",
+ 	.probe		= stub_probe,
+ 	.disconnect	= stub_disconnect,
+ 	.id_table	= stub_table,
++	.pre_reset	= stub_pre_reset,
++	.post_reset	= stub_post_reset,
+ };

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

[Greg KH]

On Thu, Jun 09, 2011 at 04:58:04PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/usbip/stub_dev.c between commit d3ac07788017 ("staging:
> usbip: bugfix prevent driver unbind") from the staging.current tree and
> commit d012c2a5aca1 ("staging: usbip: stub_dev.c: move stub_driver
> definition and update driver name") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Looks correct, thanks for doing this.

greg k-h

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

[Greg KH]

On Thu, Jun 09, 2011 at 11:42:06AM -0700, Greg KH wrote:
> On Thu, Jun 09, 2011 at 04:58:04PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/staging/usbip/stub_dev.c between commit d3ac07788017 ("staging:
> > usbip: bugfix prevent driver unbind") from the staging.current tree and
> > commit d012c2a5aca1 ("staging: usbip: stub_dev.c: move stub_driver
> > definition and update driver name") from the staging tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> Looks correct, thanks for doing this.

This should now be resolved.

greg k-h

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

[Arjan Mels]

Greg, Stephen,

Below mentioned patch does not seem to have made it into the linux-next tree 
(and other stable branches).

What do I need to do to correct this?

Best Regards,

Arjan

> > drivers/staging/usbip/stub_dev.c between commit d3ac07788017 ("staging:
> > usbip: bugfix prevent driver unbind") from the staging.current tree and
> > commit d012c2a5aca1 ("staging: usbip: stub_dev.c: move stub_driver




-----Original Message----- 
From: Greg KH
Sent: Thursday, June 09, 2011 22:51
To: Stephen Rothwell
Cc: linux-next@vger.kernel.org ; linux-kernel@vger.kernel.org ; Arjan Mels ; 
matt mooney
Subject: Re: linux-next: manual merge of the staging tree with the 
staging.current tree

On Thu, Jun 09, 2011 at 11:42:06AM -0700, Greg KH wrote:
> On Thu, Jun 09, 2011 at 04:58:04PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/staging/usbip/stub_dev.c between commit d3ac07788017 ("staging:
> > usbip: bugfix prevent driver unbind") from the staging.current tree and
> > commit d012c2a5aca1 ("staging: usbip: stub_dev.c: move stub_driver
> > definition and update driver name") from the staging tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
>
> Looks correct, thanks for doing this.

This should now be resolved.

greg k-h 

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

[Greg KH]

On Tue, Jun 28, 2011 at 04:07:25PM +0200, Arjan Mels wrote:
> Greg, Stephen,
> 
> Below mentioned patch does not seem to have made it into the
> linux-next tree (and other stable branches).

What do you mean by "other stable branches"?

> What do I need to do to correct this?

I don't understand what you are wanting to correct, please be explicit
as I am totally confused.

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/hv/vmbus_drv.c between commit 22356585712d ("staging: hv:
use sync_bitops when interacting with the hypervisor") from the
staging.current tree and commit 98e087022b61 ("staging: hv: Remove all
unneeded DPRINT from hv_vmbus") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/hv/vmbus_drv.c
index 79089f8,501ab36..0000000
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@@ -254,10 -527,8 +527,8 @@@ static int vmbus_on_isr(void
  	event = (union hv_synic_event_flags *)page_addr + VMBUS_MESSAGE_SINT;
  
  	/* Since we are a child, we only need to check bit 0 */
- 	if (sync_test_and_clear_bit(0, (unsigned long *) &event->flags32[0])) {
- 		DPRINT_DBG(VMBUS, "received event %d", event->flags32[0]);
 -	if (test_and_clear_bit(0, (unsigned long *) &event->flags32[0]))
++	if (sync_test_and_clear_bit(0, (unsigned long *) &event->flags32[0]))
  		ret |= 0x2;
- 	}
  
  	return ret;
  }

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

[Greg KH]

On Wed, Apr 06, 2011 at 02:41:22PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/hv/vmbus_drv.c between commit 22356585712d ("staging: hv:
> use sync_bitops when interacting with the hypervisor") from the
> staging.current tree and commit 98e087022b61 ("staging: hv: Remove all
> unneeded DPRINT from hv_vmbus") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Thanks, yes, that looks correct, I'll resolve the conflict when I send
the staging-linus tree to Linus in a few days.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/zram/zram_drv.c between commit
5414e557fca545614ceedc3d3496f747457e2e3b ("staging: zram: fix data
corruption issue") from the staging.current tree and commit
2787f959d6c5fb258d964218ac75346019f49ee9 ("zram: Return zero'd pages on
new reads") from the staging tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/zram/zram_drv.c
index 4bd8cbd,1017d6d..0000000
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@@ -235,8 -237,7 +238,8 @@@ static void zram_read(struct zram *zram
  		if (unlikely(!zram->table[index].page)) {
  			pr_debug("Read before write: sector=%lu, size=%u",
  				(ulong)(bio->bi_sector), bio->bi_size);
- 			/* Do nothing */
+ 			handle_zero_page(page);
 +			index++;
  			continue;
  		}
  

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

[Nitin Gupta]

On 02/10/2011 11:05 AM, Stephen Rothwell wrote:
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/zram/zram_drv.c between commit
> 5414e557fca545614ceedc3d3496f747457e2e3b ("staging: zram: fix data
> corruption issue") from the staging.current tree and commit
> 2787f959d6c5fb258d964218ac75346019f49ee9 ("zram: Return zero'd pages on
> new reads") from the staging tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.

The fix looks correct to me. Thanks for fixing this.

Nitin

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

[Robert Jennings]

* Stephen Rothwell (sfr@canb.auug.org.au) wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/zram/zram_drv.c between commit
> 5414e557fca545614ceedc3d3496f747457e2e3b ("staging: zram: fix data
> corruption issue") from the staging.current tree and commit
> 2787f959d6c5fb258d964218ac75346019f49ee9 ("zram: Return zero'd pages on
> new reads") from the staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc drivers/staging/zram/zram_drv.c
> index 4bd8cbd,1017d6d..0000000
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@@ -235,8 -237,7 +238,8 @@@ static void zram_read(struct zram *zram
>   		if (unlikely(!zram->table[index].page)) {
>   			pr_debug("Read before write: sector=%lu, size=%u",
>   				(ulong)(bio->bi_sector), bio->bi_size);
> - 			/* Do nothing */
> + 			handle_zero_page(page);
>  +			index++;
>   			continue;
>   		}
>   

This is correct, thanks.

--Rob Jennings

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

[Greg KH]

On Thu, Feb 10, 2011 at 04:35:27PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/zram/zram_drv.c between commit
> 5414e557fca545614ceedc3d3496f747457e2e3b ("staging: zram: fix data
> corruption issue") from the staging.current tree and commit
> 2787f959d6c5fb258d964218ac75346019f49ee9 ("zram: Return zero'd pages on
> new reads") from the staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

Thanks, I'll handle this when Linus takes my tree and I'll merge to
resolve the conflict.

greg k-h

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

[Greg KH]

On Thu, Feb 10, 2011 at 04:35:27PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/zram/zram_drv.c between commit
> 5414e557fca545614ceedc3d3496f747457e2e3b ("staging: zram: fix data
> corruption issue") from the staging.current tree and commit
> 2787f959d6c5fb258d964218ac75346019f49ee9 ("zram: Return zero'd pages on
> new reads") from the staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

I've merge Linus's tree into the staging-next tree now and took this
resolution and pushed it back out so you should not have any more
problems.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c between commit
f32b8453e5a5587ae112ba478ae0bbad74e83d22 ("Staging: ste_rmi4: use after
input_unregister_device()") from the staging.current tree and commit
dc7b202a4ee6cb686e2bbef80c84443f43ec91bd ("staging/ste_rmi4: Remove
obsolete cleanup for clientdata") from the staging tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
index 80183a7,fa1ee9d..0000000
--- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
+++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
@@@ -997,21 -1001,14 +995,19 @@@ static int __devinit synaptics_rmi4_pro
  	if (retval) {
  		dev_err(&client->dev, "%s:Unable to get attn irq %d\n",
  				__func__, platformdata->irq_number);
- 		goto err_unset_clientdata;
 -		goto err_request_irq;
++		goto err_query_dev;
 +	}
 +
 +	retval = input_register_device(rmi4_data->input_dev);
 +	if (retval) {
 +		dev_err(&client->dev, "%s:input register failed\n", __func__);
 +		goto err_free_irq;
  	}
  
  	return retval;
  
 -err_request_irq:
 +err_free_irq:
  	free_irq(platformdata->irq_number, rmi4_data);
- err_unset_clientdata:
- 	i2c_set_clientdata(client, NULL);
 -	input_unregister_device(rmi4_data->input_dev);
  err_query_dev:
  	if (platformdata->regulator_en) {
  		regulator_disable(rmi4_data->regulator);

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

[Greg KH]

On Mon, Jan 31, 2011 at 04:16:40PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c between commit
> f32b8453e5a5587ae112ba478ae0bbad74e83d22 ("Staging: ste_rmi4: use after
> input_unregister_device()") from the staging.current tree and commit
> dc7b202a4ee6cb686e2bbef80c84443f43ec91bd ("staging/ste_rmi4: Remove
> obsolete cleanup for clientdata") from the staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

Thanks, that looks correct to me.  I'll apply this when Linus syncs up
with my staging-linus tree.

greg k-h

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

[Greg KH]

On Mon, Jan 31, 2011 at 04:16:40PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c between commit
> f32b8453e5a5587ae112ba478ae0bbad74e83d22 ("Staging: ste_rmi4: use after
> input_unregister_device()") from the staging.current tree and commit
> dc7b202a4ee6cb686e2bbef80c84443f43ec91bd ("staging/ste_rmi4: Remove
> obsolete cleanup for clientdata") from the staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

I've merged with Linus's tree now so this should not be needed anymore.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/brcm80211/brcmsmac/wl_mac80211.c,
drivers/staging/brcm80211/sys/wlc_mac80211.c and
drivers/staging/brcm80211/sys/wlc_mac80211.c (these three files names are
the same file, it has been renamed twice, I think ..) between
commit4032ec639af9b735fdd903fab09de567bd73eaa0 ("staging: brcm80211: fix
suspend/resume issue in brcmsmac") from the staging.current tree and
commit c836f77fdba3631e295e3da1718ab53a9038fdf2 ("staging: brcm80211: use
KBUILD_MODNAME as driver name in registration") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
index f123588,6505732..0000000
--- a/drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
+++ b/drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
@@@ -1187,11 -1154,13 +1157,11 @@@ static void wl_remove(struct pci_dev *p
  }
  
  static struct pci_driver wl_pci_driver = {
- 	.name = "brcm80211",
+ 	.name  = KBUILD_MODNAME,
  	.probe = wl_pci_probe,
 -#ifdef LINUXSTA_PS
  	.suspend = wl_suspend,
 -	.resume  = wl_resume,
 -#endif				/* LINUXSTA_PS */
 -	.remove   = __devexit_p(wl_remove),
 +	.resume = wl_resume,
 +	.remove = __devexit_p(wl_remove),
  	.id_table = wl_id_table,
  };
  

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

[Arend van Spriel]

Hi Stephen,

On Mon, 31 Jan 2011 06:09:26 +0100, Stephen Rothwell  
<sfr@canb.auug.org.au> wrote:

> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/brcm80211/brcmsmac/wl_mac80211.c,
> drivers/staging/brcm80211/sys/wlc_mac80211.c and
> drivers/staging/brcm80211/sys/wlc_mac80211.c (these three files names are
> the same file, it has been renamed twice, I think ..) between

wl_mac80211.c and wlc_mac80211.c are different source files. The driver  
source
tree has been restructured in the staging-next branch and files that were
located in brcm80211/sys are moved to brcm80211/brcmsmac.

>
> I fixed it up (see below) and can carry the fix as necessary.

The fix looks ok and I also verified the wl_mac80211.c in linux-next on
gitweb.

Regards,
Arend van Spriel
-- 
"The most merciful thing in the world, I think, is the inability of the  
human
mind to correlate all its contents." - "The Call of Cthulhu"

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

[Greg KH]

On Mon, Jan 31, 2011 at 04:09:26PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/brcm80211/brcmsmac/wl_mac80211.c,
> drivers/staging/brcm80211/sys/wlc_mac80211.c and
> drivers/staging/brcm80211/sys/wlc_mac80211.c (these three files names are
> the same file, it has been renamed twice, I think ..) between
> commit4032ec639af9b735fdd903fab09de567bd73eaa0 ("staging: brcm80211: fix
> suspend/resume issue in brcmsmac") from the staging.current tree and
> commit c836f77fdba3631e295e3da1718ab53a9038fdf2 ("staging: brcm80211: use
> KBUILD_MODNAME as driver name in registration") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

I've merged with Linus's tree now, so this should not be needed anymore.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/winbond/sysdef.h between commit
412dc7f368bf10a8049a8a4c41abbfd0108742e7 ("staging: fix winbond build,
needs delay.h") from the staging.current tree and commit
ddee7e28e7d5e4ba2b8537c6a59b035745c250bb ("Staging: w35und: Remove empty
sysdef.h header") from the staging tree.

I removed the file.  I wonder if
drivers/staging/winbond/phy_calibration.c and
drivers/staging/winbond/reg.c now need their own includes of
linux/delay.h ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Randy Dunlap]

On 12/01/10 18:22, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/winbond/sysdef.h between commit
> 412dc7f368bf10a8049a8a4c41abbfd0108742e7 ("staging: fix winbond build,
> needs delay.h") from the staging.current tree and commit
> ddee7e28e7d5e4ba2b8537c6a59b035745c250bb ("Staging: w35und: Remove empty
> sysdef.h header") from the staging tree.
> 
> I removed the file.  I wonder if
> drivers/staging/winbond/phy_calibration.c and
> drivers/staging/winbond/reg.c now need their own includes of
> linux/delay.h ...

Probably, since sysdef.h was no longer an empty file.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

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

[Greg KH]

On Thu, Dec 02, 2010 at 01:22:54PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/winbond/sysdef.h between commit
> 412dc7f368bf10a8049a8a4c41abbfd0108742e7 ("staging: fix winbond build,
> needs delay.h") from the staging.current tree and commit
> ddee7e28e7d5e4ba2b8537c6a59b035745c250bb ("Staging: w35und: Remove empty
> sysdef.h header") from the staging tree.
> 
> I removed the file.  I wonder if
> drivers/staging/winbond/phy_calibration.c and
> drivers/staging/winbond/reg.c now need their own includes of
> linux/delay.h ...

Heh, probably.  I'll handle this merge when thes staging.current code
goes to Linus this week.

thanks,

greg k-h

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

[Greg KH]

On Wed, Dec 01, 2010 at 08:00:31PM -0800, Greg KH wrote:
> On Thu, Dec 02, 2010 at 01:22:54PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/staging/winbond/sysdef.h between commit
> > 412dc7f368bf10a8049a8a4c41abbfd0108742e7 ("staging: fix winbond build,
> > needs delay.h") from the staging.current tree and commit
> > ddee7e28e7d5e4ba2b8537c6a59b035745c250bb ("Staging: w35und: Remove empty
> > sysdef.h header") from the staging tree.
> > 
> > I removed the file.  I wonder if
> > drivers/staging/winbond/phy_calibration.c and
> > drivers/staging/winbond/reg.c now need their own includes of
> > linux/delay.h ...
> 
> Heh, probably.  I'll handle this merge when thes staging.current code
> goes to Linus this week.

Now merged so this conflict should have gone away.

thanks,

greg k-h

linux-next: manual merge of the staging tree with the staging.current tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/bcm/Bcmchar.c between commit
eccbf04a904fc99c54ab37c29a2a4dedcec66e33 ("Staging: bcm: use get_user()
to access user pointers") from the staging.current tree and commit
ada692b09f4707a8e06b087b1546d9f5b3f2d37d ("beceem: fix character device
ioctl") from the staging tree.

I just assumed that the latter supercedes the former and so used the
staging version of the file.  I may well be wrong in this.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Greg KH]

On Wed, Nov 10, 2010 at 01:24:20PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/bcm/Bcmchar.c between commit
> eccbf04a904fc99c54ab37c29a2a4dedcec66e33 ("Staging: bcm: use get_user()
> to access user pointers") from the staging.current tree and commit
> ada692b09f4707a8e06b087b1546d9f5b3f2d37d ("beceem: fix character device
> ioctl") from the staging tree.
> 
> I just assumed that the latter supercedes the former and so used the
> staging version of the file.  I may well be wrong in this.

That sounds correct, I'll handle the merge when the patches go to Linus.

thanks,

greg k-h