* [PATCH] ath6kl: fix null skb dereference in ath6kl_rx()
From: Kalle Valo @ 2011-10-06 11:32 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
smatch found that skb might be null in some cases in ath6kl_rx():
ath6kl/txrx.c +1252 ath6kl_rx(222) error: potential null derefence 'skb'.
This will happen when ath6kl is in AP mode and two clients send traffic
to each other.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/txrx.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/txrx.c b/drivers/net/wireless/ath/ath6kl/txrx.c
index bcf7b01..a9dff01 100644
--- a/drivers/net/wireless/ath/ath6kl/txrx.c
+++ b/drivers/net/wireless/ath/ath6kl/txrx.c
@@ -1247,6 +1247,11 @@ void ath6kl_rx(struct htc_target *target, struct htc_packet *packet)
}
if (skb1)
ath6kl_data_tx(skb1, ar->net_dev);
+
+ if (skb == NULL) {
+ /* nothing to deliver up the stack */
+ return;
+ }
}
datap = (struct ethhdr *) skb->data;
^ permalink raw reply related
* Re: ath6kl: pass only unicast frames for aggregation
From: Kalle Valo @ 2011-10-06 11:27 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Dan Carpenter, linux-wireless
In-Reply-To: <20111005115738.GA7368@jouni.qca.qualcomm.com>
On 10/05/2011 02:57 PM, Jouni Malinen wrote:
> On Wed, Oct 05, 2011 at 01:09:53PM +0300, Kalle Valo wrote:
>> Good catch, thanks! I should run smatch more, it's a really nice tool.
>
> This could have actually been found even before
> 5694f962964c5162f6b49ddb5d517180bd7d1d98 with more thorough static
> analysis since an A-MSDU sent to ath6kl AP would have hit the NULL
> pointer dereference in aggr_slice_amsdu().. Anyway, this new commit does
> indeed seem to make this much more likely to hit the issue (any data
> frame between two associated STAs).
Good point, I'll mention in the patch how severe this actually is.
>> I think a fix like this would be appropriate. Jouni, what do you think?
>
>> --- a/drivers/net/wireless/ath/ath6kl/txrx.c
>> +++ b/drivers/net/wireless/ath/ath6kl/txrx.c
>> @@ -1247,6 +1247,10 @@ void ath6kl_rx(struct htc_target *target, struct
>> htc_packet *packet)
>> }
>> if (skb1)
>> ath6kl_data_tx(skb1, ar->net_dev);
>> +
>> + if (skb == NULL)
>> + /* nothing to deliver up the stack */
>> + return;
>> }
>>
>> datap = (struct ethhdr *) skb->data;
>
>
> This looks like the correct behavior here. However, I would recommend
> using braces around any multi-line conditional statement even if it
> really is a comment and a single statement that would not, in theory,
> require this in C language. Leaving those out here seems to be just
> asking for problems should someone add something before the "return;"
> line and not notice to add braces at that point. The same comment would
> actually apply for the commit 5694f962964c5162f6b49ddb5d517180bd7d1d98,
> too. If you want to avoid the extra line an braces, moving the comment
> to the end of the return line would work for me.
I have used to not using braces even there's a comment like here. But
you have a point and I'll change my style.
Thanks for checking this.
Kalle
^ permalink raw reply
* Re: [PATCH] ath6kl:Fix execution address of OTP AR6003 HW2.0
From: Sangwook Lee @ 2011-10-06 11:03 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, patches
In-Reply-To: <4E8D8766.1030809@qca.qualcomm.com>
Hi Kalle
On 6 October 2011 11:48, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> On 10/05/2011 05:14 PM, Sangwook Lee wrote:
>> Fix OTP execution address for AR6003 HW2.0
>>
>> ath6kl: writing otp to 0x543180 (3689 B)
>> ath6kl: bmi LZ stream start: addr: 0x543180)
>> ath6kl: bmi send LZ data: len: 3688)
>> ath6kl: bmi send LZ data: len: 4)
>> ath6kl: bmi LZ stream start: addr: 0x0)
>> ath6kl: bmi read memory: device: addr: 0x54061c, len: 4
>> ath6kl: app_start_override_addr 0x0
>> ath6kl: executing OTP at 0x0
>> ath6kl: bmi execute: addr: 0x0, param: 0)
>> ath6kl: bmi_recv_buf FIFO empty
>> ath6kl: Unable to read from the device: -22
>
> Ah, now I understand. So this patch broke it:
>
> commit 639d0b8996aa5913402b846932d57a51a23a40c9
> Author: Kalle Valo <kvalo@qca.qualcomm.com>
> Date: Mon Sep 12 12:48:09 2011 +0300
>
> ath6kl: read firmware start address from hardware
>
> It's actually possible to read the firmware start address from hardware,
> that way there's no need to hardcode the address in hardware.
>
>
> So the firmware start address detections doesn't actually work with hw
> 2.0, too bad.
>
> Actually I would like to fix this a bit differently, can you please try
> the attached patch? Compile tested only. If it works, please send me a
> Tested-by tag.
Yes I will do it.
>
> BTW, do you still need to enable debug logs to get hw2.0 working properly?
Yes, I still have to use debug but want to fix it now, so please let me debug
as based on your last advice and then report to you.
>
> Kalle
>
Sangwook
^ permalink raw reply
* Re: [PATCH] ath6kl:Fix execution address of OTP AR6003 HW2.0
From: Kalle Valo @ 2011-10-06 10:48 UTC (permalink / raw)
To: Sangwook Lee; +Cc: linux-wireless, patches
In-Reply-To: <1317824077-13476-1-git-send-email-sangwook.lee@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On 10/05/2011 05:14 PM, Sangwook Lee wrote:
> Fix OTP execution address for AR6003 HW2.0
>
> ath6kl: writing otp to 0x543180 (3689 B)
> ath6kl: bmi LZ stream start: addr: 0x543180)
> ath6kl: bmi send LZ data: len: 3688)
> ath6kl: bmi send LZ data: len: 4)
> ath6kl: bmi LZ stream start: addr: 0x0)
> ath6kl: bmi read memory: device: addr: 0x54061c, len: 4
> ath6kl: app_start_override_addr 0x0
> ath6kl: executing OTP at 0x0
> ath6kl: bmi execute: addr: 0x0, param: 0)
> ath6kl: bmi_recv_buf FIFO empty
> ath6kl: Unable to read from the device: -22
Ah, now I understand. So this patch broke it:
commit 639d0b8996aa5913402b846932d57a51a23a40c9
Author: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Mon Sep 12 12:48:09 2011 +0300
ath6kl: read firmware start address from hardware
It's actually possible to read the firmware start address from hardware,
that way there's no need to hardcode the address in hardware.
So the firmware start address detections doesn't actually work with hw
2.0, too bad.
Actually I would like to fix this a bit differently, can you please try
the attached patch? Compile tested only. If it works, please send me a
Tested-by tag.
BTW, do you still need to enable debug logs to get hw2.0 working properly?
Kalle
[-- Attachment #2: 0001-ath6kl-fix-firmware-start-address-for-ar6003-hw2.0.patch --]
[-- Type: text/x-patch, Size: 2891 bytes --]
>From e982bc13435b3f5dca76c77d472dcd2cfcba2b66 Mon Sep 17 00:00:00 2001
From: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Thu, 6 Oct 2011 13:26:58 +0300
Subject: [PATCH] ath6kl: fix firmware start address for ar6003 hw2.0
Sangwook found out that commit 639d0b89 ("ath6kl: read firmware start
address from hardware") broke firmware boot on ar6003 hw2.0 as it seems
it's not posible to automatically query the address from hardware. So
we need to hardcode the address for hw2.0.
Reported-by: Sangwook Lee <sangwook.lee@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/init.c | 34 ++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 8466f3d..d52c925 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1182,6 +1182,7 @@ static int ath6kl_upload_board_file(struct ath6kl *ar)
static int ath6kl_upload_otp(struct ath6kl *ar)
{
u32 address, param;
+ bool from_hw = false;
int ret;
if (WARN_ON(ar->fw_otp == NULL))
@@ -1199,24 +1200,29 @@ static int ath6kl_upload_otp(struct ath6kl *ar)
return ret;
}
- /* read firmware start address */
- ret = ath6kl_bmi_read(ar,
- ath6kl_get_hi_item_addr(ar,
- HI_ITEM(hi_app_start)),
- (u8 *) &address, sizeof(address));
+ if (ar->hw.app_start_override_addr == 0) {
+ /* read firmware start address */
+ ret = ath6kl_bmi_read(ar,
+ ath6kl_get_hi_item_addr(ar,
+ HI_ITEM(hi_app_start)),
+ (u8 *) &address, sizeof(address));
- if (ret) {
- ath6kl_err("Failed to read hi_app_start: %d\n", ret);
- return ret;
- }
+ if (ret) {
+ ath6kl_err("Failed to read hi_app_start: %d\n", ret);
+ return ret;
+ }
- ar->hw.app_start_override_addr = address;
+ ar->hw.app_start_override_addr = address;
+ from_hw = true;
+ }
- ath6kl_dbg(ATH6KL_DBG_BOOT, "app_start_override_addr 0x%x\n",
+ ath6kl_dbg(ATH6KL_DBG_BOOT, "app_start_override_addr%s 0x%x\n",
+ from_hw ? " (from hw)" : "",
ar->hw.app_start_override_addr);
/* execute the OTP code */
- ath6kl_dbg(ATH6KL_DBG_BOOT, "executing OTP at 0x%x\n", address);
+ ath6kl_dbg(ATH6KL_DBG_BOOT, "executing OTP at 0x%x\n",
+ ar->hw.app_start_override_addr);
param = 0;
ath6kl_bmi_execute(ar, address, ¶m);
@@ -1420,6 +1426,10 @@ static int ath6kl_init_hw_params(struct ath6kl *ar)
ar->hw.app_load_addr = AR6003_REV2_APP_LOAD_ADDRESS;
ar->hw.board_ext_data_addr = AR6003_REV2_BOARD_EXT_DATA_ADDRESS;
ar->hw.reserved_ram_size = AR6003_REV2_RAM_RESERVE_SIZE;
+
+ /* hw2.0 needs override address hardcoded */
+ ar->hw.app_start_override_addr = 0x944C00;
+
break;
case AR6003_REV3_VERSION:
ar->hw.dataset_patch_addr = AR6003_REV3_DATASET_PATCH_ADDRESS;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 00/15] staging: brcm80211: cleanup fullmac structs and softmac srom lookup
From: Arend van Spriel @ 2011-10-06 9:56 UTC (permalink / raw)
To: Greg KH
Cc: gregkh@suse.de, devel@linuxdriverproject.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20111005204705.GA2467@kroah.com>
On 10/05/2011 10:47 PM, Greg KH wrote:
> On Wed, Oct 05, 2011 at 03:19:59PM +0200, Arend van Spriel wrote:
>> This series addresses more community feedback items received on mainline
>> patch (v2) posted August 25, 2011. The driver structures in brcmfmac could
>> do with some tidying and in the brcmsmac variables loaded from srom were
>> accessed by string identifiers. This has been replaced by enumerated
>> identifiers and the entries are stored in kernel standard linked list.
>>
>> This series applies to staging-next and depends on the patch series posted
>> on Oct 4, 2011 (see Message-ID below).
>>
>> Message-ID:<1317763152-17607-1-git-send-email-arend@broadcom.com>
> All applied, thanks.
>
> greg k-h
Thanks, Greg
That was a speedy integration bringing the staging tree in sync with
what went in the mainline patch.
Gr. AvS
^ permalink raw reply
* [PATCH] compat: make driver-select only select complete lines
From: Johannes Berg @ 2011-10-06 9:15 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Otherwise we end up enabling CONFIG_FOOBAR if
only CONFIG_FOO is requested.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -88,7 +88,7 @@ function disable_makefile
function select_driver
{
backup_file $DRIVERS_MAKEFILE
- perl -i -ne 'print if /'$1'/ ' $DRIVERS_MAKEFILE
+ perl -i -ne 'print if /'$1'\)/ ' $DRIVERS_MAKEFILE
}
function select_drivers
^ permalink raw reply
* Re: [PATCH 1/6] ath6kl: remove unused parameters from struct wmi
From: Kalle Valo @ 2011-10-06 9:01 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20111005092305.1095.713.stgit@localhost6.localdomain6>
On 10/05/2011 12:23 PM, Kalle Valo wrote:
> There's no use for these, at least right now, so better to remove them.
> If some of them are ever needed, we can always add them back.
All six applied.
Kalle
^ permalink raw reply
* Re: [PATCH] ath6kl: make sure WLAN power save is enabled during suspend
From: Kalle Valo @ 2011-10-06 8:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Ng, Chilam
In-Reply-To: <20111005071252.19388.38625.stgit@localhost6.localdomain6>
On 10/05/2011 10:12 AM, Kalle Valo wrote:
> From: Chilam Ng <chilamng@qca.qualcomm.com>
>
> Power save is enabled during ath6kl init. But when user space disables power
> save, the system will go into suspend with power save disabled. The ath6kl
> driver will now explicitly enable power save prior to entering suspend and
> restore its previous setting upon resume
Applied.
Kalle
^ permalink raw reply
* Re: [PATCH V2 1/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_process_packets()
From: Kalle Valo @ 2011-10-06 8:46 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1317643087-16104-1-git-send-email-vthiagar@qca.qualcomm.com>
On 10/03/2011 02:58 PM, Vasanthakumar Thiagarajan wrote:
> Packet is not reclaimed when ath6kl_htc_rx_process_hdr() fails.
> Fix this by deferring the packet deletion from comp_pktq till
> ath6kl_htc_rx_process_hdr() returns success. This bug is found
> in code review, impact is not easily visible as the leak happens
> only in failure cases.
Thanks, all four applied.
Kalle
^ permalink raw reply
* [PATCH] compat: fix warning in alloc_netdev_mqs
From: Johannes Berg @ 2011-10-06 8:45 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Depending on the arguments to alloc_netdev_mqs(),
it may give a warning due to the use of max().
Fix the warning with max_t().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/linux/compat-2.6.38.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/compat-2.6.38.h b/include/linux/compat-2.6.38.h
index 1f9ab52..06bbd9d 100644
--- a/include/linux/compat-2.6.38.h
+++ b/include/linux/compat-2.6.38.h
@@ -73,7 +73,8 @@ static inline int skb_checksum_start_offset(const struct sk_buff *skb)
/* include/linux/netdevice.h */
#define alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs) \
- alloc_netdev_mq(sizeof_priv, name, setup, max(txqs, rxqs))
+ alloc_netdev_mq(sizeof_priv, name, setup, \
+ max_t(unsigned int, txqs, rxqs))
#define ETH_P_LINK_CTL 0x886c /* HPNA, wlan link local tunnel */
--
1.7.6.3
^ permalink raw reply related
* Re: hostapd with Ralink3060, SSID not visible to STA
From: Helmut Schaa @ 2011-10-06 7:12 UTC (permalink / raw)
To: Manish Verma; +Cc: linux-wireless
In-Reply-To: <loom.20111005T122216-407@post.gmane.org>
On Wed, Oct 5, 2011 at 12:47 PM, Manish Verma
<mail.manishverma@gmail.com> wrote:
> I'm not able to see the SSID configured on my x86 PC using hostapd-0.7.3 with a
> DWA-525 (Dlink N-150) wifi adapter.
> This card has a Ralink's 3060 chipset that is using rt2800pci drivers.
>
> Although hostapd is able to configure the card in AP mode but its SSID is not
> visible to other STAs to connect.
>
>
> I'm using FC15 shipped kernel 2.6.28.6-26.rc1.fc15.i686
2.6.28 is quite old, you could try to use a newer driver version
by using compat-wireless [1].
Helmut
[1] http://linuxwireless.org/en/users/Download
^ permalink raw reply
* hostapd with Ralink3060, SSID not visible to STA
From: Manish Verma @ 2011-10-05 10:47 UTC (permalink / raw)
To: linux-wireless
Hello,
I'm not able to see the SSID configured on my x86 PC using hostapd-0.7.3 with a
DWA-525 (Dlink N-150) wifi adapter.
This card has a Ralink's 3060 chipset that is using rt2800pci drivers.
Although hostapd is able to configure the card in AP mode but its SSID is not
visible to other STAs to connect.
I'm using FC15 shipped kernel 2.6.28.6-26.rc1.fc15.i686
Has someone got this configuration working? Any pointers to the solution are
welcome.
Best regards,
Manish
Logs:-
#ifconfig wlan0
shows that some packets are transmitted but none received. (byte count never
increases further)
{{{
[root@localhost ~]# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 14:D6:4D:4B:C9:A6
inet6 addr: fe80::16d6:4dff:fe4b:c9a6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:2880 (2.8 KiB)
}}}
hostapd console messages are as follows:
{{{
[root@localhost hostapd]# ./hostapd -ddd /etc/hostapd/hostapd.conf
Configuration file: /etc/hostapd/hostapd.conf
ctrl_interface_group=10 (from group name 'wheel')
nl80211: Add own interface ifindex 3
nl80211: New interface mon.wlan0 created: ifindex=7
nl80211: Add own interface ifindex 7
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
nl80211: Added 802.11b mode based on 802.11g information
Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=12 freq=2467 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=13 freq=2472 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=12 freq=2467 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=13 freq=2472 MHz max_tx_power=20 dBm
RATE[0] rate=10 flags=0x1
RATE[1] rate=20 flags=0x1
RATE[2] rate=55 flags=0x1
RATE[3] rate=110 flags=0x1
RATE[4] rate=60 flags=0x0
RATE[5] rate=90 flags=0x0
RATE[6] rate=120 flags=0x0
RATE[7] rate=180 flags=0x0
RATE[8] rate=240 flags=0x0
RATE[9] rate=360 flags=0x0
RATE[10] rate=480 flags=0x0
RATE[11] rate=540 flags=0x0
Completing interface initialization
Mode: IEEE 802.11g Channel: 11 Frequency: 2462 MHz
Flushing old station entries
Deauthenticate all stations
wpa_driver_nl80211_set_key: ifindex=3 alg=0 addr=(nil) key_idx=0 set_tx=1
seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 alg=0 addr=(nil) key_idx=1 set_tx=0
seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 alg=0 addr=(nil) key_idx=2 set_tx=0
seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 alg=0 addr=(nil) key_idx=3 set_tx=0
seq_len=0 key_len=0
Using interface wlan0 with hwaddr 14:d6:4d:4b:c9:a6 and ssid 'Test'
nl80211: Set beacon (beacon_set=0)
wlan0: Setup of interface done.
RTM_NEWLINK: operstate=0 ifi_flags=0x1002 ()
RTM_NEWLINK, IFLA_IFNAME: Interface 'mon.wlan0' added
Unknown event 5
RTM_NEWLINK: operstate=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'mon.wlan0' added
Unknown event 5
RTM_NEWLINK: operstate=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
Unknown event 5
}}}
hostapd.conf
{{{
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
# Some usable default settings...
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
# Uncomment these for base WPA & WPA2 support with a pre-shared key
#wpa=2
#wpa_key_mgmt=WPA-PSK
#wpa_pairwise=TKIP
#rsn_pairwise=CCMP
# DO NOT FORGET TO SET A WPA PASSPHRASE!!
#wpa_passphrase=YourPassPhrase
# Most modern wireless drivers in the kernel need driver=nl80211
driver=nl80211
# Customize these for your local configuration...
interface=wlan0
hw_mode=g
channel=11
ssid=Test
}}}
^ permalink raw reply
* Re: 答复: 答复: 答复: 3.1-rc6+ rtl8192se issue
From: Larry Finger @ 2011-10-06 2:37 UTC (permalink / raw)
To: Borislav Petkov; +Cc: 李朝明, linux-wireless, 'LKML'
In-Reply-To: <20111005151533.GA18592@gere.osrc.amd.com>
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
On 10/05/2011 10:15 AM, Borislav Petkov wrote:
> Ok, I can cautiosly say now that after a couple days of running the
> Realtek version that the box runs just fine, no hiccups whatsoever.
>
> Larry, you said in an earlier mail that you've gone through the
> rtl8192se changes and weren't optimistic with the attached diff you sent
> me. What about the rtlwifi changes, is there something in Realtek's
> version which is missing upstream that would cause the sluggishness?
I have been going though the differences between the 06/20/2011 and 08/16/2011
drivers and making those changes to the kernel drivers. Could you please apply
the 5 attached patches to the wireless-testing tree and see if your sluggishness
is fixed?
Thanks,
Larry
[-- Attachment #2: 0001-rtlwifi-Change-PCI-drivers-to-use-the-new-PM-framewo.patch --]
[-- Type: text/x-patch, Size: 5896 bytes --]
>From 7888163e5f25feb9825349e346759f7c884dd074 Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 5 Oct 2011 10:50:24 -0500
Subject: [PATCH 1/5] rtlwifi: Change PCI drivers to use the new PM framework
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/pci.c | 19 ++++---------------
drivers/net/wireless/rtlwifi/pci.h | 4 ++--
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 16 ++++++++++------
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 16 ++++++++++------
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 16 ++++++++++------
5 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 9983fa1..5380f3b 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -1993,36 +1993,25 @@ call rtl_mac_stop() from the mac80211
suspend function first, So there is
no need to call hw_disable here.
****************************************/
-int rtl_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+int rtl_pci_suspend(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtlpriv->cfg->ops->hw_suspend(hw);
rtl_deinit_rfkill(hw);
- pci_save_state(pdev);
- pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
return 0;
}
EXPORT_SYMBOL(rtl_pci_suspend);
-int rtl_pci_resume(struct pci_dev *pdev)
+int rtl_pci_resume(struct device *dev)
{
- int ret;
+ struct pci_dev *pdev = to_pci_dev(dev);
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct rtl_priv *rtlpriv = rtl_priv(hw);
- pci_set_power_state(pdev, PCI_D0);
- ret = pci_enable_device(pdev);
- if (ret) {
- RT_ASSERT(false, ("ERR: <======\n"));
- return ret;
- }
-
- pci_restore_state(pdev);
-
rtlpriv->cfg->ops->hw_resume(hw);
rtl_init_rfkill(hw);
return 0;
diff --git a/drivers/net/wireless/rtlwifi/pci.h b/drivers/net/wireless/rtlwifi/pci.h
index a24e505..ebe0b42 100644
--- a/drivers/net/wireless/rtlwifi/pci.h
+++ b/drivers/net/wireless/rtlwifi/pci.h
@@ -237,8 +237,8 @@ extern struct rtl_intf_ops rtl_pci_ops;
int __devinit rtl_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id);
void rtl_pci_disconnect(struct pci_dev *pdev);
-int rtl_pci_suspend(struct pci_dev *pdev, pm_message_t state);
-int rtl_pci_resume(struct pci_dev *pdev);
+int rtl_pci_suspend(struct device *dev);
+int rtl_pci_resume(struct device *dev);
static inline u8 pci_read8_sync(struct rtl_priv *rtlpriv, u32 addr)
{
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
index b7ecb9e..07a75d3 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -365,17 +365,21 @@ MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+static const struct dev_pm_ops rtlwifi_pm_ops = {
+ .suspend = rtl_pci_suspend,
+ .resume = rtl_pci_resume,
+ .freeze = rtl_pci_suspend,
+ .thaw = rtl_pci_resume,
+ .poweroff = rtl_pci_suspend,
+ .restore = rtl_pci_resume,
+};
+
static struct pci_driver rtl92ce_driver = {
.name = KBUILD_MODNAME,
.id_table = rtl92ce_pci_ids,
.probe = rtl_pci_probe,
.remove = rtl_pci_disconnect,
-
-#ifdef CONFIG_PM
- .suspend = rtl_pci_suspend,
- .resume = rtl_pci_resume,
-#endif
-
+ .driver.pm = &rtlwifi_pm_ops,
};
static int __init rtl92ce_module_init(void)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/sw.c b/drivers/net/wireless/rtlwifi/rtl8192de/sw.c
index c681597..12042d8 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/sw.c
@@ -385,17 +385,21 @@ MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+static const struct dev_pm_ops rtlwifi_pm_ops = {
+ .suspend = rtl_pci_suspend,
+ .resume = rtl_pci_resume,
+ .freeze = rtl_pci_suspend,
+ .thaw = rtl_pci_resume,
+ .poweroff = rtl_pci_suspend,
+ .restore = rtl_pci_resume,
+};
+
static struct pci_driver rtl92de_driver = {
.name = KBUILD_MODNAME,
.id_table = rtl92de_pci_ids,
.probe = rtl_pci_probe,
.remove = rtl_pci_disconnect,
-
-#ifdef CONFIG_PM
- .suspend = rtl_pci_suspend,
- .resume = rtl_pci_resume,
-#endif
-
+ .driver.pm = &rtlwifi_pm_ops,
};
/* add global spin lock to solve the problem that
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
index 24bd331..80facb5 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -396,17 +396,21 @@ MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+static const struct dev_pm_ops rtlwifi_pm_ops = {
+ .suspend = rtl_pci_suspend,
+ .resume = rtl_pci_resume,
+ .freeze = rtl_pci_suspend,
+ .thaw = rtl_pci_resume,
+ .poweroff = rtl_pci_suspend,
+ .restore = rtl_pci_resume,
+};
+
static struct pci_driver rtl92se_driver = {
.name = KBUILD_MODNAME,
.id_table = rtl92se_pci_ids,
.probe = rtl_pci_probe,
.remove = rtl_pci_disconnect,
-
-#ifdef CONFIG_PM
- .suspend = rtl_pci_suspend,
- .resume = rtl_pci_resume,
-#endif
-
+ .driver.pm = &rtlwifi_pm_ops,
};
static int __init rtl92se_module_init(void)
--
1.7.6.4
[-- Attachment #3: 0002-rtlwifi-Update-to-new-Realtek-version-Part-I.patch --]
[-- Type: text/x-patch, Size: 1944 bytes --]
>From 18157ae7138110bf72540fac4c1fa16e09c81774 Mon Sep 17 00:00:00 2001
From: Chaoming Li <chaoming_li@realsil.com.cn>
Date: Wed, 5 Oct 2011 10:54:06 -0500
Subject: [PATCH 2/5] rtlwifi: Update to new Realtek version - Part I
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org
This patch incorporate the differences between the 06/20/2011 and
08/16/2011 Realtek releases of the rtlwifi driver.
The changes include:
1. Handling of IEEE80211_HW_CONNECTION_MONITOR.
2. Fix typo to get proper response to nullfunc frames.
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/base.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index eafe980..a2704fb 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -311,6 +311,8 @@ static void _rtl_init_mac80211(struct ieee80211_hw *hw)
IEEE80211_HW_RX_INCLUDES_FCS |
IEEE80211_HW_BEACON_FILTER |
IEEE80211_HW_AMPDU_AGGREGATION |
+ IEEE80211_HW_CONNECTION_MONITOR |
+ /* IEEE80211_HW_SUPPORTS_CQM_RSSI | */
IEEE80211_HW_REPORTS_TX_ACK_STATUS | 0;
/* swlps or hwlps has been set in diff chip in init_sw_vars */
@@ -850,7 +852,7 @@ void rtl_get_tcb_desc(struct ieee80211_hw *hw,
*So tcb_desc->hw_rate is just used for
*special data and mgt frames
*/
- if (info->control.rates[0].idx == 0 &&
+ if (info->control.rates[0].idx == 0 ||
ieee80211_is_nullfunc(fc)) {
tcb_desc->use_driver_rate = true;
tcb_desc->ratr_index = RATR_INX_WIRELESS_MC;
@@ -1138,7 +1140,7 @@ void rtl_watchdog_wq_callback(void *data)
}
/*
- *<3> to check if traffic busy, if
+ *<2> to check if traffic busy, if
* busytraffic we don't change channel
*/
if (mac->link_state >= MAC80211_LINKED) {
--
1.7.6.4
[-- Attachment #4: 0003-rtlwifi-rtl8192ce-Add-new-chip-revisions.patch --]
[-- Type: text/x-patch, Size: 4354 bytes --]
>From a3c6b35d2d81c99707b1c36fc3b4d84eb461ff7f Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 5 Oct 2011 11:05:36 -0500
Subject: [PATCH 3/5] rtlwifi: rtl8192ce: Add new chip revisions
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org
From: Chaoming Li <chaoming_li@realsil.com.cn>
This patch incorporate the differences between the 06/20/2011 and
08/16/2011 Realtek releases of the rtlwifi driver.
The changes include:
1. Adding new chip revisions including new firmware.
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 14 ++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 14 ++++++++++++--
drivers/net/wireless/rtlwifi/rtl8192cu/def.h | 4 ----
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
index 11f4319..a816459 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
@@ -142,8 +142,22 @@ enum version_8192c {
VERSION_UNKNOWN = 0x88,
};
+#define CUT_VERSION_MASK (BIT(6)|BIT(7))
+#define CHIP_VENDOR_UMC BIT(5)
+#define CHIP_VENDOR_UMC_B_CUT BIT(6) /* Chip version for ECO */
+#define IS_VENDOR_UMC_A_CUT(version) ((IS_CHIP_VENDOR_UMC(version)) ? \
+ ((GET_CVID_CUT_VERSION(version)) ? false : true) : false)
#define IS_CHIP_VER_B(version) ((version & CHIP_VER_B) ? true : false)
+#define IS_VENDOR_UMC_A_CUT(version) ((IS_CHIP_VENDOR_UMC(version)) ? \
+ ((GET_CVID_CUT_VERSION(version)) ? false : true) : false)
#define IS_92C_SERIAL(version) ((version & CHIP_92C_BITMASK) ? true : false)
+#define IS_CHIP_VENDOR_UMC(version) \
+ ((version & CHIP_VENDOR_UMC) ? true : false)
+#define GET_CVID_CUT_VERSION(version) ((version) & CUT_VERSION_MASK)
+#define IS_81xxC_VENDOR_UMC_B_CUT(version) \
+ ((IS_CHIP_VENDOR_UMC(version)) ? \
+ ((GET_CVID_CUT_VERSION(version) == CHIP_VENDOR_UMC_B_CUT) ? \
+ true : false) : false)
enum rtl819x_loopback_e {
RTL819X_NO_LOOPBACK = 0,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
index 07a75d3..f515bf7 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -92,6 +92,8 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
const struct firmware *firmware;
+ struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ char *fw_name = NULL;
rtl8192ce_bt_reg_init(hw);
@@ -159,8 +161,14 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
}
/* request fw */
- err = request_firmware(&firmware, rtlpriv->cfg->fw_name,
- rtlpriv->io.dev);
+ if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
+ !IS_92C_SERIAL(rtlhal->version))
+ fw_name = "rtlwifi/rtl8192cfwU.bin";
+ else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
+ fw_name = "rtlwifi/rtl8192cfwU_B.bin";
+ else
+ fw_name = rtlpriv->cfg->fw_name;
+ err = request_firmware(&firmware, fw_name, rtlpriv->io.dev);
if (err) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
("Failed to request firmware!\n"));
@@ -355,6 +363,8 @@ MODULE_AUTHOR("Larry Finger <Larry.Finger@lwfinger.net>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 8192C/8188C 802.11n PCI wireless");
MODULE_FIRMWARE("rtlwifi/rtl8192cfw.bin");
+MODULE_FIRMWARE("rtlwifi/rtl8192cfwU.bin");
+MODULE_FIRMWARE("rtlwifi/rtl8192cfwU_B.bin");
module_param_named(swenc, rtl92ce_mod_params.sw_crypto, bool, 0444);
module_param_named(ips, rtl92ce_mod_params.inactiveps, bool, 0444);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/def.h b/drivers/net/wireless/rtlwifi/rtl8192cu/def.h
index c54940e..d097efb 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/def.h
@@ -50,10 +50,6 @@
#define IS_VENDOR_UMC(version) \
(((version) & CHIP_VENDOR_UMC) ? true : false)
-#define IS_VENDOR_UMC_A_CUT(version) \
- (((version) & CHIP_VENDOR_UMC) ? (((version) & (BIT(6) | BIT(7))) ? \
- false : true) : false)
-
#define IS_VENDOR_8723_A_CUT(version) \
(((version) & CHIP_VENDOR_UMC) ? (((version) & (BIT(6))) ? \
false : true) : false)
--
1.7.6.4
[-- Attachment #5: 0004-rtlwifi-rtl8192se-Updates-from-latest-Realtek-driver.patch --]
[-- Type: text/x-patch, Size: 9879 bytes --]
>From 958afb7351d9ff1b48b4f53796db1abd78b4b350 Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 5 Oct 2011 11:11:04 -0500
Subject: [PATCH 4/5] rtlwifi: rtl8192se: Updates from latest Realtek driver
version - Part II
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org
From: Chaoming Li <chaoming_li@realsil.com.cn>
This patch incorporate the differences between the 06/20/2011 and
08/16/2011 Realtek releases of the rtl8192se driver.
The changes include:
1. Fixing some typos in register usage.
2. A change in the handling of decryption status for 802.11w packets.
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 22 +++++-----
drivers/net/wireless/rtlwifi/rtl8192se/reg.h | 1 +
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 53 +++++++++++++++----------
drivers/net/wireless/rtlwifi/wifi.h | 1 +
5 files changed, 46 insertions(+), 32 deletions(-)
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
@@ -1382,7 +1382,7 @@ static void _rtl92se_power_domain_init(s
rtl_write_byte(rtlpriv, LDOA15_CTRL, 0x34);
/* Reset MAC-IO and CPU and Core Digital BIT10/11/15 */
- tmpu1b = rtl_read_byte(rtlpriv, SYS_FUNC_EN + 1);
+ tmpu1b = rtl_read_byte(rtlpriv, REG_SYS_FUNC_EN + 1);
/* If IPS we need to turn LED on. So we not
* not disable BIT 3/7 of reg3. */
@@ -1391,7 +1391,7 @@ static void _rtl92se_power_domain_init(s
else
tmpu1b &= 0x73;
- rtl_write_byte(rtlpriv, SYS_FUNC_EN + 1, tmpu1b);
+ rtl_write_byte(rtlpriv, REG_SYS_FUNC_EN + 1, tmpu1b);
/* wait for BIT 10/11/15 to pull high automatically!! */
mdelay(1);
@@ -1428,15 +1428,15 @@ static void _rtl92se_power_domain_init(s
rtl_write_byte(rtlpriv, LDOA15_CTRL, (tmpu1b | BIT(0)));
/* Set Digital Vdd to Retention isolation Path. */
- tmpu2b = rtl_read_word(rtlpriv, SYS_ISO_CTRL);
- rtl_write_word(rtlpriv, SYS_ISO_CTRL, (tmpu2b | BIT(11)));
+ tmpu2b = rtl_read_word(rtlpriv, REG_SYS_ISO_CTRL);
+ rtl_write_word(rtlpriv, REG_SYS_ISO_CTRL, (tmpu2b | BIT(11)));
/* For warm reboot NIC disappera bug. */
- tmpu2b = rtl_read_word(rtlpriv, SYS_FUNC_EN);
- rtl_write_word(rtlpriv, SYS_FUNC_EN, (tmpu2b | BIT(13)));
+ tmpu2b = rtl_read_word(rtlpriv, REG_SYS_FUNC_EN);
+ rtl_write_word(rtlpriv, REG_SYS_FUNC_EN, (tmpu2b | BIT(13)));
- rtl_write_byte(rtlpriv, SYS_ISO_CTRL + 1, 0x68);
+ rtl_write_byte(rtlpriv, REG_SYS_ISO_CTRL + 1, 0x68);
/* Enable AFE PLL Macro Block */
tmpu1b = rtl_read_byte(rtlpriv, AFE_PLL_CTRL);
@@ -1447,17 +1447,17 @@ static void _rtl92se_power_domain_init(s
mdelay(1);
/* Release isolation AFE PLL & MD */
- rtl_write_byte(rtlpriv, SYS_ISO_CTRL, 0xA6);
+ rtl_write_byte(rtlpriv, REG_SYS_ISO_CTRL, 0xA6);
/* Enable MAC clock */
tmpu2b = rtl_read_word(rtlpriv, SYS_CLKR);
rtl_write_word(rtlpriv, SYS_CLKR, (tmpu2b | BIT(12) | BIT(11)));
/* Enable Core digital and enable IOREG R/W */
- tmpu2b = rtl_read_word(rtlpriv, SYS_FUNC_EN);
- rtl_write_word(rtlpriv, SYS_FUNC_EN, (tmpu2b | BIT(11)));
+ tmpu2b = rtl_read_word(rtlpriv, REG_SYS_FUNC_EN);
+ rtl_write_word(rtlpriv, REG_SYS_FUNC_EN, (tmpu2b | BIT(11)));
/* enable REG_EN */
- rtl_write_word(rtlpriv, SYS_FUNC_EN, (tmpu2b | BIT(11) | BIT(15)));
+ rtl_write_word(rtlpriv, REG_SYS_FUNC_EN, (tmpu2b | BIT(11) | BIT(15)));
/* Switch the control path. */
tmpu2b = rtl_read_word(rtlpriv, SYS_CLKR);
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/reg.h
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192se/reg.h
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/reg.h
@@ -735,6 +735,7 @@
#define HWSET_MAX_SIZE_92S 128
#define EFUSE_MAX_SECTION 16
#define EFUSE_REAL_CONTENT_LEN 512
+#define EFUSE_OOB_PROTECT_BYTES 15
#define RTL8190_EEPROM_ID 0x8129
#define EEPROM_HPON 0x02
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -304,6 +304,7 @@ static struct rtl_hal_cfg rtl92se_hal_cf
.maps[EFUSE_HWSET_MAX_SIZE] = HWSET_MAX_SIZE_92S,
.maps[EFUSE_MAX_SECTION_MAP] = EFUSE_MAX_SECTION,
.maps[EFUSE_REAL_CONTENT_SIZE] = EFUSE_REAL_CONTENT_LEN,
+ .maps[EFUSE_OOB_PROTECT_BYTES_LEN] = EFUSE_OOB_PROTECT_BYTES,
.maps[RWCAM] = REG_RWCAM,
.maps[WCAMI] = REG_WCAMI,
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -124,18 +124,15 @@ static void _rtl92se_query_rxphystatus(s
u8 i, max_spatial_stream;
u32 rssi, total_rssi = 0;
bool in_powersavemode = false;
- bool is_cck_rate;
+ bool is_cck = pstats->is_cck;
- is_cck_rate = SE_RX_HAL_IS_CCK_RATE(pdesc);
pstats->packet_matchbssid = packet_match_bssid;
pstats->packet_toself = packet_toself;
- pstats->is_cck = is_cck_rate;
pstats->packet_beacon = packet_beacon;
- pstats->is_cck = is_cck_rate;
pstats->rx_mimo_signalquality[0] = -1;
pstats->rx_mimo_signalquality[1] = -1;
- if (is_cck_rate) {
+ if (is_cck) {
u8 report, cck_highpwr;
cck_buf = (struct phy_sts_cck_8192s_t *)p_drvinfo;
@@ -246,9 +243,8 @@ static void _rtl92se_query_rxphystatus(s
pstats->rxpower = rx_pwr_all;
pstats->recvsignalpower = rx_pwr_all;
- if (GET_RX_STATUS_DESC_RX_HT(pdesc) &&
- GET_RX_STATUS_DESC_RX_MCS(pdesc) >= DESC92_RATEMCS8 &&
- GET_RX_STATUS_DESC_RX_MCS(pdesc) <= DESC92_RATEMCS15)
+ if (pstats->is_ht && pstats->rate >= DESC92_RATEMCS8 &&
+ pstats->rate <= DESC92_RATEMCS15)
max_spatial_stream = 2;
else
max_spatial_stream = 1;
@@ -266,7 +262,7 @@ static void _rtl92se_query_rxphystatus(s
}
}
- if (is_cck_rate)
+ if (is_cck)
pstats->signalstrength = (u8)(_rtl92se_signal_scale_mapping(hw,
pwdb_all));
else if (rf_rx_num != 0)
@@ -518,6 +514,7 @@ bool rtl92se_rx_query_desc(struct ieee80
{
struct rx_fwinfo *p_drvinfo;
u32 phystatus = (u32)GET_RX_STATUS_DESC_PHY_STATUS(pdesc);
+ struct ieee80211_hdr *hdr;
stats->length = (u16)GET_RX_STATUS_DESC_PKT_LEN(pdesc);
stats->rx_drvinfo_size = (u8)GET_RX_STATUS_DESC_DRVINFO_SIZE(pdesc) * 8;
@@ -530,8 +527,12 @@ bool rtl92se_rx_query_desc(struct ieee80
stats->rate = (u8)GET_RX_STATUS_DESC_RX_MCS(pdesc);
stats->shortpreamble = (u16)GET_RX_STATUS_DESC_SPLCP(pdesc);
stats->isampdu = (bool)(GET_RX_STATUS_DESC_PAGGR(pdesc) == 1);
+ stats->isfirst_ampdu = (bool) ((GET_RX_STATUS_DESC_PAGGR(pdesc) == 1)
+ && (GET_RX_STATUS_DESC_FAGGR(pdesc) == 1));
stats->timestamp_low = GET_RX_STATUS_DESC_TSFL(pdesc);
stats->rx_is40Mhzpacket = (bool)GET_RX_STATUS_DESC_BW(pdesc);
+ stats->is_ht = (bool)GET_RX_STATUS_DESC_RX_HT(pdesc);
+ stats->is_cck = SE_RX_HAL_IS_CCK_RATE(pdesc);
if (stats->hwerror)
return false;
@@ -539,29 +540,39 @@ bool rtl92se_rx_query_desc(struct ieee80
rx_status->freq = hw->conf.channel->center_freq;
rx_status->band = hw->conf.channel->band;
- if (GET_RX_STATUS_DESC_CRC32(pdesc))
- rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
+ hdr = (struct ieee80211_hdr *)(skb->data + stats->rx_drvinfo_size
+ + stats->rx_bufshift);
- if (!GET_RX_STATUS_DESC_SWDEC(pdesc))
- rx_status->flag |= RX_FLAG_DECRYPTED;
+ if (stats->crc)
+ rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
- if (GET_RX_STATUS_DESC_BW(pdesc))
+ if (stats->rx_is40Mhzpacket)
rx_status->flag |= RX_FLAG_40MHZ;
- if (GET_RX_STATUS_DESC_RX_HT(pdesc))
+ if (stats->is_ht)
rx_status->flag |= RX_FLAG_HT;
rx_status->flag |= RX_FLAG_MACTIME_MPDU;
- if (stats->decrypted)
- rx_status->flag |= RX_FLAG_DECRYPTED;
+ /* hw will set stats->decrypted true, if it finds the
+ * frame is open data frame or mgmt frame,
+ * hw will not decrypt robust managment frame
+ * for IEEE80211w but still set stats->decrypted
+ * true, so here we should set it back to undecrypted
+ * for IEEE80211w frame, and mac80211 sw will help
+ * to decrypt it */
+ if (stats->decrypted) {
+ if ((ieee80211_is_robust_mgmt_frame(hdr)) &&
+ (ieee80211_has_protected(hdr->frame_control)))
+ rx_status->flag &= ~RX_FLAG_DECRYPTED;
+ else
+ rx_status->flag |= RX_FLAG_DECRYPTED;
+ }
rx_status->rate_idx = rtlwifi_rate_mapping(hw,
- (bool)GET_RX_STATUS_DESC_RX_HT(pdesc),
- (u8)GET_RX_STATUS_DESC_RX_MCS(pdesc));
-
+ stats->is_ht, stats->rate);
- rx_status->mactime = GET_RX_STATUS_DESC_TSFL(pdesc);
+ rx_status->mactime = stats->timestamp_low;
if (phystatus) {
p_drvinfo = (struct rx_fwinfo *)(skb->data +
stats->rx_bufshift);
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/wifi.h
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/wifi.h
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/wifi.h
@@ -450,6 +450,7 @@ enum rtl_var_map {
EFUSE_HWSET_MAX_SIZE,
EFUSE_MAX_SECTION_MAP,
EFUSE_REAL_CONTENT_SIZE,
+ EFUSE_OOB_PROTECT_BYTES_LEN,
/*CAM map */
RWCAM,
@@ -1324,6 +1325,7 @@ struct rtl_stats {
s8 rx_mimo_signalquality[2];
bool packet_matchbssid;
bool is_cck;
+ bool is_ht;
bool packet_toself;
bool packet_beacon; /*for rssi */
char cck_adc_pwdb[4]; /*for rx path selection */
[-- Attachment #6: 0005-rtlwifi-rtl8192de-Updates-from-latest-Reaktek-driver.patch --]
[-- Type: text/x-patch, Size: 7962 bytes --]
>From 319071578daa1e1a151d4488510c3b706e2803cd Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Wed, 5 Oct 2011 11:14:37 -0500
Subject: [PATCH 5/5] rtlwifi: rtl8192de: Updates from latest Reaktek driver -
Part III
To: linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org
From: Chaoming Li <chaoming_li@realsil.com.cn>
This patch incorporate the differences between the 06/20/2011 and
08/16/2011 Realtek releases of the rtl8192de driver.
The changes include:
1. Update for new chip versions
Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192de/def.h | 124 ++++++++++++++++----------
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 19 ++---
2 files changed, 84 insertions(+), 59 deletions(-)
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192de/def.h
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192de/def.h
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192de/def.h
@@ -122,60 +122,99 @@
#define GET_C2H_CMD_FEEDBACK_CCX_SEQ(__pcmdfbhdr) \
LE_BITS_TO_4BYTE(((__pcmdfbhdr) + 4), 20, 12)
-/*
- * 92D chip ver:
- * BIT8: IS 92D
- * BIT9: single phy
- * BIT10: C-cut
- * BIT11: D-cut
- */
-
-/* Chip specific */
-#define CHIP_92C BIT(0)
-#define CHIP_92C_1T2R BIT(1)
-#define CHIP_8723 BIT(2) /* RTL8723 With BT feature */
-#define CHIP_8723_DRV_REV BIT(3) /* RTL8723 Driver Revised */
-#define NORMAL_CHIP BIT(4)
-#define CHIP_VENDOR_UMC BIT(5)
-#define CHIP_VENDOR_UMC_B_CUT BIT(6) /* Chip version for ECO */
+enum version_8192d {
+ VERSION_TEST_CHIP_88C = 0x0000,
+ VERSION_TEST_CHIP_92C = 0x0020,
+ VERSION_TEST_UMC_CHIP_8723 = 0x0081,
+ VERSION_NORMAL_TSMC_CHIP_88C = 0x0008,
+ VERSION_NORMAL_TSMC_CHIP_92C = 0x0028,
+ VERSION_NORMAL_TSMC_CHIP_92C_1T2R = 0x0018,
+ VERSION_NORMAL_UMC_CHIP_88C_A_CUT = 0x0088,
+ VERSION_NORMAL_UMC_CHIP_92C_A_CUT = 0x00a8,
+ VERSION_NORMAL_UMC_CHIP_92C_1T2R_A_CUT = 0x0098,
+ VERSION_NORMAL_UMC_CHIP_8723_1T1R_A_CUT = 0x0089,
+ VERSION_NORMAL_UMC_CHIP_8723_1T1R_B_CUT = 0x1089,
+ VERSION_NORMAL_UMC_CHIP_88C_B_CUT = 0x1088,
+ VERSION_NORMAL_UMC_CHIP_92C_B_CUT = 0x10a8,
+ VERSION_NORMAL_UMC_CHIP_92C_1T2R_B_CUT = 0x1090,
+ VERSION_TEST_CHIP_92D_SINGLEPHY = 0x0022,
+ VERSION_TEST_CHIP_92D_DUALPHY = 0x0002,
+ VERSION_NORMAL_CHIP_92D_SINGLEPHY = 0x002a,
+ VERSION_NORMAL_CHIP_92D_DUALPHY = 0x000a,
+ VERSION_NORMAL_CHIP_92D_C_CUT_SINGLEPHY = 0x202a,
+ VERSION_NORMAL_CHIP_92D_C_CUT_DUALPHY = 0x200a,
+ VERSION_NORMAL_CHIP_92D_D_CUT_SINGLEPHY = 0x302a,
+ VERSION_NORMAL_CHIP_92D_D_CUT_DUALPHY = 0x300a,
+ VERSION_NORMAL_CHIP_92D_E_CUT_SINGLEPHY = 0x402a,
+ VERSION_NORMAL_CHIP_92D_E_CUT_DUALPHY = 0x400a,
+};
/* for 92D */
-#define CHIP_92D BIT(8)
#define CHIP_92D_SINGLEPHY BIT(9)
+#define C_CUT_VERSION BIT(13)
+#define D_CUT_VERSION ((BIT(12)|BIT(13)))
+#define E_CUT_VERSION BIT(14)
+
+/* Chip specific */
+#define CHIP_BONDING_IDENTIFIER(_value) (((_value)>>22)&0x3)
+#define CHIP_BONDING_92C_1T2R 0x1
+#define CHIP_BONDING_88C_USB_MCARD 0x2
+#define CHIP_BONDING_88C_USB_HP 0x1
+
+/* [15:12] IC version(CUT): A-cut=0, B-cut=1, C-cut=2, D-cut=3 */
+/* [7] Manufacturer: TSMC=0, UMC=1 */
+/* [6:4] RF type: 1T1R=0, 1T2R=1, 2T2R=2 */
+/* [3] Chip type: TEST=0, NORMAL=1 */
+/* [2:0] IC type: 81xxC=0, 8723=1, 92D=2 */
+#define CHIP_8723 BIT(0)
+#define CHIP_92D BIT(1)
+#define NORMAL_CHIP BIT(3)
+#define RF_TYPE_1T1R (~(BIT(4)|BIT(5)|BIT(6)))
+#define RF_TYPE_1T2R BIT(4)
+#define RF_TYPE_2T2R BIT(5)
+#define CHIP_VENDOR_UMC BIT(7)
+#define B_CUT_VERSION BIT(12)
+
+/* MASK */
+#define IC_TYPE_MASK (BIT(0)|BIT(1)|BIT(2))
+#define CHIP_TYPE_MASK BIT(3)
+#define RF_TYPE_MASK (BIT(4)|BIT(5)|BIT(6))
+#define MANUFACTUER_MASK BIT(7)
+#define ROM_VERSION_MASK (BIT(11)|BIT(10)|BIT(9)|BIT(8))
+#define CUT_VERSION_MASK (BIT(15)|BIT(14)|BIT(13)|BIT(12))
+
+
+/* Get element */
+#define GET_CVID_IC_TYPE(version) ((version) & IC_TYPE_MASK)
+#define GET_CVID_CHIP_TYPE(version) ((version) & CHIP_TYPE_MASK)
+#define GET_CVID_RF_TYPE(version) ((version) & RF_TYPE_MASK)
+#define GET_CVID_MANUFACTUER(version) ((version) & MANUFACTUER_MASK)
+#define GET_CVID_ROM_VERSION(version) ((version) & ROM_VERSION_MASK)
+#define GET_CVID_CUT_VERSION(version) ((version) & CUT_VERSION_MASK)
+
+#define IS_1T1R(version) ((GET_CVID_RF_TYPE(version)) ? \
+ false : true)
+#define IS_1T2R(version) ((GET_CVID_RF_TYPE(version) == \
+ RF_TYPE_1T2R) ? true : false)
+#define IS_2T2R(version) ((GET_CVID_RF_TYPE(version) == \
+ RF_TYPE_2T2R) ? true : false)
+
+#define IS_92D_SINGLEPHY(version) ((IS_92D(version)) ? \
+ (IS_2T2R(version) ? true : false) : false)
+#define IS_92D(version) ((GET_CVID_IC_TYPE(version) == \
+ CHIP_92D) ? true : false)
+#define IS_92D_C_CUT(version) ((IS_92D(version)) ? \
+ ((GET_CVID_CUT_VERSION(version) == \
+ 0x2000) ? true : false) : false)
+#define IS_92D_D_CUT(version) ((IS_92D(version)) ? \
+ ((GET_CVID_CUT_VERSION(version) == \
+ 0x3000) ? true : false) : false)
+#define IS_92D_E_CUT(version) ((IS_92D(version)) ? \
+ ((GET_CVID_CUT_VERSION(version) == \
+ 0x4000) ? true : false) : false)
#define CHIP_92D_C_CUT BIT(10)
#define CHIP_92D_D_CUT BIT(11)
-enum version_8192d {
- VERSION_TEST_CHIP_88C = 0x00,
- VERSION_TEST_CHIP_92C = 0x01,
- VERSION_NORMAL_TSMC_CHIP_88C = 0x10,
- VERSION_NORMAL_TSMC_CHIP_92C = 0x11,
- VERSION_NORMAL_TSMC_CHIP_92C_1T2R = 0x13,
- VERSION_NORMAL_UMC_CHIP_88C_A_CUT = 0x30,
- VERSION_NORMAL_UMC_CHIP_92C_A_CUT = 0x31,
- VERSION_NORMAL_UMC_CHIP_92C_1T2R_A_CUT = 0x33,
- VERSION_NORMA_UMC_CHIP_8723_1T1R_A_CUT = 0x34,
- VERSION_NORMA_UMC_CHIP_8723_1T1R_B_CUT = 0x3c,
- VERSION_NORMAL_UMC_CHIP_88C_B_CUT = 0x70,
- VERSION_NORMAL_UMC_CHIP_92C_B_CUT = 0x71,
- VERSION_NORMAL_UMC_CHIP_92C_1T2R_B_CUT = 0x73,
- VERSION_TEST_CHIP_92D_SINGLEPHY = 0x300,
- VERSION_TEST_CHIP_92D_DUALPHY = 0x100,
- VERSION_NORMAL_CHIP_92D_SINGLEPHY = 0x310,
- VERSION_NORMAL_CHIP_92D_DUALPHY = 0x110,
- VERSION_NORMAL_CHIP_92D_C_CUT_SINGLEPHY = 0x710,
- VERSION_NORMAL_CHIP_92D_C_CUT_DUALPHY = 0x510,
- VERSION_NORMAL_CHIP_92D_D_CUT_SINGLEPHY = 0xB10,
- VERSION_NORMAL_CHIP_92D_D_CUT_DUALPHY = 0x910,
-};
-
-#define IS_92D_SINGLEPHY(version) \
- ((version & CHIP_92D_SINGLEPHY) ? true : false)
-#define IS_92D_C_CUT(version) \
- ((version & CHIP_92D_C_CUT) ? true : false)
-#define IS_92D_D_CUT(version) \
- ((version & CHIP_92D_D_CUT) ? true : false)
-
enum rf_optype {
RF_OP_BY_SW_3WIRE = 0,
RF_OP_BY_FW,
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
@@ -1608,17 +1608,16 @@ static void _rtl92de_read_txpower_info(s
tempval[0] = hwinfo[EEPROM_IQK_DELTA] & 0x03;
tempval[1] = (hwinfo[EEPROM_LCK_DELTA] & 0x0C) >> 2;
rtlefuse->txpwr_fromeprom = true;
- if (IS_92D_D_CUT(rtlpriv->rtlhal.version)) {
+ if (IS_92D_D_CUT(rtlpriv->rtlhal.version) ||
+ IS_92D_E_CUT(rtlpriv->rtlhal.version)) {
rtlefuse->internal_pa_5g[0] =
- !((hwinfo[EEPROM_TSSI_A_5G] &
- BIT(6)) >> 6);
+ !((hwinfo[EEPROM_TSSI_A_5G] & BIT(6)) >> 6);
rtlefuse->internal_pa_5g[1] =
- !((hwinfo[EEPROM_TSSI_B_5G] &
- BIT(6)) >> 6);
- RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
+ !((hwinfo[EEPROM_TSSI_B_5G] & BIT(6)) >> 6);
+ RT_TRACE(rtlpriv, COMP_INIT, DBG_DMESG,
("Is D cut,Internal PA0 %d Internal PA1 %d\n",
- rtlefuse->internal_pa_5g[0],
- rtlefuse->internal_pa_5g[1]))
+ rtlefuse->internal_pa_5g[0],
+ rtlefuse->internal_pa_5g[1]))
}
rtlefuse->eeprom_c9 = hwinfo[EEPROM_RF_OPT6];
rtlefuse->eeprom_cc = hwinfo[EEPROM_RF_OPT7];
^ permalink raw reply related
* When is the carl9170 source code going to be available again?
From: chris @ 2011-10-06 2:03 UTC (permalink / raw)
To: linux-wireless
When is the carl9170 source code going to be available again?
http://git.kernel.org/?p=linux/kernel/git/chr/carl9170fw.git
Reports no such project. Is there another means of gaining access to it?
Thanks!
^ permalink raw reply
* RE: mwifiex: add cfg80211 handlers add/del_virtual_intf
From: Bing Zhao @ 2011-10-05 23:14 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Yogesh Powar, linux-wireless@vger.kernel.org
In-Reply-To: <20111005195228.GG30887@longonot.mountain>
Hi Dan,
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Wednesday, October 05, 2011 12:52 PM
> To: Bing Zhao
> Cc: Yogesh Powar; linux-wireless@vger.kernel.org
> Subject: Re: mwifiex: add cfg80211 handlers add/del_virtual_intf
>
> On Wed, Oct 05, 2011 at 12:08:36PM -0700, Bing Zhao wrote:
> > Since the first element of priv[] cannot be NULL. How about this fix?
> >
> > + priv = adapter->priv[0];
> > + BUG_ON(!priv);
> > +
> > wiphy_unregister(priv->wdev->wiphy);
> >
>
> I don't know the code at all, so I'll trust you on that. :)
>
> But please don't add the BUG_ON(). Calls to BUG_ON() make the code
> messier, and they are more painful than needed for the user. If we
> don't have the BUG_ON() then we get an Oops and the driver will die,
> but we can still can close our documents and reboot the system.
>
> Debugging NULL dereference bugs is normally super easy. Just compile
> with CONFIG_DEBUG_INFO=y, run gdb on the .ko file and type:
> "list *(function_name+0x63)" at the gdb prompt. Done.
Thanks for the information.
Regards,
Bing
>
> regards,
> dan carpenter
^ permalink raw reply
* Re: Cannot make ath9k driver
From: Panu Avakul @ 2011-10-05 23:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <CAB=NE6VhgWws89upWaON_0FXmSnmyzsLSyO2S2fTfY2eYvwv4w@mail.gmail.com>
Thank you very much for your reply,
I tried the compat-wireless-2011-09-27.tar.bz2 which is the latest one
I believed.
It still give me the same problem.
However,
I changed the ath.h file according to
https://dev.openwrt.org/changeset/28095
and it seems that now it works ok now.
Thank you very much.
Best Regards,
Panu Avakul
On Wed, Oct 5, 2011 at 4:05 PM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> On Wed, Oct 5, 2011 at 3:57 PM, Panu Avakul <avakulpa@gmail.com> wrote:
>> Hello, I got the compat-wireless-2011-09-27
>
> Can you try today's release?
>
> Luis
>
^ permalink raw reply
* Re: Cannot make ath9k driver
From: Luis R. Rodriguez @ 2011-10-05 23:05 UTC (permalink / raw)
To: Panu Avakul; +Cc: linux-wireless
In-Reply-To: <CAFHVRfc1N8YNCmxMwsk1_UCZFQuOMNJE-9y31dnfcwrDsk36wA@mail.gmail.com>
On Wed, Oct 5, 2011 at 3:57 PM, Panu Avakul <avakulpa@gmail.com> wrote:
> Hello, I got the compat-wireless-2011-09-27
Can you try today's release?
Luis
^ permalink raw reply
* Cannot make ath9k driver
From: Panu Avakul @ 2011-10-05 22:57 UTC (permalink / raw)
To: linux-wireless
Hello, I got the compat-wireless-2011-09-27 and was trying to make the
ath9k driver.
I did the
./scripts/driver-select ath9k
sudo make unload
sudo make
However, it give me this error
make -C /lib/modules/2.6.38-11-generic-pae/build
M=/home/radius0014/compat-wireless-2011-09-27 modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.38-11-generic-pae'
CC [M] /home/radius0014/compat-wireless-2011-09-27/drivers/net/wireless/ath/debug.o
/home/radius0014/compat-wireless-2011-09-27/drivers/net/wireless/ath/debug.c:19:13:
error: redefinition of ‘ath_opmode_to_string’
/home/radius0014/compat-wireless-2011-09-27/drivers/net/wireless/ath/ath.h:280:27:
note: previous definition of ‘ath_opmode_to_string’ was here
make[4]: *** [/home/radius0014/compat-wireless-2011-09-27/drivers/net/wireless/ath/debug.o]
Error 1
make[3]: *** [/home/radius0014/compat-wireless-2011-09-27/drivers/net/wireless/ath]
Error 2
make[2]: *** [/home/radius0014/compat-wireless-2011-09-27/drivers/net/wireless]
Error 2
make[1]: *** [_module_/home/radius0014/compat-wireless-2011-09-27] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.38-11-generic-pae'
make: *** [modules] Error 2
Does anyone have similar problem or know someway to fix this?
I used to got it to compiled a while ago and did not work with it until now.
I also tried different version and they all giving me similar error.
Thank you very much,
Best Regards,
Panu
^ permalink raw reply
* Re: [PATCH v13 5/5] ath9k: implement .get_antenna and .set_antenna
From: Felix Fietkau @ 2011-10-05 22:43 UTC (permalink / raw)
To: Daniel Smith; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <4E8C9D53.1080307@gmail.com>
On 2011-10-05 8:09 PM, Daniel Smith wrote:
> On 9/2/2011 7:40 PM, Felix Fietkau wrote:
>> On MIMO chips this can be used to enable/disable hardware chains, ensuring
>> that the MCS information is updated accordingly.
>> On non-MIMO chips with rx diversity (e.g. 9285), this configures the rx
>> input antenna.
>
> I have been working with this patch as I needed the ability to select
> the rx chain/antenna on an AR9820.. A problem I have ran into is that
> regardless of what I set the antenna chain to, the radiotap header
> always reports antenna 1. I know this originates from the rx status
> descriptor, but is this really what should be used to report the antenna
> when using chains to select the antenna?
Typically all receive chains are used simultaneously when receiving
packets, and the antenna field in the rx status is meaningless. I'm
currently working on a patch that makes per-chain rx signal strength
available in the status info and puts it in the station info available
via nl80211.
- Felix
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:37 UTC (permalink / raw)
To: Adrian Chadd
Cc: Christian Lamparter, Zefir Kurtisi, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-VmomWYUtd84APvEg7mKC-sevT3UVaX2qKBn3KiVriPZybgQ@mail.gmail.com>
On Tue, Oct 4, 2011 at 7:50 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
>
> For example: you may not want to do DFS on the AR5416 NICs because (as
> documented in the open hal and earlier ath9k bits) there isn't support
> for radar pulses on the ext channel. So even if you had a successful
> DFS algorithm for this NIC, you'd have to somehow tell the DFS
> machinery that HT40+DFS channels aren't supported but HT20+DFS
> channels are.
Good point. I simply rather start out with the best possible DFS
support on Linux and go with the best hardware we have instead of
dealing with old hardware. Think about the support issues that can
come up with supporting the above. I rather simply not deal with it as
I also do not care about Turbo crap. Let legacy crap die.
> But then, the AR5416 supports per-packet TPC, so you could use it in
> STA mode perfectly fine and it'd support that part of spectrum
> management. Since you get per-frame RSSI of RX'ed frames, you can
> support the spectrum power histogram IE.
TPC is not implemented even in a lot of proprietary code bases,
although TPC is part of 802.11h its requirements are me by statically
reducing the maximum EIRP by 3 dB in frequency bands requiring TPC in
consideration for interference with satellites. In my latest
evaluation of TPC the only thing we want to do is simply enable the
option to explicitly state the max delta on power in consideration for
TPC in such a way that *if* TPC is implemented we can reduce the
reduction. But given that this is hardware specific and vendor
specific and not many people implement it right now I frankly don't
care too much about it. DFS is a bigger aspect.
Luis
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:31 UTC (permalink / raw)
To: Adrian Chadd
Cc: Zefir Kurtisi, Christian Lamparter, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-Vmo=TACq_d7JU0stibcqnvWgzUO7Ozue=4VayeHNcgXTejw@mail.gmail.com>
On Tue, Oct 4, 2011 at 7:34 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> .. erm, how complicated is the pattern matching code when it's compiled?
>
> The port of the fusion radar detection module didn't end up being all that big.
Adrian, please keep terms like "fusion codebase" out of public lists.
Luis
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:30 UTC (permalink / raw)
To: Zefir Kurtisi
Cc: Christian Lamparter, linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <4E8B157F.2080203@neratec.com>
On Tue, Oct 4, 2011 at 7:17 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> On 10/04/2011 03:38 PM, Christian Lamparter wrote:
>> On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
>>> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
>>> <chunkeey@googlemail.com> wrote:
>>>> On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
>>>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>>>>>>
>>>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>>>>> ---
>>>>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>>>>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>>>>>> index e8aeb98..5defebe 100644
>>>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>>>>>> "Unable to reset channel, reset status %d\n", r);
>>>>>> goto out;
>>>>>> }
>>>>>> +#ifdef CONFIG_ATH9K_DFS
>>>>>
>>>>> Please spare the #ifdef and just call something within dfs.c, then
>>>>> dfs.h would wrap it to nothing if DFS is disabled.
>>>> Why would anyone want to disable DFS driver support?
>>>> I would say: drop the ifdefs altogether since DFS
>>>> is and will be "required".
>>>
>>> Because DFS requires to be properly tested before being enabled.
>> Testing if a driver detects a pulse is "trivial" compared to the
>> stuff mac80211/cfg80211 and hostapd will have to do to make a
>> channel-change as smooth as possible. I think if there's a DFS
>> "OFF" switch, it should be in hostapd and I hope more people
>> agree on this one.
>>
> Yes on both. Work on the management part of the DFS module has just been started by TI guys. When this is in, hostapd will be able to query the driver's DFS detection capabilities and leave DFS channels disabled for those devices with no (or insufficient) support (like it is generally done today for DFS channels).
>
> The proper way for a driver's OFF switch would then be to just announce missing DFS capabilities.
And this is what I meant by leaving a kernel build option available
for each driver to enable/disable DFS. If a vendor does not want to
deal with the question of enabling DFS they can disable it on the
driver front.
>>> You may also want to simply disable DFS if you do not want to
>>> deal with the regulatory test implications of having it enabled.
>> AFAIK you can't "simply" disable the DFS requirement: hostapd
>> (hw_features.c), [cfg80211] (checks if tx on secondary channel
>> is possible) and mac80211 (tx.c) all have checks. Indeed, the
>> easiest way is to modify crda's database. So there's no need
>> for an extra compile-time option.
>>
> There might be a demand for conditional compiling in addition to DFS capabilities announcements to reduce memory footprint, since (especially) pattern matching algorithms will increase it significantly.
I doubt space considerations will be that much given that we don't
even have build options to disable hardware families, at least nbd had
determine already that separating families at build time wouldn't save
us much. Given that -- I suspect using build size as an argument for
introducing a flag here doesn't carry much weight. The argument I'm
using is to simply enable integrators to decide whether or not to have
to deal with testing such features.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:27 UTC (permalink / raw)
To: Christian Lamparter; +Cc: kgiori, ath9k-devel, linux-wireless, Zefir Kurtisi
In-Reply-To: <201110041538.12885.chunkeey@googlemail.com>
On Tue, Oct 4, 2011 at 6:38 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
>> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
>> >> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> >> >
>> >> > Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>> >> > ---
>> >> > drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>> >> > 1 files changed, 12 insertions(+), 0 deletions(-)
>> >> >
>> >> > diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>> >> > index e8aeb98..5defebe 100644
>> >> > --- a/drivers/net/wireless/ath/ath9k/main.c
>> >> > +++ b/drivers/net/wireless/ath/ath9k/main.c
>> >> > @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>> >> > "Unable to reset channel, reset status %d\n", r);
>> >> > goto out;
>> >> > }
>> >> > +#ifdef CONFIG_ATH9K_DFS
>> >>
>> >> Please spare the #ifdef and just call something within dfs.c, then
>> >> dfs.h would wrap it to nothing if DFS is disabled.
>> > Why would anyone want to disable DFS driver support?
>> > I would say: drop the ifdefs altogether since DFS
>> > is and will be "required".
>>
>> Because DFS requires to be properly tested before being enabled.
> Testing if a driver detects a pulse is "trivial" compared to the
> stuff mac80211/cfg80211 and hostapd will have to do to make a
> channel-change as smooth as possible. I think if there's a DFS
> "OFF" switch, it should be in hostapd and I hope more people
> agree on this one.
You do have a good point, but I disagree that you do not need to test
/ regress test hardware / driver code for DFS. This is what I'm
talking about. But yes, userspace also submits itself to the same
criteria.
>> You may also want to simply disable DFS if you do not want to
>> deal with the regulatory test implications of having it enabled.
> AFAIK you can't "simply" disable the DFS requirement: hostapd
> (hw_features.c), [cfg80211] (checks if tx on secondary channel
> is possible) and mac80211 (tx.c) all have checks. Indeed, the
> easiest way is to modify crda's database. So there's no need
> for an extra compile-time option.
No, DFS is set for certain channels on wireless-regdb/CRDA, I just
posted DFS master region support for wireless-regdb and CRDA. Apart
from this we then need driver support. To get DFS you need all of
these + hostapd part. Each one has its own set of components and does
deserve its own set of tests and review.
Luis
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:23 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <4E8ADBE0.6050406@neratec.com>
On Tue, Oct 4, 2011 at 3:11 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> On 10/03/2011 08:27 PM, Luis R. Rodriguez wrote:
>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>>>
>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>> ---
>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>>> index e8aeb98..5defebe 100644
>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>>> "Unable to reset channel, reset status %d\n", r);
>>> goto out;
>>> }
>>> +#ifdef CONFIG_ATH9K_DFS
>>> + /**
>>> + * enable radar pulse detection
>>> + *
>>> + * TODO: do this only for DFS channels
>>> + */
>>> + ah->private_ops.set_radar_params(ah, &ah->radar_conf);
>>> + ath9k_hw_setrxfilter(ah,
>>> + ath9k_hw_getrxfilter(ah) | ATH9K_RX_FILTER_PHYRADAR);
>>> + ath_dbg(common, ATH_DBG_DFS,
>>> + "DFS enabled for channel %d\n", hchan->chan->center_freq);
>>> +#endif
>>
>> Please spare the #ifdef and just call something within dfs.c, then
>> dfs.h would wrap it to nothing if DFS is disabled.
>>
> This possibly won't work, since setting up DFS registers is part of HW layer and not
> done in the dfs module. If you want to have DFS conditionally compilable, you can not spare this #ifdefs.
Its not about sparing the ifdefs completely but instead to place them
strategically to remove #ifdef sprinkling all over C code. You can
leave ifdefs on header files, and for C files leaves this as a
conditional build time option.
Luis
^ permalink raw reply
* Re: [RFC 4/6] ath9k: add DFS build parameter
From: Luis R. Rodriguez @ 2011-10-05 22:20 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Zefir Kurtisi, linux-wireless, ath9k-devel, kgiori
In-Reply-To: <4E8AE1CC.5060703@openwrt.org>
On Tue, Oct 4, 2011 at 3:37 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-10-04 11:55 AM, Zefir Kurtisi wrote:
>>
>> On 10/03/2011 08:26 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi<zefir.kurtisi@neratec.com>
>>> wrote:
>>>>
>>>> Signed-off-by: Zefir Kurtisi<zefir.kurtisi@neratec.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath9k/Kconfig | 7 +++++++
>>>> drivers/net/wireless/ath/ath9k/Makefile | 2 ++
>>>> 2 files changed, 9 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
>>>> b/drivers/net/wireless/ath/ath9k/Kconfig
>>>> index d9c08c6..adddcca 100644
>>>> --- a/drivers/net/wireless/ath/ath9k/Kconfig
>>>> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
>>>> @@ -58,6 +58,13 @@ config ATH9K_RATE_CONTROL
>>>> Say Y, if you want to use the ath9k specific rate control
>>>> module instead of minstrel_ht.
>>>>
>>>> +config ATH9K_DFS
>>>> + bool "Atheros ath9k DFS support"
>>>> + depends on ATH9K
>>>> + default y
>>>
>>> At this point selecting y does nothing. Leave this patch out until
>>> selecting "y" means something.
>>>
>> What do you mean by 'nothing'? It allows you to select DFS as ath9k
>> feature in your kernel configuration, or? Though, I agree that enabling it
>> by default is not a good idea.
>>
>>> Default should be n, and in particular Atheros itself can only likely
>>> commit to supporting DFS for AR9003 when it finds resources to do so
>>> as well as properly test it, so DFS support kconfig should state this.
>>> If someone wants to step up to completely support all bugs for older
>>> families that is their prerogative but we cannot commit to it, due to
>>> the regulatory considerations though unless this happens this cannot
>>> and should not be enabled for older families in code.
>>>
>> In fact, AR9003 is the platform we are interested in. Although it
>> seems that older chipsets do also detect pulses with this patches
>> (AR9280 does, IIRC), I agree to limit DFS support to AR9003 (and later).
>> This should be easily possible by setting priv_ops->set_radar_params for
>> AR9003 only. I'll remove it for AR5008 in my v2 RFC.
>
> Please don't remove support code for older hardware. I'm fine with adding a
> SREV check that prevents it from being enabled by default on older hardware,
> but eventually I will need at least AR9280 DFS support for a few devices in
> OpenWrt.
That's fine, leaving it disabled is what I meant, and only once
something has been properly tested do we enable it. I personally only
want to spend my own energy on AR9003 and newer.
Luis
^ 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