All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Yeoh Chun-Yeow <yeohchunyeow@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH] ath10k: set the mactime of ieee80211_rx_status
Date: Thu, 27 Feb 2014 13:38:11 +0200	[thread overview]
Message-ID: <87ob1sg50c.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAEFj9870+z+2yxjO7F69bGv3XzKNmi+ddyF41WSnv2aR98kjrw@mail.gmail.com> (Yeoh Chun-Yeow's message of "Thu, 20 Feb 2014 10:47:45 +0800")

Yeoh Chun-Yeow <yeohchunyeow@gmail.com> 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.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Yeoh Chun-Yeow <yeohchunyeow@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH] ath10k: set the mactime of ieee80211_rx_status
Date: Thu, 27 Feb 2014 13:38:11 +0200	[thread overview]
Message-ID: <87ob1sg50c.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAEFj9870+z+2yxjO7F69bGv3XzKNmi+ddyF41WSnv2aR98kjrw@mail.gmail.com> (Yeoh Chun-Yeow's message of "Thu, 20 Feb 2014 10:47:45 +0800")

Yeoh Chun-Yeow <yeohchunyeow@gmail.com> 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.

-- 
Kalle Valo

  reply	other threads:[~2014-02-27 11:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12  9:37 [PATCH] ath10k: set the mactime of ieee80211_rx_status Chun-Yeow Yeoh
2014-02-12  9:37 ` Chun-Yeow Yeoh
2014-02-19 15:25 ` Kalle Valo
2014-02-19 15:25   ` Kalle Valo
2014-02-20  2:47   ` Yeoh Chun-Yeow
2014-02-20  2:47     ` Yeoh Chun-Yeow
2014-02-27 11:38     ` Kalle Valo [this message]
2014-02-27 11:38       ` Kalle Valo
2014-02-27 13:48       ` Yeoh Chun-Yeow
2014-02-27 13:48         ` Yeoh Chun-Yeow
2014-02-27 16:38 ` Kalle Valo
2014-02-27 16:38   ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ob1sg50c.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=yeohchunyeow@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.