Re: [PATCH 2/2] ath10k: set peer MFP flag in peer assoc command
"Raja, Tamizh Chelvam" writes: >>> From: Tamizh chelvam >>> >>> Set peer's management frame protection flag in peer assoc command, >>> this setting will enable/disable encrytion of management frames in fw. >>> >>> Setting of this flag is based on whether MFP is enabled/disabled at >>> STA and a firmware feature flag ATH10K_FW_FEATURE_MFP_SUPPORT. This is >>> because only firmwares 10.1.561 and above have support for MFP. >>> >>> Signed-off-by: Tamizh chelvam >>> Signed-off-by: Manikanta pubbisetty > >>There was a trivial conflict, please check my conflict resolution in the >>pending branch: > >>https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=c33d4ded1d2db2166c14afe602fe7ef645a5b16b > > > When I try to apply this patch. I got following conflict. > > Checking patch drivers/net/wireless/ath/ath10k/core.c... > Checking patch drivers/net/wireless/ath/ath10k/core.h... > Hunk #1 succeeded at 512 (offset -1 lines). > Checking patch drivers/net/wireless/ath/ath10k/htt_tx.c... > Checking patch drivers/net/wireless/ath/ath10k/mac.c... > error: while searching for: I don't know what you are trying to do, but I apply the patches from the pending branch to ath-next. You might get a conflict if you apply the patch to another branch. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] Revert "Staging: wilc1000: coreconfigurator: Drop unneeded wrapper functions"
The addresses are not properly aglined for using ether_addr_copy function.
I revert this as author agree to drop this patch.
This reverts commit d4622f68db8095dd54179e3134e97812727f6b89.
Signed-off-by: Glen Lee
---
drivers/staging/wilc1000/coreconfigurator.c | 48 +++--
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 1caa66e..954b5eb 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -13,12 +13,8 @@
#include "wilc_wlan.h"
#include
#include
-#include
#define TAG_PARAM_OFFSET (MAC_HDR_LEN + TIME_STAMP_LEN + \
BEACON_INTERVAL_LEN +
CAP_INFO_LEN)
-#define ADDR1 4
-#define ADDR2 10
-#define ADDR3 16
/* Basic Frame Type Codes (2-bit) */
enum basic_frame_type {
@@ -175,32 +171,38 @@ static inline u8 get_from_ds(u8 *header)
return ((header[1] & 0x02) >> 1);
}
+/* This function extracts the MAC Address in 'address1' field of the MAC */
+/* header and updates the MAC Address in the allocated 'addr' variable. */
+static inline void get_address1(u8 *pu8msa, u8 *addr)
+{
+ memcpy(addr, pu8msa + 4, 6);
+}
+
+/* This function extracts the MAC Address in 'address2' field of the MAC */
+/* header and updates the MAC Address in the allocated 'addr' variable. */
+static inline void get_address2(u8 *pu8msa, u8 *addr)
+{
+ memcpy(addr, pu8msa + 10, 6);
+}
+
+/* This function extracts the MAC Address in 'address3' field of the MAC */
+/* header and updates the MAC Address in the allocated 'addr' variable. */
+static inline void get_address3(u8 *pu8msa, u8 *addr)
+{
+ memcpy(addr, pu8msa + 16, 6);
+}
+
/* This function extracts the BSSID from the incoming WLAN packet based on */
-/* the 'from ds' bit, and updates the MAC Address in the allocated 'data'*/
+/* the 'from ds' bit, and updates the MAC Address in the allocated 'addr'*/
/* variable. */
static inline void get_BSSID(u8 *data, u8 *bssid)
{
if (get_from_ds(data) == 1)
- /*
-* Extract the MAC Address in 'address2' field of the MAC
-* header and update the MAC Address in the allocated 'data'
-* variable.
-*/
- ether_addr_copy(data, bssid + ADDR2);
+ get_address2(data, bssid);
else if (get_to_ds(data) == 1)
- /*
-* Extract the MAC Address in 'address1' field of the MAC
-* header and update the MAC Address in the allocated 'data'
-* variable.
-*/
- ether_addr_copy(data, bssid + ADDR1);
+ get_address1(data, bssid);
else
- /*
-* Extract the MAC Address in 'address3' field of the MAC
-* header and update the MAC Address in the allocated 'data'
-* variable.
-*/
- ether_addr_copy(data, bssid + ADDR3);
+ get_address3(data, bssid);
}
/* This function extracts the SSID from a beacon/probe response frame*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel 7260 - limited in 5GHz spectrum
On Tue, 2015-11-03 at 09:43 -0800, Tim Harvey wrote: > No surprise that its sold outside the US, but why should that mean it > should exclude 5GHz support? They all have their regulatory domains > and my understanding is that the intersection of the reg domain rules > and card capabilities should dictate if they can operate as an AP per > 5GHz channel. So I'm trying to understand why this card is dropping > that capability. > It does have 5 GHz capability, but not for active operation, since that's not permitted everywhere in the world. The device doesn't want to rely on software regulatory enforcement, nor are there multiple versions of the device for different countries, so this is about the only option left. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iw: Removed the libnl-tiny >= 1 requirement
On Wed, 2015-11-04 at 08:31 +0200, Dima Krasner wrote: > Hi, > > Recent libnl-tiny revisions do not specify a version in the pkg > -config data. This patch corrects libnl-tiny support added in the > previous patch in the series, so it works with the latest revision > too. You need to resend the patch (after reading iw's CONTRIBUTING file) - so please just make a single one. Thanks, johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] iw: Removed the libnl-tiny >= 1 requirement
Hi, Recent libnl-tiny revisions do not specify a version in the pkg-config data. This patch corrects libnl-tiny support added in the previous patch in the series, so it works with the latest revision too. Cheers, Dima >From 84f4fbf5e9f765dafbb436b2593f13d1326a27ea Mon Sep 17 00:00:00 2001 From: Dima Krasner Date: Wed, 4 Nov 2015 07:57:04 +0200 Subject: [PATCH 2/2] Removed the libnl-tiny >= 1 requirement --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 63169a3..4077020 100644 --- a/Makefile +++ b/Makefile @@ -27,7 +27,7 @@ OBJS += $(OBJS-y) $(OBJS-Y) ALL = iw ifeq ($(NO_PKG_CONFIG),) -NLTINYFOUND := $(shell $(PKG_CONFIG) --atleast-version=1 libnl-tiny && echo Y) +NLTINYFOUND := $(shell $(PKG_CONFIG) libnl-tiny && echo Y) ifneq ($(NLTINYFOUND),Y) NL3xFOUND := $(shell $(PKG_CONFIG) --atleast-version=3.2 libnl-3.0 && echo Y) ifneq ($(NL3xFOUND),Y) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
[fixed ath9k list address. sorry for the spam] Hi all, I have a pretty weird problem I've been chasing for a few weeks and have narrowed it down, but not quite solved it. It may be caused by bugs in aggregation-related code. Steps: - Set up an ath9k-based Linux AP on an ARM processor (currently using this version of backports, though I've tried older and newer versions with no change: "backported from Linux (next-20150525-0-gc201847) using backports backports-20150525-0-g49969bd") - Join my iPhone 4S (running iOS 7.1.2) to the network - Use it for a while - Eventually it will stay connected, but Internet access doesn't work - Wireless packet captures show that packets are received *from* the iPhone, and ACKs are returned for those packets from the ath9k, and those packets are correctly forwarded to the AP's br0 interface. But outgoing packets show up on br0 and wlan0 with tcpdump, but never make it onto the air. - Putting the iPhone 4S into airplane mode and then letting it reconnecting will fix it for a few more seconds/minutes before it stops again. More details: - It only seems to happen to my iPhone 4S client (never seen it with a different client). - It only seems to happen with my ath9k AP. - It only seems to happen on my home network (another instance of the same AP hardware on another network doesn't trigger the problem). - It only seems to happen when no other 802.11n-capable devices are connected to the same AP. - The moment I join an 802.11n-capable device to the AP, traffic instantly unblocks (see packet capture below). - Joining an 802.11g-only device (no aggregation) does *not* unblock traffic. - Disabling encryption and turning wmm_enable on and off have no effect. - Disabling 802.11n support on the AP (so that everyone has to use 802.11g) makes the problem go away. - 'ip -s link show dev wlan0' shows tx packet counters continuing to increase during the outage, even though packets aren't flowing. - I applied a patch from Tim Shepard to track the most recent tx attempt, acked tx, and rx packet times inside mac80211. According to this data, mac80211 thinks rx happened at most a couple of seconds ago (as expected). The most recent tx was acked, but it was back around the time the outage started. Note that this disagrees with 'ip -s link' and tcpdump, which think they transmitted much more recently than that. (The patch is here: https://gfiber-review.googlesource.com/#/c/1250/ ) I captured a pcap of a new 802.11n-capable device joining the network and unblocking the transmit. The action starts around frame 325: http://apenwarr.ca/tmp/iPod4-fixing-iPhone4-trimmed.pcap.gz In this pcap, the main players are: ath9k AP: 88:dc:96:08:60:50 iPhone 4S with the problem: e4:25:e7:73:e6:31 New client fixing the problem (iPod 4): 18:e7:f4:7e:c1:42 Observations from the pcap: - Upstream packets (iPhone->ath9k) are received and acked (see eg. frame 154) - Beacons from the ath9k show an empty TIM bitmap until the iPod joins, then it's nonempty and things unblock. Does anyone have any thoughts about what to look for here? Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ath10k: set peer MFP flag in peer assoc command
>> From: Tamizh chelvam >> >> Set peer's management frame protection flag in peer assoc command, >> this setting will enable/disable encrytion of management frames in fw. >> >> Setting of this flag is based on whether MFP is enabled/disabled at >> STA and a firmware feature flag ATH10K_FW_FEATURE_MFP_SUPPORT. This is >> because only firmwares 10.1.561 and above have support for MFP. >> >> Signed-off-by: Tamizh chelvam >> Signed-off-by: Manikanta pubbisetty >There was a trivial conflict, please check my conflict resolution in the >pending branch: >https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=c33d4ded1d2db2166c14afe602fe7ef645a5b16b When I try to apply this patch. I got following conflict. Checking patch drivers/net/wireless/ath/ath10k/core.c... Checking patch drivers/net/wireless/ath/ath10k/core.h... Hunk #1 succeeded at 512 (offset -1 lines). Checking patch drivers/net/wireless/ath/ath10k/htt_tx.c... Checking patch drivers/net/wireless/ath/ath10k/mac.c... error: while searching for: ath10k_dbg(ar, ATH10K_DBG_WMI, "%s: wpa ie found\n", __func__); arg->peer_flags |= ar->wmi.peer_flags->need_gtk_2_way; } } static void ath10k_peer_assoc_h_rates(struct ath10k *ar, error: patch failed: drivers/net/wireless/ath/ath10k/mac.c:2009 Hunk #3 succeeded at 2480 (offset -6 lines). Applied patch drivers/net/wireless/ath/ath10k/core.c cleanly. Applied patch drivers/net/wireless/ath/ath10k/core.h cleanly. Applied patch drivers/net/wireless/ath/ath10k/htt_tx.c cleanly. Applying patch drivers/net/wireless/ath/ath10k/mac.c with 1 rejects... Hunk #1 applied cleanly. Rejected hunk #2. Hunk #3 applied cleanly. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ath10k: Add thermal throttling support for 10.4 firmware.
>> From: Tamizh chelvam >> >> This patch enables thermal throttling support for 10.4 firmware. >> >> Signed-off-by: Tamizh chelvam >There was a trivial conflict, please check my conflict resolution in the >pending branch: >https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=6a3b459d9bb84bf6ae02cef084895898b18316a4 Looks good. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins
Hi all, I have a pretty weird problem I've been chasing for a few weeks and have narrowed it down, but not quite solved it. It may be caused by bugs in aggregation-related code. Steps: - Set up an ath9k-based Linux AP on an ARM processor (currently using this version of backports, though I've tried older and newer versions with no change: "backported from Linux (next-20150525-0-gc201847) using backports backports-20150525-0-g49969bd") - Join my iPhone 4S (running iOS 7.1.2) to the network - Use it for a while - Eventually it will stay connected, but Internet access doesn't work - Wireless packet captures show that packets are received *from* the iPhone, and ACKs are returned for those packets from the ath9k, and those packets are correctly forwarded to the AP's br0 interface. But outgoing packets show up on br0 and wlan0 with tcpdump, but never make it onto the air. - Putting the iPhone 4S into airplane mode and then letting it reconnecting will fix it for a few more seconds/minutes before it stops again. More details: - It only seems to happen to my iPhone 4S client (never seen it with a different client). - It only seems to happen with my ath9k AP. - It only seems to happen on my home network (another instance of the same AP hardware on another network doesn't trigger the problem). - It only seems to happen when no other 802.11n-capable devices are connected to the same AP. - The moment I join an 802.11n-capable device to the AP, traffic instantly unblocks (see packet capture below). - Joining an 802.11g-only device (no aggregation) does *not* unblock traffic. - Disabling encryption and turning wmm_enable on and off have no effect. - Disabling 802.11n support on the AP (so that everyone has to use 802.11g) makes the problem go away. - 'ip -s link show dev wlan0' shows tx packet counters continuing to increase during the outage, even though packets aren't flowing. - I applied a patch from Tim Shepard to track the most recent tx attempt, acked tx, and rx packet times inside mac80211. According to this data, mac80211 thinks rx happened at most a couple of seconds ago (as expected). The most recent tx was acked, but it was back around the time the outage started. Note that this disagrees with 'ip -s link' and tcpdump, which think they transmitted much more recently than that. (The patch is here: https://gfiber-review.googlesource.com/#/c/1250/ ) I captured a pcap of a new 802.11n-capable device joining the network and unblocking the transmit. The action starts around frame 325: http://apenwarr.ca/tmp/iPod4-fixing-iPhone4-trimmed.pcap.gz In this pcap, the main players are: ath9k AP: 88:dc:96:08:60:50 iPhone 4S with the problem: e4:25:e7:73:e6:31 New client fixing the problem (iPod 4): 18:e7:f4:7e:c1:42 Observations from the pcap: - Upstream packets (iPhone->ath9k) are received and acked (see eg. frame 154) - Beacons from the ath9k show an empty TIM bitmap until the iPod joins, then it's nonempty and things unblock. Does anyone have any thoughts about what to look for here? Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] brcm: new firmware files
On Fri, Oct 23, 2015 at 11:21:46AM +0200, Arend van Spriel wrote:
> One firmware file update and firmware for a new supported device.
>
> The patches are for the master branch of the linux-firmware repository
> and apply on top of commit 66d3d8d7607c ("Add FW binary used by mwlwifi
> driver.").
>
> Arend van Spriel (2):
> brcm: adding firmware for BCM4350 PCIe device
> brcm: update firmware for the BCM4356 PCIe device
>
> WHENCE | 1 +
> brcm/brcmfmac4350-pcie.bin | Bin 0 -> 626140 bytes
> brcm/brcmfmac4356-pcie.bin | Bin 593956 -> 623012 bytes
> 3 files changed, 1 insertion(+)
> create mode 100755 brcm/brcmfmac4350-pcie.bin
> rewrite brcm/brcmfmac4356-pcie.bin (77%)
>
applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ath10k: add notice.txt references to WHENCE
On Tue, Oct 20, 2015 at 06:13:29PM +0300, Kalle Valo wrote: > This is to make sure that the notice files get automatically included. > > Signed-off-by: Kalle Valo applied. > --- > WHENCE |5 + > 1 file changed, 5 insertions(+) > > diff --git a/WHENCE b/WHENCE > index 9b7e8e8526aa..ded2e7ad161b 100755 > --- a/WHENCE > +++ b/WHENCE > @@ -2393,17 +2393,22 @@ Driver: ath10k - Qualcomm Atheros support for QCA988x > family of chips > File: ath10k/QCA988X/hw2.0/board.bin > File: ath10k/QCA988X/hw2.0/firmware-4.bin > Version: 10.2.4.45 > +Licence: ath10k/QCA988X/hw2.0/notice_ath10k_firmware-4.txt > File: ath10k/QCA988X/hw2.0/firmware-5.bin > Version: 10.2.4.70.9-2 > +Licence: ath10k/QCA988X/hw2.0/notice_ath10k_firmware-5.txt > File: ath10k/QCA6174/hw2.1/board.bin > File: ath10k/QCA6174/hw2.1/firmware-5.bin > Version: WLAN.RM.1.1-00141 > +Licence: ath10k/QCA6174/hw2.1/notice_ath10k_firmware-5.txt > File: ath10k/QCA6174/hw3.0/board.bin > File: ath10k/QCA6174/hw3.0/firmware-4.bin > Version: WLAN.RM.2.0-00180-QCARMSWPZ-1 > +Licence: ath10k/QCA6174/hw3.0/notice_ath10k_firmware-4.txt > File: ath10k/QCA99X0/hw2.0/board.bin > File: ath10k/QCA99X0/hw2.0/firmware-5.bin > Version: 10.4.1.00030-1 > +Licence: ath10k/QCA99X0/hw2.0/notice_ath10k_firmware-5.txt > > Licence: Redistributable. See LICENSE.QualcommAtheros_ath10k for details > > -- > 1.7.9.5 > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NFC: nfcmrvl: fix SPI driver dependencies
Hi Arnd,
On Tue, Nov 03, 2015 at 03:03:33PM +0100, Arnd Bergmann wrote:
> The newly added nfcmrvl_spi driver uses the spi_nci
> infrastructure, but does not have a Kconfig dependency on
> that, so we can get a link-time error:
>
> drivers/built-in.o: In function `nfcmrvl_spi_nci_send':
> (.text+0x1428dc): undefined reference to `nci_spi_send'
> drivers/built-in.o: In function `nfcmrvl_spi_probe':
> (.text+0x142a24): undefined reference to `nci_spi_allocate_spi'
> drivers/built-in.o: In function `nfcmrvl_spi_int_irq_thread_fn':
> (.text+0x142abc): undefined reference to `nci_spi_read'
>
> This clarifies the dependency.
>
> Signed-off-by: Arnd Bergmann
> Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
Applied, thanks.
Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Question STBC and LDPC
I've been digging in the guts of ath10k rate-ctrl, and I notice that if I tell the chip to do NSS of 1 without STBC or LDPC, then it works as I expect (single stream, MCS-1 encoding). But, if I do NSS of 1 and STBC and LDPC enabled (VHT-MCS-0, for instance), then wireshark shows the frame as being a 2-stream packet and double the bandwidth. Is this expected? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iw: Add libnl-tiny support
Hi,
I'd like to upstream this patch, which adds libnl-tiny support to iw, as a
smaller alternative to libnl 2.0. It's great for static builds against musl.
Cheers,
Dima
>From 88ad01745f6f8b2d5fcc066d18dba9dce21609fd Mon Sep 17 00:00:00 2001
From: Dima Krasner
Date: Wed, 4 Nov 2015 00:04:44 +0200
Subject: [PATCH] Added libnl-tiny support
---
Makefile | 8
iw.c | 10 --
iw.h | 2 +-
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index e61825e..63169a3 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,8 @@ OBJS += $(OBJS-y) $(OBJS-Y)
ALL = iw
ifeq ($(NO_PKG_CONFIG),)
+NLTINYFOUND := $(shell $(PKG_CONFIG) --atleast-version=1 libnl-tiny && echo Y)
+ifneq ($(NLTINYFOUND),Y)
NL3xFOUND := $(shell $(PKG_CONFIG) --atleast-version=3.2 libnl-3.0 && echo Y)
ifneq ($(NL3xFOUND),Y)
NL31FOUND := $(shell $(PKG_CONFIG) --exact-version=3.1 libnl-3.1 && echo Y)
@@ -40,6 +42,12 @@ endif
endif
endif
endif
+endif
+
+ifeq ($(NLTINYFOUND),Y)
+CFLAGS += -DCONFIG_LIBNL_TINY
+NLLIBNAME = libnl-tiny
+endif
ifeq ($(NL1FOUND),Y)
NLLIBNAME = libnl-1
diff --git a/iw.c b/iw.c
index 0f511d9..f702e92 100644
--- a/iw.c
+++ b/iw.c
@@ -23,8 +23,14 @@
#include "nl80211.h"
#include "iw.h"
+#ifdef CONFIG_LIBNL_TINY
+#define nl_handle nl_sock
+#define nl_handle_alloc_cb nl_socket_alloc_cb
+#define nl_handle_destroy nl_socket_free
+#endif
+
/* libnl 1.x compatibility code */
-#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
+#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) &&
!defined(CONFIG_LIBNL_TINY)
static inline struct nl_handle *nl_socket_alloc(void)
{
return nl_handle_alloc();
@@ -40,7 +46,7 @@ static inline int nl_socket_set_buffer_size(struct nl_sock
*sk,
{
return nl_set_buffer_size(sk, rxbuf, txbuf);
}
-#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 */
+#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 && CONFIG_LIBNL_TINY */
int iw_debug = 0;
diff --git a/iw.h b/iw.h
index 263e8b1..93813be 100644
--- a/iw.h
+++ b/iw.h
@@ -14,7 +14,7 @@
#define ETH_ALEN 6
/* libnl 1.x compatibility code */
-#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
+#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) &&
!defined(CONFIG_LIBNL_TINY)
# define nl_sock nl_handle
#endif
--
1.9.1
--
Dima Krasner
>From 88ad01745f6f8b2d5fcc066d18dba9dce21609fd Mon Sep 17 00:00:00 2001
From: Dima Krasner
Date: Wed, 4 Nov 2015 00:04:44 +0200
Subject: [PATCH] Added libnl-tiny support
---
Makefile | 8
iw.c | 10 --
iw.h | 2 +-
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index e61825e..63169a3 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,8 @@ OBJS += $(OBJS-y) $(OBJS-Y)
ALL = iw
ifeq ($(NO_PKG_CONFIG),)
+NLTINYFOUND := $(shell $(PKG_CONFIG) --atleast-version=1 libnl-tiny && echo Y)
+ifneq ($(NLTINYFOUND),Y)
NL3xFOUND := $(shell $(PKG_CONFIG) --atleast-version=3.2 libnl-3.0 && echo Y)
ifneq ($(NL3xFOUND),Y)
NL31FOUND := $(shell $(PKG_CONFIG) --exact-version=3.1 libnl-3.1 && echo Y)
@@ -40,6 +42,12 @@ endif
endif
endif
endif
+endif
+
+ifeq ($(NLTINYFOUND),Y)
+CFLAGS += -DCONFIG_LIBNL_TINY
+NLLIBNAME = libnl-tiny
+endif
ifeq ($(NL1FOUND),Y)
NLLIBNAME = libnl-1
diff --git a/iw.c b/iw.c
index 0f511d9..f702e92 100644
--- a/iw.c
+++ b/iw.c
@@ -23,8 +23,14 @@
#include "nl80211.h"
#include "iw.h"
+#ifdef CONFIG_LIBNL_TINY
+#define nl_handle nl_sock
+#define nl_handle_alloc_cb nl_socket_alloc_cb
+#define nl_handle_destroy nl_socket_free
+#endif
+
/* libnl 1.x compatibility code */
-#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
+#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) && !defined(CONFIG_LIBNL_TINY)
static inline struct nl_handle *nl_socket_alloc(void)
{
return nl_handle_alloc();
@@ -40,7 +46,7 @@ static inline int nl_socket_set_buffer_size(struct nl_sock *sk,
{
return nl_set_buffer_size(sk, rxbuf, txbuf);
}
-#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 */
+#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 && CONFIG_LIBNL_TINY */
int iw_debug = 0;
diff --git a/iw.h b/iw.h
index 263e8b1..93813be 100644
--- a/iw.h
+++ b/iw.h
@@ -14,7 +14,7 @@
#define ETH_ALEN 6
/* libnl 1.x compatibility code */
-#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
+#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) && !defined(CONFIG_LIBNL_TINY)
# define nl_sock nl_handle
#endif
--
1.9.1
Re: Ralink RT5592 5Ghz capability not working
OK. Too bad. Anyway, this EEPROM RF chipset detection is the part where needs to be looked at. At least that's where rt2x00 is deciding that the HW doesn't support 5GHz. On 11/03/15 22:44, Alberto Mattea wrote: > Hey, > > I didn't have to, it was recognized this way out of the box. > I had to install an eeprom for the other onboard chip though (5390). > > In data mar 3 novembre 2015 22:33:19, Gertjan van Wingerde ha scritto: >> Did you have to install an eeprom file for the RT5592 PCI device? >> >> If yes, this eeprom file could be the problem. As far as I can tell the >> rt2x00 driver only enables the 2.4 GHz band because it determines that >> the RF chip doesn't support the 5GHz band. The RF chip is determined >> from the EEPROM, and is currently read as an RF2820 chip (the message >> rt2x00_set_rf: Info - RF chipset 0001 detected) >> >> --- >> Gertjan. >> >> On 11/03/15 22:07, Alberto Mattea wrote: >>> I found the FCC photos for the RP-N53: >>> https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=2001985 >>> >>> On page 9 there is a photo of the ralink chip, unfortunately very blurred. >>> But I also found the photos for the Buffalo WHR-600D (which exhibits the >>> same behaviour): >>> https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1950610 >>> Here (page 12) we can clearly read "RT5692N", and if we look closer that's >>> the same number you can see on the RP-N53. That's a model I cannot find >>> anywhere. So it seems some kind of OEM specific chip. >>> >>> In data mar 3 novembre 2015 11:31:42, hai scritto: All signs point to RT5592 not supported by rt2x00 driver... I'm guessing they fudged pci id for some internal reasons (maybe even to mess with OpenWRT people). On Tue, Nov 3, 2015 at 11:09 AM, Alberto Mattea > wrote: > My device (the RP-N53) has 2 chips too: the other is integrated in the > mt7620 soc and reports itself as > > [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - > Loading EEPROM data from 'soc_wmac.eeprom'. [ 14.14] ieee80211 > phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected [ > 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 > detected > [ 14.17] ieee80211 phy1: Selected rate control algorithm > 'minstrel_ht' > > it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) > Unfortunately opening the RP-N53 appears impossible without voiding the > warranty :(> > > In data mar 3 novembre 2015 10:32:29, hai scritto: >> This is so strange. Asus RT-N56U you mentioned earlier as one of the >> examples actually has two separate chips for each band (and one of >> them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U >> Are you able to take a picture of the chip? >> >> On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea >>> >>> wrote: >>> Hey, thanks for your answer. The device definitely isn't a RT3091, so >>> do >>> you think it's some sort of an OEM hybrid? Do you think it would be >>> better to report this to the openwrt bugzilla? >>> >>> Thanks >>> >>> In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: Alberto Mattea wrote: > this is about the mini-pcie version used in some embedded products > (for example the Buffalo WHR-600D and the Asus RP-N53). > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > (5Ghz works with the proprietary driver supplied with the devices), > but rt2800pci seems to see only the 2.4 Ghz capability. As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > dmesg: > > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset > 5592, > rev > 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - > RF > chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate > control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: > rt2x00lib_request_firmware: Info - Loading firmware file > 'rt2860.bin' [ > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - > Firmware > detected - version: 0.34 Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb 2013): phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, rev: 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device. > The weird thing is that in lspci it is reported as an RT3091, due to > the > 0x3091 pci device id: > > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless > 802.11n > 1T/2R PCIe [1814:3091]> > >
Re: Ralink RT5592 5Ghz capability not working
In data mar 3 novembre 2015 22:44:00, Alberto Mattea ha scritto: > Hey, > > I didn't have to, it was recognized this way out of the box. > I had to install an eeprom for the other onboard chip though (5390). Oh and I just found this in lsmod: eeprom_93cx61616 1 rt2800pci So it seems it's getting the eeprom by itself > > In data mar 3 novembre 2015 22:33:19, Gertjan van Wingerde ha scritto: > > Did you have to install an eeprom file for the RT5592 PCI device? > > > > If yes, this eeprom file could be the problem. As far as I can tell the > > rt2x00 driver only enables the 2.4 GHz band because it determines that > > the RF chip doesn't support the 5GHz band. The RF chip is determined > > from the EEPROM, and is currently read as an RF2820 chip (the message > > rt2x00_set_rf: Info - RF chipset 0001 detected) > > > > --- > > Gertjan. > > > > On 11/03/15 22:07, Alberto Mattea wrote: > > > I found the FCC photos for the RP-N53: > > > https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=2001985 > > > > > > On page 9 there is a photo of the ralink chip, unfortunately very > > > blurred. > > > But I also found the photos for the Buffalo WHR-600D (which exhibits the > > > same behaviour): > > > https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1950610 > > > Here (page 12) we can clearly read "RT5692N", and if we look closer > > > that's > > > the same number you can see on the RP-N53. That's a model I cannot find > > > anywhere. So it seems some kind of OEM specific chip. > > > > > > In data mar 3 novembre 2015 11:31:42, hai scritto: > > >> All signs point to RT5592 not supported by rt2x00 driver... I'm > > >> guessing they fudged pci id for some internal reasons (maybe even to > > >> mess with OpenWRT people). > > >> > > >> On Tue, Nov 3, 2015 at 11:09 AM, Alberto Mattea > > wrote: > > >>> My device (the RP-N53) has 2 chips too: the other is integrated in the > > >>> mt7620 soc and reports itself as > > >>> > > >>> [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - > > >>> Loading EEPROM data from 'soc_wmac.eeprom'. [ 14.14] ieee80211 > > >>> phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected [ > > >>> 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 > > >>> detected > > >>> [ 14.17] ieee80211 phy1: Selected rate control algorithm > > >>> 'minstrel_ht' > > >>> > > >>> it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) > > >>> Unfortunately opening the RP-N53 appears impossible without voiding > > >>> the > > >>> warranty :(> > > >>> > > >>> In data mar 3 novembre 2015 10:32:29, hai scritto: > > This is so strange. Asus RT-N56U you mentioned earlier as one of the > > examples actually has two separate chips for each band (and one of > > them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U > > Are you able to take a picture of the chip? > > > > On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea > > > > > > wrote: > > > Hey, thanks for your answer. The device definitely isn't a RT3091, > > > so > > > do > > > you think it's some sort of an OEM hybrid? Do you think it would be > > > better to report this to the openwrt bugzilla? > > > > > > Thanks > > > > > > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: > > >> Alberto Mattea wrote: > > >>> this is about the mini-pcie version used in some embedded products > > >>> (for example the Buffalo WHR-600D and the Asus RP-N53). > > >>> It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > > >>> (5Ghz works with the proprietary driver supplied with the > > >>> devices), > > >>> but rt2800pci seems to see only the 2.4 Ghz capability. > > >> > > >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > > >> > > >>> dmesg: > > >>> > > >>> [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset > > >>> 5592, > > >>> rev > > >>> 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - > > >>> RF > > >>> chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate > > >>> control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: > > >>> rt2x00lib_request_firmware: Info - Loading firmware file > > >>> 'rt2860.bin' [ > > >>> 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - > > >>> Firmware > > >>> detected - version: 0.34 > > >> > > >> Here is the output of a real RT5592 PCIe device with rt2800pci > > >> driver(Feb > > >> 2013): > > >> > > >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: > > >> 000f, > > >> rev: > > >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 > > >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate > > >> device. > > >> > > >>> The weird thing is that in lspci it is reported as a
Re: Ralink RT5592 5Ghz capability not working
Hey, I didn't have to, it was recognized this way out of the box. I had to install an eeprom for the other onboard chip though (5390). In data mar 3 novembre 2015 22:33:19, Gertjan van Wingerde ha scritto: > Did you have to install an eeprom file for the RT5592 PCI device? > > If yes, this eeprom file could be the problem. As far as I can tell the > rt2x00 driver only enables the 2.4 GHz band because it determines that > the RF chip doesn't support the 5GHz band. The RF chip is determined > from the EEPROM, and is currently read as an RF2820 chip (the message > rt2x00_set_rf: Info - RF chipset 0001 detected) > > --- > Gertjan. > > On 11/03/15 22:07, Alberto Mattea wrote: > > I found the FCC photos for the RP-N53: > > https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=2001985 > > > > On page 9 there is a photo of the ralink chip, unfortunately very blurred. > > But I also found the photos for the Buffalo WHR-600D (which exhibits the > > same behaviour): > > https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1950610 > > Here (page 12) we can clearly read "RT5692N", and if we look closer that's > > the same number you can see on the RP-N53. That's a model I cannot find > > anywhere. So it seems some kind of OEM specific chip. > > > > In data mar 3 novembre 2015 11:31:42, hai scritto: > >> All signs point to RT5592 not supported by rt2x00 driver... I'm > >> guessing they fudged pci id for some internal reasons (maybe even to > >> mess with OpenWRT people). > >> > >> On Tue, Nov 3, 2015 at 11:09 AM, Alberto Mattea wrote: > >>> My device (the RP-N53) has 2 chips too: the other is integrated in the > >>> mt7620 soc and reports itself as > >>> > >>> [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - > >>> Loading EEPROM data from 'soc_wmac.eeprom'. [ 14.14] ieee80211 > >>> phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected [ > >>> 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 > >>> detected > >>> [ 14.17] ieee80211 phy1: Selected rate control algorithm > >>> 'minstrel_ht' > >>> > >>> it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) > >>> Unfortunately opening the RP-N53 appears impossible without voiding the > >>> warranty :(> > >>> > >>> In data mar 3 novembre 2015 10:32:29, hai scritto: > This is so strange. Asus RT-N56U you mentioned earlier as one of the > examples actually has two separate chips for each band (and one of > them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U > Are you able to take a picture of the chip? > > On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea > > > > wrote: > > Hey, thanks for your answer. The device definitely isn't a RT3091, so > > do > > you think it's some sort of an OEM hybrid? Do you think it would be > > better to report this to the openwrt bugzilla? > > > > Thanks > > > > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: > >> Alberto Mattea wrote: > >>> this is about the mini-pcie version used in some embedded products > >>> (for example the Buffalo WHR-600D and the Asus RP-N53). > >>> It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > >>> (5Ghz works with the proprietary driver supplied with the devices), > >>> but rt2800pci seems to see only the 2.4 Ghz capability. > >> > >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > >> > >>> dmesg: > >>> > >>> [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset > >>> 5592, > >>> rev > >>> 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - > >>> RF > >>> chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate > >>> control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: > >>> rt2x00lib_request_firmware: Info - Loading firmware file > >>> 'rt2860.bin' [ > >>> 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - > >>> Firmware > >>> detected - version: 0.34 > >> > >> Here is the output of a real RT5592 PCIe device with rt2800pci > >> driver(Feb > >> 2013): > >> > >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: > >> 000f, > >> rev: > >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 > >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate > >> device. > >> > >>> The weird thing is that in lspci it is reported as an RT3091, due to > >>> the > >>> 0x3091 pci device id: > >>> > >>> 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless > >>> 802.11n > >>> 1T/2R PCIe [1814:3091]> > >>> > >>> Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe > >>> [1814:3091] > >>> > >>> [...] > >> > >> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] > >> > >
Re: Ralink RT5592 5Ghz capability not working
Did you have to install an eeprom file for the RT5592 PCI device? If yes, this eeprom file could be the problem. As far as I can tell the rt2x00 driver only enables the 2.4 GHz band because it determines that the RF chip doesn't support the 5GHz band. The RF chip is determined from the EEPROM, and is currently read as an RF2820 chip (the message rt2x00_set_rf: Info - RF chipset 0001 detected) --- Gertjan. On 11/03/15 22:07, Alberto Mattea wrote: > I found the FCC photos for the RP-N53: > https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=2001985 > > On page 9 there is a photo of the ralink chip, unfortunately very blurred. > But > I also found the photos for the Buffalo WHR-600D (which exhibits the same > behaviour): > https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1950610 > Here (page 12) we can clearly read "RT5692N", and if we look closer that's > the > same number you can see on the RP-N53. That's a model I cannot find anywhere. > So it seems some kind of OEM specific chip. > > In data mar 3 novembre 2015 11:31:42, hai scritto: >> All signs point to RT5592 not supported by rt2x00 driver... I'm >> guessing they fudged pci id for some internal reasons (maybe even to >> mess with OpenWRT people). >> >> On Tue, Nov 3, 2015 at 11:09 AM, Alberto Mattea wrote: >>> My device (the RP-N53) has 2 chips too: the other is integrated in the >>> mt7620 soc and reports itself as >>> >>> [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - >>> Loading EEPROM data from 'soc_wmac.eeprom'. [ 14.14] ieee80211 >>> phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected [ >>> 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected >>> [ 14.17] ieee80211 phy1: Selected rate control algorithm >>> 'minstrel_ht' >>> >>> it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) >>> Unfortunately opening the RP-N53 appears impossible without voiding the >>> warranty :(> >>> In data mar 3 novembre 2015 10:32:29, hai scritto: This is so strange. Asus RT-N56U you mentioned earlier as one of the examples actually has two separate chips for each band (and one of them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U Are you able to take a picture of the chip? On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea > wrote: > Hey, thanks for your answer. The device definitely isn't a RT3091, so > do > you think it's some sort of an OEM hybrid? Do you think it would be > better to report this to the openwrt bugzilla? > > Thanks > > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: >> Alberto Mattea wrote: >>> this is about the mini-pcie version used in some embedded products >>> (for example the Buffalo WHR-600D and the Asus RP-N53). >>> It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz >>> (5Ghz works with the proprietary driver supplied with the devices), >>> but rt2800pci seems to see only the 2.4 Ghz capability. >> >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. >> >>> dmesg: >>> >>> [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset >>> 5592, >>> rev >>> 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - >>> RF >>> chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate >>> control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: >>> rt2x00lib_request_firmware: Info - Loading firmware file >>> 'rt2860.bin' [ >>> 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - >>> Firmware >>> detected - version: 0.34 >> >> Here is the output of a real RT5592 PCIe device with rt2800pci >> driver(Feb >> 2013): >> >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, >> rev: >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate >> device. >> >>> The weird thing is that in lspci it is reported as an RT3091, due to >>> the >>> 0x3091 pci device id: >>> >>> 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless >>> 802.11n >>> 1T/2R PCIe [1814:3091]> >>> >>> Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe >>> [1814:3091] >>> >>> [...] >> >> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] >> >> Subsystem: ASUSTeK Computer Inc. Device [1043:851a] >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- >> >> Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- >> ParErr- >> DEVSEL=fast >TAbort- SERR- > Cache Line Size: 64 bytes >> >> Interrupt: pin A routed to IRQ 11 >> Region 0: Memory at fe50 (32-bit, non-prefetchable) >
Re: Ralink RT5592 5Ghz capability not working
I found the FCC photos for the RP-N53: https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=2001985 On page 9 there is a photo of the ralink chip, unfortunately very blurred. But I also found the photos for the Buffalo WHR-600D (which exhibits the same behaviour): https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1950610 Here (page 12) we can clearly read "RT5692N", and if we look closer that's the same number you can see on the RP-N53. That's a model I cannot find anywhere. So it seems some kind of OEM specific chip. In data mar 3 novembre 2015 11:31:42, hai scritto: > All signs point to RT5592 not supported by rt2x00 driver... I'm > guessing they fudged pci id for some internal reasons (maybe even to > mess with OpenWRT people). > > On Tue, Nov 3, 2015 at 11:09 AM, Alberto Mattea wrote: > > My device (the RP-N53) has 2 chips too: the other is integrated in the > > mt7620 soc and reports itself as > > > > [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - > > Loading EEPROM data from 'soc_wmac.eeprom'. [ 14.14] ieee80211 > > phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected [ > > 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected > > [ 14.17] ieee80211 phy1: Selected rate control algorithm > > 'minstrel_ht' > > > > it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) > > Unfortunately opening the RP-N53 appears impossible without voiding the > > warranty :(> > > In data mar 3 novembre 2015 10:32:29, hai scritto: > >> This is so strange. Asus RT-N56U you mentioned earlier as one of the > >> examples actually has two separate chips for each band (and one of > >> them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U > >> Are you able to take a picture of the chip? > >> > >> On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea wrote: > >> > Hey, thanks for your answer. The device definitely isn't a RT3091, so > >> > do > >> > you think it's some sort of an OEM hybrid? Do you think it would be > >> > better to report this to the openwrt bugzilla? > >> > > >> > Thanks > >> > > >> > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: > >> >> Alberto Mattea wrote: > >> >> > this is about the mini-pcie version used in some embedded products > >> >> > (for example the Buffalo WHR-600D and the Asus RP-N53). > >> >> > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > >> >> > (5Ghz works with the proprietary driver supplied with the devices), > >> >> > but rt2800pci seems to see only the 2.4 Ghz capability. > >> >> > >> >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > >> >> > >> >> > dmesg: > >> >> > > >> >> > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset > >> >> > 5592, > >> >> > rev > >> >> > 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - > >> >> > RF > >> >> > chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate > >> >> > control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: > >> >> > rt2x00lib_request_firmware: Info - Loading firmware file > >> >> > 'rt2860.bin' [ > >> >> > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - > >> >> > Firmware > >> >> > detected - version: 0.34 > >> >> > >> >> Here is the output of a real RT5592 PCIe device with rt2800pci > >> >> driver(Feb > >> >> 2013): > >> >> > >> >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, > >> >> rev: > >> >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 > >> >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate > >> >> device. > >> >> > >> >> > The weird thing is that in lspci it is reported as an RT3091, due to > >> >> > the > >> >> > 0x3091 pci device id: > >> >> > > >> >> > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless > >> >> > 802.11n > >> >> > 1T/2R PCIe [1814:3091]> > >> >> > > >> >> > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe > >> >> > [1814:3091] > >> >> > > >> >> > [...] > >> >> > >> >> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] > >> >> > >> >> Subsystem: ASUSTeK Computer Inc. Device [1043:851a] > >> >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > >> >> ParErr- > >> >> > >> >> Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- > >> >> ParErr- > >> >> DEVSEL=fast >TAbort- SERR- >> >> Cache Line Size: 64 bytes > >> >> > >> >> Interrupt: pin A routed to IRQ 11 > >> >> Region 0: Memory at fe50 (32-bit, non-prefetchable) > >> >> [size=64K] > >> >> Capabilities: [40] Power Management version 3 > >> >> > >> >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > >> >> > >> >> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- > >> >> DSel=0 > >> >> DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- > >> >> 64bit+ > >> >> Ad
Re: Ralink RT5592 5Ghz capability not working
On 11/03/2015 07:10 PM, Alberto Mattea wrote: > Hey, thanks for your answer. The device definitely isn't a RT3091, so do you > think it's some sort of an OEM hybrid? I don't know. Open the device or look for photos at FCC site. wikidevi.com usually has links to it. > Do you think it would be better to report this to the openwrt bugzilla? Yes. As you can see, *OpenWrt doesn't run a standard Linux kernel* : -rw--- 1 xose xose 633 Nov 3 21:10 000-fix_kconfig.patch -rw--- 1 xose xose 5634 Nov 3 21:10 001-fix_build.patch -rw--- 1 xose xose 1651 Nov 3 21:10 002-change_allconfig.patch -rw--- 1 xose xose 1188 Nov 3 21:10 003-remove_bogus_modparams.patch -rw--- 1 xose xose 319 Nov 3 21:10 010-disable_rfkill.patch -rw--- 1 xose xose 875 Nov 3 21:10 030-rt2x00_options.patch -rw--- 1 xose xose 222 Nov 3 21:10 040-brcmutil_option.patch -rw--- 1 xose xose 622 Nov 3 21:10 050-lib80211_option.patch -rw--- 1 xose xose 3766 Nov 3 21:10 060-no_local_ssb_bcma.patch -rw--- 1 xose xose 391 Nov 3 21:10 070-ath_common_config.patch -rw--- 1 xose xose 390 Nov 3 21:10 080-disable_clk_backport.patch -rw--- 1 xose xose 10948 Nov 3 21:10 100-remove-cryptoapi-dependencies.patch -rw--- 1 xose xose 400 Nov 3 21:10 110-mac80211_keep_keys_on_stop_ap.patch -rw--- 1 xose xose 1292 Nov 3 21:10 120-cfg80211_allow_perm_addr_change.patch -rw--- 1 xose xose 1906 Nov 3 21:10 150-disable_addr_notifier.patch -rw--- 1 xose xose 1309 Nov 3 21:10 201-ath5k-WAR-for-AR71xx-PCI-bug.patch -rw--- 1 xose xose 385 Nov 3 21:10 210-ap_scan.patch -rw--- 1 xose xose 972 Nov 3 21:10 300-ath9k-force-rx_clear-when-disabling-rx.patch -rw--- 1 xose xose 3643 Nov 3 21:10 301-ath9k-limit-retries-for-powersave-response-frames.patch -rw--- 1 xose xose 4122 Nov 3 21:10 302-ath9k-fix-phyerror-codes.patch -rw--- 1 xose xose 8493 Nov 3 21:10 303-ath10k-enable-adaptive-CCA.patch -rw--- 1 xose xose 9188 Nov 3 21:10 304-ath10k-add-FW-API-support-to-test-mode.patch -rw--- 1 xose xose 14220 Nov 3 21:10 305-ath10k-add-fw_stats-support-to-10.4-firmware.patch -rw--- 1 xose xose 2173 Nov 3 21:10 306-ath10k-use-local-memory-instead-of-shadow-descriptor.patch -rw--- 1 xose xose 1195 Nov 3 21:10 307-ath10k-remove-send-completion-validation-in-diag-rea.patch -rw--- 1 xose xose 5688 Nov 3 21:10 308-ath10k-cleanup-copy-engine-send-completion.patch -rw--- 1 xose xose 2829 Nov 3 21:10 309-ath10k-remove-shadow-copy-of-CE-descriptors-for-sour.patch -rw--- 1 xose xose 2474 Nov 3 21:10 310-ath10k-remove-supported-chain-mask.patch -rw--- 1 xose xose 1305 Nov 3 21:10 311-ath10k-fill-HT-VHT-MCS-rateset-only-for-configured-c.patch -rw--- 1 xose xose 8563 Nov 3 21:10 312-ath10k-move-static-HT-VHT-capability-setup-functions.patch -rw--- 1 xose xose 1337 Nov 3 21:10 313-mac80211-fix-crash-on-mesh-local-link-ID-generation-.patch -rw--- 1 xose xose 795 Nov 3 21:10 400-ath_move_debug_code.patch -rw--- 1 xose xose 432 Nov 3 21:10 401-ath9k_blink_default.patch -rw--- 1 xose xose 1562 Nov 3 21:10 402-ath_regd_optional.patch -rw--- 1 xose xose 2131 Nov 3 21:10 403-world_regd_fixup.patch -rw--- 1 xose xose 551 Nov 3 21:10 404-regd_no_assoc_hints.patch -rw--- 1 xose xose 976 Nov 3 21:10 405-ath_regd_us.patch -rw--- 1 xose xose 1171 Nov 3 21:10 406-ath_relax_default_regd.patch -rw--- 1 xose xose 391 Nov 3 21:10 410-ath9k_allow_adhoc_and_ap.patch -rw--- 1 xose xose 1836 Nov 3 21:10 411-ath5k_allow_adhoc_and_ap.patch -rw--- 1 xose xose 476 Nov 3 21:10 420-ath5k_disable_fast_cc.patch -rw--- 1 xose xose 1263 Nov 3 21:10 430-add_ath5k_platform.patch -rw--- 1 xose xose 1398 Nov 3 21:10 431-add_platform_eeprom_support_to_ath5k.patch -rw--- 1 xose xose 514 Nov 3 21:10 432-ath5k_add_pciids.patch -rw--- 1 xose xose 4024 Nov 3 21:10 440-ath5k_channel_bw_debugfs.patch -rw--- 1 xose xose 1718 Nov 3 21:10 500-ath9k_eeprom_debugfs.patch -rw--- 1 xose xose 650 Nov 3 21:10 501-ath9k_ahb_init.patch -rw--- 1 xose xose 507 Nov 3 21:10 510-ath9k_intr_mitigation_tweak.patch -rw--- 1 xose xose 407 Nov 3 21:10 511-ath9k_reduce_rxbuf.patch -rw--- 1 xose xose 3555 Nov 3 21:10 512-ath9k_channelbw_debugfs.patch -rw--- 1 xose xose 932 Nov 3 21:10 513-ath9k_add_pci_ids.patch -rw--- 1 xose xose 5378 Nov 3 21:10 522-mac80211_configure_antenna_gain.patch -rw--- 1 xose xose 6653 Nov 3 21:10 530-ath9k_extra_leds.patch -rw--- 1 xose xose 1564 Nov 3 21:10 531-ath9k_extra_platform_leds.patch -rw--- 1 xose xose 354 Nov 3 21:10 540-ath9k_reduce_ani_interval.patch -rw--- 1 xose xose 819 Nov 3 21:10 541-ath9k_rx_dma_stop_check.patch -rw--- 1 xose xose 3967 Nov 3 21:10 542-ath9k_debugfs_diag.patch -rw--- 1 xose xose 6001 Nov 3 21:10 543-ath9k_entropy_from_adc.patch -rw---
Re: Ralink RT5592 5Ghz capability not working
All signs point to RT5592 not supported by rt2x00 driver... I'm guessing they fudged pci id for some internal reasons (maybe even to mess with OpenWRT people). On Tue, Nov 3, 2015 at 11:09 AM, Alberto Mattea wrote: > My device (the RP-N53) has 2 chips too: the other is integrated in the mt7620 > soc and reports itself as > > [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - Loading > EEPROM data from 'soc_wmac.eeprom'. > [ 14.14] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5390, rev > 0500 detected > [ 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected > [ 14.17] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' > > it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) > Unfortunately opening the RP-N53 appears impossible without voiding the > warranty :( > > In data mar 3 novembre 2015 10:32:29, hai scritto: >> This is so strange. Asus RT-N56U you mentioned earlier as one of the >> examples actually has two separate chips for each band (and one of >> them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U >> Are you able to take a picture of the chip? >> >> On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea wrote: >> > Hey, thanks for your answer. The device definitely isn't a RT3091, so do >> > you think it's some sort of an OEM hybrid? Do you think it would be >> > better to report this to the openwrt bugzilla? >> > >> > Thanks >> > >> > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: >> >> Alberto Mattea wrote: >> >> > this is about the mini-pcie version used in some embedded products >> >> > (for example the Buffalo WHR-600D and the Asus RP-N53). >> >> > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz >> >> > (5Ghz works with the proprietary driver supplied with the devices), >> >> > but rt2800pci seems to see only the 2.4 Ghz capability. >> >> >> >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. >> >> >> >> > dmesg: >> >> > >> >> > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, >> >> > rev >> >> > 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF >> >> > chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate >> >> > control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: >> >> > rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin' [ >> >> > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware >> >> > detected - version: 0.34 >> >> >> >> Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb >> >> 2013): >> >> >> >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, >> >> rev: >> >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 >> >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device. >> >> >> >> > The weird thing is that in lspci it is reported as an RT3091, due to >> >> > the >> >> > 0x3091 pci device id: >> >> > >> >> > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n >> >> > 1T/2R PCIe [1814:3091]> >> >> > >> >> > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe >> >> > [1814:3091] >> >> > >> >> > [...] >> >> >> >> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] >> >> >> >> Subsystem: ASUSTeK Computer Inc. Device [1043:851a] >> >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> >> ParErr- >> >> >> >> Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- >> >> ParErr- >> >> DEVSEL=fast >TAbort- SERR- > >> Cache Line Size: 64 bytes >> >> >> >> Interrupt: pin A routed to IRQ 11 >> >> Region 0: Memory at fe50 (32-bit, non-prefetchable) >> >> [size=64K] >> >> Capabilities: [40] Power Management version 3 >> >> >> >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA >> >> >> >> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 >> >> DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ >> >> Address: Data: >> >> >> >> Capabilities: [70] Express (v2) Endpoint, MSI 00 >> >> >> >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s >> >> >> >> <512ns, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- >> >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >> >> RlxdOrd- >> >> ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 >> >> bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >> >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, >> >> L1 <64us ClockPM+ Surprise- LLActRep- BwNot- >> >> >> >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- >> >> >> >> CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed >> >> 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >> >> D
Re: Ralink RT5592 5Ghz capability not working
My device (the RP-N53) has 2 chips too: the other is integrated in the mt7620 soc and reports itself as [ 14.12] ieee80211 phy1: rt2x00lib_request_eeprom_file: Info - Loading EEPROM data from 'soc_wmac.eeprom'. [ 14.14] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected [ 14.15] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected [ 14.17] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' it is used for 2.4Ghz only (https://wikidevi.com/wiki/ASUS_RP-N53) Unfortunately opening the RP-N53 appears impossible without voiding the warranty :( In data mar 3 novembre 2015 10:32:29, hai scritto: > This is so strange. Asus RT-N56U you mentioned earlier as one of the > examples actually has two separate chips for each band (and one of > them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U > Are you able to take a picture of the chip? > > On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea wrote: > > Hey, thanks for your answer. The device definitely isn't a RT3091, so do > > you think it's some sort of an OEM hybrid? Do you think it would be > > better to report this to the openwrt bugzilla? > > > > Thanks > > > > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: > >> Alberto Mattea wrote: > >> > this is about the mini-pcie version used in some embedded products > >> > (for example the Buffalo WHR-600D and the Asus RP-N53). > >> > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > >> > (5Ghz works with the proprietary driver supplied with the devices), > >> > but rt2800pci seems to see only the 2.4 Ghz capability. > >> > >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > >> > >> > dmesg: > >> > > >> > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, > >> > rev > >> > 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF > >> > chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate > >> > control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: > >> > rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin' [ > >> > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware > >> > detected - version: 0.34 > >> > >> Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb > >> 2013): > >> > >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, > >> rev: > >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 > >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device. > >> > >> > The weird thing is that in lspci it is reported as an RT3091, due to > >> > the > >> > 0x3091 pci device id: > >> > > >> > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n > >> > 1T/2R PCIe [1814:3091]> > >> > > >> > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe > >> > [1814:3091] > >> > > >> > [...] > >> > >> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] > >> > >> Subsystem: ASUSTeK Computer Inc. Device [1043:851a] > >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > >> ParErr- > >> > >> Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- > >> ParErr- > >> DEVSEL=fast >TAbort- SERR- >> Cache Line Size: 64 bytes > >> > >> Interrupt: pin A routed to IRQ 11 > >> Region 0: Memory at fe50 (32-bit, non-prefetchable) > >> [size=64K] > >> Capabilities: [40] Power Management version 3 > >> > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > >> > >> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 > >> DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ > >> Address: Data: > >> > >> Capabilities: [70] Express (v2) Endpoint, MSI 00 > >> > >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s > >> > >> <512ns, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- > >> RlxdOrd- > >> ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 > >> bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, > >> L1 <64us ClockPM+ Surprise- LLActRep- BwNot- > >> > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > >> > >> CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed > >> 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > >> DevCap2: Completion Timeout: Not Supported, TimeoutDis+ DevCtl2: > >> Completion > >> Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 2.5GT/s, > >> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: > >> Normal Operating Range, EnterModifiedCompliance- Complia
Re: Ralink RT5592 5Ghz capability not working
This is so strange. Asus RT-N56U you mentioned earlier as one of the examples actually has two separate chips for each band (and one of them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U Are you able to take a picture of the chip? On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea wrote: > Hey, thanks for your answer. The device definitely isn't a RT3091, so do you > think it's some sort of an OEM hybrid? Do you think it would be better to > report this to the openwrt bugzilla? > > Thanks > > In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: >> Alberto Mattea wrote: >> > this is about the mini-pcie version used in some embedded products >> > (for example the Buffalo WHR-600D and the Asus RP-N53). >> > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz >> > (5Ghz works with the proprietary driver supplied with the devices), >> > but rt2800pci seems to see only the 2.4 Ghz capability. >> >> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. >> >> > dmesg: >> > >> > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev >> > 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF >> > chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate >> > control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: >> > rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin' [ >> > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware >> > detected - version: 0.34 >> Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb >> 2013): >> >> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, rev: >> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 >> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device. >> >> > The weird thing is that in lspci it is reported as an RT3091, due to the >> > 0x3091 pci device id: >> > >> > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n >> > 1T/2R PCIe [1814:3091]> >> > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe >> > [1814:3091] >> > >> > [...] >> >> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] >> Subsystem: ASUSTeK Computer Inc. Device [1043:851a] >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- >> DEVSEL=fast >TAbort- SERR- > Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 11 >> Region 0: Memory at fe50 (32-bit, non-prefetchable) [size=64K] >> Capabilities: [40] Power Management version 3 >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA >> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 >> DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ >> Address: Data: >> Capabilities: [70] Express (v2) Endpoint, MSI 00 >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s >> <512ns, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- >> ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 >> bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, >> L1 <64us ClockPM+ Surprise- LLActRep- BwNot- >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- >> CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed >> 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >> DevCap2: Completion Timeout: Not Supported, TimeoutDis+ DevCtl2: Completion >> Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 2.5GT/s, >> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: >> Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance >> De-emphasis: -6dB >> LnkSta2: Current De-emphasis Level: -6dB, >> EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, >> EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] >> Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- >> CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ >> ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- >> NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- >> NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ >> ChkEn- Capabilities: [140 v1] Device Serial Number c1-a5-f3-ff-fe-a9-85-30 >> > So maybe due to this (i'm not sure), rt2800pci only enables the 2.4 Ghz > band support: >> Your device does not
Re: Ralink RT5592 5Ghz capability not working
Hey, thanks for your answer. The device definitely isn't a RT3091, so do you think it's some sort of an OEM hybrid? Do you think it would be better to report this to the openwrt bugzilla? Thanks In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto: > Alberto Mattea wrote: > > this is about the mini-pcie version used in some embedded products > > (for example the Buffalo WHR-600D and the Asus RP-N53). > > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > > (5Ghz works with the proprietary driver supplied with the devices), > > but rt2800pci seems to see only the 2.4 Ghz capability. > > As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > > > dmesg: > > > > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev > > 0222 detected [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF > > chipset 0001 detected [ 14.10] ieee80211 phy0: Selected rate > > control algorithm 'minstrel_ht' [ 134.42] ieee80211 phy0: > > rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin' [ > > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware > > detected - version: 0.34 > Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb > 2013): > > phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, rev: > 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 > detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device. > > > The weird thing is that in lspci it is reported as an RT3091, due to the > > 0x3091 pci device id: > > > > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n > > 1T/2R PCIe [1814:3091]> > > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe > > [1814:3091] > > > > [...] > > 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] > Subsystem: ASUSTeK Computer Inc. Device [1043:851a] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- > DEVSEL=fast >TAbort- SERR- Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 11 > Region 0: Memory at fe50 (32-bit, non-prefetchable) [size=64K] > Capabilities: [40] Power Management version 3 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 > DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ > Address: Data: > Capabilities: [70] Express (v2) Endpoint, MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s > <512ns, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- > ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 > bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, > L1 <64us ClockPM+ Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed > 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis+ DevCtl2: Completion > Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 2.5GT/s, > EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: > Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance > De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB, > EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, > EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] > Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- > CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ > ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ > ChkEn- Capabilities: [140 v1] Device Serial Number c1-a5-f3-ff-fe-a9-85-30 > > So maybe due to this (i'm not sure), rt2800pci only enables the 2.4 Ghz band support: > Your device does not look like a real RT5592 chip. > > > All this with kernel 3.18 (openwrt 15.05 Chaos Calmer). > > Any ideas? > > OpenWrt brings _a lot of_ code out upstream kernel. > Who knows what is running. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.or
Re: Intel 7260 - limited in 5GHz spectrum
On Tue, Nov 3, 2015 at 8:27 AM, Johannes Berg wrote: > On Tue, 2015-11-03 at 08:08 -0800, Tim Harvey wrote: >> >> Out of curiosity, can you explain what you mean about 'regulatory >> concerns'? There are channels in the 5GHz band that can be used in >> FCC >> with and without DFS. Is it that certification in the 5GHz band is >> optional and Intel didn't want to do the certification? >> > > I believe the reason is that the device is sold in countries other than > the US. Surprise! ;-) > > johannes Johannes, No surprise that its sold outside the US, but why should that mean it should exclude 5GHz support? They all have their regulatory domains and my understanding is that the intersection of the reg domain rules and card capabilities should dictate if they can operate as an AP per 5GHz channel. So I'm trying to understand why this card is dropping that capability. Thanks, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath9k: incorrect queue may be stopped/awaken
When channel context is enabled, we could be
stopping/awakening an incorrect queue.
---
drivers/net/wireless/ath/ath9k/xmit.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 3e3dac3..9b17a59 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -147,7 +147,12 @@ static void ath_txq_skb_done(struct ath_softc *sc, struct
ath_txq *txq,
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ath_frame_info *fi = get_frame_info(skb);
- int q = fi->txq;
+ int q;
+
+ if (ath9k_is_chanctx_enabled())
+ q = fi->txq;
+ else
+ q = info->hw_queue;
if (q < 0)
return;
@@ -158,10 +163,7 @@ static void ath_txq_skb_done(struct ath_softc *sc, struct
ath_txq *txq,
if (txq->stopped &&
txq->pending_frames < sc->tx.txq_max_pending[q]) {
- if (ath9k_is_chanctx_enabled())
- ieee80211_wake_queue(sc->hw, info->hw_queue);
- else
- ieee80211_wake_queue(sc->hw, q);
+ ieee80211_wake_queue(sc->hw, q);
txq->stopped = false;
}
}
@@ -2299,17 +2301,17 @@ int ath_tx_start(struct ieee80211_hw *hw, struct
sk_buff *skb,
* info are no longer valid (overwritten by the ath_frame_info data.
*/
- q = skb_get_queue_mapping(skb);
+ if (ath9k_is_chanctx_enabled())
+ q = skb_get_queue_mapping(skb);
+ else
+ q = info->hw_queue;
ath_txq_lock(sc, txq);
if (txq == sc->tx.txq_map[q]) {
fi->txq = q;
if (++txq->pending_frames > sc->tx.txq_max_pending[q] &&
!txq->stopped) {
- if (ath9k_is_chanctx_enabled())
- ieee80211_stop_queue(sc->hw, info->hw_queue);
- else
- ieee80211_stop_queue(sc->hw, q);
+ ieee80211_stop_queue(sc->hw, q);
txq->stopped = true;
}
}
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull-request: mac80211 2015-11-03
From: Johannes Berg Date: Tue, 03 Nov 2015 15:40:02 +0100 > After the travel I got a whole bunch of things in - I've sorted through > and taken the fix-like things. > > Note that this is in the mac80211 tree, but based on net-next, since I > thought you might decide to pull this in before you send a pull request > to Linus. > However, the content is only things I'd also send after -rc1 (with the > WMM stuff being a bit borderline, since it's fairly big, but it's a > huge improvement with broken APs and we've had it in our Intel tree > testing there for quite a while.) > > Let me know if you run into any problems. Pulled, thanks Johannes. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel 7260 - limited in 5GHz spectrum
On Tue, 2015-11-03 at 08:08 -0800, Tim Harvey wrote: > > Out of curiosity, can you explain what you mean about 'regulatory > concerns'? There are channels in the 5GHz band that can be used in > FCC > with and without DFS. Is it that certification in the 5GHz band is > optional and Intel didn't want to do the certification? > I believe the reason is that the device is sold in countries other than the US. Surprise! ;-) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel 7260 - limited in 5GHz spectrum
On Sat, Oct 31, 2015 at 12:12 PM, Grumbach, Emmanuel wrote: > Hi, > > On 10/30/2015 06:37 PM, Pushpal Sidhu wrote: >> Hi, >> >> I've been working with the Intel 7260 card which advertises itself as >> dual band wireless AC card. However, I cannot get it working in AP >> mode in the 5GHz range. An $(iw list) shows that the entire 5GHz band >> has 'no IR' next to it so as not to allow device radiation (please see >> pastebin here: http://pastebin.com/T4BWnBmn). >> >> After searching around the internet a bit, it seems that the card >> doesn't allow for this mode (And is thus not really dual band?). I'd >> like to know if this is a firmware limitation and if there's a fix in >> place, or if not, why is this card limited to the spectrum it can >> radiate at? >> > > > 7260 does not (and will not) support AP mode in 5GHz band. This is of > course not a hardware limitation since it can function as a station in > this band. The limitation is due to regulatory concerns. Later devices > (8260) have the ability to be an AP in 5GHz under certain circumstances. Emmanuel, Out of curiosity, can you explain what you mean about 'regulatory concerns'? There are channels in the 5GHz band that can be used in FCC with and without DFS. Is it that certification in the 5GHz band is optional and Intel didn't want to do the certification? Regards, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] offchannel: Cancel the pending_action TX wait, before starting new one.
On Mon, Nov 2, 2015 at 8:40 PM, Chaitanya T K wrote:
> From: tkc
>
> Before the tx_status is received for the action frame, if we
> get another request, we respond to that by freeing the memory
> for pending_action_tx, but we don't cancel the TX wait, so
> in the kernel the ROC will not be cancelled.
>
> Due to above issue, wpa_supplicant assumes that all pending
> RoC's are cancelled and proceeds with interface creation and
> connection, where as state in mac80211/driver will be roc_in_progress.
>
> This is leading to issues at driver level.
>
> Signed-off-by: Chaitanya T K
> ---
> V2: Fix 2 from's.
> Remove the unnecessary braces.
> ---
> wpa_supplicant/offchannel.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/wpa_supplicant/offchannel.c b/wpa_supplicant/offchannel.c
> index 6b3f83c..581c5f6 100644
> --- a/wpa_supplicant/offchannel.c
> +++ b/wpa_supplicant/offchannel.c
> @@ -253,15 +253,9 @@ int offchannel_send_action(struct wpa_supplicant *wpa_s,
> unsigned int freq,
>
> wpa_s->pending_action_tx_status_cb = tx_cb;
>
> - if (wpa_s->pending_action_tx) {
> - wpa_printf(MSG_DEBUG, "Off-channel: Dropped pending Action "
> - "frame TX to " MACSTR " (pending_action_tx=%p)",
> - MAC2STR(wpa_s->pending_action_dst),
> - wpa_s->pending_action_tx);
I think we should retain this print to identify if its a proper complete
or dropping pending. Anyways will wait for comments before sending V3.
.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Encryption problems with libertas drivers, kernel 3.18 and wpa_supplicant using wext
Hi all, I hope this is the right place to ask for help. I am experiencing problems when I try to create a IBSS netwoork with wpa_supplicant. The drivers used for the wifi hardware are the "libertas" and the wireles adapter is a Marvell WLAN 802.11. What happens is that when I create the network, it appears always as unencrypted. I cannot set any encryption key (WEP, WPA etc.) I can only connect to the IBSS network if this has been set without key. When I execute wpa_supplicant the output is: wpa_supplicant -D wext -i wlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf -dd wpa_supplicant v2.3 random: Trying to read entropy from /dev/random Successfully initialized wpa_supplicant Initializing interface 'wlan0' conf '/etc/wpa_supplicant/wpa_supplicant.conf' driver 'wext' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' -> '/etc/wpa_supplicant/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' ap_scan=1 ctrl_interface='/var/run/wpa_supplicant' Line: 3 - start of a new network block ssid - hexdump_ascii(len=8): 73 69 6d 6f 5f 6e 65 74 simo_net mode=1 (0x1) frequency=2412 (0x96c) priority=10 (0xa) key_mgmt: 0x4 wep_key0 - hexdump(len=5): [REMOVED] Priority group 10 id=0 ssid='simo_net' WEXT: cfg80211-based driver detected wext: interface wlan0 phy: phy2 rfkill: initial event: idx=1 type=2 op=0 soft=0 hard=0 rfkill: initial event: idx=3 type=1 op=0 soft=0 hard=0 SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf capabilities: key_mgmt 0xf enc 0x1f flags 0x0 netlink: Operstate: ifindex=5 linkmode=1 (userspace-control), operstate=5 (IF_OPER_DORMANT) Add interface wlan0 to a new radio phy2 wlan0: Own MAC address: xx:xx:xx:xx:xx:xx wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_countermeasures wlan0: RSN: flushing PMKID list in the driver wlan0: Setting scan request: 0.10 sec wlan0: WPS: UUID based on MAC address: 39cee858-d55e-5e3d-b589-30e2c9d32960 EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: Supplicant port status: Unauthorized EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED wlan0: Added interface wlan0 wlan0: State: DISCONNECTED -> DISCONNECTED wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) netlink: Operstate: ifindex=5 linkmode=-1 (no change), operstate=5 (IF_OPER_DORMANT) random: Got 20/20 bytes from /dev/random RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event Wireless event: cmd=0x8b06 len=8 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event Wireless event: cmd=0x8b1a len=8 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event wlan0: State: DISCONNECTED -> SCANNING wlan0: Starting AP scan for wildcard SSID wlan0: Add radio work 'scan'@0xfa450 wlan0: First radio work item in the queue - schedule start immediately wlan0: Starting radio work 'scan'@0xfa450 after 0.000122 second wait Scan requested (ret=0) - scan timeout 10 seconds EAPOL: disable timer tick RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event Wireless event: cmd=0x8b19 len=8 wlan0: Event SCAN_RESULTS (3) received Received 0 bytes of scan results (0 BSSes) wlan0: BSS: Start scan result update 1 BSS: last_scan_res_used=0/0 wlan0: New scan results available (own=0 ext=0) wlan0: Radio work 'scan'@0xfa450 done in 1.086812 seconds wlan0: No suitable network found wlan0: Setup a new network wlan0: Add radio work 'connect'@0xfa450 wlan0: First radio work item in the queue - schedule start immediately wlan0: Starting radio work 'connect'@0xfa450 after 0.000153 second wait wlan0: Trying to associate with SSID 'simo_net' wlan0: Cancelling scan request wlan0: WPA: clearing own WPA/RSN IE wlan0: Automatic auth_alg selection: 0x1 wlan0: WPA: clearing AP WPA IE wlan0: WPA: clearing AP RSN IE wlan0: WPA: clearing own WPA/RSN IE wpa_driver_wext_set_key: alg=1 key_idx=0 set_tx=1 seq_len=0 key_len=5 wlan0: State: SCANNING -> ASSOCIATING wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) netlink: Operstate: ifindex=5 linkmode=-1 (no change), operstate=5 (IF_OPER_DORMANT) wpa_driver_wext_associate wpa_driver_wext_set_drop_unencrypted ioctl[SIOCSIWGENIE]: Operation not suppor
Re: [PATCH] Revert "Staging: wilc1000: coreconfigurator: Drop unneeded wrapper functions"
On Tue, Nov 03, 2015 at 07:05:11PM +0900, Glen Lee wrote: > The addresses are not properly aglined for using ether_addr_copy function. > I revert this as author agree to drop this patch. > > This reverts commit d4622f68db8095dd54179e3134e97812727f6b89. > --- > drivers/staging/wilc1000/coreconfigurator.c | 48 > +++-- > 1 file changed, 25 insertions(+), 23 deletions(-) No signed-off-by: line :( -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull-request: mac80211 2015-11-03
Hi, After the travel I got a whole bunch of things in - I've sorted through and taken the fix-like things. Note that this is in the mac80211 tree, but based on net-next, since I thought you might decide to pull this in before you send a pull request to Linus. However, the content is only things I'd also send after -rc1 (with the WMM stuff being a bit borderline, since it's fairly big, but it's a huge improvement with broken APs and we've had it in our Intel tree testing there for quite a while.) Let me know if you run into any problems. johannes The following changes since commit e9829b9745b6e1683fd2a90842da498a2197299e: Merge tag 'mac80211-next-for-davem-2015-10-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next (2015-10-22 07:28:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2015-11-03 for you to fetch changes up to e4208427247ecc7306c8f71ab3c5c08e08cf9fda: cfg80211: allow AID/listen interval changes for unassociated station (2015-11-03 11:20:29 +0100) Another set of fixes: * remove a warning on a check that can trigger without any errors having happened (Andrei) * correctly handle deauth request while in the process of associating (Andrei) * fix TDLS HT operation (Arik) * allow changing AID/listen interval during client setup (Ayala) * be more forgiving with WMM parameters to get HT/VHT in case of broken APs with bad WMM settings (Emmanuel, myself) * a number of other fixes (some in documentation) Andrei Otcheretianski (2): mac80211: Fix local deauth while associating mac80211: Remove WARN_ON_ONCE in ieee80211_recalc_smps Arik Nemtsov (2): mac80211: allow null chandef in tracing mac80211: TDLS: add proper HT-oper IE Ayala Beker (1): cfg80211: allow AID/listen interval changes for unassociated station Chaitanya T K (1): mac80211: document sleep requirements for channel context ops Eliad Peller (3): mac80211: use freezable workqueue for restart work mac80211: call drv_stop only if driver is started mac80211: don't reconfigure sched scan in case of wowlan Emmanuel Grumbach (1): mac80211: fixup AIFSN instead of disabling WMM janusz.dzied...@tieto.com (1): mac80211: fix divide by zero when NOA update Johannes Berg (4): cfg80211/mac80211: clarify RSSI CQM reporting requirements mac80211: make enable_qos parameter to ieee80211_set_wmm_default() mac80211: treat bad WMM parameters more gracefully mac80211: further improve "no supported rates" warning Matthias Schiffer (1): mac80211: fix crash on mesh local link ID generation with VIFs Ola Olsson (1): nl80211: Fix potential memory leak from parse_acl_data include/net/cfg80211.h | 4 ++ include/net/mac80211.h | 10 ++- net/mac80211/cfg.c | 6 +- net/mac80211/driver-ops.c | 46 net/mac80211/driver-ops.h | 42 --- net/mac80211/ibss.c| 4 +- net/mac80211/ieee80211_i.h | 6 +- net/mac80211/iface.c | 8 ++- net/mac80211/main.c| 2 +- net/mac80211/mesh.c| 3 +- net/mac80211/mesh_plink.c | 3 + net/mac80211/mlme.c| 173 +++-- net/mac80211/pm.c | 11 +++ net/mac80211/rate.c| 2 +- net/mac80211/scan.c| 12 ++-- net/mac80211/tdls.c| 13 +++- net/mac80211/trace.h | 10 +-- net/mac80211/util.c| 94 ++-- net/wireless/nl80211.c | 39 ++ 19 files changed, 277 insertions(+), 211 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: NFC: nci: Create pipe on specific gate in nci_hci_connect_gate
Hello Christophe Ricard,
The patch a1b0b9415817: "NFC: nci: Create pipe on specific gate in
nci_hci_connect_gate" from Oct 25, 2015, leads to the following
static checker warning:
net/nfc/nci/hci.c:679 nci_hci_connect_gate()
warn: impossible condition '(pipe < 0) => (0-255 < 0)'
net/nfc/nci/hci.c
655 int nci_hci_connect_gate(struct nci_dev *ndev,
656 u8 dest_host, u8 dest_gate, u8 pipe)
657 {
658 bool pipe_created = false;
659 int r;
660
661 if (pipe == NCI_HCI_DO_NOT_OPEN_PIPE)
662 return 0;
663
664 if (ndev->hci_dev->gate2pipe[dest_gate] != NCI_HCI_INVALID_PIPE)
665 return -EADDRINUSE;
666
667 if (pipe != NCI_HCI_INVALID_PIPE)
668 goto open_pipe;
669
670 switch (dest_gate) {
671 case NCI_HCI_LINK_MGMT_GATE:
672 pipe = NCI_HCI_LINK_MGMT_PIPE;
673 break;
674 case NCI_HCI_ADMIN_GATE:
675 pipe = NCI_HCI_ADMIN_PIPE;
676 break;
677 default:
678 pipe = nci_hci_create_pipe(ndev, dest_host, dest_gate,
&r);
679 if (pipe < 0)
Unsigned never less than zero.
680 return r;
681 pipe_created = true;
682 break;
683 }
684
685 open_pipe:
686 r = nci_hci_open_pipe(ndev, pipe);
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NFC: nfcmrvl: fix SPI driver dependencies
The newly added nfcmrvl_spi driver uses the spi_nci
infrastructure, but does not have a Kconfig dependency on
that, so we can get a link-time error:
drivers/built-in.o: In function `nfcmrvl_spi_nci_send':
(.text+0x1428dc): undefined reference to `nci_spi_send'
drivers/built-in.o: In function `nfcmrvl_spi_probe':
(.text+0x142a24): undefined reference to `nci_spi_allocate_spi'
drivers/built-in.o: In function `nfcmrvl_spi_int_irq_thread_fn':
(.text+0x142abc): undefined reference to `nci_spi_read'
This clarifies the dependency.
Signed-off-by: Arnd Bergmann
Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
---
Found on ARM randconfig builds on yesterday's linux-next
diff --git a/drivers/nfc/nfcmrvl/Kconfig b/drivers/nfc/nfcmrvl/Kconfig
index 444ca94697d9..670af76922e0 100644
--- a/drivers/nfc/nfcmrvl/Kconfig
+++ b/drivers/nfc/nfcmrvl/Kconfig
@@ -44,7 +44,7 @@ config NFC_MRVL_I2C
config NFC_MRVL_SPI
tristate "Marvell NFC-over-SPI driver"
- depends on NFC_MRVL && SPI
+ depends on NFC_MRVL && NFC_NCI_SPI
help
Marvell NFC-over-SPI driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ralink RT5592 5Ghz capability not working
Alberto Mattea wrote: > this is about the mini-pcie version used in some embedded products > (for example the Buffalo WHR-600D and the Asus RP-N53). > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz > (5Ghz works with the proprietary driver supplied with the devices), > but rt2800pci seems to see only the 2.4 Ghz capability. As far as I know, RT5592 PCIe devices are unsupported by rt2800pci. > dmesg: > > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev > 0222 detected > [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0001 detected > [ 14.10] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' > [ 134.42] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading > firmware file 'rt2860.bin' > [ 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware > detected - version: 0.34 Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb 2013): phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, rev: 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592 detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device. > The weird thing is that in lspci it is reported as an RT3091, due to the > 0x3091 pci device id: > > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n 1T/2R > PCIe [1814:3091] > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe [1814:3091] > [...] 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592] Subsystem: ASUSTeK Computer Inc. Device [1043:851a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- So maybe due to this (i'm not sure), rt2800pci only enables the 2.4 Ghz band > support: Your device does not look like a real RT5592 chip. > All this with kernel 3.18 (openwrt 15.05 Chaos Calmer). > Any ideas? OpenWrt brings _a lot of_ code out upstream kernel. Who knows what is running. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NFC: fdp: i2c: Check for NULL prior to dereference
Dan Carpenter reported the following:
"The patch a06347c04c13: "NFC: Add Intel Fields Peak NFC solution
driver" from Oct 22, 2015, leads to the following Smatch complaint:
drivers/nfc/fdp/i2c.c:216 fdp_nci_i2c_irq_thread_fn()
warn: variable dereferenced before check 'phy' (see line 213)
drivers/nfc/fdp/i2c.c
212
213 client = phy->i2c_dev;
^
Dereference.
214 dev_dbg(&client->dev, "%s\n", __func__);
215
216 if (!phy || irq != phy->i2c_dev->irq) {
Check.
217 WARN_ON_ONCE(1);
218 return IRQ_NONE;
"
Reported-by: Dan Carpenter
Signed-off-by: Fabio Estevam
---
drivers/nfc/fdp/i2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index 532db28..a5d7332 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -210,14 +210,14 @@ static irqreturn_t fdp_nci_i2c_irq_thread_fn(int irq,
void *phy_id)
struct sk_buff *skb;
int r;
- client = phy->i2c_dev;
- dev_dbg(&client->dev, "%s\n", __func__);
-
if (!phy || irq != phy->i2c_dev->irq) {
WARN_ON_ONCE(1);
return IRQ_NONE;
}
+ client = phy->i2c_dev;
+ dev_dbg(&client->dev, "%s\n", __func__);
+
r = fdp_nci_i2c_read(phy, &skb);
if (r == -EREMOTEIO)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
re: NFC: Add Intel Fields Peak NFC solution driver
Hello Robert Dolca,
This is a semi-automatic email about new static checker warnings.
The patch a06347c04c13: "NFC: Add Intel Fields Peak NFC solution
driver" from Oct 22, 2015, leads to the following Smatch complaint:
drivers/nfc/fdp/i2c.c:216 fdp_nci_i2c_irq_thread_fn()
warn: variable dereferenced before check 'phy' (see line 213)
drivers/nfc/fdp/i2c.c
212
213 client = phy->i2c_dev;
^
Dereference.
214 dev_dbg(&client->dev, "%s\n", __func__);
215
216 if (!phy || irq != phy->i2c_dev->irq) {
Check.
217 WARN_ON_ONCE(1);
218 return IRQ_NONE;
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ralink RT5592 5Ghz capability not working
Hello, thanks for your answer. I'm completely sure the hardware supports 5Ghz: with the proprietary ralink driver it works. As you can see from the dmesg, the board actually has a RT5592, not a RT3091. So I think the board has only the pci device id of the RT3091, and that is confusing the rt2800pci driver, making it assume it is a 2.4GHz device. What do you think? Thanks In data lun 2 novembre 2015 21:51:32, Alexis Green ha scritto: > Looks like this device is BGN only (at least it is detected as such by > lspci) - https://wikidevi.com/wiki/Ralink_RT3091_Reference_Design. You'll > probably want something like this instead - > http://www.amazon.com/HP-RALINK-RT3592-Wireless-BlueTooth/dp/B00AARTZ40 > > On Mon, Nov 2, 2015 at 1:39 PM, Alberto Mattea wrote: > > Hello, > > this is about the mini-pcie version used in some embedded products (for > > example the Buffalo WHR-600D and the Asus RP-N53). > > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz (5Ghz > > works with the proprietary driver supplied with the devices), but > > rt2800pci > > seems to see only the 2.4 Ghz capability. > > > > dmesg: > > > > [ 14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev > > 0222 detected > > [ 14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0001 > > detected > > [ 14.10] ieee80211 phy0: Selected rate control algorithm > > 'minstrel_ht' > > [ 134.42] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading > > firmware file 'rt2860.bin' > > [ 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware > > detected - version: 0.34 > > > > The weird thing is that in lspci it is reported as an RT3091, due to the > > 0x3091 pci device id: > > > > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n > > 1T/2R PCIe [1814:3091] > > > > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe > > > > [1814:3091] > > > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > > > ParErr- Stepping- SERR- FastB2B- DisINTx- > > > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > > > > SERR- > > > Latency: 0, Cache Line Size: 80 bytes > > Interrupt: pin A routed to IRQ 4 > > Region 0: Memory at 2000 (32-bit, non-prefetchable) [size=64K] > > Region 1: Memory at (32-bit, non-prefetchable) > > > > [size=2] > > > > Region 2: Memory at (32-bit, non-prefetchable) > > > > [size=2] > > > > Region 3: Memory at (32-bit, non-prefetchable) > > > > [size=2] > > > > Region 4: Memory at (32-bit, non-prefetchable) > > > > [size=2] > > > > Region 5: Memory at (32-bit, non-prefetchable) > > > > [size=2] > > > > Expansion ROM at [disabled] [size=2] > > Capabilities: [40] Power Management version 3 > > > > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > > > > PME(D0+,D1-,D2-,D3hot+,D3cold-) > > > > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+ > > > > Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ > > > > Address: Data: > > > > Capabilities: [70] Express (v2) Endpoint, MSI 00 > > > > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s > > > > unlimited, L1 unlimited > > > > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > > > > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- > > > > Unsupported- > > > > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- > > MaxPayload 128 bytes, MaxReadReq 512 bytes > > > > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- > > > > TransPend- > > > > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, > > > > Exit Latency L0s <512ns, L1 <64us > > > > ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- > > > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- > > > > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > > > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > > > > DLActive- BWMgmt- ABWMgmt- > > > > DevCap2: Completion Timeout: Not Supported, TimeoutDis+, > > > > LTR-, OBFF Not Supported > > > > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, > > > > LTR-, OBFF Disabled > > > > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- > > > > SpeedDis- > > > > Transmit Margin: Normal Operating Range, > > > > EnterModifiedCompliance- ComplianceSOS- > > > > Compliance De-emphasis: -6dB > > > > LnkSta2: Current De-emphasis Level: -6d
Re: [PATCH] iw: Fix memory leak if nla_put fails
On Sat, 2015-10-24 at 00:33 +0200, Ola Olsson wrote: > The NLA_PUT macro will automatically goto nla_put_failure if > the underlying nla_put fails. This will in turn leak our malloced > memory in both the scan and wowlan commands. > Fix that by not using the macro in the cases where we have > allocated heap mem. > Applied, thanks. Luckily the tool just exits right away so we don't have to care all that much :) But of course it's still good to fix it since people can (and do) copy it into other code. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: Enable update of properties for unassociated station.
On Fri, 2015-10-23 at 11:20 +0300, Emmanuel Grumbach wrote: > From: Ayala Beker > > Currently, cfg80211 rejects updates of AID and listen interval > parameters > for existing entries. This information is known only at association > stage, > and as a result it's impossible to update entries that were added > unassociated. > Fix this by allowing updates of these properies for stations that the > driver (or mac80211) assigned unassociated state. > Applied. Does the feature work completely with this patch? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Handle sleep requirements for channel context ops.
On Fri, 2015-10-30 at 23:16 +0530, Chaitanya T K wrote: > From: Chaitanya T K > > Channel context OPs can sleep, so add might_sleep() and > also document sleep requirements for those OPs. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Revert "Staging: wilc1000: coreconfigurator: Drop unneeded wrapper functions"
The addresses are not properly aglined for using ether_addr_copy function.
I revert this as author agree to drop this patch.
This reverts commit d4622f68db8095dd54179e3134e97812727f6b89.
---
drivers/staging/wilc1000/coreconfigurator.c | 48 +++--
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 1caa66e..954b5eb 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -13,12 +13,8 @@
#include "wilc_wlan.h"
#include
#include
-#include
#define TAG_PARAM_OFFSET (MAC_HDR_LEN + TIME_STAMP_LEN + \
BEACON_INTERVAL_LEN +
CAP_INFO_LEN)
-#define ADDR1 4
-#define ADDR2 10
-#define ADDR3 16
/* Basic Frame Type Codes (2-bit) */
enum basic_frame_type {
@@ -175,32 +171,38 @@ static inline u8 get_from_ds(u8 *header)
return ((header[1] & 0x02) >> 1);
}
+/* This function extracts the MAC Address in 'address1' field of the MAC */
+/* header and updates the MAC Address in the allocated 'addr' variable. */
+static inline void get_address1(u8 *pu8msa, u8 *addr)
+{
+ memcpy(addr, pu8msa + 4, 6);
+}
+
+/* This function extracts the MAC Address in 'address2' field of the MAC */
+/* header and updates the MAC Address in the allocated 'addr' variable. */
+static inline void get_address2(u8 *pu8msa, u8 *addr)
+{
+ memcpy(addr, pu8msa + 10, 6);
+}
+
+/* This function extracts the MAC Address in 'address3' field of the MAC */
+/* header and updates the MAC Address in the allocated 'addr' variable. */
+static inline void get_address3(u8 *pu8msa, u8 *addr)
+{
+ memcpy(addr, pu8msa + 16, 6);
+}
+
/* This function extracts the BSSID from the incoming WLAN packet based on */
-/* the 'from ds' bit, and updates the MAC Address in the allocated 'data'*/
+/* the 'from ds' bit, and updates the MAC Address in the allocated 'addr'*/
/* variable. */
static inline void get_BSSID(u8 *data, u8 *bssid)
{
if (get_from_ds(data) == 1)
- /*
-* Extract the MAC Address in 'address2' field of the MAC
-* header and update the MAC Address in the allocated 'data'
-* variable.
-*/
- ether_addr_copy(data, bssid + ADDR2);
+ get_address2(data, bssid);
else if (get_to_ds(data) == 1)
- /*
-* Extract the MAC Address in 'address1' field of the MAC
-* header and update the MAC Address in the allocated 'data'
-* variable.
-*/
- ether_addr_copy(data, bssid + ADDR1);
+ get_address1(data, bssid);
else
- /*
-* Extract the MAC Address in 'address3' field of the MAC
-* header and update the MAC Address in the allocated 'data'
-* variable.
-*/
- ether_addr_copy(data, bssid + ADDR3);
+ get_address3(data, bssid);
}
/* This function extracts the SSID from a beacon/probe response frame*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] mac80211: TDLS: add proper HT-oper IE
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Arik Nemtsov > > When 11n peers performs a TDLS connection on a legacy BSS, the HT > operation IE must be specified according to IEEE802.11-2012 section > 9.23.3.2. Otherwise HT-protection is compromised and the medium > becomes > noisy for both the TDLS and the BSS links. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] mac80211: call drv_stop only if driver is started
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Eliad Peller > > If drv_start() fails during hw_restart, all the running > interfaces are being closed/stopped, which results in > drv_stop() being called, although the driver was never > started successfully. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix crash on mesh local link ID generation with VIFs
On Sat, 2015-10-24 at 21:25 +0200, Matthias Schiffer wrote: > llid_in_use needs to be limited to stations of the same VIF, > otherwise it > will cause a NULL deref as the sta_info of non-mesh-VIFs don't have > sta->mesh set. > Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] mac80211: don't reconfigure sched scan in case of wowlan
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Eliad Peller > > Scheduled scan has to be reconfigured only if wowlan wasn't > configured, since otherwise it should continue to run (with > the 'any' trigger) or be aborted. > > The current code will end up asking the driver to start a new > scheduled scan without stopping the previous one, and leaking > some memory (from the previous request.) > > Fix this by doing the abort/restart under the proper conditions. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] ath10k: replace vdev_id and tid in skb cb
On 2 November 2015 at 15:03, Michal Kazior wrote: > This prepares the driver for future ieee80211_txq > and wake_tx_queue() support. I think I've found a regression and bisect blames this patch. Do not apply this yet, please. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mac80211: Remove WARN_ON_ONCE in ieee80211_recalc_smps
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Andrei Otcheretianski > > The recalc_smps work can run after the station disassociates. > At this stage we already released the channel, but the work > will be cancelled only when the interface stops. > In this scenario we can hit the warning in ieee80211_recalc_smps, so > just remove it. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] mac80211: allow null chandef in tracing
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Arik Nemtsov > > In TDLS channel-switch operations the chandef can sometimes be NULL. > Avoid an oops in the trace code for these cases and just print a > chandef full of zeros. > Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/14] mac80211: fix divide by zero when NOA update
On Tue, 2015-10-27 at 08:35 +0100, Janusz Dziedzic wrote: > In case of one shot NOA the interval could be 0. > Applied, thanks! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] mac80211: use freezable workqueue for restart work
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Eliad Peller > > Requesting hw restart during suspend might result > in the restart work being executed after mac80211 > and the hw are suspended. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] mac80211: Fix local deauth while associating
On Sun, 2015-10-25 at 10:59 +0200, Emmanuel Grumbach wrote: > From: Andrei Otcheretianski > > Local request to deauthenticate wasn't handled while associating, > thus > the association could continue even when the user space required to > disconnect. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: Fix potential memory leak from parse_acl_data
On Thu, 2015-10-29 at 07:04 +0100, Ola Olsson wrote: > If parse_acl_data succeeds but the subsequent parsing of smps > attributes fails, there will be a memory leak due to early returns. > Fix that. > Applied, thanks! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the patch "Staging: wilc1000: coreconfigurator: Drop unneeded wrapper functions"
Hi Shivani, I will revert as you said, I always appreciate all the effort and your time to help. Regards, glen lee. On 2015년 11월 03일 17:26, Shivani Bhardwaj wrote: On Mon, Nov 2, 2015 at 7:13 AM, glen lee wrote: Hi Shivani Bhardwaj, Thank you for the patches. I am writing this new mail thread since I didn't received about following patch which is applied recently. https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/patch/drivers/staging/wilc1000?id=d4622f68db8095dd54179e3134e97812727f6b89 I have tested this on hardware but it did not working. As far as I know, ether_addr_copy function can be used when src and dst addresss are __aligned(2) and it has to be proved. Would you let us know the addresses are properly aligned? I cannot make sure the data is aligned(2). Hi Glen, Thanks for pointing out. I checked it. The alignment is wrong. Please drop this patch. I'm really sorry for the inconvenience caused. I'll make sure to send a new patch with correct alignment. Thank you Shivani Regards, glen lee. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the patch "Staging: wilc1000: coreconfigurator: Drop unneeded wrapper functions"
On Mon, Nov 2, 2015 at 7:13 AM, glen lee wrote: > Hi Shivani Bhardwaj, > > Thank you for the patches. > > I am writing this new mail thread since I didn't received about following > patch which is applied recently. > > https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/patch/drivers/staging/wilc1000?id=d4622f68db8095dd54179e3134e97812727f6b89 > > I have tested this on hardware but it did not working. > As far as I know, ether_addr_copy function can be used when src and dst > addresss are __aligned(2) and it has to be proved. > Would you let us know the addresses are properly aligned? I cannot make sure > the data is aligned(2). Hi Glen, Thanks for pointing out. I checked it. The alignment is wrong. Please drop this patch. I'm really sorry for the inconvenience caused. I'll make sure to send a new patch with correct alignment. Thank you Shivani > > Regards, > glen lee. > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
