linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

Hi Kalle,

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

  drivers/net/wireless/intel/iwlwifi/mvm/tx.c

between commit:

  909b27f70643 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")

from the net-next tree and commit:

  a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes")

from the wireless-drivers-next tree.

I fixed it up (I think that the net-next tree merge lost the changes
to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f ("iwlwifi:
mvm: don't override the rate with the AMSDU len")) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

Hi Kalle,

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

  drivers/net/wireless/intel/iwlwifi/mvm/tx.c

between commit:

  909b27f70643 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")

from the net-next tree and commit:

  a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes")

from the wireless-drivers-next tree.

I fixed it up (I think that the net-next tree merge lost the changes
to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f ("iwlwifi:
mvm: don't override the rate with the AMSDU len")) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

[Kalle Valo]

(Adding Luca and linux-wireless)

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

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
>
> between commit:
>
>   909b27f70643 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> from the net-next tree and commit:
>
>   a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (I think that the net-next tree merge lost the changes
> to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f ("iwlwifi:
> mvm: don't override the rate with the AMSDU len")) and can carry the
> fix as necessary.

Hmm, I'm starting to suspect something is wrong. I did a test merge of
net-next and wireless-drivers-next and got this as a diff after the
merge:

--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
                        struct iwl_tx_cmd *tx_cmd,
                        struct ieee80211_tx_info *info, u8 sta_id)
 {
-       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
        struct ieee80211_hdr *hdr = (void *)skb->data;
        __le16 fc = hdr->frame_control;
        u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
        tx_cmd->tx_flags = cpu_to_le32(tx_flags);
        /* Total # bytes to be transmitted */
        tx_cmd->len = cpu_to_le16((u16)skb->len +
-               (uintptr_t)skb_info->driver_data[0]);
+               (uintptr_t)info->driver_data[0]);
        tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
        tx_cmd->sta_id = sta_id;

But commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
AMSDU len") specifically added skb_info variable to that function:

@@ -105,6 +105,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
                        struct iwl_tx_cmd *tx_cmd,
                        struct ieee80211_tx_info *info, u8 sta_id)
 {
+       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
        struct ieee80211_hdr *hdr = (void *)skb->data;
        __le16 fc = hdr->frame_control;
        u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -185,7 +186,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
        tx_cmd->tx_flags = cpu_to_le32(tx_flags);
        /* Total # bytes to be transmitted */
        tx_cmd->len = cpu_to_le16((u16)skb->len +
-               (uintptr_t)info->driver_data[0]);
+               (uintptr_t)skb_info->driver_data[0]);
        tx_cmd->next_frame_len = 0;
        tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
        tx_cmd->sta_id = sta_id;

I wasn't expecting that skb_info variable is removed. Do we now have
merge damage somewhere? Luca, what do you think?

-- 
Kalle Valo

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

[Kalle Valo]

(Adding Luca and linux-wireless)

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

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
>
> between commit:
>
>   909b27f70643 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> from the net-next tree and commit:
>
>   a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (I think that the net-next tree merge lost the changes
> to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f ("iwlwifi:
> mvm: don't override the rate with the AMSDU len")) and can carry the
> fix as necessary.

Hmm, I'm starting to suspect something is wrong. I did a test merge of
net-next and wireless-drivers-next and got this as a diff after the
merge:

--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
                        struct iwl_tx_cmd *tx_cmd,
                        struct ieee80211_tx_info *info, u8 sta_id)
 {
-       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
        struct ieee80211_hdr *hdr = (void *)skb->data;
        __le16 fc = hdr->frame_control;
        u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
        tx_cmd->tx_flags = cpu_to_le32(tx_flags);
        /* Total # bytes to be transmitted */
        tx_cmd->len = cpu_to_le16((u16)skb->len +
-               (uintptr_t)skb_info->driver_data[0]);
+               (uintptr_t)info->driver_data[0]);
        tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
        tx_cmd->sta_id = sta_id;

But commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
AMSDU len") specifically added skb_info variable to that function:

@@ -105,6 +105,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
                        struct iwl_tx_cmd *tx_cmd,
                        struct ieee80211_tx_info *info, u8 sta_id)
 {
+       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
        struct ieee80211_hdr *hdr = (void *)skb->data;
        __le16 fc = hdr->frame_control;
        u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -185,7 +186,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
        tx_cmd->tx_flags = cpu_to_le32(tx_flags);
        /* Total # bytes to be transmitted */
        tx_cmd->len = cpu_to_le16((u16)skb->len +
-               (uintptr_t)info->driver_data[0]);
+               (uintptr_t)skb_info->driver_data[0]);
        tx_cmd->next_frame_len = 0;
        tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
        tx_cmd->sta_id = sta_id;

I wasn't expecting that skb_info variable is removed. Do we now have
merge damage somewhere? Luca, what do you think?

-- 
Kalle Valo

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

[Coelho, Luciano]

SGkgS2FsbGUsDQoNCk9uIE1vbiwgMjAxNi0wNS0xNiBhdCAxNjoxMCArMDMwMCwgS2FsbGUgVmFs
byB3cm90ZToNCj4gKEFkZGluZyBMdWNhIGFuZCBsaW51eC13aXJlbGVzcykNCj4gDQo+IFN0ZXBo
ZW4gUm90aHdlbGwgPHNmckBjYW5iLmF1dWcub3JnLmF1PiB3cml0ZXM6DQo+IA0KPiA+IA0KPiA+
IFRvZGF5J3MgbGludXgtbmV4dCBtZXJnZSBvZiB0aGUgd2lyZWxlc3MtZHJpdmVycy1uZXh0IHRy
ZWUgZ290IGENCj4gPiBjb25mbGljdCBpbjoNCj4gPiANCj4gPiDCoCBkcml2ZXJzL25ldC93aXJl
bGVzcy9pbnRlbC9pd2x3aWZpL212bS90eC5jDQo+ID4gDQo+ID4gYmV0d2VlbiBjb21taXQ6DQo+
ID4gDQo+ID4gwqAgOTA5YjI3ZjcwNjQzICgiTWVyZ2UNCj4gPiBnaXQ6Ly9naXQua2VybmVsLm9y
Zy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvZGF2ZW0vbmV0IikNCj4gPiANCj4gPiBmcm9tIHRo
ZSBuZXQtbmV4dCB0cmVlIGFuZCBjb21taXQ6DQo+ID4gDQo+ID4gwqAgYTUyNWQwZWFiMTdkICgi
TWVyZ2UgdGFnICdpd2x3aWZpLWZvci1rYWxsZS0yMDE2LTA1LTA0JyBvZg0KPiA+IGdpdDovL2dp
dC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9pd2x3aWZpL2l3bHdpZmktDQo+
ID4gZml4ZXMiKQ0KPiA+IA0KPiA+IGZyb20gdGhlIHdpcmVsZXNzLWRyaXZlcnMtbmV4dCB0cmVl
Lg0KPiA+IA0KPiA+IEkgZml4ZWQgaXQgdXAgKEkgdGhpbmsgdGhhdCB0aGUgbmV0LW5leHQgdHJl
ZSBtZXJnZSBsb3N0IHRoZQ0KPiA+IGNoYW5nZXMNCj4gPiB0byBpd2xfbXZtX3NldF90eF9jbWQo
KSBhc3NvY2lhdGVkIHdpdGggY29tbWl0IDVjMDhiMGY1MDI2Zg0KPiA+ICgiaXdsd2lmaToNCj4g
PiBtdm06IGRvbid0IG92ZXJyaWRlIHRoZSByYXRlIHdpdGggdGhlIEFNU0RVIGxlbiIpKSBhbmQg
Y2FuIGNhcnJ5DQo+ID4gdGhlDQo+ID4gZml4IGFzIG5lY2Vzc2FyeS4NCj4gSG1tLCBJJ20gc3Rh
cnRpbmcgdG8gc3VzcGVjdCBzb21ldGhpbmcgaXMgd3JvbmcuIEkgZGlkIGEgdGVzdCBtZXJnZQ0K
PiBvZg0KPiBuZXQtbmV4dCBhbmQgd2lyZWxlc3MtZHJpdmVycy1uZXh0IGFuZCBnb3QgdGhpcyBh
cyBhIGRpZmYgYWZ0ZXIgdGhlDQo+IG1lcmdlOg0KPiANCj4gLS0tIGEvZHJpdmVycy9uZXQvd2ly
ZWxlc3MvaW50ZWwvaXdsd2lmaS9tdm0vdHguYw0KPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVz
cy9pbnRlbC9pd2x3aWZpL212bS90eC5jDQo+IEBAIC0yMTEsNyArMjExLDYgQEAgdm9pZCBpd2xf
bXZtX3NldF90eF9jbWQoc3RydWN0IGl3bF9tdm0gKm12bSwNCj4gc3RydWN0IHNrX2J1ZmYgKnNr
YiwNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgc3Ry
dWN0IGl3bF90eF9jbWQgKnR4X2NtZCwNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgc3RydWN0IGllZWU4MDIxMV90eF9pbmZvICppbmZvLCB1OCBzdGFf
aWQpDQo+IMKgew0KPiAtwqDCoMKgwqDCoMKgwqBzdHJ1Y3QgaWVlZTgwMjExX3R4X2luZm8gKnNr
Yl9pbmZvID0gSUVFRTgwMjExX1NLQl9DQihza2IpOw0KPiDCoMKgwqDCoMKgwqDCoMKgc3RydWN0
IGllZWU4MDIxMV9oZHIgKmhkciA9ICh2b2lkICopc2tiLT5kYXRhOw0KPiDCoMKgwqDCoMKgwqDC
oMKgX19sZTE2IGZjID0gaGRyLT5mcmFtZV9jb250cm9sOw0KPiDCoMKgwqDCoMKgwqDCoMKgdTMy
IHR4X2ZsYWdzID0gbGUzMl90b19jcHUodHhfY21kLT50eF9mbGFncyk7DQo+IEBAIC0yOTUsNyAr
Mjk0LDcgQEAgdm9pZCBpd2xfbXZtX3NldF90eF9jbWQoc3RydWN0IGl3bF9tdm0gKm12bSwNCj4g
c3RydWN0IHNrX2J1ZmYgKnNrYiwNCj4gwqDCoMKgwqDCoMKgwqDCoHR4X2NtZC0+dHhfZmxhZ3Mg
PSBjcHVfdG9fbGUzMih0eF9mbGFncyk7DQo+IMKgwqDCoMKgwqDCoMKgwqAvKiBUb3RhbCAjIGJ5
dGVzIHRvIGJlIHRyYW5zbWl0dGVkICovDQo+IMKgwqDCoMKgwqDCoMKgwqB0eF9jbWQtPmxlbiA9
IGNwdV90b19sZTE2KCh1MTYpc2tiLT5sZW4gKw0KPiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgKHVpbnRwdHJfdClza2JfaW5mby0+ZHJpdmVyX2RhdGFbMF0pOw0KPiArwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgKHVpbnRwdHJfdClpbmZvLT5kcml2ZXJfZGF0YVswXSk7DQo+
IMKgwqDCoMKgwqDCoMKgwqB0eF9jbWQtPmxpZmVfdGltZSA9IGNwdV90b19sZTMyKFRYX0NNRF9M
SUZFX1RJTUVfSU5GSU5JVEUpOw0KPiDCoMKgwqDCoMKgwqDCoMKgdHhfY21kLT5zdGFfaWQgPSBz
dGFfaWQ7DQo+IA0KPiBCdXQgY29tbWl0IDVjMDhiMGY1MDI2ZiAoIml3bHdpZmk6IG12bTogZG9u
J3Qgb3ZlcnJpZGUgdGhlIHJhdGUgd2l0aA0KPiB0aGUNCj4gQU1TRFUgbGVuIikgc3BlY2lmaWNh
bGx5IGFkZGVkIHNrYl9pbmZvIHZhcmlhYmxlIHRvIHRoYXQgZnVuY3Rpb246DQo+IA0KPiBAQCAt
MTA1LDYgKzEwNSw3IEBAIHZvaWQgaXdsX212bV9zZXRfdHhfY21kKHN0cnVjdCBpd2xfbXZtICpt
dm0sDQo+IHN0cnVjdCBza19idWZmICpza2IsDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoHN0cnVjdCBpd2xfdHhfY21kICp0eF9jbWQsDQo+IMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHN0cnVjdCBpZWVlODAy
MTFfdHhfaW5mbyAqaW5mbywgdTggc3RhX2lkKQ0KPiDCoHsNCj4gK8KgwqDCoMKgwqDCoMKgc3Ry
dWN0IGllZWU4MDIxMV90eF9pbmZvICpza2JfaW5mbyA9IElFRUU4MDIxMV9TS0JfQ0Ioc2tiKTsN
Cj4gwqDCoMKgwqDCoMKgwqDCoHN0cnVjdCBpZWVlODAyMTFfaGRyICpoZHIgPSAodm9pZCAqKXNr
Yi0+ZGF0YTsNCj4gwqDCoMKgwqDCoMKgwqDCoF9fbGUxNiBmYyA9IGhkci0+ZnJhbWVfY29udHJv
bDsNCj4gwqDCoMKgwqDCoMKgwqDCoHUzMiB0eF9mbGFncyA9IGxlMzJfdG9fY3B1KHR4X2NtZC0+
dHhfZmxhZ3MpOw0KPiBAQCAtMTg1LDcgKzE4Niw3IEBAIHZvaWQgaXdsX212bV9zZXRfdHhfY21k
KHN0cnVjdCBpd2xfbXZtICptdm0sDQo+IHN0cnVjdCBza19idWZmICpza2IsDQo+IMKgwqDCoMKg
wqDCoMKgwqB0eF9jbWQtPnR4X2ZsYWdzID0gY3B1X3RvX2xlMzIodHhfZmxhZ3MpOw0KPiDCoMKg
wqDCoMKgwqDCoMKgLyogVG90YWwgIyBieXRlcyB0byBiZSB0cmFuc21pdHRlZCAqLw0KPiDCoMKg
wqDCoMKgwqDCoMKgdHhfY21kLT5sZW4gPSBjcHVfdG9fbGUxNigodTE2KXNrYi0+bGVuICsNCj4g
LcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCh1aW50cHRyX3QpaW5mby0+ZHJpdmVyX2Rh
dGFbMF0pOw0KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgKHVpbnRwdHJfdClza2Jf
aW5mby0+ZHJpdmVyX2RhdGFbMF0pOw0KPiDCoMKgwqDCoMKgwqDCoMKgdHhfY21kLT5uZXh0X2Zy
YW1lX2xlbiA9IDA7DQo+IMKgwqDCoMKgwqDCoMKgwqB0eF9jbWQtPmxpZmVfdGltZSA9IGNwdV90
b19sZTMyKFRYX0NNRF9MSUZFX1RJTUVfSU5GSU5JVEUpOw0KPiDCoMKgwqDCoMKgwqDCoMKgdHhf
Y21kLT5zdGFfaWQgPSBzdGFfaWQ7DQo+IA0KPiBJIHdhc24ndCBleHBlY3RpbmcgdGhhdCBza2Jf
aW5mbyB2YXJpYWJsZSBpcyByZW1vdmVkLiBEbyB3ZSBub3cgaGF2ZQ0KPiBtZXJnZSBkYW1hZ2Ug
c29tZXdoZXJlPyBMdWNhLCB3aGF0IGRvIHlvdSB0aGluaz8NCg0KQXMgd2UgZGlzY3Vzc2VkIG9u
IElSQywgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGVyZSB3YXMgYSBtZXJnZSBkYW1hZ2UNCndoZW4g
RGF2ZSBtZXJnZWQgbmV0LmdpdCBpbnRvIG5ldC1uZXh0LmdpdCAoYXMgeW91IG1vc3RseSBmb3Vu
ZCBvdXQgOykuDQoNCkknbSBub3Qgc3VyZSBob3cgdG8gc29sdmUgdGhhdCwgYnV0IEknbSBzdXJl
IHlvdSBhbmQgRGF2ZSBjYW4gZmlndXJlDQpzb21ldGhpbmcgb3V0LiA6KSBQbGVhc2UgbGV0IG1l
IGtub3cgaWYgeW91IG5lZWQgYW55IGhlbHAgd2l0aCBpdC4NCg0KLS0NCkNoZWVycywNCkx1Y2Eu

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

[Coelho, Luciano]

Hi Kalle,

On Mon, 2016-05-16 at 16:10 +0300, Kalle Valo wrote:
> (Adding Luca and linux-wireless)
> 
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 
> > 
> > Today's linux-next merge of the wireless-drivers-next tree got a
> > conflict in:
> > 
> >   drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> > 
> > between commit:
> > 
> >   909b27f70643 ("Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> > 
> > from the net-next tree and commit:
> > 
> >   a525d0eab17d ("Merge tag 'iwlwifi-for-kalle-2016-05-04' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-
> > fixes")
> > 
> > from the wireless-drivers-next tree.
> > 
> > I fixed it up (I think that the net-next tree merge lost the
> > changes
> > to iwl_mvm_set_tx_cmd() associated with commit 5c08b0f5026f
> > ("iwlwifi:
> > mvm: don't override the rate with the AMSDU len")) and can carry
> > the
> > fix as necessary.
> Hmm, I'm starting to suspect something is wrong. I did a test merge
> of
> net-next and wireless-drivers-next and got this as a diff after the
> merge:
> 
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
> @@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>                         struct iwl_tx_cmd *tx_cmd,
>                         struct ieee80211_tx_info *info, u8 sta_id)
>  {
> -       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
>         struct ieee80211_hdr *hdr = (void *)skb->data;
>         __le16 fc = hdr->frame_control;
>         u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
> @@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>         tx_cmd->tx_flags = cpu_to_le32(tx_flags);
>         /* Total # bytes to be transmitted */
>         tx_cmd->len = cpu_to_le16((u16)skb->len +
> -               (uintptr_t)skb_info->driver_data[0]);
> +               (uintptr_t)info->driver_data[0]);
>         tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
>         tx_cmd->sta_id = sta_id;
> 
> But commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with
> the
> AMSDU len") specifically added skb_info variable to that function:
> 
> @@ -105,6 +105,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>                         struct iwl_tx_cmd *tx_cmd,
>                         struct ieee80211_tx_info *info, u8 sta_id)
>  {
> +       struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
>         struct ieee80211_hdr *hdr = (void *)skb->data;
>         __le16 fc = hdr->frame_control;
>         u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
> @@ -185,7 +186,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm,
> struct sk_buff *skb,
>         tx_cmd->tx_flags = cpu_to_le32(tx_flags);
>         /* Total # bytes to be transmitted */
>         tx_cmd->len = cpu_to_le16((u16)skb->len +
> -               (uintptr_t)info->driver_data[0]);
> +               (uintptr_t)skb_info->driver_data[0]);
>         tx_cmd->next_frame_len = 0;
>         tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
>         tx_cmd->sta_id = sta_id;
> 
> I wasn't expecting that skb_info variable is removed. Do we now have
> merge damage somewhere? Luca, what do you think?

As we discussed on IRC, it seems to me that there was a merge damage
when Dave merged net.git into net-next.git (as you mostly found out ;).

I'm not sure how to solve that, but I'm sure you and Dave can figure
something out. :) Please let me know if you need any help with it.

--
Cheers,
Luca.

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

[Kalle Valo]

"Coelho, Luciano" <luciano.coelho@intel.com> writes:

(dropping damaged diffs etc, adding Emmanuel as the author of
5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU
len"))

>> I wasn't expecting that skb_info variable is removed. Do we now have
>> merge damage somewhere? Luca, what do you think?
>
> As we discussed on IRC, it seems to me that there was a merge damage
> when Dave merged net.git into net-next.git (as you mostly found out ;).
>
> I'm not sure how to solve that, but I'm sure you and Dave can figure
> something out. :) Please let me know if you need any help with it.

Yeah, I guess in net-next.git Dave assumed that 'info == skb_info' is
always valid in iwl_mvm_set_tx_cmd(), but I don't that's the case. So I
think the end case, after a merge, should look like this:

void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
			struct iwl_tx_cmd *tx_cmd,
			struct ieee80211_tx_info *info, u8 sta_id)
{
	struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
	struct ieee80211_hdr *hdr = (void *)skb->data;
	__le16 fc = hdr->frame_control;
	u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
	u32 len = skb->len + FCS_LEN;
	u8 ac;

[...]

	tx_cmd->tx_flags = cpu_to_le32(tx_flags);
	/* Total # bytes to be transmitted */
	tx_cmd->len = cpu_to_le16((u16)skb->len +
		(uintptr_t)skb_info->driver_data[0]);
	tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
	tx_cmd->sta_id = sta_id;

I'm going to propose this to Dave in my pending pull request[1]. But I
would appreciate if someone else would double check this.

[1] https://patchwork.ozlabs.org/patch/621953/

-- 
Kalle Valo

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

[Kalle Valo]

"Coelho, Luciano" <luciano.coelho@intel.com> writes:

(dropping damaged diffs etc, adding Emmanuel as the author of
5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU
len"))

>> I wasn't expecting that skb_info variable is removed. Do we now have
>> merge damage somewhere? Luca, what do you think?
>
> As we discussed on IRC, it seems to me that there was a merge damage
> when Dave merged net.git into net-next.git (as you mostly found out ;).
>
> I'm not sure how to solve that, but I'm sure you and Dave can figure
> something out. :) Please let me know if you need any help with it.

Yeah, I guess in net-next.git Dave assumed that 'info == skb_info' is
always valid in iwl_mvm_set_tx_cmd(), but I don't that's the case. So I
think the end case, after a merge, should look like this:

void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff *skb,
			struct iwl_tx_cmd *tx_cmd,
			struct ieee80211_tx_info *info, u8 sta_id)
{
	struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
	struct ieee80211_hdr *hdr = (void *)skb->data;
	__le16 fc = hdr->frame_control;
	u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
	u32 len = skb->len + FCS_LEN;
	u8 ac;

[...]

	tx_cmd->tx_flags = cpu_to_le32(tx_flags);
	/* Total # bytes to be transmitted */
	tx_cmd->len = cpu_to_le16((u16)skb->len +
		(uintptr_t)skb_info->driver_data[0]);
	tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
	tx_cmd->sta_id = sta_id;

I'm going to propose this to Dave in my pending pull request[1]. But I
would appreciate if someone else would double check this.

[1] https://patchwork.ozlabs.org/patch/621953/

-- 
Kalle Valo

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

[David Miller]

From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 16 May 2016 16:10:27 +0300

> I wasn't expecting that skb_info variable is removed. Do we now have
> merge damage somewhere? Luca, what do you think?

It's possible I got the net --> net-next merge wrong the other day, feel
free to send me an appropriate fixup.

Thanks.

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

[Kalle Valo]

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

> Hi all,
>
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/ath/ath10k/mac.c
>
> between commit:
>
>   f3fe4e93dd63 ("mac80211: add a HW flag for supporting HW TX fragmentation")
>
> from the net-next tree and commit:
>
>   ff32eeb86aa1 ("ath10k: advertize hardware packet loss mechanism")
>
> from the wireless-drivers-next 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.

The fix looks good, thanks. I sent a pull request to Dave yesteday which
should fix this.

-- 
Kalle Valo

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/wireless/ath/ath10k/mac.c

between commit:

  f3fe4e93dd63 ("mac80211: add a HW flag for supporting HW TX fragmentation")

from the net-next tree and commit:

  ff32eeb86aa1 ("ath10k: advertize hardware packet loss mechanism")

from the wireless-drivers-next 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/net/wireless/ath/ath10k/mac.c
index 717b2fad9a8a,db6ddf974d1d..000000000000
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@@ -8005,7 -7993,7 +7993,8 @@@ int ath10k_mac_register(struct ath10k *
  	ieee80211_hw_set(ar->hw, WANT_MONITOR_VIF);
  	ieee80211_hw_set(ar->hw, CHANCTX_STA_CSA);
  	ieee80211_hw_set(ar->hw, QUEUE_CONTROL);
 +	ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
+ 	ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
  
  	if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags))
  		ieee80211_hw_set(ar->hw, SW_CRYPTO_CONTROL);

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

[Kalle Valo]

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

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/scan.c
>
> between commit:
>
>   7947d3e075cd ("mac80211: Add support for beacon report radio measurement")
>
> from the net-next tree and commit:
>
>   69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")
>
> from the wireless-drivers-next 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. I'm planning to submit a pull request to Dave tomorrow and I'll
include instruction how to solve these mac80211 API conflicts.

-- 
Kalle Valo

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

[Kalle Valo]

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

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/scan.c
>
> between commit:
>
>   7947d3e075cd ("mac80211: Add support for beacon report radio measurement")
>
> from the net-next tree and commit:
>
>   69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")
>
> from the wireless-drivers-next 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. I'm planning to submit a pull request to Dave tomorrow and I'll
include instruction how to solve these mac80211 API conflicts.

-- 
Kalle Valo

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/wireless/intel/iwlwifi/mvm/scan.c

between commit:

  7947d3e075cd ("mac80211: Add support for beacon report radio measurement")

from the net-next tree and commit:

  69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")

from the wireless-drivers-next 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/net/wireless/intel/iwlwifi/mvm/scan.c
index 1cac10c5d818,fb25d9e41912..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@@ -400,9 -396,10 +400,9 @@@ void iwl_mvm_rx_lmac_scan_complete_noti
  			       iwl_mvm_ebs_status_str(scan_notif->ebs_status));
  
  		mvm->scan_status &= ~IWL_MVM_SCAN_REGULAR;
 -		ieee80211_scan_completed(mvm->hw,
 -				scan_notif->status == IWL_SCAN_OFFLOAD_ABORTED);
 +		ieee80211_scan_completed(mvm->hw, &info);
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
  	} else {
  		IWL_ERR(mvm,
  			"got scan complete notification but no scan is running\n");
@@@ -1433,13 -1432,9 +1435,13 @@@ void iwl_mvm_rx_umac_scan_complete_noti
  
  	/* if the scan is already stopping, we don't need to notify mac80211 */
  	if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_REGULAR) {
 -		ieee80211_scan_completed(mvm->hw, aborted);
 +		struct cfg80211_scan_info info = {
 +			.aborted = aborted,
 +		};
 +
 +		ieee80211_scan_completed(mvm->hw, &info);
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
  	} else if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_SCHED) {
  		ieee80211_sched_scan_stopped(mvm->hw);
  		mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
@@@ -1644,14 -1630,9 +1646,14 @@@ out
  		 * to release the scan reference here.
  		 */
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
 -		if (notify)
 -			ieee80211_scan_completed(mvm->hw, true);
 +		if (notify) {
 +			struct cfg80211_scan_info info = {
 +				.aborted = true,
 +			};
 +
 +			ieee80211_scan_completed(mvm->hw, &info);
 +		}
  	} else if (notify) {
  		ieee80211_sched_scan_stopped(mvm->hw);
  		mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/wireless/intel/iwlwifi/mvm/scan.c

between commit:

  7947d3e075cd ("mac80211: Add support for beacon report radio measurement")

from the net-next tree and commit:

  69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")

from the wireless-drivers-next 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/net/wireless/intel/iwlwifi/mvm/scan.c
index 1cac10c5d818,fb25d9e41912..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@@ -400,9 -396,10 +400,9 @@@ void iwl_mvm_rx_lmac_scan_complete_noti
  			       iwl_mvm_ebs_status_str(scan_notif->ebs_status));
  
  		mvm->scan_status &= ~IWL_MVM_SCAN_REGULAR;
 -		ieee80211_scan_completed(mvm->hw,
 -				scan_notif->status == IWL_SCAN_OFFLOAD_ABORTED);
 +		ieee80211_scan_completed(mvm->hw, &info);
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
  	} else {
  		IWL_ERR(mvm,
  			"got scan complete notification but no scan is running\n");
@@@ -1433,13 -1432,9 +1435,13 @@@ void iwl_mvm_rx_umac_scan_complete_noti
  
  	/* if the scan is already stopping, we don't need to notify mac80211 */
  	if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_REGULAR) {
 -		ieee80211_scan_completed(mvm->hw, aborted);
 +		struct cfg80211_scan_info info = {
 +			.aborted = aborted,
 +		};
 +
 +		ieee80211_scan_completed(mvm->hw, &info);
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
  	} else if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_SCHED) {
  		ieee80211_sched_scan_stopped(mvm->hw);
  		mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
@@@ -1644,14 -1630,9 +1646,14 @@@ out
  		 * to release the scan reference here.
  		 */
  		iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- 		del_timer(&mvm->scan_timer);
+ 		cancel_delayed_work(&mvm->scan_timeout_dwork);
 -		if (notify)
 -			ieee80211_scan_completed(mvm->hw, true);
 +		if (notify) {
 +			struct cfg80211_scan_info info = {
 +				.aborted = true,
 +			};
 +
 +			ieee80211_scan_completed(mvm->hw, &info);
 +		}
  	} else if (notify) {
  		ieee80211_sched_scan_stopped(mvm->hw);
  		mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

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

Hi Kalle,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in drivers/net/wireless/ath/ath10k/mac.c between commits
41fbf6e4f317 ("ath10k: enable IEEE80211_HW_SUPPORT_FAST_XMIT") and
df1404650ccb ("mac80211: remove support for IFF_PROMISC") from the
net-next tree and commits 548462133d98 ("ath10k: fix interrupt storm"),
cc9904e694fa ("ath10k: add hw connection monitor support") and
500ff9f9389d ("ath10k: implement chanctx API") (and a few others) from
the wireless-drivers-next tree.

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

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

diff --cc drivers/net/wireless/ath/ath10k/mac.c
index fcd08b2f8d26,eaa0182e001d..000000000000
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@@ -766,9 -1031,68 +1031,48 @@@ static int ath10k_monitor_stop(struct a
  	return 0;
  }
  
 -static bool ath10k_mac_should_disable_promisc(struct ath10k *ar)
 -{
 -	struct ath10k_vif *arvif;
 -
 -	if (!(ar->filter_flags & FIF_PROMISC_IN_BSS))
 -		return true;
 -
 -	if (!ar->num_started_vdevs)
 -		return false;
 -
 -	list_for_each_entry(arvif, &ar->arvifs, list)
 -		if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
 -			return false;
 -
 -	ath10k_dbg(ar, ATH10K_DBG_MAC,
 -		   "mac disabling promiscuous mode because vdev is started\n");
 -	return true;
 -}
 -
+ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar)
+ {
+ 	int num_ctx;
+ 
+ 	/* At least one chanctx is required to derive a channel to start
+ 	 * monitor vdev on.
+ 	 */
+ 	num_ctx = ath10k_mac_num_chanctxs(ar);
+ 	if (num_ctx == 0)
+ 		return false;
+ 
+ 	/* If there's already an existing special monitor interface then don't
+ 	 * bother creating another monitor vdev.
+ 	 */
+ 	if (ar->monitor_arvif)
+ 		return false;
+ 
+ 	return ar->monitor ||
 -	       !ath10k_mac_should_disable_promisc(ar) ||
+ 	       test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
+ }
+ 
+ static bool ath10k_mac_monitor_vdev_is_allowed(struct ath10k *ar)
+ {
+ 	int num_ctx;
+ 
+ 	num_ctx = ath10k_mac_num_chanctxs(ar);
+ 
+ 	/* FIXME: Current interface combinations and cfg80211/mac80211 code
+ 	 * shouldn't allow this but make sure to prevent handling the following
+ 	 * case anyway since multi-channel DFS hasn't been tested at all.
+ 	 */
+ 	if (test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags) && num_ctx > 1)
+ 		return false;
+ 
+ 	return true;
+ }
+ 
  static int ath10k_monitor_recalc(struct ath10k *ar)
  {
- 	bool should_start;
+ 	bool needed;
+ 	bool allowed;
+ 	int ret;
  
  	lockdep_assert_held(&ar->conf_mutex);
  
@@@ -5499,9 -6915,14 +6894,15 @@@ int ath10k_mac_register(struct ath10k *
  			IEEE80211_HW_AP_LINK_PS |
  			IEEE80211_HW_SPECTRUM_MGMT |
  			IEEE80211_HW_SW_CRYPTO_CONTROL |
- 			IEEE80211_HW_SUPPORT_FAST_XMIT;
++			IEEE80211_HW_SUPPORT_FAST_XMIT |
+ 			IEEE80211_HW_CONNECTION_MONITOR |
+ 			IEEE80211_HW_SUPPORTS_PER_STA_GTK |
+ 			IEEE80211_HW_WANT_MONITOR_VIF |
+ 			IEEE80211_HW_CHANCTX_STA_CSA |
+ 			IEEE80211_HW_QUEUE_CONTROL;
  
  	ar->hw->wiphy->features |= NL80211_FEATURE_STATIC_SMPS;
+ 	ar->hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
  
  	if (ar->ht_cap_info & WMI_HT_CAP_DYNAMIC_SMPS)
  		ar->hw->wiphy->features |= NL80211_FEATURE_DYNAMIC_SMPS;

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

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

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

Hi Kalle,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in drivers/net/wireless/ath/ath10k/mac.c between commits
41fbf6e4f317 ("ath10k: enable IEEE80211_HW_SUPPORT_FAST_XMIT") and
df1404650ccb ("mac80211: remove support for IFF_PROMISC") from the
net-next tree and commits 548462133d98 ("ath10k: fix interrupt storm"),
cc9904e694fa ("ath10k: add hw connection monitor support") and
500ff9f9389d ("ath10k: implement chanctx API") (and a few others) from
the wireless-drivers-next tree.

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

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

diff --cc drivers/net/wireless/ath/ath10k/mac.c
index fcd08b2f8d26,eaa0182e001d..000000000000
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@@ -766,9 -1031,68 +1031,48 @@@ static int ath10k_monitor_stop(struct a
  	return 0;
  }
  
 -static bool ath10k_mac_should_disable_promisc(struct ath10k *ar)
 -{
 -	struct ath10k_vif *arvif;
 -
 -	if (!(ar->filter_flags & FIF_PROMISC_IN_BSS))
 -		return true;
 -
 -	if (!ar->num_started_vdevs)
 -		return false;
 -
 -	list_for_each_entry(arvif, &ar->arvifs, list)
 -		if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
 -			return false;
 -
 -	ath10k_dbg(ar, ATH10K_DBG_MAC,
 -		   "mac disabling promiscuous mode because vdev is started\n");
 -	return true;
 -}
 -
+ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar)
+ {
+ 	int num_ctx;
+ 
+ 	/* At least one chanctx is required to derive a channel to start
+ 	 * monitor vdev on.
+ 	 */
+ 	num_ctx = ath10k_mac_num_chanctxs(ar);
+ 	if (num_ctx == 0)
+ 		return false;
+ 
+ 	/* If there's already an existing special monitor interface then don't
+ 	 * bother creating another monitor vdev.
+ 	 */
+ 	if (ar->monitor_arvif)
+ 		return false;
+ 
+ 	return ar->monitor ||
 -	       !ath10k_mac_should_disable_promisc(ar) ||
+ 	       test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
+ }
+ 
+ static bool ath10k_mac_monitor_vdev_is_allowed(struct ath10k *ar)
+ {
+ 	int num_ctx;
+ 
+ 	num_ctx = ath10k_mac_num_chanctxs(ar);
+ 
+ 	/* FIXME: Current interface combinations and cfg80211/mac80211 code
+ 	 * shouldn't allow this but make sure to prevent handling the following
+ 	 * case anyway since multi-channel DFS hasn't been tested at all.
+ 	 */
+ 	if (test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags) && num_ctx > 1)
+ 		return false;
+ 
+ 	return true;
+ }
+ 
  static int ath10k_monitor_recalc(struct ath10k *ar)
  {
- 	bool should_start;
+ 	bool needed;
+ 	bool allowed;
+ 	int ret;
  
  	lockdep_assert_held(&ar->conf_mutex);
  
@@@ -5499,9 -6915,14 +6894,15 @@@ int ath10k_mac_register(struct ath10k *
  			IEEE80211_HW_AP_LINK_PS |
  			IEEE80211_HW_SPECTRUM_MGMT |
  			IEEE80211_HW_SW_CRYPTO_CONTROL |
- 			IEEE80211_HW_SUPPORT_FAST_XMIT;
++			IEEE80211_HW_SUPPORT_FAST_XMIT |
+ 			IEEE80211_HW_CONNECTION_MONITOR |
+ 			IEEE80211_HW_SUPPORTS_PER_STA_GTK |
+ 			IEEE80211_HW_WANT_MONITOR_VIF |
+ 			IEEE80211_HW_CHANCTX_STA_CSA |
+ 			IEEE80211_HW_QUEUE_CONTROL;
  
  	ar->hw->wiphy->features |= NL80211_FEATURE_STATIC_SMPS;
+ 	ar->hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
  
  	if (ar->ht_cap_info & WMI_HT_CAP_DYNAMIC_SMPS)
  		ar->hw->wiphy->features |= NL80211_FEATURE_DYNAMIC_SMPS;

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