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

[Stephen Rothwell]

Hi Greg,

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

Yep, thanks.

-- 
Cheers,
Stephen Rothwell


pgp7yFb9_JAiu.pgp
Description: OpenPGP digital signature

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..
> > --- 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(>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

[Alexandru Ardelean]

On Tue, Apr 9, 2019 at 6:40 PM Andy Shevchenko
 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  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  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  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
>
>

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  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  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  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

[Jonathan Cameron]

On Mon, 8 Apr 2019 13:34:37 +0300
Andy Shevchenko  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  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  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 11:14:39AM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:01:21 +0300
> Andy Shevchenko  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  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:01:21 +0300
Andy Shevchenko  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  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 09:14:58AM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:02:12 +1000
> Stephen Rothwell  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:02:12 +1000
Stephen Rothwell  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

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

[Stephen Rothwell]

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


pgpYhnGcUI5Q1.pgp
Description: OpenPGP digital signature

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

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

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

[Jonathan Cameron]

> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: 04 December 2017 09:10
> To: Stephen Rothwell <s...@canb.auug.org.au>
> Cc: Linux-Next Mailing List <linux-n...@vger.kernel.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Xingyu Chen <xingyu.c...@amlogic.com>;
> Jonathan Cameron <jonathan.came...@huawei.com>; Martin Blumenstingl
> <martin.blumensti...@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

[Jonathan Cameron]

> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: 04 December 2017 09:10
> To: Stephen Rothwell 
> Cc: Linux-Next Mailing List ; Linux Kernel Mailing
> List ; Xingyu Chen ;
> Jonathan Cameron ; Martin Blumenstingl
> 
> 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.

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

[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

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..
--- 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);

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..
--- 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 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 
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

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 
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

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  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

[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  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 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 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

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..
--- 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..
--- 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/

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..
--- 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..
--- 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/

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/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

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

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/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..
--- 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;

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..
--- 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 27 April 2016 05:54:00 BST, Stephen Rothwell  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.

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  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/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..
--- 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(>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

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..
--- 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(>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

[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

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/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

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 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]

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]

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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/iio/adc/Kconfig
index 24c28e3f93a3,6cbf34a90c04..
--- 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


pgpqa6clTH_hj.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/iio/adc/Kconfig
index 24c28e3f93a3,6cbf34a90c04..
--- 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


pgpqa6clTH_hj.pgp
Description: PGP signature

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au


pgpRwB6NT_0R4.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au


pgpRwB6NT_0R4.pgp
Description: PGP signature

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/staging/cxt1e1/linux.c
> index 79206cb3fb94,579e68e3dece..
> --- 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 (, 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, 
> ) : -EFAULT;
> - if (ret == 0)   /* no error, copy data */
> - if (copy_to_user (data, , 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(, 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:
> + 

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/staging/cxt1e1/linux.c
index 79206cb3fb94,579e68e3dece..
--- 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 (, 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, 
) : -EFAULT;
- if (ret == 0)   /* no error, copy data */
- if (copy_to_user (data, , 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(, 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:
+

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/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 Rothwells...@canb.auug.org.au

diff --cc drivers/staging/cxt1e1/linux.c
index 79206cb3fb94,579e68e3dece..
--- 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, 

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 Rothwells...@canb.auug.org.au
 
 diff --cc drivers/staging/cxt1e1/linux.c
 index 79206cb3fb94,579e68e3dece..
 --- 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 

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
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 Rothwells...@canb.auug.org.au

diff --cc include/linux/hid-sensor-ids.h
index 8323775ac21d,4cc165887b09..
--- 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_STATE0x200316
  #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


pgp6ikLfO1KPi.pgp
Description: PGP signature

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
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 Rothwells...@canb.auug.org.au

diff --cc include/linux/hid-sensor-ids.h
index 8323775ac21d,4cc165887b09..
--- 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_STATE0x200316
  #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


pgp6ikLfO1KPi.pgp
Description: PGP signature

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au


pgpiFk0rFzpt4.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au


pgpiFk0rFzpt4.pgp
Description: PGP signature

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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Cameron]

Stephen Rothwell  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-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 Rothwells...@canb.auug.org.au

diff --cc drivers/iio/industrialio-event.c
index 6be65ef,2390e3d..000
--- 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(_int->wait.lock);
 -  fd = anon_inode_getfd("iio:event",
 -  _event_chrdev_fileops, ev_int, O_RDONLY | 
O_CLOEXEC);
 +  iio_device_get(indio_dev);
 +
 +  fd = anon_inode_getfd("iio:event", _event_chrdev_fileops,
-   indio_dev, O_RDONLY);
++  indio_dev, O_RDONLY | O_CLOEXEC);
if (fd < 0) {
spin_lock_irq(_int->wait.lock);
__clear_bit(IIO_BUSY_BIT_POS, _int->flags);


pgpiEKnHQ4MF2.pgp
Description: PGP signature

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-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 Rothwells...@canb.auug.org.au

diff --cc drivers/iio/industrialio-buffer.c
index 2710f72,2361fbc..000
--- 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(_buffer->buffer_list);
+   list_del_init(_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;


pgp4dZd1JWVOt.pgp
Description: PGP signature

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-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 Rothwells...@canb.auug.org.au

diff --cc drivers/iio/industrialio-buffer.c
index 2710f72,2361fbc..000
--- 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;


pgp4dZd1JWVOt.pgp
Description: PGP signature

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-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 Rothwells...@canb.auug.org.au

diff --cc drivers/iio/industrialio-event.c
index 6be65ef,2390e3d..000
--- 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);


pgpiEKnHQ4MF2.pgp
Description: PGP signature

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 s...@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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jonathan Cameron]

Stephen Rothwell s...@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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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: )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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: abbo...@mev.co.uk)=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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/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 Rothwells...@canb.auug.org.au


pgpzh3kcKSYvL.pgp
Description: PGP signature

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/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 Rothwells...@canb.auug.org.au


pgpzh3kcKSYvL.pgp
Description: PGP signature