Re: [ath9k-devel] Wifi basics documents
On 02/08/2013 07:55 AM, Onteddu Slreddy wrote: Hello All, I recently joined this group the group. Can anybody suggest me places where I can get Documents which will explain wifi Architecture in brief i would like to know details like In Linux for embedded systems: What is the software architecture for wifi What are each folders in kernel/net and kernel/drivers/net refer to What is wpa_supplicant how to know which version I have to use How to get familiar with words like nl802.11, mac802.11, wext, copat-wireless, compatwireless-openmac If I have to add a new chip driver what are the checklist points i have to see My Quesitions may be basic kindly bare with me If any body have self prepared documents that will be great help for me 802.11 is a IEEE standard that is freely available for download. Regarding Linux architecture and infrastructure there is a lot of information to be found on wireless.kernel.org. Regards, Arend ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFCv2 2/3] mac80211: mesh power save doze scheduling
On Wed, 2013-02-06 at 12:48 +0100, Marco Porsch wrote:
For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
a timer which triggers a doze call on expiry.
That seems questionable -- drivers are not required to request each
beacon. I know you only want to make it work on ath9k, but I don't think
stretching the API, without even documenting it, is a good idea.
+static inline void mps_queue_work(struct ieee80211_sub_if_data *sdata,
+ enum mesh_deferred_task_flags flag)
+{
+ set_bit(flag, sdata-u.mesh.wrkq_flags);
+ ieee80211_queue_work(sdata-local-hw, sdata-work);
+}
Doing any sort of wakeup from here is also undesirable -- the workqueue
might actually sometimes be blocked for quite a while, I believe.
+/**
+ * ieee80211_mps_hw_conf - check conditions for mesh PS and configure driver
+ *
+ * @sdata: local mesh subif
+ */
+void ieee80211_mps_hw_conf(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_local *local = sdata-local;
+ bool enable;
+
+ enable = mps_hw_conf_check(local);
+
+ if (local-mps_enabled == enable)
+ return;
+
+ if (enable) {
+ mps_hw_conf_sta_prepare(local);
+ local-hw.conf.flags |= IEEE80211_CONF_PS;
+ } else {
+ local-hw.conf.flags = ~IEEE80211_CONF_PS;
+ }
+
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
For some reason I thought this was supposed to be covered by the new
mesh PS callbacks, why do you still need hw conf?
Or wait -- this is only for general enable/disable, depending on the
other interfaces? I guess that's ok.
+ /* simple Deep Sleep implementation: only wake up for DTIM beacons */
+ if (sta-local_pm == NL80211_MESH_POWER_DEEP_SLEEP)
+ skip = tim-dtim_count ? tim-dtim_count : tim-dtim_period;
+ /*
+ * determine time to peer TBTT (TSF % beacon_interval = 0).
+ * This approach is robust to delayed beacons.
+ */
+ tsf_peer = tsf_local + sta-t_offset;
+ nexttbtt_interval = sta-beacon_interval * skip -
+ do_div(tsf_peer, sta-beacon_interval * skip);
+
+ mps_dbg(sta-sdata, updating %pM next TBTT in %dus (%lldus awake)\n,
+ sta-sta.addr, nexttbtt_interval,
+ (long long) tsf_local - sta-nexttbtt_tsf);
+
+ sta-nexttbtt_tsf = tsf_local + nexttbtt_interval;
+ sta-nexttbtt_jiffies = jiffies + usecs_to_jiffies(nexttbtt_interval);
+
+ mod_timer(sta-nexttbtt_timer, sta-nexttbtt_jiffies +
+ usecs_to_jiffies(BEACON_TIMEOUT));
Is that some sort of recovery? jiffies can be up to 20ms (I think, in
that order of magnitude anyway) inaccurate.
johannes
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFCv2 2/3] mac80211: mesh power save doze scheduling
On 02/08/2013 10:20 AM, Johannes Berg wrote:
On Wed, 2013-02-06 at 12:48 +0100, Marco Porsch wrote:
For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
a timer which triggers a doze call on expiry.
That seems questionable -- drivers are not required to request each
beacon. I know you only want to make it work on ath9k, but I don't think
stretching the API, without even documenting it, is a good idea.
Currently, we already use ieee80211_beacon_get_tim as time reference for
mesh sync's adjust_tbtt. And, as far as I know, all mesh-capable drivers
use the call for each and every beacon.
So what would you recommend: keep using beacon_get and adding
documentation - or - creating an exported callback for awake_window_start?
+static inline void mps_queue_work(struct ieee80211_sub_if_data *sdata,
+ enum mesh_deferred_task_flags flag)
+{
+set_bit(flag, sdata-u.mesh.wrkq_flags);
+ieee80211_queue_work(sdata-local-hw, sdata-work);
+}
Doing any sort of wakeup from here is also undesirable -- the workqueue
might actually sometimes be blocked for quite a while, I believe.
Yeah, right. Now that the hrtimer stuff is gone, I will check if the
remaining contexts allows skipping the work queue for wakeups.
+/**
+ * ieee80211_mps_hw_conf - check conditions for mesh PS and configure driver
+ *
+ * @sdata: local mesh subif
+ */
+void ieee80211_mps_hw_conf(struct ieee80211_sub_if_data *sdata)
+{
+struct ieee80211_local *local = sdata-local;
+bool enable;
+
+enable = mps_hw_conf_check(local);
+
+if (local-mps_enabled == enable)
+return;
+
+if (enable) {
+mps_hw_conf_sta_prepare(local);
+local-hw.conf.flags |= IEEE80211_CONF_PS;
+} else {
+local-hw.conf.flags = ~IEEE80211_CONF_PS;
+}
+
+ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
For some reason I thought this was supposed to be covered by the new
mesh PS callbacks, why do you still need hw conf?
Or wait -- this is only for general enable/disable, depending on the
other interfaces? I guess that's ok.
+/* simple Deep Sleep implementation: only wake up for DTIM beacons */
+if (sta-local_pm == NL80211_MESH_POWER_DEEP_SLEEP)
+skip = tim-dtim_count ? tim-dtim_count : tim-dtim_period;
+/*
+ * determine time to peer TBTT (TSF % beacon_interval = 0).
+ * This approach is robust to delayed beacons.
+ */
+tsf_peer = tsf_local + sta-t_offset;
+nexttbtt_interval = sta-beacon_interval * skip -
+do_div(tsf_peer, sta-beacon_interval * skip);
+
+mps_dbg(sta-sdata, updating %pM next TBTT in %dus (%lldus awake)\n,
+sta-sta.addr, nexttbtt_interval,
+(long long) tsf_local - sta-nexttbtt_tsf);
+
+sta-nexttbtt_tsf = tsf_local + nexttbtt_interval;
+sta-nexttbtt_jiffies = jiffies + usecs_to_jiffies(nexttbtt_interval);
+
+mod_timer(sta-nexttbtt_timer, sta-nexttbtt_jiffies +
+usecs_to_jiffies(BEACON_TIMEOUT));
Is that some sort of recovery? jiffies can be up to 20ms (I think, in
that order of magnitude anyway) inaccurate.
Yeah, that timer just hits as recovery in case a beacon is not received.
Then it projects the next TBTT and goes to sleep again.
Thanks,
--Marco
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Wifi basics documents
On 02/08/2013 10:53 AM, sl reddy wrote: any successions will be helpful for me My *suggestion* would be: http://wireless.kernel.org/en/developers/Documentation For what it is worth, below is some terrible ascii art. Gr. AvS Fullmac model: user-space (libnl) | +--+ v | cfg80211 |--o nl80211 api +--+ ^ | v +--+ | fullmac |--o netdev | driver | +--+ Softmac model: user-space (libnl) | +--+ v | cfg80211 |--o nl80211 api +--+ ^ | v +--+ | mac80211 |--o netdev +--+ ^ | v +--+ | softmac | | driver | +--+ ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k-devel Digest, Vol 56, Issue 17
Dear Compex ‘s Partner and Friends We are having Chinese New Year holiday till 18th Feb 2013 . We will reply your email as soon as we back from holiday Remy Liaw Sales Account Manager www.compex.com.sg T +65 62862086 | F +65 62809947 Let's Connect! Facebook Twitter Blog Youtube Compex Systems – Your Trusted Partner in Wireless Co ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Wifi basics documents
Hi Thanks for reply i referred that site (wireless.kernel.org) as you said there is lot of information but i am bit confused in getting right information because i am not interested much about hardware architecture as of now I need clear picture of software architecture but in the website there is lot of information so bit confused where to start any successions will be helpful for me Thanks Regards O S L Reddy slredd...@gmail.com On Fri, Feb 8, 2013 at 2:04 PM, Arend van Spriel ar...@broadcom.com wrote: On 02/08/2013 07:55 AM, Onteddu Slreddy wrote: Hello All, I recently joined this group the group. Can anybody suggest me places where I can get Documents which will explain wifi Architecture in brief i would like to know details like In Linux for embedded systems: What is the software architecture for wifi What are each folders in kernel/net and kernel/drivers/net refer to What is wpa_supplicant how to know which version I have to use How to get familiar with words like nl802.11, mac802.11, wext, copat-wireless, compatwireless-openmac If I have to add a new chip driver what are the checklist points i have to see My Quesitions may be basic kindly bare with me If any body have self prepared documents that will be great help for me 802.11 is a IEEE standard that is freely available for download. Regarding Linux architecture and infrastructure there is a lot of information to be found on wireless.kernel.org. Regards, Arend -- 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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Wifi basics documents
Thank you I will start from here Thanks Regards O S L Reddy slredd...@gmail.com On Fri, Feb 8, 2013 at 3:50 PM, Arend van Spriel ar...@broadcom.com wrote: On 02/08/2013 10:53 AM, sl reddy wrote: any successions will be helpful for me My *suggestion* would be: http://wireless.kernel.org/en/developers/Documentation For what it is worth, below is some terrible ascii art. Gr. AvS Fullmac model: user-space (libnl) | +--+ v | cfg80211 |--o nl80211 api +--+ ^ | v +--+ | fullmac |--o netdev | driver | +--+ Softmac model: user-space (libnl) | +--+ v | cfg80211 |--o nl80211 api +--+ ^ | v +--+ | mac80211 |--o netdev +--+ ^ | v +--+ | softmac | | driver | +--+ ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages
On Thu, Feb 07, 2013 at 01:46:27PM -0800, Joe Perches wrote: alloc failures already get standardized OOM messages and a dump_stack. For the affected mallocs around these OOM messages: Converted kmallocs with multiplies to kmalloc_array. Converted a kmalloc/memcpy to kmemdup. Removed now unused stack variables. Removed unnecessary parentheses. Neatened alignment. Signed-off-by: Joe Perches j...@perches.com No objection... Acked-by: John W. Linville linvi...@tuxdriver.com -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Auth Packet TX Delay
Maybe I have the terminology wrong, but I thought a cold reset meant toggling the PCI reset line. On Thu, Feb 7, 2013 at 4:40 PM, Adrian Chadd adr...@freebsd.org wrote: On 7 February 2013 11:43, Robert Shade robert.sh...@gmail.com wrote: AR9160 / AR9106 Things are getting into a really odd state if that particular initial calibration isn't finishing... Things I can think of: * There's some kind of noise going on that's angering the PHY (eg a spur); * We should be doing a cold reset instead of a warm reset, upon a channel change; (That fixes some issues I've seen on the AR9280 in some environments); * Bad/incorrectly hooked up antenans. From a software side, nothing much can be going wrong. as long as the driver isn't doing something stupid like running multiple copies of the reset / setup path on different CPUs/threads, it should be reliable. HTH, Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFCv2 2/3] mac80211: mesh power save doze scheduling
On Fri, 2013-02-08 at 11:09 +0100, Marco Porsch wrote: For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start a timer which triggers a doze call on expiry. That seems questionable -- drivers are not required to request each beacon. I know you only want to make it work on ath9k, but I don't think stretching the API, without even documenting it, is a good idea. Currently, we already use ieee80211_beacon_get_tim as time reference for mesh sync's adjust_tbtt. And, as far as I know, all mesh-capable drivers use the call for each and every beacon. Oops, why did I miss that before? :-) So what would you recommend: keep using beacon_get and adding documentation - or - creating an exported callback for awake_window_start? I guess you could add it... However, I don't really fully understand. There's no guarantee that fetching the beacon is done anywhere close to TBTT? Or does ath9k happen to do it just after TXing a beacon? You're encoding quite a lot of ath9k-specific assumptions here it seems? johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k-devel Digest, Vol 56, Issue 18
Dear Compex ‘s Partner and Friends We are having Chinese New Year holiday till 18th Feb 2013 . We will reply your email as soon as we back from holiday Remy Liaw Sales Account Manager www.compex.com.sg T +65 62862086 | F +65 62809947 Let's Connect! Facebook Twitter Blog Youtube Compex Systems – Your Trusted Partner in Wireless Co ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages
From: Joe Perches j...@perches.com Date: Thu, 07 Feb 2013 13:46:27 -0800 alloc failures already get standardized OOM messages and a dump_stack. For the affected mallocs around these OOM messages: Converted kmallocs with multiplies to kmalloc_array. Converted a kmalloc/memcpy to kmemdup. Removed now unused stack variables. Removed unnecessary parentheses. Neatened alignment. Signed-off-by: Joe Perches j...@perches.com Applied, thanks Joe. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
