* [PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0
From: Arnd Bergmann @ 2016-07-20 15:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev, Jes Sorensen,
devel, linux-kernel, Arnd Bergmann
In-Reply-To: <20160720152606.201775-1-arnd@arndb.de>
There is one remaining warning about a type limit check in rtl8192e:
staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits]
This changes a macro into a local function to clarify the types and simplify
the check while removing the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/rtl8192e/rtl819x_Qos.h | 3 ---
drivers/staging/rtl8192e/rtl819x_TSProc.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_Qos.h b/drivers/staging/rtl8192e/rtl819x_Qos.h
index 463122db6d29..61da8f7475bb 100644
--- a/drivers/staging/rtl8192e/rtl819x_Qos.h
+++ b/drivers/staging/rtl8192e/rtl819x_Qos.h
@@ -169,9 +169,6 @@ union qos_tclas {
} TYPE2_8021Q;
};
-#define IsACValid(ac) ((ac >= 0 && ac <= 7) ? true : false)
-
-
union aci_aifsn {
u8 charData;
diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c
index 2c8a526773ed..a966a8e490ab 100644
--- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
@@ -306,6 +306,11 @@ static void MakeTSEntry(struct ts_common_info *pTsCommonInfo, u8 *Addr,
pTsCommonInfo->TClasNum = TCLAS_Num;
}
+static bool IsACValid(unsigned int tid)
+{
+ return tid < 7;
+}
+
bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
u8 *Addr, u8 TID, enum tr_select TxRxSelect, bool bAddNewTs)
{
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Arnd Bergmann @ 2016-07-20 15:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev, Jes Sorensen,
devel, linux-kernel, Arnd Bergmann
In-Reply-To: <20160720151818.4142386-1-arnd@arndb.de>
Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.
staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/r8192E_phy.c:1104:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/rtl_core.c:1987:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtl8192e/rtl_dm.c:782:37: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192e/rtllib_softmac_wx.c:465:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8 ++++----
drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +-
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++---
drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 8 ++++----
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index ba64a4f1b3a8..8d6bca61e7aa 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -1487,8 +1487,8 @@ static void _rtl92e_query_rxphystatus(
struct phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
- char rx_pwr[4], rx_pwr_all = 0;
- char rx_snrX, rx_evmX;
+ s8 rx_pwr[4], rx_pwr_all = 0;
+ s8 rx_snrX, rx_evmX;
u8 evm, pwdb_all;
u32 RSSI, total_rssi = 0;
u8 is_cck_rate = 0;
@@ -1613,7 +1613,7 @@ static void _rtl92e_query_rxphystatus(
2) - 110;
tmp_rxsnr = pofdm_buf->rxsnr_X[i];
- rx_snrX = (char)(tmp_rxsnr);
+ rx_snrX = (s8)(tmp_rxsnr);
rx_snrX /= 2;
priv->stats.rxSNRdB[i] = (long)rx_snrX;
@@ -1643,7 +1643,7 @@ static void _rtl92e_query_rxphystatus(
for (i = 0; i < max_spatial_stream; i++) {
tmp_rxevm = pofdm_buf->rxevm_X[i];
- rx_evmX = (char)(tmp_rxevm);
+ rx_evmX = (s8)(tmp_rxevm);
rx_evmX /= 2;
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
index 5e3bbe5c3ca4..0698131e4300 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
@@ -630,7 +630,7 @@ void rtl92e_set_tx_power(struct net_device *dev, u8 channel)
{
struct r8192_priv *priv = rtllib_priv(dev);
u8 powerlevel = 0, powerlevelOFDM24G = 0;
- char ant_pwr_diff;
+ s8 ant_pwr_diff;
u32 u4RegValue;
if (priv->epromtype == EEPROM_93C46) {
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 13a5ddc2bea5..41e05f206300 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1982,7 +1982,7 @@ void rtl92e_update_rx_statistics(struct r8192_priv *priv,
weighting) / 6;
}
-u8 rtl92e_rx_db_to_percent(char antpower)
+u8 rtl92e_rx_db_to_percent(s8 antpower)
{
if ((antpower <= -100) || (antpower >= 20))
return 0;
@@ -1993,9 +1993,9 @@ u8 rtl92e_rx_db_to_percent(char antpower)
} /* QueryRxPwrPercentage */
-u8 rtl92e_evm_db_to_percent(char value)
+u8 rtl92e_evm_db_to_percent(s8 value)
{
- char ret_val;
+ s8 ret_val;
ret_val = value;
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
index f627fdc15a58..6921125c9d35 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h
@@ -503,8 +503,8 @@ struct r8192_priv {
u32 Pwr_Track;
u8 CCKPresentAttentuation_20Mdefault;
u8 CCKPresentAttentuation_40Mdefault;
- char CCKPresentAttentuation_difference;
- char CCKPresentAttentuation;
+ s8 CCKPresentAttentuation_difference;
+ s8 CCKPresentAttentuation;
long undecorated_smoothed_pwdb;
u32 MCSTxPowerLevelOriginalOffset[6];
@@ -604,8 +604,8 @@ void rtl92e_update_rx_pkt_timestamp(struct net_device *dev,
long rtl92e_translate_to_dbm(struct r8192_priv *priv, u8 signal_strength_index);
void rtl92e_update_rx_statistics(struct r8192_priv *priv,
struct rtllib_rx_stats *pprevious_stats);
-u8 rtl92e_evm_db_to_percent(char value);
-u8 rtl92e_rx_db_to_percent(char antpower);
+u8 rtl92e_evm_db_to_percent(s8 value);
+u8 rtl92e_rx_db_to_percent(s8 antpower);
void rtl92e_copy_mpdu_stats(struct rtllib_rx_stats *psrc_stats,
struct rtllib_rx_stats *ptarget_stats);
bool rtl92e_enable_nic(struct net_device *dev);
--
2.9.0
^ permalink raw reply related
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Toke Høiland-Jørgensen @ 2016-07-20 15:24 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <87oa5snzav.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@toke.dk> writes:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> - if I put a hack in the fq code to force the hash to a constant value
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>
> There's definitely something iffy about the hashing. Here's the output
> relevant line from the aqm debug file after running a single TCP stream
> for 60 seconds to that station:
>
> ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit collisions
> tx-bytes tx-packets
> wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925
>
> (there are two extra fields here; I added per-txq CoDel stats, will send
> a patch later).
>
> This shows that the txq has 146 flows associated from that one TCP flow.
> Looking at this over time, it seems that each time the queue runs empty
> (which happens way too often, which is what I was originally
> investigating), another flow is assigned.
>
> Michal, any idea why? :)
And to answer this: because the flow is being freed to be reassigned
when it runs empty, but the counter is not decremented. Is this
deliberate? I.e. is the 'flows' var supposed to be a total 'new_flows'
counter and not a measure of the current number of assigned flows?
-Toke
^ permalink raw reply
* [PATCH 1/3] staging/rtl8192u: use s8 instead of char
From: Arnd Bergmann @ 2016-07-20 15:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev, Jes Sorensen,
Arnd Bergmann, devel, linux-kernel
Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
incorrect code that results from 'char' being unsigned here, e.g.
staging/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192u/r8192U_dm.c:646:50: error: comparison is always false due to limited range of data type [-Werror=type-limits]
This patch changes all uses of 'char' in this driver that refer to
8-bit integers to use 's8' instead, which is signed on all architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 ++--
drivers/staging/rtl8192u/r8192U.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 14 +++++++-------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 09e9499b7f9d..077ea13eb1e7 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -746,7 +746,7 @@ struct ieee80211_rx_stats {
bool bisrxaggrsubframe;
bool bPacketBeacon; //cosa add for rssi
bool bToSelfBA; //cosa add for rssi
- char cck_adc_pwdb[4]; //cosa add for rx path selection
+ s8 cck_adc_pwdb[4]; //cosa add for rx path selection
u16 Seq_Num;
};
@@ -1814,7 +1814,7 @@ struct ieee80211_device {
u32 wpax_type_notify; //{added by David, 2006.9.26}
/* QoS related flag */
- char init_wmmparam_flag;
+ s8 init_wmmparam_flag;
/* set on initialization */
u8 qos_support;
diff --git a/drivers/staging/rtl8192u/r8192U.h b/drivers/staging/rtl8192u/r8192U.h
index 5dba6a28dd9b..b28bc7812caa 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -533,7 +533,7 @@ typedef struct _rt_9x_tx_rate_history {
u32 ht_mcs[4][16];
} rt_tx_rahis_t, *prt_tx_rahis_t;
typedef struct _RT_SMOOTH_DATA_4RF {
- char elements[4][100]; /* array to store values */
+ s8 elements[4][100]; /* array to store values */
u32 index; /* index to current array to store */
u32 TotalNum; /* num of valid elements */
u32 TotalVal[4]; /* sum of valid elements */
@@ -1031,7 +1031,7 @@ typedef struct r8192_priv {
s8 cck_present_attentuation;
u8 cck_present_attentuation_20Mdefault;
u8 cck_present_attentuation_40Mdefault;
- char cck_present_attentuation_difference;
+ s8 cck_present_attentuation_difference;
bool btxpower_tracking;
bool bcck_in_ch14;
bool btxpowerdata_readfromEEPORM;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index dd0970facdf5..f36b2d3b1ee9 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4209,7 +4209,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv *priv, u8 *buffer,
*
* Return: 0-100 percentage
*---------------------------------------------------------------------------*/
-static u8 rtl819x_query_rxpwrpercentage(char antpower)
+static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
{
if ((antpower <= -100) || (antpower >= 20))
return 0;
@@ -4220,9 +4220,9 @@ static u8 rtl819x_query_rxpwrpercentage(char antpower)
} /* QueryRxPwrPercentage */
-static u8 rtl819x_evm_dbtopercentage(char value)
+static u8 rtl819x_evm_dbtopercentage(s8 value)
{
- char ret_val;
+ s8 ret_val;
ret_val = value;
@@ -4297,8 +4297,8 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc;
u8 *prxpkt;
u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg;
- char rx_pwr[4], rx_pwr_all = 0;
- char rx_snrX, rx_evmX;
+ s8 rx_pwr[4], rx_pwr_all = 0;
+ s8 rx_snrX, rx_evmX;
u8 evm, pwdb_all;
u32 RSSI, total_rssi = 0;
u8 is_cck_rate = 0;
@@ -4423,7 +4423,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
/* Get Rx snr value in DB */
tmp_rxsnr = pofdm_buf->rxsnr_X[i];
- rx_snrX = (char)(tmp_rxsnr);
+ rx_snrX = (s8)(tmp_rxsnr);
rx_snrX /= 2;
priv->stats.rxSNRdB[i] = (long)rx_snrX;
@@ -4457,7 +4457,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
for (i = 0; i < max_spatial_stream; i++) {
tmp_rxevm = pofdm_buf->rxevm_X[i];
- rx_evmX = (char)(tmp_rxevm);
+ rx_evmX = (s8)(tmp_rxevm);
/* Do not use shift operation like "rx_evmX >>= 1"
* because the compiler of free build environment will
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Arnd Bergmann @ 2016-07-20 15:12 UTC (permalink / raw)
To: Jes Sorensen
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel,
Andrea Merello
In-Reply-To: <wrfjlh0wsg9s.fsf@redhat.com>
On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> >> I'd like to get rid of all the drivers/staging/rtl* drivers eventually
> >
> > That would be great, yes.
> >
> > Can you clarify what the long-term plan is? I see that
> > drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
> > and one USB device (rtl8192cu/rtl8188cus) while
> > drivers/net/wireless/rtl8xxx has all the USB parts including
> > that one.
> >
> > Does that mean we want the staging drivers for PCIe devices
> > to get merged into rtlwifi, and the remaining USB drivers to get
> > replaced by r8xxxu?
>
> Well it really all depends on how much time I have and how much others
> step up and help contribute to the code. For rtl8xxxu my plans are as
> follows:
>
> 1) rtl8188eu support, since this is the most widely distributed USB
> dongle which isn't currently supported by a non staging driver. I am
> currently working on this together with Andrea Merello.
Ok, cool.
> 2) Beacon support for IBSS and AP mode - hopefully this should make it
> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
> them in rtlwifi.
Do we have any indication that those two actually work in rtlwifi at the
moment? My experience seems to match the recommendations for all the
raspberry pi users that use yet another (worse looking) driver:
https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56
> 3) SDIO device support
>
> 4) PCI device support
>
> 5) 802.11ac device support
>
> 3/4/5 not necessarily in that order. There really is no reason why
> rtl8xxxu shouldn't have SDIO and PCI device support added so the core
> code can be shared.
Ok, got it.
> > As one data point that I can provide (but you are probably
> > aware of), I could never get my rtl8188cus stick to work with
> > rtlwifi, but I found the older r8712u device to work fine with
> > the staging/rtl8712 driver.
>
> I'd love to hear if the rtl8188cus works better with rtl8xxxu.
It took me far too long to get the driver running on my machine (all my fault),
but I've tested it now. Unfortunately there is something very wrong
with my home wireless network at the moment, so I can only confirm
that it doesn't work any worse than my Intel Wireless card on 2.4GHz,
but that isn't any good (5GHz devices are fine, but that doesn't
help on a 2.4GHz-only device).
This is what I see in the kernel log
[ 773.862848] usb 2-1.2: new high-speed USB device number 8 using ehci-pci
[ 773.957415] usb 2-1.2: New USB device found, idVendor=0bda, idProduct=8176
[ 773.957425] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 773.957430] usb 2-1.2: Manufacturer: Realtek
[ 773.957433] usb 2-1.2: SerialNumber: 00e04c000001
[ 774.115182] usb 2-1.2: Vendor: Realtek
[ 774.115192] usb 2-1.2: Product:
[ 774.115199] usb 2-1.2: rtl8192cu_parse_efuse: dumping efuse (0x80 bytes):
[ 774.115206] usb 2-1.2: 00: 29 81 00 74 ed 00 00 00
[ 774.115212] usb 2-1.2: 08: ff 00 da 0b 76 81 01 41
[ 774.115219] usb 2-1.2: 10: 32 00 85 62 7e ad 5c f3
[ 774.115225] usb 2-1.2: 18: 70 15 9c b1 0a 03 52 65
[ 774.115231] usb 2-1.2: 20: 61 6c 74 65 6b 00 02 03
[ 774.115237] usb 2-1.2: 28: 00 00 00 00 00 00 00 00
[ 774.115242] usb 2-1.2: 30: 00 00 00 00 00 00 00 00
[ 774.115248] usb 2-1.2: 38: 00 00 00 00 00 00 00 00
[ 774.115254] usb 2-1.2: 40: 00 00 00 00 00 00 00 00
[ 774.115260] usb 2-1.2: 48: 00 00 00 00 00 00 00 00
[ 774.115265] usb 2-1.2: 50: 00 00 00 00 00 00 00 00
[ 774.115271] usb 2-1.2: 58: 06 00 2a 2a 2a 00 00 00
[ 774.115277] usb 2-1.2: 60: 2a 2a 2a 00 00 00 00 00
[ 774.115283] usb 2-1.2: 68: 00 00 00 00 04 04 04 00
[ 774.115289] usb 2-1.2: 70: 00 00 00 00 00 00 05 00
[ 774.115295] usb 2-1.2: 78: 10 00 00 00 36 00 00 00
[ 774.115302] usb 2-1.2: RTL8188CU rev A (TSMC) 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[ 774.115308] usb 2-1.2: RTL8188CU MAC: 5c:f3:70:15:9c:b1
[ 774.115314] usb 2-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 774.115409] usb 2-1.2: Firmware revision 80.0 (signature 0x88c1)
[ 775.692344] rtl8xxxu 2-1.2:1.0 wlan1: renamed from wlan0
[ 775.721151] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 775.746653] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 775.798780] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 788.414618] wlan2: authenticate with 22:4e:7f:6f:5b:3c
[ 788.452485] wlan2: send auth to 22:4e:7f:6f:5b:3c (try 1/3)
[ 788.457926] wlan2: authenticated
[ 788.462261] wlan2: associate with 22:4e:7f:6f:5b:3c (try 1/3)
[ 788.475159] wlan2: RX AssocResp from 22:4e:7f:6f:5b:3c (capab=0x431 status=0 aid=1)
[ 788.504683] wlan2: associated
throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets
5mbit/s on the same network, but I guess that doesn't really mean much
as long as I have problems with the infrastructure.
rtl8xxxu IEEE 802.11 ESSID:"openwrt24-ab"
Mode:Managed Frequency:2.462 GHz Access Point: 22:4E:7F:6F:5B:3C
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr=2347 B Fragment thr:off
Power Management:off
Link Quality=47/70 Signal level=-63 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:38 Missed beacon:0
iwlwifi IEEE 802.11 ESSID:"openwrt24-ab"
Mode:Managed Frequency:2.462 GHz Access Point: 22:4E:7F:6F:5B:3C
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=65/70 Signal level=-45 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:90 Invalid misc:146 Missed beacon:0
> For the rtl8712 device, rtl8192su?, then potentially that could be added to
> rtl8xxxu as well, but it's not a top priority on my list right now.
This one:
Bus 001 Device 033: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter
I bought the rtl8188su a while ago, while the rtl8188cus (0bda:8176)
is from this year. According to https://wikidevi.com/wiki/Realtek, it
seems to be one year older than the rtl8188cus and was almost as common
in its day. Apparently everyone that used to make ...su device replaced it
with a ...cu or the newer ...eu chips and that is all you can buy these days
on the low end.
Arnd
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Xose Vazquez Perez @ 2016-07-20 15:06 UTC (permalink / raw)
To: linux-wireless, netdev, LKML,
driverdev-devel@linuxdriverproject.org, Jes Sorensen,
Christian Lamparter, Larry Finger, Arnd Bergmann
Arnd Bergmann <arnd@arndb.de> wrote:
> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.
A replacement for "staging/rtl8712", with MAC80211 support, is
available at: https://github.com/chunkeey/rtl8192su
Also a fullmac/cfg80211 driver(r92su) is available at the
same repository.
^ permalink raw reply
* [PATCH] mac80211: Keep CoDel stats per txq, export them in debugfs.
From: Toke Høiland-Jørgensen @ 2016-07-20 14:54 UTC (permalink / raw)
To: make-wifi-fast, linux-wireless
Cc: Toke Høiland-Jørgensen, Michal Kazior
Currently the 'aqm' stats in mac80211 only keeps overlimit drop stats,
not CoDel stats. This moves the CoDel stats into the txqi structure and
adds the drop and mark counts to the debug output.
Cc: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
net/mac80211/debugfs.c | 12 ++++++++----
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/tx.c | 4 ++--
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 27e6fb9..69bf2e5 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -137,18 +137,20 @@ static int aqm_open(struct inode *inode, struct file *file)
len += scnprintf(info->buf + len,
info->size - len,
"* vif\n"
- "ifname addr ac backlog-bytes backlog-packets flows overlimit collisions tx-bytes tx-packets\n");
+ "ifname addr ac backlog-bytes backlog-packets flows drops marks overlimit collisions tx-bytes tx-packets\n");
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
txqi = to_txq_info(sdata->vif.txq);
len += scnprintf(info->buf + len, info->size - len,
- "%s %pM %u %u %u %u %u %u %u %u\n",
+ "%s %pM %u %u %u %u %u %u %u %u %u %u\n",
sdata->name,
sdata->vif.addr,
txqi->txq.ac,
txqi->tin.backlog_bytes,
txqi->tin.backlog_packets,
txqi->tin.flows,
+ txqi->cstats.drop_count,
+ txqi->cstats.ecn_mark,
txqi->tin.overlimit,
txqi->tin.collisions,
txqi->tin.tx_bytes,
@@ -158,14 +160,14 @@ static int aqm_open(struct inode *inode, struct file *file)
len += scnprintf(info->buf + len,
info->size - len,
"* sta\n"
- "ifname addr tid ac backlog-bytes backlog-packets flows overlimit collisions tx-bytes tx-packets\n");
+ "ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit collisions tx-bytes tx-packets\n");
list_for_each_entry_rcu(sta, &local->sta_list, list) {
sdata = sta->sdata;
for (i = 0; i < ARRAY_SIZE(sta->sta.txq); i++) {
txqi = to_txq_info(sta->sta.txq[i]);
len += scnprintf(info->buf + len, info->size - len,
- "%s %pM %d %d %u %u %u %u %u %u %u\n",
+ "%s %pM %d %d %u %u %u %u %u %u %u %u %u\n",
sdata->name,
sta->sta.addr,
txqi->txq.tid,
@@ -173,6 +175,8 @@ static int aqm_open(struct inode *inode, struct file *file)
txqi->tin.backlog_bytes,
txqi->tin.backlog_packets,
txqi->tin.flows,
+ txqi->cstats.drop_count,
+ txqi->cstats.ecn_mark,
txqi->tin.overlimit,
txqi->tin.collisions,
txqi->tin.tx_bytes,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c9f8c80..9f11b13 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -812,6 +812,7 @@ struct txq_info {
struct fq_tin tin;
struct fq_flow def_flow;
struct codel_vars def_cvars;
+ struct codel_stats cstats;
unsigned long flags;
/* keep last! */
@@ -1106,7 +1107,6 @@ struct ieee80211_local {
struct fq fq;
struct codel_vars *cvars;
struct codel_params cparams;
- struct codel_stats cstats;
const struct ieee80211_ops *ops;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 682011e..201167d 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1339,7 +1339,7 @@ static struct sk_buff *fq_tin_dequeue_func(struct fq *fq,
local = container_of(fq, struct ieee80211_local, fq);
txqi = container_of(tin, struct txq_info, tin);
cparams = &local->cparams;
- cstats = &local->cstats;
+ cstats = &txqi->cstats;
if (flow == &txqi->def_flow)
cvars = &txqi->def_cvars;
@@ -1399,6 +1399,7 @@ void ieee80211_txq_init(struct ieee80211_sub_if_data *sdata,
fq_tin_init(&txqi->tin);
fq_flow_init(&txqi->def_flow);
codel_vars_init(&txqi->def_cvars);
+ codel_stats_init(&txqi->cstats);
txqi->txq.vif = &sdata->vif;
@@ -1437,7 +1438,6 @@ int ieee80211_txq_setup_flows(struct ieee80211_local *local)
return ret;
codel_params_init(&local->cparams);
- codel_stats_init(&local->cstats);
local->cparams.interval = MS2TIME(100);
local->cparams.target = MS2TIME(20);
local->cparams.ecn = true;
--
2.9.0
^ permalink raw reply related
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Toke Høiland-Jørgensen @ 2016-07-20 14:45 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <11fa6d16-21e2-2169-8d18-940f6dc11dca@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> - if I put a hack in the fq code to force the hash to a constant value
> (effectively disabling fq without disabling codel), the problem
> disappears and even multiple streams get proper performance.
There's definitely something iffy about the hashing. Here's the output
relevant line from the aqm debug file after running a single TCP stream
for 60 seconds to that station:
ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit collisions
tx-bytes tx-packets
wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925
(there are two extra fields here; I added per-txq CoDel stats, will send
a patch later).
This shows that the txq has 146 flows associated from that one TCP flow.
Looking at this over time, it seems that each time the queue runs empty
(which happens way too often, which is what I was originally
investigating), another flow is assigned.
Michal, any idea why? :)
-Toke
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Larry Finger @ 2016-07-20 14:25 UTC (permalink / raw)
To: Jes Sorensen, Arnd Bergmann
Cc: linux-wireless, Kalle Valo, netdev, Greg Kroah-Hartman,
Mateusz Kulikowski, devel, linux-kernel, Andrea Merello
In-Reply-To: <wrfjlh0wsg9s.fsf@redhat.com>
On 07/20/2016 06:25 AM, Jes Sorensen wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>> I think that would be better, albeit not a big issue.
>>
>> Ok, and since Kalle applied the first patch to his tree, I'm now sending
>> a series of three patches that are all for Greg, which also avoids some
>> possible confusion.
>
> Awesome!
>
>>> I'd like to get rid of all the drivers/staging/rtl* drivers eventually
>>
>> That would be great, yes.
>>
>> Can you clarify what the long-term plan is? I see that
>> drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
>> and one USB device (rtl8192cu/rtl8188cus) while
>> drivers/net/wireless/rtl8xxx has all the USB parts including
>> that one.
>>
>> Does that mean we want the staging drivers for PCIe devices
>> to get merged into rtlwifi, and the remaining USB drivers to get
>> replaced by r8xxxu?
>
> Well it really all depends on how much time I have and how much others
> step up and help contribute to the code. For rtl8xxxu my plans are as
> follows:
>
> 1) rtl8188eu support, since this is the most widely distributed USB
> dongle which isn't currently supported by a non staging driver. I am
> currently working on this together with Andrea Merello.
>
> 2) Beacon support for IBSS and AP mode - hopefully this should make it
> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
> them in rtlwifi.
>
> 3) SDIO device support
>
> 4) PCI device support
>
> 5) 802.11ac device support
>
> 3/4/5 not necessarily in that order. There really is no reason why
> rtl8xxxu shouldn't have SDIO and PCI device support added so the core
> code can be shared.
>
>> As one data point that I can provide (but you are probably
>> aware of), I could never get my rtl8188cus stick to work with
>> rtlwifi, but I found the older r8712u device to work fine with
>> the staging/rtl8712 driver.
>
> I'd love to hear if the rtl8188cus works better with rtl8xxxu. For the
> rtl8712 device, rtl8192su?, then potentially that could be added to
> rtl8xxxu as well, but it's not a top priority on my list right now.
I would be very pleased to eliminate all the rtl* drivers from staging,
particularly the USB varieties. I have been very disappointed with the USB group
at Realtek. They dropped rtl8192cu on me, and then have provided no support. As
I know nothing of the chip internals, there has been little I could do to
improve the driver. In addition, they have never implemented any of the code
improvements in any new USB drivers. Jes has done a wonderful job of making
sense of the crap drivers from Realtek, and rtl8xxxu is a very good start.
Adding SDIO support for the RTL8723BS would be a plus. At the moment, there is
only an out-of-tree driver at GitHub, which I refuse to submit to staging. At
the moment, it appears that every tablet with this chip needs special treatment.
In addition, the SDIO support seems to be buggy.
The drivers in question and my comments are as follows:
rtl8712u and rtl8188eu - replaced by new code in rtl8xxxu.
rtl8723au - already in rtl8xxxu
rtl8192e - This chip is so rarely used that it does not make much difference
what we do. If someone wants to integrate it into rtlwifi, I would have no
objection, but I do not expect to contribute to the effort.
rtl8192u - This one is even rarer. I have no sample, thus I would be unable to test.
rtl8192cu - Replace with rtl8xxxu as soon as the new driver supports beacons.
Good riddance.
Larry
^ permalink raw reply
* Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
From: Luana Borgia @ 2016-07-20 13:23 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: Nestor Machno, linux-wireless@vger.kernel.org
In-Reply-To: <efa3441022124e74af56753a70041eee@SC-EXCH04.marvell.com>
Hi Amitkumar,
any news about this issue? I've the same problem also..
Security a part, we can't leave the WIFI open or just with WEP because
we get too many not trusted connection that consume a lot of our
bandwidth
Thanks, regards
Luana
2016-07-08 11:15 GMT+02:00 Amitkumar Karwar <akarwar@marvell.com>:
>> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] On Behalf Of Nestor Machno
>> Sent: Thursday, July 07, 2016 6:07 AM
>> To: linux-wireless@vger.kernel.org
>> Subject: Fwd: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC
>>
>> Hi All,
>> Amitkumar, can you confirm if this this is a bug or today is fixed?
>
> Yes. This is a bug in our firmware. ADHOC in WPA/WPA2 security is broken. We have asked firmware experts to look into this. As we have a mid-year shutdown this week, they will be able to check the problem next week only. However ADHOC in open mode should work as expected
>
>>
>> Vincent, I had also faced similar issue on Surface Pro 2 with backports
>> from 4.1... So here few question:
>>
>> * I saw in 1st post that you where working to make work the
>> wpa_supplicant with mixed configuration for adhoc (wpa-none + wpa-ibss),
>> but also in recent post that you focus mostly on debugging wpa-ibss. I
>> suggest to focus your test on one wpa mode and I think wpa-none better
>> because it's easier..
>> * Why you are not testing the latest backport from upstream kernel? as
>> you can know Marvell is focus most to fix open issue on current stable
>> release, I saw from commit that recently they fix something about WPA on
>> mixflex, see
>> https://backports.wiki.kernel.org/index.php/Documentation/compat-
>> drivers/hacking
>> * Would be good information to know if you tested also on backport 3.x,
>> did you? I know mwifiex's WPA stack changed a lot from 3.x kernel.
>> * To support you more, could you enable debug info and provide full log
>> of your setup? .config? patch? anything else?
>> * Can you share us your hacked backport?
>> * Lat question Vincent, are you working for AIRBUS, ACTIA or THALES ?
>> :)
>>
>> Best Regards
>> Nestor
>>
>> On Mon, Jun 13, 2016 at 7:42 AM, Vincent CESSON
>> <vincent.cesson@smile.fr> wrote:
>> > Hi Amitkumar,
>> >
>> > Here are the wpa_supplicant logs (with CONFIG_IBSS_RSN=y enabled) from
>> > the two devices. Beside wpa_supplicant, I manually set IPs
>> > 192.168.1.xy with command "ifconfig mlan0 192.168.1.xy" and then I try
>> > to ping each other, without success.
>> >
>
> Regards,
> Amitkumar
^ permalink raw reply
* RE: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Undekari, Sunil Dutt @ 2016-07-20 13:15 UTC (permalink / raw)
To: Johannes Berg, Arend Van Spriel, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath
In-Reply-To: <1468869757.2944.6.camel@sipsolutions.net>
PkFoLCBoZWguIFllcywgSSB0aGluayB0aGlzIGlzIGV4YWN0bHkgdGhlIHVzZSBjYXNlIHRoZXkg
aGF2ZSBpbiBtaW5kLg0KPkVhY2ggb2YgdGhlIG11bHRpcGxlIEJTU2VzIGlzIHJlcHJlc2VudGVk
IGJ5IGl0cyBvd24gQVAgdHlwZSB2aXJ0dWFsIGludGVyZmFjZS4NClllcyAuIFRoaXMgaXMgdGhl
IHJlcXVpcmVtZW50IHdlIGFyZSB0YXJnZXRpbmcgLiBUaGUgdXNlIGNhc2UgaXMgYWxzbyB0byBo
YXZlIGRpZmZlcmVudCBiZWFjb24gaW50ZXJ2YWwgZm9yIHRoZXNlIFZBUCdzIGFuZCBoZW5jZSB0
aGlzIHBhdGNoLiANClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIHBhdGNoIHdpdGggdHlwbyBh
ZGRyZXNzZWQgdG8gImRpZmZlcmVudCIgaXMgYWNjZXB0YWJsZS4gU2hhbGwgcmFpc2UgYW5vdGhl
ciBwYXRjaCBzZXQgYWNjb3JkaW5nbHkuIA0KDQpSZWdhcmRzLA0KU3VuaWwNCg0K
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later
From: Michal Kazior @ 2016-07-20 12:22 UTC (permalink / raw)
To: Shajakhan, Mohammed Shafi (Mohammed Shafi)
Cc: Mohammed Shafi, Mohammed Shafi Shajakhan,
ath10k@lists.infradead.org, linux-wireless, Raja, Tamizh Chelvam
In-Reply-To: <900ae7541c5a4194a2f73479e1dd8bb2@aphydexm01b.ap.qualcomm.com>
On 20 July 2016 at 13:43, Shajakhan, Mohammed Shafi (Mohammed Shafi)
<mohammed@qti.qualcomm.com> wrote:
> Michal,
>
> Can you please let me know if this change is fine or not ?
> I am waiting infinitely for your reply long time
Sorry. I was absent for a while and this email slipped by.
Quoting your other email:
> is this patch is good to go (or) should i re-work ?
> I had replied to Michal's comment of introducing a new firmware
> feature flag will not address the issue in older firmware / code.
> Let me know if i had missed something very obvious.
I couldn't really find any conclusion to this thread in my inbox.
The hw_params approach is definitely wrong. The ACK problem is
firmware-specific, not hardware-specific.
I'm fine with removing the workaround completely if 636 is guaranteed
to not be broken, including AP and P2P GO operation. The client
operation will probably work since wmi-roam event is used for HW
connection monitoring.
Nullfunc tx-status ack/noack reports could be probably fixed up using
sta kickout events (with short timeouts) as a fallback. This would
make it easier for users because otherwise they'd need to enable
disassoc_low_ack in hostapd (which is probably impossible with
wpa_supplicant for p2p, no?).
Michał
^ permalink raw reply
* RE: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Machani, Yaniv @ 2016-07-20 12:15 UTC (permalink / raw)
To: Yeoh Chun-Yeow
Cc: Bob Copeland, linux-wireless@vger.kernel.org, Hahn, Maital,
Johannes Berg
In-Reply-To: <CAEFj986LZ8zjBtyJrRL4GX3S-yTGxL-MJs3S18ze-NNw544OPQ@mail.gmail.com>
T24gV2VkLCBKdWwgMjAsIDIwMTYgYXQgMDk6NDU6MTYsIFllb2ggQ2h1bi1ZZW93IHdyb3RlOg0K
PiBKb2hhbm5lcyBCZXJnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMi8zXSBtYWM4MDIxMTog
bWVzaDogaW1wcm92ZSBwYXRoIHJlc29sdmluZyANCj4gdGltZQ0KPiANCj4gT24gV2VkLCBKdWwg
MjAsIDIwMTYgYXQgNDowMSBBTSwgTWFjaGFuaSwgWWFuaXYgPHlhbml2bWFAdGkuY29tPiB3cm90
ZToNCj4gPiBPbiBUdWUsIEp1bCAxOSwgMjAxNiBhdCAxOTowMTo1NCwgWWVvaCBDaHVuLVllb3cg
d3JvdGU6DQo+ID4+IEpvaGFubmVzIEJlcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAy
LzNdIG1hYzgwMjExOiBtZXNoOiBpbXByb3ZlIHBhdGggcmVzb2x2aW5nIA0KPiA+PiB0aW1lDQo+
ID4+DQo+ID4+IE9uIFR1ZSwgSnVsIDE5LCAyMDE2IGF0IDk6NDMgUE0sIEJvYiBDb3BlbGFuZCA8
bWVAYm9iY29wZWxhbmQuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4gPiBPbiBUdWUsIEp1bCAxOSwg
MjAxNiBhdCAwMTowMjoxM1BNICswMDAwLCBNYWNoYW5pLCBZYW5pdiB3cm90ZToNCj4gPj4gPj4g
T24gVHVlLCBKdWwgMTksIDIwMTYgYXQgMTU6NDQ6NTYsIEJvYiBDb3BlbGFuZCB3cm90ZToNCj4g
Pj4gPg0KPiA+PiA+IFRoaXMgd29yZGluZyBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIG5v
dCBwZXIgcGF0aC4gIFBlcmhhcHMgDQo+ID4+ID4gdGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGlu
IHRoZSBzdGFuZGFyZC4gIChJZiB0aGUgaW50ZW50IHR1cm5zIA0KPiA+PiA+IG91dCB0byBiZSBw
ZXIgcGF0aCwgdGhlbiBJIGd1ZXNzIHdlIHNob3VsZCBmaXggaXQgYnkgc3RvcmluZyANCj4gPj4g
PiBsYXN0X3ByZXEgcGVyIHBhdGgNCj4gPj4gPiBpbnN0ZWFkLikNCj4gPj4gPg0KPiA+PiA+DQo+
ID4+ID4gSWdub3JpbmcgdGhlIHN0YW5kYXJkIGZvciBhIHNlY29uZCwgbGV0J3MgZXhwbG9yZSB0
aGlzOiBjYW4geW91IA0KPiA+PiA+IGdpdmUgc29tZSBpZGVhIG9uIGhvdyBtYW55IHN0YXRpb25z
IGFyZSBpbiB5b3VyIHRhcmdldCBuZXR3b3JrLCANCj4gPj4gPiBob3cgZnJlcXVlbnRseSBhIGdp
dmVuIHBhaXIgb2Ygbm9kZXMgdW5wZWVyLCB3aGF0IHNvcnQgb2YgDQo+ID4+ID4gaW1wcm92ZW1l
bnRzIHlvdSBzZWUgd2l0aCB0aGUgcGF0Y2g/ICBJdCBzaG91bGQgdGhlbiBiZSBwcmV0dHkgDQo+
ID4+ID4gZWFzeSB0byBydW4gc29tZSBzaW11bGF0aW9ucyB0byBzZWUgdGhlIHNjZW5hcmlvcyB3
aGVyZSB0aGlzIGhlbHBzIGFuZCB3aGVyZSBpdCBodXJ0cy4NCj4gPj4gPg0KPiA+Pg0KPiA+DQo+
ID4gQm9iLCBDaHVuLVllb3csDQo+ID4gVGhhbmtzIGZvciB5b3VyIGlucHV0cy4NCj4gPg0KPiA+
IExldCB0YWtlIGEgc2ltcGxlIHNjZW5hcmlvLCB3aGVyZSB5b3UgaGF2ZSBhLGIsYyxkIG5vZGVz
IGNvbm5lY3RlZCANCj4gPiB0byBlYWNoDQo+IG90aGVyIGFzIHNob3duIGJlbG93Lg0KPiA+DQo+
ID4gQX4gfiB+fn5+Qy0gLSAtIEQNCj4gPiAgICBcICAgICAgICAgIC8NCj4gPiAgICAgICBcICAg
ICAvDQo+ID4gICAgICAgICAgQg0KPiA+DQo+ID4gQSB3b3VsZCBsaWtlIHRvIHBhc3MgZGF0YSB0
byBELg0KPiA+IEEtQyBtYXRyaWMgaXMgd29yc2UgdGhhbiBBLUItQywgc28gcGF0aCBpcyBjb25z
dHJ1Y3RlZCB2aWEgQi4NCj4gPiBXZSBhcmUgaW4gaWRsZSBzdGF0ZSwgYW5kIFBSRVEgYXJlIHNl
bnQgZXZlcnkNCj4gZG90MTFNZXNoSFdNUHByZXFNaW5JbnRlcnZhbC4NCj4gPiBOb3csIG5vZGUg
QiBoYXZlIGJlZW4gZGlzY29ubmVjdGVkIChyYW4gb3V0IG9mIGJhdHRlcnkvc2h1dCANCj4gPiBk
b3duL3N1ZGRlbmx5IHdlbnQgb3V0IG9mIHJhbmdlKSBBcyBBIGhhcyBhIHBhdGggdG8gRCB2aWEg
QiwgaGUgDQo+ID4gY2xlYW5zIHVwIGhpcw0KPiBwYXRoIHRhYmxlLg0KPiA+IE5vdyBoZSBuZWVk
cyB0byBidWlsZCBhIG5ldyBwYXRoLCBpbiB0aGUgV0NTLCBoZSBoYXZlIGp1c3Qgc2VudCBhIFBS
RVEuDQo+ID4gQW5kIG5vdyBoZSBuZWVkcyB0byB3YWl0IGRvdDExTWVzaEhXTVBwcmVxTWluSW50
ZXJ2YWwgc2Vjb25kcywgdW50aWwNCj4gaGUgY2FuIHJlYnVpbGQgdGhlIHBhdGguDQo+IA0KPiBE
aWQgeW91IHJlZHVjZSB0aGUgZG90MTFNZXNoSFdNUGFjdGl2ZVBhdGhUaW1lb3V0IHRvIHNlZSB3
aGV0aGVyIGl0IA0KPiBwcm9kdWNlcyBwb3NpdGl2ZSBpbXBhY3QgdG8geW91ciBuZXR3b3JrPyBP
bmNlIHRoZSBwYXRoIHRvIEEgLSBDIC0gRCANCj4gaGFzIGVzdGFibGlzaGVkLCBpdCBuZWVkcyB0
byB3YWl0IHRpbGwgdGhlIGFjdGl2ZSBwYXRoIHRpbWVyIHRvIGV4cGlyZSANCj4gYmVmb3JlIGVz
dGFibGlzaGluZyBhIG5ldyBwYXRoLiBUaGlzIGFjdGl2ZSBwYXRoIHRpbWUgaXMgZGVmYXVsdCB0
bw0KPiA1MDAwIFRVcyAob3IgNXMpLg0KPiANCg0KV2UgZGlkIHRyaWVkIGl0IGFzIHdlbGwsIGJ1
dCBhZ2FpbiwgdGhpcyB3aWxsIGNhdXNlIHVzIHNlbmRpbmcgUFJFUSBtb3JlIGZyZXF1ZW50bHku
DQoNCj4gPiBBcyB3ZSB3b3VsZG4ndCBsaWtlIHRvIGZsb29kIHRoZSBuZXR3b3JrIHdpdGggUFJF
USwgd2UgY2FuIGFzc3VtZSANCj4gPiB0aGF0IHRoZQ0KPiBkb3QxMU1lc2hIV01QcHJlcU1pbklu
dGVydmFsIGlzIGZldyBzZWNvbmRzLCBmb3IgdXMsIGl0IHNlZW1lZCB1bi0gDQo+IGFjY2VwdGFi
bGUuDQo+ID4NCj4gDQo+IEJ1dCB5b3VyIHBhdGNoIGlzIGluZGVlZCBnZW5lcmF0aW5nICJtb3Jl
IiBQUkVRIGZyYW1lLg0KPg0KV2VsbCwgd2UgYXJlIHNlbmRpbmcgbW9yZSwgYnV0IGp1c3QgaW4g
YSBzcGVjaWZpYyBzY2VuYXJpbyB3aGVyZSBpdCdzIG5lZWRlZCBBU0FQIHRvIGVzdGFibGlzaCBh
IHBhdGguDQogDQo+ID4gSW4gY2FzZXMgd2hlcmUgeW91IG5lZWQgdG8gaGF2ZSBhIHJlbGlhYmxl
IGRhdGEgbGluaywgcGFzc2luZyANCj4gPiBhdWRpby92aWRlbyB5b3UNCj4gdXN1YWxseSBjYW4n
dCBhZmZvcmQgZmV3IHNlY29uZHMgdy9vIHRyYWZmaWMuDQo+ID4NCj4gPj4gSW4gYWRkaXRpb24g
dG8gQm9iJ3MgY29tbWVudCwgeW91IHByb2JhYmx5IGNhbiB0cnkgdG8gcmVkdWNlIHRoZSANCj4g
Pj4gZG90MTFNZXNoSFdNUHByZXFNaW5JbnRlcnZhbCB0byAxIFRVICgxbXMpIGluc3RlYWQgb2Yg
c3RpY2tpbmcgdG8gDQo+ID4+IGRlZmF1bHQgdmFsdWUgMTAgVFVzLiBCZXNpZGVzLCB5b3UgY2Fu
IGFsc28gcmVkdWNlIHRoZSANCj4gPj4gbWVzaF9wYXRoX3JlZnJlc2hfdGltZSB3aGljaCBpcyBj
dXJyZW50bHkgZGVmYXVsdCB0byAxMDAwIG1zIGFuZCANCj4gPj4gY2hlY2sgd2hldGhlciB5b3Ug
Y2FuIGltcHJvdmUgb24geW91ciBuZXR3b3JrIHNjZW5hcmlvcy4NCj4gPj4NCj4gPg0KPiA+IFdl
IGRpZCB0cmllZCB0byBwbGF5IHdpdGggdGhlc2UgdmFsdWVzLCBidXQgYWdhaW4sIHdlIGRvbid0
IHdhbnQgdG8gDQo+ID4gZmxvb2QgdGhlDQo+IG5ldHdvcmsuDQo+ID4gV2UganVzdCB3YW50IHRv
IHJlY292ZXIgQVNBUC4NCj4gPg0KPiA+PiBXaGVuIHlvdSBtZW50aW9uZWQgIm5leHQgaG9wIHBl
ZXIgZGlzY29ubmVjdCIsIGl0IGNvdWxkIGFsc28gYmUgdGhlIA0KPiA+PiB0aW1lIHRha2VuIHRv
IHJlLWVzdGFibGlzaGVkIHRoZSBtZXNoIHBlZXJpbmcgYmVmb3JlIHlvdXIgbWVzaCBTVEEgDQo+
ID4+IGNhbiB0cmFuc21pdCB0aGUgZGF0YSB0byB5b3VyIHBlZXIgbWVzaCBTVEEuDQo+ID4+DQo+
ID4NCj4gPiBMaW5rIGVzdGFibGlzaG1lbnQgdGFrZXMgbm8gbW9yZSB0aGFuIGZldyAxMDBzIG9m
IG1zIHVzdWFsbHksIEFuZCBpbiANCj4gPiB0aGUgZXhhbXBsZSBhYm92ZSwgdGhlcmUgaXMgbm8g
bmV3IGxpbmsgZXN0YWJsaXNobWVudCwganVzdCBwYXRoIGdlbmVyYXRpb24uDQo+ID4NCj4gDQo+
IFN1Z2dlc3QgdGhhdCB5b3Ugc2ltdWxhdGUgeW91ciBzY2VuYXJpbyBhbmQgdmFsaWRhdGUgdGhl
IGltcHJvdmVtZW50IGZpcnN0Lg0KPiANCg0KV2UgaGF2ZSBtYWRlIG1hbnkgbGFiIHRlc3RzLCB3
aXRoIDEwcyBvZiBub2RlcyBpbiBvcGVuIGFpciBhbmQgaW4gYSBjb250cm9sbGVkIGVudmlyb25t
ZW50Lg0KVGhpcyBwYXRjaCBpcyBqdXN0IG9uZSBvZiB0aGUgaW1wcm92ZW1lbnRzIHdlIHNhdyBu
ZWNlc3NhcnkgZm9yIHBlcmZvcm1hbmNlLCB3ZSBoYXZlIG11bHRpcGxlIG90aGVycyBmb3IgdGhl
IG1ldHJpYyBjYWxjdWxhdGlvbiwgYW5kIG1vcmUuIA0KV2UgdW5kZXJzdGFuZCB0aGF0IHRoZSBI
V01QIGFuZCB0aGUgZ2VuZXJhbCBtZXNoIGltcGxlbWVudGF0aW9uIGlzIG1vcmUgc2Vuc29yIG5l
dHdvcmsgcmVsYXRlZCwgd2hlcmUgdGhlcmUgaXMgbm8gbmVlZCBmb3Igc3RhYmxlIGhpZ2ggdGhy
b3VnaHB1dCAxMDAlIG9mIHRoZSB0aW1lLg0KWW91IGNhbiBhbHNvIGhhdmUgYSBsb29rIGluIG91
ciB3aGl0ZSBwYXBlciwgZGVzY3JpYmluZyBzbWFsbCBwYXJ0cyBvZiB0aGUgdGVzdHMgd2UgaGF2
ZSBtYWRlIGluIHRoZSBsYXN0IHNlY3Rpb24gLSBodHRwOi8vd3d3LnRpLmNvbS9saXQvd3Avc3dy
eTAyNC9zd3J5MDI0LnBkZg0KDQpUaGFua3MsDQpZYW5pdg0KDQo=
^ permalink raw reply
* [RESEND PATCH v4] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later
From: Mohammed Shafi Shajakhan @ 2016-07-20 12:10 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan,
Tamizh chelvam
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
NULL func status (always acked/successs !!) when hostapd does a
PROBE_CLIENT via nullfunc frames when the station is powered off
abruptly (inactive timer probes client via null func after the inactive
time reaches beyond the threshold). Fix this by disabling the workaround
introduced by the change ("ath10k: fix beacon loss handling ") for
QCA99X0 and later chipsets. The normal tx path provides the proper
status for NULL data frames. As of now disable this workaround for
chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
completely get rid of this workaround for all the chipsets
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 3 +++
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dcc76b6..8687aaa 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+ .disable_null_func_workaround = true,
},
},
{
@@ -204,6 +205,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+ .disable_null_func_workaround = true,
},
},
{
@@ -262,6 +264,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+ .disable_null_func_workaround = true,
},
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3da18c9..d3dfda0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -750,6 +750,7 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
+ bool disable_null_func_workaround;
} fw;
} hw_params;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d4b7a16..f1e9672 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3236,6 +3236,7 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
* mode though because AP don't sleep.
*/
if (ar->htt.target_version_major < 3 &&
+ !ar->hw_params.fw.disable_null_func_workaround &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
ar->running_fw->fw_file.fw_features))
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Bob Copeland @ 2016-07-20 11:44 UTC (permalink / raw)
To: Masashi Honma; +Cc: johannes, linux-wireless, j
In-Reply-To: <1a324d4c-9a6b-1c0d-c18d-2df207de708c@gmail.com>
On Wed, Jul 20, 2016 at 04:11:33PM +0900, Masashi Honma wrote:
> On 2016年07月19日 19:40, Bob Copeland wrote:
> >
> >OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in
> >ieee80211_mps_sta_status_update(), or does the node completely repeer?
> >
> >ISTR running into a problem where rebooted peer (previously in power-save)
> >would send popen but we would buffer the response due to stale PS sta
> >flag.
[...]
>
> So looks no problem.
Ok, thanks for testing that - fwiw original patch
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH] staging: rtl8723au: hal: check BT_Active and BT_State with correct bit pattern
From: Jes Sorensen @ 2016-07-20 11:36 UTC (permalink / raw)
To: Colin King
Cc: Larry Finger, Greg Kroah-Hartman, Bhaktipriya Shridhar,
Bhumika Goyal, Amitoj Kaur Chawla, Shivani Bhardwaj,
Daniil Leshchev, Ksenija Stanojevic, linux-wireless, devel,
linux-kernel
In-Reply-To: <1468491688-17225-1-git-send-email-colin.king@canonical.com>
Colin King <colin.king@canonical.com> writes:
> From: Colin Ian King <colin.king@canonical.com>
>
> BT_Active and BT_State are being masked with 0x00ffffff so it the subsequent
> comparisons with 0xffffffff are therefore a buggy check. Instead, check them
> against 0x00ffffff.
>
> Unfortunately I couldn't find a datasheet or hardware to see if 0xffffffff
> is an expected invalid bit pattern that should be checked before BT_Active and
> BT_State are masked with 0x00ffffff, so for now, this fix seems like the least
> risky approach.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I don't really know about the BT parts here, since I never did anything
with that part of the chip. Larry probably knows more.
The only question is whether fixing this bug changes behavior that has
unexpected side effects?
Cheers,
Jes
>
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
> index bfcbd7a..6989580 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
> @@ -9824,7 +9824,7 @@ void BTDM_CheckBTIdleChange1Ant(struct rtw_adapter *padapter)
> BT_Polling = rtl8723au_read32(padapter, regBTPolling);
> RTPRINT(FBT, BT_TRACE, ("[DM][BT], BT_Polling(0x%x) =%x\n", regBTPolling, BT_Polling));
>
> - if (BT_Active == 0xffffffff && BT_State == 0xffffffff && BT_Polling == 0xffffffff)
> + if (BT_Active == 0x00ffffff && BT_State == 0x00ffffff && BT_Polling == 0xffffffff)
> return;
> if (BT_Polling == 0)
> return;
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Jes Sorensen @ 2016-07-20 11:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel,
Andrea Merello
In-Reply-To: <4806848.QL77nxBrs4@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> I think that would be better, albeit not a big issue.
>
> Ok, and since Kalle applied the first patch to his tree, I'm now sending
> a series of three patches that are all for Greg, which also avoids some
> possible confusion.
Awesome!
>> I'd like to get rid of all the drivers/staging/rtl* drivers eventually
>
> That would be great, yes.
>
> Can you clarify what the long-term plan is? I see that
> drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
> and one USB device (rtl8192cu/rtl8188cus) while
> drivers/net/wireless/rtl8xxx has all the USB parts including
> that one.
>
> Does that mean we want the staging drivers for PCIe devices
> to get merged into rtlwifi, and the remaining USB drivers to get
> replaced by r8xxxu?
Well it really all depends on how much time I have and how much others
step up and help contribute to the code. For rtl8xxxu my plans are as
follows:
1) rtl8188eu support, since this is the most widely distributed USB
dongle which isn't currently supported by a non staging driver. I am
currently working on this together with Andrea Merello.
2) Beacon support for IBSS and AP mode - hopefully this should make it
possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable
them in rtlwifi.
3) SDIO device support
4) PCI device support
5) 802.11ac device support
3/4/5 not necessarily in that order. There really is no reason why
rtl8xxxu shouldn't have SDIO and PCI device support added so the core
code can be shared.
> As one data point that I can provide (but you are probably
> aware of), I could never get my rtl8188cus stick to work with
> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.
I'd love to hear if the rtl8188cus works better with rtl8xxxu. For the
rtl8712 device, rtl8192su?, then potentially that could be added to
rtl8xxxu as well, but it's not a top priority on my list right now.
Cheers,
Jes
^ permalink raw reply
* Re: ath10k + iw set bitrates is causing FW crash
From: Krishna Chaitanya @ 2016-07-20 10:52 UTC (permalink / raw)
To: Manoharan, Rajkumar; +Cc: linux-wireless, ath10k
In-Reply-To: <CABPxzYJPi4CqO+KUFA7=r=zpq_c2vFtrgBQ+nF_nThO-cYrteg@mail.gmail.com>
On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
>
> On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
> > On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar
> > <rmanohar@qti.qualcomm.com> wrote:
> >> I think security failures are due to peer unmap & map upon reassoc. Can you please try below change?
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> >> index 5e1cc8f4c43c..f7f04bb46fc8 100644
> >> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >> @@ -5745,8 +5745,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
> >> sta->addr, smps, err);
> >> }
> >>
> >> - if (changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> - changed & IEEE80211_RC_NSS_CHANGED) {
> >> + if ((changed & IEEE80211_RC_SUPP_RATES_CHANGED ||
> >> + changed & IEEE80211_RC_NSS_CHANGED) &&
> >> + (arvif->vif->type == NL80211_IFTYPE_ADHOC)) {
> >> ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n",
> >> sta->addr);
> >
> > Bottom posting please. I have tried your change i still see the same issue.
> > Right after connecting i see that packets are encrypted but once it
> > unset/set "bitrates" plain packets are seen in sniffer.
> >
> > BTW, i am not rebooting for each driver update, just re-inserting the module,
> > do i need to do a reboot for each driver change?
>
> After reboot i dont see the "unencrypted" packet issue, i will do
> some more testing on limiting the rates, currently in my setup its
> not reaching MCS9 so cannot verify now.
>
> Thanks for the fixes and prompt reply.
>
> ________________________________________
> >> From: Krishna Chaitanya <chaitanya.mgit@gmail.com>
> >> Sent: Friday, July 8, 2016 5:26 PM
> >> To: Manoharan, Rajkumar
> >> Cc: linux-wireless; ath10k
> >> Subject: Re: ath10k + iw set bitrates is causing FW crash
> >>
> >> On Fri, Jul 8, 2016 at 3:39 PM, Manoharan, Rajkumar
> >> <rmanohar@qti.qualcomm.com> wrote:
> >>>>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use
> >>>>> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7).
> >>>>>
> >>>>> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL
> >>>>> no crash is observed but it still uses MCS9.
> >>>>>
> >>>>> tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339
> >>>>>
> >>>>> 1) If i disable HW_RATE_CONTROL, will ath10k honor
> >>>>> the mac80211 rates?
> >>>>>
> >>>>
> >>> Thanks for reporting the issue. Could you please try with below change?
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> >>> index 5e1cc8f4c43c..cfa7e01a6103 100644
> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >>> @@ -2812,6 +2812,9 @@ static int ath10k_station_assoc(struct ath10k *ar,
> >>> return ret;
> >>> }
> >>>
> >>> + if (vif->type != NL80211_IFTYPE_ADHOC)
> >>> + peer_arg.peer_reassoc = reassoc;
> >>> +
> >>> ret = ath10k_wmi_peer_assoc(ar, &peer_arg);
> >>> if (ret) {
> >>> ath10k_warn(ar, "failed to run peer assoc for STA %pM vdev %i: %d\n",
> >>
> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> >> seeing 0-9, so its
> >> working.
> >>
> >> But i am seeing a weird issues, the moment i give bitrates command,
> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> >> interface up/down
> >> it doesn't work.
Rajkumar,
I am still not able to make mcs9 work, so i have tried to change the Nss to 1
using iw, but that is not taking affect. This command is not taking effect.
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-20 9:53 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <CANXHH3k4x1QWY9H4n=hDeLmVMxdi4HOuVxHTv1ztX0AhZF7B-Q@mail.gmail.com>
Just following up from my previous email:
I am actually setting the reg domain using: iw reg set GB (copy/pasted
the IN from elsewhere - oops!)
As for progress, however, I have tried the following:
- setting the debug level to 0xfffffff. This still produces no
additional output even with 8 set in printk.
- removing the v9 firmware - same result as before - system fully locks up.
- disabling ipv6 - gets rid of IPv6 interface not up warning but
that’s not causing any problems and this didn’t make any difference.
It doesn’t seem to matter what I try at the moment - all attempts to
connect result in the system crashing which I guess is better than it
just asking me for a password over and over - it looks like it is
attempting association at this point which is good but I don’t know
why the box is crashing out and dmesg -w doesn’t show any additional
output before the freeze.
If anyone has any more ideas I would be more than happy to try them!
Thanks for the help so far Dan!
Christopher Williamson
On 19 July 2016 at 18:41:34, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> So I’ve now disabled IPv6 and have set the GB (Great Britain) regulation code using:
>
> iw reg set IN
>
> Now when I try to connect to the network using wicd the system seems to crash - I guess at least it’s doing something more than just asking for the password again like it did with NetworkManager but so far no further progress on getting this working properly.
>
> Christopher Williamson
>
>
>
> On 19 July 2016 at 18:03:16, Christopher Williamson (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> > Absolutely!
> >
> > With the debug logging enabled I got the following:
> >
> > Connecting the device initially with debug enabled:
> >
> > [ 205.302685] libertas_sdio: Libertas SDIO driver
> > [ 205.302698] libertas_sdio: Copyright Pierre Ossman
> > [ 205.503465] cfg80211: World regulatory domain updated:
> > [ 205.503478] cfg80211: DFS Master region: unset
> > [ 205.503483] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> > [ 205.503492] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> > [ 205.503499] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> > [ 205.503505] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
> > [ 205.503513] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
> > [ 205.503522] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
> > [ 205.503529] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
> > [ 205.503535] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
> > [ 205.503542] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
> > [ 212.249171] gma500 0000:00:02.0: Backlight lvds set brightness 7a127a12
> > [ 212.324898] mmc1: new SDIO card at address 0001
> > [ 212.921672] libertas_sdio mmc1:0001:1 (unnamed net_device) (uninitialized): 00:02:78:69:49:94, fw 9.70.20p0, cap 0x00000303
> > [ 212.925774] libertas_sdio mmc1:0001:1 (unnamed net_device) (uninitialized): PREP_CMD: command 0x00a3 failed: 2
> > [ 212.936190] libertas_sdio mmc1:0001:1 wlan0: Marvell WLAN 802.11 adapter
> > [ 213.053612] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >
> >
> > Strangely when I attempt to connect to the WiFi network I’m using the only error I get is:
> >
> > [ 338.076632] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >
> > I was expecting more output and am guessing I’ve missed something here.
> >
> > Christopher Williamson
> >
> > On 19 July 2016 at 17:38:35, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> >
> > > On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote:
> > > > Hi everyone!
> > > >
> > > > I’ve just got myself a Viliv N5 and am trying to get the integrated
> > > > Wifi chipset working on it.
> > > >
> > > > I am able to see networks around me but any attempts to connect them
> > > > appear to time out and fail.
> > > >
> > > > I have filed a linux kernel bug related to this issue:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=135421goo
> > > >
> > > > I figured here may be a good place to ask about it and hopefully to
> > > > get to the bottom of why it happens and how I can help to fix it.
> > > >
> > > > Happy to provide any information which may be helpful! :)
> > >
> > > Can you reload the driver stack:
> > >
> > > rmmod libertas_sdio
> > > rmmod libertas
> > > modprobe libertas libertas_debug=0x251e7ff
> > > modprobe libertas_sdio
> > >
> > > and then reproduce the issue? The debug info should dump to 'dmesg'
> > > and may tell us what's going on.
> > >
> > > Dan
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Arnd Bergmann @ 2016-07-20 8:25 UTC (permalink / raw)
To: Jes Sorensen
Cc: linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel
In-Reply-To: <wrfjlh0xvck3.fsf@redhat.com>
On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote:
> >> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> >> > index 2c8a526773ed..e0a2fe5e6148 100644
> >> > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
> >> > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
> >> > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
> >> > if (ieee->current_network.qos_data.supported == 0) {
> >> > UP = 0;
> >> > } else {
> >> > - if (!IsACValid(TID)) {
> >> > + if (!IsACValid((s8)TID)) {
> >> > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
> >> > __func__, TID);
> >> > return false;
> >>
> >> TID is a 4-bit field, it should never go negative. The cast to s8 seems
> >> wrong to me, if anything it should be using u8. I do realize the macro
> >> IsACValid checks against negative too, but that just looks silly to me.
> >
> > Ok, I'll remove the extra comparison then to avoid the warning:
> >
> > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always
> > true due to limited range of data type [-Werror=type-limits]
> >
> > I guess it should be a separate patch. I had just stumbled over the
> > same thing before resending the patch but decided not to change it
> > to keep the patch simple.
>
> I think that would be better, albeit not a big issue.
Ok, and since Kalle applied the first patch to his tree, I'm now sending
a series of three patches that are all for Greg, which also avoids some
possible confusion.
> I'd like to get rid of all the drivers/staging/rtl* drivers eventually
That would be great, yes.
Can you clarify what the long-term plan is? I see that
drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts
and one USB device (rtl8192cu/rtl8188cus) while
drivers/net/wireless/rtl8xxx has all the USB parts including
that one.
Does that mean we want the staging drivers for PCIe devices
to get merged into rtlwifi, and the remaining USB drivers to get
replaced by r8xxxu?
As one data point that I can provide (but you are probably
aware of), I could never get my rtl8188cus stick to work with
rtlwifi, but I found the older r8712u device to work fine with
the staging/rtl8712 driver.
Arnd
^ permalink raw reply
* [PATCH] wlcore: spi: fix build warning caused by redundant variable
From: Reizer, Eyal @ 2016-07-20 7:30 UTC (permalink / raw)
To: Kalle Valo, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-spi@vger.kernel.org,
Rob Herring
In-Reply-To: <1468999637-31006-1-git-send-email-eyalr@ti.com>
The ret variable is unused in wlcore_probe_of()
Remove it for fixing build warning.
Fixes: 01efe65aba65 ("wlcore: spi: add wl18xx support")
Signed-off-by: Eyal Reizer <eyalr@ti.com>
---
drivers/net/wireless/ti/wlcore/spi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index 73fbcf1..6d24040 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -454,7 +454,6 @@ static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue *glue,
struct wlcore_platdev_data *pdev_data)
{
struct device_node *dt_node = spi->dev.of_node;
- int ret;
const struct of_device_id *of_id;
of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Masashi Honma @ 2016-07-20 7:11 UTC (permalink / raw)
To: Bob Copeland; +Cc: johannes, linux-wireless, j
In-Reply-To: <20160719104034.GB11996@localhost>
On 2016年07月19日 19:40, Bob Copeland wrote:
>
> OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in
> ieee80211_mps_sta_status_update(), or does the node completely repeer?
>
> ISTR running into a problem where rebooted peer (previously in power-save)
> would send popen but we would buffer the response due to stale PS sta
> flag.
>
Thanks. I have tried your scenario.
I have disconnected remote peer by accidental shutdown.
(This means local peer does not recognize remote peer left.)
Then remote peer restarted and started to send Mesh Peering Open frames.
Local peer receives these frames but does not respond to these
because peer_lid mismatch.
After 3 times retrial, remote peer sent Mesh Peering Close frame
with reason code = 56(MESH-MAX-RETRIES).
And then, struct sta_info is freed and allocated.
So looks no problem.
^ permalink raw reply
* RE: [PATCHv8] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-07-20 7:04 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-spi@vger.kernel.org, Rob Herring
In-Reply-To: <871t2ovll6.fsf@kamboji.qca.qualcomm.com>
>
> > Add support for using with both wl12xx and wl18xx.
> >
> > - all wilink family needs special init command for entering wspi mode.
> > extra clock cycles should be sent after the spi init command while the
> > cs pin is high.
> > - Use inverted chip select for sending a dummy 4 bytes command that
> > completes the init stage.
> >
> > Signed-off-by: Eyal Reizer <eyalr@ti.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > v1->v2:update device tree bindings configuration
> > v2->v3:revert from manual gpio manipulation. use inverted chip select
> instead
> > for sending the extra init cycle which, achieves the same hardware purpose.
> > update device tree bindings docucmentation accordingly
> > v3->v4: Remove redundant data form binding documentation and fix chip
> select
> > number mismatch in wl1271 example
> > v4->v5: Rebase on top of head of wireless-drivers-next
> > v5->v6: Add ACKs
> > v6->v7: Mail format issues
> > v7->v8: Remove redundant varaible from wlcore_probe_of
>
> I have already applied this patch, it's too late to send a new version.
> Now you need to send a new patch, on top of wireless-drivers-next, which
> removes the redundant variable.
>
Understood. Will submit shortly
Best Regards,
Eyal
^ permalink raw reply
* Re: [PATCHv8] wlcore: spi: add wl18xx support
From: Kalle Valo @ 2016-07-20 7:02 UTC (permalink / raw)
To: Reizer, Eyal
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-spi@vger.kernel.org, Rob Herring
In-Reply-To: <8665E2433BC68541A24DFFCA87B70F5B36161990@DFRE01.ent.ti.com>
"Reizer, Eyal" <eyalr@ti.com> writes:
> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
> extra clock cycles should be sent after the spi init command while the
> cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
> completes the init stage.
>
> Signed-off-by: Eyal Reizer <eyalr@ti.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select instead
> for sending the extra init cycle which, achieves the same hardware purpose.
> update device tree bindings docucmentation accordingly
> v3->v4: Remove redundant data form binding documentation and fix chip select
> number mismatch in wl1271 example
> v4->v5: Rebase on top of head of wireless-drivers-next
> v5->v6: Add ACKs
> v6->v7: Mail format issues
> v7->v8: Remove redundant varaible from wlcore_probe_of
I have already applied this patch, it's too late to send a new version.
Now you need to send a new patch, on top of wireless-drivers-next, which
removes the redundant variable.
--
Kalle Valo
^ permalink raw reply
* [PATCHv8] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-07-20 6:58 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-spi@vger.kernel.org, Rob Herring
In-Reply-To: <1468994768-23609-1-git-send-email-eyalr@ti.com>
Add support for using with both wl12xx and wl18xx.
- all wilink family needs special init command for entering wspi mode.
extra clock cycles should be sent after the spi init command while the
cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
completes the init stage.
Signed-off-by: Eyal Reizer <eyalr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next
v5->v6: Add ACKs
v6->v7: Mail format issues
v7->v8: Remove redundant varaible from wlcore_probe_of
.../bindings/net/wireless/ti,wlcore,spi.txt | 41 +++++--
drivers/net/wireless/ti/wlcore/spi.c | 124 +++++++++++++++++----
2 files changed, 137 insertions(+), 28 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
document describes the binding for the SPI connected chip.
Required properties:
-- compatible : Should be "ti,wl1271"
+- compatible : Should be one of the following:
+ * "ti,wl1271"
+ * "ti,wl1273"
+ * "ti,wl1281"
+ * "ti,wl1283"
+ * "ti,wl1801"
+ * "ti,wl1805"
+ * "ti,wl1807"
+ * "ti,wl1831"
+ * "ti,wl1835"
+ * "ti,wl1837"
- reg : Chip select address of device
- spi-max-frequency : Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
- interrupt-parent, interrupts :
Should contain parameters for 1 interrupt line.
Interrupt parameters: parent, line number, type.
-- vwlan-supply : Point the node of the regulator that powers/enable the wl1271 chip
+- vwlan-supply : Point the node of the regulator that powers/enable the
+ wl12xx/wl18xx chip
Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
- clock-xtal : boolean, clock is generated from XTAL
- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:
Examples:
+For wl12xx family:
&spi1 {
- wl1271@1 {
+ wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <48000000>;
- clock-xtal;
- ref-clock-frequency = <38400000>;
interrupt-parent = <&gpio3>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <&vwlan_fixed>;
+ clock-xtal;
+ ref-clock-frequency = <38400000>;
+ };
+};
+
+For wl18xx family:
+&spi0 {
+ wlcore: wlcore@0 {
+ compatible = "ti,wl1835";
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ vwlan-supply = <&vwlan_fixed>;
};
};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..6d24040 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
#define WSPI_MAX_CHUNK_SIZE 4092
/*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
*/
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
/* Maximum number of SPI write chunks */
#define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
+struct wilink_familiy_data {
+ char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+ .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+ .name = "wl12xx",
+};
+
struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+ struct spi_device *spi = to_spi_device(glue->dev);
u8 *cmd = kzalloc(WSPI_INIT_CMD_LEN, GFP_KERNEL);
if (!cmd) {
@@ -151,6 +166,7 @@ static void wl12xx_spi_init(struct device *child)
cmd[6] |= WSPI_INIT_CMD_EN_FIXEDBUSY;
cmd[7] = crc7_be(0, cmd+2, WSPI_INIT_CMD_CRC_LEN) | WSPI_INIT_CMD_END;
+
/*
* The above is the logical order; it must actually be stored
* in the buffer byte-swapped.
@@ -163,6 +179,28 @@ static void wl12xx_spi_init(struct device *child)
spi_message_add_tail(&t, &m);
spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Send extra clocks with inverted CS (high). this is required
+ * by the wilink family in order to successfully enter WSPI mode.
+ */
+ spi->mode ^= SPI_CS_HIGH;
+ memset(&m, 0, sizeof(m));
+ spi_message_init(&m);
+
+ cmd[0] = 0xff;
+ cmd[1] = 0xff;
+ cmd[2] = 0xff;
+ cmd[3] = 0xff;
+ __swab32s((u32 *)cmd);
+
+ t.tx_buf = cmd;
+ t.len = 4;
+ spi_message_add_tail(&t, &m);
+
+ spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Restore chip select configration to normal */
+ spi->mode ^= SPI_CS_HIGH;
kfree(cmd);
}
@@ -270,22 +308,25 @@ static int __must_check wl12xx_spi_raw_read(struct device *child, int addr,
return 0;
}
-static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
- void *buf, size_t len, bool fixed)
+static int __wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
{
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
- /* SPI write buffers - 2 for each chunk */
- struct spi_transfer t[2 * WSPI_MAX_NUM_OF_CHUNKS];
+ struct spi_transfer *t;
struct spi_message m;
u32 commands[WSPI_MAX_NUM_OF_CHUNKS]; /* 1 command per chunk */
u32 *cmd;
u32 chunk_len;
int i;
+ /* SPI write buffers - 2 for each chunk */
+ t = kzalloc(sizeof(*t) * 2 * WSPI_MAX_NUM_OF_CHUNKS, GFP_KERNEL);
+ if (!t)
+ return -ENOMEM;
+
WARN_ON(len > SPI_AGGR_BUFFER_SIZE);
spi_message_init(&m);
- memset(t, 0, sizeof(t));
cmd = &commands[0];
i = 0;
@@ -318,9 +359,26 @@ static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
spi_sync(to_spi_device(glue->dev), &m);
+ kfree(t);
return 0;
}
+static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
+{
+ int ret;
+
+ /* The ELP wakeup write may fail the first time due to internal
+ * hardware latency. It is safer to send the wakeup command twice to
+ * avoid unexpected failures.
+ */
+ if (addr == HW_ACCESS_ELP_CTRL_REG)
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+
+ return ret;
+}
+
/**
* wl12xx_spi_set_power - power on/off the wl12xx unit
* @child: wl12xx device handle.
@@ -349,17 +407,38 @@ static int wl12xx_spi_set_power(struct device *child, bool enable)
return ret;
}
+/**
+ * wl12xx_spi_set_block_size
+ *
+ * This function is not needed for spi mode, but need to be present.
+ * Without it defined the wlcore fallback to use the wrong packet
+ * allignment on tx.
+ */
+static void wl12xx_spi_set_block_size(struct device *child,
+ unsigned int blksz)
+{
+}
+
static struct wl1271_if_operations spi_ops = {
.read = wl12xx_spi_raw_read,
.write = wl12xx_spi_raw_write,
.reset = wl12xx_spi_reset,
.init = wl12xx_spi_init,
.power = wl12xx_spi_set_power,
- .set_block_size = NULL,
+ .set_block_size = wl12xx_spi_set_block_size,
};
static const struct of_device_id wlcore_spi_of_match_table[] = {
- { .compatible = "ti,wl1271" },
+ { .compatible = "ti,wl1271", .data = &wl12xx_data},
+ { .compatible = "ti,wl1273", .data = &wl12xx_data},
+ { .compatible = "ti,wl1281", .data = &wl12xx_data},
+ { .compatible = "ti,wl1283", .data = &wl12xx_data},
+ { .compatible = "ti,wl1801", .data = &wl18xx_data},
+ { .compatible = "ti,wl1805", .data = &wl18xx_data},
+ { .compatible = "ti,wl1807", .data = &wl18xx_data},
+ { .compatible = "ti,wl1831", .data = &wl18xx_data},
+ { .compatible = "ti,wl1835", .data = &wl18xx_data},
+ { .compatible = "ti,wl1837", .data = &wl18xx_data},
{ }
};
MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table);
@@ -375,18 +454,24 @@ static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue *glue,
struct wlcore_platdev_data *pdev_data)
{
struct device_node *dt_node = spi->dev.of_node;
- int ret;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
+ if (!of_id)
+ return -ENODEV;
+
+ wilink_data = of_id->data;
+ dev_info(&spi->dev, "selected chip familiy is %s\n",
+ wilink_data->name);
if (of_find_property(dt_node, "clock-xtal", NULL))
pdev_data->ref_clock_xtal = true;
- ret = of_property_read_u32(dt_node, "ref-clock-frequency",
- &pdev_data->ref_clock_freq);
- if (ret) {
- dev_err(glue->dev,
- "can't get reference clock frequency (%d)\n", ret);
- return ret;
- }
+ /* optional clock frequency params */
+ of_property_read_u32(dt_node, "ref-clock-frequency",
+ &pdev_data->ref_clock_freq);
+ of_property_read_u32(dt_node, "tcxo-clock-frequency",
+ &pdev_data->tcxo_clock_freq);
return 0;
}
@@ -437,7 +522,8 @@ static int wl1271_probe(struct spi_device *spi)
return ret;
}
- glue->core = platform_device_alloc("wl12xx", PLATFORM_DEVID_AUTO);
+ glue->core = platform_device_alloc(wilink_data->name,
+ PLATFORM_DEVID_AUTO);
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device\n");
return -ENOMEM;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox