On Friday 28 May 2010 00:14:18 Bob Copeland wrote: > Well the invariant is supposed to be that we are always behind where the > hardware is. If that holds, the hardware can't loop around and write into > the buffer we are currently processing, because we'd have to add the buffer > back to the descriptor list first. The RXDP check is supposed to ensure > that the hardware has loaded the next descriptor before we do anything with > the current one (we already "know" it is done with DMAing the SKB due to > the status register read).
yes, this makes sense. however can we always be sure, the RXDP is set to one of the descriptor adresses? could it be null or undefined, even for a short time? therefore i'd say adding the safety-net to check we don't process the self-linked descriptor wouldn't hurt. > > "ands" is the next descriptor. so if the next descriptor is NOT done and > > the RXDP points at the current descriptor, return. > > Yeah I've read it before, it doesn't make sense to me either. I think it > does make a certain amount of sense to look at RXDP for the current buffer > subject to the earlier caveats. Of course, we could try adopting all of > the paranoia of the HAL and see if it cures all ailments and then narrow > down what really matters. i spent some time today together with benoit to understand this code, and we came to the conclusion that it doesnt make sense as well. no - let's not blindly add all the "HAL paranoia" to ath5k, please... ;) bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
