[PATCH] mac80211: fix the beacon csa counter for mesh and ibss
The csa counter has moved from sdata to beacon/presp but
it is not updated accordingly for mesh and ibss. Fix this.
This regression is introduced by the following patch:
mac80211: move csa counters from sdata to beacon/presp
Signed-off-by: Chun-Yeow Yeoh
---
net/mac80211/cfg.c | 1 +
net/mac80211/ibss.c | 1 +
net/mac80211/mesh.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index bb9f836..0fdfc20 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3443,6 +3443,7 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct
wireless_dev *wdev,
/* Update CSA counters */
if (sdata->vif.csa_active &&
(sdata->vif.type == NL80211_IFTYPE_AP ||
+sdata->vif.type == NL80211_IFTYPE_MESH_POINT ||
sdata->vif.type == NL80211_IFTYPE_ADHOC) &&
params->n_csa_offsets) {
int i;
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 21716af..7f72bc9 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -146,6 +146,7 @@ ieee80211_ibss_build_presp(struct ieee80211_sub_if_data
*sdata,
csa_settings->chandef.chan->center_freq);
presp->csa_counter_offsets[0] = (pos - presp->head);
*pos++ = csa_settings->count;
+ presp->csa_current_counter = csa_settings->count;
}
/* put the remaining rates in WLAN_EID_EXT_SUPP_RATES */
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index d468424..817098a 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -680,6 +680,7 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
*pos++ = 0x0;
*pos++ = ieee80211_frequency_to_channel(
csa->settings.chandef.chan->center_freq);
+ bcn->csa_current_counter = csa->settings.count;
bcn->csa_counter_offsets[0] = hdr_len + 6;
*pos++ = csa->settings.count;
*pos++ = WLAN_EID_CHAN_SWITCH_PARAM;
--
2.3.0
--
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: [WEXT]: multiple calls for SIOCGIWSTATS return same value
> On Sat, 2015-06-06 at 20:37 -0600, Gerrit Renker wrote: > > A problem has been found in recent kernels where multiple > > calls using SIOCGIWSTATS return the same, identical value. > > Which "value"? I believe these return a number of different values. What > are the returned values? Are they perhaps just 0? > I am primarily referring to the signal level. The first call returns a plausible value e.g. -78dB. All subsequent calls return the same value, regardless of receiver position (moving the laptop). It almost looks like a static value that gets initialized and then does not change. There is a similar behaviour for scan results: the signal levels reported for stations remain the same for all subsequent calls. Previously these also changed with time and position of receiver. > Is the application a 32-bit application running on a 64-bit machine > perhaps? Sorry forgot to mention: application and operating system both 64 bit, the bug submitted to wavemon also mentioned 64 bit. Thank you for the reply -- maybe this means that the root cause is in a different part; I would not know which at the moment. -- 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 v3] ath10k: add 'cryptmode' param to support raw tx injection and software crypto
This change supports hardware crypto engine bypass by enabling raw
Rx/Tx encap mode. This enables use cases such as software crypto and raw
tx injection. This change introduces a new module param 'cryptmode'.
cryptmode:
0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
encapsulation to the firmware. This is the default mode.
1: Use sofware crypto engine globally with raw mode TX/RX encapsulation
to the firmware.
2: Supports both hardware and software crypto with raw mode TX/RX
encapsulation to the firmware. By default hardware crypto engine is
used. To use software crypto in this mode, set the per ath10k_vif
'nohwcrypt' flag value to True.*
*) The patch for setting vif specific 'nohwcrypt' flag when
cryptmode=2 would be a separate patch to mac80211.
Possible use case examples:
- Use software crypto engine in mac80211. (cryptmode=1)
- Support inject raw unencrypted frame on monitor interface and use
hardware crypto to encrypt the injected Tx frames. (cryptmode=2)
- Support receive raw hardware decrypted frame with encryption header
on monitor interface. (cryptmode=2)
- Support hybrid local & split MAC mode to support tunneling protocols
such as CAPWAP: Use hardware crypto for BSS in local mode,
and bypass hardware crypto for BSS in split MAC mode.
(cryptmode=2, ath10k_vif nohwcrypt=0 for local mode, =1 for split MAC
mode)
Testing:
Used QCA988x hw 2.0 with firmware-4.bin_10.2.4.48 with
backports-20150424.
All test case tested** with hostapd in both WPA2-PSK-TKIP (11g) and
WPA2-PSK-CCMP(11n/ac). Verified ping and http to google.com works.
**) Need to skip ATH10K_FW_FEATURE_RAW_MODE_SUPPORT check in core.c to
test firmware. After all, none of the existing QCA official firmware
exports that firmware bit yet.
Test Casecryptmode value tested
---
1. ath10k hardware crypto can encrypt/decrypt 0: PASS
data frames when hostapd config the BSS in 1: Not applicable.
WPA2-PSK-TKIP and WPA2-PSK-CCMP modes. 2: PASS
2. mac80211 software crypto can encrypt/decrypt 0: Not applicable
data frames when hostapd config the BSS in 1: PASS
WPA2-PSK-TKIP and WPA2-PSK-CCMP modes. 2: PASS, when vif
nohwcrypt=1
3. Monitor interface Tx: User application can 0: Not applicable
inject unencrypted raw Tx frames to monitor 1: PASS (mac80211)
interface for mac80211 or hardware to encrypt2: PASS (hardware)
the frames.
4. Monitor interface Rx: mac80211 software crypto 0: Not applicable
engine can decrypt received TKIP/CCMP frames.1: PASS
User application see decrypted frames. 2: PASS, when vif
nohwcrypt=1
5. CAPWAP-like local and split MAC datapath 0: Not applicable
tunneling: Setup BSS1=Local MAC mode on wlan0, 1: Not applicable
BSS2=Split MAC mode on wlan0_monitor interface. 2: PASS
Test BSS1 data frames can be encrypted and
decrypted by ath10k hardware crypto engine
while BSS2 data frames can skip both hardware &
kernel mac80211 crypto engines via monitor
interface to the user application fot tunneling.
Signed-off-by: Liu CF/TW
---
drivers/net/wireless/ath/ath10k/core.c| 31 ++
drivers/net/wireless/ath/ath10k/core.h| 33 +--
drivers/net/wireless/ath/ath10k/debug.c | 5 +--
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 ++-
drivers/net/wireless/ath/ath10k/htt_tx.c | 9 +-
drivers/net/wireless/ath/ath10k/hw.h | 11 +++
drivers/net/wireless/ath/ath10k/mac.c | 54 ++-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 8 ++---
9 files changed, 129 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 59496a9..ea1c43f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -31,16 +31,19 @@
#include "wmi-ops.h"
unsigned int ath10k_debug_mask;
+static unsigned int ath10k_cryptmode_param;
static bool uart_print;
static bool skip_otp;
module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
+module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
module_param(uart_print, bool, 0644);
module_param(skip_otp, bool, 0644);
MODULE_PARM_DESC(debug_mask, "Debugging mask");
MODULE_PARM_DESC(uart_print, "Uart target debugging");
MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode");
+MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software, 2-both");
static const struct ath10k_hw_params ath10k_hw_params_list[] = {
{
Re: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
On Mo, 2015-06-08 at 23:14 +0200, Arend van Spriel wrote: > On 06/08/15 22:17, Jörg Krause wrote: > > On Mo, 2015-06-08 at 18:46 +0200, Arend van Spriel wrote: > > > On 06/08/15 15:48, Jörg Krause wrote: > > > > Hi Arend, > > > > > > > > On Mo, 2015-06-08 at 14:41 +0200, Arend van Spriel wrote: > > > > > On 06/08/15 14:35, Jörg Krause wrote: > > > > > > Hi, > > > > > > > > > > > > I've trouble creating the p2p interface on a BCM43362 wifi > > > > > > device > > > > > > running Linux kernel 4.0.4: > > > > > > > > > > > ># dmesg | grep brcmfmac > > > > > >[7.010870] brcmfmac: brcmf_c_preinit_dcmds: > > > > > > Firmware > > > > > > version = > > > > > >wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID > > > > > > 01 > > > > > > -b30a427d > > > > > >[7.158905] brcmfmac: > > > > > > brcmf_cfg80211_reg_notifier: not > > > > > > a > > > > > > ISO3166 > > > > > >code > > > > > >[ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: > > > > > > timeout > > > > > > occurred > > > > > > > > > > > > Trying to add the p2p interface manually: > > > > > > > > > > > ># iw phy0 interface add p2p0 type __p2pdev > > > > > >[ 372.042704] brcmfmac: brcmf_link_down: > > > > > > WLC_DISASSOC > > > > > > failed > > > > > > (-52) > > > > > >[ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: > > > > > > timeout > > > > > > occurred > > > > > >[ 373.679377] brcmfmac: brcmf_cfg80211_del_key: > > > > > > invalid > > > > > > key > > > > > > index (4) > > > > > >[ 373.685733] brcmfmac: brcmf_cfg80211_del_key: > > > > > > invalid > > > > > > key > > > > > > index (5) > > > > > > > > > > > > Any idea? > > > > > > > > > > Wondering whether it is similar to what Rafal reported. Can > > > > > you > > > > > do a > > > > > hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 > > > > > > > > I managed to set up the p2p interface by recompiling the kernel > > > > with > > > > CONFIG_BRCMDBG and loading the brcmfmac module with p2pon=1. > > > > > > > > I had a discussion some month ago with Hante Meulemann about > > > > setting up > > > > the p2p interface. This is one of his replies: > > > > > > > > "For what I can see from the log is that we don’t get the > > > > event from > > > > the FW indicating that the p2p interface was created. > > > > This > > > > probably > > > > means that there is a bug in this FW for this device. I > > > > need > > > > to discuss > > > > this to see how much priority we can give this. The best > > > > option for you > > > > for the moment is to use the legacy method with the > > > > 'p2pon=1' > > > > command." > > > > > > Thanks for digging your email archive as we clearly forgot about > > > this > > > > > > entirely. > > > > Me too :-) > > > > > The timeout in your log indeed indicates it is missing a > > > notification from firmware. I assume your primary interface is in > > > managed mode when trying to create the p2p_dev interface. Is that > > > correct? > > > > Correct. > > So do you have the following commit in your kernel tree: > > commit f48556e1b6a60f1b394a6c4b0a7b8cacba3eb107 > Author: Arend van Spriel > Date: Tue Sep 30 10:23:16 2014 +0200 > > brcmfmac: assure P2P discovery is disabled when setting > P2P_DEVICE > mac addre > Yes. $ git log --oneline --grep="brcmfmac: assure P2P discovery is disabled when setting P2P_DEVICE" f48556e brcmfmac: assure P2P discovery is disabled when setting P2P_DEVICE mac address -- 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: nci: hci: Fix releasing uninitialized skbs
Hi Joe,
On Sun, May 31, 2015 at 05:44:45PM -0700, Joe Perches wrote:
> Several of these goto exit; uses should be direct returns
> as skb is not yet initialized by nci_hci_get_param().
>
> Miscellanea:
>
> o Use !memcmp instead of memcmp() == 0
> o Remove unnecessary goto from if () {... goto exit;} else {...} exit:
>
> Signed-off-by: Joe Perches
> ---
> net/nfc/nci/hci.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
Applied to nfc-next, 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
Re: [PATCH] NFC: PN544: use flags argument of devm_gpiod_get to set direction
Hi Uwe,
On Tue, May 19, 2015 at 09:22:56AM +0200, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Use this to simplify the driver. Furthermore this is one caller less
> that stops us making the flags argument to gpiod_get*() mandatory.
>
> While touching this also do some minor coding style fixes.
>
> Fixes: 0a5942c8e148 ("NFC: Add ACPI support for NXP PN544")
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/nfc/pn544/i2c.c | 43 +++
> 1 file changed, 11 insertions(+), 32 deletions(-)
Applied to nfc-next, 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
Re: [char-misc-next] NFC: microread: drop unused variable
Hi Tomas, On Thu, May 07, 2015 at 04:38:30PM +0300, Tomas Winkler wrote: > In microread_i2c_irq_thread_fn 'client' set but not used > > Cc: Lauro Ramos Venancio > Cc: Aloisio Almeida Jr > Signed-off-by: Tomas Winkler > --- > drivers/nfc/microread/i2c.c | 3 --- > 1 file changed, 3 deletions(-) Applied to nfc-next, 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
Re: [PATCH] drivers/nfc: remove obsolete setting of DEBUG
Hi Valentin, On Tue, Apr 28, 2015 at 11:08:47AM +0200, Valentin Rothberg wrote: > The CPP identifier 'DEBUG' is not used in the source code of nfc at all, > so we can safely remove setting it in both Makefiles. > > Signed-off-by: Valentin Rothberg > --- > I detected this issue with ./scripts/checkkconfigsymbols.py since > CONFIG_NFC_DEBUG is not defined in Kconfig. > --- > drivers/nfc/Makefile | 2 -- > drivers/nfc/nxp-nci/Makefile | 2 -- > 2 files changed, 4 deletions(-) Applied, with a massaged commit message. 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
Re: [PATCH] ath10k: new debugfs interface to enable adaptive CCA
Is there any publicly available firmware binary that supports this feature, even if one has to force the feature flag? Thanks, Ben On 06/04/2015 03:11 PM, Ben Greear wrote: > Is there any way to make this work on a 10.1 firmware, even if that means > manually poking registers through debugfs? > > I have a user of CT firmware that would really like Adaptive CCA to > work, so if I can just get some clues as to what needs setting, > I can write up an API that works with my 10.1 firmware... > > Thanks, > Ben > > > On 05/10/2015 11:05 PM, Michal Kazior wrote: >> On 8 May 2015 at 16:01, wrote: >>> From: Manikanta Pubbisetty >>> >>> For devices working in 2.4 GHz to be ETSI compliant, >>> it is required to support adaptive CCA. Some firmwares >>> support adaptive CCA and is disabled by default. >>> >>> The patch is an attempt to add a new debugfs interface to enable >>> adaptive cca on supported firmwares. Support for this feature is >>> advertised with a new firmware feature flag. >> >> I guess this should be configured automatically depending on DFS >> domain. You can't expect users to configure their devices via debugfs, >> can you? This should just work. > > -- 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
Re: [PATCH] Doc:nfc: Fix typo in nfc-hci.txt
Hi Msanari, On Fri, Jun 05, 2015 at 09:38:19PM +0900, Masanari Iida wrote: > This patch fix a spelling typo in nfc-hci.txt > > Signed-off-by: Masanari Iida > --- > Documentation/nfc/nfc-hci.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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
Re: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
On Mo, 2015-06-08 at 18:46 +0200, Arend van Spriel wrote: > On 06/08/15 15:48, Jörg Krause wrote: > > Hi Arend, > > > > On Mo, 2015-06-08 at 14:41 +0200, Arend van Spriel wrote: > > > On 06/08/15 14:35, Jörg Krause wrote: > > > > Hi, > > > > > > > > I've trouble creating the p2p interface on a BCM43362 wifi > > > > device > > > > running Linux kernel 4.0.4: > > > > > > > > # dmesg | grep brcmfmac > > > > [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware > > > > version = > > > > wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01 > > > > -b30a427d > > > > [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not > > > > a > > > > ISO3166 > > > > code > > > > [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout > > > > occurred > > > > > > > > Trying to add the p2p interface manually: > > > > > > > > # iw phy0 interface add p2p0 type __p2pdev > > > > [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC > > > > failed > > > > (-52) > > > > [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout > > > > occurred > > > > [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid > > > > key > > > > index (4) > > > > [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid > > > > key > > > > index (5) > > > > > > > > Any idea? > > > > > > Wondering whether it is similar to what Rafal reported. Can you > > > do a > > > hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 > > > > I managed to set up the p2p interface by recompiling the kernel > > with > > CONFIG_BRCMDBG and loading the brcmfmac module with p2pon=1. > > > > I had a discussion some month ago with Hante Meulemann about > > setting up > > the p2p interface. This is one of his replies: > > > > "For what I can see from the log is that we don’t get the > > event from > > the FW indicating that the p2p interface was created. This > > probably > > means that there is a bug in this FW for this device. I need > > to discuss > > this to see how much priority we can give this. The best > > option for you > > for the moment is to use the legacy method with the 'p2pon=1' > > command." > > Thanks for digging your email archive as we clearly forgot about this > > entirely. Me too :-) > The timeout in your log indeed indicates it is missing a > notification from firmware. I assume your primary interface is in > managed mode when trying to create the p2p_dev interface. Is that > correct? Correct. Best regards Jörg Krause -- 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: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
On 06/08/15 22:17, Jörg Krause wrote: On Mo, 2015-06-08 at 18:46 +0200, Arend van Spriel wrote: On 06/08/15 15:48, Jörg Krause wrote: Hi Arend, On Mo, 2015-06-08 at 14:41 +0200, Arend van Spriel wrote: On 06/08/15 14:35, Jörg Krause wrote: Hi, I've trouble creating the p2p interface on a BCM43362 wifi device running Linux kernel 4.0.4: # dmesg | grep brcmfmac [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01 -b30a427d [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred Trying to add the p2p interface manually: # iw phy0 interface add p2p0 type __p2pdev [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC failed (-52) [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4) [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5) Any idea? Wondering whether it is similar to what Rafal reported. Can you do a hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 I managed to set up the p2p interface by recompiling the kernel with CONFIG_BRCMDBG and loading the brcmfmac module with p2pon=1. I had a discussion some month ago with Hante Meulemann about setting up the p2p interface. This is one of his replies: "For what I can see from the log is that we don’t get the event from the FW indicating that the p2p interface was created. This probably means that there is a bug in this FW for this device. I need to discuss this to see how much priority we can give this. The best option for you for the moment is to use the legacy method with the 'p2pon=1' command." Thanks for digging your email archive as we clearly forgot about this entirely. Me too :-) The timeout in your log indeed indicates it is missing a notification from firmware. I assume your primary interface is in managed mode when trying to create the p2p_dev interface. Is that correct? Correct. So do you have the following commit in your kernel tree: commit f48556e1b6a60f1b394a6c4b0a7b8cacba3eb107 Author: Arend van Spriel Date: Tue Sep 30 10:23:16 2014 +0200 brcmfmac: assure P2P discovery is disabled when setting P2P_DEVICE mac addre Regards, Arend Best regards Jörg Krause -- 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 -- 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 v3 1/2] staging: wilc1000: Cleanup to coreconfigurator
On Mon, Jun 08, 2015 at 12:41:08PM -0700, Greg KH wrote: > On Tue, Jun 02, 2015 at 12:55:06PM +0400, Stanislav Kholmanskikh wrote: > > Fixed several syntax/style issues found with checkpatch.pl. > > What exactly is "several"? Please be specific as to what type of > changes you are making. > > Please fix and resend both of these. Sorry. I put a more detailed description and sent V4. Thanks. > > thanks, > > greg k-h -- 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 v4 1/2] staging: wilc1000: Cleanup to coreconfigurator
Fixed the following issues found with checkpatch.pl:
* Multiple debug strings contained " \n". Changed
it to "\n".
* Changed 'return(X)' to 'return X'.
* Aligned TAG_PARAM_OFFSET to fit 80 columns
Signed-off-by: Stanislav Kholmanskikh
---
Changes since v3:
* Put a more detailed explanation what I do in patch 1/2.
drivers/staging/wilc1000/coreconfigurator.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index e3e3f20..43864dc 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -28,7 +28,7 @@
#define INVALID 255
#define MAC_ADDR_LEN6
#define TAG_PARAM_OFFSET (MAC_HDR_LEN + TIME_STAMP_LEN + \
- BEACON_INTERVAL_LEN +
CAP_INFO_LEN)
+BEACON_INTERVAL_LEN + CAP_INFO_LEN)
/*/
/* Function Macros */
@@ -672,14 +672,14 @@ INLINE WILC_Uint16 get_asoc_id(u8 *data)
WILC_Sint32 CoreConfiguratorInit(void)
{
WILC_Sint32 s32Error = WILC_SUCCESS;
- PRINT_D(CORECONFIG_DBG, "CoreConfiguratorInit() \n");
+ PRINT_D(CORECONFIG_DBG, "CoreConfiguratorInit()\n");
sema_init(&SemHandleSendPkt, 1);
sema_init(&SemHandlePktResp, 0);
gps8ConfigPacket = (WILC_Sint8 *)WILC_MALLOC(MAX_PACKET_BUFF_SIZE);
if (gps8ConfigPacket == NULL) {
- PRINT_ER("failed in gps8ConfigPacket allocation \n");
+ PRINT_ER("failed in gps8ConfigPacket allocation\n");
s32Error = WILC_NO_MEM;
goto _fail_;
}
@@ -710,13 +710,13 @@ u8 *get_tim_elm(u8 *pu8msa, WILC_Uint16 u16RxLen,
WILC_Uint16 u16TagParamOffset)
/* Search for the TIM Element Field and return if the element is found
*/
while (u16index < (u16RxLen - FCS_LEN)) {
if (pu8msa[u16index] == ITIM) {
- return(&pu8msa[u16index]);
+ return &pu8msa[u16index];
} else {
u16index += (IE_HDR_LEN + pu8msa[u16index + 1]);
}
}
- return(0);
+ return 0;
}
/* This function gets the current channel information from
@@ -728,7 +728,7 @@ u8 get_current_channel_802_11n(u8 *pu8msa, WILC_Uint16
u16RxLen)
index = TAG_PARAM_OFFSET;
while (index < (u16RxLen - FCS_LEN)) {
if (pu8msa[index] == IDSPARMS)
- return (pu8msa[index + 2]);
+ return pu8msa[index + 2];
else
/* Increment index by length information and header */
index += pu8msa[index + 1] + IE_HDR_LEN;
@@ -750,7 +750,7 @@ u8 get_current_channel(u8 *pu8msa, WILC_Uint16 u16RxLen)
#else /* FIVE_GHZ_BAND */
/* Extract current channel information from */
/* the beacon/probe response frame */
- return (get_current_channel_802_11n(pu8msa, u16RxLen));
+ return get_current_channel_802_11n(pu8msa, u16RxLen);
#endif /* FIVE_GHZ_BAND */
#else
return 0;
@@ -1444,7 +1444,7 @@ void ProcessAdrWid(WILC_Char *pcPacket, WILC_Sint32
*ps32PktLen,
void ProcessBinWid(WILC_Char *pcPacket, WILC_Sint32 *ps32PktLen,
tstrWID *pstrWID, u8 *pu8val, WILC_Sint32 s32ValueSize)
{
- /* WILC_ERROR("processing Binary WIDs is not supported \n"); */
+ /* WILC_ERROR("processing Binary WIDs is not supported\n"); */
WILC_Uint16 u16MsgLen = 0;
WILC_Uint16 idx= 0;
@@ -1583,7 +1583,7 @@ WILC_Sint32 further_process_response(u8 *resp,
WILC_memcpy(pstrWIDresult->ps8WidVal, cfg_str,
cfg_len); /* mostafa: no need currently for the extra NULL byte */
pstrWIDresult->s32ValueSize = cfg_len;
} else {
- PRINT_ER("allocated WID buffer length is smaller than
the received WID Length \n");
+ PRINT_ER("allocated WID buffer length is smaller than
the received WID Length\n");
retval = -2;
}
@@ -2027,7 +2027,7 @@ WILC_Sint32 ConfigProvideResponse(WILC_Char
*pcRespBuffer, WILC_Sint32 s32RespLe
} else {
WILC_memcpy(gstrConfigPktInfo.pcRespBuffer,
pcRespBuffer, gstrConfigPktInfo.s32MaxRespBuffLen);
gstrConfigPktInfo.s32BytesRead =
gstrConfigPktInfo.s32MaxRespBuffLen;
- PRINT_ER("BusProvideResponse() Response greater than
the prepared Buffer Size \n");
+ PRINT_ER("BusProvideResponse() Response greater than
the prepared Buffer Size\n");
}
up(&SemHandlePktResp);
@@ -2076,7 +2076,7 @@ WILC_S
[PATCH v4 2/2] staging: wilc1000: Align enum members in coreconfigurator
Aligned enum members to follow a common style per enum.
Signed-off-by: Stanislav Kholmanskikh
---
drivers/staging/wilc1000/coreconfigurator.c | 29 +++---
drivers/staging/wilc1000/coreconfigurator.h | 62 ++---
2 files changed, 46 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 43864dc..c55ed9d 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -40,11 +40,12 @@
/*/
/* Basic Frame Type Codes (2-bit) */
-typedef enum {FRAME_TYPE_CONTROL = 0x04,
- FRAME_TYPE_DATA= 0x08,
- FRAME_TYPE_MANAGEMENT= 0x00,
- FRAME_TYPE_RESERVED = 0x0C,
- FRAME_TYPE_FORCE_32BIT = 0x
+typedef enum {
+ FRAME_TYPE_CONTROL = 0x04,
+ FRAME_TYPE_DATA= 0x08,
+ FRAME_TYPE_MANAGEMENT = 0x00,
+ FRAME_TYPE_RESERVED= 0x0C,
+ FRAME_TYPE_FORCE_32BIT = 0x
} tenuBasicFrmType;
/* Frame Type and Subtype Codes (6-bit) */
@@ -188,7 +189,7 @@ static tstrWID gastrWIDs[] = {
{WID_QOS_ENABLE,WID_CHAR},
{WID_11I_MODE, WID_CHAR},
{WID_CURRENT_TX_RATE, WID_CHAR},
- {WID_LINKSPEED, WID_CHAR},
+ {WID_LINKSPEED, WID_CHAR},
{WID_RTS_THRESHOLD, WID_SHORT},
{WID_FRAG_THRESHOLD,WID_SHORT},
{WID_SSID, WID_STR},
@@ -223,14 +224,14 @@ static tstrWID gastrWIDs[] = {
{WID_MEMORY_ACCESS_32BIT, WID_INT},
{WID_MEMORY_ACCESS_16BIT, WID_SHORT},
{WID_MEMORY_ACCESS_8BIT,WID_CHAR},
- {WID_SITE_SURVEY_RESULTS, WID_STR},
- {WID_PMKID_INFO,WID_STR},
- {WID_ASSOC_RES_INFO,WID_STR},
- {WID_MANUFACTURER, WID_STR}, /* 4 Wids
added for the CAPI tool*/
- {WID_MODEL_NAME,WID_STR},
- {WID_MODEL_NUM, WID_STR},
- {WID_DEVICE_NAME, WID_STR},
- {WID_SSID_PROBE_REQ, WID_STR},
+ {WID_SITE_SURVEY_RESULTS, WID_STR},
+ {WID_PMKID_INFO,WID_STR},
+ {WID_ASSOC_RES_INFO,WID_STR},
+ {WID_MANUFACTURER, WID_STR}, /* 4 Wids added for the CAPI
tool*/
+ {WID_MODEL_NAME,WID_STR},
+ {WID_MODEL_NUM, WID_STR},
+ {WID_DEVICE_NAME, WID_STR},
+ {WID_SSID_PROBE_REQ,WID_STR},
#ifdef MAC_802_11N
{WID_11N_ENABLE,WID_CHAR},
diff --git a/drivers/staging/wilc1000/coreconfigurator.h
b/drivers/staging/wilc1000/coreconfigurator.h
index 73cdbef..b8e5241 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -19,9 +19,9 @@
/*/
/* Number of WID Options Supported */
#define NUM_BASIC_SWITCHES 45
-#define NUM_FHSS_SWITCHES0
+#define NUM_FHSS_SWITCHES 0
-#define NUM_RSSI 5
+#define NUM_RSSI5
#ifdef MAC_802_11N
#define NUM_11N_BASIC_SWITCHES 25
@@ -51,14 +51,14 @@ extern WILC_Uint16 g_num_total_switches;
#define MAX_PACKET_BUFF_SIZE 1596
-#define MAX_STRING_LEN 256
-#define MAX_SURVEY_RESULT_FRAG_SIZE MAX_STRING_LEN
-#define SURVEY_RESULT_LENGTH 44
-#define MAX_ASSOC_RESP_FRAME_SIZE MAX_STRING_LEN
+#define MAX_STRING_LEN 256
+#define MAX_SURVEY_RESULT_FRAG_SIZE MAX_STRING_LEN
+#define SURVEY_RESULT_LENGTH 44
+#define MAX_ASSOC_RESP_FRAME_SIZEMAX_STRING_LEN
-#define STATUS_MSG_LEN 12
-#define MAC_CONNECTED 1
-#define MAC_DISCONNECTED 0
+#define STATUS_MSG_LEN 12
+#define MAC_CONNECTED1
+#define MAC_DISCONNECTED 0
@@ -327,10 +327,10 @@ typedef enum {
WID_SUPP_PASSWORD = 0x3011,
WID_SITE_SURVEY_RESULTS= 0x3012,
WID_RX_POWER_LEVEL = 0x3013,
- WID_MANUFACTURER = 0x3026, /*Added for
CAPI tool */
- WID_MODEL_NAME = 0x3027,
/*Added for CAPI tool */
- WID_MODEL_NUM = 0x3028, /*Added for
CAPI tool */
- WID_DEVICE_NAME= 0x3029,
/*Added for CAPI tool */
+ WID_MANUFACTURER = 0x3026,/*Added for CAPI tool */
+ WID_MODEL_NAME = 0x3027,/*Added for CAPI
Re: [RFC v3 2/2] firmware: add firmware signature checking support
On Mon, May 18, 2015 at 5:45 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Systems that have module signing currently enabled may > wish to extend vetting of firmware passed to the kernel > as well. We can re-use most of the code for module signing > for firmware signature verification and signing. This will > also later enable re-use of this same code for subsystems > that wish to provide their own cryptographic verification > requirements on userspace data needed. > > Contrary to module signing the signature files are expected > to be completely detached for practical and licensing puposes. > If you have foo.bin, you'll need foo.bin.p7s file present > for firmware signing. > > There's both a config option and a boot parameter which control > whether we accept or fail with unsigned firmware and firmware > that are signed with an unknown key. If firmware signing is > enabled permissively we'll only log into the kernel ring buffer > when use of an unsigned firmware file is used. If firmware > signing is in enforced mode the kernel will not allow invalid > or unsigned firmware files to be loaded into the kernel. > > Contrary to module signing we do not taint the kernel in > the permissive fw signing mode due to restrictions on the > firmware_class API, extensions to enable this are expected > however in the future. > > Cc: Rusty Russell > Cc: David Howells > Cc: Ming Lei > Cc: Seth Forshee > Cc: Kyle McMartin > Cc: David Woodhouse > Signed-off-by: Luis R. Rodriguez > --- > Documentation/firmware_class/signing.txt | 90 + > drivers/base/Kconfig | 18 +++ > drivers/base/firmware_class.c| 213 > ++- > 3 files changed, 314 insertions(+), 7 deletions(-) > create mode 100644 Documentation/firmware_class/signing.txt > > diff --git a/Documentation/firmware_class/signing.txt > b/Documentation/firmware_class/signing.txt > new file mode 100644 > index 000..b03f654 > --- /dev/null > +++ b/Documentation/firmware_class/signing.txt > @@ -0,0 +1,90 @@ > + > + KERNEL FIRMWARE SIGNING FACILITY > + > + > +CONTENTS > + > + - Overview. > + - Configuring firmware signing. > + - Using signing keys. > + - Signing firmware files. > + > + > + > +OVERVIEW > + > + > +Device drivers which require a firmware to be uploaded onto a device as its > own > +device's microcode use any of the following APIs: > + > + * request_firmware() > + * request_firmware_direct() > + * request_firmware_nowait() > + > +The kernel firmware signing facility enables to cryptographically sign > +firmware files on a system using the same keys used for module signing. > +Firmware files's signatures consist of PKCS#7 messages of the respective > +firmware file. A firmware file named foo.bin, would have its respective > +signature on the filesystem as foo.bin.p7s. When firmware signature > +checking is enabled (FIRMWARE_SIG) and when one of the above APIs is used > +against foo.bin, the file foo.bin.p7s will also be looked for. If > +FIRMWARE_SIG_FORCE is enabled the foo.bin file will only be allowed to > +be returned to callers of the above APIs if and only if the foo.bin.p7s > +file is confirmed to be a valid signature of the foo.bin file. If > +FIRMWARE_SIG_FORCE is not enabled and only FIRMWARE_SIG is enabled the > +kernel will be permissive and enabled unsigned firmware files, or firmware > +files with incorrect signatures. If FIRMWARE_SIG is not enabled the > +signature file is ignored completely. > + > +Firmware signing increases security by making it harder to load a malicious > +firmware into the kernel. The firmware signature checking is done by the > +kernel so that it is not necessary to have trusted userspace bits. > + > + > +CONFIGURING FIRMWARE SIGNING > + > + > +The firmware signing facility is enabled by going to the section: > + > +-> Device Drivers > + -> Generic Driver Options > +-> Userspace firmware loading support (FW_LOADER [=y]) > + -> Firmware signature verification (FIRMWARE_SIG [=y]) > + > +If you want to not allow unsigned firmware to be loaded you should > +enable: > + > +"Require all firmware to be validly signed" (FIRMWARE_SIG_FORCE [=y]), > +under the same menu. > + > +== > +USING SIGNING KEYS > +== > + > +The same key types used for module signing can be used for firmware > +signing. For details on that refer to Documentation/module-signing.txt. > + > +You will need: > + > + A) A DER-encoded X.509 certificate containing the public key. > + B) A DER-encoded PKCS#7 message containing the signatures, these are > + the .p7s files. > + C) A binary blob that is the detached data for the PKCS#7 message, this > + is the firmware files > + > +A) is must be made available to the k
Re: [PATCH v3 1/2] staging: wilc1000: Cleanup to coreconfigurator
On Tue, Jun 02, 2015 at 12:55:06PM +0400, Stanislav Kholmanskikh wrote: > Fixed several syntax/style issues found with checkpatch.pl. What exactly is "several"? Please be specific as to what type of changes you are making. Please fix and resend both of these. thanks, greg k-h -- 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: mac80211 modification
On Mon, Jun 8, 2015 at 10:40 PM, Alexis Green wrote: > > You should build mac80211 as module instead of built-in driver and > "make modules" instead of full make. This way you'll be just > rebuilding mac80211.ko instead of the whole thing. > > On Mon, Jun 8, 2015 at 2:39 AM, Duy Tai Nguyen wrote: > > Hi, > > > > I want to inject particular data into beacon frame in Android device. > > I found two approaches: > > 1. Write loadable kernel module. > > 2. Modify MAC80211 subsystem > > In the first approach, I found that I could not include directly > > source code from MAC80211 sub system in folder /net/mac80211/. Thus, I > > used the second approach, but, every time I change any line of source > > code, it takes 30 minutes to build zImage then install new kernel in > > my Android device. Finally, I was stuck. > > Therefore, my questions are: > > 1. Is it right approach to modify MAC80211 subsystem? > > 2. Are there any faster approach to modify MAC80211 and test source code? > > 3. I am curious about the way you write code and test MAC80211. Could > > you explain in details? The way i do it is, as below: 1) First time compile the full kernel. With mac80211=m 2) Next time: after changing source : make modules M=net/mac80211 make modules_install M=net/mac80211 modprobe -v mac80211 -r modprobe -v mac80211 3) I normally use mac80211_hwsim to test the mac80211 code. Refer: https://wireless.wiki.kernel.org/en/users/drivers/mac80211_hwsim In that case: modprobe -v mac80211_hwsim -r modprobe -v mac80211_hwsim -- 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] rtl8723au: replaced asm/atomic.h by linux/atomic.h
Hi Kalle, On Mon, 8 Jun 2015, Kalle Valo wrote: For staging patches please prefix the title "staging: " Here's a tip how you can check what commit title you should use: git log --oneline drivers/staging/rtl8723au/include/rtw_io.h Thanks a lot! Xavier -- 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 a case of incorrect metric used when forwarding a PREQ
I took a look at the spec too and also didn't see mention of the MP_F_RF flag. Section 13.10.9.3 for example talks about PREQ handling and in case E2 talks about sending replies back. It says to do that if target only is not set which makes sense: MP_F_RF and MP_F_DO are exclusive options so it's silly to use two different flags for them. But for the purposes of this patch that is a moot issue: the semantics of the function don't change and the original code was both confusing and using the wrong value for metric for the not target only, intermediate station case. -- Jesse -Original Message- From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Yeoh Chun-Yeow Sent: Monday, June 08, 2015 1:55 AM To: linux-wireless@vger.kernel.org Subject: Re: [PATCH] mac80211: Fix a case of incorrect metric used when forwarding a PREQ As mentioned in Section 13.10.9.3 Case E2, the PREQ forwarding should use metric "as received + own metric toward transmitter of received PREQ". So you are right. Just MP_F_RF bit is no longer use. After replying with PREP, forwarding the PREQ by setting the IEEE80211_PREQ_TO_FLAG in the per target flags. --- Chun-Yeow On Mon, Jun 8, 2015 at 4:07 PM, Yeoh Chun-Yeow wrote: > Hi, Alexis Green > > I just take a look back on the code before implementing the Proactive > PREQ for PREP. For the case of reply and forward (target_flags & > MP_F_RF), the previous metric used is the one which resolved from > mpath->metric. > > Refer here: > https://github.com/o11s/open80211s/blob/o11s-0.4.2/net/mac80211/mesh_h > wmp.c > > But to say that, I cannpt confirm whether this is correct. The > standard 802.11-2012 has no longer specified bit-1 MP_F_RF (Refer > section 8.4.2.115 per target flag). So maybe it is not relevant > anymore. We may need to remove as well. > > > Chun-Yeow -- 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 -- 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: mac80211 modification
You should build mac80211 as module instead of built-in driver and "make modules" instead of full make. This way you'll be just rebuilding mac80211.ko instead of the whole thing. On Mon, Jun 8, 2015 at 2:39 AM, Duy Tai Nguyen wrote: > Hi, > > I want to inject particular data into beacon frame in Android device. > I found two approaches: > 1. Write loadable kernel module. > 2. Modify MAC80211 subsystem > In the first approach, I found that I could not include directly > source code from MAC80211 sub system in folder /net/mac80211/. Thus, I > used the second approach, but, every time I change any line of source > code, it takes 30 minutes to build zImage then install new kernel in > my Android device. Finally, I was stuck. > Therefore, my questions are: > 1. Is it right approach to modify MAC80211 subsystem? > 2. Are there any faster approach to modify MAC80211 and test source code? > 3. I am curious about the way you write code and test MAC80211. Could > you explain in details? > Best Regards, > Duy Tai. > > Nguyen Duy Tai > Ym: kimjiwoo741 > Phone: +841676919422 > Faculty of Computer Science and Engineering. > University of Technology HCMC. > > -- > 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 -- 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: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
On 06/08/15 15:48, Jörg Krause wrote: Hi Arend, On Mo, 2015-06-08 at 14:41 +0200, Arend van Spriel wrote: On 06/08/15 14:35, Jörg Krause wrote: Hi, I've trouble creating the p2p interface on a BCM43362 wifi device running Linux kernel 4.0.4: # dmesg | grep brcmfmac [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01 -b30a427d [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred Trying to add the p2p interface manually: # iw phy0 interface add p2p0 type __p2pdev [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC failed (-52) [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4) [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5) Any idea? Wondering whether it is similar to what Rafal reported. Can you do a hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 I managed to set up the p2p interface by recompiling the kernel with CONFIG_BRCMDBG and loading the brcmfmac module with p2pon=1. I had a discussion some month ago with Hante Meulemann about setting up the p2p interface. This is one of his replies: "For what I can see from the log is that we don’t get the event from the FW indicating that the p2p interface was created. This probably means that there is a bug in this FW for this device. I need to discuss this to see how much priority we can give this. The best option for you for the moment is to use the legacy method with the 'p2pon=1' command." Thanks for digging your email archive as we clearly forgot about this entirely. The timeout in your log indeed indicates it is missing a notification from firmware. I assume your primary interface is in managed mode when trying to create the p2p_dev interface. Is that correct? Regards, Arend Best regards Jörg Krause -- 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
Fwd: TX99 rate control
Hi all, I'm trying to figure out how to get rate control working in TX99. Currently it's forced in code to rate = &tx_info->control.rates[0]; Every time I force/try anything besides "0" (which is the value of tx_info->control.rates[0]) the module won't start radiating. Can anyone provide any help with this subject? Kind regards Mathieu -- 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 'cryptmode' param to support raw tx injection and sw crypto.
Liu CF/TW writes: > This change supports bypassing HW crypto engine by enabling raw Rx/Tx mode. > This will enable use cases such as sw crypto and raw tx injection. > This change introduces a new module param 'cryptmode'. Please use full words, eg. sw -> software, hw -> hardware > cryptmode: > > 0Use HW crypto engine. Use native WiFi mode Tx/Rx encap "Use hardware crypto engine with native Wi-Fi mode TX/RX encapsulation to the firmware" > 1Use SW crypto engine. Use raw mode Tx/Rx encap "Use sofware crypto engine from mac80211 with raw mode TX/RX encapsulation to the firmware" > 2Supports both SW & HW crypto engine. Use raw mode Tx/Rx encap. It's not clear how to use this. How does the user choose between SW or HW crypto modes? Please document that fully in the commit log. > ath10k > cryptmode > param Testing Status > ---- > 0 HW CCMP/TKIP tested ok. > Note: HW crypto bypass not supported by ath10k hw in native WiFi > mode. What's "HW crypto bypass"? Please write the commit log so that everyone can understand it. > 1 - mac80211 SW crypto tested ok. > - raw Tx frame injection tested ok. What does "mac80211 SW crypto tested ok" exactly mean? > 2 HW CCMP/TKIP tested ok. > SW CCMP/TKIP tested ok. How were the HW and SW modes chosen? > Tested raw Tx encrypted frame injection ok. With HW or SW crypto mode? -- 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
Re: [PATCH V2] ath10k: add 'cryptmode' param to support raw tx injection and sw crypto.
Liu CF/TW writes: > This change supports bypassing HW crypto engine by enabling raw Rx/Tx mode. > This will enable use cases such as sw crypto and raw tx injection. > This change introduces a new module param 'cryptmode'. > > cryptmode: > > 0Use HW crypto engine. Use native WiFi mode Tx/Rx encap > > 1Use SW crypto engine. Use raw mode Tx/Rx encap > > 2Supports both SW & HW crypto engine. Use raw mode Tx/Rx encap. > > Testing: used QCA988x hw 2.0 with firmware-4.bin_10.2.4.48 with > backports-20150424 > (Skipped ATH10K_FW_FEATURE_RAW_MODE_SUPPORT check in core.c within this > patch. > Since none of the existing QCA official firmware has the feature bit set yet) > > ath10k > cryptmode > param Testing Status > ---- > 0 HW CCMP/TKIP tested ok. > Note: HW crypto bypass not supported by ath10k hw in native WiFi > mode. > > 1 - mac80211 SW crypto tested ok. > - raw Tx frame injection tested ok. > > 2 HW CCMP/TKIP tested ok. > SW CCMP/TKIP tested ok. > Tested raw Tx encrypted frame injection ok. > > Signed-off-by: Liu CF/TW Kbuild bot found a sparse warning: >> drivers/net/wireless/ath/ath10k/core.c:34:14: sparse: symbol >> 'ath10k_cryptmode_param' was not declared. Should it be static? -- 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
Re: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
Hi Arend, On Mo, 2015-06-08 at 14:41 +0200, Arend van Spriel wrote: > On 06/08/15 14:35, Jörg Krause wrote: > > Hi, > > > > I've trouble creating the p2p interface on a BCM43362 wifi device > > running Linux kernel 4.0.4: > > > > # dmesg | grep brcmfmac > > [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware > > version = > > wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01 > > -b30a427d > > [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not a > > ISO3166 > > code > > [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout > > occurred > > > > Trying to add the p2p interface manually: > > > > # iw phy0 interface add p2p0 type __p2pdev > > [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC failed > > (-52) > > [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout > > occurred > > [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid key > > index (4) > > [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid key > > index (5) > > > > Any idea? > > Wondering whether it is similar to what Rafal reported. Can you do a > hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 I managed to set up the p2p interface by recompiling the kernel with CONFIG_BRCMDBG and loading the brcmfmac module with p2pon=1. I had a discussion some month ago with Hante Meulemann about setting up the p2p interface. This is one of his replies: "For what I can see from the log is that we don’t get the event from the FW indicating that the p2p interface was created. This probably means that there is a bug in this FW for this device. I need to discuss this to see how much priority we can give this. The best option for you for the moment is to use the legacy method with the 'p2pon=1' command." Best regards Jörg Krause -- 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
wireless-drivers-next deadline for 4.2
Hi, by the looks of it Linus will release 4.1 on June 21st. So anything which should go to 4.2 should be submitted to the list by Thursday June 11th. Anything later than that might need to wait for 4.3. -- 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
Re: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
Hi Arend, On Mo, 2015-06-08 at 14:41 +0200, Arend van Spriel wrote: > On 06/08/15 14:35, Jörg Krause wrote: > > Hi, > > > > I've trouble creating the p2p interface on a BCM43362 wifi device > > running Linux kernel 4.0.4: > > > > # dmesg | grep brcmfmac > > [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware > > version = > > wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01 > > -b30a427d > > [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not a > > ISO3166 > > code > > [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout > > occurred > > > > Trying to add the p2p interface manually: > > > > # iw phy0 interface add p2p0 type __p2pdev > > [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC failed > > (-52) > > [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout > > occurred > > [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid key > > index (4) > > [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid key > > index (5) > > > > Any idea? > > Wondering whether it is similar to what Rafal reported. Can you do a > hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 This is the output: $ hexdump -C brcmfmac43362-sdio.bin | tail -30 000357e0 03 37 a2 00 02 5e 02 f0 00 a8 01 87 60 05 60 6b |.7...^..`.`k| 000357f0 03 00 02 de 02 f0 00 00 00 68 2b eb 00 13 11 00 |.h+.| 00035800 b0 2c 13 00 17 a1 00 e0 5e 85 60 b7 a1 00 6b de |.,..^.`...k.| 00035810 86 23 33 11 01 86 e0 06 f7 f7 bf 00 02 de 02 f0 |.#3.| 00035820 00 00 00 b0 5e 8f 00 10 64 00 b0 5e 87 00 17 a3 |^...d..^| 00035830 00 b0 5e 8b 00 10 65 00 b0 5a 03 00 17 a1 00 68 |..^...e..Z.h| 00035840 41 93 00 13 1a 00 02 5e 02 f0 00 a2 00 b0 40 67 |A..^..@g| 00035850 00 16 01 00 e0 41 93 00 50 64 00 b0 5a 07 00 17 |.A..Pd..Z...| 00035860 a2 00 02 5e 02 f0 00 a8 00 e0 41 97 00 50 65 00 |...^..A..Pe.| 00035870 e8 5e 8f 00 37 a3 00 68 de 8f 00 13 15 00 02 de |.^..7..h| 00035880 02 f0 00 00 00 b0 5e 8f 00 10 64 00 b0 5e 87 00 |..^...d..^..| 00035890 17 a3 00 b0 5e 8b 00 10 65 00 b0 5a 03 00 17 80 |^...e..Z| 000358a0 00 68 41 93 00 13 28 00 02 5e 02 f0 0e 3f 00 b0 |.hA...(..^...?..| 000358b0 5e 07 00 16 01 00 e0 41 93 00 50 64 00 b0 5a 07 |^..A..Pd..Z.| 000358c0 00 17 81 00 02 5e 02 f0 0e 44 00 e0 41 97 00 50 |.^...D..A..P| 000358d0 65 00 e8 5e 8f 00 37 a3 00 68 de 8f 00 13 23 00 |e..^..7..h#.| 000358e0 02 de 02 f0 00 00 02 02 00 bf 00 01 88 02 03 c5 || 000358f0 73 00 01 b1 00 00 00 00 00 00 00 00 57 86 00 00 |s...W...| 00035900 a5 c1 e1 42 05 5a c3 59 dc 01 75 51 3e 5b 23 49 |...B.Z.Y..uQ>[#I| 00035910 47 28 67 69 45 00 5e 55 f8 f5 c9 7d 42 0a b3 09 |G(giE.^U...}B...| 00035920 01 bd 32 08 01 00 34 33 33 36 32 61 32 2d 72 6f |..2...43362a2-ro| 00035930 6d 6c 2f 73 64 69 6f 2d 67 2d 70 6e 6f 2d 70 6b |ml/sdio-g -pno-pk| 00035940 74 66 69 6c 74 65 72 2d 6b 65 65 70 61 6c 69 76 |tfilter -keepaliv| 00035950 65 2d 77 61 70 69 2d 77 6d 65 2d 70 32 70 20 56 |e-wapi-wme -p2p V| 00035960 65 72 73 69 6f 6e 3a 20 35 2e 39 30 2e 31 39 35 |ersion: 5.90.195| 00035970 2e 38 39 20 43 52 43 3a 20 62 64 31 65 33 65 35 |.89 CRC: bd1e3e5| 00035980 61 20 44 61 74 65 3a 20 4d 6f 6e 20 32 30 31 33 |a Date: Mon 2013| 00035990 2d 30 34 2d 32 32 20 31 37 3a 32 34 3a 34 34 20 |-04-22 17:24:44 | 000359a0 43 53 54 7d 00|CST}.| 000359a5 Best regards Jörg Krause -- 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: Debugfs entry to enable/disable BTC feature
"Li, Yanbo" writes:
>> -Original Message-
>> From: Valo, Kalle
>> Sent: Wednesday, May 27, 2015 5:57 AM
>> To: Li, Yanbo
>> Cc: dreamfly...@gmail.com; linux-wireless@vger.kernel.org;
>> michal.kaz...@tieto.com; ath...@lists.infradead.org
>> Subject: Re: [PATCH] ath10k: Debugfs entry to enable/disable BTC feature
>>
>> Yanbo Li writes:
>>
>> > As some radio have no connection with BT modules, enable the BTC
>> > feature will has some side effect if the radio's GPIO connect with any
>> > other HW modules. Add the control switcher "btc_feature" at debugfs
>> > and set the feature as disable by default to avoid such case.
>> >
>> > To enable this feature, execute:
>> > echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
>> > To disable:
>> > echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btc_feature
>>
>> I suspect "BTC" does not really tell much for most of the people and
>> acronyms should be always spelled out at least once.
>>
>> > Signed-off-by: Yanbo Li
>> >
>> > diff --git a/drivers/net/wireless/ath/ath10k/core.h
>> > b/drivers/net/wireless/ath/ath10k/core.h
>> > index 8444adf42195..6852e7fc5d5f 100644
>> > --- a/drivers/net/wireless/ath/ath10k/core.h
>> > +++ b/drivers/net/wireless/ath/ath10k/core.h
>> > @@ -720,6 +720,8 @@ struct ath10k {
>> >u32 fw_cold_reset_counter;
>> >} stats;
>> >
>> > + bool btc_feature;
>>
>> Could we use ar->dev_flags instead?
>
> This dev_flags currently used to mark some status, like the cradh, CAC
> running,
> The BTcoex feature is more likely a HW feature, there are seems different
> set.
>
> Maybe a separately hw_feature_flag is needed as there are some other HW
> feature
> That we want to enable/disable from user space.
I think we don't need a separate bitmap, we can use dev_flags just fine
for this.
>> > +static ssize_t ath10k_write_btc_feature(struct file *file,
>> > + const char __user *ubuf,
>> > + size_t count, loff_t *ppos)
>> > +{
>> > + struct ath10k *ar = file->private_data;
>> > + char buf[32];
>> > + size_t buf_size;
>> > + bool val;
>> > +
>> > + buf_size = min(count, (sizeof(buf) - 1));
>> > + if (copy_from_user(buf, ubuf, buf_size))
>> > + return -EFAULT;
>> > +
>> > + buf[buf_size] = '\0';
>> > + if (strtobool(buf, &val) != 0) {
>> > + ath10k_warn(ar, "Wrong BTC feature setting\n");
>> > + return -EINVAL;
>> > + }
>> > +
>> > + mutex_lock(&ar->conf_mutex);
>> > + ar->btc_feature = val;
>> > + queue_work(ar->workqueue, &ar->restart_work);
>> > + mutex_unlock(&ar->conf_mutex);
>>
>> Shouldn't we test ATH10K_STATE_ON first?
>
> The restart process will judge by itself whether the device is on or not, and
> print below warning in that case:
>
> [797424.496190] ath10k_pci :05:00.0: cannot restart a device that
> hasn't been started
That's just buggy, ath10k should not print anything if a setting is
changed while interface is down. It's much better we have the check for
ATH10K_STATE_ON here.
--
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
brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
Hi, I've trouble creating the p2p interface on a BCM43362 wifi device running Linux kernel 4.0.4: # dmesg | grep brcmfmac [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred Trying to add the p2p interface manually: # iw phy0 interface add p2p0 type __p2pdev [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC failed (-52) [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4) [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5) Any idea? Best regards Jörg Krause -- 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: enable VHT for IBSS
Janusz Dziedzic writes: > Enable VHT support for IBSS. > > Signed-off-by: Janusz Dziedzic You should give background info here. For example, why did you enable now and not earlier? How did you test it? What user space requirements (wpasupplicant version etc) there are? What kind of throughput did you see? -- 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
Re: brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred
On 06/08/15 14:35, Jörg Krause wrote: Hi, I've trouble creating the p2p interface on a BCM43362 wifi device running Linux kernel 4.0.4: # dmesg | grep brcmfmac [7.010870] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d [7.158905] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 11.007164] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred Trying to add the p2p interface manually: # iw phy0 interface add p2p0 type __p2pdev [ 372.042704] brcmfmac: brcmf_link_down: WLC_DISASSOC failed (-52) [ 373.637263] brcmfmac: brcmf_p2p_create_p2pdev: timeout occurred [ 373.679377] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4) [ 373.685733] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5) Any idea? Wondering whether it is similar to what Rafal reported. Can you do a hexdump, ie. hexdump -C brcmfmac43362-sdio.bin | tail -30 Regards, Arend Best regards Jörg Krause -- 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 3/4] brcmfmac: remove watchdog reset from brcmf_pcie_buscoreprep()
The watchdog reset as done in brcmf_pcie_buscoreprep() is not
sufficient. It needs to modify PCIe core registers as well
which is properly done by brcmf_pcie_reset_device() after the
chip recognition is done. So the faulty watchdog reset can be
removed as it was causing driver reload to fail and hang the
system requiring a power-cycle. Instead the call to to the
brcmf_pcie_reset_device() function is done twice in the unload.
Reviewed-by: Hante Meuleman
Reviewed-by: Daniel (Deognyoun) Kim
Reviewed-by: Franky (Zhenhui) Lin
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
index 37a2624..3a98c43 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
@@ -1629,20 +1629,7 @@ static void brcmf_pcie_buscore_write32(void *ctx, u32
addr, u32 value)
static int brcmf_pcie_buscoreprep(void *ctx)
{
- struct brcmf_pciedev_info *devinfo = (struct brcmf_pciedev_info *)ctx;
- int err;
-
- err = brcmf_pcie_get_resource(devinfo);
- if (err == 0) {
- /* Set CC watchdog to reset all the cores on the chip to bring
-* back dongle to a sane state.
-*/
- brcmf_pcie_buscore_write32(ctx, CORE_CC_REG(SI_ENUM_BASE,
- watchdog), 4);
- msleep(100);
- }
-
- return err;
+ return brcmf_pcie_get_resource(ctx);
}
@@ -1824,6 +1811,7 @@ brcmf_pcie_remove(struct pci_dev *pdev)
brcmf_pcie_intr_disable(devinfo);
brcmf_detach(&pdev->dev);
+ brcmf_pcie_reset_device(devinfo);
kfree(bus->bus_priv.pcie);
kfree(bus->msgbuf->flowrings);
--
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
[PATCH 4/4] brcmfmac: use debugfs_create_devm_seqfile() helper function
Some time ago the function debugfs_create_devm_seqfile() was
introduced in debugfs. The caller simply needs to provide a
device pointer and read function. The function brcmf_debugfs_add_entry()
is now simply a wrapper only doing the work for CONFIG_BRCMDBG.
Reviewed-by: Hante Meuleman
Reviewed-by: Franky (Zhenhui) Lin
Reviewed-by: Daniel (Deognyoun) Kim
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmfmac/debug.c | 40 +++--
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/debug.c
b/drivers/net/wireless/brcm80211/brcmfmac/debug.c
index 10a9221..2d6d005 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/debug.c
@@ -64,44 +64,12 @@ struct dentry *brcmf_debugfs_get_devdir(struct brcmf_pub
*drvr)
return drvr->dbgfs_dir;
}
-struct brcmf_debugfs_entry {
- int (*read)(struct seq_file *seq, void *data);
- struct brcmf_pub *drvr;
-};
-
-static int brcmf_debugfs_entry_open(struct inode *inode, struct file *f)
-{
- struct brcmf_debugfs_entry *entry = inode->i_private;
-
- return single_open(f, entry->read, entry->drvr->bus_if->dev);
-}
-
-static const struct file_operations brcmf_debugfs_def_ops = {
- .owner = THIS_MODULE,
- .open = brcmf_debugfs_entry_open,
- .release = single_release,
- .read = seq_read,
- .llseek = seq_lseek
-};
-
int brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
int (*read_fn)(struct seq_file *seq, void *data))
{
- struct dentry *dentry = drvr->dbgfs_dir;
- struct brcmf_debugfs_entry *entry;
-
- if (IS_ERR_OR_NULL(dentry))
- return -ENOENT;
-
- entry = devm_kzalloc(drvr->bus_if->dev, sizeof(*entry), GFP_KERNEL);
- if (!entry)
- return -ENOMEM;
-
- entry->read = read_fn;
- entry->drvr = drvr;
-
- dentry = debugfs_create_file(fn, S_IRUGO, dentry, entry,
-&brcmf_debugfs_def_ops);
+ struct dentry *e;
- return PTR_ERR_OR_ZERO(dentry);
+ e = debugfs_create_devm_seqfile(drvr->bus_if->dev, fn,
+ drvr->dbgfs_dir, read_fn);
+ return PTR_ERR_OR_ZERO(e);
}
--
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
[PATCH 2/4] brcmfmac: remove chipinfo debugfs entry
The information provided by chipinfo is also provided by the
revinfo debugfs entry. Removing it from debugfs.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmfmac/debug.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/debug.c
b/drivers/net/wireless/brcm80211/brcmfmac/debug.c
index 9b473d5..10a9221 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/debug.c
@@ -41,15 +41,6 @@ void brcmf_debugfs_exit(void)
root_folder = NULL;
}
-static int brcmf_debugfs_chipinfo_read(struct seq_file *seq, void *data)
-{
- struct brcmf_bus *bus = dev_get_drvdata(seq->private);
-
- seq_printf(seq, "chip: %x(%u) rev %u\n",
- bus->chip, bus->chip, bus->chiprev);
- return 0;
-}
-
int brcmf_debugfs_attach(struct brcmf_pub *drvr)
{
struct device *dev = drvr->bus_if->dev;
@@ -58,7 +49,6 @@ int brcmf_debugfs_attach(struct brcmf_pub *drvr)
return -ENODEV;
drvr->dbgfs_dir = debugfs_create_dir(dev_name(dev), root_folder);
- brcmf_debugfs_add_entry(drvr, "chipinfo", brcmf_debugfs_chipinfo_read);
return PTR_ERR_OR_ZERO(drvr->dbgfs_dir);
}
--
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
[PATCH 0/4] brcmfmac: pcie fixes and debugfs cleanup
Summary of this series: * fix module reload issue for PCIe. * improving msgbuf protocol for PCIe devices. * cleanup of the debugfs code. This series is intended for v4.2 kernel and applies to the master branch of the wireless-drivers-next repository. Arend van Spriel (3): brcmfmac: remove chipinfo debugfs entry brcmfmac: remove watchdog reset from brcmf_pcie_buscoreprep() brcmfmac: use debugfs_create_devm_seqfile() helper function Hante Meuleman (1): brcmfmac: Update msgbuf read pointer quicker. .../net/wireless/brcm80211/brcmfmac/commonring.c | 19 .../net/wireless/brcm80211/brcmfmac/commonring.h | 3 +- drivers/net/wireless/brcm80211/brcmfmac/debug.c| 50 ++ drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c | 12 +- drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 16 +-- 5 files changed, 27 insertions(+), 73 deletions(-) -- 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
[PATCH 1/4] brcmfmac: Update msgbuf read pointer quicker.
From: Hante Meuleman
On device to host data using msgbuf the read pointer gets updated
once all data is processed. Updating this pointer more frequently
allows the firmware to add more data quicker. This will result in
slightly higher and more stable throughput on CPU bounded host
processors.
Reviewed-by: Arend Van Spriel
Reviewed-by: Franky (Zhenhui) Lin
Reviewed-by: Pieter-Paul Giesberts
Signed-off-by: Hante Meuleman
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/brcm80211/brcmfmac/commonring.c | 19 ---
drivers/net/wireless/brcm80211/brcmfmac/commonring.h | 3 ++-
drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c | 12 +++-
3 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/commonring.c
b/drivers/net/wireless/brcm80211/brcmfmac/commonring.c
index 26c6587..7b0e521 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/commonring.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/commonring.c
@@ -223,8 +223,6 @@ void brcmf_commonring_write_cancel(struct brcmf_commonring
*commonring,
void *brcmf_commonring_get_read_ptr(struct brcmf_commonring *commonring,
u16 *n_items)
{
- void *ret_addr;
-
if (commonring->cr_update_wptr)
commonring->cr_update_wptr(commonring->cr_ctx);
@@ -235,19 +233,18 @@ void *brcmf_commonring_get_read_ptr(struct
brcmf_commonring *commonring,
if (*n_items == 0)
return NULL;
- ret_addr = commonring->buf_addr +
- (commonring->r_ptr * commonring->item_len);
-
- commonring->r_ptr += *n_items;
- if (commonring->r_ptr == commonring->depth)
- commonring->r_ptr = 0;
-
- return ret_addr;
+ return commonring->buf_addr +
+ (commonring->r_ptr * commonring->item_len);
}
-int brcmf_commonring_read_complete(struct brcmf_commonring *commonring)
+int brcmf_commonring_read_complete(struct brcmf_commonring *commonring,
+ u16 n_items)
{
+ commonring->r_ptr += n_items;
+ if (commonring->r_ptr == commonring->depth)
+ commonring->r_ptr = 0;
+
if (commonring->cr_write_rptr)
return commonring->cr_write_rptr(commonring->cr_ctx);
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/commonring.h
b/drivers/net/wireless/brcm80211/brcmfmac/commonring.h
index 3d40401..b850336 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/commonring.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/commonring.h
@@ -62,7 +62,8 @@ void brcmf_commonring_write_cancel(struct brcmf_commonring
*commonring,
u16 n_items);
void *brcmf_commonring_get_read_ptr(struct brcmf_commonring *commonring,
u16 *n_items);
-int brcmf_commonring_read_complete(struct brcmf_commonring *commonring);
+int brcmf_commonring_read_complete(struct brcmf_commonring *commonring,
+ u16 n_items);
#define brcmf_commonring_n_items(commonring) (commonring->depth)
#define brcmf_commonring_len_item(commonring) (commonring->item_len)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
b/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
index 1b47de0..898c380 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c
@@ -75,6 +75,8 @@
#define BRCMF_MSGBUF_DELAY_TXWORKER_THRS 96
#define BRCMF_MSGBUF_TRICKLE_TXWORKER_THRS 32
+#define BRCMF_MSGBUF_UPDATE_RX_PTR_THRS48
+
struct msgbuf_common_hdr {
u8 msgtype;
@@ -1257,19 +1259,27 @@ static void brcmf_msgbuf_process_rx(struct brcmf_msgbuf
*msgbuf,
{
void *buf;
u16 count;
+ u16 processed;
again:
buf = brcmf_commonring_get_read_ptr(commonring, &count);
if (buf == NULL)
return;
+ processed = 0;
while (count) {
brcmf_msgbuf_process_msgtype(msgbuf,
buf + msgbuf->rx_dataoffset);
buf += brcmf_commonring_len_item(commonring);
+ processed++;
+ if (processed == BRCMF_MSGBUF_UPDATE_RX_PTR_THRS) {
+ brcmf_commonring_read_complete(commonring, processed);
+ processed = 0;
+ }
count--;
}
- brcmf_commonring_read_complete(commonring);
+ if (processed)
+ brcmf_commonring_read_complete(commonring, processed);
if (commonring->r_ptr == 0)
goto again;
--
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
[PATCH 2/2] ath10k: print htt op_version upon driver boot
HTT version itself isn't sufficient to know what HTT version given firmware blob uses. Hence print the recently introduced HTT op version code. While at it make the info string a bit more consistent and clear. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/debug.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c index 8a4edfd36e47..edf6047997a7 100644 --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -128,7 +128,7 @@ void ath10k_print_driver_info(struct ath10k *ar) ath10k_core_get_fw_features_str(ar, fw_features, sizeof(fw_features)); - ath10k_info(ar, "%s (0x%08x, 0x%08x%s%s%s) fw %s api %d htt %d.%d wmi %d cal %s max_sta %d features %s\n", + ath10k_info(ar, "%s (0x%08x, 0x%08x%s%s%s) fw %s api %d htt-ver %d.%d wmi-op %d htt-op %d cal %s max-sta %d features %s\n", ar->hw_params.name, ar->target_version, ar->chip_id, @@ -141,6 +141,7 @@ void ath10k_print_driver_info(struct ath10k *ar) ar->htt.target_version_major, ar->htt.target_version_minor, ar->wmi.op_version, + ar->htt.op_version, ath10k_cal_mode_str(ar->cal_mode), ar->max_num_stations, fw_features); -- 2.1.4 -- 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 1/2] ath10k: dump fw features during probing
This should help when analysing problems from
users and spot fw api blob problems easier.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/core.c | 45 +
drivers/net/wireless/ath/ath10k/core.h | 3 +++
drivers/net/wireless/ath/ath10k/debug.c | 9 +--
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 59496a90ad5e..efc648a973d0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -103,6 +103,51 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
},
};
+static const char *const ath10k_core_fw_feature_str[] = {
+ [ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX] = "wmi-mgmt-rx",
+ [ATH10K_FW_FEATURE_WMI_10X] = "wmi-10.x",
+ [ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX] = "has-wmi-mgmt-tx",
+ [ATH10K_FW_FEATURE_NO_P2P] = "no-p2p",
+ [ATH10K_FW_FEATURE_WMI_10_2] = "wmi-10.2",
+ [ATH10K_FW_FEATURE_MULTI_VIF_PS_SUPPORT] = "multi-vif-ps",
+ [ATH10K_FW_FEATURE_WOWLAN_SUPPORT] = "wowlan",
+ [ATH10K_FW_FEATURE_IGNORE_OTP_RESULT] = "ignore-otp",
+ [ATH10K_FW_FEATURE_NO_NWIFI_DECAP_4ADDR_PADDING] = "no-4addr-pad",
+ [ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT] = "skip-clock-init",
+};
+
+static unsigned int ath10k_core_get_fw_feature_str(char *buf,
+ size_t buf_len,
+ enum ath10k_fw_features feat)
+{
+ if (feat >= ARRAY_SIZE(ath10k_core_fw_feature_str) ||
+ WARN_ON(!ath10k_core_fw_feature_str[feat])) {
+ return scnprintf(buf, buf_len, "bit%d", feat);
+ } else {
+ return scnprintf(buf, buf_len, "%s",
+ath10k_core_fw_feature_str[feat]);
+ }
+}
+
+void ath10k_core_get_fw_features_str(struct ath10k *ar,
+char *buf,
+size_t buf_len)
+{
+ unsigned int len = 0;
+ int i;
+
+ for (i = 0; i < ATH10K_FW_FEATURE_COUNT; i++) {
+ if (test_bit(i, ar->fw_features)) {
+ if (len > 0)
+ len += scnprintf(buf + len, buf_len - len, ",");
+
+ len += ath10k_core_get_fw_feature_str(buf + len,
+ buf_len - len,
+ i);
+ }
+ }
+}
+
static void ath10k_send_suspend_complete(struct ath10k *ar)
{
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot suspend complete\n");
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 45f9603a0868..74a6b6883ce5 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -758,6 +758,9 @@ struct ath10k *ath10k_core_create(size_t priv_size, struct
device *dev,
enum ath10k_hw_rev hw_rev,
const struct ath10k_hif_ops *hif_ops);
void ath10k_core_destroy(struct ath10k *ar);
+void ath10k_core_get_fw_features_str(struct ath10k *ar,
+char *buf,
+size_t max_len);
int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode);
int ath10k_wait_for_suspend(struct ath10k *ar, u32 suspend_opt);
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8fa606a9c4dd..8a4edfd36e47 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -124,7 +124,11 @@ EXPORT_SYMBOL(ath10k_info);
void ath10k_print_driver_info(struct ath10k *ar)
{
- ath10k_info(ar, "%s (0x%08x, 0x%08x%s%s%s) fw %s api %d htt %d.%d wmi
%d cal %s max_sta %d\n",
+ char fw_features[128];
+
+ ath10k_core_get_fw_features_str(ar, fw_features, sizeof(fw_features));
+
+ ath10k_info(ar, "%s (0x%08x, 0x%08x%s%s%s) fw %s api %d htt %d.%d wmi
%d cal %s max_sta %d features %s\n",
ar->hw_params.name,
ar->target_version,
ar->chip_id,
@@ -138,7 +142,8 @@ void ath10k_print_driver_info(struct ath10k *ar)
ar->htt.target_version_minor,
ar->wmi.op_version,
ath10k_cal_mode_str(ar->cal_mode),
- ar->max_num_stations);
+ ar->max_num_stations,
+ fw_features);
ath10k_info(ar, "debug %d debugfs %d tracing %d dfs %d testmode %d\n",
config_enabled(CONFIG_ATH10K_DEBUG),
config_enabled(CONFIG_ATH10K_DEBUGFS),
--
2.1.4
--
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
Re: [PATCH 1/2] bcma: make calls to PCI hostmode functions config-safe
Rafał Miłecki writes: > Signed-off-by: Rafał Miłecki Thanks, both applied manually. And in the future please avoid empty commit logs. -- 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
Re: [PATCH FIX] b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset
Rafał Miłecki writes: > It seems Broadcom released two devices with conflicting device id. There > are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they > can be found in routers, e.g. Netgear WNR834Bv2. However, according to > Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY). > It's unsure if they meant PCI device id, or "virtual" id (from SPROM). > To distinguish these devices lets check PHY type (G vs. N). > > Signed-off-by: Rafał Miłecki > Cc: # 3.16+ Thanks, applied manually. -- 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
Re: [PATCH RESEND] brcmfmac: use direct data pointer in NVRAM parser struct
Rafał Miłecki writes: > As we plan to add support for platform NVRAM we should store direct > data pointer without the extra struct firmware layer. This will allow > us to support other sources with the only requirement being u8 buffer. > > Signed-off-by: Rafał Miłecki > Acked-by: Arend van Spriel Thanks, applied manually. -- 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
Re: [PATCH 1/4] mt7601u: unify paged and non-paged RX dma paths
Jakub Kicinski writes: > From: Jakub Kicinski > > Signed-off-by: Jakub Kicinski Thanks, applied all four manually. -- 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
Re: [PATCH] brcmfmac: set wiphy perm_addr to hardware MAC address
Rafał Miłecki writes: > This allows e.g. user space to use /sys/class/ieee80211/*/macaddress > > Signed-off-by: Rafał Miłecki Thanks, applied manually. -- 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
Re: [PATCH] brcmfmac: support NVRAMs containing pci devpaths (instead of pcie)
Rafał Miłecki writes: > Recently Broadcom added support for NVRAMs with entries for multiple > PCIe devices. One of the supported formats is based on prefixes defined > like: devpath0=pcie/1/4/ and entries like 0:foo=bar 0:baz=qux etc. > > Unfortunately there are also a bit older devices using different way of > defining prefixes, e.g. SmartRG SR400ac (2 x BCM43602) with entries: > devpath0=pci/1/1/ > devpath1=pci/2/1 > Broadcom stated this old format will never be used/supported by brcmfmac > but given the simplicity of this patch I'll insist on supporting it. > > Signed-off-by: Rafał Miłecki Thanks, applied manually. -- 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] ath10k: prevent memory leak in wmi rx ops
Found during code review. This was pretty much impossible to happen but better safe than sorry. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 3 ++- drivers/net/wireless/ath/ath10k/wmi.c | 8 +--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c index 563fde73623c..8fdba3865c96 100644 --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c @@ -402,7 +402,7 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct sk_buff *skb) id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID); if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL) - return; + goto out; trace_ath10k_wmi_event(ar, id, skb->data, skb->len); @@ -521,6 +521,7 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct sk_buff *skb) break; } +out: dev_kfree_skb(skb); } diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index 77220b0f0e89..c2e86edfd66f 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -3222,7 +3222,7 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb) id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID); if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL) - return; + goto out; trace_ath10k_wmi_event(ar, id, skb->data, skb->len); @@ -3326,6 +3326,7 @@ static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb) break; } +out: dev_kfree_skb(skb); } @@ -3339,7 +3340,7 @@ static void ath10k_wmi_10_1_op_rx(struct ath10k *ar, struct sk_buff *skb) id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID); if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL) - return; + goto out; trace_ath10k_wmi_event(ar, id, skb->data, skb->len); @@ -3462,7 +3463,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb) id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID); if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL) - return; + goto out; trace_ath10k_wmi_event(ar, id, skb->data, skb->len); @@ -3570,6 +3571,7 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, struct sk_buff *skb) break; } +out: dev_kfree_skb(skb); } -- 2.1.4 -- 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: kmalloc panic
On Sat, 2015-06-06 at 19:10 -0400, Toan Pham wrote: > I am experiencing a similar issue on another system (at91sam9n12) that > uses Redpine Signal Wireless Driver 1.1.0. I do not know the root > cause yet, but it may be related to the Redpine Signals driver. Will > update this mailing list if the problem is with the redpine driver. > thanks Please don't top-post. It's almost certainly related to the redpine driver, but apparently not using the upstream "rsi" driver ... you're in the wrong place here. I'll note that the driver should probably be converted to cfg80211 instead of having its own wext handling (which I'd think is causing this issue) 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
mac80211 modification
Hi, I want to inject particular data into beacon frame in Android device. I found two approaches: 1. Write loadable kernel module. 2. Modify MAC80211 subsystem In the first approach, I found that I could not include directly source code from MAC80211 sub system in folder /net/mac80211/. Thus, I used the second approach, but, every time I change any line of source code, it takes 30 minutes to build zImage then install new kernel in my Android device. Finally, I was stuck. Therefore, my questions are: 1. Is it right approach to modify MAC80211 subsystem? 2. Are there any faster approach to modify MAC80211 and test source code? 3. I am curious about the way you write code and test MAC80211. Could you explain in details? Best Regards, Duy Tai. Nguyen Duy Tai Ym: kimjiwoo741 Phone: +841676919422 Faculty of Computer Science and Engineering. University of Technology HCMC. -- 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 a case of incorrect metric used when forwarding a PREQ
As mentioned in Section 13.10.9.3 Case E2, the PREQ forwarding should use metric "as received + own metric toward transmitter of received PREQ". So you are right. Just MP_F_RF bit is no longer use. After replying with PREP, forwarding the PREQ by setting the IEEE80211_PREQ_TO_FLAG in the per target flags. --- Chun-Yeow On Mon, Jun 8, 2015 at 4:07 PM, Yeoh Chun-Yeow wrote: > Hi, Alexis Green > > I just take a look back on the code before implementing the Proactive > PREQ for PREP. For the case of reply and forward (target_flags & > MP_F_RF), the previous metric used is the one which resolved from > mpath->metric. > > Refer here: > https://github.com/o11s/open80211s/blob/o11s-0.4.2/net/mac80211/mesh_hwmp.c > > But to say that, I cannpt confirm whether this is correct. The > standard 802.11-2012 has no longer specified bit-1 MP_F_RF (Refer > section 8.4.2.115 per target flag). So maybe it is not relevant > anymore. We may need to remove as well. > > > Chun-Yeow -- 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: [1/2] mwifiex: change debug dump issue since skb maybe null
> From: Zhaoyang Liu > > This patch fixes semantic warning for debugging data dump feature. > Previous code is based on the assumption that skb is not null. > New change makes sure that we already have data buffer. > > Reported-by: Dan Carpenter > Signed-off-by: Zhaoyang Liu > Signed-off-by: Avinash Patil Thanks, 2 patches applied to wireless-drivers-next.git: 7a56c4168e44 mwifiex: change debug dump issue since skb maybe null 39d94eaa76e7 mwifiex: update current config_band info in start_ap 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
Re: rtlwifi: rtl8192cu: Fix performance issue.
> After physical reconnect, the rtl8192cu chipset shows low > transmission rates.It cause is that variable "iqk_initialized" > do not de-initialized. So I add this code. > > Signed-off-by: Taehee Yoo > Acked-by: Larry Finger Thanks, applied to wireless-drivers-next.git. 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
Re: [PATCHv5, 01/17] mwifiex: verbose logging for association failure messages
> This patch adds more detailed information about association failures > - reason and states. > > Signed-off-by: Avinash Patil > Signed-off-by: Cathy Luo Thanks, 17 patches applied to wireless-drivers-next.git: 12d111097428 mwifiex: verbose logging for association failure messages c951a6671340 mwifiex: correct bss_type assignment ed5cfbe6ba27 mwifiex: support AP reset after bss_stop 88af6f053ad8 mwifiex: enable 11d after bss reset 7b7166256d27 mwifiex: reset 11h active flag when chandef does not require dfs 511c8989fe5a mwifiex: disable CAC upon radar detection event 7ee38bf4edea mwifiex: add cfg80211 get_channel handler 442f6f9b49c8 mwifiex: maintain station statistic in uap mode b21783e94e20 mwifiex: add sta_list firmware command 8baca1a34d4c mwifiex: dump station support in uap mode 8a73dd639889 mwifiex: parse power constraint IE from Tail e4f59aca0b63 mwifiex: support downloading IEs from tail 3e6f8a4b955f mwifiex: drop block-ack action frames c2b6680f63ff mwifiex: advertise PS ON by default support to cfg80211 debfc6008169 mwifiex: update AP WMM settings from BSS_START event 719a25e33153 mwifiex: using right tid for addressing ra_list ec264a43029f mwifiex: do not decrease tx_pending for AMSDU packet once more 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
Re: [PATCH v2 0/2] staging: rtl8723au: core: endianness issues
Thanks. These look nice. 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: ath9k: fix DMA stop sequence for AR9003+
> AR93xx and newer needs to stop rx before tx to avoid getting the DMA > engine or MAC into a stuck state. > This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam. > > Cc: sta...@vger.kernel.org > Signed-off-by: Felix Fietkau Thanks, applied to wireless-drivers-next.git. 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
Re: [5/9] wl1251: drop unneeded goto
> From: Julia Lawall > > Delete jump to a label on the next line, when that label is not > used elsewhere. > > A simplified version of the semantic patch that makes this change is as > follows: (http://coccinelle.lip6.fr/) > > // > @r@ > identifier l; > @@ > > -if (...) goto l; > -l: > // > > Signed-off-by: Julia Lawall Thanks, applied to wireless-drivers-next.git. 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
Re: [PATCH FIX] b43: fix support for 14e4:4321 PCI dev with BCM4321 chipset
Rafał Miłecki writes: > It seems Broadcom released two devices with conflicting device id. There > are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they > can be found in routers, e.g. Netgear WNR834Bv2. However, according to > Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY). > It's unsure if they meant PCI device id, or "virtual" id (from SPROM). > To distinguish these devices lets check PHY type (G vs. N). > > Signed-off-by: Rafał Miłecki > Cc: # 3.16+ > --- > Kalle: I'm aware it's quite late for a 4.1 fix, this bug was reported just > today. I guess you can just take it for wireless-drivers-next and let stable > guys handle it. Yeah, I don't think this is critical enough to send this to 4.1. So let's push this via wireless-drivers-next. -- 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
Re: wl18xx: wlconf kernel compatibility
Hi Yaniv, On Sun, Jun 7, 2015 at 9:30 AM, Machani, Yaniv wrote: > Hi, > As the configuration file is HW depended it should be created per platform, > we have set this wiki page and script to help with initial setup : > http://processors.wiki.ti.com/index.php/Open_Source_Wireless_Connectivity_wlconf > > We have also pushed a patch that makes sure the driver will not crash if > there is a file size mismatch, > and will fall back to default. What about following proposal. I'm learning libxmlrpc now. It has following struct *xmlrpc_server_abyss_parms* (http://xmlrpc-c.sourceforge.net/doc/libxmlrpc_server_abyss.html#server_abyss_parameters). If new parameter will be added, it is done via appending this to the bottom of the structure. This way old structure is still preserved. The user of this library must specify till what parameter this structure should be used (parmSize parameter): oid xmlrpc_server_abyss(xmlrpc_env *const envP, xmlrpc_server_abyss_parms * const parmP, unsigned int const parmSize); This will be achieved via XMLRPC_APSIZE(log_file_name), i.e. macro with structure field name. This way old programs still can work with newer library. This approach could be taken for wl18xx-conf.bin. Driver calculates the size of known parameters and conf file size and as long as the size of wl18xx-conf.bin is not smaller than known size, the driver can use it. What do you think about it? Yegor >> -Original Message- >> From: Yegor Yefremov [mailto:yegorsli...@googlemail.com] >> Sent: Saturday, June 06, 2015 6:19 PM >> To: Kalle Valo >> Cc: linux-wireless@vger.kernel.org; Machani, Yaniv; Eliad Peller; Marc >> Kleine- >> Budde >> Subject: Re: wl18xx: wlconf kernel compatibility >> >> Hi Kalle, >> >> On Sat, Jun 6, 2015 at 3:27 PM, Kalle Valo wrote: >> > Yegor Yefremov writes: >> > >> >> How do I know, which wlconf version is compatible with which kernel >> >> version? I have following problem: >> >> >> >> I have *.INI file for my particular WLAN chip. This file will be used >> >> to produce wl18xx-conf.bin. The size of this file will be check >> >> during device initialization. Depending on which kernel version is >> >> used the size of the required file differs. For example kernel 3.18 >> >> requires wl18xx-conf.bin to have 1221 bytes, 4.1 expects 1226 bytes. >> >> Recent wlconf (git://git.ti.com/wilink8-wlan/18xx-ti-utils.git) >> >> produces 1229 bytes files. >> >> >> >> How should I determine correct wlconf version? >> > >> > I also complained about something along these lines earlier, this is >> > not how upstream drivers are supposed to work. Users should not be >> > forced to find correct files from somewhere, instead everything should >> > just work out of box. >> > >> > Can anyone help Yegor to solve his problem? But in the long run wl18xx >> > really should manage this better. >> >> I could solve the problem, though for the future it should be clear, what >> wlconf >> version to use. >> >> See my post here: >> http://e2e.ti.com/support/wireless_connectivity/f/307/p/426229/1523235#152 >> 3235 >> >> Yegor -- 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 a case of incorrect metric used when forwarding a PREQ
Hi, Alexis Green I just take a look back on the code before implementing the Proactive PREQ for PREP. For the case of reply and forward (target_flags & MP_F_RF), the previous metric used is the one which resolved from mpath->metric. Refer here: https://github.com/o11s/open80211s/blob/o11s-0.4.2/net/mac80211/mesh_hwmp.c But to say that, I cannpt confirm whether this is correct. The standard 802.11-2012 has no longer specified bit-1 MP_F_RF (Refer section 8.4.2.115 per target flag). So maybe it is not relevant anymore. We may need to remove as well. Chun-Yeow -- 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: [WEXT]: multiple calls for SIOCGIWSTATS return same value
On Sat, 2015-06-06 at 20:37 -0600, Gerrit Renker wrote: > A problem has been found in recent kernels where multiple > calls using SIOCGIWSTATS return the same, identical value. Which "value"? I believe these return a number of different values. What are the returned values? Are they perhaps just 0? Is the application a 32-bit application running on a 64-bit machine perhaps? There have been bugs in that area in the past, though I don't believe anything changed between 3.19 and 4.0. In fact, in wext nothing really changed at all - only some internal maintenance (commit 319090bf6c75e3ad42a8c74973be5e78ae4f948f) > This behaviour is observable both using 'iwconfig ' > and wavemon info screen, where it was reported in [1]. > > It looks as if this is a WEXT issue, since on the same > system multiple 'iw dev station dump' calls > return different signal level values. > > I can confirm the behaviour on davem 4.1.0-rc6 net tree > at commit c46a024ea5, it has been reported on [1] for > fedora 21 with kernel-4.0.4-201/2 as well. > > That report also stated that the behaviour does not occur > on kernel-3.19.7-200. Have not had time to bisect yet. > > Thanks for any hints that can help resolve this. I have no idea, sorry. 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 1/4] mt7601u: unify paged and non-paged RX dma paths
Jakub Kicinski writes: > From: Jakub Kicinski > > Signed-off-by: Jakub Kicinski No need to change anything now but in the future please avoid empty commit logs. And at some point I'll start automatically rejecting patches with empty commit logs so better get used to this already now. -- 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
