On Sat, Jan 17, 2009 at 11:12:25PM +0100, Alina Friedrichsen wrote: > > I agree that merge part (updating Beacon/ProbeRsp data) can be skipped > > for same BSSID, but this change seems to break timesync by removing call > > to local->ops->reset_tsf(). I don't think that that should be removed > > unconditionally. > I have looked in the Source of ath5k and ath9k. It seens to me that the TSF sync is done in the low-level driver and/or the hardware directly. So I see no reason to set it back to zero, if you have a dummy merge to the same BSSID and channel. (E.g. caused by TSF overflows.) I think it should only done if you change the network, so BSSID and/or channel is deferent. Some hardware designs require the reset_tsf call to allow the hardware to get back in sync with the TSF based on received timestamp values in some cases. I would expect this to be used in ath9k and ath5k. This does not mean that the timestamp would be reset to zero in actual Beacon frames, i.e., this is just something done internally in the driver/firmware/hardware and the need for reset_tsf() is to just provide the notification to the driver when this special case is needed. -- Jouni Malinen PGP id EFC895FA -- 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
