* 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 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: 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 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: [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 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: 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: 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: 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
* [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
* [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 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 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 4/8] wireless: cw1200: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:55 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Solomon Peachy'
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/cw1200/cw1200_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index d063760..b7d1e0f 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -355,7 +355,7 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
static int cw1200_spi_probe(struct spi_device *func)
{
const struct cw1200_platform_data_spi *plat_data =
- func->dev.platform_data;
+ dev_get_platdata(&func->dev);
struct hwbus_priv *self;
int status;
@@ -431,7 +431,7 @@ static int cw1200_spi_disconnect(struct spi_device *func)
}
kfree(self);
}
- cw1200_spi_off(func->dev.platform_data);
+ cw1200_spi_off(dev_get_platdata(&func->dev));
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/8] wireless: libertas: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:56 UTC (permalink / raw)
To: 'John W. Linville'; +Cc: linux-wireless, 'Jingoo Han'
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/libertas/if_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
index 4bb6574..5d39ec8 100644
--- a/drivers/net/wireless/libertas/if_spi.c
+++ b/drivers/net/wireless/libertas/if_spi.c
@@ -1128,7 +1128,7 @@ static int if_spi_probe(struct spi_device *spi)
{
struct if_spi_card *card;
struct lbs_private *priv = NULL;
- struct libertas_spi_platform_data *pdata = spi->dev.platform_data;
+ struct libertas_spi_platform_data *pdata = dev_get_platdata(&spi->dev);
int err = 0;
lbs_deb_enter(LBS_DEB_SPI);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/8] wireless: wl1251: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:57 UTC (permalink / raw)
To: 'John W. Linville'; +Cc: linux-wireless, 'Jingoo Han'
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/ti/wl1251/spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index c7dc6fe..1342f81 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -243,7 +243,7 @@ static int wl1251_spi_probe(struct spi_device *spi)
struct wl1251 *wl;
int ret;
- pdata = spi->dev.platform_data;
+ pdata = dev_get_platdata(&spi->dev);
if (!pdata) {
wl1251_error("no platform data");
return -ENODEV;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/8] wireless: wlcore: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:57 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Luciano Coelho'
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/ti/wlcore/main.c | 2 +-
drivers/net/wireless/ti/wlcore/spi.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 38995f9..c30e1f1 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5900,7 +5900,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
{
struct wl1271 *wl = context;
struct platform_device *pdev = wl->pdev;
- struct wlcore_platdev_data *pdev_data = pdev->dev.platform_data;
+ struct wlcore_platdev_data *pdev_data = dev_get_platdata(&pdev->dev);
struct wl12xx_platform_data *pdata = pdev_data->pdata;
unsigned long irqflags;
int ret;
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index 1b0cd98..b2c018d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -335,7 +335,7 @@ static int wl1271_probe(struct spi_device *spi)
if (!pdev_data)
goto out;
- pdev_data->pdata = spi->dev.platform_data;
+ pdev_data->pdata = dev_get_platdata(&spi->dev);
if (!pdev_data->pdata) {
dev_err(&spi->dev, "no platform data\n");
ret = -ENODEV;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 8/8] wireless: wl12xx: use dev_get_platdata()
From: Jingoo Han @ 2013-09-10 8:58 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Luciano Coelho'
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/ti/wl12xx/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..591526b 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1704,7 +1704,7 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
static int wl12xx_setup(struct wl1271 *wl)
{
struct wl12xx_priv *priv = wl->priv;
- struct wlcore_platdev_data *pdev_data = wl->pdev->dev.platform_data;
+ struct wlcore_platdev_data *pdev_data = dev_get_platdata(&wl->pdev->dev);
struct wl12xx_platform_data *pdata = pdev_data->pdata;
wl->rtable = wl12xx_rtable;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Arik Nemtsov @ 2013-09-10 9:11 UTC (permalink / raw)
To: Luca Coelho; +Cc: Eliad Peller, linux-wireless@vger.kernel.org
In-Reply-To: <1378795636.4799.44.camel@porter.coelho.fi>
On Tue, Sep 10, 2013 at 9:47 AM, Luca Coelho <luca@coelho.fi> wrote:
> 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
I believe he only fixed one mode (AP - hostapd) but not the other (GO
- wpa_supplicant). Anyway that's what we tested at the time.
Anyway marking it as this level doesn't do any harm. You're right
about the FW version though - it should be upstreamed first.
Arik
^ permalink raw reply
* Re: [PATCH 06/12] wlcore: send EAPOL frames with voice priority
From: Luca Coelho @ 2013-09-10 9:15 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Eliad Peller, linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfc6RG1BngT_+doiOUhtYAgnG9Q0-oXns-ckJkU7XhE5ag@mail.gmail.com>
On Tue, 2013-09-10 at 11:11 +0200, Arik Nemtsov wrote:
> On Tue, Sep 10, 2013 at 9:47 AM, Luca Coelho <luca@coelho.fi> wrote:
> > 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
>
> I believe he only fixed one mode (AP - hostapd) but not the other (GO
> - wpa_supplicant). Anyway that's what we tested at the time.
Okay, I didn't dig much into it.
> Anyway marking it as this level doesn't do any harm. You're right
> about the FW version though - it should be upstreamed first.
Fair enough. If the firmware implements this, no reason why not use it.
But I'll wait for the new firmware before applying this.
--
Luca.
^ permalink raw reply
* Re: Always send management frames at MCS-0??
From: Krishna Chaitanya @ 2013-09-10 9:17 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
In-Reply-To: <522E5558.4070008@candelatech.com>
On Tue, Sep 10, 2013 at 4:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> Would forcing them to a lower rate at least theoretically improve
> the chance that the packets are properly delivered?
Yes. But we already have a RC algorithm taking care of that.
Right?
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Samuel Ortiz @ 2013-09-10 9:46 UTC (permalink / raw)
To: Marcel Holtmann
Cc: John W.Linville, Dan Williams, linux-wireless, johannes,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <6D969CDD-C551-4C4C-A674-A7518B3EE0AC@holtmann.org>
Hi Marcel, John,
On Mon, 2013-09-09 at 13:48 -0700, Marcel Holtmann wrote:
> Hi John,
>
> >>>> Sorry, forgot to copy linux-bluetooth and linux-nfc...
> >>>>
> >>>> On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
> >>>>> Greetings!
> >>>>>
> >>>>> This is a reminder that we will have a Linux Wireless Mini-Summit in
> >>>>> New Orleans this year on 19-20 September. This will immediately follow
> >>>>> LinuxCon and will run concurrently with Linux Plumber's Conference.
> >>>>> This event includes Linux developers for wireless LAN (802.11),
> >>>>> Bluetooth, and NFC technologies. Both kernel and userland developers
> >>>>> are welcomed and heartily encouraged to attend!
> >>>>>
> >>>>> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
> >>>>>
> >>>>> The link above is a Wiki. We are using it to collect discussion
> >>>>> topics and to negotiate agenda/scheduling options for the event.
> >>>>> Please go there to record your intent to attend the event and to
> >>>>> propopse topics for discussion.
> >>>>>
> >>>>> Please be aware that in order to attend the event above one must
> >>>>> register for either LinuxCon or for Linux Plumbers Conference.
> >>>>> Act now, before those events fill-up and close their registrations!
> >>>>>
> >>>>> We are allotted one "large" room (up to ~80 people "theater style"), and
> >>>>> two "small" rooms (up to ~25 people) for this event. Based on history
> >>>>> and the numbers of contributors, the larger room will primarily be
> >>>>> for the 802.11 discussions and any "plenary" topics while the smaller
> >>>>> rooms will be for Bluetooth, NFC, and any "breakout" topics.
> >>>>>
> >>>>> So...thoughts? Topics to discuss?
> >>>
> >>> Ping? We're now just 2 weeks away!
> >>>
> >>> Is our topic list complete? It looks a bit light...
> >>>
> >>> Anyone have any input on scheduling the topics? Are there any
> >>> overlapping LPC sessions that it would make sense to work around?
> >>
> >> I'm attending though I haven't put my name on the wiki yet.
> >>
> >> Random thoughts; it doesn't look like any of these are covered in the
> >> regular LinuxConf or LPC sessions.
> >>
> >> 1) State of the Union (maybe by multiple people in the same session per
> >> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
> >> what's happening in BT or NFC land, or not everyone working on a
> >> specific driver may know what new stuff their driver might need to be
> >> fixed up for. Maybe 5 minutes or less for things like:
> >>
> >> * what's under the most active development right now?
> >> * upcoming new driver, hardware, and new capabilities
> >> * new 802.11 standards
> >> * and what's coming up in the next year from the standards orgs
> >> * what people will start working on soon
> >> * what will 3.13 or 3.14 look like from a wireless perspective?
> >> * 11s mesh status?
> >> * anything interesting in wpa_supplicant land?
> >> * anything new/interesting on the Android front?
> >>
> >> 2) Bluetooth - update about what's new and what's coming up in Bluez
> >> land, and interaction with kernel 802.11 if any,
> >>
> >> 3) NFC - update about what's new and what's coming up in NFC land, where
> >> it's getting used, what the stack looks like
> >>
> >> 4) What are users having the most problems with and how these problems
> >> be fixed better/more quickly? Are they driver bugs? Are they stack
> >> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
> >> development processes that's not working as smoothly as it could be?
> >
> > Thanks, Dan -- those all look like decent discussion points.
> > I've added most of the points above to the topic list:
> >
> > http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
> >
> > Now, we need a few volunteers...
> >
> > Gustavo, can you do a session on Bluetooth developments?
> >
> > Samuel, can you cover NFC?
>
> I can do the Bluetooth part and I am just volunteering Samuel for NFC ;)
Thanks Marcel for the initiative ;)
John, I'll do the NFC part, sorry for not being able to reply earlier.
Cheers,
Samuel.
^ permalink raw reply
* ath9k_htc embedded modules
From: Drasko DRASKOVIC @ 2013-09-10 10:09 UTC (permalink / raw)
To: linux-wireless
Hi all,
anyone aware of ath9k_htc supported embedded modules on the market
(Atheros AR9002U UB94, i.e. AR9280+AR7010 combo).
All I could find from USB based modules is Ralink RT5572 and RT3572
and I do not know how these are supported in linux-wireless (for
example AP mode).
Best regards,
Drasko
^ permalink raw reply
* [PATCH 0/11] wireless: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-10 11:14 UTC (permalink / raw)
To: 'John W. Linville'; +Cc: linux-wireless, 'Jingoo Han'
Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound),
the driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
---
drivers/net/wireless/adm8211.c | 1 -
drivers/net/wireless/airo.c | 1 -
drivers/net/wireless/ath/ath10k/pci.c | 2 --
drivers/net/wireless/ath/wil6210/pcie_bus.c | 1 -
drivers/net/wireless/ipw2x00/ipw2200.c | 2 --
drivers/net/wireless/iwlegacy/3945-mac.c | 2 --
drivers/net/wireless/iwlegacy/4965-mac.c | 2 --
drivers/net/wireless/iwlwifi/pcie/drv.c | 3 ---
drivers/net/wireless/mwl8k.c | 2 --
drivers/net/wireless/orinoco/orinoco_nortel.c | 2 --
drivers/net/wireless/orinoco/orinoco_pci.c | 2 --
drivers/net/wireless/orinoco/orinoco_plx.c | 2 --
drivers/net/wireless/orinoco/orinoco_tmd.c | 2 --
drivers/net/wireless/p54/p54pci.c | 1 -
drivers/net/wireless/rtl818x/rtl8180/dev.c | 1 -
drivers/net/wireless/rtlwifi/pci.c | 3 ---
16 files changed, 29 deletions(-)
^ permalink raw reply
* [PATCH 01/12] wireless: iwlwifi: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-10 11:16 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, 'Jingoo Han', 'Johannes Berg',
'Emmanuel Grumbach', ilw
In-Reply-To: <00b101ceae16$ecb87c30$c6297490$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/wireless/iwlwifi/pcie/drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/pcie/drv.c b/drivers/net/wireless/iwlwifi/pcie/drv.c
index dc02cb9..5c5c423 100644
--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -349,7 +349,6 @@ out_free_drv:
iwl_drv_stop(trans_pcie->drv);
out_free_trans:
iwl_trans_pcie_free(iwl_trans);
- pci_set_drvdata(pdev, NULL);
return ret;
}
@@ -360,8 +359,6 @@ static void iwl_pci_remove(struct pci_dev *pdev)
iwl_drv_stop(trans_pcie->drv);
iwl_trans_pcie_free(trans);
-
- pci_set_drvdata(pdev, NULL);
}
#ifdef CONFIG_PM_SLEEP
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox