* 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
* Re: [PATCH] net/wireless/ti/wlcore/spi: Use module_spi_driver to register driver
From: Luciano Coelho @ 2013-06-17 9:23 UTC (permalink / raw)
To: Peter Huewe
Cc: John W. Linville, Felipe Balbi, Ido Yariv, Arik Nemtsov,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1369079560-6101-1-git-send-email-peterhuewe@gmx.de>
On Mon, 2013-05-20 at 21:52 +0200, Peter Huewe wrote:
> Removing some boilerplate by using module_spi_driver instead of calling
> register and unregister in the otherwise empty init/exit functions
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
> ---
Applied. Thanks, Peter.
--
Luca.
^ permalink raw reply
* Re: [PATCH 1/4] wlcore: set default_wep_key when configured
From: Luciano Coelho @ 2013-06-17 9:14 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1368351331-6914-1-git-send-email-eliad@wizery.com>
On Sun, 2013-05-12 at 12:35 +0300, Eliad Peller wrote:
> From: Yoni Divinsky <yoni.divinsky@ti.com>
>
> When associating to an AP with WEP set the
> default key upon association by implementing
> the set_deafult_key_idx op.
>
> Fixes auto-arp sent with wrong key_idx bug.
>
> Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com>
> Signed-off-by: Eyal Shapira <eyal@wizery.com>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Applied this entire series. Thanks!
--
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: increase minimum singlerole firmware version required
From: Luciano Coelho @ 2013-06-17 9:06 UTC (permalink / raw)
To: linux-wireless; +Cc: tony
In-Reply-To: <1368172024-14746-1-git-send-email-coelho@ti.com>
On Fri, 2013-05-10 at 10:47 +0300, Luciano Coelho wrote:
> The minimum firmware version required for singlerole after recent
> driver changes is 6/7.3.10.0.133.
>
> Reported-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
This patch has been pushed up and applied in v3.11-rc6.
--
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: fix minimum required firmware version for wl127x multirole
From: Luciano Coelho @ 2013-06-17 9:05 UTC (permalink / raw)
To: linux-wireless; +Cc: levipearson, hashcode0f
In-Reply-To: <1368171177-13682-1-git-send-email-coelho@ti.com>
On Fri, 2013-05-10 at 10:32 +0300, Luciano Coelho wrote:
> There was a typo in commit 8675f9 (wlcore/wl12xx/wl18xx: verify
> multi-role and single-role fw versions), which was causing the
> multirole firmware for wl127x (WiLink6) to be rejected. The actual
> minimum version needed for wl127x multirole is 6.5.7.0.42.
>
> Reported-by: Levi Pearson <levipearson@gmail.com>
> Reported-by: Michael Scott <hashcode0f@gmail.com>
> Cc: stable@kernel.org # 3.9+
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
This patch has been pushed up and applied in v3.11-rc6.
--
Luca.
^ permalink raw reply
* Re: [PATCH v2] wl18xx: use locally administered MAC address if not available from fuse
From: Luciano Coelho @ 2013-06-17 9:04 UTC (permalink / raw)
To: linux-wireless; +Cc: arik, eliad
In-Reply-To: <1368006896-24468-1-git-send-email-coelho@ti.com>
On Wed, 2013-05-08 at 12:54 +0300, Luciano Coelho wrote:
> In some R&D chips, the device may be left untrimmed and with the MAC
> address missing from fuse ROM. In order to support those devices,
> apply a random locally administered MAC address instead.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
>
> In v2:
>
> * use eth_random_addr() to generate the locally assigned address,
> instead of hardcoding it. (thanks Johannes)
Applied.
--
Luca.
^ permalink raw reply
* [PATCH v2] ath9k: Fix ANI for AP mode
From: Sujith Manoharan @ 2013-06-17 8:54 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Felix Fietkau, Rajkumar Manoharan
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The commit "ath9k: Fix ANI monitoring" reverted an earlier
commit that adjusted ANI to improve performance. But, this causes
adverse effects in AP mode (as reported by Felix based on an OpenWrt
report). Use the older INI/period configuration for now until more
testing is done.
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
v2 - Earlier patch added a macro twice.
drivers/net/wireless/ath/ath9k/ani.c | 29 ++++++++++++-----------------
drivers/net/wireless/ath/ath9k/ani.h | 6 +++++-
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index a68beb1..4994bea 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -186,6 +186,14 @@ static void ath9k_hw_set_ofdm_nil(struct ath_hw *ah, u8 immunityLevel,
ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
entry_ofdm->ofdm_weak_signal_on);
}
+
+ if (aniState->ofdmNoiseImmunityLevel >= ATH9K_ANI_OFDM_DEF_LEVEL) {
+ ah->config.ofdm_trig_high = ATH9K_ANI_OFDM_TRIG_HIGH;
+ ah->config.ofdm_trig_low = ATH9K_ANI_OFDM_TRIG_LOW_ABOVE_INI;
+ } else {
+ ah->config.ofdm_trig_high = ATH9K_ANI_OFDM_TRIG_HIGH_BELOW_INI;
+ ah->config.ofdm_trig_low = ATH9K_ANI_OFDM_TRIG_LOW;
+ }
}
static void ath9k_hw_ani_ofdm_err_trigger(struct ath_hw *ah)
@@ -420,25 +428,12 @@ void ath9k_hw_ani_monitor(struct ath_hw *ah, struct ath9k_channel *chan)
ofdmPhyErrRate, aniState->cckNoiseImmunityLevel,
cckPhyErrRate, aniState->ofdmsTurn);
- if (aniState->listenTime > 5 * ah->aniperiod) {
- /*
- * Check if we need to lower immunity if
- * 5 ani_periods have passed.
- */
- if (ofdmPhyErrRate <= ah->config.ofdm_trig_low &&
- cckPhyErrRate <= ah->config.cck_trig_low) {
+ if (aniState->listenTime > ah->aniperiod) {
+ if (cckPhyErrRate < ah->config.cck_trig_low &&
+ ofdmPhyErrRate < ah->config.ofdm_trig_low) {
ath9k_hw_ani_lower_immunity(ah);
aniState->ofdmsTurn = !aniState->ofdmsTurn;
- }
- ath9k_ani_restart(ah);
- } else if (aniState->listenTime > ah->aniperiod) {
- /*
- * Check if immunity has to be raised,
- * (either OFDM or CCK).
- */
- if (ofdmPhyErrRate > ah->config.ofdm_trig_high &&
- (cckPhyErrRate <= ah->config.cck_trig_high ||
- aniState->ofdmsTurn)) {
+ } else if (ofdmPhyErrRate > ah->config.ofdm_trig_high) {
ath9k_hw_ani_ofdm_err_trigger(ah);
aniState->ofdmsTurn = false;
} else if (cckPhyErrRate > ah->config.cck_trig_high) {
diff --git a/drivers/net/wireless/ath/ath9k/ani.h b/drivers/net/wireless/ath/ath9k/ani.h
index 77a06fd..b54a3fb 100644
--- a/drivers/net/wireless/ath/ath9k/ani.h
+++ b/drivers/net/wireless/ath/ath9k/ani.h
@@ -20,8 +20,12 @@
#define BEACON_RSSI(ahp) (ahp->stats.avgbrssi)
/* units are errors per second */
-#define ATH9K_ANI_OFDM_TRIG_HIGH 1000
+#define ATH9K_ANI_OFDM_TRIG_HIGH 3500
+#define ATH9K_ANI_OFDM_TRIG_HIGH_BELOW_INI 1000
+
#define ATH9K_ANI_OFDM_TRIG_LOW 400
+#define ATH9K_ANI_OFDM_TRIG_LOW_ABOVE_INI 900
+
#define ATH9K_ANI_CCK_TRIG_HIGH 600
#define ATH9K_ANI_CCK_TRIG_LOW 300
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ath9k: Fix ANI for AP mode
From: Sujith Manoharan @ 2013-06-17 8:49 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Felix Fietkau, Rajkumar Manoharan
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The commit "ath9k: Fix ANI monitoring" reverted an earlier
commit that adjusted ANI to improve performance. But, this causes
adverse effects in AP mode (as reported by Felix based on an OpenWrt
report). Use the older INI/period configuration for now until more
testing is done.
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ani.c | 29 ++++++++++++-----------------
drivers/net/wireless/ath/ath9k/ani.h | 7 ++++++-
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index a68beb1..4994bea 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -186,6 +186,14 @@ static void ath9k_hw_set_ofdm_nil(struct ath_hw *ah, u8 immunityLevel,
ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
entry_ofdm->ofdm_weak_signal_on);
}
+
+ if (aniState->ofdmNoiseImmunityLevel >= ATH9K_ANI_OFDM_DEF_LEVEL) {
+ ah->config.ofdm_trig_high = ATH9K_ANI_OFDM_TRIG_HIGH;
+ ah->config.ofdm_trig_low = ATH9K_ANI_OFDM_TRIG_LOW_ABOVE_INI;
+ } else {
+ ah->config.ofdm_trig_high = ATH9K_ANI_OFDM_TRIG_HIGH_BELOW_INI;
+ ah->config.ofdm_trig_low = ATH9K_ANI_OFDM_TRIG_LOW;
+ }
}
static void ath9k_hw_ani_ofdm_err_trigger(struct ath_hw *ah)
@@ -420,25 +428,12 @@ void ath9k_hw_ani_monitor(struct ath_hw *ah, struct ath9k_channel *chan)
ofdmPhyErrRate, aniState->cckNoiseImmunityLevel,
cckPhyErrRate, aniState->ofdmsTurn);
- if (aniState->listenTime > 5 * ah->aniperiod) {
- /*
- * Check if we need to lower immunity if
- * 5 ani_periods have passed.
- */
- if (ofdmPhyErrRate <= ah->config.ofdm_trig_low &&
- cckPhyErrRate <= ah->config.cck_trig_low) {
+ if (aniState->listenTime > ah->aniperiod) {
+ if (cckPhyErrRate < ah->config.cck_trig_low &&
+ ofdmPhyErrRate < ah->config.ofdm_trig_low) {
ath9k_hw_ani_lower_immunity(ah);
aniState->ofdmsTurn = !aniState->ofdmsTurn;
- }
- ath9k_ani_restart(ah);
- } else if (aniState->listenTime > ah->aniperiod) {
- /*
- * Check if immunity has to be raised,
- * (either OFDM or CCK).
- */
- if (ofdmPhyErrRate > ah->config.ofdm_trig_high &&
- (cckPhyErrRate <= ah->config.cck_trig_high ||
- aniState->ofdmsTurn)) {
+ } else if (ofdmPhyErrRate > ah->config.ofdm_trig_high) {
ath9k_hw_ani_ofdm_err_trigger(ah);
aniState->ofdmsTurn = false;
} else if (cckPhyErrRate > ah->config.cck_trig_high) {
diff --git a/drivers/net/wireless/ath/ath9k/ani.h b/drivers/net/wireless/ath/ath9k/ani.h
index 77a06fd..a709490 100644
--- a/drivers/net/wireless/ath/ath9k/ani.h
+++ b/drivers/net/wireless/ath/ath9k/ani.h
@@ -20,8 +20,13 @@
#define BEACON_RSSI(ahp) (ahp->stats.avgbrssi)
/* units are errors per second */
-#define ATH9K_ANI_OFDM_TRIG_HIGH 1000
+#define ATH9K_ANI_OFDM_TRIG_HIGH 3500
#define ATH9K_ANI_OFDM_TRIG_LOW 400
+#define ATH9K_ANI_OFDM_TRIG_HIGH_BELOW_INI 1000
+
+#define ATH9K_ANI_OFDM_TRIG_LOW 400
+#define ATH9K_ANI_OFDM_TRIG_LOW_ABOVE_INI 900
+
#define ATH9K_ANI_CCK_TRIG_HIGH 600
#define ATH9K_ANI_CCK_TRIG_LOW 300
--
1.8.3.1
^ permalink raw reply related
* Re: ath3k hackery; doing it in userland
From: Julian Calaby @ 2013-06-17 6:35 UTC (permalink / raw)
To: Adrian Chadd; +Cc: linux-wireless
In-Reply-To: <CAJ-VmonxpTv0=5M6faG=UzswdH=c4+L1HYMXatnmssx1Rz7vLQ@mail.gmail.com>
Hi Adrian,
On 17 June 2013 16:27, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi,
>
> As part of general freebsd wireless hackery I've found a need to port
> ath3k to freebsd.
>
> Whilst doing it, I asked - why isn't this in userland? All it's doing
> is pushing firmware in. It doesn't have to be in the kernel!
>
> So, without further ado:
>
> https://github.com/erikarn/ath3k
>
> I'm using the libusb 1.0 API so it should be portable between OSes.
>
> There's some interesting issues that have crept up - specifically, the
> AR3012 resets after loading in the syscfg and thus doesn't take the
> "set normal mode" and "change VID".
>
> So, why's this in the kernel?
A further question: why isn't this in usb-modeswitch or some similar
"make my dumb USB device work" system?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* ath3k hackery; doing it in userland
From: Adrian Chadd @ 2013-06-17 6:27 UTC (permalink / raw)
To: linux-wireless
Hi,
As part of general freebsd wireless hackery I've found a need to port
ath3k to freebsd.
Whilst doing it, I asked - why isn't this in userland? All it's doing
is pushing firmware in. It doesn't have to be in the kernel!
So, without further ado:
https://github.com/erikarn/ath3k
I'm using the libusb 1.0 API so it should be portable between OSes.
There's some interesting issues that have crept up - specifically, the
AR3012 resets after loading in the syscfg and thus doesn't take the
"set normal mode" and "change VID".
So, why's this in the kernel?
Adrian
^ permalink raw reply
* bug-report: Ralink corp. Device [1814:539a] - Kernel 3.8 +
From: Lars Zastrow @ 2013-06-17 3:18 UTC (permalink / raw)
To: backports, linux-wireless
Dear Team,
I'am using the following wireless-network-device:
Network controller [0280]: Ralink corp. Device [1814:539a]
Subsystem: Hewlett-Packard Company Device [103c:1839]
Kernel driver in use: rt2800pci
I had problems with it since I bought my laptop... The driver was
unstable with the kernel I used back in autumn 2012. Howeverer, one
kernel-update fixed it. Must be something about 3.4x?
It was defenetly working with the Kernels from 3.5 till 3.7 on multible
distros. 3.8 was bringing back the old Problems:
- extremly low signal
- hard to establish a connection to any acess-point.
The last "problematic" kernel I have testet was 3.9.5-1 on Arch-Linux.
Compiling the compat-drivers manually did not bring any fix.
I am currently using 3.7.4-1 wich is working.
Best regards
Lars Zastrow
^ permalink raw reply
* [PATCH] ath9k: Fix LNA gpio for AR9485
From: Sujith Manoharan @ 2013-06-17 1:31 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The commit "ath9k: Add custom parameters for CUS198" didn't
pass the correct gpio value to ath9k_hw_cfg_output(). Fix it.
Reported-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 9a00bc0..eae23b9 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3576,7 +3576,7 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
else
gpio = AR9300_EXT_LNA_CTL_GPIO_AR9485;
- ath9k_hw_cfg_output(ah, AR9300_EXT_LNA_CTL_GPIO_AR9485,
+ ath9k_hw_cfg_output(ah, gpio,
AR_GPIO_OUTPUT_MUX_AS_PCIE_ATTENTION_LED);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] ath9k: Add custom parameters for CUS198
From: Sujith Manoharan @ 2013-06-17 1:21 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John Linville, linux-wireless, jkp, gfmichaud
In-Reply-To: <51BDFED6.1060509@openwrt.org>
Felix Fietkau wrote:
> Shouldn't the ath9k_hw_cfg_output line change as well, otherwise you
> simply add an unused-but-set variable here.
Hm, I thought I sent the updated patch in v2.
Thanks for catching this !
Sujith
^ permalink raw reply
* Re: [PATCH v2] ath9k: Add custom parameters for CUS198
From: Felix Fietkau @ 2013-06-16 18:07 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: John Linville, linux-wireless, jkp, gfmichaud
In-Reply-To: <1371144086-10150-1-git-send-email-sujith@msujith.org>
On 2013-06-13 7:21 PM, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> CUS198 is a card based on AR9485. There are differences
> between the base reference design HB125 and CUS198.
> Identify such cards based on the PCI subsystem IDs and
> set HW parameters appropriately.
>
> Addresses this bug - https://bugzilla.kernel.org/show_bug.cgi?id=49201
>
> Cc: jkp@iki.fi
> Cc: gfmichaud@gmail.com
> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 18 +++++++++++++---
> drivers/net/wireless/ath/ath9k/ath9k.h | 3 +++
> drivers/net/wireless/ath/ath9k/hw.h | 4 ++++
> drivers/net/wireless/ath/ath9k/init.c | 21 +++++++++++++++++++
> drivers/net/wireless/ath/ath9k/pci.c | 29 ++++++++++++++++++++++++++
> 5 files changed, 72 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
> index 25b8bbb..9a00bc0 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
> @@ -3563,16 +3563,22 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
> {
> struct ath9k_hw_capabilities *pCap = &ah->caps;
> int chain;
> - u32 regval, value;
> + u32 regval, value, gpio;
> static const u32 switch_chain_reg[AR9300_MAX_CHAINS] = {
> AR_PHY_SWITCH_CHAIN_0,
> AR_PHY_SWITCH_CHAIN_1,
> AR_PHY_SWITCH_CHAIN_2,
> };
>
> - if (AR_SREV_9485(ah) && (ar9003_hw_get_rx_gain_idx(ah) == 0))
> + if (AR_SREV_9485(ah) && (ar9003_hw_get_rx_gain_idx(ah) == 0)) {
> + if (ah->config.xlna_gpio)
> + gpio = ah->config.xlna_gpio;
> + else
> + gpio = AR9300_EXT_LNA_CTL_GPIO_AR9485;
> +
> ath9k_hw_cfg_output(ah, AR9300_EXT_LNA_CTL_GPIO_AR9485,
> AR_GPIO_OUTPUT_MUX_AS_PCIE_ATTENTION_LED);
Shouldn't the ath9k_hw_cfg_output line change as well, otherwise you
simply add an unused-but-set variable here.
- Felix
^ 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