* RE: [RFC v2] mac80211: Use libnl-configurable values for retry counts
From: Jean-Pierre Tosoni @ 2013-07-02 13:28 UTC (permalink / raw)
To: 'Felix Fietkau'; +Cc: linux-wireless
In-Reply-To: <51CF3EC9.3000707@openwrt.org>
Hi Felix,
> -----Message d'origine-----
> De : Felix Fietkau [mailto:nbd@openwrt.org]
> > ---
> > What I am seeking with this patch:
> > I believe the configuration of the retries will help making recovery
> > much faster when an AP (in infrastructure mode) or a peer (in mesh
> > mode) suddenly disappears.
> I'm all for reducing retries, but I think the way you're applying the
> limit is problematic.
> If minstrel decides to use many retries for a high rate and you're
> simply cutting off all retries that exceed the configured limit, you're
> potentially inviting quite a bit of unnecessary packet loss.
> I'm planning to remove the use of retry rate slot 4 (fallback to lowest
> rate) from minstrel, since max_prob_rate should already provide quite
> decent reliability.
Well, on one hand, people who want to reduce retries are more concerned with
low latency and jitter than with reliable delivery of data.
On another hand the code should work for any rate control plugin, not just
minstrel.
Finally this code is executed for each frame, and I don’t want to bloat it
more than necessary...
I am thinking of trimming only the largest retry count in the table, but not
below 2 (one try and one retry). I'll test this today.
Do you feel this is a good path ?
Or should I just wait for the slot 4 removal ?
I could also split the trimming between 2 rates, the largest count and the
next-to-largest. Or I could use a minimum of 1 instead of 2.
>
> - Felix
Jean-Pierre
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Neil Horman @ 2013-07-02 12:37 UTC (permalink / raw)
To: Arend van Spriel
Cc: Larry Finger, linville, linux-wireless, netdev, Stable,
Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
brcm80211-dev-list
In-Reply-To: <51D29391.4080000@broadcom.com>
On Tue, Jul 02, 2013 at 10:47:13AM +0200, Arend van Spriel wrote:
> On 07/01/2013 11:08 PM, Larry Finger wrote:
> >The driver fails to check the results of DMA mapping in twp places, which results
> >in the following warning:
> >
> >[ 28.078515] ------------[ cut here ]------------
> >[ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> >[ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> > single]
> >[ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> >11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> > cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> >6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> >[ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> >[ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> >[ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> >[ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> >[ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> >[ 28.078622] Call Trace:
> >[ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> >[ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> >[ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> >[ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> >[ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> >[ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> >[ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> >[ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> >[ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> >[ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> >[ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> >--snip--
> >[ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> >[ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> >[ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> >[ 28.078984] Mapped at:
> >[ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> >[ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> >[ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> >[ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> >[ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
> >
> >As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> >comment at the start of the routine to add that information, I also polished
> >the wording.
>
> Thanks, Larry
>
> I think there a bugzilla issue for this that you might want to reference:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=60261
>
Thanks Larry, you beat me too it, feel free to reassign the bz to yourself. :)
> >Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> >Cc: Stable <stable@vger.kernel.org>
> >Cc: Brett Rudley <brudley@broadcom.com>
> >Cc: Arend van Spriel <arend@broadcom.com>
> >Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> >Cc: Hante Meuleman <meuleman@broadcom.com>
> >Cc: brcm80211-dev-list@broadcom.com
> >---
> >
> > drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> >index 1860c57..6260571 100644
> >--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> >+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> >@@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
> >
> > /*
> > * post receive buffers
> >- * return false is refill failed completely and ring is empty this will stall
> >- * the rx dma and user might want to call rxfill again asap. This unlikely
> >- * happens on memory-rich NIC, but often on memory-constrained dongle
> >+ * return false is refill failed completely or dma mapping failed. The ring
>
> Missed some polishing opportunity: return false is refill... ->
> return false if refill...
>
> >+ * is empty, which will stall the rx dma and user might want to call rxfill
> >+ * again asap. This is unlikely to happen on a memory-rich NIC, but often on
> >+ * memory-constrained dongle
> > */
> > bool dma_rxfill(struct dma_pub *pub)
> > {
> >@@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
> >
> > pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> > DMA_FROM_DEVICE);
> >+ if (dma_mapping_error(di->dmadev,pa))
> >+ return false;
Hmm, wouldn't it be better to set ring_empty to false and break out of the for
loop here, in the event that you partially refilled the ring? Otherwise, a
single dma mapping failure would let some useable descriptors go unused.
Neil
^ permalink raw reply
* Re: Fw: Intel 6330 N
From: Sedat Dilek @ 2013-07-02 12:16 UTC (permalink / raw)
To: Matt Allen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1372767087.74391.YahooMailNeo@web161902.mail.bf1.yahoo.com>
On Tue, Jul 2, 2013 at 2:11 PM, Matt Allen <allencon19@yahoo.com> wrote:
>
>
>
>
> To Whom it may concern,
>
> I am having trouble getting my Intel 6330 wireless card to work on N. How long am I going to have to wait, until I am able to use N on my Intel 6330 wireless card? I have seen a lot of ways to disable it. I have found another Intel wireless card below this one that has N speed in linux, but I do not want to spend about money on a card that is not Linux compatable. Is there a current driver that I could download that works on Debian Jessie? Thank you for your time and assistance.
>
"$myDevice does not work is not a bug-report."
Please, attach some more informations like kernel-release, dmesg and
lspci/lsusb and interested people can look at this.
Might be good to CC ilw ML, too.
Also, take a look at docs websites on <http://wireless.kernel.org/>.
- Sedat -
> Matt Allen
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Fw: Intel 6330 N
From: Matt Allen @ 2013-07-02 12:11 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1372731231.96036.YahooMailNeo@web161905.mail.bf1.yahoo.com>
To Whom it may concern,
I am having trouble getting my Intel 6330 wireless card to work on N. How long am I going to have to wait, until I am able to use N on my Intel 6330 wireless card? I have seen a lot of ways to disable it. I have found another Intel wireless card below this one that has N speed in linux, but I do not want to spend about money on a card that is not Linux compatable. Is there a current driver that I could download that works on Debian Jessie? Thank you for your time and assistance.
Matt Allen
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Arend van Spriel @ 2013-07-02 8:47 UTC (permalink / raw)
To: Larry Finger
Cc: linville, linux-wireless, netdev, Stable, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list,
Neil Horman
In-Reply-To: <1372712883-4464-1-git-send-email-Larry.Finger@lwfinger.net>
On 07/01/2013 11:08 PM, Larry Finger wrote:
> The driver fails to check the results of DMA mapping in twp places, which results
> in the following warning:
>
> [ 28.078515] ------------[ cut here ]------------
> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> single]
> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> [ 28.078622] Call Trace:
> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> --snip--
> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> [ 28.078984] Mapped at:
> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>
> As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> comment at the start of the routine to add that information, I also polished
> the wording.
Thanks, Larry
I think there a bugzilla issue for this that you might want to reference:
https://bugzilla.kernel.org/show_bug.cgi?id=60261
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: brcm80211-dev-list@broadcom.com
> ---
>
> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> index 1860c57..6260571 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> @@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
>
> /*
> * post receive buffers
> - * return false is refill failed completely and ring is empty this will stall
> - * the rx dma and user might want to call rxfill again asap. This unlikely
> - * happens on memory-rich NIC, but often on memory-constrained dongle
> + * return false is refill failed completely or dma mapping failed. The ring
Missed some polishing opportunity: return false is refill... -> return
false if refill...
> + * is empty, which will stall the rx dma and user might want to call rxfill
> + * again asap. This is unlikely to happen on a memory-rich NIC, but often on
> + * memory-constrained dongle
> */
> bool dma_rxfill(struct dma_pub *pub)
> {
> @@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
>
> pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> DMA_FROM_DEVICE);
> + if (dma_mapping_error(di->dmadev,pa))
> + return false;
>
> /* save the free packet pointer */
> di->rxp[rxout] = p;
> @@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di, struct sk_buff *p)
>
> /* get physical address of buffer start */
> pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
> -
> + if(dma_mapping_error(di->dmadev, pa))
> + return;
I think the caller(s) should be informed or silently free the sk_buff
here so we are not leaking it.
> /* With a DMA segment list, Descriptor table is filled
> * using the segment list instead of looping over
> * buffers in multi-chain DMA. Therefore, EOF for SGLIST
>
Regards,
Arend
^ permalink raw reply
* Re: Fwd: User-level question: on wil6210
From: Vladimir Kondratiev @ 2013-07-02 6:42 UTC (permalink / raw)
To: John W. Linville
Cc: Chang Liu, Sujith Manoharan, erez.kirshenbaum, linux-wireless
In-Reply-To: <20130701160759.GA20999@tuxdriver.com>
On Monday, July 01, 2013 12:07:59 PM John W. Linville wrote:
> Chang,
>
> It looks to me like you should be using the ath9k driver. What makes
> you think that you have a wil6210?
>
> In any case, I've Cc'ed Vladimir and Sujith -- hopefully one of them
> can be more helpful. :-)
>
> John
John,
Thanks for forwarding. Indeed, it is for me.
>
> On Sat, Jun 29, 2013 at 10:41:20AM +0200, Chang Liu wrote:
> > Dear John,
> >
> > My name is Chang, currently a student. I have a problem when I try to use
> > wil6210 as driver. Sorry to bother you with this letter here. I read the
> > notice on wireless.kernel.org and asked the same question on IRC but got no
> > reply. I subscribed the mailing list and I know you are respected in this
> > field. So I am here for help. I hope this doesn't bother you much.
> >
> > The thing is: I have a laptop Dell 6430u, which has wil6210 inside. I
> > downloaded the driver "compat driver-3.8.3-2-snp" and later run *make
> > install* and *modprobe wil6210*. No error returned. When I check iw
> > --version, it shows iw version 3.2.
> >
> > Now I want to check whether or not I have installed the driver correctly
> > and whether it works. I have no docking station (the access point) at hand
> > right now. First I run* lspci -nn*, which returns:
> >
<skip>
> > 02:00.0 PCI bridge [0604]: Device [1ae9:0101] (rev 03)
> > 03:00.0 PCI bridge [0604]: Device [1ae9:0200] (rev 03)
> > 03:02.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> > 03:03.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> > 04:00.0 Network controller [0280]: Atheros Communications Inc. AR9462
> > Wireless Network Adapter [168c:0034] (rev 01)
Yes, these 5 devices above are from wil6210, so you definetely have wil6210
card on your laptop.
This card is composite device. For details, see wiki
http://wireless.kernel.org/en/users/Drivers/wil6210
On this card, there is firmware that is stored in the on-card flash memory, and
is not loaded by the driver. Unfortunately, firmware on your laptop (and all
laptops like this) flashed with device 1ae9:0301 disabled. This firmware support
only so called WBE, that is essentially PCIE over 60g, for wireless docking.
Wireless docking stations that are used with WBE are NOT access points; as far as I
know there is no 60g access points available at this moment. You can run AP on another
Linux laptop with wil6210.
In order to support wifi, appropriate firmware need to be flashed on this card,
and then you will see wi-fi device 1ae9:0301.
To flash firmware, you need to contact Wilocity (adding Erez).
> >
> > Now comes the question:
> > 1. I saw on the website that the device 6210 should be "wil6210 device,
> > 1ae9:0301" (from linux wireless wil6210 page
> > http://wireless.kernel.org/en/users/Drivers/wil6210), which I cannot see
> > now. How should I find where the device is?
> >
> > 2. About the driver, I have no idea how to check whether it works.
> >
> > I use Ubuntu 12.04.2 LTS, and uname -a give information as follows:
> > Linux george-Latitude-6430U 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri
> > Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
You better use latest kernels since support for 60g band was integrated to versions
3.7 (some initial bits) to 3.10; and even some more patches are in the pipe for
inclusion in next versions.
> >
<skip
> >
> >
> > I am not familiar with linux, please help me with this. My id on the IRC
> > channel #linux-wireless is george_.I have tried google but not much
> > found. I really hope you could help me with this. Thank you in advance!
In general, 60g technology is in very early stages; wil6210 is 1-st commercially
available device. For now, I'd say it is better to have good knowledge in Linux
and wireless to experiment with this matter. You will also need to compile latest
wpa_supplicant and iw from git, released with Ubuntu 12.10 versions are not
good for 60g.
> >
> > Best regards!
> > Chang
Thanks, Vladimir
^ permalink raw reply
* RE: [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
From: Bing Zhao @ 2013-07-02 5:33 UTC (permalink / raw)
To: Harvey Yang, linux-wireless@vger.kernel.org; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1372731526-2979-1-git-send-email-harvey.huawei.yang@gmail.com>
Hi Harvey,
> From: Huawei Yang <harvey.huawei.yang@gmail.com>
>
> In function 'mwifiex_write_data_complete' it need tx info to find the
> mwifiex_private to updates statistics and wake up tx queues.
> Or we may trigger tx queues timeout when transmitting lots of mgmt frames.
>
> Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
> ---
> drivers/net/wireless/mwifiex/cfg80211.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
> b/drivers/net/wireless/mwifiex/cfg80211.c
> index e42b266..b4e2538 100644
> --- a/drivers/net/wireless/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/mwifiex/cfg80211.c
> @@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> struct sk_buff *skb;
> u16 pkt_len;
> const struct ieee80211_mgmt *mgmt;
> + struct mwifiex_txinfo *tx_info;
> struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev-
> >netdev);
>
> if (!buf || !len) {
> @@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> wiphy_err(wiphy, "allocate skb failed for management
> frame\n");
> return -ENOMEM;
> }
> +
Here checkpatch.pl script reports whitespace damaged error.
I can fix it in my local tree and resend v3 to John after the 3.11 merge window.
Thanks,
Bing
> + tx_info = MWIFIEX_SKB_TXCB(skb);
> + tx_info->bss_num = priv->bss_num;
> + tx_info->bss_type = priv->bss_type;
>
> mwifiex_form_mgmt_frame(skb, buf, len);
> mwifiex_queue_tx_pkt(priv, skb);
> --
> 1.7.10.4
^ permalink raw reply
* Re: [PATCH] iwlwifi: add firmware for 7260 / 3160 devices
From: Emmanuel Grumbach @ 2013-07-02 5:03 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Ben Hutchings, linux-wireless, Bjorn Mork, Johannes Berg
In-Reply-To: <1372075552-3253-1-git-send-email-emmanuel.grumbach@intel.com>
On Mon, Jun 24, 2013 at 3:05 PM, Emmanuel Grumbach
<emmanuel.grumbach@intel.com> wrote:
> Add new firmware for new devices: 7260 and 3160
> version:
> 22.0.7.0
>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> LICENCE.iwlwifi_firmware | 2 +-
> WHENCE | 6 ++++++
> iwlwifi-3160-7.ucode | Bin 0 -> 670172 bytes
> iwlwifi-7260-7.ucode | Bin 0 -> 682892 bytes
> 4 files changed, 7 insertions(+), 1 deletion(-)
> create mode 100644 iwlwifi-3160-7.ucode
> create mode 100644 iwlwifi-7260-7.ucode
>
ping? :)
^ permalink raw reply
* [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
From: Harvey Yang @ 2013-07-02 2:18 UTC (permalink / raw)
To: Bing Zhao, linux-wireless; +Cc: linux-kernel, Huawei Yang
From: Huawei Yang <harvey.huawei.yang@gmail.com>
In function 'mwifiex_write_data_complete' it need tx info to find
the mwifiex_private to updates statistics and wake up tx queues.
Or we may trigger tx queues timeout when transmitting lots of mgmt
frames.
Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
---
drivers/net/wireless/mwifiex/cfg80211.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index e42b266..b4e2538 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct sk_buff *skb;
u16 pkt_len;
const struct ieee80211_mgmt *mgmt;
+ struct mwifiex_txinfo *tx_info;
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev->netdev);
if (!buf || !len) {
@@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
wiphy_err(wiphy, "allocate skb failed for management frame\n");
return -ENOMEM;
}
+
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ tx_info->bss_num = priv->bss_num;
+ tx_info->bss_type = priv->bss_type;
mwifiex_form_mgmt_frame(skb, buf, len);
mwifiex_queue_tx_pkt(priv, skb);
--
1.7.10.4
^ permalink raw reply related
* Re: backports based on next-20130618
From: Luis R. Rodriguez @ 2013-07-01 21:39 UTC (permalink / raw)
To: backports@vger.kernel.org; +Cc: netdev@vger.kernel.org, linux-wireless
In-Reply-To: <CAB=NE6W6oa1Oa9O_s7B_4qKHdEz6S3DhVyvtpzP78XqRM_xk8A@mail.gmail.com>
On Mon, Jul 1, 2013 at 2:25 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> A new backports release has been made based on next-20130618, this has
> the new upstream alx driver, and the ath10k driver.
>
> https://www.kernel.org/pub/linux/kernel/projects/backports/2013/06/18/backports-20130618.tar.bz2
Sorry it just has alx, ath10k requires a small patch that I think
someone has sitting somewhere, next release.
Luis
^ permalink raw reply
* backports based on next-20130618
From: Luis R. Rodriguez @ 2013-07-01 21:25 UTC (permalink / raw)
To: backports@vger.kernel.org; +Cc: netdev@vger.kernel.org, linux-wireless
A new backports release has been made based on next-20130618, this has
the new upstream alx driver, and the ath10k driver.
https://www.kernel.org/pub/linux/kernel/projects/backports/2013/06/18/backports-20130618.tar.bz2
Luis
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Hauke Mehrtens @ 2013-07-01 21:12 UTC (permalink / raw)
To: Larry Finger
Cc: linville, linux-wireless, netdev, Stable, Brett Rudley,
Arend van Spriel, Franky (Zhenhui) Lin, Hante Meuleman,
brcm80211-dev-list
In-Reply-To: <1372712883-4464-1-git-send-email-Larry.Finger@lwfinger.net>
On 07/01/2013 11:08 PM, Larry Finger wrote:
> The driver fails to check the results of DMA mapping in twp places, which results
> in the following warning:
>
> [ 28.078515] ------------[ cut here ]------------
> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> single]
> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> [ 28.078622] Call Trace:
> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> --snip--
> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> [ 28.078984] Mapped at:
> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>
> As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> comment at the start of the routine to add that information, I also polished
> the wording.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: brcm80211-dev-list@broadcom.com
> ---
>
> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> index 1860c57..6260571 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> @@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
>
> /*
> * post receive buffers
> - * return false is refill failed completely and ring is empty this will stall
> - * the rx dma and user might want to call rxfill again asap. This unlikely
> - * happens on memory-rich NIC, but often on memory-constrained dongle
> + * return false is refill failed completely or dma mapping failed. The ring
> + * is empty, which will stall the rx dma and user might want to call rxfill
> + * again asap. This is unlikely to happen on a memory-rich NIC, but often on
> + * memory-constrained dongle
> */
> bool dma_rxfill(struct dma_pub *pub)
> {
> @@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
>
> pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> DMA_FROM_DEVICE);
> + if (dma_mapping_error(di->dmadev,pa))
^^
missing space
> + return false;
>
> /* save the free packet pointer */
> di->rxp[rxout] = p;
> @@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di, struct sk_buff *p)
>
> /* get physical address of buffer start */
> pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
> -
> + if(dma_mapping_error(di->dmadev, pa))
^^
missing space
> + return;
> /* With a DMA segment list, Descriptor table is filled
> * using the segment list instead of looping over
> * buffers in multi-chain DMA. Therefore, EOF for SGLIST
>
^ permalink raw reply
* [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Larry Finger @ 2013-07-01 21:08 UTC (permalink / raw)
To: linville
Cc: linux-wireless, Larry Finger, netdev, Stable, Brett Rudley,
Arend van Spriel, Franky (Zhenhui) Lin, Hante Meuleman,
brcm80211-dev-list
The driver fails to check the results of DMA mapping in twp places, which results
in the following warning:
[ 28.078515] ------------[ cut here ]------------
[ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
[ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
single]
[ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
[ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
[ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
[ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
[ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
[ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
[ 28.078622] Call Trace:
[ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
[ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
[ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
[ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
[ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
[ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
[ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
[ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
[ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
[ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
[ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
--snip--
[ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
[ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
[ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
[ 28.078984] Mapped at:
[ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
[ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
[ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
[ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
[ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
comment at the start of the routine to add that information, I also polished
the wording.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
---
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
index 1860c57..6260571 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
@@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
/*
* post receive buffers
- * return false is refill failed completely and ring is empty this will stall
- * the rx dma and user might want to call rxfill again asap. This unlikely
- * happens on memory-rich NIC, but often on memory-constrained dongle
+ * return false is refill failed completely or dma mapping failed. The ring
+ * is empty, which will stall the rx dma and user might want to call rxfill
+ * again asap. This is unlikely to happen on a memory-rich NIC, but often on
+ * memory-constrained dongle
*/
bool dma_rxfill(struct dma_pub *pub)
{
@@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(di->dmadev,pa))
+ return false;
/* save the free packet pointer */
di->rxp[rxout] = p;
@@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di, struct sk_buff *p)
/* get physical address of buffer start */
pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
-
+ if(dma_mapping_error(di->dmadev, pa))
+ return;
/* With a DMA segment list, Descriptor table is filled
* using the segment list instead of looping over
* buffers in multi-chain DMA. Therefore, EOF for SGLIST
--
1.8.1.4
^ permalink raw reply related
* Re: [RFC] wlcore: sdio: add wilink clock providers
From: Luciano Coelho @ 2013-07-01 20:55 UTC (permalink / raw)
To: balbi
Cc: mturquette, mark.rutland, grant.likely, rob.herring,
devicetree-discuss, --linux-doc, linux-kernel, linux-omap,
linux-wireless, linux-arm-kernel
In-Reply-To: <20130701204633.GB805@arwen.pp.htv.fi>
On Mon, 2013-07-01 at 23:46 +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 670c3ce..7f061b8 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -65,11 +65,19 @@
> > enable-active-high;
> > };
> >
> > +
> > wlan {
> > - compatible = "ti,wilink6";
> > - interrupt-parent = <&gpio2>;
> > - interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > - refclock = <2>; /* 38.4 MHz */
> > + compatible = "ti,wilink6";
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > + clocks = <&refclock>;
> > + clock-names = "refclock";
>
> hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
> explicitly here ?
No, not needed for Panda. Panda uses WiLink6 and only the refclock
needs to be provided.
> Also, you should probably make it clear that the WiLink module is fed by
> the 32K sync clock just to make sure clock usecounts are correctly
> incremented ?
Hmmm, yes, that is probably a good idea. At least to make sure
everything is initialized properly before the WiLink module is up and
running. I'll look into it and eventually add in a separate patch.
Thanks for your comments!
--
Luca.
^ permalink raw reply
* [PATCH 3/3] backports: add SPEED_UNKNOWN and DUPLEX_UNKNOWN
From: Luis R. Rodriguez @ 2013-07-01 20:55 UTC (permalink / raw)
To: backports; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1372712120-16606-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This gets us in synch with next-20130618.
This was added via uapi/linux/ethtool.h but using
that file causes some odd issues I simply cannot
resolve right now. I stuff these definitions into
the regular include/linux/ethtool.h for now.
This backports commit 589665f5 added via v3.2.
mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains \
589665f5a6008dbce1d0af2cb93e94a80bf78151
v3.2-rc1~4^2~10
commit 589665f5a6008dbce1d0af2cb93e94a80bf78151
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Nov 4 08:21:38 2011 +0000
bonding: comparing a u8 with -1 is always false
slave->duplex is a u8 type so the in bond_info_show_slave() when we
check "if (slave->duplex == -1)", it's always false.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31 [ OK ]
9 2.6.32 [ OK ]
10 2.6.33 [ OK ]
11 2.6.34 [ OK ]
12 2.6.35 [ OK ]
13 2.6.36 [ OK ]
14 2.6.37 [ OK ]
15 2.6.38 [ OK ]
16 2.6.39 [ OK ]
17 3.0.79 [ OK ]
18 3.1.10 [ OK ]
19 3.10-rc1 [ OK ]
20 3.2.45 [ OK ]
21 3.3.8 [ OK ]
22 3.4.46 [ OK ]
23 3.5.7 [ OK ]
24 3.6.11 [ OK ]
25 3.7.10 [ OK ]
26 3.8.13 [ OK ]
27 3.9.3 [ OK ]
real 15m7.262s
user 335m33.818s
sys 82m36.486s
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
backport/backport-include/linux/ethtool.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/backport/backport-include/linux/ethtool.h b/backport/backport-include/linux/ethtool.h
index 0c1eee6..2f323b0 100644
--- a/backport/backport-include/linux/ethtool.h
+++ b/backport/backport-include/linux/ethtool.h
@@ -3,6 +3,14 @@
#include_next <linux/ethtool.h>
#include <linux/version.h>
+#ifndef SPEED_UNKNOWN
+#define SPEED_UNKNOWN -1
+#endif /* SPEED_UNKNOWN */
+
+#ifndef DUPLEX_UNKNOWN
+#define DUPLEX_UNKNOWN 0xff
+#endif /* DUPLEX_UNKNOWN */
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(3,3,0)
#define ethtool_rxfh_indir_default LINUX_BACKPORT(ethtool_rxfh_indir_default)
static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] backports: add new alx upstream backport
From: Luis R. Rodriguez @ 2013-07-01 20:55 UTC (permalink / raw)
To: backports; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1372712120-16606-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This backports the new upstream alx driver and
properly splits up each required backports into
its respective collateral evolution bucket.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
.../network/0001-netdev_ops/alx.patch | 11 ++
.../network/0007-pci_dev_dev_flags/INFO | 28 +++++
.../network/0007-pci_dev_dev_flags/alx.patch | 13 +++
.../drivers_net_ethernet_atheros_alx_main.patch | 24 ++++
.../drivers_net_ethernet_atheros_alx_main.patch | 14 +++
.../drivers_net_ethernet_atheros_alx_main.patch | 58 +++++++++
.../drivers_net_ethernet_atheros_alx_main.patch | 13 +++
.../network/0001-backport-alx/alx.patch | 123 --------------------
.../0003-alx-deactivate-loopback-test/alx.patch | 25 ----
9 files changed, 161 insertions(+), 148 deletions(-)
create mode 100644 patches/collateral-evolutions/network/0001-netdev_ops/alx.patch
create mode 100644 patches/collateral-evolutions/network/0007-pci_dev_dev_flags/INFO
create mode 100644 patches/collateral-evolutions/network/0007-pci_dev_dev_flags/alx.patch
create mode 100644 patches/collateral-evolutions/network/11-dev-pm-ops/drivers_net_ethernet_atheros_alx_main.patch
create mode 100644 patches/collateral-evolutions/network/25-multicast-list_head/drivers_net_ethernet_atheros_alx_main.patch
create mode 100644 patches/collateral-evolutions/network/40-netdev-hw-features/drivers_net_ethernet_atheros_alx_main.patch
create mode 100644 patches/collateral-evolutions/network/61-netdev-addr_assign_type/drivers_net_ethernet_atheros_alx_main.patch
delete mode 100644 patches/unified-drivers/network/0001-backport-alx/alx.patch
delete mode 100644 patches/unified-drivers/network/0003-alx-deactivate-loopback-test/alx.patch
diff --git a/patches/collateral-evolutions/network/0001-netdev_ops/alx.patch b/patches/collateral-evolutions/network/0001-netdev_ops/alx.patch
new file mode 100644
index 0000000..46ed1fe
--- /dev/null
+++ b/patches/collateral-evolutions/network/0001-netdev_ops/alx.patch
@@ -0,0 +1,11 @@
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -1317,7 +1317,7 @@ static int alx_probe(struct pci_dev *pde
+ goto out_free_netdev;
+ }
+
+- netdev->netdev_ops = &alx_netdev_ops;
++ netdev_attach_ops(netdev, &alx_netdev_ops);
+ SET_ETHTOOL_OPS(netdev, &alx_ethtool_ops);
+ netdev->irq = pdev->irq;
+ netdev->watchdog_timeo = ALX_WATCHDOG_TIME;
diff --git a/patches/collateral-evolutions/network/0007-pci_dev_dev_flags/INFO b/patches/collateral-evolutions/network/0007-pci_dev_dev_flags/INFO
new file mode 100644
index 0000000..fc95b61
--- /dev/null
+++ b/patches/collateral-evolutions/network/0007-pci_dev_dev_flags/INFO
@@ -0,0 +1,28 @@
+The struct pci_dev dev_flags member was added as of
+v2.6.24 via ba698ad4. This collateral evolution can be
+enhanced and backported atomically through these series
+of patches. The end goal is to optimize this in SmPL form.
+
+mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains ba698ad4
+v2.6.24-rc2~28^2~6
+
+commit ba698ad4b7e466cbb4a8bde6b9da8080ab06808d
+Author: David Miller <davem@davemloft.net>
+Date: Thu Oct 25 01:16:30 2007 -0700
+
+ PCI: Add quirk for devices which disable MSI when INTX_DISABLE is set.
+
+ A reasonably common problem with some devices is that they will
+ disable MSI generation when the INTX_DISABLE bit is set in the
+ PCI_COMMAND register.
+
+ Quirk this explicitly, guarding the pci_intx() calls in msi.c with
+ this quirk indication.
+
+ The first entries for this quirk are for 5714 and 5780 Tigon3 chips,
+ and thus we can remove the workaround code from the tg3.c driver.
+
+ Signed-off-by: David S. Miller <davem@davemloft.net>
+ Acked-by: Michael Chan <mchan@broadcom.com>
+ Acked-by: Jeff Garzik <jgarzik@redhat.com>
+ Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff --git a/patches/collateral-evolutions/network/0007-pci_dev_dev_flags/alx.patch b/patches/collateral-evolutions/network/0007-pci_dev_dev_flags/alx.patch
new file mode 100644
index 0000000..aa782b7
--- /dev/null
+++ b/patches/collateral-evolutions/network/0007-pci_dev_dev_flags/alx.patch
@@ -0,0 +1,13 @@
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -1322,8 +1322,10 @@ static int alx_probe(struct pci_dev *pde
+ netdev->irq = pdev->irq;
+ netdev->watchdog_timeo = ALX_WATCHDOG_TIME;
+
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24)
+ if (ent->driver_data & ALX_DEV_QUIRK_MSI_INTX_DISABLE_BUG)
+ pdev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
++#endif
+
+ err = alx_init_sw(alx);
+ if (err) {
diff --git a/patches/collateral-evolutions/network/11-dev-pm-ops/drivers_net_ethernet_atheros_alx_main.patch b/patches/collateral-evolutions/network/11-dev-pm-ops/drivers_net_ethernet_atheros_alx_main.patch
new file mode 100644
index 0000000..4f4cce9
--- /dev/null
+++ b/patches/collateral-evolutions/network/11-dev-pm-ops/drivers_net_ethernet_atheros_alx_main.patch
@@ -0,0 +1,24 @@
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -1590,6 +1590,8 @@ static const struct pci_error_handlers a
+ };
+
+ #ifdef CONFIG_PM_SLEEP
++compat_pci_suspend(alx_suspend);
++compat_pci_resume(alx_resume);
+ static SIMPLE_DEV_PM_OPS(alx_pm_ops, alx_suspend, alx_resume);
+ #define ALX_PM_OPS (&alx_pm_ops)
+ #else
+@@ -1615,7 +1617,12 @@ static struct pci_driver alx_driver = {
+ .remove = alx_remove,
+ .shutdown = alx_shutdown,
+ .err_handler = &alx_err_handlers,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29))
+ .driver.pm = ALX_PM_OPS,
++#elif defined(CONFIG_PM_SLEEP)
++ .suspend = alx_suspend_compat,
++ .resume = alx_resume_compat,
++#endif
+ };
+
+ module_pci_driver(alx_driver);
diff --git a/patches/collateral-evolutions/network/25-multicast-list_head/drivers_net_ethernet_atheros_alx_main.patch b/patches/collateral-evolutions/network/25-multicast-list_head/drivers_net_ethernet_atheros_alx_main.patch
new file mode 100644
index 0000000..886bb87
--- /dev/null
+++ b/patches/collateral-evolutions/network/25-multicast-list_head/drivers_net_ethernet_atheros_alx_main.patch
@@ -0,0 +1,14 @@
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -466,7 +466,11 @@ static void __alx_set_rx_mode(struct net
+
+ if (!(netdev->flags & IFF_ALLMULTI)) {
+ netdev_for_each_mc_addr(ha, netdev)
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
+ alx_add_mc_addr(hw, ha->addr, mc_hash);
++#else
++ alx_add_mc_addr(hw, ha->dmi_addr, mc_hash);
++#endif
+
+ alx_write_mem32(hw, ALX_HASH_TBL0, mc_hash[0]);
+ alx_write_mem32(hw, ALX_HASH_TBL1, mc_hash[1]);
diff --git a/patches/collateral-evolutions/network/40-netdev-hw-features/drivers_net_ethernet_atheros_alx_main.patch b/patches/collateral-evolutions/network/40-netdev-hw-features/drivers_net_ethernet_atheros_alx_main.patch
new file mode 100644
index 0000000..35e3371
--- /dev/null
+++ b/patches/collateral-evolutions/network/40-netdev-hw-features/drivers_net_ethernet_atheros_alx_main.patch
@@ -0,0 +1,58 @@
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -737,6 +737,7 @@ static int alx_init_sw(struct alx_priv *
+ }
+
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39))
+ static netdev_features_t alx_fix_features(struct net_device *netdev,
+ netdev_features_t features)
+ {
+@@ -745,6 +746,7 @@ static netdev_features_t alx_fix_feature
+
+ return features;
+ }
++#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) */
+
+ static void alx_netif_stop(struct alx_priv *alx)
+ {
+@@ -820,7 +822,17 @@ static int alx_change_mtu(struct net_dev
+ alx->hw.mtu = mtu;
+ alx->rxbuf_size = mtu > ALX_DEF_RXBUF_SIZE ?
+ ALIGN(max_frame, 8) : ALX_DEF_RXBUF_SIZE;
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39))
++ if (mtu > (7*1024)) {
++ netdev->features &= ~NETIF_F_TSO;
++ netdev->features &= ~NETIF_F_TSO6;
++ } else {
++ netdev->features |= NETIF_F_TSO;
++ netdev->features |= NETIF_F_TSO6;
++ }
++#else
+ netdev_update_features(netdev);
++#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)) */
+ if (netif_running(netdev))
+ alx_reinit(alx);
+ return 0;
+@@ -1238,7 +1250,9 @@ static const struct net_device_ops alx_n
+ .ndo_change_mtu = alx_change_mtu,
+ .ndo_do_ioctl = alx_ioctl,
+ .ndo_tx_timeout = alx_tx_timeout,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39))
+ .ndo_fix_features = alx_fix_features,
++#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) */
+ #ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = alx_poll_controller,
+ #endif
+@@ -1361,7 +1375,11 @@ static int alx_probe(struct pci_dev *pde
+ }
+ }
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39))
+ netdev->hw_features = NETIF_F_SG | NETIF_F_HW_CSUM;
++#else
++ netdev->features = NETIF_F_SG | NETIF_F_HW_CSUM;
++#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) */
+
+ if (alx_get_perm_macaddr(hw, hw->perm_addr)) {
+ dev_warn(&pdev->dev,
diff --git a/patches/collateral-evolutions/network/61-netdev-addr_assign_type/drivers_net_ethernet_atheros_alx_main.patch b/patches/collateral-evolutions/network/61-netdev-addr_assign_type/drivers_net_ethernet_atheros_alx_main.patch
new file mode 100644
index 0000000..a492664
--- /dev/null
+++ b/patches/collateral-evolutions/network/61-netdev-addr_assign_type/drivers_net_ethernet_atheros_alx_main.patch
@@ -0,0 +1,13 @@
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -499,8 +499,10 @@ static int alx_set_mac_address(struct ne
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
+ if (netdev->addr_assign_type & NET_ADDR_RANDOM)
+ netdev->addr_assign_type ^= NET_ADDR_RANDOM;
++#endif
+
+ memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
+ memcpy(hw->mac_addr, addr->sa_data, netdev->addr_len);
diff --git a/patches/unified-drivers/network/0001-backport-alx/alx.patch b/patches/unified-drivers/network/0001-backport-alx/alx.patch
deleted file mode 100644
index a0a9c1f..0000000
--- a/patches/unified-drivers/network/0001-backport-alx/alx.patch
+++ /dev/null
@@ -1,123 +0,0 @@
---- a/drivers/net/ethernet/atheros/alx/alx_main.c
-+++ b/drivers/net/ethernet/atheros/alx/alx_main.c
-@@ -98,7 +98,11 @@ static void __alx_set_rx_mode(struct net
-
- /* comoute mc addresses' hash value ,and put it into hash table */
- netdev_for_each_mc_addr(ha, netdev)
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
- alx_add_mc_addr(hw, ha->addr);
-+#else
-+ alx_add_mc_addr(hw, ha->dmi_addr);
-+#endif
-
- ALX_MEM_W32(hw, ALX_HASH_TBL0, hw->mc_hash[0]);
- ALX_MEM_W32(hw, ALX_HASH_TBL1, hw->mc_hash[1]);
-@@ -130,8 +134,10 @@ static int alx_set_mac_address(struct ne
- if (!is_valid_ether_addr(addr->sa_data))
- return -EADDRNOTAVAIL;
-
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
- if (netdev->addr_assign_type & NET_ADDR_RANDOM)
- netdev->addr_assign_type ^= NET_ADDR_RANDOM;
-+#endif
-
- memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
- memcpy(hw->mac_addr, addr->sa_data, netdev->addr_len);
-@@ -1138,6 +1144,7 @@ static void alx_set_vlan_mode(struct alx
- }
-
-
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39))
- static netdev_features_t alx_fix_features(struct net_device *netdev,
- netdev_features_t features)
- {
-@@ -1170,6 +1177,7 @@ static int alx_set_features(struct net_d
-
- return 0;
- }
-+#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) */
-
- /* alx_change_mtu - Change the Maximum Transfer Unit */
- static int alx_change_mtu(struct net_device *netdev, int new_mtu)
-@@ -1194,7 +1202,17 @@ static int alx_change_mtu(struct net_dev
- adpt->hw.mtu = new_mtu;
- adpt->rxbuf_size = new_mtu > ALX_DEF_RXBUF_SIZE ?
- ALIGN(max_frame, 8) : ALX_DEF_RXBUF_SIZE;
-+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39))
-+ if (new_mtu > (7*1024)) {
-+ netdev->features &= ~NETIF_F_TSO;
-+ netdev->features &= ~NETIF_F_TSO6;
-+ } else {
-+ netdev->features |= NETIF_F_TSO;
-+ netdev->features |= NETIF_F_TSO6;
-+ }
-+#else
- netdev_update_features(netdev);
-+#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)) */
- if (netif_running(netdev))
- alx_reinit(adpt, false);
- }
-@@ -2460,8 +2478,10 @@ static const struct net_device_ops alx_n
- .ndo_change_mtu = alx_change_mtu,
- .ndo_do_ioctl = alx_ioctl,
- .ndo_tx_timeout = alx_tx_timeout,
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39))
- .ndo_fix_features = alx_fix_features,
- .ndo_set_features = alx_set_features,
-+#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) */
- #ifdef CONFIG_NET_POLL_CONTROLLER
- .ndo_poll_controller = alx_poll_controller,
- #endif
-@@ -2563,7 +2583,7 @@ alx_probe(struct pci_dev *pdev, const st
- goto err_iomap;
- }
-
-- netdev->netdev_ops = &alx_netdev_ops;
-+ netdev_attach_ops(netdev, &alx_netdev_ops);
- alx_set_ethtool_ops(netdev);
- netdev->irq = pdev->irq;
- netdev->watchdog_timeo = ALX_WATCHDOG_TIME;
-@@ -2608,12 +2628,21 @@ alx_probe(struct pci_dev *pdev, const st
- }
- }
-
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39))
- netdev->hw_features = NETIF_F_SG |
- NETIF_F_HW_CSUM |
- NETIF_F_HW_VLAN_CTAG_RX |
- NETIF_F_TSO |
- NETIF_F_TSO6;
- netdev->features = netdev->hw_features | NETIF_F_HW_VLAN_CTAG_TX;
-+#else
-+ netdev->features = NETIF_F_SG |
-+ NETIF_F_HW_CSUM |
-+ NETIF_F_HW_VLAN_CTAG_RX |
-+ NETIF_F_TSO |
-+ NETIF_F_TSO6 |
-+ NETIF_F_HW_VLAN_CTAG_TX;
-+#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)) */
-
- /* read permanent mac addr from register or eFuse */
- if (alx_get_perm_macaddr(hw, hw->perm_addr)) {
-@@ -2789,6 +2818,8 @@ static struct pci_error_handlers alx_err
- };
-
- #ifdef CONFIG_PM_SLEEP
-+compat_pci_suspend(alx_suspend);
-+compat_pci_resume(alx_resume);
- static SIMPLE_DEV_PM_OPS(alx_pm_ops, alx_suspend, alx_resume);
- #define ALX_PM_OPS (&alx_pm_ops)
- #else
-@@ -2802,7 +2833,12 @@ static struct pci_driver alx_driver = {
- .remove = alx_remove,
- .shutdown = alx_shutdown,
- .err_handler = &alx_err_handler,
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29))
- .driver.pm = ALX_PM_OPS,
-+#elif defined(CONFIG_PM_SLEEP)
-+ .suspend = alx_suspend_compat,
-+ .resume = alx_resume_compat,
-+#endif
- };
-
- module_pci_driver(alx_driver);
diff --git a/patches/unified-drivers/network/0003-alx-deactivate-loopback-test/alx.patch b/patches/unified-drivers/network/0003-alx-deactivate-loopback-test/alx.patch
deleted file mode 100644
index 3ed96a4..0000000
--- a/patches/unified-drivers/network/0003-alx-deactivate-loopback-test/alx.patch
+++ /dev/null
@@ -1,25 +0,0 @@
---- a/drivers/net/ethernet/atheros/alx/alx_ethtool.c
-+++ b/drivers/net/ethernet/atheros/alx/alx_ethtool.c
-@@ -1687,7 +1687,9 @@ static void alx_self_test(struct net_dev
- {
- struct alx_adapter *adpt = netdev_priv(netdev);
- bool if_running = netif_running(netdev);
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,1,0))
- bool phy_lpback = etest->flags & ETH_TEST_FL_EXTERNAL_LB;
-+#endif
-
- ALX_FLAG_SET(adpt, TESTING);
- memset(data, 0, sizeof(u64) * ALX_TEST_LEN);
-@@ -1707,10 +1709,12 @@ static void alx_self_test(struct net_dev
- if (alx_diag_interrupt(adpt, &data[2]))
- etest->flags |= ETH_TEST_FL_FAILED;
-
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,1,0))
- if (phy_lpback)
- etest->flags |= ETH_TEST_FL_EXTERNAL_LB_DONE;
- if (alx_diag_loopback(adpt, &data[3], phy_lpback))
- etest->flags |= ETH_TEST_FL_FAILED;
-+#endif
-
- } else {
- netif_info(adpt, hw, adpt->netdev, "online test start...\n");
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] backports: remove alx extra patch
From: Luis R. Rodriguez @ 2013-07-01 20:55 UTC (permalink / raw)
To: backports; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1372712120-16606-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
The alx driver was upstreamed by Johannes, so this is
no longer required. Note that this driver is now GPLv2
or later, BSD folks will have to look at the old unified
tree for a permissive licensed port.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
.../network/0001-netdev_ops/mwifiex.patch | 2 +-
...drivers_net_wireless_rtlwifi_rtl8192cu_sw.patch | 2 +-
.../network/0002-alx-make-kconfig/alx.patch | 32 --------------------
3 files changed, 2 insertions(+), 34 deletions(-)
delete mode 100644 patches/unified-drivers/network/0002-alx-make-kconfig/alx.patch
diff --git a/patches/collateral-evolutions/network/0001-netdev_ops/mwifiex.patch b/patches/collateral-evolutions/network/0001-netdev_ops/mwifiex.patch
index 0567191..58a38ab 100644
--- a/patches/collateral-evolutions/network/0001-netdev_ops/mwifiex.patch
+++ b/patches/collateral-evolutions/network/0001-netdev_ops/mwifiex.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
-@@ -750,7 +750,7 @@ static const struct net_device_ops mwifi
+@@ -749,7 +749,7 @@ static const struct net_device_ops mwifi
void mwifiex_init_priv_params(struct mwifiex_private *priv,
struct net_device *dev)
{
diff --git a/patches/collateral-evolutions/network/62-usb_driver_lpm/drivers_net_wireless_rtlwifi_rtl8192cu_sw.patch b/patches/collateral-evolutions/network/62-usb_driver_lpm/drivers_net_wireless_rtlwifi_rtl8192cu_sw.patch
index 28b2173..23181a0 100644
--- a/patches/collateral-evolutions/network/62-usb_driver_lpm/drivers_net_wireless_rtlwifi_rtl8192cu_sw.patch
+++ b/patches/collateral-evolutions/network/62-usb_driver_lpm/drivers_net_wireless_rtlwifi_rtl8192cu_sw.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
-@@ -385,7 +385,9 @@ static struct usb_driver rtl8192cu_drive
+@@ -386,7 +386,9 @@ static struct usb_driver rtl8192cu_drive
#ifdef CONFIG_AUTOSUSPEND
.supports_autosuspend = 1,
#endif
diff --git a/patches/unified-drivers/network/0002-alx-make-kconfig/alx.patch b/patches/unified-drivers/network/0002-alx-make-kconfig/alx.patch
deleted file mode 100644
index 465e499..0000000
--- a/patches/unified-drivers/network/0002-alx-make-kconfig/alx.patch
+++ /dev/null
@@ -1,32 +0,0 @@
---- a/drivers/net/ethernet/atheros/Kconfig
-+++ b/drivers/net/ethernet/atheros/Kconfig
-@@ -67,4 +67,22 @@ config ATL1C
- To compile this driver as a module, choose M here. The module
- will be called atl1c.
-
-+config ALX
-+ tristate "Qualcomm Atheros L1F Gigabit Ethernet support"
-+ depends on PCI
-+ select CRC32
-+ select NET_CORE
-+ select MII
-+ ---help---
-+ This driver supports the Qualcomm Atheros L1F ethernet adapter.
-+ This driver supports following chipsets:
-+
-+ 1969:1091 - AR8161 Gigabit Ethernet
-+ 1969:1090 - AR8162 Fast Ethernet
-+ 1969:10A1 - AR8171 Gigabit Ethernet
-+ 1969:10A0 - AR8172 Fast Ethernet
-+
-+ To compile this driver as a module, choose M here. The module
-+ will be called alx.
-+
- endif # NET_VENDOR_ATHEROS
---- a/drivers/net/ethernet/atheros/Makefile
-+++ b/drivers/net/ethernet/atheros/Makefile
-@@ -6,3 +6,4 @@ obj-$(CONFIG_ATL1) += atlx/
- obj-$(CONFIG_ATL2) += atlx/
- obj-$(CONFIG_ATL1E) += atl1e/
- obj-$(CONFIG_ATL1C) += atl1c/
-+obj-$(CONFIG_ALX) += alx/
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/3] backports: backport alx
From: Luis R. Rodriguez @ 2013-07-01 20:55 UTC (permalink / raw)
To: backports; +Cc: linux-wireless, Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Johannes threw alx upstream, this fixes the backport based on
the new shiny code.
Luis R. Rodriguez (3):
backports: remove alx extra patch
backports: add new alx upstream backport
backports: add SPEED_UNKNOWN and DUPLEX_UNKNOWN
backport/backport-include/linux/ethtool.h | 8 ++
.../network/0001-netdev_ops/alx.patch | 11 ++
.../network/0001-netdev_ops/mwifiex.patch | 2 +-
.../network/0007-pci_dev_dev_flags/INFO | 28 +++++
.../network/0007-pci_dev_dev_flags/alx.patch | 13 +++
.../drivers_net_ethernet_atheros_alx_main.patch | 24 ++++
.../drivers_net_ethernet_atheros_alx_main.patch | 14 +++
.../drivers_net_ethernet_atheros_alx_main.patch | 58 +++++++++
.../drivers_net_ethernet_atheros_alx_main.patch | 13 +++
...drivers_net_wireless_rtlwifi_rtl8192cu_sw.patch | 2 +-
.../network/0001-backport-alx/alx.patch | 123 --------------------
.../network/0002-alx-make-kconfig/alx.patch | 32 -----
.../0003-alx-deactivate-loopback-test/alx.patch | 25 ----
13 files changed, 171 insertions(+), 182 deletions(-)
create mode 100644 patches/collateral-evolutions/network/0001-netdev_ops/alx.patch
create mode 100644 patches/collateral-evolutions/network/0007-pci_dev_dev_flags/INFO
create mode 100644 patches/collateral-evolutions/network/0007-pci_dev_dev_flags/alx.patch
create mode 100644 patches/collateral-evolutions/network/11-dev-pm-ops/drivers_net_ethernet_atheros_alx_main.patch
create mode 100644 patches/collateral-evolutions/network/25-multicast-list_head/drivers_net_ethernet_atheros_alx_main.patch
create mode 100644 patches/collateral-evolutions/network/40-netdev-hw-features/drivers_net_ethernet_atheros_alx_main.patch
create mode 100644 patches/collateral-evolutions/network/61-netdev-addr_assign_type/drivers_net_ethernet_atheros_alx_main.patch
delete mode 100644 patches/unified-drivers/network/0001-backport-alx/alx.patch
delete mode 100644 patches/unified-drivers/network/0002-alx-make-kconfig/alx.patch
delete mode 100644 patches/unified-drivers/network/0003-alx-deactivate-loopback-test/alx.patch
--
1.7.10.4
^ permalink raw reply
* Re: [RFC] wlcore: sdio: add wilink clock providers
From: Felipe Balbi @ 2013-07-01 20:46 UTC (permalink / raw)
To: Luciano Coelho
Cc: mturquette, mark.rutland, balbi, grant.likely, rob.herring,
devicetree-discuss, --linux-doc, linux-kernel, linux-omap,
linux-wireless, linux-arm-kernel
In-Reply-To: <1372707250-11998-1-git-send-email-coelho@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
Hi,
On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 670c3ce..7f061b8 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -65,11 +65,19 @@
> enable-active-high;
> };
>
> +
> wlan {
> - compatible = "ti,wilink6";
> - interrupt-parent = <&gpio2>;
> - interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> - refclock = <2>; /* 38.4 MHz */
> + compatible = "ti,wilink6";
> + interrupt-parent = <&gpio2>;
> + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> + clocks = <&refclock>;
> + clock-names = "refclock";
hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
explicitly here ?
Also, you should probably make it clear that the WiLink module is fed by
the 32K sync clock just to make sure clock usecounts are correctly
incremented ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] ath9k_htc: fix data race between request_firmware_nowait() callback and suspend()
From: Alexey Khoroshilov @ 2013-07-01 20:43 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian
Cc: Alexey Khoroshilov, John W. Linville, linux-wireless, ath9k-devel,
linux-kernel, ldv-project
ath9k_hif_usb_probe() requests firmware asynchronically and
there is some initialization postponed till firmware is ready.
In particular, ath9k_hif_usb_firmware_cb() callback initializes
hif_dev->tx.tx_buf and hif_dev->tx.tx_pending lists.
At the same time, ath9k_hif_usb_suspend() iterates that lists through
ath9k_hif_usb_dealloc_urbs(). If suspend happens before request_firmware_nowait()
callback is called, it can lead to oops.
Similar issue could be in ath9k_hif_usb_disconnect(), but it is prevented
using hif_dev->fw_done completion and HIF_USB_READY flag. The patch extends
this approach to suspend() as well.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..fcd9aa5 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1076,7 +1076,7 @@ static void ath9k_hif_usb_firmware_fail(struct hif_device_usb *hif_dev)
struct device *dev = &hif_dev->udev->dev;
struct device *parent = dev->parent;
- complete(&hif_dev->fw_done);
+ complete_all(&hif_dev->fw_done);
if (parent)
device_lock(parent);
@@ -1125,7 +1125,7 @@ static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
release_firmware(fw);
hif_dev->flags |= HIF_USB_READY;
- complete(&hif_dev->fw_done);
+ complete_all(&hif_dev->fw_done);
return;
@@ -1310,7 +1310,10 @@ static int ath9k_hif_usb_suspend(struct usb_interface *interface,
if (!(hif_dev->flags & HIF_USB_START))
ath9k_htc_suspend(hif_dev->htc_handle);
- ath9k_hif_usb_dealloc_urbs(hif_dev);
+ wait_for_completion(&hif_dev->fw_done);
+
+ if (hif_dev->flags & HIF_USB_READY)
+ ath9k_hif_usb_dealloc_urbs(hif_dev);
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* Re: pull request: wireless-next 2013-06-28
From: David Miller @ 2013-07-01 20:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130628174000.GC30328@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 28 Jun 2013 13:40:00 -0400
> Yet one more pull request for wireless updates intended for 3.11...
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
Pulled, thanks John.
^ permalink raw reply
* merge window is CLOSED
From: David Miller @ 2013-07-01 20:14 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, netfilter-devel
With the 3.10 release, the merge window is closed.
If it's not a bug fix, and it isn't in patchwork right now, I
don't want to see it until net-next is openned again.
Thanks.
^ permalink raw reply
* [RFC] wlcore: sdio: add wilink clock providers
From: Luciano Coelho @ 2013-07-01 19:34 UTC (permalink / raw)
To: mturquette, mark.rutland, balbi
Cc: grant.likely, rob.herring, devicetree-discuss, --linux-doc,
linux-kernel, linux-omap, linux-wireless, linux-arm-kernel
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
Hi,
I came up with this code, trying to make the WiLink clocks definitions
as generic as possible and use existing fixed-clock bindings. This
looks relatively clean to me, even though it adds some complexity.
But I think it's better than the original bindings I had defined.
I still need to take care of the XTAL/not-XTAl boolean, but I will do
that separately.
This patch will be split (to take away the Panda DTS part) and
squashed in other patches in my series.
Please let me know what you think.
--
Cheers,
Luca.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ++++++++---
drivers/net/wireless/ti/wlcore/sdio.c | 43 ++++++++++++++++++++++++++---
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 670c3ce..7f061b8 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -65,11 +65,19 @@
enable-active-high;
};
+
wlan {
- compatible = "ti,wilink6";
- interrupt-parent = <&gpio2>;
- interrupts = <21 0x4>; /* gpio line 53, high level triggered */
- refclock = <2>; /* 38.4 MHz */
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 0x4>; /* gpio line 53, high level triggered */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
};
};
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 5b08620..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include <linux/wl12xx.h>
#include <linux/pm_runtime.h>
#include <linux/printk.h>
+#include <linux/clk-provider.h>
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -52,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -214,10 +216,16 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = "ti,wilink-clock" },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
+ struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,11 +249,28 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
- of_property_read_u32(np, "refclock", &pdata->ref_clock_freq);
+ glue->refclock = of_clk_get_by_name(np, "refclock");
+ if (IS_ERR(glue->refclock)) {
+ dev_err(dev, "couldn't find refclock on the device tree\n");
+ glue->refclock = NULL;
+ } else {
+ clk_prepare_enable(glue->refclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+ }
/* TODO: make sure we have this when needed (ie. for WL7) */
- of_property_read_u32(np, "tcxoclock", &pdata->tcxo_clock_freq);
+ glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+ if (IS_ERR(glue->tcxoclock)) {
+ dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+ glue->tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue->tcxoclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+ }
goto out;
@@ -291,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ sdio_set_drvdata(func, glue);
+
/* The pdata allocated here is freed when the device is freed,
* so we don't need an additional out label to free it in case
* of error further on.
@@ -316,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
if (mmcflags & MMC_PM_KEEP_POWER)
pdev_data->pwr_in_suspend = true;
- sdio_set_drvdata(func, glue);
-
/* Tell PM core that we don't need the card to be powered now */
pm_runtime_put_noidle(&func->dev);
@@ -384,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
{
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+ if (glue->refclock) {
+ clk_disable_unprepare(glue->refclock);
+ clk_put(glue->refclock);
+ }
+
+ if (glue->tcxoclock) {
+ clk_disable_unprepare(glue->tcxoclock);
+ clk_put(glue->tcxoclock);
+ }
+
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(&func->dev);
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH 1/1] mwifiex: add tx info to skb when forming mgmt frame
From: Bing Zhao @ 2013-07-01 19:34 UTC (permalink / raw)
To: Harvey Yang
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Avinash Patil, Stone Piao
In-Reply-To: <1372671230-8733-1-git-send-email-harvey.huawei.yang@gmail.com>
Hi Harvey,
Thanks for your patch.
> From: Huawei Yang <harvey.huawei.yang@gmail.com>
>
> In function 'mwifiex_write_data_complete' it need tx info to find the mwifiex_private to updates
> statistics and wake up tx queues. Or we may trigger tx queues timeout when transmitting lots of mgmt
> frames burstly.
Please shorten the commit log to less than 68 characters per line.
>
> Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
> ---
> drivers/net/wireless/mwifiex/cfg80211.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
> index e42b266..e8655f9 100644
> --- a/drivers/net/wireless/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/mwifiex/cfg80211.c
> @@ -166,6 +166,10 @@ mwifiex_form_mgmt_frame(struct sk_buff *skb, const u8 *buf, size_t len)
> memcpy(skb_put(skb, len - sizeof(struct ieee80211_hdr_3addr)),
> buf + sizeof(struct ieee80211_hdr_3addr),
> len - sizeof(struct ieee80211_hdr_3addr));
> +
> + tx_info = MWIFIEX_SKB_TXCB(skb);
> + tx_info->bss_num = priv->bss_num;
> + tx_info->bss_type = priv->bss_type;
This code doesn't compile because both tx_info and priv are undefined in this function.
Perhaps you meant to add it in mwifiex_cfg80211_mgmt_tx() instead?
@@ -216,6 +216,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wirele
return -ENOMEM;
}
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ tx_info->bss_num = priv->bss_num;
+ tx_info->bss_type = priv->bss_type;
+
mwifiex_form_mgmt_frame(skb, buf, len);
mwifiex_queue_tx_pkt(priv, skb);
>
> skb->priority = LOW_PRIO_TID;
> do_gettimeofday(&tv);
Thanks,
Bing
^ permalink raw reply
* Re: [PATCH 00/19] rt2x00: add experimental support for RT3593
From: Andreas Hartmann @ 2013-07-01 15:20 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <51D173EA.9030803@openwrt.org>
Hello Gabor,
Gabor Juhos wrote:
> Hi Andreas,
>
>> bad guy is back again :-)
>
> :)
>
>>
>> Gabor Juhos wrote:
>>> This patch-set implements experiemental support for the
>>> RT3593 chipset. The patches are tested on the Linksys
>>> AE3000 USB device only, however other USB devices which
>>> are using the RT3573 chips might work as well.
>>
>> I did another test with raspberry pi. Same network parameters (2.4 GHz,
>> 40MHz, eap-tls, ccmp/ccmp) but this time w/o any other load on the
>> wlan. But there is a reinforced-concrete floor between AP and STA.
>>
>> netperf with rt2800usb / backports-20130617 / kernel 3.6.11 gives:
>>
>> MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to server port 0 AF_INET
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.39 28.16
>> MIGRATED TCP MAERTS TEST from 0.0.0.0 () port 0 AF_INET from server port 0 AF_INET
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.00 30.23
>> TCP SENDFILE TEST from 0.0.0.0 () port 0 AF_INET to server port 0 AF_INET
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.35 27.69
>>
>>
>> Same with DPO_RT5572_LinuxSTA_2.6.1.3_20121022
>>
>> MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to server port 0 AF_INET
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.01 97.95
>> MIGRATED TCP MAERTS TEST from 0.0.0.0 () port 0 AF_INET from server port 0 AF_INET
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.01 121.69
>> TCP SENDFILE TEST from 0.0.0.0 () port 0 AF_INET to server port 0 AF_INET
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 10.01 82.75
>>
>> If you compare the result w/ rt2800usb/AE3000 with rt2800usb/rt3572[1]
>> you can see: no difference :-(.
>
> These results with the rt2800usb driver are quite bad. I don't yet have an idea
> what causes the huge performance loss on that platform.
One reason, from my point of view the main reason:
The rt2800usb driver causes to much interrupts (bad USB-handling). The
vendor driver uses a few interrupts with big data portions, rt2800usb
does it vice versa: small packets, but a lot more (1500 (14 Mbit/s) :
24.000 (9Mbit/s)).
See: http://article.gmane.org/gmane.linux.drivers.rt2x00.user/615
On systems with enough cpu resources, this problem doesn't hit that much
(but even there). But on all other systems, you're getting more or less
problems: all the more problems as worse the CPU resources get.
That's why rt5572sta performs mostly fine even with raspberry pi from my
point of view (besides the optimized rate control of the vendor driver).
Regards,
Andreas
^ 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