* [PATCH 3/8] wireless: brcmfmac: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:54 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Brett Rudley',
'Arend van Spriel', 'Franky (Zhenhui) Lin',
'Hante Meuleman'
In-Reply-To: <005101ceae02$9cbb95f0$d632c1d0$%han@samsung.com>
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
index 64f4a2b..592ae13 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
@@ -468,7 +468,7 @@ static int brcmf_sdio_pd_probe(struct platform_device *pdev)
brcmf_dbg(SDIO, "Enter\n");
- brcmfmac_sdio_pdata = pdev->dev.platform_data;
+ brcmfmac_sdio_pdata = dev_get_platdata(&pdev->dev);
if (brcmfmac_sdio_pdata->power_on)
brcmfmac_sdio_pdata->power_on();
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/8] wireless: ath9k: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:53 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Luis R. Rodriguez',
'Jouni Malinen', 'Vasanthakumar Thiagarajan',
'Senthil Balasubramanian'
In-Reply-To: <005101ceae02$9cbb95f0$d632c1d0$%han@samsung.com>
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/wireless/ath/ath9k/ahb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 072e4b5..2dff276 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -54,7 +54,7 @@ static bool ath_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
struct platform_device *pdev = to_platform_device(sc->dev);
struct ath9k_platform_data *pdata;
- pdata = (struct ath9k_platform_data *) pdev->dev.platform_data;
+ pdata = dev_get_platdata(&pdev->dev);
if (off >= (ARRAY_SIZE(pdata->eeprom_data))) {
ath_err(common,
"%s: flash read failed, offset %08x is out of range\n",
@@ -84,7 +84,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
struct ath_hw *ah;
char hw_name[64];
- if (!pdev->dev.platform_data) {
+ if (!dev_get_platdata(&pdev->dev)) {
dev_err(&pdev->dev, "no platform data specified\n");
return -EINVAL;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/8] wireless: ath5k: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:51 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Jiri Slaby',
'Nick Kossifidis', 'Luis R. Rodriguez'
In-Reply-To: <005101ceae02$9cbb95f0$d632c1d0$%han@samsung.com>
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/wireless/ath/ath5k/ahb.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
index e9bc9e6..79bffe1 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -37,12 +37,9 @@ ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
{
struct ath5k_hw *ah = common->priv;
struct platform_device *pdev = to_platform_device(ah->dev);
- struct ar231x_board_config *bcfg = pdev->dev.platform_data;
+ struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
u16 *eeprom, *eeprom_end;
-
-
- bcfg = pdev->dev.platform_data;
eeprom = (u16 *) bcfg->radio;
eeprom_end = ((void *) bcfg->config) + BOARD_CONFIG_BUFSZ;
@@ -57,7 +54,7 @@ ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
int ath5k_hw_read_srev(struct ath5k_hw *ah)
{
struct platform_device *pdev = to_platform_device(ah->dev);
- struct ar231x_board_config *bcfg = pdev->dev.platform_data;
+ struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
ah->ah_mac_srev = bcfg->devid;
return 0;
}
@@ -65,7 +62,7 @@ int ath5k_hw_read_srev(struct ath5k_hw *ah)
static int ath5k_ahb_eeprom_read_mac(struct ath5k_hw *ah, u8 *mac)
{
struct platform_device *pdev = to_platform_device(ah->dev);
- struct ar231x_board_config *bcfg = pdev->dev.platform_data;
+ struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
u8 *cfg_mac;
if (to_platform_device(ah->dev)->id == 0)
@@ -87,7 +84,7 @@ static const struct ath_bus_ops ath_ahb_bus_ops = {
/*Initialization*/
static int ath_ahb_probe(struct platform_device *pdev)
{
- struct ar231x_board_config *bcfg = pdev->dev.platform_data;
+ struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
struct ath5k_hw *ah;
struct ieee80211_hw *hw;
struct resource *res;
@@ -96,7 +93,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
int ret = 0;
u32 reg;
- if (!pdev->dev.platform_data) {
+ if (!dev_get_platdata(&pdev->dev)) {
dev_err(&pdev->dev, "no platform data specified\n");
ret = -EINVAL;
goto err_out;
@@ -193,7 +190,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
static int ath_ahb_remove(struct platform_device *pdev)
{
- struct ar231x_board_config *bcfg = pdev->dev.platform_data;
+ struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
struct ieee80211_hw *hw = platform_get_drvdata(pdev);
struct ath5k_hw *ah;
u32 reg;
--
1.7.10.4
^ permalink raw reply related
* [PATCH] wireless: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:49 UTC (permalink / raw)
To: 'John W. Linville'; +Cc: linux-wireless, 'Jingoo Han'
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
---
drivers/net/wireless/ath/ath5k/ahb.c | 15 ++++++---------
drivers/net/wireless/ath/ath9k/ahb.c | 4 ++--
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 2 +-
drivers/net/wireless/cw1200/cw1200_spi.c | 4 ++--
drivers/net/wireless/libertas/if_spi.c | 2 +-
drivers/net/wireless/ti/wl1251/spi.c | 2 +-
drivers/net/wireless/ti/wl12xx/main.c | 2 +-
drivers/net/wireless/ti/wlcore/main.c | 2 +-
drivers/net/wireless/ti/wlcore/spi.c | 2 +-
9 files changed, 16 insertions(+), 19 deletions(-)
^ permalink raw reply
* Re: Performance problems with Netgear WNDAP350
From: Sujith Manoharan @ 2013-09-10 8:37 UTC (permalink / raw)
To: Seth Forshee; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20130909212544.GA27771@thinkpad-t410>
Seth Forshee wrote:
> I posted some wireshark traces in case someone else can find something
> else informative that I've missed. They're at
> http://people.canonical.com/~sforshee/wndap350/:
>
> * iperf-iwlwifi.pcapng.gz: Trace from iperf client on Linux STA with
> iwlwifi
> * iperf-server.pcapng.gz: Trace from the iperf server for the same test
> as iperf-iwlwifi
> * iperf-osx.pcapng.gz: Trace from iperf client on OSX, using Broadcom
> wireless
The link with the iwlwifi client seems to be drowning in RTS/CTS exchanges
compared with the osx client.
iwlwifi: total: 109087, RTS - 9782 (9.0 %)
osx: total: 522581, RTS - 8366 (1.6 %)
Sujith
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Sujith Manoharan @ 2013-09-10 8:10 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
In-Reply-To: <522E1D31.2090403@candelatech.com>
Ben Greear wrote:
> I had a user request that we support always sending management frames
> (such as EAPOL) at the lowest rate. Evidently, other equipment does this,
> where as normal-ish supplicant/linux tends to send them at much higher
> rates.
>
> Any suggestions on how to go about doing this properly?
If this is with ath9k_rate_control, then it is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=927191
Sujith
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Arend van Spriel @ 2013-09-10 7:59 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
On 09/09/2013 09:23 PM, John W. Linville wrote:
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
Hi John
Because of personal reasons I am not attending this year. I would have
loved to celebrate my birthday in New Orleans and have a couple of beers
with you guys. Oh well. Guess I owe you.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 12/12] wlcore: always register dummy hardirq
From: Luca Coelho @ 2013-09-10 7:50 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-12-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Arik Nemtsov <arik@wizery.com>
>
> This keeps the kernel happy when using edge-irqs and requesting a
> threaded irq.
>
> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Ouch, I think this is not going to fit at all with the DT patches I
sent.
BTW, someone should probably take over those patches, rework according
to the reviews and submit them again, as I don't think I'll have the
time to rework them anytime soon... :(
--
Luca.
^ permalink raw reply
* Re: [PATCH 11/12] wl18xx: print new RDL versions during boot
From: Luca Coelho @ 2013-09-10 7:47 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-11-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> Extract and print info for the new RDL 5, 6, 7 and 8.
> Replace const struct with function which translates
> the RDL number to string.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Barak Bercovitz <barak@wizery.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Why convert the array with a function? The array looks much cleaner to
me.
[...[
> diff --git a/drivers/net/wireless/ti/wl18xx/main.c b/drivers/net/wireless/ti/wl18xx/main.c
> index b47eb62..aef0c91 100644
> --- a/drivers/net/wireless/ti/wl18xx/main.c
> +++ b/drivers/net/wireless/ti/wl18xx/main.c
> @@ -1228,16 +1228,46 @@ static u32 wl18xx_ap_get_mimo_wide_rate_mask(struct wl1271 *wl,
> }
> }
>
> +static const char *wl18xx_rdl_name(enum wl18xx_rdl_num rdl_num)
> +{
> + switch (rdl_num) {
> + case RDL_1_HP:
> + return "183xH";
> + case RDL_2_SP:
> + return "183x or 180x";
> + case RDL_3_HP:
> + return "187xH";
> + case RDL_4_SP:
> + return "187x";
> + case RDL_5_SP:
> + return "RDL11 - Not Supported";
> + case RDL_6_SP:
> + return "180xD";
> + case RDL_7_SP:
> + return "RDL13 - Not Supported (1893Q)";
> + case RDL_8_SP:
> + return "18xxQ";
> + default:
> + return "UNTRIMMED";
This may become misleading if we get more RDLs versions in the future.
And the untrimmed case is probably reporting 0? Or something predefined,
hopefully, otherwise how can we know that we wouldn't randomly get a
valid value?
Also, in the unsupported cases, it would probably be better to bail out?
--
Luca.
^ permalink raw reply
* Re: [PATCH 09/12] wlcore: fix regulatory domain bit translation
From: Luca Coelho @ 2013-09-10 7:39 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-9-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Ido Reis <idor@ti.com>
>
> This is a fix for channels 52,56,60,64 bit translation.
>
> Reported-by: Yaniv Machani <yanivma@ti.com>
> Signed-off-by: Ido Reis <idor@ti.com>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
> drivers/net/wireless/ti/wlcore/cmd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
> index e3ae425..1cb3296 100644
> --- a/drivers/net/wireless/ti/wlcore/cmd.c
> +++ b/drivers/net/wireless/ti/wlcore/cmd.c
> @@ -1613,8 +1613,10 @@ static int wlcore_get_reg_conf_ch_idx(enum ieee80211_band band, u16 ch)
> case IEEE80211_BAND_5GHZ:
> if (ch >= 8 && ch <= 16)
> idx = ((ch-8)/4 + 18);
> - else if (ch >= 34 && ch <= 64)
> + else if (ch >= 34 && ch <= 48)
> idx = ((ch-34)/2 + 3 + 18);
> + else if (ch >= 52 && ch <= 64)
> + idx = ((ch-52)/4 + 11 + 18);
> else if (ch >= 100 && ch <= 140)
> idx = ((ch-100)/4 + 15 + 18);
> else if (ch >= 149 && ch <= 165)
Hmmm... I don't have a clue what is going on here. I don't know how I
let this function pass as is originally, shame on me. :)
The change probably makes things work better, since someone apparently
saw a bug in real life and reported it, but can anyone explain what is
going on during this translation? Aren't we losing data here? Eg.
channels 8, 9, 10 and 11 all use the same bit in the firmware command
bitmask?
--
Luca.
^ permalink raw reply
* Re: beginner build question
From: Christian Lamparter @ 2013-09-10 7:34 UTC (permalink / raw)
To: Brian O'Connor; +Cc: linux-wireless
In-Reply-To: <CAHhaCVh_etgA1aoSur5shtduCbk9R-zuya8sBKu90A9M_Kj6qg@mail.gmail.com>
Hello Brain,
On Tuesday 10 September 2013 07:27:39 Brian O'Connor wrote:
> Thanks for getting back to me. I've run into another issue:
>
> # note the extra / before r92su
> $ sudo make load
> insmod /r92su/r92su.ko
> Error: could not load module /r92su/r92su.ko: No such file or directory
> make: *** [load] Error 1
Ok, apparently $(PWD) is not available on all shells?
<http://patchwork.coreboot.org/patch/2002/>
[Should be fixed now]
> # so I manually run
> $ sudo insmod r92su/r92su.ko
> Error: could not insert module r92su/r92su.ko: Unknown symbol in module
>
> $ dmesg
> ...
> [ 2066.923259] r92su: module verification failed: signature and/or required key missing - tainting kernel
Well, there's not much I can do for now. r92su is a unofficial module.
> [ 2066.923332] r92su: Unknown symbol cfg80211_scan_done (err 0)
> [ 2066.923362] r92su: Unknown symbol ieee80211_amsdu_to_8023s (err 0)
> [ 2066.923386] r92su: Unknown symbol ieee80211_data_from_8023 (err 0)
> [ 2066.923403] r92su: Unknown symbol cfg80211_disconnected (err 0)
> [ 2066.923432] r92su: Unknown symbol wiphy_register (err 0)
> [ 2066.923442] r92su: Unknown symbol wiphy_new (err 0)
> [ 2066.923451] r92su: Unknown symbol cfg80211_put_bss (err 0)
> [ 2066.923461] r92su: Unknown symbol cfg80211_inform_bss (err 0)
> [ 2066.923478] r92su: Unknown symbol cfg80211_ibss_joined (err 0)
> [ 2066.923496] r92su: Unknown symbol cfg80211_michael_mic_failure (err 0)
> [ 2066.923508] r92su: Unknown symbol cfg80211_connect_result (err 0)
> [ 2066.923527] r92su: Unknown symbol wiphy_unregister (err 0)
> [ 2066.923546] r92su: Unknown symbol cfg80211_get_bss (err 0)
> [ 2066.923576] r92su: Unknown symbol ieee80211_data_to_8023 (err 0)
> [ 2066.923597] r92su: Unknown symbol ieee80211_hdrlen (err 0)
> [ 2066.923615] r92su: Unknown symbol ieee80211_frequency_to_channel (err 0)
> [ 2066.923634] r92su: Unknown symbol cfg80211_unlink_bss (err 0)
> [ 2066.923644] r92su: Unknown symbol wiphy_free (err 0)
insmod doesn't load any dependent modules.
(In this case all that's missing is: cfg80211 - the new
makefile should take care of that)
> [ 2233.171269] r8712u 2-4:1.0 wlan0: r8712_got_addbareq_event_callback: mac = c8:d7:19:xx:xx:xx, seq = 10528, tid = 2
Ah, unload r8712u before loading r92su [else, r92su won't control the device].
modprobe -r r8712u
If r92su works and you want to stick with it for the time, you can
blacklist r8712u. AFAICT, you just have to follow the instruction at
<https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/rescuemode_drivers-blacklisting.html>
Regards
Christian
^ permalink raw reply
* Re: [PATCH 07/12] wlcore: cleanup scan debug prints
From: Luca Coelho @ 2013-09-10 7:19 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-7-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> Remove scan debug dumps which are rarely used.
> Make scan debug prints more clear and short.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
This is fine, these dumps were used when the firmware scan APIs were
changing all the time and we were having lots of problems following it.
It can be removed now to reduce excessive output.
Some nitpicks below.
[...]
> diff --git a/drivers/net/wireless/ti/wlcore/scan.c b/drivers/net/wireless/ti/wlcore/scan.c
> index f407101..bbe0bc4 100644
> --- a/drivers/net/wireless/ti/wlcore/scan.c
> +++ b/drivers/net/wireless/ti/wlcore/scan.c
> @@ -174,17 +174,7 @@ wlcore_scan_get_channels(struct wl1271 *wl,
> /* if radar is set, we ignore the passive flag */
> (radar ||
> !!(flags & IEEE80211_CHAN_PASSIVE_SCAN) == passive)) {
> - wl1271_debug(DEBUG_SCAN, "band %d, center_freq %d ",
> - req_channels[i]->band,
> - req_channels[i]->center_freq);
> - wl1271_debug(DEBUG_SCAN, "hw_value %d, flags %X",
> - req_channels[i]->hw_value,
> - req_channels[i]->flags);
> - wl1271_debug(DEBUG_SCAN, "max_power %d",
> - req_channels[i]->max_power);
> - wl1271_debug(DEBUG_SCAN, "min_dwell_time %d max dwell time %d",
> - min_dwell_time_active,
> - max_dwell_time_active);
> +
>
Unnecessary extra line here.
[...]
> @@ -222,6 +212,18 @@ wlcore_scan_get_channels(struct wl1271 *wl,
> *n_pactive_ch);
> }
>
> + wl1271_debug(DEBUG_SCAN, "freq %04d, ch. %03d, flags 0x%02X, power %02d, min/max_dwell %02d/%02d%s%s",
Left-padding with zeros is quite ugly with the decimals here.
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Luca Coelho @ 2013-09-10 6:56 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Eliad Peller, linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfdiudFgdXVAugkHVBLPVgLyrsokosCyhpNd5c5G7DOcOg@mail.gmail.com>
On Tue, 2013-09-10 at 08:47 +0200, Arik Nemtsov wrote:
> On Tue, Sep 10, 2013 at 9:33 AM, Luca Coelho <luca@coelho.fi> wrote:
> > On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> >> From: Yair Shapira <yair.shapira@ti.com>
> >>
> >> Under this mode the chip is powered on including sdio
> >> but no FW is downloaded and run, interrupts are not enabled, etc...
> >>
> >> This mode is intended to allow RTTT to bridge sdio as a transport
> >> to the chip.
> >>
> >> Driver only provides sdio access using the dev_mem debugfs file.
> >>
> >> Some fixes done to the code that ensures that PLT mode and normal
> >> driver power mode (ifconfig/add_interface) are mutually excluded.
> >>
> >> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >
> > I had some comments to this patch internally while I was still at TI.
> > Namely, I asked why do we need a new way of doing this if this is
> > already possible via debugsfs (using the gpio_power file)?
>
> Are you commenting on the correct patch? Seems this is just a patch to
> prevent "ifconfig up" during PLT mode..
Yes, I'm commenting on the right patch. It allows the chip power
(namely the WLAN_EN GPIO pin) to be set directly, without loading the
firmware and doing other initialization stuff. This can already be
controlled via the gpio_power debugfs file. I've used that a bunch of
times, including with the RTTT tool.
Okay, this patch has a few more protections (eg. not allowing an
interface to be added while the chip is powered in this way), but this
could also be added on top of the existing implementation.
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Arik Nemtsov @ 2013-09-10 6:47 UTC (permalink / raw)
To: Luca Coelho; +Cc: Eliad Peller, linux-wireless@vger.kernel.org
In-Reply-To: <1378794813.4799.35.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 9:33 AM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
>> From: Yair Shapira <yair.shapira@ti.com>
>>
>> Under this mode the chip is powered on including sdio
>> but no FW is downloaded and run, interrupts are not enabled, etc...
>>
>> This mode is intended to allow RTTT to bridge sdio as a transport
>> to the chip.
>>
>> Driver only provides sdio access using the dev_mem debugfs file.
>>
>> Some fixes done to the code that ensures that PLT mode and normal
>> driver power mode (ifconfig/add_interface) are mutually excluded.
>>
>> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>
> I had some comments to this patch internally while I was still at TI.
> Namely, I asked why do we need a new way of doing this if this is
> already possible via debugsfs (using the gpio_power file)?
Are you commenting on the correct patch? Seems this is just a patch to
prevent "ifconfig up" during PLT mode..
^ permalink raw reply
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Luca Coelho @ 2013-09-10 6:47 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-6-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Igal Chernobelsky <igalc@ti.com>
>
> Send EAPOL frames with voice priority by setting TX_HW_ATTR_EAPOL_FRAME
> new bit in tx attribute. Sending EAPOL with voice priority fixes
> re-key timeout during heavy traffic issue.
>
> Signed-off-by: Igal Chernobelsky <igalc@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
This seems to be the same problem that Ben had and debugged by himself
[1]. Fixing this in hostapd/wpa_supplicant seems more appropriate?
This patch seems to take an advantage of some sort of hack in the
firmware that will change the priority by itself when the
TX_HW_ATTR_EAPOL_GRAME bit is set. If we have a good reason to use this
patch, we need to take care of the firmware version as well. This
probably doesn't work with the latest published firmware.
[1] http://mid.gmane.org/522E18E5.1020503@candelatech.com
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 05/12] wl18xx: increase the number of allowed BA sessions
From: Luca Coelho @ 2013-09-10 6:39 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-5-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:34 +0300, Eliad Peller wrote:
> From: Victor Goldenshtein <victorg@ti.com>
>
> The current fw (actually starting from fw 8.5.0.0.58)
> supports 8 rx BA sessions.
>
> Signed-off-by: Victor Goldenshtein <victorg@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
The latest firmware version published at linux-firmware.git is
8.5.0.0.55 (wl18xx-fw-2.bin), so this patch cannot be taken into the
official tree yet.
Please publish a newer version of the firmware (with appropriate
increase in the filename version), since I cannot do that myself
anymore.
--
Luca.
^ permalink raw reply
* [PATCH 1/1] net: ath9k: Use NULL instead of false
From: Sachin Kamat @ 2013-09-10 6:20 UTC (permalink / raw)
To: linux-wireless
Cc: ath9k-devel, netdev, mcgrof, jouni, vthiagar, senthilb, linville,
sachin.kamat
The function returns a pointer. Hence return NULL instead of false.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/net/wireless/ath/ath9k/dfs_pri_detector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c b/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
index 5ba4b6f..c718fc3 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
@@ -392,7 +392,7 @@ static struct pri_sequence *pri_detector_add_pulse(struct pri_detector *de,
if (!pseq_handler_create_sequences(de, ts, max_updated_seq)) {
pri_detector_reset(de, ts);
- return false;
+ return NULL;
}
ps = pseq_handler_check_detection(de);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 03/12] wlcore: disable elp sleep while in plt mode
From: Luca Coelho @ 2013-09-10 6:34 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-3-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> From: Yair Shapira <yair.shapira@ti.com>
>
> We now disable elp sleep during plt mode to allow normal operation of
> plt tools such as calibrator.
>
> Having elp_sleep enabled during plt mode is actually not required and
> in fact it disrupt plt operations such as rx statistics etc.
>
> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
I also had a comment internally about this one. Why do we need this?
AFAICT this would never happen in real life, since the firmware is not
even loaded at this point. Is there any real life situation where we
try to go into ELP while in PLT mode?
--
Luca.
^ permalink raw reply
* Re: [PATCH 02/12] wlcore: add new plt power-mode: CHIP_AWAKE
From: Luca Coelho @ 2013-09-10 6:33 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1378218848-7853-2-git-send-email-eliad@wizery.com>
On Tue, 2013-09-03 at 17:33 +0300, Eliad Peller wrote:
> From: Yair Shapira <yair.shapira@ti.com>
>
> Under this mode the chip is powered on including sdio
> but no FW is downloaded and run, interrupts are not enabled, etc...
>
> This mode is intended to allow RTTT to bridge sdio as a transport
> to the chip.
>
> Driver only provides sdio access using the dev_mem debugfs file.
>
> Some fixes done to the code that ensures that PLT mode and normal
> driver power mode (ifconfig/add_interface) are mutually excluded.
>
> Signed-off-by: Yair Shapira <yair.shapira@ti.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
I had some comments to this patch internally while I was still at TI.
Namely, I asked why do we need a new way of doing this if this is
already possible via debugsfs (using the gpio_power file)?
--
Cheers,
Luca.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Luca Coelho @ 2013-09-10 6:28 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
On Mon, 2013-09-09 at 15:23 -0400, John W. Linville wrote:
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
Unfortunately I didn't get "sponsorship" to join the summit this year.
Second one (for different reasons) that I'll miss in a row. Hopefully
next time I'll be there.
Have fun! :)
--
Cheers,
Luca.
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-10 5:58 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E896E.7000607@lwfinger.net>
On 10/09/13 03:52, Larry Finger wrote:
> We now know that the beacons are being lost. The last one was at
> 90600.642566 as shown below:
>
> Sep 10 00:29:48 kentang kernel: [90599.513526] rtlwifi: mode 2, state 2,
> is_beacon 1, is_probe_resp 0, length 153
> Sep 10 00:29:50 kentang kernel: [90600.642566] rtlwifi: mode 2, state 2,
> is_beacon 1, is_probe_resp 0, length 153
> Sep 10 00:29:57 kentang kernel: [90607.829051]
> rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
> Sep 10 00:29:57 kentang kernel: [90607.829058] wlan1: Connection to AP
> 00:1f:9f:d5:a8:3b lost
> Sep 10 00:29:57 kentang kernel: [90607.830086] cfg80211: Calling CRDA to
> update world regulatory domain
>
> We have to conclude that your interface has been shut down as we have
> gotten no beacons or RX data packets received. Unfortunately, my
> restricting the output to only your AP does not let me know if any data
> are being received. I hate to do this, but the attached patch will dump
> all packets again with no limit. Once you get a disconnect, then you can
> stop the run before the log gets too full.
No worries - disk space is reasonably cheap these days ;)
dmesg output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-4-dmesg.txt
wpa_supplicant output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-4-wpa_supplicant.txt
I noticed that I got several re-authentication attempts in the dmesg
output without the corresponding rtl_watchdog_wq_callback() line being
emitted - this is again something I don't see with zd1211rw and iwlwifi.
Once these drivers are associated, they seem to stay in that state for
hours.
Whilst checking various parts of my kernel, I noticed for the first time
during testing that my current kernel configuration doesn't have SMP
enabled. This got me thinking that perhaps there are other build options
which could have an effect on the driver. Hence I also uploaded a copy
of my .config file to http://www.ilande.co.uk/tmp/rtl8192cu-config in
the hope that maybe this can help you recreate the issue locally?
ATB,
Mark.
^ permalink raw reply
* Re: beginner build question
From: Brian O'Connor @ 2013-09-10 5:27 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <1781136.IRflOffuSs@blech>
Hi Christian,
Thanks for getting back to me. I've run into another issue:
# note the extra / before r92su
$ sudo make load
insmod /r92su/r92su.ko
Error: could not load module /r92su/r92su.ko: No such file or directory
make: *** [load] Error 1
# so I manually run
$ sudo insmod r92su/r92su.ko
Error: could not insert module r92su/r92su.ko: Unknown symbol in module
$ dmesg
...
[ 2066.923259] r92su: module verification failed: signature and/or
required key missing - tainting kernel
[ 2066.923332] r92su: Unknown symbol cfg80211_scan_done (err 0)
[ 2066.923362] r92su: Unknown symbol ieee80211_amsdu_to_8023s (err 0)
[ 2066.923386] r92su: Unknown symbol ieee80211_data_from_8023 (err 0)
[ 2066.923403] r92su: Unknown symbol cfg80211_disconnected (err 0)
[ 2066.923432] r92su: Unknown symbol wiphy_register (err 0)
[ 2066.923442] r92su: Unknown symbol wiphy_new (err 0)
[ 2066.923451] r92su: Unknown symbol cfg80211_put_bss (err 0)
[ 2066.923461] r92su: Unknown symbol cfg80211_inform_bss (err 0)
[ 2066.923478] r92su: Unknown symbol cfg80211_ibss_joined (err 0)
[ 2066.923496] r92su: Unknown symbol cfg80211_michael_mic_failure (err 0)
[ 2066.923508] r92su: Unknown symbol cfg80211_connect_result (err 0)
[ 2066.923527] r92su: Unknown symbol wiphy_unregister (err 0)
[ 2066.923546] r92su: Unknown symbol cfg80211_get_bss (err 0)
[ 2066.923576] r92su: Unknown symbol ieee80211_data_to_8023 (err 0)
[ 2066.923597] r92su: Unknown symbol ieee80211_hdrlen (err 0)
[ 2066.923615] r92su: Unknown symbol ieee80211_frequency_to_channel (err 0)
[ 2066.923634] r92su: Unknown symbol cfg80211_unlink_bss (err 0)
[ 2066.923644] r92su: Unknown symbol wiphy_free (err 0)
[ 2233.171269] r8712u 2-4:1.0 wlan0:
r8712_got_addbareq_event_callback: mac = c8:d7:19:xx:xx:xx, seq =
10528, tid = 2
Any idea? I would be happy to provide more debugging if it helps.
Thanks,
Brian
On Fri, Sep 6, 2013 at 3:21 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> Hello,
>
> On Friday, September 06, 2013 02:27:26 AM Brian O'Connor wrote:
>> I am trying to compile rtl8192su in Ubuntu 13.04 and I get the
>> following error when I "make all":
>>
>> make -C /lib/modules/3.10.10-031010-generic/build
>> M=/home/media/rtl8192su/r92su CONFIG_R92SU=m CONFIG_R92SU_DEBUGFS=y
>> CONFIG_R92SU_WPC=y all EXTRA_CFLAGS="-DDEBUG -DCONFIG_R92SU=m
> ^^^
>> -DCONFIG_R92SU_DEBUGFS=y -DCONFIG_R92SU_WPC=y"
>> make[1]: Entering directory `/usr/src/linux-headers-3.10.10-031010-generic'
>> make[1]: *** No rule to make target `vmlinux', needed by `all'. Stop.
>> make[1]: Leaving directory `/usr/src/linux-headers-3.10.10-031010-generic'
>> make: *** [all] Error 2
>>
>> Any suggestions?
> Thanks for reporting this. I fixed the project's readme.
> <https://github.com/chunkeey/rtl8192su/commit/d1934e155840ccd273a429d85f1f2aa407ba49b7>
>
> Just run "make" instead of "make all".
>
> Regards
>
> Chr
>
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-10 2:52 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E5D83.9060103@ilande.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
On 09/09/2013 06:45 PM, Mark Cave-Ayland wrote:
> dmesg output:
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-dmesg.txt
>
> wpa_supplicant output:
> http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-wpa_supplicant.txt
>
> Now the interesting part was as you can see from the logs, I managed to get a
> reasonably long association to the AP towards the end so I tried running
> dhclient against the wlan1 interface - this was slow, taking about 60s to
> complete, but it did eventually return with an IP address. With that in place, I
> tried pinging 8.8.8.8 and ended up with a very poor connection, with the ping
> exit banner reporting 87% packet loss :(
We now know that the beacons are being lost. The last one was at 90600.642566 as
shown below:
Sep 10 00:29:48 kentang kernel: [90599.513526] rtlwifi: mode 2, state 2,
is_beacon 1, is_probe_resp 0, length 153
Sep 10 00:29:50 kentang kernel: [90600.642566] rtlwifi: mode 2, state 2,
is_beacon 1, is_probe_resp 0, length 153
Sep 10 00:29:57 kentang kernel: [90607.829051]
rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
Sep 10 00:29:57 kentang kernel: [90607.829058] wlan1: Connection to AP
00:1f:9f:d5:a8:3b lost
Sep 10 00:29:57 kentang kernel: [90607.830086] cfg80211: Calling CRDA to update
world regulatory domain
We have to conclude that your interface has been shut down as we have gotten no
beacons or RX data packets received. Unfortunately, my restricting the output to
only your AP does not let me know if any data are being received. I hate to do
this, but the attached patch will dump all packets again with no limit. Once you
get a disconnect, then you can stop the run before the log gets too full.
Larry
[-- Attachment #2: rtl8192cu_dump_AP_off --]
[-- Type: text/plain, Size: 1709 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/usb.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
@@ -484,6 +484,8 @@ static void _rtl_usb_rx_process_agg(stru
if (unicast)
rtlpriv->link_info.num_rx_inperiod++;
}
+ /* static bcn for roaming */
+ rtl_beacon_statistic(hw, skb);
}
}
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/core.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
@@ -184,6 +184,7 @@ static int rtl_op_add_interface(struct i
rtlpriv->cfg->maps
[RTL_IBSS_INT_MASKS]);
}
+ mac->link_state = MAC80211_LINKED;
break;
case NL80211_IFTYPE_ADHOC:
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
@@ -1288,6 +1288,10 @@ void rtl_beacon_statistic(struct ieee802
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ pr_info("mode %d, state %d, is_beacon %d, is_probe_resp %d, length %d\n",
+ rtlpriv->mac80211.opmode, rtlpriv->mac80211.link_state, ieee80211_is_beacon(hdr->frame_control),
+ ieee80211_is_probe_resp(hdr->frame_control), skb->len);
+
if (rtlpriv->mac80211.opmode != NL80211_IFTYPE_STATION)
return;
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-09 23:45 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E5416.4010901@lwfinger.net>
On 10/09/13 00:04, Larry Finger wrote:
>> I also tried another experiment which was to change your patch so that
>> instead
>> of logging just the first 100 beacons to dmesg, log every 10th beacon
>> (count %
>> 10) to dmesg instead. This showed that even when the timeouts are
>> occurring
>> against the AP, I'm still seeing a continual stream of beacons from other
>> stations on the network.
>
> Looking at only every 10th one could be systematically missing the ones
> from your AP.
Oh sure - what I was looking to prove was whether it was all beacons
that weren't getting through, or just the ones from the AP when the
timeout occurred.
>> This makes me wonder if Oleksij is correct in that the problem is that
>> not all
>> the frames coming from the USB interface are being picked up by the
>> driver.
>> Perhaps not all incoming USB RX buffers are being scanned (causing
>> some queued
>> frames to be lost) or maybe USB transfers can contain more than 1
>> frame and
>> rtlwifi is only catching the first frame within each notified transfer?
>
> None of those suppositions make any sense.
Well I freely admit that I don't have much knowledge of the kernel USB
layers (only from some old embedded systems years ago), so it was really
just a case of thinking out loud...
>> To double check whether it was a general ehci-pci problem, I tried
>> plugging in a
>> spare zd1211rw dongle and that worked absolutely fine. So I think
>> that's a
>> reasonable indication that general USB function is okay.
>
> I do not suspect any USB problem unless it is in rtl8192cu.
Okay.
> Could you please run the attached patch? It will only print messages for
> your AP, and print enough to still be getting them when the AP timeout
> occurs.
Done.
dmesg output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-dmesg.txt
wpa_supplicant output:
http://www.ilande.co.uk/tmp/rtl8192cu_patch-3-wpa_supplicant.txt
Now the interesting part was as you can see from the logs, I managed to
get a reasonably long association to the AP towards the end so I tried
running dhclient against the wlan1 interface - this was slow, taking
about 60s to complete, but it did eventually return with an IP address.
With that in place, I tried pinging 8.8.8.8 and ended up with a very
poor connection, with the ping exit banner reporting 87% packet loss :(
ATB,
Mark.
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Ben Greear @ 2013-09-09 23:10 UTC (permalink / raw)
To: Krishna Chaitanya; +Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
In-Reply-To: <CABPxzYLaLUdCXULmx7mV5Gk7L_RrnG4Zq-vO6XRCUt0pvm9SJA@mail.gmail.com>
On 09/09/2013 12:15 PM, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 12:40 AM, Ben Greear <greearb@candelatech.com> wrote:
>> I had a user request that we support always sending management frames
>> (such as EAPOL) at the lowest rate. Evidently, other equipment does this,
>> where as normal-ish supplicant/linux tends to send them at much higher
>> rates.
>>
>> Any suggestions on how to go about doing this properly?
>>
>> Any opinions on whether it's a good idea or not?
>
> EAPOL frames are data frams from WLAN perspective
> and are unicast, thats why we send at highest possible
> MCS supported. There is no advantage in forcing them to
> go at lower rates.
>
Would forcing them to a lower rate at least theoretically improve
the chance that the packets are properly delivered?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox