On Thu, Feb 27, 2014 at 7:38 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: > Yeoh Chun-Yeow <yeohchunyeow@xxxxxxxxx> writes: > >>> Why? Where do you need tsf exactly? And what bug are you actually fixing >>> here? >> >> There are two type of configuration modes that require local TSF, IBSS >> and mesh for operation and also monitor mode. >> >> For IBSS, it is use for merging of BSSID (mac address) with same SSID >> name, but currently this is taking care by the following "ugly" patch. >> http://lists.infradead.org/pipermail/ath10k/2014-February/001159.html >> >> Mesh mode needs this for more accurate synchronization purpose. >> >> Besides, the monitor mode requires this to add extra piece of >> information in radiotap header for local TSF. >> >>> Do we get some regressions because of proving only a 32 bit TSF? Which >>> one is better, provide a 32-bit TSF or not at all? >> >> 32-bit is not good. It could cause problem when inter-operate with >> other non-ath10k drivers with 64-bit local TSF. > > Yeah, I understand that. But my question is will we create regressions > if I apply this patch which provides only 32-bit TSF? I guess not as we > haven't provided TSF at all before, but I would like to be sure. > >> The better is that we can get the 64-bit local TSF. providing high TSF >> and low TSF as found in "struct wmi_comb_phyerr_rx_hd". Is this >> possible with current FW? > > I'm not familiar with the firmware so I sent a question to the firmware > team about this. Great, appreciate if the FW team can take a look on this. Hope to hear from you again on this. ---- Chun-Yeow -- 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
