linux-next: build failure after merge of the mac80211-next tree

linux-next: build failure after merge of the mac80211-next tree

[Stephen Rothwell]

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

Hi all,

After merging the mac80211-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/wilc1000/cfg80211.c:1668:3: error: 'const struct cfg80211_ops' has no member named 'mgmt_frame_register'
 1668 |  .mgmt_frame_register = wilc_mgmt_frame_register,
      |   ^~~~~~~~~~~~~~~~~~~
drivers/staging/wilc1000/cfg80211.c:1668:25: error: initialization of 'int (*)(struct wiphy *, struct wireless_dev *, u64)' {aka 'int (*)(struct wiphy *, struct wireless_dev *, long long unsigned int)'} from incompatible pointer type 'void (*)(struct wiphy *, struct wireless_dev *, u16,  bool)' {aka 'void (*)(struct wiphy *, struct wireless_dev *, short unsigned int,  _Bool)'} [-Werror=incompatible-pointer-types]
 1668 |  .mgmt_frame_register = wilc_mgmt_frame_register,
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/wilc1000/cfg80211.c:1668:25: note: (near initialization for 'wilc_cfg80211_ops.mgmt_tx_cancel_wait')
cc1: some warnings being treated as errors
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3400:3: error: 'struct cfg80211_ops' has no member named 'mgmt_frame_register'
 3400 |  .mgmt_frame_register = cfg80211_rtw_mgmt_frame_register,
      |   ^~~~~~~~~~~~~~~~~~~
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3400:25: error: initialization of 'int (*)(struct wiphy *, struct wireless_dev *, u64)' {aka 'int (*)(struct wiphy *, struct wireless_dev *, long long unsigned int)'} from incompatible pointer type 'void (*)(struct wiphy *, struct wireless_dev *, u16,  bool)' {aka 'void (*)(struct wiphy *, struct wireless_dev *, short unsigned int,  _Bool)'} [-Werror=incompatible-pointer-types]
 3400 |  .mgmt_frame_register = cfg80211_rtw_mgmt_frame_register,
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3400:25: note: (near initialization for 'rtw_cfg80211_ops.mgmt_tx_cancel_wait')

Caused by commit

  6cd536fe62ef ("cfg80211: change internal management frame registration API")

I have used the mac80211-next from next-20200424 for today.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the mac80211-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> Caused by commit
> 
>   6cd536fe62ef ("cfg80211: change internal management frame registration API")

Yeah. I forgot about staging. I guess I'll throw in a quick fix.

johannes

Re: linux-next: build failure after merge of the mac80211-next tree

[Sergey Matyukevich]

On Tue, Apr 28, 2020 at 09:01:30AM +0200, Johannes Berg wrote:
> On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the mac80211-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > Caused by commit
> > 
> >   6cd536fe62ef ("cfg80211: change internal management frame registration API")
> 
> Yeah. I forgot about staging. I guess I'll throw in a quick fix.
> 
> johannes

Hello Johannes,

Could you please take a look at the following fix for this issue:
https://patchwork.kernel.org/patch/11509497/

Regards,
Sergey

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

On Tue, 2020-04-28 at 10:25 +0300, Sergey Matyukevich wrote:
> On Tue, Apr 28, 2020 at 09:01:30AM +0200, Johannes Berg wrote:
> > On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > After merging the mac80211-next tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > Caused by commit
> > > 
> > >   6cd536fe62ef ("cfg80211: change internal management frame registration API")
> > 
> > Yeah. I forgot about staging. I guess I'll throw in a quick fix.
> > 
> > johannes
> 
> Hello Johannes,
> 
> Could you please take a look at the following fix for this issue:
> https://patchwork.kernel.org/patch/11509497/

Heh. I was just fixing it too, missed your patch. How do you like this
fix?

https://p.sipsolutions.net/0638ee56c2e48a30.txt

johannes

Re: linux-next: build failure after merge of the mac80211-next tree

[Sergey Matyukevich]

On Tue, Apr 28, 2020 at 09:24:16AM +0200, Johannes Berg wrote:
> On Tue, 2020-04-28 at 10:25 +0300, Sergey Matyukevich wrote:
> > On Tue, Apr 28, 2020 at 09:01:30AM +0200, Johannes Berg wrote:
> > > On Tue, 2020-04-28 at 12:29 +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the mac80211-next tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > Caused by commit
> > > > 
> > > >   6cd536fe62ef ("cfg80211: change internal management frame registration API")
> > > 
> > > Yeah. I forgot about staging. I guess I'll throw in a quick fix.
> > > 
> > > johannes
> > 
> > Hello Johannes,
> > 
> > Could you please take a look at the following fix for this issue:
> > https://patchwork.kernel.org/patch/11509497/
> 
> Heh. I was just fixing it too, missed your patch. How do you like this
> fix?
> 
> https://p.sipsolutions.net/0638ee56c2e48a30.txt

Looks good. But I have a couple of questions:

- why cleanup vif->mgmt_frame_reg in wilc_mac_open ?

- previously wilc_wfi_p2p_rx was called only for PROBE_REQ and ACTION,
  now it will be called for all the other registred frames as well

Regards,
Sergey

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

On Tue, 2020-04-28 at 10:45 +0300, Sergey Matyukevich wrote:
> 
> Looks good. But I have a couple of questions:
> 
> - why cleanup vif->mgmt_frame_reg in wilc_mac_open ?

Otherwise wilc_update_mgmt_frame_registrations() will think there are no
changes whatsoever, and do nothing.

> - previously wilc_wfi_p2p_rx was called only for PROBE_REQ and ACTION,
>   now it will be called for all the other registred frames as well


Huh, good catch. How about this?

https://p.sipsolutions.net/51183f5492f05ea6.txt

johannes

Re: linux-next: build failure after merge of the mac80211-next tree

[Sergey Matyukevich]

> > Looks good. But I have a couple of questions:
> > 
> > - why cleanup vif->mgmt_frame_reg in wilc_mac_open ?
> 
> Otherwise wilc_update_mgmt_frame_registrations() will think there are no
> changes whatsoever, and do nothing.
> 
> > - previously wilc_wfi_p2p_rx was called only for PROBE_REQ and ACTION,
> >   now it will be called for all the other registred frames as well
> 
> 
> Huh, good catch. How about this?
> 
> https://p.sipsolutions.net/51183f5492f05ea6.txt

Ok, this one looks good to me.

Regards,
Sergey

linux-next: build failure after merge of the mac80211-next tree

[Stephen Rothwell]

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

Hi all,

After merging the mac80211-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_event_mgmt_rx':
drivers/net/wireless/ath/ath10k/wmi.c:2626:12: error: too few arguments to function 'cfg80211_get_ies_channel_number'
 2626 |   ies_ch = cfg80211_get_ies_channel_number(mgmt->u.beacon.variable,
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/net/mac80211.h:21,
                 from drivers/net/wireless/ath/ath10k/htt.h:16,
                 from drivers/net/wireless/ath/ath10k/core.h:18,
                 from drivers/net/wireless/ath/ath10k/wmi.c:11:
include/net/cfg80211.h:6421:5: note: declared here
 6421 | int cfg80211_get_ies_channel_number(const u8 *ie, size_t ielen,
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  7f599aeccbd2 ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel")

interacting with commit

  3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak from other channel")

from the net-next tree.

I have applied the following merge fix patch for today (which, on
reflection, may not be correct, but builds).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 21 Dec 2021 11:40:49 +1100
Subject: [PATCH] fixup for "cfg80211: Use the HE operation IE to determine a 6GHz BSS channel"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4733fd7fb169..657bd6a32a36 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2613,6 +2613,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 	if (ieee80211_is_beacon(hdr->frame_control) ||
 	    ieee80211_is_probe_resp(hdr->frame_control)) {
 		struct ieee80211_mgmt *mgmt = (void *)skb->data;
+		enum cfg80211_bss_frame_type ftype;
 		u8 *ies;
 		int ies_ch;
 
@@ -2623,9 +2624,14 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 
 		ies = mgmt->u.beacon.variable;
 
+		if (ieee80211_is_beacon(mgmt->frame_control))
+			ftype = CFG80211_BSS_FTYPE_BEACON;
+		else /* if (ieee80211_is_probe_resp(mgmt->frame_control)) */
+			ftype = CFG80211_BSS_FTYPE_PRESP;
+
 		ies_ch = cfg80211_get_ies_channel_number(mgmt->u.beacon.variable,
 							 skb_tail_pointer(skb) - ies,
-							 sband->band);
+							 sband->band, ftype);
 
 		if (ies_ch > 0 && ies_ch != channel) {
 			ath10k_dbg(ar, ATH10K_DBG_MGMT,
-- 
2.33.0



-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

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

Hi Stephen,

Thanks for the heads-up, also on the merge issue.

I'll pull back net-next and fix this.

johannes


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: build failure after merge of the mac80211-next tree

[Stephen Rothwell]

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

Hi Johannes,

On Tue, 21 Dec 2021 12:02:57 +0100 Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Thanks for the heads-up, also on the merge issue.
> 
> I'll pull back net-next and fix this.

Or just let Dave know when you ask him to merge your tree ...

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

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

On Tue, 2021-12-21 at 22:15 +1100, Stephen Rothwell wrote:
> Hi Johannes,
> 
> On Tue, 21 Dec 2021 12:02:57 +0100 Johannes Berg <johannes@sipsolutions.net> wrote:
> > 
> > Thanks for the heads-up, also on the merge issue.
> > 
> > I'll pull back net-next and fix this.
> 
> Or just let Dave know when you ask him to merge your tree ...
> 

Yeah, I guess I can do that too.

Maybe I'll do that and link to both of your resolutions, they both look
good :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: build failure after merge of the mac80211-next tree

[Kalle Valo]

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

> Hi all,
>
> After merging the mac80211-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_event_mgmt_rx':
> drivers/net/wireless/ath/ath10k/wmi.c:2626:12: error: too few
> arguments to function 'cfg80211_get_ies_channel_number'
>  2626 |   ies_ch = cfg80211_get_ies_channel_number(mgmt->u.beacon.variable,
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from include/net/mac80211.h:21,
>                  from drivers/net/wireless/ath/ath10k/htt.h:16,
>                  from drivers/net/wireless/ath/ath10k/core.h:18,
>                  from drivers/net/wireless/ath/ath10k/wmi.c:11:
> include/net/cfg80211.h:6421:5: note: declared here
>  6421 | int cfg80211_get_ies_channel_number(const u8 *ie, size_t ielen,
>       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
>   7f599aeccbd2 ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel")
>
> interacting with commit
>
>   3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak from other channel")
>
> from the net-next tree.
>
> I have applied the following merge fix patch for today (which, on
> reflection, may not be correct, but builds).
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 21 Dec 2021 11:40:49 +1100
> Subject: [PATCH] fixup for "cfg80211: Use the HE operation IE to determine a 6GHz BSS channel"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/net/wireless/ath/ath10k/wmi.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 4733fd7fb169..657bd6a32a36 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -2613,6 +2613,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
>  	if (ieee80211_is_beacon(hdr->frame_control) ||
>  	    ieee80211_is_probe_resp(hdr->frame_control)) {
>  		struct ieee80211_mgmt *mgmt = (void *)skb->data;
> +		enum cfg80211_bss_frame_type ftype;
>  		u8 *ies;
>  		int ies_ch;
>  
> @@ -2623,9 +2624,14 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
>  
>  		ies = mgmt->u.beacon.variable;
>  
> +		if (ieee80211_is_beacon(mgmt->frame_control))
> +			ftype = CFG80211_BSS_FTYPE_BEACON;
> +		else /* if (ieee80211_is_probe_resp(mgmt->frame_control)) */
> +			ftype = CFG80211_BSS_FTYPE_PRESP;
> +
>  		ies_ch = cfg80211_get_ies_channel_number(mgmt->u.beacon.variable,
>  							 skb_tail_pointer(skb) - ies,
> -							 sband->band);
> +							 sband->band, ftype);

I would remove the commented out code '/* if
(ieee80211_is_probe_resp(mgmt->frame_control)) */', otherwise looks good
to me.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

linux-next: build failure after merge of the mac80211-next tree

[Stephen Rothwell]

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

Hi all,

After merging the mac80211-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/wireless/ath/ath9k/debug.c: In function 'read_file_misc':
drivers/net/wireless/ath/ath9k/debug.c:741:35: error: 'struct ath9k_vif_iter_data' has no member named 'nwds'
  741 |       iter_data.nmeshes, iter_data.nwds);
      |                                   ^

Caused by commit

  f532b9716eeb ("ath9k: remove WDS code")

I have used the mac80211-next tree from next-20201110 for today.

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the mac80211-next tree

[Stephen Rothwell]

Hi Johannes,

After merging the mac80211-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/wireless/mediatek/mt76/mt76x2_main.c:539:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .wake_tx_queue = mt76_wake_tx_queue,
                   ^
drivers/net/wireless/mediatek/mt76/mt76x2_main.c:539:19: note: (near initialization for 'mt76x2_ops.wake_tx_queue')

Caused by commits

  17f1de56df05 ("mt76: add common code shared between multiple chipsets")
  7bc04215a66b ("mt76: add driver code for MT76x2e")

from the wireless-drivers-next tree interacting with commit

  e937b8da5a59 ("mac80211: Add TXQ scheduling API")

from the mac80211-next tree.

I applied the below hack merge fix ... please let me know if something
more/better is required.  Someone needs to remember to tell Dave when
these trees meet in his tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 12 Dec 2017 12:50:40 +1100
Subject: [PATCH] mt76: fix up for "mac80211: Add TXQ scheduling API"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/wireless/mediatek/mt76/mt76.h |  2 +-
 drivers/net/wireless/mediatek/mt76/tx.c   | 10 +++++++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index aa0880bbea7f..e395d3859212 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -338,7 +338,7 @@ void mt76_tx(struct mt76_dev *dev, struct ieee80211_sta *sta,
 	     struct mt76_wcid *wcid, struct sk_buff *skb);
 void mt76_txq_init(struct mt76_dev *dev, struct ieee80211_txq *txq);
 void mt76_txq_remove(struct mt76_dev *dev, struct ieee80211_txq *txq);
-void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq);
+void mt76_wake_tx_queue(struct ieee80211_hw *hw);
 void mt76_stop_tx_queues(struct mt76_dev *dev, struct ieee80211_sta *sta,
 			 bool send_bar);
 void mt76_txq_schedule(struct mt76_dev *dev, struct mt76_queue *hwq);
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 4eef69bd8a9e..ad414af0750f 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -463,12 +463,16 @@ void mt76_stop_tx_queues(struct mt76_dev *dev, struct ieee80211_sta *sta,
 }
 EXPORT_SYMBOL_GPL(mt76_stop_tx_queues);
 
-void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
+void mt76_wake_tx_queue(struct ieee80211_hw *hw)
 {
+	struct ieee80211_txq *txq;
 	struct mt76_dev *dev = hw->priv;
-	struct mt76_txq *mtxq = (struct mt76_txq *) txq->drv_priv;
-	struct mt76_queue *hwq = mtxq->hwq;
+	struct mt76_txq *mtxq;
+	struct mt76_queue *hwq;
 
+	txq = ieee80211_next_txq(hw);
+	mtxq = (struct mt76_txq *) txq->drv_priv;
+	hwq = mtxq->hwq;
 	spin_lock_bh(&hwq->lock);
 	if (list_empty(&mtxq->list))
 		list_add_tail(&mtxq->list, &hwq->swq);
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

Hi Stephen,

Thanks!

Felix made me aware of this yesterday evening and said he's going to
work out the required changes to mt76.

Kalle and I will make sure to submit the trees to Dave one by one so he
doesn't have to deal with it :)

Unfortunately, this might take a few days to resolve.

> -void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
> +void mt76_wake_tx_queue(struct ieee80211_hw *hw)
>  {
> +	struct ieee80211_txq *txq;
>  	struct mt76_dev *dev = hw->priv;
> -	struct mt76_txq *mtxq = (struct mt76_txq *) txq->drv_priv;
> -	struct mt76_queue *hwq = mtxq->hwq;
> +	struct mt76_txq *mtxq;
> +	struct mt76_queue *hwq;
>  
> +	txq = ieee80211_next_txq(hw);
> +	mtxq = (struct mt76_txq *) txq->drv_priv;
> +	hwq = mtxq->hwq;


Looks pretty much right to me - perhaps for safety there should be a
NULL check on txq, but OTOH when you get here it should be non-NULL.

Sorry for the inconvenience, I hadn't realized mt76 went in now.

johannes

Re: linux-next: build failure after merge of the mac80211-next tree

[Toke Høiland-Jørgensen]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:

> Hi Stephen,
>
> Thanks!
>
> Felix made me aware of this yesterday evening and said he's going to
> work out the required changes to mt76.
>
> Kalle and I will make sure to submit the trees to Dave one by one so he
> doesn't have to deal with it :)
>
> Unfortunately, this might take a few days to resolve.
>
>> -void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
>> +void mt76_wake_tx_queue(struct ieee80211_hw *hw)
>>  {
>> +	struct ieee80211_txq *txq;
>>  	struct mt76_dev *dev = hw->priv;
>> -	struct mt76_txq *mtxq = (struct mt76_txq *) txq->drv_priv;
>> -	struct mt76_queue *hwq = mtxq->hwq;
>> +	struct mt76_txq *mtxq;
>> +	struct mt76_queue *hwq;
>>  
>> +	txq = ieee80211_next_txq(hw);
>> +	mtxq = (struct mt76_txq *) txq->drv_priv;
>> +	hwq = mtxq->hwq;
>
> Looks pretty much right to me - perhaps for safety there should be a
> NULL check on txq, but OTOH when you get here it should be non-NULL.

Note that while this will fix compilation it probably won't work right.
next_txq() is not guaranteed to return the same txq as was previously
passed in the wake_tx_queue() argument, so if this is the only place the
driver calls next_txq(), things are likely going to break.

Rather, the driver should call next_txq() whenever it schedules queues
instead of doing its own internal scheduling.

> Sorry for the inconvenience, I hadn't realized mt76 went in now.

Yeah, hadn't expected these streams to cross either. If Felix is looking
into this that is great; let me know if you need me to do anything else
on the mac80211 side. :)

-Toke

Re: linux-next: build failure after merge of the mac80211-next tree

[Kalle Valo]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

>> Sorry for the inconvenience, I hadn't realized mt76 went in now.
>
> Yeah, hadn't expected these streams to cross either.

I did ask[1] if everyone are ok that I apply mt76 and I didn't get any
comments, I guess I need to make more noise next time when I'm applying
a new driver.

[1] https://lkml.kernel.org/r/87wp22jzzb.fsf@purkki.adurom.net

-- 
Kalle Valo

Re: linux-next: build failure after merge of the mac80211-next tree

[Toke Høiland-Jørgensen]

Kalle Valo <kvalo@codeaurora.org> writes:

> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>>> Sorry for the inconvenience, I hadn't realized mt76 went in now.
>>
>> Yeah, hadn't expected these streams to cross either.
>
> I did ask[1] if everyone are ok that I apply mt76 and I didn't get any
> comments,

Huh, did actually see that. But was not aware that Johannes had already
merged my patches; have been caught up in other stuff since netdev, so
have not been paying that close attention... Sorry about that, should
have pointed out the potential conflict :)

> I guess I need to make more noise next time when I'm applying a new
> driver.

Yeah, I would like to request a marching band to my apartment next time,
please. I'll send you my address off list... ;)

-Toke

linux-next: build failure after merge of the mac80211-next tree

[Stephen Rothwell]

Hi Johannes,

After merging the mac80211-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/linkage.h:4:0,
                 from include/linux/kernel.h:6,
                 from net/rfkill/core.c:20:
net/rfkill/core.c: In function 'rfkill_find_type':
include/linux/compiler.h:501:38: error: call to '__compiletime_assert_647' declared with attribute error: BUILD_BUG_ON failed: !rfkill_types[NUM_RFKILL_TYPES - 1]
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:484:4: note: in definition of macro '__compiletime_assert'
    prefix ## suffix();    \
    ^
include/linux/compiler.h:501:2: note: in expansion of macro '_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:74:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  ^
net/rfkill/core.c:647:2: note: in expansion of macro 'BUILD_BUG_ON'
  BUILD_BUG_ON(!rfkill_types[NUM_RFKILL_TYPES - 1]);
  ^

Caused by commit

  1f86443b4ffe ("net: rfkill: add rfkill_find_type function")

Maybe the compiler version matters?  I am using gcc v5.2.0.

Though, it seems to be that "!rfkill_types[NUM_RFKILL_TYPES - 1]" is
not a constant expression since

static const char *rfkill_types[NUM_RFKILL_TYPES]

does not stop "rfkill_types[NUM_RFKILL_TYPES - 1]" being modified at
run time. I think that you might need:

static const char * const rfkill_types[NUM_RFKILL_TYPES]

I have used the mac80211-next from next-20160223 for today.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the mac80211-next tree

[Johannes Berg]

Hi Stephen,

> [...]
> include/linux/bug.h:74:2: note: in expansion of macro
> 'BUILD_BUG_ON_MSG'
>   BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
>   ^
> net/rfkill/core.c:647:2: note: in expansion of macro 'BUILD_BUG_ON'
>   BUILD_BUG_ON(!rfkill_types[NUM_RFKILL_TYPES - 1]);
>   ^
> 
> Caused by commit
> 
>   1f86443b4ffe ("net: rfkill: add rfkill_find_type function")

Thanks for the heads-up.

> Maybe the compiler version matters?  I am using gcc v5.2.0.

Hm. I'm using Debian 5.3.1-8.

> Though, it seems to be that "!rfkill_types[NUM_RFKILL_TYPES - 1]" is
> not a constant expression since
> 
> static const char *rfkill_types[NUM_RFKILL_TYPES]
> 
> does not stop "rfkill_types[NUM_RFKILL_TYPES - 1]" being modified at
> run time. I think that you might need:
> 
> static const char * const rfkill_types[NUM_RFKILL_TYPES]

That's true, but since I can't test it I'll just solve this
differently. We'll never be able to insert anything into the middle, so
we can also just BUILD_BUG_ON() the ARRAY_SIZE() and do the code a bit
differently.

Thanks,
johannes