Hi, It may be; that's the problem. :/
Adrian On 12 November 2012 10:53, Thomas Pedersen <tho...@cozybit.com> wrote: > This is true for at least AR5213, and shouldn't be different for other > ath5k PHYs. > > Signed-off-by: Thomas Pedersen <tho...@cozybit.com> > --- > drivers/net/wireless/ath/ath5k/base.c | 13 +------------ > 1 file changed, 1 insertion(+), 12 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath5k/base.c > b/drivers/net/wireless/ath/ath5k/base.c > index 9f31cfa..ae1a2fe 100644 > --- a/drivers/net/wireless/ath/ath5k/base.c > +++ b/drivers/net/wireless/ath/ath5k/base.c > @@ -1335,20 +1335,9 @@ ath5k_receive_frame(struct ath5k_hw *ah, struct > sk_buff *skb, > * 15bit only. that means TSF extension has to be done within > * 32768usec (about 32ms). it might be necessary to move this to > * the interrupt handler, like it is done in madwifi. > - * > - * Unfortunately we don't know when the hardware takes the rx > - * timestamp (beginning of phy frame, data frame, end of rx?). > - * The only thing we know is that it is hardware specific... > - * On AR5213 it seems the rx timestamp is at the end of the > - * frame, but I'm not sure. > - * > - * NOTE: mac80211 defines mactime at the beginning of the first > - * data symbol. Since we don't have any time references it's > - * impossible to comply to that. This affects IBSS merge only > - * right now, so it's not too bad... > */ > rxs->mactime = ath5k_extend_tsf(ah, rs->rs_tstamp); > - rxs->flag |= RX_FLAG_MACTIME_MPDU; > + rxs->flag |= RX_FLAG_MACTIME_END; > > rxs->freq = ah->curchan->center_freq; > rxs->band = ah->curchan->band; > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
