* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Sedat Dilek @ 2013-08-06 19:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <1375816128.8219.28.camel@jlt4.sipsolutions.net>
On Tue, Aug 6, 2013 at 9:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-08-06 at 20:35 +0200, Sedat Dilek wrote:
>
>> Attached is a diff comparing all new commits in next-20130805.
>> If one of the commits smells bad to you, please let me know.
>
> Out of that list, only the af_packet changes would seem to have any
> impact on wireless at all.
>
git-bisecting... 2 steps to go...
This one is bad... "af_packet: simplify VLAN frame check in packet_snd"
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c483e02614551e44ced3fe6eedda8e36d3277ccc
- Sedat -
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Johannes Berg @ 2013-08-06 19:18 UTC (permalink / raw)
To: sedat.dilek; +Cc: David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <CA+icZUXaTYVc_iv3hny6Je9mVdX8KCVpFSNBeukS+Fh-347Wvw@mail.gmail.com>
On Tue, 2013-08-06 at 21:14 +0200, Sedat Dilek wrote:
> On Tue, Aug 6, 2013 at 9:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Tue, 2013-08-06 at 20:35 +0200, Sedat Dilek wrote:
> >
> >> Attached is a diff comparing all new commits in next-20130805.
> >> If one of the commits smells bad to you, please let me know.
> >
> > Out of that list, only the af_packet changes would seem to have any
> > impact on wireless at all.
> >
>
> git-bisecting... 2 steps to go...
>
> This one is bad... "af_packet: simplify VLAN frame check in packet_snd"
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c483e02614551e44ced3fe6eedda8e36d3277ccc
That seems weird, does reverting it fix it?
johannes
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Sedat Dilek @ 2013-08-06 19:32 UTC (permalink / raw)
To: Johannes Berg, Phil Sutter
Cc: David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <1375816715.8219.29.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]
On Tue, Aug 6, 2013 at 9:18 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-08-06 at 21:14 +0200, Sedat Dilek wrote:
>> On Tue, Aug 6, 2013 at 9:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > On Tue, 2013-08-06 at 20:35 +0200, Sedat Dilek wrote:
>> >
>> >> Attached is a diff comparing all new commits in next-20130805.
>> >> If one of the commits smells bad to you, please let me know.
>> >
>> > Out of that list, only the af_packet changes would seem to have any
>> > impact on wireless at all.
>> >
>>
>> git-bisecting... 2 steps to go...
>>
>> This one is bad... "af_packet: simplify VLAN frame check in packet_snd"
>>
>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c483e02614551e44ced3fe6eedda8e36d3277ccc
>
> That seems weird, does reverting it fix it?
>
[ TO Phil Sutter ]
This was 3/3 of af_packet patches :-).
So, the culprit commit is...
0f75b09c798ed00c30d7d5551b896be883bc2aeb is the first bad commit
commit 0f75b09c798ed00c30d7d5551b896be883bc2aeb
Author: Phil Sutter <phil@nwl.cc>
Date: Fri Aug 2 11:37:39 2013 +0200
af_packet: when sending ethernet frames, parse header for skb->protocol
This may be necessary when the SKB is passed to other layers on the go,
which check the protocol field on their own. An example is a VLAN packet
sent out using AF_PACKET on a bridge interface. The bridging code checks
the SKB size, accounting for any VLAN header only if the protocol field
is set accordingly.
Note that eth_type_trans() sets skb->dev to the passed argument, so this
can be skipped in packet_snd() for ethernet frames, as well.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
:040000 040000 af403a20a321517f6cfb51d2e22c17ca5a60e947
1f302ebd62a87b9e874a3e61203499e17d6fce3c M net
- Sedat -
[-- Attachment #2: git-bisect-log.txt --]
[-- Type: text/plain, Size: 1834 bytes --]
git bisect start
# good: [88825c70d47953e7f38b86fb2ef00623439217d0] Merge remote-tracking branch 'wireless/master'
git bisect good 88825c70d47953e7f38b86fb2ef00623439217d0
# good: [3580d2439702fa29efcbce9e2bb1bceb2688d352] Merge remote-tracking branch 'slave-dma/next'
git bisect good 3580d2439702fa29efcbce9e2bb1bceb2688d352
# good: [88825c70d47953e7f38b86fb2ef00623439217d0] Merge remote-tracking branch 'wireless/master'
git bisect good 88825c70d47953e7f38b86fb2ef00623439217d0
# good: [3580d2439702fa29efcbce9e2bb1bceb2688d352] Merge remote-tracking branch 'slave-dma/next'
git bisect good 3580d2439702fa29efcbce9e2bb1bceb2688d352
# good: [a594e4f8c31c400024293b2e97fc7d3faaae74da] Merge branch 'bond_rcu'
git bisect good a594e4f8c31c400024293b2e97fc7d3faaae74da
# bad: [7f84622b9ac741614e7d066f7e8511d054f513ec] Merge remote-tracking branch 'net-next/master'
git bisect bad 7f84622b9ac741614e7d066f7e8511d054f513ec
# bad: [c483e02614551e44ced3fe6eedda8e36d3277ccc] af_packet: simplify VLAN frame check in packet_snd
git bisect bad c483e02614551e44ced3fe6eedda8e36d3277ccc
# good: [e216975ad97cfcfc436789aa66d59a0e93f337f7] uapi: Convert some uses of 6 to ETH_ALEN
git bisect good e216975ad97cfcfc436789aa66d59a0e93f337f7
# good: [ba5082c71476891623757956ebfc36040ac317e2] Merge branch 'eth_alen'
git bisect good ba5082c71476891623757956ebfc36040ac317e2
# bad: [0f75b09c798ed00c30d7d5551b896be883bc2aeb] af_packet: when sending ethernet frames, parse header for skb->protocol
git bisect bad 0f75b09c798ed00c30d7d5551b896be883bc2aeb
# good: [d27fc78208b53ccdfd6a57d4ac44a459ca66806f] sctp: Don't lookup dst if transport dst is still valid
git bisect good d27fc78208b53ccdfd6a57d4ac44a459ca66806f
# first bad commit: [0f75b09c798ed00c30d7d5551b896be883bc2aeb] af_packet: when sending ethernet frames, parse header for skb->protocol
[-- Attachment #3: git-bisect-visualize.txt --]
[-- Type: text/plain, Size: 786 bytes --]
commit 0f75b09c798ed00c30d7d5551b896be883bc2aeb
Author: Phil Sutter <phil@nwl.cc>
Date: Fri Aug 2 11:37:39 2013 +0200
af_packet: when sending ethernet frames, parse header for skb->protocol
This may be necessary when the SKB is passed to other layers on the go,
which check the protocol field on their own. An example is a VLAN packet
sent out using AF_PACKET on a bridge interface. The bridging code checks
the SKB size, accounting for any VLAN header only if the protocol field
is set accordingly.
Note that eth_type_trans() sets skb->dev to the passed argument, so this
can be skipped in packet_snd() for ethernet frames, as well.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Sedat Dilek @ 2013-08-06 19:47 UTC (permalink / raw)
To: Johannes Berg, Phil Sutter
Cc: David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <CA+icZUXdAjEDgu2XrA4Dg2hsLDJYdFTCpJwiW6=ZUgULe2noyw@mail.gmail.com>
On Tue, Aug 6, 2013 at 9:32 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Tue, Aug 6, 2013 at 9:18 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Tue, 2013-08-06 at 21:14 +0200, Sedat Dilek wrote:
>>> On Tue, Aug 6, 2013 at 9:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>>> > On Tue, 2013-08-06 at 20:35 +0200, Sedat Dilek wrote:
>>> >
>>> >> Attached is a diff comparing all new commits in next-20130805.
>>> >> If one of the commits smells bad to you, please let me know.
>>> >
>>> > Out of that list, only the af_packet changes would seem to have any
>>> > impact on wireless at all.
>>> >
>>>
>>> git-bisecting... 2 steps to go...
>>>
>>> This one is bad... "af_packet: simplify VLAN frame check in packet_snd"
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c483e02614551e44ced3fe6eedda8e36d3277ccc
>>
>> That seems weird, does reverting it fix it?
>>
>
> [ TO Phil Sutter ]
>
> This was 3/3 of af_packet patches :-).
>
> So, the culprit commit is...
>
> 0f75b09c798ed00c30d7d5551b896be883bc2aeb is the first bad commit
> commit 0f75b09c798ed00c30d7d5551b896be883bc2aeb
> Author: Phil Sutter <phil@nwl.cc>
> Date: Fri Aug 2 11:37:39 2013 +0200
>
> af_packet: when sending ethernet frames, parse header for skb->protocol
>
> This may be necessary when the SKB is passed to other layers on the go,
> which check the protocol field on their own. An example is a VLAN packet
> sent out using AF_PACKET on a bridge interface. The bridging code checks
> the SKB size, accounting for any VLAN header only if the protocol field
> is set accordingly.
>
> Note that eth_type_trans() sets skb->dev to the passed argument, so this
> can be skipped in packet_snd() for ethernet frames, as well.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> :040000 040000 af403a20a321517f6cfb51d2e22c17ca5a60e947
> 1f302ebd62a87b9e874a3e61203499e17d6fce3c M net
>
> - Sedat -
[ net/packet/af_packet.c ]
...
#include <linux/if_arp.h>
$ find include/ -name if_arp.h
include/uapi/linux/if_arp.h
include/linux/if_arp.h
$ LC_ALL=C ll include/uapi/linux/if_arp.h include/linux/if_arp.h
-rw-r--r-- 1 wearefam wearefam 1560 Jul 11 19:42 include/linux/if_arp.h
-rw-r--r-- 1 wearefam wearefam 6344 Jul 26 12:36 include/uapi/linux/if_arp.h
$ grep ARPHRD_ETHER include/linux/if_arp.h include/uapi/linux/if_arp.h
include/uapi/linux/if_arp.h:#define ARPHRD_ETHER 1
/* Ethernet 10Mbps */
Wrong include?
- Sedat -
^ permalink raw reply
* Re: [PATCH] mac80211: add control port protocol TX control flag
From: Kalle Valo @ 2013-08-06 20:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1375783056-2665-1-git-send-email-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> From: Johannes Berg <johannes.berg@intel.com>
>
> A lot of drivers check the frame protocol for ETH_P_PAE,
> for various reasons (like making those more reliable).
> Add a new flags bitmap to the TX control info and a new
> flag indicating the control port protocol is in use to
> let all drivers also apply such logic to other control
> port protocols, should they be configured.
>
> Change-Id: I292ba4865694142670f005856b6320f7f3fa05c8
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
I'm sure you noticed, but there's a Change-Id tag.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Phil Sutter @ 2013-08-06 21:29 UTC (permalink / raw)
To: Sedat Dilek
Cc: Johannes Berg, David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <CA+icZUVmokQ1fKmtbuPyp7f5Z2wdFYfjG5HCAm4Kue7efyKV8w@mail.gmail.com>
On Tue, Aug 06, 2013 at 09:47:01PM +0200, Sedat Dilek wrote:
> On Tue, Aug 6, 2013 at 9:32 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> > On Tue, Aug 6, 2013 at 9:18 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >> On Tue, 2013-08-06 at 21:14 +0200, Sedat Dilek wrote:
> >>> On Tue, Aug 6, 2013 at 9:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >>> > On Tue, 2013-08-06 at 20:35 +0200, Sedat Dilek wrote:
> >>> >
> >>> >> Attached is a diff comparing all new commits in next-20130805.
> >>> >> If one of the commits smells bad to you, please let me know.
> >>> >
> >>> > Out of that list, only the af_packet changes would seem to have any
> >>> > impact on wireless at all.
> >>> >
> >>>
> >>> git-bisecting... 2 steps to go...
> >>>
> >>> This one is bad... "af_packet: simplify VLAN frame check in packet_snd"
> >>>
> >>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c483e02614551e44ced3fe6eedda8e36d3277ccc
> >>
> >> That seems weird, does reverting it fix it?
> >>
> >
> > [ TO Phil Sutter ]
> >
> > This was 3/3 of af_packet patches :-).
> >
> > So, the culprit commit is...
> >
> > 0f75b09c798ed00c30d7d5551b896be883bc2aeb is the first bad commit
> > commit 0f75b09c798ed00c30d7d5551b896be883bc2aeb
> > Author: Phil Sutter <phil@nwl.cc>
> > Date: Fri Aug 2 11:37:39 2013 +0200
> >
> > af_packet: when sending ethernet frames, parse header for skb->protocol
> >
> > This may be necessary when the SKB is passed to other layers on the go,
> > which check the protocol field on their own. An example is a VLAN packet
> > sent out using AF_PACKET on a bridge interface. The bridging code checks
> > the SKB size, accounting for any VLAN header only if the protocol field
> > is set accordingly.
> >
> > Note that eth_type_trans() sets skb->dev to the passed argument, so this
> > can be skipped in packet_snd() for ethernet frames, as well.
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > :040000 040000 af403a20a321517f6cfb51d2e22c17ca5a60e947
> > 1f302ebd62a87b9e874a3e61203499e17d6fce3c M net
> >
> > - Sedat -
>
> [ net/packet/af_packet.c ]
> ...
> #include <linux/if_arp.h>
>
> $ find include/ -name if_arp.h
> include/uapi/linux/if_arp.h
> include/linux/if_arp.h
>
> $ LC_ALL=C ll include/uapi/linux/if_arp.h include/linux/if_arp.h
> -rw-r--r-- 1 wearefam wearefam 1560 Jul 11 19:42 include/linux/if_arp.h
> -rw-r--r-- 1 wearefam wearefam 6344 Jul 26 12:36 include/uapi/linux/if_arp.h
>
> $ grep ARPHRD_ETHER include/linux/if_arp.h include/uapi/linux/if_arp.h
> include/uapi/linux/if_arp.h:#define ARPHRD_ETHER 1
> /* Ethernet 10Mbps */
>
> Wrong include?
Nope, <linux/if_arp.h> includes <uapi/linux/if_arp.h>. I suppose there
is a semantical problem here.
Did you verify your bisect by reverting just the three patches?
Does the problem occur on client or server side? AFAICT, hostapd as well
as wpa_supplicant use AF_PACKET.
The tricky thing is, these patches are meant to *loosen* the
restrictions in af_packet.c, so *should* not be harmful. So either my
patches create a side effect I did not foresee, or it's something nasty
(too much delay introduced by calling eth_type_trans() or so).
Could you please provide steps on how to reproduce the faulty behaviour?
Best wishes, Phil
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Sedat Dilek @ 2013-08-06 21:40 UTC (permalink / raw)
To: Sedat Dilek, Johannes Berg, David Miller, Stephen Rothwell,
wireless, netdev
In-Reply-To: <20130806213006.078C72210F@mail.nwl.cc>
[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]
On Tue, Aug 6, 2013 at 11:29 PM, Phil Sutter <phil@nwl.cc> wrote:
> On Tue, Aug 06, 2013 at 09:47:01PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 6, 2013 at 9:32 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> > On Tue, Aug 6, 2013 at 9:18 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> >> On Tue, 2013-08-06 at 21:14 +0200, Sedat Dilek wrote:
>> >>> On Tue, Aug 6, 2013 at 9:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> >>> > On Tue, 2013-08-06 at 20:35 +0200, Sedat Dilek wrote:
>> >>> >
>> >>> >> Attached is a diff comparing all new commits in next-20130805.
>> >>> >> If one of the commits smells bad to you, please let me know.
>> >>> >
>> >>> > Out of that list, only the af_packet changes would seem to have any
>> >>> > impact on wireless at all.
>> >>> >
>> >>>
>> >>> git-bisecting... 2 steps to go...
>> >>>
>> >>> This one is bad... "af_packet: simplify VLAN frame check in packet_snd"
>> >>>
>> >>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c483e02614551e44ced3fe6eedda8e36d3277ccc
>> >>
>> >> That seems weird, does reverting it fix it?
>> >>
>> >
>> > [ TO Phil Sutter ]
>> >
>> > This was 3/3 of af_packet patches :-).
>> >
>> > So, the culprit commit is...
>> >
>> > 0f75b09c798ed00c30d7d5551b896be883bc2aeb is the first bad commit
>> > commit 0f75b09c798ed00c30d7d5551b896be883bc2aeb
>> > Author: Phil Sutter <phil@nwl.cc>
>> > Date: Fri Aug 2 11:37:39 2013 +0200
>> >
>> > af_packet: when sending ethernet frames, parse header for skb->protocol
>> >
>> > This may be necessary when the SKB is passed to other layers on the go,
>> > which check the protocol field on their own. An example is a VLAN packet
>> > sent out using AF_PACKET on a bridge interface. The bridging code checks
>> > the SKB size, accounting for any VLAN header only if the protocol field
>> > is set accordingly.
>> >
>> > Note that eth_type_trans() sets skb->dev to the passed argument, so this
>> > can be skipped in packet_snd() for ethernet frames, as well.
>> >
>> > Signed-off-by: Phil Sutter <phil@nwl.cc>
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>> >
>> > :040000 040000 af403a20a321517f6cfb51d2e22c17ca5a60e947
>> > 1f302ebd62a87b9e874a3e61203499e17d6fce3c M net
>> >
>> > - Sedat -
>>
>> [ net/packet/af_packet.c ]
>> ...
>> #include <linux/if_arp.h>
>>
>> $ find include/ -name if_arp.h
>> include/uapi/linux/if_arp.h
>> include/linux/if_arp.h
>>
>> $ LC_ALL=C ll include/uapi/linux/if_arp.h include/linux/if_arp.h
>> -rw-r--r-- 1 wearefam wearefam 1560 Jul 11 19:42 include/linux/if_arp.h
>> -rw-r--r-- 1 wearefam wearefam 6344 Jul 26 12:36 include/uapi/linux/if_arp.h
>>
>> $ grep ARPHRD_ETHER include/linux/if_arp.h include/uapi/linux/if_arp.h
>> include/uapi/linux/if_arp.h:#define ARPHRD_ETHER 1
>> /* Ethernet 10Mbps */
>>
>> Wrong include?
>
> Nope, <linux/if_arp.h> includes <uapi/linux/if_arp.h>. I suppose there
> is a semantical problem here.
>
> Did you verify your bisect by reverting just the three patches?
>
> Does the problem occur on client or server side? AFAICT, hostapd as well
> as wpa_supplicant use AF_PACKET.
>
> The tricky thing is, these patches are meant to *loosen* the
> restrictions in af_packet.c, so *should* not be harmful. So either my
> patches create a side effect I did not foresee, or it's something nasty
> (too much delay introduced by calling eth_type_trans() or so).
>
> Could you please provide steps on how to reproduce the faulty behaviour?
>
By reverting the culprit commit my network/wifi is fine, again.
See also attached patch with changelog.
- Sedat -
[-- Attachment #2: 0001-Revert-af_packet-when-sending-ethernet-frames-parse-.patch --]
[-- Type: application/octet-stream, Size: 2301 bytes --]
From 82d8f55ceab00c9ef829195e454a9cd74fded166 Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Tue, 6 Aug 2013 23:03:57 +0200
Subject: [PATCH next-20130805] Revert "af_packet: when sending ethernet
frames, parse header for skb->protocol"
This reverts commit 0f75b09c798ed00c30d7d5551b896be883bc2aeb
("af_packet: when sending ethernet frames, parse header for skb->protocol").
I noticed with next-20130806 that I cannot connect to my WLAN-AP anymore.
next-20130802 was the last GOOD and next-20130805 the first BAD Linux-next
release.
Debugging with wpasupplicant did not show any inconsistency.
To ensure it is not a problem of wireless, I tried wireless-testing
(master-2013-08-05), which did not show the symptoms.
Thanks Johannes Berg for the vital help.
After a git-bisect session it turned out that the above commit is the
culprit.
Reverting it fixes the issue for me.
Adapted and tested against Linux-next (next-20130805).
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
net/packet/af_packet.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 0c0f6c9..9343ea7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -88,7 +88,6 @@
#include <linux/virtio_net.h>
#include <linux/errqueue.h>
#include <linux/net_tstamp.h>
-#include <linux/if_arp.h>
#ifdef CONFIG_INET
#include <net/inet_common.h>
@@ -2002,9 +2001,6 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
if (unlikely(err))
return err;
- if (dev->type == ARPHRD_ETHER)
- skb->protocol = eth_type_trans(skb, dev);
-
data += dev->hard_header_len;
to_write -= dev->hard_header_len;
}
@@ -2331,20 +2327,13 @@ static int packet_snd(struct socket *sock,
sock_tx_timestamp(sk, &skb_shinfo(skb)->tx_flags);
- if (dev->type == ARPHRD_ETHER) {
- skb->protocol = eth_type_trans(skb, dev);
- if (skb->protocol == htons(ETH_P_8021Q))
- reserve += VLAN_HLEN;
- } else {
- skb->protocol = proto;
- skb->dev = dev;
- }
-
if (!gso_type && (len > dev->mtu + reserve + extra_len)) {
err = -EMSGSIZE;
goto out_free;
}
+ skb->protocol = proto;
+ skb->dev = dev;
skb->priority = sk->sk_priority;
skb->mark = sk->sk_mark;
--
1.8.3.4
^ permalink raw reply related
* [PATCH v2] mac80211: allow lowest basic rate for unicast management for mesh
From: Chun-Yeow Yeoh @ 2013-08-06 21:45 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, Chun-Yeow Yeoh
Allow lowest basic rate to be used for unicast management frame in
mesh. Otherwise, the lowest supported rate is used for unicast
management frame, such as 1Mbps for 2.4GHz and 6Mbps for 5GHz. Rename
the rc_send_low_broadcast to re_send_low_basicrate since now it is
also applied to unicast management frame in mesh.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
---
v2: Refactor to avoid duplication of code (Johannes)
net/mac80211/rate.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index ba63ac8..4aa7bb6 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -210,7 +210,7 @@ static bool rc_no_data_or_no_ack_use_min(struct ieee80211_tx_rate_control *txrc)
!ieee80211_is_data(fc);
}
-static void rc_send_low_broadcast(s8 *idx, u32 basic_rates,
+static void rc_send_low_basicrate(s8 *idx, u32 basic_rates,
struct ieee80211_supported_band *sband)
{
u8 i;
@@ -263,28 +263,37 @@ static void __rate_control_send_low(struct ieee80211_hw *hw,
}
-bool rate_control_send_low(struct ieee80211_sta *sta,
+bool rate_control_send_low(struct ieee80211_sta *pubsta,
void *priv_sta,
struct ieee80211_tx_rate_control *txrc)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(txrc->skb);
struct ieee80211_supported_band *sband = txrc->sband;
+ struct sta_info *sta;
int mcast_rate;
+ bool use_basicrate = false;
- if (!sta || !priv_sta || rc_no_data_or_no_ack_use_min(txrc)) {
- __rate_control_send_low(txrc->hw, sband, sta, info);
+ if (!pubsta || !priv_sta || rc_no_data_or_no_ack_use_min(txrc)) {
+ __rate_control_send_low(txrc->hw, sband, pubsta, info);
- if (!sta && txrc->bss) {
+ if (!pubsta && txrc->bss) {
mcast_rate = txrc->bss_conf->mcast_rate[sband->band];
if (mcast_rate > 0) {
info->control.rates[0].idx = mcast_rate - 1;
return true;
}
+ use_basicrate = true;
+ } else {
+ sta = container_of(pubsta, struct sta_info, sta);
+ if (ieee80211_vif_is_mesh(&sta->sdata->vif))
+ use_basicrate = true;
+ }
- rc_send_low_broadcast(&info->control.rates[0].idx,
+ if (use_basicrate)
+ rc_send_low_basicrate(&info->control.rates[0].idx,
txrc->bss_conf->basic_rates,
sband);
- }
+
return true;
}
return false;
--
1.7.9.5
^ permalink raw reply related
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Johannes Berg @ 2013-08-06 21:45 UTC (permalink / raw)
To: sedat.dilek; +Cc: David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <CA+icZUVk1HM-VVYcARvY7p5KBYz0YcY9+rW8s-nKPTeVYh4tgw@mail.gmail.com>
On Tue, 2013-08-06 at 23:40 +0200, Sedat Dilek wrote:
> > Does the problem occur on client or server side? AFAICT, hostapd as well
> > as wpa_supplicant use AF_PACKET.
> >
> > The tricky thing is, these patches are meant to *loosen* the
> > restrictions in af_packet.c, so *should* not be harmful. So either my
> > patches create a side effect I did not foresee, or it's something nasty
> > (too much delay introduced by calling eth_type_trans() or so).
> By reverting the culprit commit my network/wifi is fine, again.
> See also attached patch with changelog.
I think skb->protocol is probably getting set up wrong, and just putting
back the last two lines
skb->protocol = proto;
skb->dev = dev;
is probably sufficient to fix wifi. If skb->protocol isn't set to
ETH_P_PAE, then we'd drop the packet in the wifi stack - might be worth
printing out what it's set to at the point where the skb->protocol
assignment above was removed.
I'm trying to wrap my head around all this right now but I don't yet see
how the code after the patch would not get skb->protocol correct.
johannes
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Hannes Frederic Sowa @ 2013-08-06 21:56 UTC (permalink / raw)
To: Johannes Berg
Cc: sedat.dilek, David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <1375825538.10459.1.camel@jlt4.sipsolutions.net>
On Tue, Aug 06, 2013 at 11:45:38PM +0200, Johannes Berg wrote:
> On Tue, 2013-08-06 at 23:40 +0200, Sedat Dilek wrote:
>
> > > Does the problem occur on client or server side? AFAICT, hostapd as well
> > > as wpa_supplicant use AF_PACKET.
> > >
> > > The tricky thing is, these patches are meant to *loosen* the
> > > restrictions in af_packet.c, so *should* not be harmful. So either my
> > > patches create a side effect I did not foresee, or it's something nasty
> > > (too much delay introduced by calling eth_type_trans() or so).
>
> > By reverting the culprit commit my network/wifi is fine, again.
> > See also attached patch with changelog.
>
> I think skb->protocol is probably getting set up wrong, and just putting
> back the last two lines
>
> skb->protocol = proto;
> skb->dev = dev;
>
> is probably sufficient to fix wifi. If skb->protocol isn't set to
> ETH_P_PAE, then we'd drop the packet in the wifi stack - might be worth
> printing out what it's set to at the point where the skb->protocol
> assignment above was removed.
>
> I'm trying to wrap my head around all this right now but I don't yet see
> how the code after the patch would not get skb->protocol correct.
Has anybody tested plain ethernet? I have a malfunctioning dhclient on
ethernet since the weekend(it seems to not receive any packet). I did not
look after it because have other patches on my todo list currently. Maybe
it is the same error?
Greetings,
Hannes
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Johannes Berg @ 2013-08-06 21:58 UTC (permalink / raw)
To: sedat.dilek; +Cc: David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <1375825538.10459.1.camel@jlt4.sipsolutions.net>
On Tue, 2013-08-06 at 23:45 +0200, Johannes Berg wrote:
> I think skb->protocol is probably getting set up wrong, and just putting
> back the last two lines
>
> skb->protocol = proto;
> skb->dev = dev;
>
> is probably sufficient to fix wifi. If skb->protocol isn't set to
> ETH_P_PAE, then we'd drop the packet in the wifi stack - might be worth
> printing out what it's set to at the point where the skb->protocol
> assignment above was removed.
>
> I'm trying to wrap my head around all this right now but I don't yet see
> how the code after the patch would not get skb->protocol correct.
Actually, I think that's not it, but the code now behaves totally
differently?
Say this is the frame data with two points marked:
(1) (2)
| dst | src | ethtype | ... |
As I understand it (in my admittedly rather tired state), previously we
had
skb_network_header() == (1)
skb_mac_header() == (1)
skb->data == (1)
After calling eth_type_trans(), we get
skb_network_header() == (1)
skb_mac_header() == (1)
skb->data == (2)
I think? Maybe I'm totally confused though.
johannes
^ permalink raw reply
* [PATCH v3] mac80211: allow lowest basic rate for unicast management for mesh
From: Chun-Yeow Yeoh @ 2013-08-06 22:39 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, devel, Chun-Yeow Yeoh
Allow lowest basic rate to be used for unicast management frame in
mesh. Otherwise, the lowest supported rate is used for unicast
management frame, such as 1Mbps for 2.4GHz and 6Mbps for 5GHz. Rename
the rc_send_low_broadcast to re_send_low_basicrate since now it is
also applied to unicast management frame in mesh.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
---
v2: Refactor to avoid duplication of code (Johannes)
v3: Add checking to avoid NULL in pubsta (Yeoh)
net/mac80211/rate.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index ba63ac8..e126605 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -210,7 +210,7 @@ static bool rc_no_data_or_no_ack_use_min(struct ieee80211_tx_rate_control *txrc)
!ieee80211_is_data(fc);
}
-static void rc_send_low_broadcast(s8 *idx, u32 basic_rates,
+static void rc_send_low_basicrate(s8 *idx, u32 basic_rates,
struct ieee80211_supported_band *sband)
{
u8 i;
@@ -263,28 +263,37 @@ static void __rate_control_send_low(struct ieee80211_hw *hw,
}
-bool rate_control_send_low(struct ieee80211_sta *sta,
+bool rate_control_send_low(struct ieee80211_sta *pubsta,
void *priv_sta,
struct ieee80211_tx_rate_control *txrc)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(txrc->skb);
struct ieee80211_supported_band *sband = txrc->sband;
+ struct sta_info *sta;
int mcast_rate;
+ bool use_basicrate = false;
- if (!sta || !priv_sta || rc_no_data_or_no_ack_use_min(txrc)) {
- __rate_control_send_low(txrc->hw, sband, sta, info);
+ if (!pubsta || !priv_sta || rc_no_data_or_no_ack_use_min(txrc)) {
+ __rate_control_send_low(txrc->hw, sband, pubsta, info);
- if (!sta && txrc->bss) {
+ if (!pubsta && txrc->bss) {
mcast_rate = txrc->bss_conf->mcast_rate[sband->band];
if (mcast_rate > 0) {
info->control.rates[0].idx = mcast_rate - 1;
return true;
}
+ use_basicrate = true;
+ } else if (pubsta) {
+ sta = container_of(pubsta, struct sta_info, sta);
+ if (ieee80211_vif_is_mesh(&sta->sdata->vif))
+ use_basicrate = true;
+ }
- rc_send_low_broadcast(&info->control.rates[0].idx,
+ if (use_basicrate)
+ rc_send_low_basicrate(&info->control.rates[0].idx,
txrc->bss_conf->basic_rates,
sband);
- }
+
return true;
}
return false;
--
1.7.9.5
^ permalink raw reply related
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Sedat Dilek @ 2013-08-06 22:55 UTC (permalink / raw)
To: Johannes Berg, sedat.dilek, David Miller, Stephen Rothwell,
wireless, netdev
In-Reply-To: <20130806215657.GA16410@order.stressinduktion.org>
On Tue, Aug 6, 2013 at 11:56 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Tue, Aug 06, 2013 at 11:45:38PM +0200, Johannes Berg wrote:
>> On Tue, 2013-08-06 at 23:40 +0200, Sedat Dilek wrote:
>>
>> > > Does the problem occur on client or server side? AFAICT, hostapd as well
>> > > as wpa_supplicant use AF_PACKET.
>> > >
>> > > The tricky thing is, these patches are meant to *loosen* the
>> > > restrictions in af_packet.c, so *should* not be harmful. So either my
>> > > patches create a side effect I did not foresee, or it's something nasty
>> > > (too much delay introduced by calling eth_type_trans() or so).
>>
>> > By reverting the culprit commit my network/wifi is fine, again.
>> > See also attached patch with changelog.
>>
>> I think skb->protocol is probably getting set up wrong, and just putting
>> back the last two lines
>>
>> skb->protocol = proto;
>> skb->dev = dev;
>>
>> is probably sufficient to fix wifi. If skb->protocol isn't set to
>> ETH_P_PAE, then we'd drop the packet in the wifi stack - might be worth
>> printing out what it's set to at the point where the skb->protocol
>> assignment above was removed.
>>
>> I'm trying to wrap my head around all this right now but I don't yet see
>> how the code after the patch would not get skb->protocol correct.
>
> Has anybody tested plain ethernet? I have a malfunctioning dhclient on
> ethernet since the weekend(it seems to not receive any packet). I did not
> look after it because have other patches on my todo list currently. Maybe
> it is the same error?
>
No, tested only with iwlwifi.
Can you try the patch from [1]?
- Sedat -
[1] http://marc.info/?l=linux-netdev&m=137582524017840&w=2
> Greetings,
>
> Hannes
>
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Hannes Frederic Sowa @ 2013-08-06 23:07 UTC (permalink / raw)
To: Sedat Dilek
Cc: Johannes Berg, David Miller, Stephen Rothwell, wireless, netdev
In-Reply-To: <CA+icZUWY8PfYeV-iaPCm4MZenNaHRboK6Kmc8=Fnse9_dwfdqg@mail.gmail.com>
On Wed, Aug 07, 2013 at 12:55:33AM +0200, Sedat Dilek wrote:
> No, tested only with iwlwifi.
> Can you try the patch from [1]?
>
> - Sedat -
>
> [1] http://marc.info/?l=linux-netdev&m=137582524017840&w=2
Fixed the problem with virtio_net, too.
Thanks,
Hannes
^ permalink raw reply
* Re: linux-next: Tree for Aug 6 [ wireless | iwlwifi | mac80211 ? ]
From: Sedat Dilek @ 2013-08-06 23:14 UTC (permalink / raw)
To: Sedat Dilek, Johannes Berg, David Miller, Stephen Rothwell,
wireless, netdev
In-Reply-To: <20130806230749.GC16410@order.stressinduktion.org>
On Wed, Aug 7, 2013 at 1:07 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Wed, Aug 07, 2013 at 12:55:33AM +0200, Sedat Dilek wrote:
>> No, tested only with iwlwifi.
>> Can you try the patch from [1]?
>>
>> - Sedat -
>>
>> [1] http://marc.info/?l=linux-netdev&m=137582524017840&w=2
>
> Fixed the problem with virtio_net, too.
>
> Thanks,
>
Cool!
I retested with latest next-20130806 which is also fine with this patch.
- Sedat -
> Hannes
>
^ permalink raw reply
* Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
From: Andy Lutomirski @ 2013-08-07 0:26 UTC (permalink / raw)
To: Tom Gundersen
Cc: Bryan Kadzban, systemd Mailing List, Linux Wireless List,
Johannes Berg, Intel Linux Wireless, linux-hotplug,
Maarten Lankhorst, Kay Sievers, linux-kernel
In-Reply-To: <CAG-2HqU=yyxomNTg9-2+bxMKP=e5_pdVT7bhB_CHhFzB-ac_mQ@mail.gmail.com>
On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen <teg@jklm.no> wrote:
>
> On 6 Aug 2013 18:32, "Bryan Kadzban" <bryan@kadzban.is-a-geek.net> wrote:
>>
>> On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote:
>> > On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen <teg@jklm.no> wrote:
>> > > On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst
>> > > <m.b.lankhorst@gmail.com> wrote:
>> > >> Op 05-08-13 18:29, Andy Lutomirski schreef:
>> > >>> The systemd commit below can delay firmware loading by multiple
>> > >>> minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one
>> > >>> noticed that the systemd-udev change would break new kernels as well
>> > >>> as old kernels.
>> > >>>
>> > >>> Since the kernel apparently can't count on reasonable userspace
>> > >>> support, turn this thing off by default.
>> > >>>
>> > >>> commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
>> > >>> Author: Tom Gundersen <teg@jklm.no>
>> > >>> Date: Mon Mar 18 15:12:18 2013 +0100
>> > >>>
>> > >>> udev: make firmware loading optional and disable by default
>> > >>>
>> > >>> Distros that whish to support old kernels should set
>> > >>>
>> > >>> --with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware"
>> > >>> to retain the old behaviour.
>> > >>>
>> > >> methinks this patch should be reverted then,
>> > >
>> > > Well, all the code is still there, so it can be enabled if anyone
>> > > wants it.
>> > >
>> > >> or a stub should be added to udev to always fail firmware loading so
>> > >> timeouts don't occur.
>> > >
>> > > I think the only use (if any) of a userspace firmware loader would be
>> > > for anyone who wants a custom one (i.e., not udev), so we shouldn't
>> > > just fail the loading from udev unconditionally.
>> > >
>> > > How about we just improve the udev documentation a bit, similar to
>> > > Andy's kernel patch?
>> >
>> > Sorry, I should first have checked. We already document this in the
>> > README:
>> >
>> > > Userspace firmware loading is deprecated, will go away, and
>> > > sometimes causes problems:
>> > > CONFIG_FW_LOADER_USER_HELPER=n
>>
>> ...And this patch is making the kernel default to the correct behavior,
>> instead of the now-broken-by-udev behavior.
>>
>> I'm not sure I see the issue with it? :-)
>
> Oh yeah this patch is totally the right thing to do, I was just arguing that
> there is nothing to be done on the udev side.
>
>> (Add me to the list of people that think udev is broken too, fwiw. But
>> let's at least not leave *both* sides in a broken-by-default state.)
>
> Well I don't think it is too much to ask that the kernel and udev should be
> configured in a consistent way. Especially as thing still work even if you
> get it wrong, albeit with a delay.
Except that the current defaults are inconsistent and there is no
explanation anywhere in the logs when this is screwed up.
--Andy
^ permalink raw reply
* [PATCH] ath10k: setup peer UAPSD flag correctly
From: Janusz Dziedzic @ 2013-08-07 5:23 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Janusz Dziedzic
Setup UAPSD peer rate control (FW flag)
correctly.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cf2ba4d..505be82 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -973,7 +973,7 @@ static void ath10k_peer_assoc_h_qos_ap(struct ath10k *ar,
sta->uapsd_queues, sta->max_sp);
arg->peer_flags |= WMI_PEER_APSD;
- arg->peer_flags |= WMI_RC_UAPSD_FLAG;
+ arg->peer_rate_caps |= WMI_RC_UAPSD_FLAG;
if (sta->uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_VO)
uapsd |= WMI_AP_PS_UAPSD_AC3_DELIVERY_EN |
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] ath10k: setup peer UAPSD flag correctly
From: Kalle Valo @ 2013-08-07 6:59 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: ath10k, linux-wireless
In-Reply-To: <1375853036-2418-1-git-send-email-janusz.dziedzic@tieto.com>
Janusz Dziedzic <janusz.dziedzic@tieto.com> writes:
> Setup UAPSD peer rate control (FW flag)
> correctly.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
This doesn't answer the question "Why?". I have now added a section in
the wiki about what the commit log should contain. Hopefully that helps.
Submitting patches
Send patches to the mailing lists below. Kalle Valo reviews the patches
within the next few days and, if they are ok, commits them to ath.git.
To: ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Preferably use ath.git master as the baseline for patches. Other trees
can be used as well, but then the chances of conflicts are higher.
Guidelines for patches:
* MUST be compiler warning free.
* MUST be sparse warning free.
* Commit log MUST not be empty.
* The commit log MUST answer the question "Why?":
* Describe the motivation behind the bug.
* How does it change the functionality from user's point of view?
* Does it fix a bug? If it does, please describe the bug (doesn't need
to be long). Also if there's a public bug report add a link to the
bug report.
* If others have reported the issue commit log SHOULD use Reported-by:
and Tested-by: tags.
* SHOULD be checkpatch clean:
* FIXME: add checkpatch example with correct arguments
* Patches SHOULD be sent with git send-email tool.
* Patchsets SHOULD contain no more than 12 patches.
The terminology is from http://www.ietf.org/rfc/rfc2119.txt
http://wireless.kernel.org/en/users/Drivers/ath10k#Submitting_patches
Please comment.
--
Kalle Valo
^ permalink raw reply
* [PATCH 2/2] ath9k: Run the LNA combining algorithm properly
From: Sujith Manoharan @ 2013-08-07 6:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The LNA combining algorithm has to be run for cards
that support the required diversity features, make
sure that that correct conditions are met before
enabing this algorithm.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 46 ++++++++++++++++++++++-------------
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 865e043..e359557 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1156,7 +1156,8 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
struct ath_buf *bf;
struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
struct ieee80211_rx_status *rxs;
- struct ath_hw *ah = sc->sc_ah;
+ struct ath_hw *ah = sc->sc_ah
+; struct ath9k_hw_capabilities *pCap = &ah->caps;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_hdr *hdr;
@@ -1328,11 +1329,30 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
skb = hdr_skb;
}
+ if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
+ skb_trim(skb, skb->len - 8);
- if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
+ spin_lock_irqsave(&sc->sc_pm_lock, flags);
+ if ((sc->ps_flags & (PS_WAIT_FOR_BEACON |
+ PS_WAIT_FOR_CAB |
+ PS_WAIT_FOR_PSPOLL_DATA)) ||
+ ath9k_check_auto_sleep(sc))
+ ath_rx_ps(sc, skb, rs.is_mybeacon);
+ spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
+ /*
+ * Run the LNA combining algorithm only in these cases:
+ *
+ * Standalone WLAN cards with both LNA/Antenna diversity
+ * enabled in the EEPROM.
+ *
+ * WLAN+BT cards which are in the supported card list
+ * in ath_pci_id_table and the user has loaded the
+ * driver with "bt_ant_diversity" set to true.
+ */
+ if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
/*
- * change the default rx antenna if rx diversity
+ * Change the default rx antenna if rx diversity
* chooses the other antenna 3 times in a row.
*/
if (sc->rx.defant != rs.rs_antenna) {
@@ -1342,22 +1362,14 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
sc->rx.rxotherant = 0;
}
+ if (pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV) {
+ if (common->bt_ant_diversity)
+ ath_ant_comb_scan(sc, &rs);
+ } else {
+ ath_ant_comb_scan(sc, &rs);
+ }
}
- if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
- skb_trim(skb, skb->len - 8);
-
- spin_lock_irqsave(&sc->sc_pm_lock, flags);
- if ((sc->ps_flags & (PS_WAIT_FOR_BEACON |
- PS_WAIT_FOR_CAB |
- PS_WAIT_FOR_PSPOLL_DATA)) ||
- ath9k_check_auto_sleep(sc))
- ath_rx_ps(sc, skb, rs.is_mybeacon);
- spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
-
- if ((ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) && sc->ant_rx == 3)
- ath_ant_comb_scan(sc, &rs);
-
ath9k_apply_ampdu_details(sc, &rs, rxs);
ieee80211_rx(hw, skb);
--
1.8.3.4
^ permalink raw reply related
* [PATCH 1/2] ath9k: Fix BTCOEX usage for RX diversity
From: Sujith Manoharan @ 2013-08-07 6:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
BTCOEX has to be *disabled* for WLAN RX diversity to
work on combo cards.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 4afe30e..3b56c2e 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -645,11 +645,11 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
/*
* Enable WLAN/BT RX Antenna diversity only when:
*
- * - BTCOEX is enabled
+ * - BTCOEX is disabled.
* - the user manually requests the feature.
* - the HW cap is set using the platform data.
*/
- if (common->btcoex_enabled && ath9k_bt_ant_diversity &&
+ if (!common->btcoex_enabled && ath9k_bt_ant_diversity &&
(pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV))
common->bt_ant_diversity = 1;
--
1.8.3.4
^ permalink raw reply related
* [PATCH 0/2] Antenna diversity fixes
From: Sujith Manoharan @ 2013-08-07 6:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Hi,
Antenna diversity support for WLAN/BT combo cards WB195 and WB225
is fairly complete. WB335, which is based on AR9565 requires more
fixes.
More information is here:
http://wireless.kernel.org/en/users/Drivers/ath9k/antennadiversity
Sujith
Sujith Manoharan (2):
ath9k: Fix BTCOEX usage for RX diversity
ath9k: Run the LNA combining algorithm properly
drivers/net/wireless/ath/ath9k/init.c | 4 +--
drivers/net/wireless/ath/ath9k/recv.c | 46 ++++++++++++++++++++++-------------
2 files changed, 31 insertions(+), 19 deletions(-)
--
1.8.3.4
^ permalink raw reply
* Re: [PATCH v2] ath10k: add SoC power save option to PCI features map
From: Kalle Valo @ 2013-08-07 7:07 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1375430329-23352-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> Unify the PCI options location.
>
> By default the SoC PS option is disabled to boost the
> performance and due to poor stability on early HW revisions.
> In future we can remove the module parameter and turn on/off
> the PS for given hardware.
>
> This change also makes the pci module parameter for SoC PS static.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Thanks, applied. But there were conflicts, please double check that I
didn't break anything.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Run the LNA combining algorithm properly
From: Felix Fietkau @ 2013-08-07 7:18 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: John Linville, linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-3-git-send-email-sujith@msujith.org>
On 2013-08-07 8:59 AM, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> The LNA combining algorithm has to be run for cards
> that support the required diversity features, make
> sure that that correct conditions are met before
> enabing this algorithm.
>
> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath9k/recv.c | 46 ++++++++++++++++++++++-------------
> 1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index 865e043..e359557 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -1156,7 +1156,8 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
> struct ath_buf *bf;
> struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
> struct ieee80211_rx_status *rxs;
> - struct ath_hw *ah = sc->sc_ah;
> + struct ath_hw *ah = sc->sc_ah
> +; struct ath9k_hw_capabilities *pCap = &ah->caps;
> struct ath_common *common = ath9k_hw_common(ah);
> struct ieee80211_hw *hw = sc->hw;
> struct ieee80211_hdr *hdr;
Misplaced semicolon
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Run the LNA combining algorithm properly
From: Sujith Manoharan @ 2013-08-07 7:18 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John Linville, linux-wireless, ath9k-devel
In-Reply-To: <5201F4B9.1080109@openwrt.org>
Felix Fietkau wrote:
> > - struct ath_hw *ah = sc->sc_ah;
> > + struct ath_hw *ah = sc->sc_ah
> > +; struct ath9k_hw_capabilities *pCap = &ah->caps;
> > struct ath_common *common = ath9k_hw_common(ah);
> > struct ieee80211_hw *hw = sc->hw;
> > struct ieee80211_hdr *hdr;
> Misplaced semicolon
Thanks, I'll send v2.
Sujith
^ permalink raw reply
* [PATCH v2 2/2] ath9k: Run the LNA combining algorithm properly
From: Sujith Manoharan @ 2013-08-07 7:24 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-3-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The LNA combining algorithm has to be run for cards
that support the required diversity features, make
sure that that correct conditions are met before
enabing this algorithm.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
v2 : Fix a misplaced semicolon
drivers/net/wireless/ath/ath9k/recv.c | 44 ++++++++++++++++++++++-------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 865e043..62dff97 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1157,6 +1157,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
struct ieee80211_rx_status *rxs;
struct ath_hw *ah = sc->sc_ah;
+ struct ath9k_hw_capabilities *pCap = &ah->caps;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_hdr *hdr;
@@ -1328,11 +1329,30 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
skb = hdr_skb;
}
+ if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
+ skb_trim(skb, skb->len - 8);
- if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
+ spin_lock_irqsave(&sc->sc_pm_lock, flags);
+ if ((sc->ps_flags & (PS_WAIT_FOR_BEACON |
+ PS_WAIT_FOR_CAB |
+ PS_WAIT_FOR_PSPOLL_DATA)) ||
+ ath9k_check_auto_sleep(sc))
+ ath_rx_ps(sc, skb, rs.is_mybeacon);
+ spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
+ /*
+ * Run the LNA combining algorithm only in these cases:
+ *
+ * Standalone WLAN cards with both LNA/Antenna diversity
+ * enabled in the EEPROM.
+ *
+ * WLAN+BT cards which are in the supported card list
+ * in ath_pci_id_table and the user has loaded the
+ * driver with "bt_ant_diversity" set to true.
+ */
+ if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
/*
- * change the default rx antenna if rx diversity
+ * Change the default rx antenna if rx diversity
* chooses the other antenna 3 times in a row.
*/
if (sc->rx.defant != rs.rs_antenna) {
@@ -1342,22 +1362,14 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
sc->rx.rxotherant = 0;
}
+ if (pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV) {
+ if (common->bt_ant_diversity)
+ ath_ant_comb_scan(sc, &rs);
+ } else {
+ ath_ant_comb_scan(sc, &rs);
+ }
}
- if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
- skb_trim(skb, skb->len - 8);
-
- spin_lock_irqsave(&sc->sc_pm_lock, flags);
- if ((sc->ps_flags & (PS_WAIT_FOR_BEACON |
- PS_WAIT_FOR_CAB |
- PS_WAIT_FOR_PSPOLL_DATA)) ||
- ath9k_check_auto_sleep(sc))
- ath_rx_ps(sc, skb, rs.is_mybeacon);
- spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
-
- if ((ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) && sc->ant_rx == 3)
- ath_ant_comb_scan(sc, &rs);
-
ath9k_apply_ampdu_details(sc, &rs, rxs);
ieee80211_rx(hw, skb);
--
1.8.3.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox