linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the staging tree with the staging.current tree
@ 2017-12-04  1:50 Stephen Rothwell
  2017-12-04  9:09 ` Greg KH
  2017-12-06 14:50 ` Greg KH
  0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2017-12-04  1:50 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Xingyu Chen,
	Jonathan Cameron, Martin Blumenstingl

Hi Greg,

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

  drivers/iio/adc/meson_saradc.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2017-12-04  1:50 linux-next: manual merge of the staging tree with the staging.current tree Stephen Rothwell
@ 2017-12-04  9:09 ` Greg KH
  2017-12-04 10:00   ` Jonathan Cameron
  2017-12-06 14:50 ` Greg KH
  1 sibling, 1 reply; 79+ messages in thread
From: Greg KH @ 2017-12-04  9:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Xingyu Chen,
	Jonathan Cameron, Martin Blumenstingl

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* RE: linux-next: manual merge of the staging tree with the staging.current tree
  2017-12-04  9:09 ` Greg KH
@ 2017-12-04 10:00   ` Jonathan Cameron
  0 siblings, 0 replies; 79+ messages in thread
From: Jonathan Cameron @ 2017-12-04 10:00 UTC (permalink / raw)
  To: Greg KH, Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Xingyu Chen,
	Martin Blumenstingl



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: 04 December 2017 09:10
> To: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Linux-Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Xingyu Chen <xingyu.chen@amlogic.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>; Martin Blumenstingl
> <martin.blumenstingl@googlemail.com>
> Subject: Re: linux-next: manual merge of the staging tree with the
> staging.current tree
> 
> On Mon, Dec 04, 2017 at 12:50:45PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got a conflict in:
> >
> >   drivers/iio/adc/meson_saradc.c
> >
> > between commit:
> >
> >   d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on
> older SoCs")
> >
> > from the staging.current tree and commit:
> >
> >   930df4d853a8 ("iio: adc: meson-saradc: remove irrelevant clock "sana"")
> >
> > from the staging tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> 
> Thanks for the notification, merge looks correct to me, Jonathan?
> 
> greg k-h

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

Thanks Stephen,

Jonathan

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2017-12-04  1:50 linux-next: manual merge of the staging tree with the staging.current tree Stephen Rothwell
  2017-12-04  9:09 ` Greg KH
@ 2017-12-06 14:50 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2017-12-06 14:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Xingyu Chen,
	Jonathan Cameron, Martin Blumenstingl

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2022-06-14  2:24 Stephen Rothwell
  2022-06-14  6:42 ` Greg KH
@ 2022-06-20  7:00 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2022-06-20  7:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Larry Finger, Linux Kernel Mailing List, Linux Next Mailing List,
	Nam Cao

On Tue, Jun 14, 2022 at 12:24:48PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/r8188eu/os_dep/ioctl_linux.c
> 
> between commit:
> 
>   96f0a54e8e65 ("staging: r8188eu: Fix warning of array overflow in ioctl_linux.c")
> 
> from the staging.current tree and commit:
> 
>   ac663ae22f02 ("staging: r8188eu: replace FIELD_OFFSET with offsetof")
> 
> from the staging tree.
> 
> I fixed it up (I just used the latter) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Should now be resolved, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2022-06-14  2:24 Stephen Rothwell
@ 2022-06-14  6:42 ` Greg KH
  2022-06-20  7:00 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2022-06-14  6:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Larry Finger, Linux Kernel Mailing List, Linux Next Mailing List,
	Nam Cao

On Tue, Jun 14, 2022 at 12:24:48PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/r8188eu/os_dep/ioctl_linux.c
> 
> between commit:
> 
>   96f0a54e8e65 ("staging: r8188eu: Fix warning of array overflow in ioctl_linux.c")
> 
> from the staging.current tree and commit:
> 
>   ac663ae22f02 ("staging: r8188eu: replace FIELD_OFFSET with offsetof")
> 
> from the staging tree.
> 
> I fixed it up (I just used the latter) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

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

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2022-06-14  2:24 Stephen Rothwell
  2022-06-14  6:42 ` Greg KH
  2022-06-20  7:00 ` Greg KH
  0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2022-06-14  2:24 UTC (permalink / raw)
  To: Greg KH
  Cc: Greg Kroah-Hartman, Larry Finger, Linux Kernel Mailing List,
	Linux Next Mailing List, Nam Cao

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

Hi all,

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

  drivers/staging/r8188eu/os_dep/ioctl_linux.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2021-09-22  2:45 Stephen Rothwell
@ 2021-09-22  6:48 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2021-09-22  6:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, Larry Finger, Linux Kernel Mailing List,
	Linux Next Mailing List

On Wed, Sep 22, 2021 at 12:45:30PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/r8188eu/os_dep/ioctl_linux.c
> 
> between commit:
> 
>   aa3233ea7bdb ("staging: r8188eu: fix -Wrestrict warnings")
> 
> from the staging.current tree and commit:
> 
>   7bdedfef085b ("staging: r8188eu: Remove mp, a.k.a. manufacturing process, code")
> 
> from the staging tree.
> 
> I fixed it up (the latter removed the code updated by the former, so I
> did that) and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be mentioned
> to your upstream maintainer when your tree is submitted for merging.
> You may also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.

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

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2021-09-22  2:45 Stephen Rothwell
  2021-09-22  6:48 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2021-09-22  2:45 UTC (permalink / raw)
  To: Greg KH
  Cc: Arnd Bergmann, Greg Kroah-Hartman, Larry Finger,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  drivers/staging/r8188eu/os_dep/ioctl_linux.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2020-04-28 12:15   ` Greg KH
@ 2020-04-28 12:55     ` Stephen Rothwell
  0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2020-04-28 12:55 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Malcolm Priestley

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

Hi Greg,

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

Yep, thanks.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2020-04-24  6:45 ` Greg KH
@ 2020-04-28 12:15   ` Greg KH
  2020-04-28 12:55     ` Stephen Rothwell
  0 siblings, 1 reply; 79+ messages in thread
From: Greg KH @ 2020-04-28 12:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Malcolm Priestley

On Fri, Apr 24, 2020 at 08:45:55AM +0200, Greg KH wrote:
> On Fri, Apr 24, 2020 at 03:15:46PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the staging tree got a conflict in:
> > 
> >   drivers/staging/vt6656/main_usb.c
> > 
> > between commit:
> > 
> >   664ba5180234 ("staging: vt6656: Fix calling conditions of vnt_set_bss_mode")
> > 
> > from the staging.current tree and commit:
> > 
> >   463288b98190 ("staging: vt6556: vnt_rf_setpower convert to use ieee80211_channel.")
> > 
> > from the staging tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc drivers/staging/vt6656/main_usb.c
> > index 5f78cad3b647,3c76d3cb5bbe..000000000000
> > --- a/drivers/staging/vt6656/main_usb.c
> > +++ b/drivers/staging/vt6656/main_usb.c
> > @@@ -743,13 -740,8 +736,12 @@@ static void vnt_bss_info_changed(struc
> >   		vnt_update_pre_ed_threshold(priv, false);
> >   	}
> >   
> >  +	if (changed & (BSS_CHANGED_BASIC_RATES | BSS_CHANGED_ERP_PREAMBLE |
> >  +		       BSS_CHANGED_ERP_SLOT))
> >  +		vnt_set_bss_mode(priv);
> >  +
> > - 	if (changed & BSS_CHANGED_TXPOWER)
> > - 		vnt_rf_setpower(priv, priv->current_rate,
> > - 				conf->chandef.chan->hw_value);
> > + 	if (changed & (BSS_CHANGED_TXPOWER | BSS_CHANGED_BANDWIDTH))
> > + 		vnt_rf_setpower(priv, conf->chandef.chan);
> >   
> >   	if (changed & BSS_CHANGED_BEACON_ENABLED) {
> >   		dev_dbg(&priv->usb->dev,
> 
> 
> Thanks, that looks correct, I'll handle this when the staging.linus
> branch goes to Linus in a few days.

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2020-04-24  5:15 Stephen Rothwell
@ 2020-04-24  6:45 ` Greg KH
  2020-04-28 12:15   ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Greg KH @ 2020-04-24  6:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Malcolm Priestley

On Fri, Apr 24, 2020 at 03:15:46PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/vt6656/main_usb.c
> 
> between commit:
> 
>   664ba5180234 ("staging: vt6656: Fix calling conditions of vnt_set_bss_mode")
> 
> from the staging.current tree and commit:
> 
>   463288b98190 ("staging: vt6556: vnt_rf_setpower convert to use ieee80211_channel.")
> 
> from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/staging/vt6656/main_usb.c
> index 5f78cad3b647,3c76d3cb5bbe..000000000000
> --- a/drivers/staging/vt6656/main_usb.c
> +++ b/drivers/staging/vt6656/main_usb.c
> @@@ -743,13 -740,8 +736,12 @@@ static void vnt_bss_info_changed(struc
>   		vnt_update_pre_ed_threshold(priv, false);
>   	}
>   
>  +	if (changed & (BSS_CHANGED_BASIC_RATES | BSS_CHANGED_ERP_PREAMBLE |
>  +		       BSS_CHANGED_ERP_SLOT))
>  +		vnt_set_bss_mode(priv);
>  +
> - 	if (changed & BSS_CHANGED_TXPOWER)
> - 		vnt_rf_setpower(priv, priv->current_rate,
> - 				conf->chandef.chan->hw_value);
> + 	if (changed & (BSS_CHANGED_TXPOWER | BSS_CHANGED_BANDWIDTH))
> + 		vnt_rf_setpower(priv, conf->chandef.chan);
>   
>   	if (changed & BSS_CHANGED_BEACON_ENABLED) {
>   		dev_dbg(&priv->usb->dev,


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

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2020-04-24  5:15 Stephen Rothwell
  2020-04-24  6:45 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2020-04-24  5:15 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Malcolm Priestley

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

Hi all,

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

  drivers/staging/vt6656/main_usb.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-12-13  1:05 Stephen Rothwell
@ 2019-12-14 12:19 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2019-12-14 12:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Johan Hovold,
	Arnd Bergmann

On Fri, Dec 13, 2019 at 12:05:34PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/isdn/gigaset/usb-gigaset.c
> 
> between commits:
> 
>   53f35a39c386 ("staging: gigaset: fix general protection fault on probe")
>   84f60ca7b326 ("staging: gigaset: fix illegal free on probe errors")
>   ed9ed5a89acb ("staging: gigaset: add endpoint-type sanity check")
> 
> from the staging.current tree and commit:
> 
>   f10870b05d5e ("staging: remove isdn capi drivers")
> 
> from the staging tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Thanks, I knew this would happen :)

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2019-12-13  1:05 Stephen Rothwell
  2019-12-14 12:19 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2019-12-13  1:05 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Johan Hovold,
	Arnd Bergmann

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

Hi all,

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

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

between commits:

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

from the staging.current tree and commit:

  f10870b05d5e ("staging: remove isdn capi drivers")

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-09 15:39           ` Andy Shevchenko
@ 2019-04-10  6:34             ` Alexandru Ardelean
  0 siblings, 0 replies; 79+ messages in thread
From: Alexandru Ardelean @ 2019-04-10  6:34 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Jonathan Cameron, Stephen Rothwell, Greg KH,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Lars-Peter Clausen, linux-iio, Alexandru Ardelean

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

Hey,

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

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

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

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

Sorry for the noise.

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

Thanks
Alex

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-08 12:01         ` Jonathan Cameron
@ 2019-04-09 15:39           ` Andy Shevchenko
  2019-04-10  6:34             ` Alexandru Ardelean
  0 siblings, 1 reply; 79+ messages in thread
From: Andy Shevchenko @ 2019-04-09 15:39 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Stephen Rothwell, Greg KH, Linux Next Mailing List,
	Linux Kernel Mailing List, Lars-Peter Clausen, linux-iio,
	Alexandru Ardelean

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

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

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

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

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-08 10:34       ` Andy Shevchenko
@ 2019-04-08 12:01         ` Jonathan Cameron
  2019-04-09 15:39           ` Andy Shevchenko
  0 siblings, 1 reply; 79+ messages in thread
From: Jonathan Cameron @ 2019-04-08 12:01 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Stephen Rothwell, Greg KH, Linux Next Mailing List,
	Linux Kernel Mailing List, Lars-Peter Clausen, linux-iio,
	Alexandru Ardelean

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

> On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote:
> > On Mon, 8 Apr 2019 13:01:21 +0300
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:  
> > > > On Mon, 8 Apr 2019 13:02:12 +1000
> > > > Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> 
> > > > > Today's linux-next merge of the staging tree got a conflict in:
> > > > > 
> > > > >   drivers/iio/industrialio-buffer.c
> > > > > 
> > > > > between commit:
> > > > > 
> > > > >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > > > > 
> > > > > from the staging.current tree and commit:
> > > > > 
> > > > >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > > > > 
> > > > > from the staging tree.
> > > > > 
> > > > > I fixed it up (I just used the staging tree version) and can carry the
> > > > > fix as necessary. This is now fixed as far as linux-next is concerned,
> > > > > but any non trivial conflicts should be mentioned to your upstream
> > > > > maintainer when your tree is submitted for merging.  You may also want
> > > > > to consider cooperating with the maintainer of the conflicting tree to
> > > > > minimise any particularly complex conflicts.
> > > > >     
> > > > Thanks Stephen,
> > > > 
> > > > That is the correct resolution.    
> > > 
> > > I think it still misses the following fix:  
> 
> > Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
> > The two masks are the same length so I don't think we have a problem with this one.
> > Am I missing something?  
> 
> Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything.
> 
Good point.  I'm don't think it ever did.  

Alex, any thoughts?

Jonathan

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-08 10:14     ` Jonathan Cameron
@ 2019-04-08 10:34       ` Andy Shevchenko
  2019-04-08 12:01         ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Andy Shevchenko @ 2019-04-08 10:34 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Stephen Rothwell, Greg KH, Linux Next Mailing List,
	Linux Kernel Mailing List, Lars-Peter Clausen, linux-iio

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

> > > > Today's linux-next merge of the staging tree got a conflict in:
> > > > 
> > > >   drivers/iio/industrialio-buffer.c
> > > > 
> > > > between commit:
> > > > 
> > > >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > > > 
> > > > from the staging.current tree and commit:
> > > > 
> > > >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > > > 
> > > > from the staging tree.
> > > > 
> > > > I fixed it up (I just used the staging tree version) and can carry the
> > > > fix as necessary. This is now fixed as far as linux-next is concerned,
> > > > but any non trivial conflicts should be mentioned to your upstream
> > > > maintainer when your tree is submitted for merging.  You may also want
> > > > to consider cooperating with the maintainer of the conflicting tree to
> > > > minimise any particularly complex conflicts.
> > > >   
> > > Thanks Stephen,
> > > 
> > > That is the correct resolution.  
> > 
> > I think it still misses the following fix:

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

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

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-08 10:01   ` Andy Shevchenko
@ 2019-04-08 10:14     ` Jonathan Cameron
  2019-04-08 10:34       ` Andy Shevchenko
  0 siblings, 1 reply; 79+ messages in thread
From: Jonathan Cameron @ 2019-04-08 10:14 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Stephen Rothwell, Greg KH, Linux Next Mailing List,
	Linux Kernel Mailing List, Lars-Peter Clausen, linux-iio

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

> On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:
> > On Mon, 8 Apr 2019 13:02:12 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >   
> > > Hi all,
> > > 
> > > Today's linux-next merge of the staging tree got a conflict in:
> > > 
> > >   drivers/iio/industrialio-buffer.c
> > > 
> > > between commit:
> > > 
> > >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > > 
> > > from the staging.current tree and commit:
> > > 
> > >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > > 
> > > from the staging tree.
> > > 
> > > I fixed it up (I just used the staging tree version) and can carry the
> > > fix as necessary. This is now fixed as far as linux-next is concerned,
> > > but any non trivial conflicts should be mentioned to your upstream
> > > maintainer when your tree is submitted for merging.  You may also want
> > > to consider cooperating with the maintainer of the conflicting tree to
> > > minimise any particularly complex conflicts.
> > >   
> > Thanks Stephen,
> > 
> > That is the correct resolution.  
> 
> I think it still misses the following fix:
> 
Hi Andy,

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

Jonathan


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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-08  8:14 ` Jonathan Cameron
@ 2019-04-08 10:01   ` Andy Shevchenko
  2019-04-08 10:14     ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Andy Shevchenko @ 2019-04-08 10:01 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Stephen Rothwell, Greg KH, Linux Next Mailing List,
	Linux Kernel Mailing List, Lars-Peter Clausen

On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:02:12 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the staging tree got a conflict in:
> > 
> >   drivers/iio/industrialio-buffer.c
> > 
> > between commit:
> > 
> >   20ea39ef9f2f ("iio: Fix scan mask selection")
> > 
> > from the staging.current tree and commit:
> > 
> >   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> > 
> > from the staging tree.
> > 
> > I fixed it up (I just used the staging tree version) and can carry the
> > fix as necessary. This is now fixed as far as linux-next is concerned,
> > but any non trivial conflicts should be mentioned to your upstream
> > maintainer when your tree is submitted for merging.  You may also want
> > to consider cooperating with the maintainer of the conflicting tree to
> > minimise any particularly complex conflicts.
> > 
> Thanks Stephen,
> 
> That is the correct resolution.

I think it still misses the following fix:

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


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2019-04-08  3:02 Stephen Rothwell
@ 2019-04-08  8:14 ` Jonathan Cameron
  2019-04-08 10:01   ` Andy Shevchenko
  0 siblings, 1 reply; 79+ messages in thread
From: Jonathan Cameron @ 2019-04-08  8:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, Linux Next Mailing List, Linux Kernel Mailing List,
	Andy Shevchenko, Lars-Peter Clausen

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

> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/iio/industrialio-buffer.c
> 
> between commit:
> 
>   20ea39ef9f2f ("iio: Fix scan mask selection")
> 
> from the staging.current tree and commit:
> 
>   3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
> 
> from the staging tree.
> 
> I fixed it up (I just used the staging tree version) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.  You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
> 
Thanks Stephen,

That is the correct resolution.

Jonathan

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2019-04-08  3:02 Stephen Rothwell
  2019-04-08  8:14 ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2019-04-08  3:02 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andy Shevchenko, Jonathan Cameron, Lars-Peter Clausen

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

Hi all,

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

  drivers/iio/industrialio-buffer.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2017-07-19  8:30   ` Marcus Wolf
@ 2017-07-20  8:19     ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2017-07-20  8:19 UTC (permalink / raw)
  To: Marcus Wolf
  Cc: Linux Kernel Mailing List, Hans de Goede,
	Linux-Next Mailing List, Stephen Rothwell

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

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

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2017-07-19  6:07 ` Greg KH
@ 2017-07-19  8:30   ` Marcus Wolf
  2017-07-20  8:19     ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Marcus Wolf @ 2017-07-19  8:30 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Kernel Mailing List, Hans de Goede,
	Linux-Next Mailing List, Stephen Rothwell

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

> Greg KH <greg@kroah.com> hat am 19. Juli 2017 um 08:07 geschrieben:
>
>
> On Wed, Jul 19, 2017 at 01:07:28PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got conflicts in:
> >
> > drivers/staging/Kconfig
> > drivers/staging/Makefile
> >
> > between commit:
> >
> > dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
> >
> > from the staging.current tree and commit:
> >
> > 874bcba65f9a ("staging: pi433: New driver")
> >
> > from the staging tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Yeah, I know this is going to happen, I'll be fixing it up when
> staging-linus gets into Linus's tree.
>
> thanks,
>
> greg k-h
>

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2017-07-19  3:07 Stephen Rothwell
@ 2017-07-19  6:07 ` Greg KH
  2017-07-19  8:30   ` Marcus Wolf
  0 siblings, 1 reply; 79+ messages in thread
From: Greg KH @ 2017-07-19  6:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Hans de Goede, Marcus Wolf

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2017-07-19  3:07 Stephen Rothwell
  2017-07-19  6:07 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2017-07-19  3:07 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Hans de Goede, Marcus Wolf

Hi Greg,

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

  drivers/staging/Kconfig
  drivers/staging/Makefile

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2017-01-30  3:59 Stephen Rothwell
  0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2017-01-30  3:59 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Rui Miguel Silva

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2016-06-14  5:04 Stephen Rothwell
@ 2016-06-19 20:17 ` Jonathan Cameron
  0 siblings, 0 replies; 79+ messages in thread
From: Jonathan Cameron @ 2016-06-19 20:17 UTC (permalink / raw)
  To: Stephen Rothwell, Greg KH; +Cc: linux-next, linux-kernel, Crestez Dan Leonard

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2016-06-14  5:04 Stephen Rothwell
  2016-06-19 20:17 ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2016-06-14  5:04 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Crestez Dan Leonard, Jonathan Cameron

Hi Greg,

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

  drivers/iio/industrialio-trigger.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2016-04-27  4:54 Stephen Rothwell
@ 2016-04-27 12:37 ` Jonathan Cameron
  0 siblings, 0 replies; 79+ messages in thread
From: Jonathan Cameron @ 2016-04-27 12:37 UTC (permalink / raw)
  To: Stephen Rothwell, Greg KH
  Cc: linux-next, linux-kernel, Gregor Boirie, Jonathan Cameron,
	Richard Leitner



On 27 April 2016 05:54:00 BST, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>Hi Greg,
>
>Today's linux-next merge of the staging tree got a conflict in:
>
>  drivers/iio/magnetometer/ak8975.c
>
>between commit:
>
>  05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning")
>
>from the staging.current tree and commit:
>
>  97eacb9166f4 ("iio:ak8975: add mounting matrix support")
>
>from the staging tree.
>
>I fixed it up (see below) and can carry the fix as necessary. This
>is now fixed as far as linux-next is concerned, but any non trivial
>conflicts should be mentioned to your upstream maintainer when your
>tree
>is submitted for merging.  You may also want to consider cooperating
>with the maintainer of the conflicting tree to minimise any
>particularly
>complex conflicts.

Hi Stephen,

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

Fix looks good, thanks

Jonathan

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2016-04-27  4:54 Stephen Rothwell
  2016-04-27 12:37 ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2016-04-27  4:54 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Gregor Boirie, Jonathan Cameron,
	Richard Leitner

Hi Greg,

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

  drivers/iio/magnetometer/ak8975.c

between commit:

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

from the staging.current tree and commit:

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

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2016-04-05  3:03 Stephen Rothwell
@ 2016-04-05  4:41 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2016-04-05  4:41 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Irina Tirdea, Jonathan Cameron

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2016-04-05  3:03 Stephen Rothwell
  2016-04-05  4:41 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2016-04-05  3:03 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Irina Tirdea, Jonathan Cameron

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2016-02-01  3:45 Stephen Rothwell
@ 2016-02-01  4:01 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2016-02-01  4:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Sudip Mukherjee, Ricardo Ruedas

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2016-02-01  3:45 Stephen Rothwell
  2016-02-01  4:01 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2016-02-01  3:45 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Sudip Mukherjee, Ricardo Ruedas

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2014-05-01  4:37 Stephen Rothwell
@ 2014-05-01  4:47 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2014-05-01  4:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Doug Anderson, Jonathan Cameron, Jean Delvare

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2014-05-01  4:37 Stephen Rothwell
  2014-05-01  4:47 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2014-05-01  4:37 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Doug Anderson, Jonathan Cameron, Jean Delvare

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/adc/Kconfig between commit bbc28134e915 ("iio: adc: Nothing
in ADC should be a bool CONFIG") from the staging.current tree and commit
9ef080ec0c5e ("iio: adc: Fix exynos_adc dependencies") from the staging
tree.

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

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

diff --cc drivers/iio/adc/Kconfig
index 24c28e3f93a3,6cbf34a90c04..000000000000
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@@ -106,8 -117,8 +117,8 @@@ config AT91_AD
  	  Say yes here to build support for Atmel AT91 ADC.
  
  config EXYNOS_ADC
 -	bool "Exynos ADC driver support"
 +	tristate "Exynos ADC driver support"
- 	depends on OF
+ 	depends on ARCH_EXYNOS || (OF && COMPILE_TEST)
  	help
  	  Core support for the ADC block found in the Samsung EXYNOS series
  	  of SoCs for drivers such as the touchscreen and hwmon to use to share

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2014-04-17  4:31 Stephen Rothwell
@ 2014-04-17 16:17 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2014-04-17 16:17 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Jes Sorensen

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2014-04-17  4:31 Stephen Rothwell
  2014-04-17 16:17 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2014-04-17  4:31 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Jes Sorensen

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

Hi Greg,

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

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2014-03-06  5:06 Stephen Rothwell
  2014-03-06  5:11 ` Greg KH
@ 2014-03-17 18:29 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2014-03-17 18:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, "Salva Peiró", Daeseok Youn

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2014-03-06  5:06 Stephen Rothwell
@ 2014-03-06  5:11 ` Greg KH
  2014-03-17 18:29 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2014-03-06  5:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, "Salva Peiró", Daeseok Youn

On Thu, Mar 06, 2014 at 04:06:49PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/cxt1e1/linux.c between commit 084b6e7765b9
> ("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
> from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
> remove space between function name and parenthesis") and a couple of
> others from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks, that looks good.

greg k-h

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2014-03-06  5:06 Stephen Rothwell
  2014-03-06  5:11 ` Greg KH
  2014-03-17 18:29 ` Greg KH
  0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2014-03-06  5:06 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, "Salva Peiró", Daeseok Youn

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/cxt1e1/linux.c between commit 084b6e7765b9
("staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()")
from the staging.current tree and commit 922b81b835c4 ("staging: cxt1e1:
remove space between function name and parenthesis") and a couple of
others from the staging tree.

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

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2013-12-04  2:06 Stephen Rothwell
  0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2013-12-04  2:06 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Srinivas Pandruvada, Jonathan Cameron

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
include/linux/hid-sensor-ids.h between commit 751d17e23a9f ("iio:
hid-sensors: Fix power and report state") from the staging.current tree
and commit 64528d03d723 ("iio: hid-sensors: accelerometer: Add
sensitivity") from the staging tree.

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

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

diff --cc include/linux/hid-sensor-ids.h
index 8323775ac21d,4cc165887b09..000000000000
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@@ -117,16 -121,8 +121,20 @@@
  #define HID_USAGE_SENSOR_PROP_REPORT_STATE			0x200316
  #define HID_USAGE_SENSOR_PROY_POWER_STATE			0x200319
  
 +/* Power state enumerations */
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_UNDEFINED_ENUM		0x00
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D0_FULL_POWER_ENUM		0x01
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D1_LOW_POWER_ENUM		0x02
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D2_STANDBY_WITH_WAKE_ENUM	0x03
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D3_SLEEP_WITH_WAKE_ENUM	0x04
 +#define HID_USAGE_SENSOR_PROP_POWER_STATE_D4_POWER_OFF_ENUM		0x05
 +
 +/* Report State enumerations */
 +#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM		0x00
 +#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM		0x01
 +
+ /* Per data field properties */
+ #define HID_USAGE_SENSOR_DATA_MOD_NONE					0x00
+ #define HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS		0x1000
+ 
  #endif

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2013-11-27  2:01 Stephen Rothwell
@ 2013-11-27  3:20 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2013-11-27  3:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Rashika Kheria

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2013-11-27  2:01 Stephen Rothwell
  2013-11-27  3:20 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2013-11-27  2:01 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Rashika Kheria

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

Hi Greg,

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

I just removed the files and can carry the fix as necessary (no action
is required).

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2013-09-23  3:16 Stephen Rothwell
@ 2013-09-23  5:54 ` Jonathan Cameron
  0 siblings, 0 replies; 79+ messages in thread
From: Jonathan Cameron @ 2013-09-23  5:54 UTC (permalink / raw)
  To: Stephen Rothwell, Greg KH
  Cc: linux-next, linux-kernel, Peter Meerwald, Lars-Peter Clausen



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

Thanks Stephen.

The merge is correct.

Jonathan

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2013-09-23  3:21 Stephen Rothwell
@ 2013-09-23  5:52 ` Jonathan Cameron
  0 siblings, 0 replies; 79+ messages in thread
From: Jonathan Cameron @ 2013-09-23  5:52 UTC (permalink / raw)
  To: Stephen Rothwell, Greg KH
  Cc: linux-next, linux-kernel, Yann Droneaud, Lars-Peter Clausen

Thanks Stephen.

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

Both are are correctly merged by Stephen.

Jonathan



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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2013-09-23  3:21 Stephen Rothwell
  2013-09-23  5:52 ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2013-09-23  3:21 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Yann Droneaud, Jonathan Cameron,
	Lars-Peter Clausen

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/industrialio-event.c between commit cadc2125e140 ("iio: fix:
Keep a reference to the IIO device for open file descriptors") from the
staging.current tree and commit a646fbf0fd11 ("iio: use anon_inode_getfd
() with O_CLOEXEC flag") from the staging tree.

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

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

diff --cc drivers/iio/industrialio-event.c
index 6be65ef,2390e3d..0000000
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@@ -163,10 -158,8 +163,10 @@@ int iio_event_getfd(struct iio_dev *ind
  		return -EBUSY;
  	}
  	spin_unlock_irq(&ev_int->wait.lock);
 -	fd = anon_inode_getfd("iio:event",
 -				&iio_event_chrdev_fileops, ev_int, O_RDONLY | O_CLOEXEC);
 +	iio_device_get(indio_dev);
 +
 +	fd = anon_inode_getfd("iio:event", &iio_event_chrdev_fileops,
- 				indio_dev, O_RDONLY);
++				indio_dev, O_RDONLY | O_CLOEXEC);
  	if (fd < 0) {
  		spin_lock_irq(&ev_int->wait.lock);
  		__clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2013-09-23  3:16 Stephen Rothwell
  2013-09-23  5:54 ` Jonathan Cameron
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2013-09-23  3:16 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Peter Meerwald, Jonathan Cameron,
	Lars-Peter Clausen

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

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/iio/industrialio-buffer.c between commit d66e0452bf6b ("iio: Fix
crash when scan_bytes is computed with active_scan_mask == NUL") from the
staging.current tree and commit 705ee2c98a37 ("iio:buffer: Simplify
iio_buffer_is_active()") from the staging tree.

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

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

diff --cc drivers/iio/industrialio-buffer.c
index 2710f72,2361fbc..0000000
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@@ -546,16 -521,9 +540,16 @@@ int iio_update_buffers(struct iio_dev *
  			 * Roll back.
  			 * Note can only occur when adding a buffer.
  			 */
- 			list_del(&insert_buffer->buffer_list);
+ 			list_del_init(&insert_buffer->buffer_list);
 -			indio_dev->active_scan_mask = old_mask;
 -			success = -EINVAL;
 +			if (old_mask) {
 +				indio_dev->active_scan_mask = old_mask;
 +				success = -EINVAL;
 +			}
 +			else {
 +				kfree(compound_mask);
 +				ret = -EINVAL;
 +				goto error_ret;
 +			}
  		}
  	} else {
  		indio_dev->active_scan_mask = compound_mask;

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2012-10-25  2:19 Stephen Rothwell
@ 2012-10-25 12:42 ` Ian Abbott
  0 siblings, 0 replies; 79+ messages in thread
From: Ian Abbott @ 2012-10-25 12:42 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Ian Abbott

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

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

Apologies for the inconvenience it caused you.

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2012-10-25  2:19 Stephen Rothwell
  2012-10-25 12:42 ` Ian Abbott
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2012-10-25  2:19 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Ian Abbott

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

Hi Greg,

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

I fixed it up (the latter is a superset of the former) and can carry the
fix as necessary (no action is required).

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-06-28 14:07     ` Arjan Mels
@ 2011-06-28 14:43       ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-06-28 14:43 UTC (permalink / raw)
  To: Arjan Mels; +Cc: Stephen Rothwell, linux-next, linux-kernel, matt mooney

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

What do you mean by "other stable branches"?

> What do I need to do to correct this?

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

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-06-09 20:51   ` Greg KH
@ 2011-06-28 14:07     ` Arjan Mels
  2011-06-28 14:43       ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Arjan Mels @ 2011-06-28 14:07 UTC (permalink / raw)
  To: Greg KH, Stephen Rothwell; +Cc: linux-next, linux-kernel, matt mooney

Greg, Stephen,

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

What do I need to do to correct this?

Best Regards,

Arjan

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




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

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

This should now be resolved.

greg k-h 

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-06-09 18:42 ` Greg KH
@ 2011-06-09 20:51   ` Greg KH
  2011-06-28 14:07     ` Arjan Mels
  0 siblings, 1 reply; 79+ messages in thread
From: Greg KH @ 2011-06-09 20:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Arjan Mels, matt mooney

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

This should now be resolved.

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-06-09 18:41 ` Greg KH
@ 2011-06-09 20:51   ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-06-09 20:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Roland Vossen

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

This should now be resolved.

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-06-09  6:58 Stephen Rothwell
@ 2011-06-09 18:42 ` Greg KH
  2011-06-09 20:51   ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Greg KH @ 2011-06-09 18:42 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Arjan Mels, matt mooney

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

Looks correct, thanks for doing this.

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-06-09  6:58 Stephen Rothwell
@ 2011-06-09 18:41 ` Greg KH
  2011-06-09 20:51   ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Greg KH @ 2011-06-09 18:41 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Roland Vossen

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

Thanks for the fix, it sounds correct.

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2011-06-09  6:58 Stephen Rothwell
  2011-06-09 18:41 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2011-06-09  6:58 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Roland Vossen

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

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2011-06-09  6:58 Stephen Rothwell
  2011-06-09 18:42 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2011-06-09  6:58 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Arjan Mels, matt mooney

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-04-06  4:41 Stephen Rothwell
@ 2011-04-06  5:12 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-04-06  5:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Olaf Hering, Hank Janssen,
	Haiyang Zhang, K. Y. Srinivasan

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2011-04-06  4:41 Stephen Rothwell
  2011-04-06  5:12 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2011-04-06  4:41 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Olaf Hering, Hank Janssen,
	Haiyang Zhang, K. Y. Srinivasan

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-02-10  5:35 Stephen Rothwell
                   ` (2 preceding siblings ...)
  2011-02-10 18:50 ` Greg KH
@ 2011-02-18 20:13 ` Greg KH
  3 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-02-18 20:13 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Nitin Gupta, Robert Jennings

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-02-10  5:35 Stephen Rothwell
  2011-02-10 11:24 ` Nitin Gupta
  2011-02-10 14:43 ` Robert Jennings
@ 2011-02-10 18:50 ` Greg KH
  2011-02-18 20:13 ` Greg KH
  3 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-02-10 18:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Nitin Gupta, Robert Jennings

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

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

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-02-10  5:35 Stephen Rothwell
  2011-02-10 11:24 ` Nitin Gupta
@ 2011-02-10 14:43 ` Robert Jennings
  2011-02-10 18:50 ` Greg KH
  2011-02-18 20:13 ` Greg KH
  3 siblings, 0 replies; 79+ messages in thread
From: Robert Jennings @ 2011-02-10 14:43 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Nitin Gupta

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

This is correct, thanks.

--Rob Jennings

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-02-10  5:35 Stephen Rothwell
@ 2011-02-10 11:24 ` Nitin Gupta
  2011-02-10 14:43 ` Robert Jennings
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 79+ messages in thread
From: Nitin Gupta @ 2011-02-10 11:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Robert Jennings

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

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

Nitin

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2011-02-10  5:35 Stephen Rothwell
  2011-02-10 11:24 ` Nitin Gupta
                   ` (3 more replies)
  0 siblings, 4 replies; 79+ messages in thread
From: Stephen Rothwell @ 2011-02-10  5:35 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Nitin Gupta, Robert Jennings

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-01-31  5:09 Stephen Rothwell
  2011-01-31  8:52 ` Arend van Spriel
@ 2011-02-02 21:58 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-02-02 21:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Arend van Spriel

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-01-31  5:16 Stephen Rothwell
  2011-01-31 18:47 ` Greg KH
@ 2011-02-02 21:58 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-02-02 21:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Dan Carpenter, Wolfram Sang

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-01-31  5:16 Stephen Rothwell
@ 2011-01-31 18:47 ` Greg KH
  2011-02-02 21:58 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Greg KH @ 2011-01-31 18:47 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Dan Carpenter, Wolfram Sang

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

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

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2011-01-31  5:09 Stephen Rothwell
@ 2011-01-31  8:52 ` Arend van Spriel
  2011-02-02 21:58 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Arend van Spriel @ 2011-01-31  8:52 UTC (permalink / raw)
  To: Greg KH, Stephen Rothwell; +Cc: linux-next, linux-kernel

Hi Stephen,

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

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

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

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2011-01-31  5:16 Stephen Rothwell
  2011-01-31 18:47 ` Greg KH
  2011-02-02 21:58 ` Greg KH
  0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2011-01-31  5:16 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Dan Carpenter, Wolfram Sang

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2011-01-31  5:09 Stephen Rothwell
  2011-01-31  8:52 ` Arend van Spriel
  2011-02-02 21:58 ` Greg KH
  0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2011-01-31  5:09 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Arend van Spriel

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2010-12-02  4:00 ` Greg KH
@ 2010-12-08 22:27   ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2010-12-08 22:27 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Randy Dunlap, Pekka Enberg

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

Now merged so this conflict should have gone away.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2010-12-02  2:22 Stephen Rothwell
  2010-12-02  3:20 ` Randy Dunlap
@ 2010-12-02  4:00 ` Greg KH
  2010-12-08 22:27   ` Greg KH
  1 sibling, 1 reply; 79+ messages in thread
From: Greg KH @ 2010-12-02  4:00 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Randy Dunlap, Pekka Enberg

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2010-12-02  2:22 Stephen Rothwell
@ 2010-12-02  3:20 ` Randy Dunlap
  2010-12-02  4:00 ` Greg KH
  1 sibling, 0 replies; 79+ messages in thread
From: Randy Dunlap @ 2010-12-02  3:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Pekka Enberg

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2010-12-02  2:22 Stephen Rothwell
  2010-12-02  3:20 ` Randy Dunlap
  2010-12-02  4:00 ` Greg KH
  0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2010-12-02  2:22 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Randy Dunlap, Pekka Enberg

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

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

* Re: linux-next: manual merge of the staging tree with the staging.current tree
  2010-11-10  2:24 Stephen Rothwell
@ 2010-11-10 18:40 ` Greg KH
  0 siblings, 0 replies; 79+ messages in thread
From: Greg KH @ 2010-11-10 18:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Dan Carpenter, Stephen Hemminger

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

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

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 79+ messages in thread

* linux-next: manual merge of the staging tree with the staging.current tree
@ 2010-11-10  2:24 Stephen Rothwell
  2010-11-10 18:40 ` Greg KH
  0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2010-11-10  2:24 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Dan Carpenter, Stephen Hemminger

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

Hi Greg,

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

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

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

^ permalink raw reply	[flat|nested] 79+ messages in thread

end of thread, other threads:[~2022-06-20  7:01 UTC | newest]

Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-04  1:50 linux-next: manual merge of the staging tree with the staging.current tree Stephen Rothwell
2017-12-04  9:09 ` Greg KH
2017-12-04 10:00   ` Jonathan Cameron
2017-12-06 14:50 ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2022-06-14  2:24 Stephen Rothwell
2022-06-14  6:42 ` Greg KH
2022-06-20  7:00 ` Greg KH
2021-09-22  2:45 Stephen Rothwell
2021-09-22  6:48 ` Greg KH
2020-04-24  5:15 Stephen Rothwell
2020-04-24  6:45 ` Greg KH
2020-04-28 12:15   ` Greg KH
2020-04-28 12:55     ` Stephen Rothwell
2019-12-13  1:05 Stephen Rothwell
2019-12-14 12:19 ` Greg KH
2019-04-08  3:02 Stephen Rothwell
2019-04-08  8:14 ` Jonathan Cameron
2019-04-08 10:01   ` Andy Shevchenko
2019-04-08 10:14     ` Jonathan Cameron
2019-04-08 10:34       ` Andy Shevchenko
2019-04-08 12:01         ` Jonathan Cameron
2019-04-09 15:39           ` Andy Shevchenko
2019-04-10  6:34             ` Alexandru Ardelean
2017-07-19  3:07 Stephen Rothwell
2017-07-19  6:07 ` Greg KH
2017-07-19  8:30   ` Marcus Wolf
2017-07-20  8:19     ` Greg KH
2017-01-30  3:59 Stephen Rothwell
2016-06-14  5:04 Stephen Rothwell
2016-06-19 20:17 ` Jonathan Cameron
2016-04-27  4:54 Stephen Rothwell
2016-04-27 12:37 ` Jonathan Cameron
2016-04-05  3:03 Stephen Rothwell
2016-04-05  4:41 ` Greg KH
2016-02-01  3:45 Stephen Rothwell
2016-02-01  4:01 ` Greg KH
2014-05-01  4:37 Stephen Rothwell
2014-05-01  4:47 ` Greg KH
2014-04-17  4:31 Stephen Rothwell
2014-04-17 16:17 ` Greg KH
2014-03-06  5:06 Stephen Rothwell
2014-03-06  5:11 ` Greg KH
2014-03-17 18:29 ` Greg KH
2013-12-04  2:06 Stephen Rothwell
2013-11-27  2:01 Stephen Rothwell
2013-11-27  3:20 ` Greg KH
2013-09-23  3:21 Stephen Rothwell
2013-09-23  5:52 ` Jonathan Cameron
2013-09-23  3:16 Stephen Rothwell
2013-09-23  5:54 ` Jonathan Cameron
2012-10-25  2:19 Stephen Rothwell
2012-10-25 12:42 ` Ian Abbott
2011-06-09  6:58 Stephen Rothwell
2011-06-09 18:41 ` Greg KH
2011-06-09 20:51   ` Greg KH
2011-06-09  6:58 Stephen Rothwell
2011-06-09 18:42 ` Greg KH
2011-06-09 20:51   ` Greg KH
2011-06-28 14:07     ` Arjan Mels
2011-06-28 14:43       ` Greg KH
2011-04-06  4:41 Stephen Rothwell
2011-04-06  5:12 ` Greg KH
2011-02-10  5:35 Stephen Rothwell
2011-02-10 11:24 ` Nitin Gupta
2011-02-10 14:43 ` Robert Jennings
2011-02-10 18:50 ` Greg KH
2011-02-18 20:13 ` Greg KH
2011-01-31  5:16 Stephen Rothwell
2011-01-31 18:47 ` Greg KH
2011-02-02 21:58 ` Greg KH
2011-01-31  5:09 Stephen Rothwell
2011-01-31  8:52 ` Arend van Spriel
2011-02-02 21:58 ` Greg KH
2010-12-02  2:22 Stephen Rothwell
2010-12-02  3:20 ` Randy Dunlap
2010-12-02  4:00 ` Greg KH
2010-12-08 22:27   ` Greg KH
2010-11-10  2:24 Stephen Rothwell
2010-11-10 18:40 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).