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 <[email protected]>
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 <[email protected]>
---
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
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
Johannes Berg <[email protected]> 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
Toke Høiland-Jørgensen <[email protected]> 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/[email protected]
--
Kalle Valo
Kalle Valo <[email protected]> writes:
> Toke Høiland-Jørgensen <[email protected]> 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
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
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
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