* Re: [PATCH] ssb: add struct for serial flash
From: Rafał Miłecki @ 2013-06-17 20:33 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-wireless, John W. Linville, Hauke Mehrtens
In-Reply-To: <CACna6rzCDHx7s9hz0=yDYsMeb45KANW0mW8qe=uH8QJGV-64CA@mail.gmail.com>
2013/6/17 Rafał Miłecki <zajec5@gmail.com>:
> 2013/6/17 Florian Fainelli <florian@openwrt.org>:
>> Hello Rafal,
>>
>> Le lundi 17 juin 2013 18:56:20, Rafał Miłecki a écrit :
>>> This data allow writing for example MTD driver.
>>
>> Your commit message could probably have some more information, by looking at
>> the patch, it is not entirely clear to me what this does, especially as sflash
>> is just a write only structure?
>
> OK, no problem. I'll give people w little more time for comments, and
> then I'll submit next version.
It's already in wireless-next, so I'll explain this just in an e-mail.
There is not much more to explain anyway ;)
--
Rafał
^ permalink raw reply
* Re: [PATCH] ssb: add struct for serial flash
From: Rafał Miłecki @ 2013-06-17 19:46 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-wireless, John W. Linville, Hauke Mehrtens
In-Reply-To: <201306172038.21642.florian@openwrt.org>
2013/6/17 Florian Fainelli <florian@openwrt.org>:
> Hello Rafal,
>
> Le lundi 17 juin 2013 18:56:20, Rafał Miłecki a écrit :
>> This data allow writing for example MTD driver.
>
> Your commit message could probably have some more information, by looking at
> the patch, it is not entirely clear to me what this does, especially as sflash
> is just a write only structure?
OK, no problem. I'll give people w little more time for comments, and
then I'll submit next version.
--
Rafał
^ permalink raw reply
* Re: [PATCH] ssb: add struct for serial flash
From: Florian Fainelli @ 2013-06-17 19:38 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, John W. Linville, Hauke Mehrtens
In-Reply-To: <1371491780-23412-1-git-send-email-zajec5@gmail.com>
Hello Rafal,
Le lundi 17 juin 2013 18:56:20, Rafał Miłecki a écrit :
> This data allow writing for example MTD driver.
Your commit message could probably have some more information, by looking at
the patch, it is not entirely clear to me what this does, especially as sflash
is just a write only structure?
>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> ---
> drivers/ssb/driver_chipcommon_sflash.c | 7 +++++++
> include/linux/ssb/ssb_driver_mips.h | 15 +++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/ssb/driver_chipcommon_sflash.c
> b/drivers/ssb/driver_chipcommon_sflash.c index 1b9e770..205f1c4 100644
> --- a/drivers/ssb/driver_chipcommon_sflash.c
> +++ b/drivers/ssb/driver_chipcommon_sflash.c
> @@ -73,6 +73,7 @@ static void ssb_sflash_cmd(struct ssb_chipcommon *cc, u32
> opcode) /* Initialize serial flash access */
> int ssb_sflash_init(struct ssb_chipcommon *cc)
> {
> + struct ssb_sflash *sflash = &cc->dev->bus->mipscore.sflash;
> const struct ssb_sflash_tbl_e *e;
> u32 id, id2;
>
> @@ -131,6 +132,12 @@ int ssb_sflash_init(struct ssb_chipcommon *cc)
> return -ENOTSUPP;
> }
>
> + sflash->window = SSB_FLASH2;
> + sflash->blocksize = e->blocksize;
> + sflash->numblocks = e->numblocks;
> + sflash->size = sflash->blocksize * sflash->numblocks;
> + sflash->present = true;
> +
> pr_info("Found %s serial flash (blocksize: 0x%X, blocks: %d)\n",
> e->name, e->blocksize, e->numblocks);
>
> diff --git a/include/linux/ssb/ssb_driver_mips.h
> b/include/linux/ssb/ssb_driver_mips.h index afe79d4..6535e47 100644
> --- a/include/linux/ssb/ssb_driver_mips.h
> +++ b/include/linux/ssb/ssb_driver_mips.h
> @@ -20,6 +20,18 @@ struct ssb_pflash {
> u32 window_size;
> };
>
> +#ifdef CONFIG_SSB_SFLASH
> +struct ssb_sflash {
> + bool present;
> + u32 window;
> + u32 blocksize;
> + u16 numblocks;
> + u32 size;
> +
> + void *priv;
> +};
> +#endif
> +
> struct ssb_mipscore {
> struct ssb_device *dev;
>
> @@ -27,6 +39,9 @@ struct ssb_mipscore {
> struct ssb_serial_port serial_ports[4];
>
> struct ssb_pflash pflash;
> +#ifdef CONFIG_SSB_SFLASH
> + struct ssb_sflash sflash;
> +#endif
> };
>
> extern void ssb_mipscore_init(struct ssb_mipscore *mcore);
--
Florian
^ permalink raw reply
* Re: Lots of confusion on bss refcounting.
From: Ben Greear @ 2013-06-17 19:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1371495758.8168.3.camel@jlt4.sipsolutions.net>
On 06/17/2013 12:02 PM, Johannes Berg wrote:
> On Mon, 2013-06-17 at 11:49 -0700, Ben Greear wrote:
>
>> We create an assoc_data, assign a bss pointer in ieee80211_mgd_assoc,
>> but do not claim a reference.
>
> Heh, yeah, I was actually looking at this code too but didn't have time
> today to finish my thoughts ...
>
>> Later, when deleting the assoc_data, the ref is not freed either,
>> except in one error path where it is explicitly freed:
>>
>> if (!ieee80211_assoc_success(sdata, *bss, mgmt, len)) {
>> /* oops -- internal error -- send timeout for now */
>> ieee80211_destroy_assoc_data(sdata, false);
>> cfg80211_put_bss(sdata->local->hw.wiphy, *bss);
>> return RX_MGMT_CFG80211_ASSOC_TIMEOUT;
>> }
>>
>> This seems ripe for bugs, if not already buggy.
>>
>> Maybe we should be more explicit about always grabbing a ref when
>> we take a reference to the pointer, and always put it when we
>> destroy the pointer?
>
> I think the reference is actually given to mac80211 by cfg80211 in
> cfg80211_mlme_assoc(), so we shouldn't need to grab a reference?
> Although I'm certainly willing to change this and make cfg80211 always
> put the reference after calling rdev_assoc() so that the driver/mac80211
> would be responsible for obtaining its own if it needs to hang on to the
> struct.
>
> This does seem broken though.
The bss reference is passed back, and through luck or careful programming,
it *seems* that all paths related to calling ieee80211_rx_mgmt_assoc_resp
managed to consume the bss.
I haven't figured out yet why this is not an erroneous put since I didn't
find the reference taken in the first place.
I'm going to work on making some changes to the ref counting scheme
a bit. I'd rather have the code perhaps take and put a few refs
it might otherwise skip to keep the ownership cleaner and make
the code easier to debug and understand...
I'll post some for RFC when I make some progress.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ath3k hackery; doing it in userland
From: Adrian Chadd @ 2013-06-17 19:05 UTC (permalink / raw)
To: Julian Calaby; +Cc: linux-wireless
In-Reply-To: <CAGRGNgWJr=EahOWeQxpchCAyv5di-WnwyL9hvJa3XYFf64OSxg@mail.gmail.com>
On 16 June 2013 23:35, Julian Calaby <julian.calaby@gmail.com> wrote:
> A further question: why isn't this in usb-modeswitch or some similar
> "make my dumb USB device work" system?
Well, there's a couple of hoops needed to jump through in order to
make this thing work. It's not a "set this value to make it work",
it's "upload this firmware blob to make this thing work."
I don't have any clue what the right order is to poke these BT devices
(and even when i was working at QCA, finding documentation on the
bluetooth devices was difficult!) and how they should behave. This
whole "it detaches right after I load the sysconfig file" thing is
quite annoying.
adrian
^ permalink raw reply
* Re: Lots of confusion on bss refcounting.
From: Johannes Berg @ 2013-06-17 19:02 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <51BF5A53.8050100@candelatech.com>
On Mon, 2013-06-17 at 11:49 -0700, Ben Greear wrote:
> We create an assoc_data, assign a bss pointer in ieee80211_mgd_assoc,
> but do not claim a reference.
Heh, yeah, I was actually looking at this code too but didn't have time
today to finish my thoughts ...
> Later, when deleting the assoc_data, the ref is not freed either,
> except in one error path where it is explicitly freed:
>
> if (!ieee80211_assoc_success(sdata, *bss, mgmt, len)) {
> /* oops -- internal error -- send timeout for now */
> ieee80211_destroy_assoc_data(sdata, false);
> cfg80211_put_bss(sdata->local->hw.wiphy, *bss);
> return RX_MGMT_CFG80211_ASSOC_TIMEOUT;
> }
>
> This seems ripe for bugs, if not already buggy.
>
> Maybe we should be more explicit about always grabbing a ref when
> we take a reference to the pointer, and always put it when we
> destroy the pointer?
I think the reference is actually given to mac80211 by cfg80211 in
cfg80211_mlme_assoc(), so we shouldn't need to grab a reference?
Although I'm certainly willing to change this and make cfg80211 always
put the reference after calling rdev_assoc() so that the driver/mac80211
would be responsible for obtaining its own if it needs to hang on to the
struct.
This does seem broken though.
johannes
^ permalink raw reply
* Lots of confusion on bss refcounting.
From: Ben Greear @ 2013-06-17 18:49 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
More on looking for bss and ies leaks...
I am trying to understand the bss refcounting, but everywhere I
look it seems like the code is weird at best.
For instance:
We create an assoc_data, assign a bss pointer in ieee80211_mgd_assoc,
but do not claim a reference.
Later, when deleting the assoc_data, the ref is not freed either,
except in one error path where it is explicitly freed:
if (!ieee80211_assoc_success(sdata, *bss, mgmt, len)) {
/* oops -- internal error -- send timeout for now */
ieee80211_destroy_assoc_data(sdata, false);
cfg80211_put_bss(sdata->local->hw.wiphy, *bss);
return RX_MGMT_CFG80211_ASSOC_TIMEOUT;
}
This seems ripe for bugs, if not already buggy.
Maybe we should be more explicit about always grabbing a ref when
we take a reference to the pointer, and always put it when we
destroy the pointer?
I'll be happy to cook up some patches if this seems like the right
path to take.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* pull request: wireless 2013-06-17
From: John W. Linville @ 2013-06-17 18:27 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 22051 bytes --]
Dave,
This will probably be the last batch of wireless fixes intended
for 3.10. Many of these are one- or two-liners, and a couple of
others are mostly relocating existing code to avoid races or to
limit the code to effecting specific hardware, etc.
The mac80211 fixes have a couple of exceptions to the above.
Regarding those, Johannes says:
"Following davem's complaint about my patch, here's a new pull request
w/o the patch he was complaining about, but instead with the const
fix rolled into the fix.
I have a fix for radar detection, one for rate control and a workaround
for broken HT APs which is a regression fix because we didn't rely
on them to be correct before."
Johannes also sends some iwlwifi fixes:
"I picked up Nikolay's patch for the chain noise calibration bug
that seems to have been there forever, a fix from Emmanuel for
setting TX flags on BAR frames and a fix of my own to avoid printing
request_module() errors if the kernel isn't even modular. We also
have our own version of Stanislaw's fix for rate control."
Along with those...
Anderson Lizardo fixes a Bluetooth memory corruption bug when an MTU
value is set to too small of a value.
Arend van Spriel sends a revised brcmsmac bug that fixes a regression
caused by a bad return value in an earlier patch. He also sends a
brcmfmac fix to avoid an oops when loading the driver at boot.
Daniel Drake fixes a race condition in btmrvl that causes hangs on
suspend for OLPC hardware.
Johan Hedberg adds a check to avoid sending a
HCI_Delete_Stored_Link_Key command to devices that don't support them,
avoiding some scary looking log spam.
Stanislaw Gruszka gives us a fix for iwlegacy to be able to use rates
higher than 1Mb/s on older wireless networks. He also sends an rt2x00
fix to reinstate older tx power handling behavior for some devices
that didn't work well with the current code.
Please let me know if there are problems! If you don't want to
pull this batch for 3.10, then I will go ahead and pull them into
wireless-next...
John
---
The following changes since commit 8177a9d79c0e942dcac3312f15585d0344d505a5:
lseek(fd, n, SEEK_END) does *not* go to eof - n (2013-06-16 08:10:53 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 722a300bf84ebebe21da164e75024c0ce7ca1868:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-06-17 13:44:01 -0400)
----------------------------------------------------------------
Anderson Lizardo (1):
Bluetooth: Fix crash in l2cap_build_cmd() with small MTU
Arend van Spriel (2):
brcmsmac: disable power-save related functions
brcmfmac: free primary net_device when brcmf_bus_start() fails
Daniel Drake (1):
Bluetooth: btmrvl: fix thread stopping race
Emmanuel Grumbach (1):
iwlwifi: mvm: correctly set the flags for BAR
Johan Hedberg (1):
Bluetooth: Fix conditions for HCI_Delete_Stored_Link_Key
Johannes Berg (2):
iwlwifi: don't print module loading error if not modular
mac80211: work around broken APs not including HT info
John W. Linville (3):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Moshe Benji (1):
iwlwifi: fix rate control regression
Nikolay Martynov (1):
iwlwifi: dvm: fix chain noise calibration
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
Stanislaw Gruszka (2):
iwlegacy: fix rate control regression
rt2800: fix RT5390 & RT3290 TX power settings regression
drivers/bluetooth/btmrvl_main.c | 9 +--
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 4 +
drivers/net/wireless/brcm80211/brcmsmac/main.c | 17 +----
drivers/net/wireless/iwlegacy/3945-rs.c | 1 +
drivers/net/wireless/iwlegacy/4965-rs.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/rs.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/rxon.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 2 +
drivers/net/wireless/iwlwifi/mvm/rs.c | 1 +
drivers/net/wireless/iwlwifi/mvm/tx.c | 3 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 29 +++++---
net/bluetooth/hci_core.c | 15 ++--
net/bluetooth/l2cap_core.c | 3 +
net/mac80211/cfg.c | 6 ++
net/mac80211/ieee80211_i.h | 5 +-
net/mac80211/mlme.c | 87 ++++++++++++++++++++--
net/mac80211/rate.c | 2 +-
net/mac80211/util.c | 4 +-
18 files changed, 142 insertions(+), 52 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 3a4343b..9a9f518 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -498,6 +498,10 @@ static int btmrvl_service_main_thread(void *data)
add_wait_queue(&thread->wait_q, &wait);
set_current_state(TASK_INTERRUPTIBLE);
+ if (kthread_should_stop()) {
+ BT_DBG("main_thread: break from main thread");
+ break;
+ }
if (adapter->wakeup_tries ||
((!adapter->int_count) &&
@@ -513,11 +517,6 @@ static int btmrvl_service_main_thread(void *data)
BT_DBG("main_thread woke up");
- if (kthread_should_stop()) {
- BT_DBG("main_thread: break from main thread");
- break;
- }
-
spin_lock_irqsave(&priv->driver_lock, flags);
if (adapter->int_count) {
adapter->int_count = 0;
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
index b98f223..2c59357 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
@@ -930,6 +930,10 @@ fail:
brcmf_fws_del_interface(ifp);
brcmf_fws_deinit(drvr);
}
+ if (drvr->iflist[0]) {
+ free_netdev(ifp->ndev);
+ drvr->iflist[0] = NULL;
+ }
if (p2p_ifp) {
free_netdev(p2p_ifp->ndev);
drvr->iflist[1] = NULL;
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 28e7aee..9fd6f2f 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -3074,21 +3074,8 @@ static void brcms_b_antsel_set(struct brcms_hardware *wlc_hw, u32 antsel_avail)
*/
static bool brcms_c_ps_allowed(struct brcms_c_info *wlc)
{
- /* disallow PS when one of the following global conditions meets */
- if (!wlc->pub->associated)
- return false;
-
- /* disallow PS when one of these meets when not scanning */
- if (wlc->filter_flags & FIF_PROMISC_IN_BSS)
- return false;
-
- if (wlc->bsscfg->type == BRCMS_TYPE_AP)
- return false;
-
- if (wlc->bsscfg->type == BRCMS_TYPE_ADHOC)
- return false;
-
- return true;
+ /* not supporting PS so always return false for now */
+ return false;
}
static void brcms_c_statsupd(struct brcms_c_info *wlc)
diff --git a/drivers/net/wireless/iwlegacy/3945-rs.c b/drivers/net/wireless/iwlegacy/3945-rs.c
index c9f197d..fe31590 100644
--- a/drivers/net/wireless/iwlegacy/3945-rs.c
+++ b/drivers/net/wireless/iwlegacy/3945-rs.c
@@ -816,6 +816,7 @@ out:
rs_sta->last_txrate_idx = idx;
info->control.rates[0].idx = rs_sta->last_txrate_idx;
}
+ info->control.rates[0].count = 1;
D_RATE("leave: %d\n", idx);
}
diff --git a/drivers/net/wireless/iwlegacy/4965-rs.c b/drivers/net/wireless/iwlegacy/4965-rs.c
index 1fc0b22..ed3c42a 100644
--- a/drivers/net/wireless/iwlegacy/4965-rs.c
+++ b/drivers/net/wireless/iwlegacy/4965-rs.c
@@ -2268,7 +2268,7 @@ il4965_rs_get_rate(void *il_r, struct ieee80211_sta *sta, void *il_sta,
info->control.rates[0].flags = 0;
}
info->control.rates[0].idx = rate_idx;
-
+ info->control.rates[0].count = 1;
}
static void *
diff --git a/drivers/net/wireless/iwlwifi/dvm/rs.c b/drivers/net/wireless/iwlwifi/dvm/rs.c
index 907bd6e..10fbb17 100644
--- a/drivers/net/wireless/iwlwifi/dvm/rs.c
+++ b/drivers/net/wireless/iwlwifi/dvm/rs.c
@@ -2799,7 +2799,7 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta, void *priv_sta,
info->control.rates[0].flags = 0;
}
info->control.rates[0].idx = rate_idx;
-
+ info->control.rates[0].count = 1;
}
static void *rs_alloc_sta(void *priv_rate, struct ieee80211_sta *sta,
diff --git a/drivers/net/wireless/iwlwifi/dvm/rxon.c b/drivers/net/wireless/iwlwifi/dvm/rxon.c
index 707446f..cd1ad001 100644
--- a/drivers/net/wireless/iwlwifi/dvm/rxon.c
+++ b/drivers/net/wireless/iwlwifi/dvm/rxon.c
@@ -1378,7 +1378,7 @@ static void iwlagn_chain_noise_reset(struct iwl_priv *priv)
struct iwl_chain_noise_data *data = &priv->chain_noise_data;
int ret;
- if (!(priv->calib_disabled & IWL_CHAIN_NOISE_CALIB_DISABLED))
+ if (priv->calib_disabled & IWL_CHAIN_NOISE_CALIB_DISABLED)
return;
if ((data->state == IWL_CHAIN_NOISE_ALIVE) &&
diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c b/drivers/net/wireless/iwlwifi/iwl-drv.c
index 39aad98..40fed1f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -1000,10 +1000,12 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
*/
if (load_module) {
err = request_module("%s", op->name);
+#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
if (err)
IWL_ERR(drv,
"failed to load module %s (error %d), is dynamic loading enabled?\n",
op->name, err);
+#endif
}
return;
diff --git a/drivers/net/wireless/iwlwifi/mvm/rs.c b/drivers/net/wireless/iwlwifi/mvm/rs.c
index 55334d5..b99fe31 100644
--- a/drivers/net/wireless/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/iwlwifi/mvm/rs.c
@@ -2546,6 +2546,7 @@ static void rs_get_rate(void *mvm_r, struct ieee80211_sta *sta, void *mvm_sta,
info->control.rates[0].flags = 0;
}
info->control.rates[0].idx = rate_idx;
+ info->control.rates[0].count = 1;
}
static void *rs_alloc_sta(void *mvm_rate, struct ieee80211_sta *sta,
diff --git a/drivers/net/wireless/iwlwifi/mvm/tx.c b/drivers/net/wireless/iwlwifi/mvm/tx.c
index f212f16..48c1891 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
@@ -180,7 +180,8 @@ static void iwl_mvm_set_tx_cmd_rate(struct iwl_mvm *mvm,
tx_cmd->tx_flags |= cpu_to_le32(TX_CMD_FLG_STA_RATE);
return;
} else if (ieee80211_is_back_req(fc)) {
- tx_cmd->tx_flags |= cpu_to_le32(TX_CMD_FLG_STA_RATE);
+ tx_cmd->tx_flags |=
+ cpu_to_le32(TX_CMD_FLG_ACK | TX_CMD_FLG_BAR);
}
/* HT rate doesn't make sense for a non data frame */
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index b52d70c..72f32e5 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -3027,19 +3027,26 @@ static void rt2800_config_txpower(struct rt2x00_dev *rt2x00dev,
* TODO: we do not use +6 dBm option to do not increase power beyond
* regulatory limit, however this could be utilized for devices with
* CAPABILITY_POWER_LIMIT.
+ *
+ * TODO: add different temperature compensation code for RT3290 & RT5390
+ * to allow to use BBP_R1 for those chips.
*/
- rt2800_bbp_read(rt2x00dev, 1, &r1);
- if (delta <= -12) {
- power_ctrl = 2;
- delta += 12;
- } else if (delta <= -6) {
- power_ctrl = 1;
- delta += 6;
- } else {
- power_ctrl = 0;
+ if (!rt2x00_rt(rt2x00dev, RT3290) &&
+ !rt2x00_rt(rt2x00dev, RT5390)) {
+ rt2800_bbp_read(rt2x00dev, 1, &r1);
+ if (delta <= -12) {
+ power_ctrl = 2;
+ delta += 12;
+ } else if (delta <= -6) {
+ power_ctrl = 1;
+ delta += 6;
+ } else {
+ power_ctrl = 0;
+ }
+ rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, power_ctrl);
+ rt2800_bbp_write(rt2x00dev, 1, r1);
}
- rt2x00_set_field8(&r1, BBP1_TX_POWER_CTRL, power_ctrl);
- rt2800_bbp_write(rt2x00dev, 1, r1);
+
offset = TX_PWR_CFG_0;
for (i = 0; i < EEPROM_TXPOWER_BYRATE_SIZE; i += 2) {
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d817c93..ace5e55 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -341,7 +341,6 @@ static void hci_init1_req(struct hci_request *req, unsigned long opt)
static void bredr_setup(struct hci_request *req)
{
- struct hci_cp_delete_stored_link_key cp;
__le16 param;
__u8 flt_type;
@@ -365,10 +364,6 @@ static void bredr_setup(struct hci_request *req)
param = __constant_cpu_to_le16(0x7d00);
hci_req_add(req, HCI_OP_WRITE_CA_TIMEOUT, 2, ¶m);
- bacpy(&cp.bdaddr, BDADDR_ANY);
- cp.delete_all = 0x01;
- hci_req_add(req, HCI_OP_DELETE_STORED_LINK_KEY, sizeof(cp), &cp);
-
/* Read page scan parameters */
if (req->hdev->hci_ver > BLUETOOTH_VER_1_1) {
hci_req_add(req, HCI_OP_READ_PAGE_SCAN_ACTIVITY, 0, NULL);
@@ -602,6 +597,16 @@ static void hci_init3_req(struct hci_request *req, unsigned long opt)
struct hci_dev *hdev = req->hdev;
u8 p;
+ /* Only send HCI_Delete_Stored_Link_Key if it is supported */
+ if (hdev->commands[6] & 0x80) {
+ struct hci_cp_delete_stored_link_key cp;
+
+ bacpy(&cp.bdaddr, BDADDR_ANY);
+ cp.delete_all = 0x01;
+ hci_req_add(req, HCI_OP_DELETE_STORED_LINK_KEY,
+ sizeof(cp), &cp);
+ }
+
if (hdev->commands[5] & 0x10)
hci_setup_link_policy(req);
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 24bee07..4be6a26 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2852,6 +2852,9 @@ static struct sk_buff *l2cap_build_cmd(struct l2cap_conn *conn, u8 code,
BT_DBG("conn %p, code 0x%2.2x, ident 0x%2.2x, len %u",
conn, code, ident, dlen);
+ if (conn->mtu < L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE)
+ return NULL;
+
len = L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE + dlen;
count = min_t(unsigned int, conn->mtu, len);
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1a89c80..4fdb306e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1057,6 +1057,12 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+ if (sdata->wdev.cac_started) {
+ cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
+ cfg80211_cac_event(sdata->dev, NL80211_RADAR_CAC_ABORTED,
+ GFP_KERNEL);
+ }
+
drv_stop_ap(sdata->local, sdata);
/* free all potentially still buffered bcast frames */
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 44be28c..9ca8e32 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1497,10 +1497,11 @@ static inline void ieee80211_tx_skb(struct ieee80211_sub_if_data *sdata,
ieee80211_tx_skb_tid(sdata, skb, 7);
}
-u32 ieee802_11_parse_elems_crc(u8 *start, size_t len, bool action,
+u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
struct ieee802_11_elems *elems,
u64 filter, u32 crc);
-static inline void ieee802_11_parse_elems(u8 *start, size_t len, bool action,
+static inline void ieee802_11_parse_elems(const u8 *start, size_t len,
+ bool action,
struct ieee802_11_elems *elems)
{
ieee802_11_parse_elems_crc(start, len, action, elems, 0, 0);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index a8c2130..741448b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2522,8 +2522,11 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
u16 capab_info, aid;
struct ieee802_11_elems elems;
struct ieee80211_bss_conf *bss_conf = &sdata->vif.bss_conf;
+ const struct cfg80211_bss_ies *bss_ies = NULL;
+ struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
u32 changed = 0;
int err;
+ bool ret;
/* AssocResp and ReassocResp have identical structure */
@@ -2555,21 +2558,86 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
ifmgd->aid = aid;
/*
+ * Some APs are erroneously not including some information in their
+ * (re)association response frames. Try to recover by using the data
+ * from the beacon or probe response. This seems to afflict mobile
+ * 2G/3G/4G wifi routers, reported models include the "Onda PN51T",
+ * "Vodafone PocketWiFi 2", "ZTE MF60" and a similar T-Mobile device.
+ */
+ if ((assoc_data->wmm && !elems.wmm_param) ||
+ (!(ifmgd->flags & IEEE80211_STA_DISABLE_HT) &&
+ (!elems.ht_cap_elem || !elems.ht_operation)) ||
+ (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT) &&
+ (!elems.vht_cap_elem || !elems.vht_operation))) {
+ const struct cfg80211_bss_ies *ies;
+ struct ieee802_11_elems bss_elems;
+
+ rcu_read_lock();
+ ies = rcu_dereference(cbss->ies);
+ if (ies)
+ bss_ies = kmemdup(ies, sizeof(*ies) + ies->len,
+ GFP_ATOMIC);
+ rcu_read_unlock();
+ if (!bss_ies)
+ return false;
+
+ ieee802_11_parse_elems(bss_ies->data, bss_ies->len,
+ false, &bss_elems);
+ if (assoc_data->wmm &&
+ !elems.wmm_param && bss_elems.wmm_param) {
+ elems.wmm_param = bss_elems.wmm_param;
+ sdata_info(sdata,
+ "AP bug: WMM param missing from AssocResp\n");
+ }
+
+ /*
+ * Also check if we requested HT/VHT, otherwise the AP doesn't
+ * have to include the IEs in the (re)association response.
+ */
+ if (!elems.ht_cap_elem && bss_elems.ht_cap_elem &&
+ !(ifmgd->flags & IEEE80211_STA_DISABLE_HT)) {
+ elems.ht_cap_elem = bss_elems.ht_cap_elem;
+ sdata_info(sdata,
+ "AP bug: HT capability missing from AssocResp\n");
+ }
+ if (!elems.ht_operation && bss_elems.ht_operation &&
+ !(ifmgd->flags & IEEE80211_STA_DISABLE_HT)) {
+ elems.ht_operation = bss_elems.ht_operation;
+ sdata_info(sdata,
+ "AP bug: HT operation missing from AssocResp\n");
+ }
+ if (!elems.vht_cap_elem && bss_elems.vht_cap_elem &&
+ !(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) {
+ elems.vht_cap_elem = bss_elems.vht_cap_elem;
+ sdata_info(sdata,
+ "AP bug: VHT capa missing from AssocResp\n");
+ }
+ if (!elems.vht_operation && bss_elems.vht_operation &&
+ !(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) {
+ elems.vht_operation = bss_elems.vht_operation;
+ sdata_info(sdata,
+ "AP bug: VHT operation missing from AssocResp\n");
+ }
+ }
+
+ /*
* We previously checked these in the beacon/probe response, so
* they should be present here. This is just a safety net.
*/
if (!(ifmgd->flags & IEEE80211_STA_DISABLE_HT) &&
(!elems.wmm_param || !elems.ht_cap_elem || !elems.ht_operation)) {
sdata_info(sdata,
- "HT AP is missing WMM params or HT capability/operation in AssocResp\n");
- return false;
+ "HT AP is missing WMM params or HT capability/operation\n");
+ ret = false;
+ goto out;
}
if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT) &&
(!elems.vht_cap_elem || !elems.vht_operation)) {
sdata_info(sdata,
- "VHT AP is missing VHT capability/operation in AssocResp\n");
- return false;
+ "VHT AP is missing VHT capability/operation\n");
+ ret = false;
+ goto out;
}
mutex_lock(&sdata->local->sta_mtx);
@@ -2580,7 +2648,8 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
sta = sta_info_get(sdata, cbss->bssid);
if (WARN_ON(!sta)) {
mutex_unlock(&sdata->local->sta_mtx);
- return false;
+ ret = false;
+ goto out;
}
sband = local->hw.wiphy->bands[ieee80211_get_sdata_band(sdata)];
@@ -2633,7 +2702,8 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
sta->sta.addr);
WARN_ON(__sta_info_destroy(sta));
mutex_unlock(&sdata->local->sta_mtx);
- return false;
+ ret = false;
+ goto out;
}
mutex_unlock(&sdata->local->sta_mtx);
@@ -2673,7 +2743,10 @@ static bool ieee80211_assoc_success(struct ieee80211_sub_if_data *sdata,
ieee80211_sta_rx_notify(sdata, (struct ieee80211_hdr *)mgmt);
ieee80211_sta_reset_beacon_monitor(sdata);
- return true;
+ ret = true;
+ out:
+ kfree(bss_ies);
+ return ret;
}
static enum rx_mgmt_action __must_check
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index d3f414f..a02bef3 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -615,7 +615,7 @@ static void rate_control_apply_mask(struct ieee80211_sub_if_data *sdata,
if (rates[i].idx < 0)
break;
- rate_idx_match_mask(&rates[i], sband, mask, chan_width,
+ rate_idx_match_mask(&rates[i], sband, chan_width, mask,
mcs_mask);
}
}
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 27e0715..72e6292 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -661,12 +661,12 @@ void ieee80211_queue_delayed_work(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_queue_delayed_work);
-u32 ieee802_11_parse_elems_crc(u8 *start, size_t len, bool action,
+u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
struct ieee802_11_elems *elems,
u64 filter, u32 crc)
{
size_t left = len;
- u8 *pos = start;
+ const u8 *pos = start;
bool calc_crc = filter != 0;
DECLARE_BITMAP(seen_elems, 256);
const u8 *ie;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH] rtlwifi: rtl8192cu: Add new USB ID for TP-Link TL-WN8200ND
From: Larry Finger @ 2013-06-17 18:25 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Tobias Kluge, Stable
This is a new device for this driver.
Reported-by: Tobias Kluge <zielscheibe@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Tobias Kluge <zielscheibe@gmail.com>
Cc: Stable <stable@vger.kernel.org>
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 826f085..2bd5985 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -359,6 +359,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/
{RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/
+ {RTL_USB_DEVICE(0x2357, 0x0100, rtl92cu_hal_cfg)}, /*TP-Link WN8200ND*/
{RTL_USB_DEVICE(0x7392, 0x7822, rtl92cu_hal_cfg)}, /*Edimax -Edimax*/
{}
};
--
1.8.1.4
^ permalink raw reply related
* Re: rtl8192cu fail to connect with a AP
From: Larry Finger @ 2013-06-17 18:12 UTC (permalink / raw)
To: Tobias Kluge; +Cc: linux-wireless
In-Reply-To: <loom.20130617T185506-165@post.gmane.org>
On 06/17/2013 12:03 PM, Tobias Kluge wrote:
>
> compiled the latest stable kernel (3.9.6) with your fixed device table, the
> dongle is now recognized properly, when the module (rtl8192cu) is loaded.
> The connection issue to any AP still remains, with the same dmesg output. I
> don't believe that the changes you mentioned in 3.10.0-rc6 are the trouble
> makers with this device. I tried many different kernels before (3.26, 3.8.0
> binaries from the Ubuntu sources, 3.9.6, 3.10.0-rc6 build from scratch). I
> hope you can see some possibilities to fix this problem.
The changes in 3.10-rc6 *fix* many problems. They are not the source of them.
Using the wireless-testing tree, my RTL8188RU will connect to a WPA2/AES AP. It
authenticates and associates with WPA1/TKIP and WEP APs, but there is no data
throughput. To me this indicates a problem with the wireless keys. I have no
idea (yet) why some chips are different than others.
Larry
^ permalink raw reply
* [PATCH] ssb: add struct for serial flash
From: Rafał Miłecki @ 2013-06-17 17:56 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: Hauke Mehrtens, Rafał Miłecki
This data allow writing for example MTD driver.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/ssb/driver_chipcommon_sflash.c | 7 +++++++
include/linux/ssb/ssb_driver_mips.h | 15 +++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/drivers/ssb/driver_chipcommon_sflash.c b/drivers/ssb/driver_chipcommon_sflash.c
index 1b9e770..205f1c4 100644
--- a/drivers/ssb/driver_chipcommon_sflash.c
+++ b/drivers/ssb/driver_chipcommon_sflash.c
@@ -73,6 +73,7 @@ static void ssb_sflash_cmd(struct ssb_chipcommon *cc, u32 opcode)
/* Initialize serial flash access */
int ssb_sflash_init(struct ssb_chipcommon *cc)
{
+ struct ssb_sflash *sflash = &cc->dev->bus->mipscore.sflash;
const struct ssb_sflash_tbl_e *e;
u32 id, id2;
@@ -131,6 +132,12 @@ int ssb_sflash_init(struct ssb_chipcommon *cc)
return -ENOTSUPP;
}
+ sflash->window = SSB_FLASH2;
+ sflash->blocksize = e->blocksize;
+ sflash->numblocks = e->numblocks;
+ sflash->size = sflash->blocksize * sflash->numblocks;
+ sflash->present = true;
+
pr_info("Found %s serial flash (blocksize: 0x%X, blocks: %d)\n",
e->name, e->blocksize, e->numblocks);
diff --git a/include/linux/ssb/ssb_driver_mips.h b/include/linux/ssb/ssb_driver_mips.h
index afe79d4..6535e47 100644
--- a/include/linux/ssb/ssb_driver_mips.h
+++ b/include/linux/ssb/ssb_driver_mips.h
@@ -20,6 +20,18 @@ struct ssb_pflash {
u32 window_size;
};
+#ifdef CONFIG_SSB_SFLASH
+struct ssb_sflash {
+ bool present;
+ u32 window;
+ u32 blocksize;
+ u16 numblocks;
+ u32 size;
+
+ void *priv;
+};
+#endif
+
struct ssb_mipscore {
struct ssb_device *dev;
@@ -27,6 +39,9 @@ struct ssb_mipscore {
struct ssb_serial_port serial_ports[4];
struct ssb_pflash pflash;
+#ifdef CONFIG_SSB_SFLASH
+ struct ssb_sflash sflash;
+#endif
};
extern void ssb_mipscore_init(struct ssb_mipscore *mcore);
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH] net: brcmfmac: add sdio chip id 0x4319
From: Jason Cooper @ 2013-06-17 17:51 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Franky Lin, rvossen, arend, linux-wireless
In-Reply-To: <CACna6ryw=QeD5OuMWYoZLYzt9CBo+PO-SwygDY+SUaVxCYu0jA@mail.gmail.com>
On Mon, Jun 17, 2013 at 07:45:25PM +0200, Rafał Miłecki wrote:
> 2013/6/17 Franky Lin <frankyl@broadcom.com>:
> > On 06/17/2013 09:19 AM, Jason Cooper wrote:
> >>
> >> Added Franky...
> >>
> >> On Wed, Jun 12, 2013 at 06:21:23PM -0400, Jason Cooper wrote:
> >>>
> >>> All,
> >>>
> >>> I have a Seagate Wireless Plus I am trying to put a vanilla kernel on
> >>> (currently v3.10-rc5 for various omap DT bits).
> >>>
> >>> I have the board booting and running a debian rootfs on the HD. I just
> >>> got mmc to come up and I've discovered that the wireless card is vendor
> >>> 0x02d0, device 0x4319.
> >>>
> >>> My hope, once I got to this point, was that I would be able to use
> >>> the mainline, open source driver. Unfortunately, it looks like brcmfmac
> >>> lost support for the 0x4319 while it was in staging.
> >>>
> >>> The commit in question is:
> >>>
> >>> 4dad253 staging: brcm80211: remove code for unsupported chip
> >>>
> >>> Is adding it back in a bridge too far?
> >>
> >> It looks like only two things are needed, adding the chip id and then
> >> setting the addresses. Here's a preliminary patch to do just that.
> >> Note, the addresses I have used are a straight copy from the 4329. It
> >> causes this:
> >>
> >> [ 12.346466] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
> >> [ 12.353149] brcmfmac_sdio mmc0:0001:1: no of_node; not parsing pinctrl
> >> DT
> >> [ 12.360717] brcmfmac_sdio mmc0:0001:2: no of_node; not parsing pinctrl
> >> DT
> >> [ 12.368804] brcmfmac: brcmf_sdio_chip_drivestrengthinit: No SDIO Drive
> >> strength init done for chip 4319 rev 1 pmurev 7
> >> [ 12.380462] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
> >> F0:@0x00408=03, Err: -22
> >> [ 12.391906] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
> >> F0:@0x00408=03, Err: -22
> >> [ 12.403289] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
> >> F0:@0x00408=03, Err: -22
> >> [ 12.412261] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
> >> [ 12.418457] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
> >> F0:@0x00408=01, Err: -22
> >> [ 12.429718] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
> >> F0:@0x00408=01, Err: -22
> >> [ 12.441101] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
> >> F0:@0x00408=01, Err: -22
> >> [ 12.450073] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
> >>
> >> I've taken a quick look at aosp, the provided GPL broadcom code, and I
> >> haven't seen anything for the 4319 wrt to addresses. How hard would it
> >> be to get those addresses from you guys?
> >
> >
> > Hi Jason,
> >
> > The major obstacle of adding 4319 support is the obsolete firmware. Since
> > it's an EOL chip we are not planning to add the support to brcmfmac.
>
> Does it mean, BCM4319 is a "new architecture" chipset, working
> similarly to the already supported (in brcmfmac) chipsets?
In older versions of the broadcom driver 4329 and 4319 were in the same
code base. There was minimal reference to 4319 beyond "I work with this
chip id". Hence my attempt.
Now I'm wondering how much effort there would be to adding legacy
firmware support to brcmfmac. I would only need AP mode to start with
(yeah, no big deal ;-) ).
thx,
Jason.
^ permalink raw reply
* Re: [RFC PATCH] net: brcmfmac: add sdio chip id 0x4319
From: Jason Cooper @ 2013-06-17 17:45 UTC (permalink / raw)
To: Franky Lin; +Cc: rvossen, arend, linux-wireless
In-Reply-To: <51BF498F.1010007@broadcom.com>
On Mon, Jun 17, 2013 at 10:38:23AM -0700, Franky Lin wrote:
> On 06/17/2013 09:19 AM, Jason Cooper wrote:
> >Added Franky...
> >
> >On Wed, Jun 12, 2013 at 06:21:23PM -0400, Jason Cooper wrote:
> >>All,
> >>
> >>I have a Seagate Wireless Plus I am trying to put a vanilla kernel on
> >>(currently v3.10-rc5 for various omap DT bits).
> >>
> >>I have the board booting and running a debian rootfs on the HD. I just
> >>got mmc to come up and I've discovered that the wireless card is vendor
> >>0x02d0, device 0x4319.
> >>
> >>My hope, once I got to this point, was that I would be able to use
> >>the mainline, open source driver. Unfortunately, it looks like brcmfmac
> >>lost support for the 0x4319 while it was in staging.
> >>
> >>The commit in question is:
> >>
> >> 4dad253 staging: brcm80211: remove code for unsupported chip
> >>
> >>Is adding it back in a bridge too far?
> >It looks like only two things are needed, adding the chip id and then
> >setting the addresses. Here's a preliminary patch to do just that.
> >Note, the addresses I have used are a straight copy from the 4329. It
> >causes this:
> >
> >[ 12.346466] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
> >[ 12.353149] brcmfmac_sdio mmc0:0001:1: no of_node; not parsing pinctrl DT
> >[ 12.360717] brcmfmac_sdio mmc0:0001:2: no of_node; not parsing pinctrl DT
> >[ 12.368804] brcmfmac: brcmf_sdio_chip_drivestrengthinit: No SDIO Drive strength init done for chip 4319 rev 1 pmurev 7
> >[ 12.380462] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
> >[ 12.391906] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
> >[ 12.403289] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
> >[ 12.412261] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
> >[ 12.418457] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
> >[ 12.429718] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
> >[ 12.441101] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
> >[ 12.450073] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
> >
> >I've taken a quick look at aosp, the provided GPL broadcom code, and I
> >haven't seen anything for the 4319 wrt to addresses. How hard would it
> >be to get those addresses from you guys?
>
> Hi Jason,
>
> The major obstacle of adding 4319 support is the obsolete firmware.
> Since it's an EOL chip we are not planning to add the support to
> brcmfmac.
Let me guess, the firmware would have to be updated to work with
brcmfmac? What about adding a BRMCFMAC_LEGACY option to allow
interfacing with the old firmware?
It may be EOL, but new products are still shipping with this chip
(Wireless Plus, other Azurewave products).
thx,
Jason.
^ permalink raw reply
* Re: [RFC PATCH] net: brcmfmac: add sdio chip id 0x4319
From: Rafał Miłecki @ 2013-06-17 17:45 UTC (permalink / raw)
To: Franky Lin; +Cc: Jason Cooper, rvossen, arend, linux-wireless
In-Reply-To: <51BF498F.1010007@broadcom.com>
2013/6/17 Franky Lin <frankyl@broadcom.com>:
> On 06/17/2013 09:19 AM, Jason Cooper wrote:
>>
>> Added Franky...
>>
>> On Wed, Jun 12, 2013 at 06:21:23PM -0400, Jason Cooper wrote:
>>>
>>> All,
>>>
>>> I have a Seagate Wireless Plus I am trying to put a vanilla kernel on
>>> (currently v3.10-rc5 for various omap DT bits).
>>>
>>> I have the board booting and running a debian rootfs on the HD. I just
>>> got mmc to come up and I've discovered that the wireless card is vendor
>>> 0x02d0, device 0x4319.
>>>
>>> My hope, once I got to this point, was that I would be able to use
>>> the mainline, open source driver. Unfortunately, it looks like brcmfmac
>>> lost support for the 0x4319 while it was in staging.
>>>
>>> The commit in question is:
>>>
>>> 4dad253 staging: brcm80211: remove code for unsupported chip
>>>
>>> Is adding it back in a bridge too far?
>>
>> It looks like only two things are needed, adding the chip id and then
>> setting the addresses. Here's a preliminary patch to do just that.
>> Note, the addresses I have used are a straight copy from the 4329. It
>> causes this:
>>
>> [ 12.346466] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
>> [ 12.353149] brcmfmac_sdio mmc0:0001:1: no of_node; not parsing pinctrl
>> DT
>> [ 12.360717] brcmfmac_sdio mmc0:0001:2: no of_node; not parsing pinctrl
>> DT
>> [ 12.368804] brcmfmac: brcmf_sdio_chip_drivestrengthinit: No SDIO Drive
>> strength init done for chip 4319 rev 1 pmurev 7
>> [ 12.380462] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
>> F0:@0x00408=03, Err: -22
>> [ 12.391906] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
>> F0:@0x00408=03, Err: -22
>> [ 12.403289] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
>> F0:@0x00408=03, Err: -22
>> [ 12.412261] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
>> [ 12.418457] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
>> F0:@0x00408=01, Err: -22
>> [ 12.429718] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
>> F0:@0x00408=01, Err: -22
>> [ 12.441101] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte
>> F0:@0x00408=01, Err: -22
>> [ 12.450073] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
>>
>> I've taken a quick look at aosp, the provided GPL broadcom code, and I
>> haven't seen anything for the 4319 wrt to addresses. How hard would it
>> be to get those addresses from you guys?
>
>
> Hi Jason,
>
> The major obstacle of adding 4319 support is the obsolete firmware. Since
> it's an EOL chip we are not planning to add the support to brcmfmac.
Does it mean, BCM4319 is a "new architecture" chipset, working
similarly to the already supported (in brcmfmac) chipsets?
When thinking about "old architecture" I mean BCM43236, which AFAIR
requires some different driver architecture with some extra memory
sharing or sth.
--
Rafał
^ permalink raw reply
* Re: [RFC PATCH] net: brcmfmac: add sdio chip id 0x4319
From: Franky Lin @ 2013-06-17 17:38 UTC (permalink / raw)
To: Jason Cooper; +Cc: rvossen, arend, linux-wireless
In-Reply-To: <20130617161903.GN31667@titan.lakedaemon.net>
On 06/17/2013 09:19 AM, Jason Cooper wrote:
> Added Franky...
>
> On Wed, Jun 12, 2013 at 06:21:23PM -0400, Jason Cooper wrote:
>> All,
>>
>> I have a Seagate Wireless Plus I am trying to put a vanilla kernel on
>> (currently v3.10-rc5 for various omap DT bits).
>>
>> I have the board booting and running a debian rootfs on the HD. I just
>> got mmc to come up and I've discovered that the wireless card is vendor
>> 0x02d0, device 0x4319.
>>
>> My hope, once I got to this point, was that I would be able to use
>> the mainline, open source driver. Unfortunately, it looks like brcmfmac
>> lost support for the 0x4319 while it was in staging.
>>
>> The commit in question is:
>>
>> 4dad253 staging: brcm80211: remove code for unsupported chip
>>
>> Is adding it back in a bridge too far?
> It looks like only two things are needed, adding the chip id and then
> setting the addresses. Here's a preliminary patch to do just that.
> Note, the addresses I have used are a straight copy from the 4329. It
> causes this:
>
> [ 12.346466] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
> [ 12.353149] brcmfmac_sdio mmc0:0001:1: no of_node; not parsing pinctrl DT
> [ 12.360717] brcmfmac_sdio mmc0:0001:2: no of_node; not parsing pinctrl DT
> [ 12.368804] brcmfmac: brcmf_sdio_chip_drivestrengthinit: No SDIO Drive strength init done for chip 4319 rev 1 pmurev 7
> [ 12.380462] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
> [ 12.391906] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
> [ 12.403289] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
> [ 12.412261] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
> [ 12.418457] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
> [ 12.429718] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
> [ 12.441101] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
> [ 12.450073] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
>
> I've taken a quick look at aosp, the provided GPL broadcom code, and I
> haven't seen anything for the 4319 wrt to addresses. How hard would it
> be to get those addresses from you guys?
Hi Jason,
The major obstacle of adding 4319 support is the obsolete firmware.
Since it's an EOL chip we are not planning to add the support to brcmfmac.
Franky
^ permalink raw reply
* [PATCH 2/2] bcma: use const for serial flash hardware table
From: Rafał Miłecki @ 2013-06-17 17:19 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: Rafał Miłecki
In-Reply-To: <1371489560-30433-1-git-send-email-zajec5@gmail.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/bcma/driver_chipcommon_sflash.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bcma/driver_chipcommon_sflash.c b/drivers/bcma/driver_chipcommon_sflash.c
index e6ed4fe..4d07cce 100644
--- a/drivers/bcma/driver_chipcommon_sflash.c
+++ b/drivers/bcma/driver_chipcommon_sflash.c
@@ -30,7 +30,7 @@ struct bcma_sflash_tbl_e {
u16 numblocks;
};
-static struct bcma_sflash_tbl_e bcma_sflash_st_tbl[] = {
+static const struct bcma_sflash_tbl_e bcma_sflash_st_tbl[] = {
{ "M25P20", 0x11, 0x10000, 4, },
{ "M25P40", 0x12, 0x10000, 8, },
@@ -41,7 +41,7 @@ static struct bcma_sflash_tbl_e bcma_sflash_st_tbl[] = {
{ 0 },
};
-static struct bcma_sflash_tbl_e bcma_sflash_sst_tbl[] = {
+static const struct bcma_sflash_tbl_e bcma_sflash_sst_tbl[] = {
{ "SST25WF512", 1, 0x1000, 16, },
{ "SST25VF512", 0x48, 0x1000, 16, },
{ "SST25WF010", 2, 0x1000, 32, },
@@ -59,7 +59,7 @@ static struct bcma_sflash_tbl_e bcma_sflash_sst_tbl[] = {
{ 0 },
};
-static struct bcma_sflash_tbl_e bcma_sflash_at_tbl[] = {
+static const struct bcma_sflash_tbl_e bcma_sflash_at_tbl[] = {
{ "AT45DB011", 0xc, 256, 512, },
{ "AT45DB021", 0x14, 256, 1024, },
{ "AT45DB041", 0x1c, 256, 2048, },
@@ -89,7 +89,7 @@ int bcma_sflash_init(struct bcma_drv_cc *cc)
{
struct bcma_bus *bus = cc->core->bus;
struct bcma_sflash *sflash = &cc->sflash;
- struct bcma_sflash_tbl_e *e;
+ const struct bcma_sflash_tbl_e *e;
u32 id, id2;
switch (cc->capabilities & BCMA_CC_CAP_FLASHT) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] ssb: use const for serial flash hardware table
From: Rafał Miłecki @ 2013-06-17 17:19 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/ssb/driver_chipcommon_sflash.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ssb/driver_chipcommon_sflash.c b/drivers/ssb/driver_chipcommon_sflash.c
index 720665c..1b9e770 100644
--- a/drivers/ssb/driver_chipcommon_sflash.c
+++ b/drivers/ssb/driver_chipcommon_sflash.c
@@ -16,7 +16,7 @@ struct ssb_sflash_tbl_e {
u16 numblocks;
};
-static struct ssb_sflash_tbl_e ssb_sflash_st_tbl[] = {
+static const struct ssb_sflash_tbl_e ssb_sflash_st_tbl[] = {
{ "M25P20", 0x11, 0x10000, 4, },
{ "M25P40", 0x12, 0x10000, 8, },
@@ -27,7 +27,7 @@ static struct ssb_sflash_tbl_e ssb_sflash_st_tbl[] = {
{ 0 },
};
-static struct ssb_sflash_tbl_e ssb_sflash_sst_tbl[] = {
+static const struct ssb_sflash_tbl_e ssb_sflash_sst_tbl[] = {
{ "SST25WF512", 1, 0x1000, 16, },
{ "SST25VF512", 0x48, 0x1000, 16, },
{ "SST25WF010", 2, 0x1000, 32, },
@@ -45,7 +45,7 @@ static struct ssb_sflash_tbl_e ssb_sflash_sst_tbl[] = {
{ 0 },
};
-static struct ssb_sflash_tbl_e ssb_sflash_at_tbl[] = {
+static const struct ssb_sflash_tbl_e ssb_sflash_at_tbl[] = {
{ "AT45DB011", 0xc, 256, 512, },
{ "AT45DB021", 0x14, 256, 1024, },
{ "AT45DB041", 0x1c, 256, 2048, },
@@ -73,7 +73,7 @@ static void ssb_sflash_cmd(struct ssb_chipcommon *cc, u32 opcode)
/* Initialize serial flash access */
int ssb_sflash_init(struct ssb_chipcommon *cc)
{
- struct ssb_sflash_tbl_e *e;
+ const struct ssb_sflash_tbl_e *e;
u32 id, id2;
switch (cc->capabilities & SSB_CHIPCO_CAP_FLASHT) {
--
1.7.10.4
^ permalink raw reply related
* Re: rtl8192cu fail to connect with a AP
From: Tobias Kluge @ 2013-06-17 17:03 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <51BF2996.9060102@lwfinger.net>
Larry Finger <Larry.Finger@...> writes:
>
> On 06/17/2013 09:06 AM, Tobias Kluge wrote:
> > Hi,
> >
> > I've recently bought a TP-Link TL-WN8200ND USB WiFi dongle, it uses the
> > Realtek 8192cu chipset.
> > After several attempts with different kernels (starting with 3.2.6) and
> > compat-wireless drivers, I'm still running into the same problem. The device
> > can successful scan for networks in reach, but cannot connect to any of
> > them, regardless the encryption (tried every mode, including no encryption
> > at all).
> >
> > At the moment I'm using the kernel release 3.10.0-rc6 and the device is
> > still not recognized by the "rtl8192cu" driver module without manually
> > setting the device ID into the SySFS
> >
> > "echo "2357 0100" > /sys/bus/usb/drivers/rtl8192cu/new_id"
>
> No one had reported that this device used rtl8192cu, thus it is not in the
> device tables, nor is it in the USB database as shown by the bare entry in
your
> lsusb output. Attached is a patch that will add your device to the tables.
That
> will be submitted to the maintainer relatively soon.
>
> There were a number of changes to that driver that just appeared in 3.10-rc6.
> These fixed a number of bug reports on the Red Hat bugzilla as shown in the
> commit message for commit 5b8df24. I had built 3.10-rc6 from the mainline git
> tree; however, I had not booted it till now. With it, my Edimax EW-7811Un
> adapter with an RTL8188CUS chip could connect to WEP, WPA1 and WPA2 APs;
> however, when I dug out my Alfa AWUS036NHR with an RTL8188RU chip, it
could not
> connect to any of my APs. I now need to check the results for the
> wireless-testing git tree, which I normally use, to see if there is a
difference
> in the two trees.
>
> Larry
>
>
>
> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> ===================================================================
> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> <at> <at> -359,6 +359,7 <at> <at> static struct usb_device_id
rtl8192c_usb
> {RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
> {RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/
> {RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/
> + {RTL_USB_DEVICE(0x2357, 0x0100, rtl92cu_hal_cfg)}, /*TP-Link WN8200ND*/
> {RTL_USB_DEVICE(0x7392, 0x7822, rtl92cu_hal_cfg)}, /*Edimax -Edimax*/
> {}
> };
>
>
Thank you for your effort Larry,
compiled the latest stable kernel (3.9.6) with your fixed device table, the
dongle is now recognized properly, when the module (rtl8192cu) is loaded.
The connection issue to any AP still remains, with the same dmesg output. I
don't believe that the changes you mentioned in 3.10.0-rc6 are the trouble
makers with this device. I tried many different kernels before (3.26, 3.8.0
binaries from the Ubuntu sources, 3.9.6, 3.10.0-rc6 build from scratch). I
hope you can see some possibilities to fix this problem.
Thank you in advance
Tobias
^ permalink raw reply
* Timer rollback in beacons on AR9342-based AP
From: Harshal Chhaya @ 2013-06-17 16:42 UTC (permalink / raw)
To: linux-wireless
Hello,
On an AR9342-based AP, we occasionally see the TSF timer in beacons
roll back i.e. the timer resets and starts over. This causes all
clients to disconnect probably because their power-save timers get out
of sync. This typically happens under heavy load.
The AP is running openwrt with compat-wireless from Feb 22nd 2013 and
the 1.0 release of hostapd (pkg version = 20120910).
Any ideas on what could be causing the timer to reset? What kind of
additional information would help in debugging this?
Thanks,
- Harshal
^ permalink raw reply
* [PATCH] bcma: update core (en|dis)abling functions
From: Rafał Miłecki @ 2013-06-17 16:34 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: Rafał Miłecki
Broadocm updated their code, this may be needed for newer hardware or
some corner cases.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/bcma/core.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/bcma/core.c b/drivers/bcma/core.c
index 17b26ce..37a5ffe 100644
--- a/drivers/bcma/core.c
+++ b/drivers/bcma/core.c
@@ -9,6 +9,25 @@
#include <linux/export.h>
#include <linux/bcma/bcma.h>
+static bool bcma_core_wait_value(struct bcma_device *core, u16 reg, u32 mask,
+ u32 value, int timeout)
+{
+ unsigned long deadline = jiffies + timeout;
+ u32 val;
+
+ do {
+ val = bcma_aread32(core, reg);
+ if ((val & mask) == value)
+ return true;
+ cpu_relax();
+ udelay(10);
+ } while (!time_after_eq(jiffies, deadline));
+
+ bcma_warn(core->bus, "Timeout waiting for register 0x%04X!\n", reg);
+
+ return false;
+}
+
bool bcma_core_is_enabled(struct bcma_device *core)
{
if ((bcma_aread32(core, BCMA_IOCTL) & (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC))
@@ -25,13 +44,15 @@ void bcma_core_disable(struct bcma_device *core, u32 flags)
if (bcma_aread32(core, BCMA_RESET_CTL) & BCMA_RESET_CTL_RESET)
return;
- bcma_awrite32(core, BCMA_IOCTL, flags);
- bcma_aread32(core, BCMA_IOCTL);
- udelay(10);
+ bcma_core_wait_value(core, BCMA_RESET_ST, ~0, 0, 300);
bcma_awrite32(core, BCMA_RESET_CTL, BCMA_RESET_CTL_RESET);
bcma_aread32(core, BCMA_RESET_CTL);
udelay(1);
+
+ bcma_awrite32(core, BCMA_IOCTL, flags);
+ bcma_aread32(core, BCMA_IOCTL);
+ udelay(10);
}
EXPORT_SYMBOL_GPL(bcma_core_disable);
@@ -43,6 +64,7 @@ int bcma_core_enable(struct bcma_device *core, u32 flags)
bcma_aread32(core, BCMA_IOCTL);
bcma_awrite32(core, BCMA_RESET_CTL, 0);
+ bcma_aread32(core, BCMA_RESET_CTL);
udelay(1);
bcma_awrite32(core, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
--
1.7.10.4
^ permalink raw reply related
* [RFC PATCH] net: brcmfmac: add sdio chip id 0x4319
From: Jason Cooper @ 2013-06-17 16:19 UTC (permalink / raw)
To: rvossen, arend, frankyl; +Cc: linux-wireless
In-Reply-To: <20130612222123.GB31667@titan.lakedaemon.net>
Added Franky...
On Wed, Jun 12, 2013 at 06:21:23PM -0400, Jason Cooper wrote:
> All,
>
> I have a Seagate Wireless Plus I am trying to put a vanilla kernel on
> (currently v3.10-rc5 for various omap DT bits).
>
> I have the board booting and running a debian rootfs on the HD. I just
> got mmc to come up and I've discovered that the wireless card is vendor
> 0x02d0, device 0x4319.
>
> My hope, once I got to this point, was that I would be able to use
> the mainline, open source driver. Unfortunately, it looks like brcmfmac
> lost support for the 0x4319 while it was in staging.
>
> The commit in question is:
>
> 4dad253 staging: brcm80211: remove code for unsupported chip
>
> Is adding it back in a bridge too far?
It looks like only two things are needed, adding the chip id and then
setting the addresses. Here's a preliminary patch to do just that.
Note, the addresses I have used are a straight copy from the 4329. It
causes this:
[ 12.346466] mmcblk mmc0:0001: no of_node; not parsing pinctrl DT
[ 12.353149] brcmfmac_sdio mmc0:0001:1: no of_node; not parsing pinctrl DT
[ 12.360717] brcmfmac_sdio mmc0:0001:2: no of_node; not parsing pinctrl DT
[ 12.368804] brcmfmac: brcmf_sdio_chip_drivestrengthinit: No SDIO Drive strength init done for chip 4319 rev 1 pmurev 7
[ 12.380462] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
[ 12.391906] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
[ 12.403289] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=03, Err: -22
[ 12.412261] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
[ 12.418457] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
[ 12.429718] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
[ 12.441101] brcmfmac: brcmf_sdioh_request_byte: Failed to write byte F0:@0x00408=01, Err: -22
[ 12.450073] brcmfmac: brcmf_sdio_regrw_helper: failed with -22
I've taken a quick look at aosp, the provided GPL broadcom code, and I
haven't seen anything for the 4319 wrt to addresses. How hard would it
be to get those addresses from you guys?
thx,
Jason.
----8<------
commit 8fa440e8d6da21c95cdbc9c1ced76d5962cd9e3d
Author: Jason Cooper <jason@lakedaemon.net>
Date: Mon Jun 17 15:30:43 2013 +0000
net: brcmfmac: add sdio chip id 0x4319
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
index 44fa0cd..75ddc2b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
@@ -43,6 +43,7 @@
#define SDIO_DEVICE_ID_BROADCOM_43143 43143
#define SDIO_DEVICE_ID_BROADCOM_43241 0x4324
+#define SDIO_DEVICE_ID_BROADCOM_4319 0x4319
#define SDIO_DEVICE_ID_BROADCOM_4329 0x4329
#define SDIO_DEVICE_ID_BROADCOM_4330 0x4330
#define SDIO_DEVICE_ID_BROADCOM_4334 0x4334
@@ -55,6 +56,7 @@
static const struct sdio_device_id brcmf_sdmmc_ids[] = {
{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_43143)},
{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_43241)},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4319)},
{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4329)},
{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4330)},
{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4334)},
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
index d248751..68816ec 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
@@ -3551,6 +3551,8 @@ static bool brcmf_sdbrcm_chipmatch(u16 chipid)
return true;
if (chipid == BCM43241_CHIP_ID)
return true;
+ if (chipid == BCM4319_CHIP_ID)
+ return true;
if (chipid == BCM4329_CHIP_ID)
return true;
if (chipid == BCM4330_CHIP_ID)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c b/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
index ca72177..4336dbb 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
@@ -31,6 +31,15 @@
#include "sdio_chip.h"
/* chip core base & ramsize */
+/* bcm4319 */
+/* SDIO device core, ID 0x829 */
+#define BCM4319_CORE_BUS_BASE 0x18011000
+/* internal memory core, ID 0x80e */
+#define BCM4319_CORE_SOCRAM_BASE 0x18003000
+/* ARM Cortex M3 core, ID 0x82a */
+#define BCM4319_CORE_ARM_BASE 0x18002000
+#define BCM4319_RAMSIZE 0x48000
+
/* bcm4329 */
/* SDIO device core, ID 0x829 */
#define BCM4329_CORE_BUS_BASE 0x18011000
@@ -484,6 +493,15 @@ static int brcmf_sdio_chip_recognition(struct brcmf_sdio_dev *sdiodev,
ci->c_inf[3].cib = 0x07004211;
ci->ramsize = 0x90000;
break;
+ case BCM4319_CHIP_ID:
+ ci->c_inf[1].id = BCMA_CORE_SDIO_DEV;
+ ci->c_inf[1].base = BCM4319_CORE_BUS_BASE;
+ ci->c_inf[2].id = BCMA_CORE_INTERNAL_MEM;
+ ci->c_inf[2].base = BCM4319_CORE_SOCRAM_BASE;
+ ci->c_inf[3].id = BCMA_CORE_ARM_CM3;
+ ci->c_inf[3].base = BCM4319_CORE_ARM_BASE;
+ ci->ramsize = BCM4319_RAMSIZE;
+ break;
case BCM4329_CHIP_ID:
ci->c_inf[1].id = BCMA_CORE_SDIO_DEV;
ci->c_inf[1].base = BCM4329_CORE_BUS_BASE;
diff --git a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
index c1fe245..c2434db 100644
--- a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
@@ -36,6 +36,7 @@
#define BCM43236_CHIP_ID 43236
#define BCM43238_CHIP_ID 43238
#define BCM43241_CHIP_ID 0x4324
+#define BCM4319_CHIP_ID 0x4319
#define BCM4329_CHIP_ID 0x4329
#define BCM4330_CHIP_ID 0x4330
#define BCM4331_CHIP_ID 0x4331
^ permalink raw reply related
* Re: rtl8192cu fail to connect with a AP
From: Larry Finger @ 2013-06-17 15:21 UTC (permalink / raw)
To: Tobias Kluge; +Cc: linux-wireless
In-Reply-To: <loom.20130617T154136-827@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On 06/17/2013 09:06 AM, Tobias Kluge wrote:
> Hi,
>
> I've recently bought a TP-Link TL-WN8200ND USB WiFi dongle, it uses the
> Realtek 8192cu chipset.
> After several attempts with different kernels (starting with 3.2.6) and
> compat-wireless drivers, I'm still running into the same problem. The device
> can successful scan for networks in reach, but cannot connect to any of
> them, regardless the encryption (tried every mode, including no encryption
> at all).
>
> At the moment I'm using the kernel release 3.10.0-rc6 and the device is
> still not recognized by the "rtl8192cu" driver module without manually
> setting the device ID into the SySFS
>
> "echo "2357 0100" > /sys/bus/usb/drivers/rtl8192cu/new_id"
No one had reported that this device used rtl8192cu, thus it is not in the
device tables, nor is it in the USB database as shown by the bare entry in your
lsusb output. Attached is a patch that will add your device to the tables. That
will be submitted to the maintainer relatively soon.
There were a number of changes to that driver that just appeared in 3.10-rc6.
These fixed a number of bug reports on the Red Hat bugzilla as shown in the
commit message for commit 5b8df24. I had built 3.10-rc6 from the mainline git
tree; however, I had not booted it till now. With it, my Edimax EW-7811Un
adapter with an RTL8188CUS chip could connect to WEP, WPA1 and WPA2 APs;
however, when I dug out my Alfa AWUS036NHR with an RTL8188RU chip, it could not
connect to any of my APs. I now need to check the results for the
wireless-testing git tree, which I normally use, to see if there is a difference
in the two trees.
Larry
[-- Attachment #2: rtl8192cu_add_deviceid_2357_0100 --]
[-- Type: text/plain, Size: 711 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -359,6 +359,7 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/
{RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/
+ {RTL_USB_DEVICE(0x2357, 0x0100, rtl92cu_hal_cfg)}, /*TP-Link WN8200ND*/
{RTL_USB_DEVICE(0x7392, 0x7822, rtl92cu_hal_cfg)}, /*Edimax -Edimax*/
{}
};
^ permalink raw reply
* Re: Missing firmware iwlwifi-2030-5.ucode
From: antonio @ 2013-06-17 14:57 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1345531562.4676.11.camel@jlt3.sipsolutions.net>
> > Your suggestion would handle the case where hardware that is only
supposed to be
> > available internally has somehow been leaked to the public. In the case
of the
> > 2030, it is a device that was intended to be available to the public,
and I
> > suspect that Windows and OS X drivers were available with built-in
firmware.
>
> Yes, that was likely the case. Except there are no OS X drivers at
> all
>
> > My feeling is that the reviewers will need to watch the situation. I
certainly
> > plan to monitor every Intel patch for a firmware change, and I will NACK
every
> > instance for which that firmware file is not already in linux-firmware.
John
> > might not honor my NACK; however, I will be on record.
>
> You're free to, of course, but I don't think we've ever (intentionally)
> changed the driver from working with a released firmware image to
> working only with unreleased firmware images. In fact, this is the
> reason we have firmware versions and try to load multiple versions, so
> we can begin working on a newer version internally while the driver
> continues to work with older, released versions.
>
> The situation with 2030 devices was different: we worked on a driver and
> submitted code into the kernel that given the right firmware could work
> with the device. I don't remember, but we may even have thought at the
> time that we'd release the -5 firmware version, but then had to use -6.
> There was definitely a chance that we could release the right firmware
> version and thereby make the previously submitted code work. As it turns
> out, we couldn't or didn't (and that we've released a -6 one I can't
> just release another one), but that wasn't necessarily something anyone
> would have known at the time we submitted the code.
>
> So I guess we could simply not submit the code before the firmware was
> released, but it would really just have the same effect on users that
> the released code has now -- their old kernel doesn't work with the
> device. Today, it's because we ended up releasing the wrong firmware, if
> we didn't release the code before the firmware it would be because they
> didn't have any driver code at all. I don't see how that would help.
>
> > At least Ben Hutchings
> > caught the attempt to delete the older version of the firmware for the
6205. His
> > diligence saved some users of older kernels from having to scramble to
find
> > firmware not in the firmware repo.
>
> Yes, that was indeed a mistake. I guess I got over-excited with the new
> firmware being available Different situation though.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
HI,
I am sorry, I cannot really understand why the iwlwifi -2030-5.ucode
firmware has been removed, just leave it there along with the -6 version for
people that might need it ! I respect your work, but I am loosing my mental
health in order to find it and I really need it, I must use MeeGo, a system
that I am not familiar with. The driver is asking *strictly* for -5 version
and I don't want to fiddle about kernel compilation every damn time for tiny
bits of proprietary code, I just want to use as it is (I don't even know if
there is a possibility to recompile the kernel in MeeGo, and I am not a
developer)
It should have been in the topic of the post really a link to the -5 version
if you are the mantainers.
Regards.
Antonio
^ permalink raw reply
* rtl8192cu fail to connect with a AP
From: Tobias Kluge @ 2013-06-17 14:06 UTC (permalink / raw)
To: linux-wireless
Hi,
I've recently bought a TP-Link TL-WN8200ND USB WiFi dongle, it uses the
Realtek 8192cu chipset.
After several attempts with different kernels (starting with 3.2.6) and
compat-wireless drivers, I'm still running into the same problem. The device
can successful scan for networks in reach, but cannot connect to any of
them, regardless the encryption (tried every mode, including no encryption
at all).
At the moment I'm using the kernel release 3.10.0-rc6 and the device is
still not recognized by the "rtl8192cu" driver module without manually
setting the device ID into the SySFS
"echo "2357 0100" > /sys/bus/usb/drivers/rtl8192cu/new_id"
here is the output of "lsusb"
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 2357:0100
Bus 002 Device 003: ID 0c0b:b159 Dura Micro, Inc. (Acomdata)
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 0d62:001c Darfon Electronics Corp. Benq X120 Internet
Keyboard Pro
Bus 001 Device 004: ID 09da:9090 A4 Tech Co., Ltd XL-750BK Laser Mouse
Bus 001 Device 003: ID 148f:3072 Ralink Technology, Corp. RT3072 Wireless
Adapter
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
dmesg output when the dongle becomes active (debug level 3 for the rtl8192cu
module):
[ 1651.800376] usb 2-1.6: USB disconnect, device number 5
[ 1651.800471] ehci-pci 0000:00:1d.0: dma_pool_free ehci_qh,
dfa0d4e0/fffff4e0 (bad dma)
[ 1653.791055] usb 2-1.6: new high-speed USB device number 6 using ehci-pci
[ 1653.866948] ehci-pci 0000:00:1d.0: dma_pool_free ehci_qh,
dfa0d540/fffff540 (bad dma)
[ 1690.240437] usbcore: registered new interface driver rtl8192cu
[ 1710.493651] rtl8192cu: Chip version 0x11
[ 1710.570428] rtl8192cu: MAC address: a0:f3:c1:29:e3:95
[ 1710.570436] rtl8192cu: Board Type 0
[ 1710.570672] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 1710.570677] cfg80211: Updating information on frequency 2412 MHz with
regulatory rule:
[ 1710.570679] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570681] cfg80211: Updating information on frequency 2417 MHz with
regulatory rule:
[ 1710.570684] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570685] cfg80211: Updating information on frequency 2422 MHz with
regulatory rule:
[ 1710.570687] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570689] cfg80211: Updating information on frequency 2427 MHz with
regulatory rule:
[ 1710.570691] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570693] cfg80211: Updating information on frequency 2432 MHz with
regulatory rule:
[ 1710.570695] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570697] cfg80211: Updating information on frequency 2437 MHz with
regulatory rule:
[ 1710.570699] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570700] cfg80211: Updating information on frequency 2442 MHz with
regulatory rule:
[ 1710.570702] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570704] cfg80211: Updating information on frequency 2447 MHz with
regulatory rule:
[ 1710.570706] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570708] cfg80211: Updating information on frequency 2452 MHz with
regulatory rule:
[ 1710.570710] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570712] cfg80211: Updating information on frequency 2457 MHz with
regulatory rule:
[ 1710.570714] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570715] cfg80211: Updating information on frequency 2462 MHz with
regulatory rule:
[ 1710.570717] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi,
2000 mBm)
[ 1710.570719] cfg80211: Disabling freq 2467 MHz as custom regd has no rule
that fits it
[ 1710.570721] cfg80211: Disabling freq 2472 MHz as custom regd has no rule
that fits it
[ 1710.570722] cfg80211: Disabling freq 2484 MHz as custom regd has no rule
that fits it
[ 1710.570752] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[ 1710.570866] cfg80211: Ignoring regulatory request Set by core since the
driver uses its own custom regulatory domain
[ 1710.570975] ieee80211 phy3: Selected rate control algorithm 'rtl_rc'
[ 1710.571427] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1710.571430] rtlwifi: wireless switch is on
[ 1710.571675] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
dmesg output when connecting to my unsecured AP
[ 1710.571430] rtlwifi: wireless switch is on
[ 1710.571675] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1715.459587] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1720.455801] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1725.468154] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1730.464371] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1735.476568] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1740.472816] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1745.485169] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1750.481384] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1755.493613] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1760.489829] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1765.502183] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1770.498399] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1775.510626] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1780.506967] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1785.519180] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1790.515411] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1795.527640] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1800.523981] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1805.536210] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1810.532425] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1815.544779] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1820.540994] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1825.553224] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1830.549439] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=09
[ 1833.830697] rtl8192cu:_rtl92cu_init_power_on():<0-0> Autoload Done!
[ 1833.832420] rtl8192cu: MAC auto ON okay!
[ 1833.865110] rtl8192cu: Tx queue select: 0x05
[ 1833.865120] rtl8192cu:rtl92c_set_network_type():<0-0> Set Network type to
NO LINK!
[ 1833.865832] rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver
sleep or unload
[ 1833.865853] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware
Version(63), Signature(0x88c1),Size(32)
[ 1834.218899] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1834.218927] rtl8192cu:rtl92cu_set_hw_reg():<0-0> Set
HW_VAR_RETRY_LIMIT(0x00000004)
[ 1834.230312] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 1834.336021] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1834.345018] rtl8192cu:_rtl92cu_init_power_on():<0-0> Autoload Done!
[ 1834.346728] rtl8192cu: MAC auto ON okay!
[ 1834.379398] rtl8192cu: Tx queue select: 0x05
[ 1834.379407] rtl8192cu:rtl92c_set_network_type():<0-0> Set Network type to
NO LINK!
[ 1834.380137] rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver
sleep or unload
[ 1834.380157] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware
Version(63), Signature(0x88c1),Size(32)
[ 1834.737048] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1834.737083] rtl8192cu:rtl92cu_set_hw_reg():<0-0> Set
HW_VAR_RETRY_LIMIT(0x00000004)
[ 1834.748491] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 1835.561793] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
[ 1840.558008] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
[ 1845.570238] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
[ 1849.503068] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1849.512063] rtl8192cu:_rtl92cu_init_power_on():<0-0> Autoload Done!
[ 1849.513775] rtl8192cu: MAC auto ON okay!
[ 1849.546445] rtl8192cu: Tx queue select: 0x05
[ 1849.546456] rtl8192cu:rtl92c_set_network_type():<0-0> Set Network type to
NO LINK!
[ 1849.547184] rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver
sleep or unload
[ 1849.547205] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware
Version(63), Signature(0x88c1),Size(32)
[ 1849.900128] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1849.900153] rtl8192cu:rtl92cu_set_hw_reg():<0-0> Set
HW_VAR_RETRY_LIMIT(0x00000004)
[ 1849.911536] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 1850.006348] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1850.152581] rtl8192cu:_rtl92cu_init_power_on():<0-0> Autoload Done!
[ 1850.154316] rtl8192cu: MAC auto ON okay!
[ 1850.186984] rtl8192cu: Tx queue select: 0x05
[ 1850.186994] rtl8192cu:rtl92c_set_network_type():<0-0> Set Network type to
NO LINK!
[ 1850.187727] rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver
sleep or unload
[ 1850.187747] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware
Version(63), Signature(0x88c1),Size(32)
[ 1850.540796] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1850.540822] rtl8192cu:rtl92cu_set_hw_reg():<0-0> Set
HW_VAR_RETRY_LIMIT(0x00000004)
[ 1850.552204] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 1850.566578] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
[ 1852.568943] wlan1: authenticate with 92:5f:2e:57:10:3b
[ 1852.568949] wlan1: Allocated STA 92:5f:2e:57:10:3b
[ 1852.580265] rtlwifi:rtl_op_bss_info_changed():<0-0> 92:5f:2e:57:10:3b
[ 1852.580747] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1852.580795] wlan1: Inserted STA 92:5f:2e:57:10:3b
[ 1852.580798] wlan1: direct probe to 92:5f:2e:57:10:3b (try 1/3)
[ 1852.583216] wlan1: deauthenticating from 92:5f:2e:57:10:3b by local
choice (reason=3)
[ 1852.583306] wlan1: Removed STA 92:5f:2e:57:10:3b
[ 1852.583377] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:00:00:00:00:00
[ 1852.583875] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1852.595156] wlan1: authenticate with 92:5f:2e:57:10:3b
[ 1852.595161] wlan1: Allocated STA 92:5f:2e:57:10:3b
[ 1852.606280] rtlwifi:rtl_op_bss_info_changed():<0-0> 92:5f:2e:57:10:3b
[ 1852.606769] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1852.606810] wlan1: Inserted STA 92:5f:2e:57:10:3b
[ 1852.606813] wlan1: direct probe to 92:5f:2e:57:10:3b (try 1/3)
[ 1852.608051] wlan1: Destroyed STA 92:5f:2e:57:10:3b
[ 1852.609213] wlan1: deauthenticating from 92:5f:2e:57:10:3b by local
choice (reason=3)
[ 1852.609276] wlan1: Removed STA 92:5f:2e:57:10:3b
[ 1852.609325] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:00:00:00:00:00
[ 1852.609896] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1852.621171] wlan1: authenticate with 92:5f:2e:57:10:3b
[ 1852.621174] wlan1: Allocated STA 92:5f:2e:57:10:3b
[ 1852.632302] rtlwifi:rtl_op_bss_info_changed():<0-0> 92:5f:2e:57:10:3b
[ 1852.632790] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1852.632824] wlan1: Inserted STA 92:5f:2e:57:10:3b
[ 1852.632827] wlan1: direct probe to 92:5f:2e:57:10:3b (try 1/3)
[ 1852.632875] wlan1: Destroyed STA 92:5f:2e:57:10:3b
[ 1852.836210] wlan1: direct probe to 92:5f:2e:57:10:3b (try 2/3)
[ 1853.040402] wlan1: direct probe to 92:5f:2e:57:10:3b (try 3/3)
[ 1853.244553] wlan1: authentication with 92:5f:2e:57:10:3b timed out
[ 1853.272625] wlan1: Removed STA 92:5f:2e:57:10:3b
[ 1853.272691] rtlwifi:rtl_op_bss_info_changed():<0-0> 00:00:00:00:00:00
[ 1853.273249] rtl8192cu:rtl92cu_set_hw_reg():<0-0> ### Set RCR(0xf0002a0e) ###
[ 1853.304623] wlan1: Destroyed STA 92:5f:2e:57:10:3b
[ 1855.578807] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
[ 1860.575022] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
My other USB WLAN dongle iwth a Ralink chipset works flawless with my PC and
AP, so it seems not to be a PEBKAC problem on my side :)
Please hit me if you need more information, Thanks in advance
Tobias
^ permalink raw reply
* Re: [PATCH 1/2] net: wireless: wl1251: Use module_spi_driver macro
From: Luciano Coelho @ 2013-06-17 9:24 UTC (permalink / raw)
To: Sachin Kamat; +Cc: linux-wireless, netdev, davem, linville
In-Reply-To: <1369822703-27769-1-git-send-email-sachin.kamat@linaro.org>
On Wed, 2013-05-29 at 15:48 +0530, Sachin Kamat wrote:
> module_spi_driver() eliminates some boiler plate and makes code
> simpler.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
Applied both patches in this series.
Thanks!
--
Luca.
^ 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