* RE: What pieces are needed for wl1271..what directories, files, configs, etc..
From: Brzezowski, Karen @ 2011-01-11 19:05 UTC (permalink / raw)
To: Krakowski, Oz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinjGLvWbSnfeNoUkoC2q4jN+uRntSYS6MAvm1vv@mail.gmail.com>
Hi Oz,
Thank you for your response. I have been looking at that web page:
http://linuxwireless.org/en/users/Drivers/wl12xx
when i get the latest driver at
git clone git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
Do I take everything that comes in this compressed file and replace it in a Linux kernel?
Which Linux kernel is this driver code for?
I'm not really sure what the compat-wireless is...we are using the Linux 2.6.31 kernel
Do I need to get compat-wireless somehow for the 31 kernel?
Then the notes say integrations needs to be gotten for SDIO, Lenient, and platform data pasing..
Then the notes say I need WL127x firmware...
after all that I can build the kernel?
Do you have any example code that uses the interfaces for the wl1271 chip (the APIs)?
I've never ported a driver in Linux before...
I assumed all it would be is to get the driver directory corresponding to the new chip, adding or replacing it
in the drivers directory, build it, and voila, i have a driver to test..
I think I should not have assumed that, correct?
...this is why I'm confused........
:-)
thank you for your time!!!!!!!!!!
Karen
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] on behalf of Krakowski, Oz [ozk@ti.com]
Sent: Tuesday, January 11, 2011 12:13 AM
To: Brzezowski, Karen
Cc: linux-wireless@vger.kernel.org
Subject: Re: What pieces are needed for wl1271..what directories, files, configs, etc..
Hi Karen,
On Mon, Jan 10, 2011 at 10:44 AM, Brzezowski, Karen
<Karen.Brzezowski@pdt.com> wrote:
>
> Hello all wireless gurus!!
>
> I've been watching the linux-wireless mailings on the wl1271...........
>
> I've been trying to figure out how to get the wl1271 working with
> imx233 processor...
>
> I think we are moving to Linux 2.6.35 and android gingerbread (2.3)...
>
> I"m very confused as to what files/configs/etc..need to be grabbed to get my task going.......
>
> I see spi, sdio...not sure where all changes are made for the wl1271...i'm assuming
> not just in the ...net/wireless/wl1271 directory.......... i have firmware too...........(.bins..)
>
> I'm quite confused about the chip and how each part will work (BT, WLAN, and FM)...
> Do you have any documentation..(for dummies, that would be me!)
> that would help me understand about the chip..how it communicates to the processor,
> how it does it's job with respect to BT, WLAN, and FM, etc..
>
> I have NO idea where to begin.......I've been googling and reading and I have downloaded
> your wl12xx git........
If you haven't done so already, suggest you start by going through the
following wiki page: http://linuxwireless.org/en/users/Drivers/wl12xx
This should give you an idea of where to get the latest code, how to
compile it to your kernel (using compat-wireless) and links to the
relevant patches needed.
This will get you started with WLAN.
>
> If you can help me AT ALL to get me up to speed/ to start, what i need to do to connect
> the wl1271 to the imx233....if not imx233..that whatever you have........
The wiki page does include some basic information needed in order to
port to different hardware platforms.
Regards,
Oz.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] wl12xx: lock the RCU when accessing sta via ieee80211_find_sta()
From: coelho @ 2011-01-11 18:07 UTC (permalink / raw)
To: linux-wireless; +Cc: jonathanc
From: Luciano Coelho <coelho@ti.com>
We were calling ieee80211_find_sta() and the sta returned by it
without locking the RCU, which is required by mac80211.
Fix this and reorganize slightly the area of the code where the sta is
used.
Reported-by: Jonathan DE CESCO <jonathanc@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
drivers/net/wireless/wl12xx/main.c | 60 +++++++++++++++++++----------------
1 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 862ec9c..67732ea 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2219,7 +2219,7 @@ static void wl1271_bss_info_changed_sta(struct wl1271 *wl,
bool do_join = false, set_assoc = false;
bool is_ibss = (wl->bss_type == BSS_TYPE_IBSS);
int ret;
- struct ieee80211_sta *sta = ieee80211_find_sta(vif, bss_conf->bssid);
+ struct ieee80211_sta *sta;
if (is_ibss) {
ret = wl1271_bss_beacon_info_changed(wl, vif, bss_conf,
@@ -2376,36 +2376,42 @@ static void wl1271_bss_info_changed_sta(struct wl1271 *wl,
if (ret < 0)
goto out;
- /*
- * Takes care of: New association with HT enable,
- * HT information change in beacon.
- */
- if (sta &&
- (changed & BSS_CHANGED_HT) &&
- (bss_conf->channel_type != NL80211_CHAN_NO_HT)) {
- ret = wl1271_acx_set_ht_capabilities(wl, &sta->ht_cap, true);
- if (ret < 0) {
- wl1271_warning("Set ht cap true failed %d", ret);
- goto out;
- }
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, bss_conf->bssid);
+ if (sta) {
+ /* handle new association with HT and HT information change */
+ if ((changed & BSS_CHANGED_HT) &&
+ (bss_conf->channel_type != NL80211_CHAN_NO_HT)) {
+ ret = wl1271_acx_set_ht_capabilities(wl, &sta->ht_cap,
+ true);
+ if (ret < 0) {
+ wl1271_warning("Set ht cap true failed %d",
+ ret);
+ rcu_read_unlock();
+ goto out;
+ }
ret = wl1271_acx_set_ht_information(wl,
- bss_conf->ht_operation_mode);
- if (ret < 0) {
- wl1271_warning("Set ht information failed %d", ret);
- goto out;
+ bss_conf->ht_operation_mode);
+ if (ret < 0) {
+ wl1271_warning("Set ht information failed %d",
+ ret);
+ rcu_read_unlock();
+ goto out;
+ }
}
- }
- /*
- * Takes care of: New association without HT,
- * Disassociation.
- */
- else if (sta && (changed & BSS_CHANGED_ASSOC)) {
- ret = wl1271_acx_set_ht_capabilities(wl, &sta->ht_cap, false);
- if (ret < 0) {
- wl1271_warning("Set ht cap false failed %d", ret);
- goto out;
+ /* handle new association without HT and disassociation */
+ else if (changed & BSS_CHANGED_ASSOC) {
+ ret = wl1271_acx_set_ht_capabilities(wl, &sta->ht_cap,
+ false);
+ if (ret < 0) {
+ wl1271_warning("Set ht cap false failed %d",
+ ret);
+ rcu_read_unlock();
+ goto out;
+ }
}
}
+ rcu_read_unlock();
if (changed & BSS_CHANGED_ARP_FILTER) {
__be32 addr = bss_conf->arp_addr_list[0];
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] wl12xx: reset 5ghz num channels on hw init
From: Luciano Coelho @ 2011-01-11 17:37 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1294693444-30807-1-git-send-email-arik@wizery.com>
On Mon, 2011-01-10 at 22:04 +0100, Arik Nemtsov wrote:
> The number of 5ghz channels is set to 0 when 11a is not supported in the
> NVS file. When a single rmmod/insmod of wl12xx_sdio this leads to a
> supported band (5ghz) with 0 supported channels, which mac80211
> considers illegal.
>
> Fix this by always resetting the number of supported 5ghz channels
> before the HW is registered.
>
> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> ---
Just for the record, this patch is not necessary anymore, once my new
patch that avoids changing the global structs (as suggested by Johannes)
gets in.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
From: Pekka Enberg @ 2011-01-11 17:33 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Jesper Juhl, linux-wireless, users, linux-kernel, netdev,
Gertjan van Wingerde, John W. Linville
In-Reply-To: <AANLkTimDHO=oiR3ncX4BLmMJaoUAmaQL6r=bZcWV4-Gg@mail.gmail.com>
On Tue, Jan 11, 2011 at 7:30 PM, Ivo Van Doorn <ivdoorn@gmail.com> wrote:
> Hi,
>
>> We need to release_firmware() in order not to leak memory.
>>
>> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> I can assume that release_firmware() checks if 'fw' is null?
Yes, it does.
> If so:
>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
^ permalink raw reply
* Re: [PATCH] rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
From: Ivo Van Doorn @ 2011-01-11 17:30 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-wireless, users, linux-kernel, netdev, Gertjan van Wingerde,
John W. Linville
In-Reply-To: <alpine.LNX.2.00.1101110044580.32164@swampdragon.chaosbits.net>
Hi,
> We need to release_firmware() in order not to leak memory.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
I can assume that release_firmware() checks if 'fw' is null?
If so:
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> rt2x00firmware.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00firmware.c b/drivers/net/wireless/rt2x00/rt2x00firmware.c
> index f0e1eb7..be0ff78 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00firmware.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00firmware.c
> @@ -58,6 +58,7 @@ static int rt2x00lib_request_firmware(struct rt2x00_dev *rt2x00dev)
>
> if (!fw || !fw->size || !fw->data) {
> ERROR(rt2x00dev, "Failed to read Firmware.\n");
> + release_firmware(fw);
> return -ENOENT;
> }
>
>
>
> --
> Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please.
>
>
^ permalink raw reply
* [PATCH] wl12xx: don't modify the global supported band structures
From: coelho @ 2011-01-11 17:25 UTC (permalink / raw)
To: linux-wireless; +Cc: arik, johannes, Luciano Coelho
From: Luciano Coelho <coelho@ti.com>
When 11a is not supported, we were modifying the global structure that
contains the bands supported by the driver. This causes problems when
having more one wl12xx device in the same system because they all use
the same global. This also causes problems when the wl12xx_sdio
module is removed and the wl12xx module remains.
Fix this problem by copying the band structure into the wl12xx
instance.
Reported-by: Arik Nemtsov <arik@wizery.com>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
drivers/net/wireless/wl12xx/main.c | 16 ++++++++++++++--
drivers/net/wireless/wl12xx/wl12xx.h | 3 +++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 8a35491..862ec9c 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -3148,8 +3148,20 @@ int wl1271_init_ieee80211(struct wl1271 *wl)
*/
wl->hw->wiphy->max_scan_ie_len = WL1271_CMD_TEMPL_MAX_SIZE -
sizeof(struct ieee80211_header);
- wl->hw->wiphy->bands[IEEE80211_BAND_2GHZ] = &wl1271_band_2ghz;
- wl->hw->wiphy->bands[IEEE80211_BAND_5GHZ] = &wl1271_band_5ghz;
+
+ /*
+ * We keep local copies of the band structs because we need to
+ * modify them on a per-device basis.
+ */
+ memcpy(&wl->bands[IEEE80211_BAND_2GHZ], &wl1271_band_2ghz,
+ sizeof(wl1271_band_2ghz));
+ memcpy(&wl->bands[IEEE80211_BAND_5GHZ], &wl1271_band_5ghz,
+ sizeof(wl1271_band_5ghz));
+
+ wl->hw->wiphy->bands[IEEE80211_BAND_2GHZ] =
+ &wl->bands[IEEE80211_BAND_2GHZ];
+ wl->hw->wiphy->bands[IEEE80211_BAND_5GHZ] =
+ &wl->bands[IEEE80211_BAND_5GHZ];
wl->hw->queues = 4;
wl->hw->max_rates = 1;
diff --git a/drivers/net/wireless/wl12xx/wl12xx.h b/drivers/net/wireless/wl12xx/wl12xx.h
index 80e0e39..cf5c1a5 100644
--- a/drivers/net/wireless/wl12xx/wl12xx.h
+++ b/drivers/net/wireless/wl12xx/wl12xx.h
@@ -457,6 +457,9 @@ struct wl1271 {
/* recoreded keys for AP-mode - set here before AP startup */
struct wl1271_ap_key *recorded_ap_keys[MAX_NUM_KEYS];
+
+ /* bands supported by this instance of wl12xx */
+ struct ieee80211_supported_band bands[IEEE80211_NUM_BANDS];
};
struct wl1271_station {
--
1.7.1
^ permalink raw reply related
* Re: linux-next: Tree for January 11 (build errors/warnings summary)
From: Randy Dunlap @ 2011-01-11 17:14 UTC (permalink / raw)
To: Stephen Rothwell, linux-wireless, linux-acpi
Cc: linux-next, LKML, driverdevel
In-Reply-To: <20110111143357.abe434a5.sfr@canb.auug.org.au>
On Tue, 11 Jan 2011 14:33:57 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Reminder: do not add any v2.6.39 material to your linux-next included
> trees until after v2.6.38-rc1 is released.
>
> Changes since 20110110:
drivers/thermal/thermal_sys.c build fails when CONFIG_NET is not enabled
Patch has been posted but not merged.
drivers/acpi/internal.h:94: warning: no return statement in function returning non-void
drivers/staging/ath6kl/os/linux/cfg80211.c:1378: warning: initialization from incompatible pointer type
drivers/staging/ath6kl/os/linux/cfg80211.c:1386: warning: initialization from incompatible pointer type
drivers/staging/ath6kl/os/linux/ioctl.c: In function 'ar6000_ioctl':
drivers/staging/ath6kl/os/linux/ioctl.c:4673: warning: the frame size of 1852 bytes is larger than 1024 bytes
drivers/staging/rt2860/common/mlme.c: In function 'BssTableSortByRssi':
drivers/staging/rt2860/common/mlme.c:4200: warning: the frame size of 1568 bytes is larger than 1024 bytes
drivers/staging/rt2860/common/cmm_aes.c: In function 'AES_GTK_KEY_WRAP':
drivers/staging/rt2860/common/cmm_aes.c:1248: warning: the frame size of 1084 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta/sync.c: In function 'PeerBeaconAtScanAction':
drivers/staging/rt2860/sta/sync.c:663: warning: the frame size of 1248 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta/sync.c: In function 'PeerBeacon':
drivers/staging/rt2860/sta/sync.c:1697: warning: the frame size of 1296 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta/sync.c: In function 'PeerBeaconAtJoinAction':
drivers/staging/rt2860/sta/sync.c:1033: warning: the frame size of 1256 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta/sync.c: In function 'MlmeStartReqAction':
drivers/staging/rt2860/sta/sync.c:545: warning: the frame size of 1060 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta/connect.c: In function 'CntlOidScanProc':
drivers/staging/rt2860/sta/connect.c:321: warning: the frame size of 1596 bytes is larger than 1024 bytes
drivers/staging/rt2860/rt_linux.c: In function 'send_monitor_packets':
drivers/staging/rt2860/rt_linux.c:903: warning: the frame size of 1080 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta_ioctl.c: In function 'rt_ioctl_iwaplist':
drivers/staging/rt2860/sta_ioctl.c:721: warning: the frame size of 1296 bytes is larger than 1024 bytes
drivers/staging/rt2860/sta_ioctl.c: In function 'rt_ioctl_siwmlme':
drivers/staging/rt2860/sta_ioctl.c:1615: warning: the frame size of 1584 bytes is larger than 1024 bytes
drivers/staging/vt6655/device_main.c: In function 'device_ioctl':
drivers/staging/vt6655/device_main.c:3579: warning: the frame size of 1296 bytes is larger than 1024 bytes
drivers/staging/vt6655/iwctl.c: In function 'iwctl_giwaplist':
drivers/staging/vt6655/iwctl.c:817: warning: the frame size of 1296 bytes is larger than 1024 bytes
drivers/media/radio/radio-aimslab.c:76: error: implicit declaration of function 'msleep'
(reported yesterday by Geert)
arch/x86/kernel/e820.c:734: error: implicit declaration of function 'suspend_nvs_register'
when CONFIG_ACPI is not enabled
fs/btrfs/ctree.h:1003: error: field 'super_kobj' has incomplete type
fs/btrfs/ctree.h:1074: error: field 'root_kobj' has incomplete type
needs <linux/kobject.h>
(already reported)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH] [RFC] ath9k: Fix reporting of RX STBC streams to userspace
From: Bernhard Walle @ 2011-01-11 16:59 UTC (permalink / raw)
To: lrodriguez, jmalinen, vasanth, senthilkumar, linville
Cc: linux-wireless, ath9k-devel, netdev, linux-kernel
While the driver reports
ath: TX streams 2, RX streams: 2
in the kernel log (with ATH_DBG_CONFIG set in the debug module
parameter), "iw list" only reported
[...]
Capabilities: 0x12ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-streams
[...]
The driver seems to set the value as flag while the iw tool interprets
it as number. This patch fixes that.
Signed-off-by: Bernhard Walle <walle@corscience.de>
---
drivers/net/wireless/ath/ath9k/init.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 639dc93..935b6c3 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -215,17 +215,17 @@ static void setup_ht_cap(struct ath_softc *sc,
else
max_streams = 2;
- if (AR_SREV_9280_20_OR_LATER(ah)) {
- if (max_streams >= 2)
- ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
- ht_info->cap |= (1 << IEEE80211_HT_CAP_RX_STBC_SHIFT);
- }
-
/* set up supported mcs set */
memset(&ht_info->mcs, 0, sizeof(ht_info->mcs));
tx_streams = ath9k_cmn_count_streams(common->tx_chainmask, max_streams);
rx_streams = ath9k_cmn_count_streams(common->rx_chainmask, max_streams);
+ if (AR_SREV_9280_20_OR_LATER(ah)) {
+ if (max_streams >= 2)
+ ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
+ ht_info->cap |= (rx_streams << IEEE80211_HT_CAP_RX_STBC_SHIFT);
+ }
+
ath_print(common, ATH_DBG_CONFIG,
"TX streams %d, RX streams: %d\n",
tx_streams, rx_streams);
--
1.7.1
^ permalink raw reply related
* Re: wl12xx compat wireless rcu_read_lock issue
From: Luciano Coelho @ 2011-01-11 16:59 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=4H6TXvXWi_KVBEn3G_aNW_8qZfBF7g36WRED6@mail.gmail.com>
On Tue, 2011-01-11 at 17:03 +0100, Arik Nemtsov wrote:
> On Tue, Jan 11, 2011 at 13:28, Luciano Coelho <coelho@ti.com> wrote:
> > I hadn't seen it before, but then again, I just integrated the AP
> > patches which added this code. The code has been tested quite well
> > before, but indeed this is broken.
[...]
> Actually this change is part of the HT patch series (in patch
> 18357850b694ba3fa29363c7d86ccd8783f4a065) so it was there quite some
> time.
> But I did port over without noticing the bug :)
Right, I didn't check very carefully when the bug was introduced and it
doesn't matter much anyway. But it's a bug and needs to be fixed. Does
any volunteers to send a patch or should I do it myself? (feeling
lazy :P)
--
Cheers,
Luca.
^ permalink raw reply
* Re: 5GHz 802.11n USB Adapter
From: Ivo Van Doorn @ 2011-01-11 16:39 UTC (permalink / raw)
To: Kalle Valo
Cc: Helmut Schaa, Jason Andryuk, linux-wireless, Gertjan van Wingerde,
Johannes Stezenbach
In-Reply-To: <87ei8jfnq2.fsf@purkki.adurom.net>
Hi,
>> Fine with me but AFAIK there are quite some users out there that use
>> rt2800usb in AP mode.
>
> Yeah, but they are using a broken implementation and will have random
> problems because of missing broadcast and multicast packets, for
> example ARP is a likely problem area. We discussed about this last
> year, I think.
>
>> In the end Ivo or Gertjan should have a chance to comment ;)
>
> Naturally :)
>
>> And furthermore Johannes Stezenbach is interested in getting rt2800usb
>> to do the mc- and bc buffering correctly. Not sure if he already had a chance
>> to investigate more.
>
> That would be the best option, but in the mean time we should disable
> AP mode.
Ok, but please don't restrict only to rt2800usb then. Basically _all_ rt2x00 USB
drivers are not functioning. Also I assume it means that also Mesh
mode, Secondary,
and Ad-hoc should also be disabled?
Ivo
^ permalink raw reply
* Re: 5GHz 802.11n USB Adapter
From: Johannes Stezenbach @ 2011-01-11 16:34 UTC (permalink / raw)
To: Kalle Valo
Cc: Helmut Schaa, Jason Andryuk, linux-wireless, Ivo Van Doorn,
Gertjan van Wingerde
In-Reply-To: <87ei8jfnq2.fsf@purkki.adurom.net>
On Tue, Jan 11, 2011 at 05:45:41PM +0200, Kalle Valo wrote:
> Helmut Schaa <helmut.schaa@googlemail.com> writes:
>
> > And furthermore Johannes Stezenbach is interested in getting rt2800usb
> > to do the mc- and bc buffering correctly. Not sure if he already had a chance
> > to investigate more.
>
> That would be the best option, but in the mean time we should disable
> AP mode.
>
> During the years I have suffered so much from broken power save
> implementations in different access points. I really do not want us to
> do the same mistake.
That's fine by me. At this time it is not clear if and when we
will have working support for mc- and bc buffering in rt2800usb.
I have one idea to try but no idea yet how well it will work.
Johannes
^ permalink raw reply
* Re: Locking problem reported for mainline
From: Larry Finger @ 2011-01-11 16:31 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
In-Reply-To: <201101102018.35232.chunkeey@googlemail.com>
On 01/10/2011 01:18 PM, Christian Lamparter wrote:
> On Monday 10 January 2011 20:11:38 Larry Finger wrote:
>> On 01/10/2011 12:13 PM, Christian Lamparter wrote:
>>> Does this patch help?
>>>
>>> ---
>>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>>> index a6701ed..8f13a83 100644
>>> --- a/net/mac80211/rx.c
>>> +++ b/net/mac80211/rx.c
>>
>> Did not compile. In ieee80211_release_reorder_frame at lines 552 and 554, rx is
>> not defined.
>>
> Oops,
>
> you are right. Fixed the copy&paste error, so this one should compile.
No, the patch did not help.
Is there a document that explains what the meaning of these semantics?
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
kdostartupconfi/3502 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&list->lock)->rlock#5){?.-...}, at: [<ffffffff812995c6>]
skb_queue_tail+0x26/0x60
{HARDIRQ-ON-W} state was registered at:
...
It appears that the problem is with rtlwifi, thus I need to sort it out. Google
has not been my friend in this case.
Thanks,
Larry
^ permalink raw reply
* Re: 5GHz 802.11n USB Adapter
From: Kalle Valo @ 2011-01-11 15:45 UTC (permalink / raw)
To: Helmut Schaa
Cc: Jason Andryuk, linux-wireless, Ivo Van Doorn,
Gertjan van Wingerde, Johannes Stezenbach
In-Reply-To: <201101111557.46845.helmut.schaa@googlemail.com>
Helmut Schaa <helmut.schaa@googlemail.com> writes:
> Am Dienstag, 11. Januar 2011 schrieb Kalle Valo:
>> Helmut Schaa <helmut.schaa@googlemail.com> writes:
>>
>> Ok, thanks. I'll try to come up with a patch which disables AP mode
>> for rt2800usb.
>
> Fine with me but AFAIK there are quite some users out there that use
> rt2800usb in AP mode.
Yeah, but they are using a broken implementation and will have random
problems because of missing broadcast and multicast packets, for
example ARP is a likely problem area. We discussed about this last
year, I think.
> In the end Ivo or Gertjan should have a chance to comment ;)
Naturally :)
> And furthermore Johannes Stezenbach is interested in getting rt2800usb
> to do the mc- and bc buffering correctly. Not sure if he already had a chance
> to investigate more.
That would be the best option, but in the mean time we should disable
AP mode.
During the years I have suffered so much from broken power save
implementations in different access points. I really do not want us to
do the same mistake.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] mac80211: Wait with enabling beacons on DFS channels
From: Bernhard Schmidt @ 2011-01-11 15:14 UTC (permalink / raw)
To: Wojciech Dubowik; +Cc: linux-wireless, lrodriguez, nbd, Johannes Berg
In-Reply-To: <15461044.40.1294756856032.JavaMail.wlan@CHBU500181>
On Tuesday, January 11, 2011 15:40:56 Wojciech Dubowik wrote:
> Hello,
> Basic DFS functionality requires that when we change to radar
> enabled channels we need to wait and listen before we can send
> beacons/frames -> Channel Availability Check (CAC).
> There is a case when we can switch to it immediately if we have
> been monitoring it off_channel for specific time. This is bit
> more complicated and doesn't need to be implemented in the first
> place because it's sort of functional optimization.
>
> Anyway there is a need for mechanism to control when to enable
> beacons if we switch to radar channel.
>
> Pseudo-code-diff bellow is an example for ath9k where we could enable
> beacons at once or fire a worker to re-enable it after CAC expires
> if radar hasn't been detected. In theory we need only to disable
> beacons because we shouldn't get any directed frames we could reply
> to and stations anyway can't probe directly. In practice to be
> sure it couldn't be probably done with making rx filters more
> restrictive during CAC period. Maybe there are other ways as well.
>
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -285,8 +285,14 @@
> ath9k_hw_set_interrupts(ah, ah->imask);
>
> if (!(sc->sc_flags & (SC_OP_OFFCHANNEL))) {
> - if (sc->sc_flags & SC_OP_BEACONS)
> - ath_beacon_config(sc, NULL);
> +
> + if (sc->sc_flags & SC_OP_BEACONS) {
> + if (channel->flags & IEEE80211_CHAN_RADAR
> + && !(channel->flags &
> IEEE80211_CHAN_NOL_FREE)) +
ieee80211_queue_delayed_work
> + (sc->hw, &sc->dfs_wait_cac_work, 0);
> + else
> + ath_beacon_config(sc, NULL);
> + }
> +
> ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
0);
> ath_start_ani(common);
> }
>
>
>
> Problem with this solution is that every driver would need to do
> their own timers and state machines to get this functionality which
> is shared by all.
> I don't know about other driver's structures but maybe a better way
> would be to implement mac80211 command to disable/enable beacons and
> set rx filters which every driver supporting DFS would have to implement.
> Mac80211 would have then timer which would control when to enable
> beacons. I guess Non Occupancy List (NOL) would be handled there as
> well so all the DFS timers could be in the same place.
>
> Any comments?
Afaik we did discuss this on IRC a few weeks ago and if I remember correctly
we decided to discard any configuration request before the CAC is over and the
channel is marked as 'clean'. As in, hostapd is modified such that it sends a
'do radar stuff now' command and only if the channel can be marked as clean
sending the actual configuration, in between those is the CAC period.
--
Best regards,
Dipl.-Inf. (FH) Bernhard Schmidt (software development)
saxnet GmbH, Willy-Brandt-Ring 1, 08606 Oelsnitz
Tel. +49 (0) 3741 300 6. 100 - Fax +49 (0) 3741 300 6. 101
managing director: Steffen Dreise - county court Chemnitz - HRB 23017
http://www.saxnet.de
^ permalink raw reply
* Re: [PATCH] cfg80211: Extend channel to frequency mapping for 802.11j
From: Dan Williams @ 2011-01-11 15:09 UTC (permalink / raw)
To: Brian Prodoehl
Cc: Johannes Berg, Gertjan van Wingerde, libertas-dev, Bruno Randolf,
Ivo van Doorn, linux-wireless, linville, users
In-Reply-To: <AANLkTimg_udpa78Fbq+-48rOC38_jg_afaME=PYCsChr@mail.gmail.com>
On Tue, 2011-01-11 at 08:16 -0500, Brian Prodoehl wrote:
> On Tue, Jan 11, 2011 at 7:18 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Tue, 2011-01-11 at 18:17 +0900, Bruno Randolf wrote:
> >
> >> > compat-wireless-2011-01-07.orig/drivers/net/wireless/libertas/cfg.c 2011-0
> >> > 1-07 15:03:59.000000000 -0500
> >> > +++
> >> > compat-wireless-2011-01-07/drivers/net/wireless/libertas/cfg.c 2011-01-08
> >> > 07:51:23.947290769 -0500
> >> > @@ -607,7 +607,8 @@
> >> > /* No channel, no luck */
> >> > if (chan_no != -1) {
> >> > struct wiphy *wiphy = priv->wdev->wiphy;
> >> > - int freq = ieee80211_channel_to_frequency(chan_no);
> >> > + int freq = ieee80211_channel_to_frequency(chan_no,
> >> > + chan_no <= 14 ? IEEE80211_BAND_2GHZ :
> >> IEEE80211_BAND_5GHZ);
> >>
> >> The whole point of having the band argument is to avoid this. We now have
> >> overlapping channel numbers: channel 8 and 12 are defined in 5GHz as well as
> >> in 2.4GHz (that is for 20MHz channel width, there are more for 10 and 5MHz
> >> width, but we don't support that yet). The band has to come from the hardware
> >> or driver configuration.
> >
> > I don't think libertas (or orinoco) support the frequencies that
> > overlap, and they use the channel number in HW config, so it should be
> > fine.
> >
> > johannes
>
> That's what it looked like to me, as well, for libertas. For rt2x00,
> with it's dependence on binary firmwares from Ralink, extending the
> channel set seems very far from trivial. Ralink advertises compliance
> with 802.11j (http://web.ralinktech.com/ralink/data/RT2800.pdf). A
> year and a half ago I asked them directly what that compliance means
> (4.9GHz channels? 10MHz channel width? misprint?) and didn't get a
> response. A way to pull the band for rt2x00 didn't pop out at me, but
> if the maintainers have suggestions, that'll be great. Also, if they
> have some idea what the level of 802.11j compliance is, I'd love to
> know!
While some libertas/fullmac devices do apparently support A, I haven't
seen any in person or heard of them in real use. And the current
libertas driver certainly doesn't support 802.11a and wont, unless we
magically find a part that does.
Dan
^ permalink raw reply
* Re: 5GHz 802.11n USB Adapter
From: Helmut Schaa @ 2011-01-11 14:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Jason Andryuk, linux-wireless, Ivo Van Doorn,
Gertjan van Wingerde, Johannes Stezenbach
In-Reply-To: <87ipxvfqg1.fsf@purkki.adurom.net>
Am Dienstag, 11. Januar 2011 schrieb Kalle Valo:
> Helmut Schaa <helmut.schaa@googlemail.com> writes:
>
> >> If some hardware models don't support broadcast/multicast buffering in
> >> that case the driver shouldn't allow AP mode, at least not in mainline
> >> kernels. We shouldn't break the standarnd knowingly.
> >>
> >> From a quick grep it looks like rt2800usb enables AP mode. Is that the
> >> case or did I misunderstood something?
> >
> > You're right, rt2800usb enables AP mode despite the lack of proper
> > mc- and bc buffering.
>
> Ok, thanks. I'll try to come up with a patch which disables AP mode
> for rt2800usb.
Fine with me but AFAIK there are quite some users out there that use rt2800usb
in AP mode. In the end Ivo or Gertjan should have a chance to comment ;)
And furthermore Johannes Stezenbach is interested in getting rt2800usb
to do the mc- and bc buffering correctly. Not sure if he already had a chance
to investigate more.
Helmut
^ permalink raw reply
* Re: 5GHz 802.11n USB Adapter
From: Kalle Valo @ 2011-01-11 14:46 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Jason Andryuk, linux-wireless
In-Reply-To: <201101101703.45802.helmut.schaa@googlemail.com>
Helmut Schaa <helmut.schaa@googlemail.com> writes:
>> If some hardware models don't support broadcast/multicast buffering in
>> that case the driver shouldn't allow AP mode, at least not in mainline
>> kernels. We shouldn't break the standarnd knowingly.
>>
>> From a quick grep it looks like rt2800usb enables AP mode. Is that the
>> case or did I misunderstood something?
>
> You're right, rt2800usb enables AP mode despite the lack of proper
> mc- and bc buffering.
Ok, thanks. I'll try to come up with a patch which disables AP mode
for rt2800usb.
--
Kalle Valo
^ permalink raw reply
* [RFC] mac80211: Wait with enabling beacons on DFS channels
From: Wojciech Dubowik @ 2011-01-11 14:40 UTC (permalink / raw)
To: linux-wireless; +Cc: lrodriguez, nbd, Johannes Berg
In-Reply-To: <5840411.32.1294754666078.JavaMail.wlan@CHBU500181>
Hello,
Basic DFS functionality requires that when we change to radar
enabled channels we need to wait and listen before we can send
beacons/frames -> Channel Availability Check (CAC).
There is a case when we can switch to it immediately if we have
been monitoring it off_channel for specific time. This is bit
more complicated and doesn't need to be implemented in the first
place because it's sort of functional optimization.
Anyway there is a need for mechanism to control when to enable
beacons if we switch to radar channel.
Pseudo-code-diff bellow is an example for ath9k where we could enable
beacons at once or fire a worker to re-enable it after CAC expires
if radar hasn't been detected. In theory we need only to disable
beacons because we shouldn't get any directed frames we could reply
to and stations anyway can't probe directly. In practice to be
sure it couldn't be probably done with making rx filters more
restrictive during CAC period. Maybe there are other ways as well.
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -285,8 +285,14 @@
ath9k_hw_set_interrupts(ah, ah->imask);
if (!(sc->sc_flags & (SC_OP_OFFCHANNEL))) {
- if (sc->sc_flags & SC_OP_BEACONS)
- ath_beacon_config(sc, NULL);
+
+ if (sc->sc_flags & SC_OP_BEACONS) {
+ if (channel->flags & IEEE80211_CHAN_RADAR
+ && !(channel->flags & IEEE80211_CHAN_NOL_FREE))
+ ieee80211_queue_delayed_work
+ (sc->hw, &sc->dfs_wait_cac_work, 0);
+ else
+ ath_beacon_config(sc, NULL);
+ }
+
ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work, 0);
ath_start_ani(common);
}
Problem with this solution is that every driver would need to do
their own timers and state machines to get this functionality which
is shared by all.
I don't know about other driver's structures but maybe a better way
would be to implement mac80211 command to disable/enable beacons and
set rx filters which every driver supporting DFS would have to implement.
Mac80211 would have then timer which would control when to enable
beacons. I guess Non Occupancy List (NOL) would be handled there as
well so all the DFS timers could be in the same place.
Any comments?
Br,
Wojtek
^ permalink raw reply
* Re: [RFC] mac80211: Allow AP to change channels for DFS support
From: Johannes Berg @ 2011-01-11 13:43 UTC (permalink / raw)
To: Wojciech Dubowik; +Cc: linux-wireless, lrodriguez, nbd
In-Reply-To: <2847292.30.1294752879394.JavaMail.wlan@CHBU500181>
On Tue, 2011-01-11 at 14:34 +0100, Wojciech Dubowik wrote:
> Hello,
>
> I have started studying DFS support possibilities in ath9k
> and I have noticed that at the moment AP is not allowed to
> change channels when it's using beacons.
>
> I have found that I can go around it by setting CHAN_MODE_UNDEFINED
> for this case. Not sure whether we need extra mode for it but
> to me this is a case when AP is neither fixed nor hopping.
>
> --- a/net/mac80211/chan.c
> +++ b/net/mac80211/chan.c
> @@ -34,8 +34,11 @@
> return CHAN_MODE_HOPPING;
> }
>
> - if (sdata->vif.type == NL80211_IFTYPE_AP &&
> - !sdata->u.ap.beacon)
> +
> + /* TODO: CHAN_MODE_FIXED shouldn't be set when
> + AP is on DFS channel. For now assume always
> + undefined */
> + if (sdata->vif.type == NL80211_IFTYPE_AP)
> continue;
>
> return CHAN_MODE_FIXED;
>
>
> It's also possible to check whether channel is of radar type
> and set mode undefined for this case. Question is whether it's
> needed at all.
>
> Any comments?
I don't think this is a good thing. Putting undefined here will inhibit
any other use of the channel since nothing can rely on it. However, in
the DFS case, everybody else will need to switch away as well, so ...
A similar issue exists with DFS clients too, btw, since they could also
hop channels which we don't currently really model.
johannes
^ permalink raw reply
* [RFC] mac80211: Allow AP to change channels for DFS support
From: Wojciech Dubowik @ 2011-01-11 13:34 UTC (permalink / raw)
To: linux-wireless; +Cc: lrodriguez, nbd, Johannes Berg
In-Reply-To: <5380482.20.1294752135253.JavaMail.wlan@CHBU500181>
Hello,
I have started studying DFS support possibilities in ath9k
and I have noticed that at the moment AP is not allowed to
change channels when it's using beacons.
I have found that I can go around it by setting CHAN_MODE_UNDEFINED
for this case. Not sure whether we need extra mode for it but
to me this is a case when AP is neither fixed nor hopping.
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -34,8 +34,11 @@
return CHAN_MODE_HOPPING;
}
- if (sdata->vif.type == NL80211_IFTYPE_AP &&
- !sdata->u.ap.beacon)
+
+ /* TODO: CHAN_MODE_FIXED shouldn't be set when
+ AP is on DFS channel. For now assume always
+ undefined */
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
continue;
return CHAN_MODE_FIXED;
It's also possible to check whether channel is of radar type
and set mode undefined for this case. Question is whether it's
needed at all.
Any comments?
Br,
Wojtek
^ permalink raw reply
* Re: [PATCH] hostap_cs: fix sleeping function called from invalid context
From: Stanislaw Gruszka @ 2011-01-11 13:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Dominik Brodowski, Tim Gardner, stable
In-Reply-To: <20110110115551.GA3227@redhat.com>
On Mon, Jan 10, 2011 at 12:56:03PM +0100, Stanislaw Gruszka wrote:
> pcmcia_request_irq() and pcmcia_enable_device() are intended
> to be called from process context (first function allocate memory
> with GFP_KERNEL, second take a mutex). We can not take spin lock
> and call them.
>
> It's safe to move spin lock after pcmcia_enable_device() as we
> still hold off IRQ until dev->base_addr is 0 and driver will
> not proceed with interrupts when is not ready.
>
> Patch resolves:
> https://bugzilla.redhat.com/show_bug.cgi?id=643758
>
> Reported-and-tested-by: rbugz@biobind.com
> Cc: stable@kernel.org # 2.6.34+
Patch is also needed for 2.6.32, I will post that version too.
Stanislaw
^ permalink raw reply
* Re: [PATCH] cfg80211: Extend channel to frequency mapping for 802.11j
From: Brian Prodoehl @ 2011-01-11 13:16 UTC (permalink / raw)
To: Johannes Berg
Cc: Bruno Randolf, linville, linux-wireless, Dan Williams,
libertas-dev, Ivo van Doorn, Gertjan van Wingerde, users
In-Reply-To: <1294748329.3611.8.camel@jlt3.sipsolutions.net>
On Tue, Jan 11, 2011 at 7:18 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2011-01-11 at 18:17 +0900, Bruno Randolf wrote:
>
>> > compat-wireless-2011-01-07.orig/drivers/net/wireless/libertas/cfg.c 2011-0
>> > 1-07 15:03:59.000000000 -0500
>> > +++
>> > compat-wireless-2011-01-07/drivers/net/wireless/libertas/cfg.c 2011-01-08
>> > 07:51:23.947290769 -0500
>> > @@ -607,7 +607,8 @@
>> > /* No channel, no luck */
>> > if (chan_no != -1) {
>> > struct wiphy *wiphy = priv->wdev->wiphy;
>> > - int freq = ieee80211_channel_to_frequency(chan_no);
>> > + int freq = ieee80211_channel_to_frequency(chan_no,
>> > + chan_no <= 14 ? IEEE80211_BAND_2GHZ :
>> IEEE80211_BAND_5GHZ);
>>
>> The whole point of having the band argument is to avoid this. We now have
>> overlapping channel numbers: channel 8 and 12 are defined in 5GHz as well as
>> in 2.4GHz (that is for 20MHz channel width, there are more for 10 and 5MHz
>> width, but we don't support that yet). The band has to come from the hardware
>> or driver configuration.
>
> I don't think libertas (or orinoco) support the frequencies that
> overlap, and they use the channel number in HW config, so it should be
> fine.
>
> johannes
That's what it looked like to me, as well, for libertas. For rt2x00,
with it's dependence on binary firmwares from Ralink, extending the
channel set seems very far from trivial. Ralink advertises compliance
with 802.11j (http://web.ralinktech.com/ralink/data/RT2800.pdf). A
year and a half ago I asked them directly what that compliance means
(4.9GHz channels? 10MHz channel width? misprint?) and didn't get a
response. A way to pull the band for rt2x00 didn't pop out at me, but
if the maintainers have suggestions, that'll be great. Also, if they
have some idea what the level of 802.11j compliance is, I'd love to
know!
-Brian
^ permalink raw reply
* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: jpo234 @ 2011-01-11 13:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1294750836.3611.25.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@...> writes:
> > see http://www.dinkumware.com/manuals/?manual=compleat&page=inttypes.html#PRIu64
>
> Oi, that's complicated. Patch welcome I guess.
Not really:
#include <inttypes.h>
#include <stdio.h>
int
main()
{
printf ("unsigned long long: %llu\n", 1llu);
printf ("uint64_t: %"PRIu64"\n", (uint64_t)1);
return 0;
}
^ permalink raw reply
* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: jpo234 @ 2011-01-11 13:00 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <loom.20110111T135315-64@post.gmane.org>
jpo234 <pommnitz@...> writes:
> The C99 way would be to use the PRIu64 macro (see stdint.h).
Sorry, make this <inttypes.h>.
^ permalink raw reply
* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: Johannes Berg @ 2011-01-11 13:00 UTC (permalink / raw)
To: jpo234; +Cc: linux-wireless
In-Reply-To: <loom.20110111T135315-64@post.gmane.org>
On Tue, 2011-01-11 at 12:57 +0000, jpo234 wrote:
> Johannes Berg <johannes@...> writes:
> > because uint64_t isn't guaranteed to be unsigned long long (in fact, it
> > is unsigned long on many machines). Please look at the commit and check.
>
> In the commit you did a cast to unsigned long long. While this works, it's
> depends on gcc-ism, e.g. long long support. The C99 way would be to use the
> PRIu64 macro (see stdint.h).
> see http://www.dinkumware.com/manuals/?manual=compleat&page=inttypes.html#PRIu64
Oi, that's complicated. Patch welcome I guess.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox