> > With iwlwifi, however, there is a possibility that it invokes > > ieee80211_tx_status() on one CPU while mac80211's tasklet is processing > > another TX status that was submitted with ieee80211_tx_status_irqsafe(). > > Tomas, I think you mentioned that the TX status processing can't > > actually ever call the non-irqsafe version, can we remove that call to > > be sure? :) > > Actually alike athk also iwlwifi driver calls tx_status from a tasklet > therfore the irqsafe can be removed. I've tested that it worked so far Ok, fine too. Just the mixing is actually bad because of locking. > However we added start_tx_ba_cb(_irqsafe) callback to get around AMPDU > queues reordering > In this case we have to use both handlers so I wonder where we have > problem here as the same mechanism as tx_status is used. I think the AMPDU stuff has its own spinlock around the fields it accesses in those things. The thing with the tx status etc. is that it uses no locking to update a few sta_info fields. If we added locking around those accesses, mixing the two irqsafe/non-irqsafe versions would be acceptable, but I don't see much point in that. > In general I'm missing some asynchronous mechanism that driver can > notify mac80211 about it's state. > Except BA states there is for example netif_carrier_off/on > functionality in the driver level. It would be very useful for early > notification of disconnection. A disconnection can happen due to > device resume or internal recoverable error. In this cases I would > expect mac to try associate again upon such trigger. I guess that's just missing. You can stop the queues but you can't tell mac80211 that you reset the hw. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
