On 28 November 2011 03:59, Nick Kossifidis <mickflemm@xxxxxxxxx> wrote: >> Oh wait. Where are you clearing these bits? It doesn't look like >> you're even clearing the ah_txq_isr bits in the most recent ath5k tree >> I have here. This means you're likely not missing events; but you're >> likely always scanning those queues. Making this code a bit pointless. >> :) > > Yup we don't clean them but that's not a bug, we still only check > active queues that produced interrupts, not everything. Anyway we have > txq->lock already so it's not a big deal to implement this I'll post a > patch on top of this patchset. Right. but you're likely only using one active TXQ (and then CAB and beacon queues, which you may not be actually checking the completion status of) it won't matter. It just means if people start using >1 hardware TXQ, you're going to check the completion status on all of them. That's not a big deal, it just means you'll spend some CPU cycles and memory accesses checking queues you don't need to. You can't protect that interrupt field behind the TXQ lock either, since you'll have multiple reader/writers from outside the TXQ. Hence why I put it behind my PCU lock (which I use to protect shared PCU state, rather than PCU access like how felix did with ath9k.) Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
