Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
