* Re: issues with RTL8188CE device and rtl8192ce driver
From: Larry Finger @ 2013-08-12 22:58 UTC (permalink / raw)
To: Colleen Josephson; +Cc: linux-wireless
In-Reply-To: <CAN3-2D7=P=9VyV7xoANw_6B8VhOaTRC1iMw+mwUH2-g8YOmPMg@mail.gmail.com>
On 08/12/2013 05:54 PM, Colleen Josephson wrote:
> I have been having consistent issues with certain networks with my
> RTL8188CE device and the rtl8192ce driver (using kernel 3.8.13). I am
> running Gentoo linux and use NetworkManager to manage connections. I
> can utilize many networks fine, but some networks enter a
> connect/reconnect cycle where the device connects (and gets an IP/DNS
> info), but as soon as I try to actually transmit anything it
> immediately disconnects.
>
> When I look at /var/log/messages, I see this pattern happening a lot
> around the time the connection fails:
> wlan0: disassociated from 00:18:0a:36:83:36 (Reason: 2)
> cfg80211: Calling CRDA to update world regulatory domain
> wlan0: deauthenticating from 00:18:0a:36:83:36 by local choice (reason=3)
>
> (sometimes it says "Calling CRDA for country: US" instead)
>
> lspci -v:
> 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
> 802.11b/g/n WiFi Adapter (rev 01)
> Subsystem: Realtek Semiconductor Co., Ltd. Device 8195
> Flags: bus master, fast devsel, latency 0, IRQ 17
> I/O ports at 5000 [size=256]
> Memory at f3800000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00
> Kernel driver in use: rtl8192ce
> Kernel modules: rtl8192ce
>
> some relevant logging:
> http://pastebin.com/4jSQAhuM
>
> Any help with resolving this issue is greatly appreciated!
Have you tried the backports driver? There are a number of changes since 3.8,
which you will access that way.
Larry
^ permalink raw reply
* Re: [PATCH 1/3] staging: vt6656: rxtx.h always pack BEACON_BUFFER/TX_BUFFER
From: Malcolm Priestley @ 2013-08-12 23:07 UTC (permalink / raw)
To: Greg KH; +Cc: linux-wireless
In-Reply-To: <20130812215959.GA1473@kroah.com>
On Mon, 2013-08-12 at 14:59 -0700, Greg KH wrote:
> On Mon, Aug 05, 2013 at 09:04:54PM +0100, Malcolm Priestley wrote:
> > All structure members of BEACON_BUFFER/TX_BUFFER should be packed.
>
> Why?
Only the first 4 members of these structures are live.
The forth member is referenced at run-time by packed structures.
typedef struct tagSTxBufHead
typedef struct tagSTxShortBufHead
in desc.h
If these structures are not packed the alignment of these members
will be wrong.
>
> What happens if they are not?
The driver does not work.
Regards
Malcolm
^ permalink raw reply
* Re: [PATCH 1/3] staging: vt6656: rxtx.h always pack BEACON_BUFFER/TX_BUFFER
From: Greg KH @ 2013-08-12 23:09 UTC (permalink / raw)
To: Malcolm Priestley; +Cc: linux-wireless
In-Reply-To: <1376348835.12399.15.camel@canaries32-MCP7A>
On Tue, Aug 13, 2013 at 12:07:15AM +0100, Malcolm Priestley wrote:
> On Mon, 2013-08-12 at 14:59 -0700, Greg KH wrote:
> > On Mon, Aug 05, 2013 at 09:04:54PM +0100, Malcolm Priestley wrote:
> > > All structure members of BEACON_BUFFER/TX_BUFFER should be packed.
> >
> > Why?
>
> Only the first 4 members of these structures are live.
>
> The forth member is referenced at run-time by packed structures.
> typedef struct tagSTxBufHead
> typedef struct tagSTxShortBufHead
> in desc.h
>
> If these structures are not packed the alignment of these members
> will be wrong.
Then say all of this in the patch please :)
> >
> > What happens if they are not?
> The driver does not work.
How is it working today without this change?
thanks,
greg k-h
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Colleen Josephson @ 2013-08-12 23:27 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <520968B0.80301@lwfinger.net>
> Have you tried the backports driver? There are a number of changes since
> 3.8, which you will access that way.
I had not tried the backports driver. Do I need remove support things
in my kernel that I am now compiling with backports?
^ permalink raw reply
* Re: [PATCH 1/3] staging: vt6656: rxtx.h always pack BEACON_BUFFER/TX_BUFFER
From: Malcolm Priestley @ 2013-08-12 23:35 UTC (permalink / raw)
To: Greg KH; +Cc: linux-wireless
In-Reply-To: <20130812230936.GA31302@kroah.com>
On Mon, 2013-08-12 at 16:09 -0700, Greg KH wrote:
> On Tue, Aug 13, 2013 at 12:07:15AM +0100, Malcolm Priestley wrote:
> > On Mon, 2013-08-12 at 14:59 -0700, Greg KH wrote:
> > > On Mon, Aug 05, 2013 at 09:04:54PM +0100, Malcolm Priestley wrote:
> > > > All structure members of BEACON_BUFFER/TX_BUFFER should be packed.
> > >
> > > Why?
> >
> > Only the first 4 members of these structures are live.
> >
> > The forth member is referenced at run-time by packed structures.
> > typedef struct tagSTxBufHead
> > typedef struct tagSTxShortBufHead
> > in desc.h
> >
> > If these structures are not packed the alignment of these members
> > will be wrong.
>
> Then say all of this in the patch please :)
>
> > >
> > > What happens if they are not?
> > The driver does not work.
>
> How is it working today without this change?
Well for *me* it works.
It appears the structure is packed anyway.
But is this guaranteed?
Anyway, do you want me to resend the patch.
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Larry Finger @ 2013-08-12 23:37 UTC (permalink / raw)
To: Colleen Josephson; +Cc: linux-wireless
In-Reply-To: <CAN3-2D5rCnXYogA6s6in_e6qpyLmZ0bpbGX=REi=Cn29U40nMw@mail.gmail.com>
On 08/12/2013 06:27 PM, Colleen Josephson wrote:
>> Have you tried the backports driver? There are a number of changes since
>> 3.8, which you will access that way.
>
> I had not tried the backports driver. Do I need remove support things
> in my kernel that I am now compiling with backports?
If you install the baclports drivers, they will replace the standard ones.
Larry
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Colleen Josephson @ 2013-08-12 23:44 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <520971BA.6040503@lwfinger.net>
> If you install the baclports drivers, they will replace the standard ones.
Even for drivers built into my kernel (not as modules?). Just making
sure, as I seem to have encountered a problem:
After installing the backports version of rtl8192ce and rebooting,
wlan0 is not longer showing up when I run "ifconfig".
lsmod shows compat and rtl8192c_common, but not rtl8192ce. If I try
'modprobe rtl8192ce' I get this error: "Unknown symbol in module, or
unknown parameter (see dmesg)"
dmesg shows "rtlwifi: Unknown symbol mac80211_ieee80211_rx (err 0)"
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Larry Finger @ 2013-08-12 23:55 UTC (permalink / raw)
To: Colleen Josephson; +Cc: linux-wireless
In-Reply-To: <CAN3-2D75TLTS-Fv3CgoBjA+RA3jv-QyLoSs+PZeKXLY_MUcSTQ@mail.gmail.com>
On 08/12/2013 06:44 PM, Colleen Josephson wrote:
>> If you install the baclports drivers, they will replace the standard ones.
>
> Even for drivers built into my kernel (not as modules?). Just making
> sure, as I seem to have encountered a problem:
>
> After installing the backports version of rtl8192ce and rebooting,
> wlan0 is not longer showing up when I run "ifconfig".
>
> lsmod shows compat and rtl8192c_common, but not rtl8192ce. If I try
> 'modprobe rtl8192ce' I get this error: "Unknown symbol in module, or
> unknown parameter (see dmesg)"
>
> dmesg shows "rtlwifi: Unknown symbol mac80211_ieee80211_rx (err 0)"
I'm not sure, but I would expect you need the standard ones to be modules. I
always build all wireless devices as modules. That way when one goes bad, you
have a chance to recover with an unload/load sequence with modprobe. If it
works, you save a reboot.
I am assuming that you built mac80211 from the backported source. That is required.
Larry
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Colleen Josephson @ 2013-08-13 0:08 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <520975D8.8040908@lwfinger.net>
After making the bultins into modules, the compat drivers are loaded and used.
Unfortunately, the same symptoms as my original e-mail persist, with
repeated deauthentication (reason=3).
I am using backports-3.11-rc3-1
On Mon, Aug 12, 2013 at 4:55 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 08/12/2013 06:44 PM, Colleen Josephson wrote:
>>>
>>> If you install the baclports drivers, they will replace the standard
>>> ones.
>>
>>
>> Even for drivers built into my kernel (not as modules?). Just making
>> sure, as I seem to have encountered a problem:
>>
>> After installing the backports version of rtl8192ce and rebooting,
>> wlan0 is not longer showing up when I run "ifconfig".
>>
>> lsmod shows compat and rtl8192c_common, but not rtl8192ce. If I try
>> 'modprobe rtl8192ce' I get this error: "Unknown symbol in module, or
>> unknown parameter (see dmesg)"
>>
>> dmesg shows "rtlwifi: Unknown symbol mac80211_ieee80211_rx (err 0)"
>
>
> I'm not sure, but I would expect you need the standard ones to be modules. I
> always build all wireless devices as modules. That way when one goes bad,
> you have a chance to recover with an unload/load sequence with modprobe. If
> it works, you save a reboot.
>
> I am assuming that you built mac80211 from the backported source. That is
> required.
>
> Larry
>
>
>
>
--
Colleen Josephson
http://www.cjosephson.net
Dept. of Electrical Engineering and Computer Science
Massachusetts Institute of Technology
^ permalink raw reply
* Re: [PATCH 1/3] staging: vt6656: rxtx.h always pack BEACON_BUFFER/TX_BUFFER
From: Greg KH @ 2013-08-13 0:26 UTC (permalink / raw)
To: Malcolm Priestley; +Cc: linux-wireless
In-Reply-To: <1376350516.13046.6.camel@canaries32-MCP7A>
On Tue, Aug 13, 2013 at 12:35:16AM +0100, Malcolm Priestley wrote:
> On Mon, 2013-08-12 at 16:09 -0700, Greg KH wrote:
> > On Tue, Aug 13, 2013 at 12:07:15AM +0100, Malcolm Priestley wrote:
> > > On Mon, 2013-08-12 at 14:59 -0700, Greg KH wrote:
> > > > On Mon, Aug 05, 2013 at 09:04:54PM +0100, Malcolm Priestley wrote:
> > > > > All structure members of BEACON_BUFFER/TX_BUFFER should be packed.
> > > >
> > > > Why?
> > >
> > > Only the first 4 members of these structures are live.
> > >
> > > The forth member is referenced at run-time by packed structures.
> > > typedef struct tagSTxBufHead
> > > typedef struct tagSTxShortBufHead
> > > in desc.h
> > >
> > > If these structures are not packed the alignment of these members
> > > will be wrong.
> >
> > Then say all of this in the patch please :)
> >
> > > >
> > > > What happens if they are not?
> > > The driver does not work.
> >
> > How is it working today without this change?
> Well for *me* it works.
>
> It appears the structure is packed anyway.
>
> But is this guaranteed?
>
> Anyway, do you want me to resend the patch.
>
Yes, please do, with this added information, and all other patches from
you that I did not apply, due to me not accepting this one.
thanks,
greg k-h
^ permalink raw reply
* RE: 80211s with DFS
From: Wright, Brett @ 2013-08-13 1:33 UTC (permalink / raw)
To: Volker von Hoesslin @ SKBX Systems, linux-wireless
In-Reply-To: <5207FC2A.4040207@skbx.de>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Volker von Hoesslin @ SKBX Systems
> i have a real big problem! i'm trying to implement a wireless-mesh
> (80211s) with openWRT (current trunk) over 11a (5GHz) with "authSAE"
for
> outdoor. all works fine, mesh is runnning and all fine. but now, i'm
at
> germany and for the outdoor use, i have to use the channel 100-140
with DFS
> & TPC. so the mesh implementation dont work in this channel? with this
> error:
>
Hi
The real difficulty with DFS and 802.11s is what happens when a radar is
detected? All mesh nodes need to be on the same channel, so there needs
to be some consistent way of propagating a channel switch announcement
to all wireless nodes.
Brett
^ permalink raw reply
* Re: [PATCH v2 3.11] genetlink: fix family dump race
From: David Miller @ 2013-08-13 5:06 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, netdev, tgraf, andrei.otcheretianski, ilan.peer,
stable, pshelar
In-Reply-To: <1376297697.11514.8.camel@jlt4.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 12 Aug 2013 10:54:57 +0200
> I think for the current code the fix would still be correct, I can
> change the commit message if you like.
I agree, please update the commit message and resubmit.
> For backporting, we'll have to check which tree has Pravin's change
> and which doesn't and change this accordingly, I suppose.
This is really tricky, because we'd need to also backport the fixes
for the regressions added by Pravin's change such as:
50754d2188b04a679a249fb57751542643a436e0
c74f2b2678f40b80265dd53556f1f778c8e1823f
^ permalink raw reply
* Re: [PATCH 2/4] ath10k: use sizeof(*var) in kmalloc
From: Michal Kazior @ 2013-08-13 5:12 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87li47t276.fsf@kamboji.qca.qualcomm.com>
On 12 August 2013 16:26, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This fixes checkpatch warning from the latest
>> 3.11-rc kernel tree.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>> ---
>> drivers/net/wireless/ath/ath10k/pci.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
>> index d95439b..1814af1 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -803,8 +803,7 @@ static int ath10k_pci_start_ce(struct ath10k *ar)
>> continue;
>>
>> for (i = 0; i < completions; i++) {
>> - compl = kmalloc(sizeof(struct ath10k_pci_compl),
>> - GFP_KERNEL);
>> + compl = kmalloc(sizeof(*compl), GFP_KERNEL);
>> if (!compl) {
>> ath10k_warn("No memory for completion state\n");
>> ath10k_pci_stop_ce(ar);
>
> Just out of curiosity, what's the warning? kmalloc() should be called
> with sizeof(*foo) style?
Checkpatch prints:
CHECK: Prefer kmalloc(sizeof(*compl)...) over kmalloc(sizeof(struct
ath10k_pci_compl)...)
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [PATCH 3/4] ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
From: Michal Kazior @ 2013-08-13 5:18 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <878v07t0up.fsf@kamboji.qca.qualcomm.com>
On 12 August 2013 16:55, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This enables driver to rx another decapped a-msdu
>> frames. It should possibly help with throughputs
>> in some cases and reduce (or eliminate) number of
>> messages like this:
>>
>> ath10k: error processing msdus -524
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> [...]
>
>> @@ -659,6 +658,15 @@ static int ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
>> decap_hdr += roundup(crypto_len, 4);
>> }
>>
>> + if (fmt == RX_MSDU_DECAP_8023_SNAP_LLC) {
>> + /* SNAP 802.3 consists of:
>> + * [dst:6][src:6][len:2][dsap:1][ssap:1][ctl:1][snap:5]
>> + * [data][fcs:4].
>> + *
>> + * Since this overlaps with A-MSDU header (da, sa, len)
>> + * there's nothing extra to do. */
>> + }
>
> This block doesn't have any code, is that on purpose? Most likely a
> static checker finds this later and we need to remove it.
>
> If your idea is to document the LLC case (which is very good!) it's
> better to do everything inside a comment, for example like this:
>
> /* When fmt == RX_MSDU_DECAP_8023_SNAP_LLC:
> *
> * SNAP 802.3 consists of:
> * [dst:6][src:6][len:2][dsap:1][ssap:1][ctl:1][snap:5]
> * [data][fcs:4].
> *
> * Since this overlaps with A-MSDU header (da, sa, len)
> * there's nothing extra to do. */
Yes, it's on purpose. I'll make a comment out of it then.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* [PATCH v2 1/4] ath10k: clean up monitor start code
From: Michal Kazior @ 2013-08-13 5:54 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373297-32369-1-git-send-email-michal.kazior@tieto.com>
Remove useless code that was causing WARN_ON when
a 80MHz+ vif entered promiscuous mode or monitor
interface was started.
The channel mode is already computed by
chan_to_phymode().
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cf2ba4d..05f5f76 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -503,13 +503,10 @@ static int ath10k_monitor_start(struct ath10k *ar, int vdev_id)
{
struct ieee80211_channel *channel = ar->hw->conf.chandef.chan;
struct wmi_vdev_start_request_arg arg = {};
- enum nl80211_channel_type type;
int ret = 0;
lockdep_assert_held(&ar->conf_mutex);
- type = cfg80211_get_chandef_type(&ar->hw->conf.chandef);
-
arg.vdev_id = vdev_id;
arg.channel.freq = channel->center_freq;
arg.channel.band_center_freq1 = ar->hw->conf.chandef.center_freq1;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/4] ath10k: cleanups
From: Michal Kazior @ 2013-08-13 5:54 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949650-9699-1-git-send-email-michal.kazior@tieto.com>
Hi,
This patchset contains a few non-functional clean
ups.
v2:
* fix line over 80 chars
Michal Kazior (4):
ath10k: clean up monitor start code
ath10k: use sizeof(*var) in kmalloc
ath10k: clean up PCI completion states
ath10k: print errcode when CE ring setup fails
drivers/net/wireless/ath/ath10k/ce.c | 15 +++++++++------
drivers/net/wireless/ath/ath10k/mac.c | 3 ---
drivers/net/wireless/ath/ath10k/pci.c | 25 +++++++++++++++++--------
drivers/net/wireless/ath/ath10k/pci.h | 13 +++++++------
4 files changed, 33 insertions(+), 23 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 2/4] ath10k: use sizeof(*var) in kmalloc
From: Michal Kazior @ 2013-08-13 5:54 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373297-32369-1-git-send-email-michal.kazior@tieto.com>
This fixes checkpatch warning from the latest
3.11-rc kernel tree.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e2f9ef5..98edb31 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -805,8 +805,7 @@ static int ath10k_pci_start_ce(struct ath10k *ar)
continue;
for (i = 0; i < completions; i++) {
- compl = kmalloc(sizeof(struct ath10k_pci_compl),
- GFP_KERNEL);
+ compl = kmalloc(sizeof(*compl), GFP_KERNEL);
if (!compl) {
ath10k_warn("No memory for completion state\n");
ath10k_pci_stop_ce(ar);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/4] ath10k: print errcode when CE ring setup fails
From: Michal Kazior @ 2013-08-13 5:54 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373297-32369-1-git-send-email-michal.kazior@tieto.com>
This makes it possible to see the reason why the
setup fails. It also adheres to code style of
error checking in ath drivers.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index f8b969f..50d2ea2 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1128,6 +1128,7 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
{
struct ce_state *ce_state;
u32 ctrl_addr = ath10k_ce_base_address(ce_id);
+ int ret;
ce_state = ath10k_ce_init_state(ar, ce_id, attr);
if (!ce_state) {
@@ -1136,18 +1137,20 @@ struct ce_state *ath10k_ce_init(struct ath10k *ar,
}
if (attr->src_nentries) {
- if (ath10k_ce_init_src_ring(ar, ce_id, ce_state, attr)) {
- ath10k_err("Failed to initialize CE src ring for ID: %d\n",
- ce_id);
+ ret = ath10k_ce_init_src_ring(ar, ce_id, ce_state, attr);
+ if (ret) {
+ ath10k_err("Failed to initialize CE src ring for ID: %d (%d)\n",
+ ce_id, ret);
ath10k_ce_deinit(ce_state);
return NULL;
}
}
if (attr->dest_nentries) {
- if (ath10k_ce_init_dest_ring(ar, ce_id, ce_state, attr)) {
- ath10k_err("Failed to initialize CE dest ring for ID: %d\n",
- ce_id);
+ ret = ath10k_ce_init_dest_ring(ar, ce_id, ce_state, attr);
+ if (ret) {
+ ath10k_err("Failed to initialize CE dest ring for ID: %d (%d)\n",
+ ce_id, ret);
ath10k_ce_deinit(ce_state);
return NULL;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] ath10k: clean up PCI completion states
From: Michal Kazior @ 2013-08-13 5:54 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373297-32369-1-git-send-email-michal.kazior@tieto.com>
Improve code readability by using enum and a
switch-case.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v2;
* fix line over 80 chars
drivers/net/wireless/ath/ath10k/pci.c | 22 ++++++++++++++++------
drivers/net/wireless/ath/ath10k/pci.h | 13 +++++++------
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 98edb31..630ba59 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -540,7 +540,7 @@ static void ath10k_pci_ce_send_done(struct ce_state *ce_state,
if (!compl)
break;
- compl->send_or_recv = HIF_CE_COMPLETE_SEND;
+ compl->state = ATH10K_PCI_COMPL_SEND;
compl->ce_state = ce_state;
compl->pipe_info = pipe_info;
compl->transfer_context = transfer_context;
@@ -590,7 +590,7 @@ static void ath10k_pci_ce_recv_data(struct ce_state *ce_state,
if (!compl)
break;
- compl->send_or_recv = HIF_CE_COMPLETE_RECV;
+ compl->state = ATH10K_PCI_COMPL_RECV;
compl->ce_state = ce_state;
compl->pipe_info = pipe_info;
compl->transfer_context = transfer_context;
@@ -812,7 +812,7 @@ static int ath10k_pci_start_ce(struct ath10k *ar)
return -ENOMEM;
}
- compl->send_or_recv = HIF_CE_COMPLETE_FREE;
+ compl->state = ATH10K_PCI_COMPL_FREE;
list_add_tail(&compl->list, &pipe_info->compl_free);
}
}
@@ -911,12 +911,14 @@ static void ath10k_pci_process_ce(struct ath10k *ar)
list_del(&compl->list);
spin_unlock_bh(&ar_pci->compl_lock);
- if (compl->send_or_recv == HIF_CE_COMPLETE_SEND) {
+ switch (compl->state) {
+ case ATH10K_PCI_COMPL_SEND:
cb->tx_completion(ar,
compl->transfer_context,
compl->transfer_id);
send_done = 1;
- } else {
+ break;
+ case ATH10K_PCI_COMPL_RECV:
ret = ath10k_pci_post_rx_pipe(compl->pipe_info, 1);
if (ret) {
ath10k_warn("Unable to post recv buffer for pipe: %d\n",
@@ -943,9 +945,17 @@ static void ath10k_pci_process_ce(struct ath10k *ar)
nbytes,
skb->len + skb_tailroom(skb));
}
+ break;
+ case ATH10K_PCI_COMPL_FREE:
+ ath10k_warn("free completion cannot be processed\n");
+ break;
+ default:
+ ath10k_warn("invalid completion state (%d)\n",
+ compl->state);
+ break;
}
- compl->send_or_recv = HIF_CE_COMPLETE_FREE;
+ compl->state = ATH10K_PCI_COMPL_FREE;
/*
* Add completion back to the pipe's free list.
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index 871bb33..3093733 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -43,9 +43,15 @@ struct bmi_xfer {
u32 resp_len;
};
+enum ath10k_pci_compl_state {
+ ATH10K_PCI_COMPL_FREE = 0,
+ ATH10K_PCI_COMPL_SEND,
+ ATH10K_PCI_COMPL_RECV,
+};
+
struct ath10k_pci_compl {
struct list_head list;
- int send_or_recv;
+ enum ath10k_pci_compl_state state;
struct ce_state *ce_state;
struct hif_ce_pipe_info *pipe_info;
void *transfer_context;
@@ -54,11 +60,6 @@ struct ath10k_pci_compl {
unsigned int flags;
};
-/* compl_state.send_or_recv */
-#define HIF_CE_COMPLETE_FREE 0
-#define HIF_CE_COMPLETE_SEND 1
-#define HIF_CE_COMPLETE_RECV 2
-
/*
* PCI-specific Target state
*
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/4] ath10k: fix HTT service setup
From: Michal Kazior @ 2013-08-13 5:59 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373578-2180-1-git-send-email-michal.kazior@tieto.com>
The "disable credit flow" flag was set too late
and it never was in the HTC service request
message.
This patch prevents firmware from reporting
(useless) HTC credits for HTT service. HTT service
doesn't use nor need credits.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index ef3329e..7d445d3 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -772,16 +772,16 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
flags |= SM(tx_alloc, ATH10K_HTC_CONN_FLAGS_RECV_ALLOC);
- req_msg = &msg->connect_service;
- req_msg->flags = __cpu_to_le16(flags);
- req_msg->service_id = __cpu_to_le16(conn_req->service_id);
-
/* Only enable credit flow control for WMI ctrl service */
if (conn_req->service_id != ATH10K_HTC_SVC_ID_WMI_CONTROL) {
flags |= ATH10K_HTC_CONN_FLAGS_DISABLE_CREDIT_FLOW_CTRL;
disable_credit_flow_ctrl = true;
}
+ req_msg = &msg->connect_service;
+ req_msg->flags = __cpu_to_le16(flags);
+ req_msg->service_id = __cpu_to_le16(conn_req->service_id);
+
INIT_COMPLETION(htc->ctl_resp);
status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/4] ath10k: fixes
From: Michal Kazior @ 2013-08-13 5:59 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375949813-10969-1-git-send-email-michal.kazior@tieto.com>
Hi,
This patchset contains some bugfixes and
improvements.
v2:
* fix indentation
* use a comment instead of a no-op if clause
Michal Kazior (4):
ath10k: fix HTT service setup
ath10k: fix HTC endpoint worker starvation
ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
ath10k: plug possible memory leak in WMI
drivers/net/wireless/ath/ath10k/htc.c | 25 +++++++++++++------------
drivers/net/wireless/ath/ath10k/htc.h | 3 ++-
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++++++--
drivers/net/wireless/ath/ath10k/wmi.c | 1 +
4 files changed, 26 insertions(+), 15 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 2/4] ath10k: fix HTC endpoint worker starvation
From: Michal Kazior @ 2013-08-13 5:59 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373578-2180-1-git-send-email-michal.kazior@tieto.com>
HTC used a worker for each endpoint. This worked
until a slow host machine was flooded with massive
number of TX requests. HTT related worker would
remain active while WMI worker was starved. This
ended up with "could not send beacon" in AP mode.
It was even possible to see userspace being
starved.
The patch switches from using workers to using
tasklets for processing and submitting HTC frames
to HIF.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v2:
* fix indentation
drivers/net/wireless/ath/ath10k/htc.c | 17 +++++++++--------
drivers/net/wireless/ath/ath10k/htc.h | 3 ++-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 7d445d3..958e048 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -15,6 +15,7 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include <linux/interrupt.h>
#include "core.h"
#include "hif.h"
#include "debug.h"
@@ -210,10 +211,9 @@ static struct sk_buff *ath10k_htc_get_skb_credit_based(struct ath10k_htc *htc,
return skb;
}
-static void ath10k_htc_send_work(struct work_struct *work)
+static void ath10k_htc_send_task(unsigned long ptr)
{
- struct ath10k_htc_ep *ep = container_of(work,
- struct ath10k_htc_ep, send_work);
+ struct ath10k_htc_ep *ep = (struct ath10k_htc_ep *)ptr;
struct ath10k_htc *htc = ep->htc;
struct sk_buff *skb;
u8 credits = 0;
@@ -264,7 +264,7 @@ int ath10k_htc_send(struct ath10k_htc *htc,
skb_push(skb, sizeof(struct ath10k_htc_hdr));
spin_unlock_bh(&htc->tx_lock);
- queue_work(htc->ar->workqueue, &ep->send_work);
+ tasklet_schedule(&ep->send_task);
return 0;
}
@@ -283,7 +283,7 @@ static int ath10k_htc_tx_completion_handler(struct ath10k *ar,
* we recheck after the packet completes */
spin_lock_bh(&htc->tx_lock);
if (!ep->tx_credit_flow_enabled && !htc->stopped)
- queue_work(ar->workqueue, &ep->send_work);
+ tasklet_schedule(&ep->send_task);
spin_unlock_bh(&htc->tx_lock);
return 0;
@@ -308,7 +308,7 @@ static void ath10k_htc_flush_endpoint_tx(struct ath10k_htc *htc,
}
spin_unlock_bh(&htc->tx_lock);
- cancel_work_sync(&ep->send_work);
+ tasklet_kill(&ep->send_task);
}
/***********/
@@ -341,7 +341,7 @@ ath10k_htc_process_credit_report(struct ath10k_htc *htc,
ep->tx_credits += report->credits;
if (ep->tx_credits && !skb_queue_empty(&ep->tx_queue))
- queue_work(htc->ar->workqueue, &ep->send_work);
+ tasklet_schedule(&ep->send_task);
}
spin_unlock_bh(&htc->tx_lock);
}
@@ -602,7 +602,8 @@ static void ath10k_htc_reset_endpoint_states(struct ath10k_htc *htc)
skb_queue_head_init(&ep->tx_queue);
ep->htc = htc;
ep->tx_credit_flow_enabled = true;
- INIT_WORK(&ep->send_work, ath10k_htc_send_work);
+ tasklet_init(&ep->send_task, ath10k_htc_send_task,
+ (unsigned long)ep);
}
}
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index e1dd8c7..6afa175 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -24,6 +24,7 @@
#include <linux/skbuff.h>
#include <linux/semaphore.h>
#include <linux/timer.h>
+#include <linux/interrupt.h>
struct ath10k;
@@ -323,7 +324,7 @@ struct ath10k_htc_ep {
int tx_credits_per_max_message;
bool tx_credit_flow_enabled;
- struct work_struct send_work;
+ struct tasklet_struct send_task;
};
struct ath10k_htc_svc_tx_credits {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] ath10k: implement 802.3 SNAP rx decap type A-MSDU handling
From: Michal Kazior @ 2013-08-13 5:59 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373578-2180-1-git-send-email-michal.kazior@tieto.com>
This enables driver to rx another decapped a-msdu
frames. It should possibly help with throughputs
in some cases and reduce (or eliminate) number of
messages like this:
ath10k: error processing msdus -524
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v2:
* use a comment instead of a no-op if clause
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index e784c40..9bb0ae89 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -610,8 +610,7 @@ static int ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
RX_MPDU_START_INFO0_ENCRYPT_TYPE);
/* FIXME: No idea what assumptions are safe here. Need logs */
- if ((fmt == RX_MSDU_DECAP_RAW && skb->next) ||
- (fmt == RX_MSDU_DECAP_8023_SNAP_LLC)) {
+ if ((fmt == RX_MSDU_DECAP_RAW && skb->next)) {
ath10k_htt_rx_free_msdu_chain(skb->next);
skb->next = NULL;
return -ENOTSUPP;
@@ -659,6 +658,15 @@ static int ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
decap_hdr += roundup(crypto_len, 4);
}
+ /* When fmt == RX_MSDU_DECAP_8023_SNAP_LLC:
+ *
+ * SNAP 802.3 consists of:
+ * [dst:6][src:6][len:2][dsap:1][ssap:1][ctl:1][snap:5]
+ * [data][fcs:4].
+ *
+ * Since this overlaps with A-MSDU header (da, sa, len)
+ * there's nothing extra to do. */
+
if (fmt == RX_MSDU_DECAP_ETHERNET2_DIX) {
/* Ethernet2 decap inserts ethernet header in place of
* A-MSDU subframe header. */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/4] ath10k: plug possible memory leak in WMI
From: Michal Kazior @ 2013-08-13 5:59 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1376373578-2180-1-git-send-email-michal.kazior@tieto.com>
There was a possible memory leak when WMI command
queue reached it's limit. Command buffers were not
freed.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 55f90c7..775fedf 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -110,6 +110,7 @@ static int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb,
if (atomic_add_return(1, &ar->wmi.pending_tx_count) >
WMI_MAX_PENDING_TX_COUNT) {
/* avoid using up memory when FW hangs */
+ dev_kfree_skb(skb);
atomic_dec(&ar->wmi.pending_tx_count);
return -EBUSY;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3.11 v3] genetlink: fix family dump race
From: Johannes Berg @ 2013-08-13 7:04 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.
A similar bug was reported to me on an old kernel (3.4.47) but
the exact scenario that happened there is no longer possible,
on those kernels the first round wasn't locked either. Looking
at the current code I found the race described above, which had
also existed on the old kernel.
Cc: stable@vger.kernel.org
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/netlink/genetlink.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 2fd6dbe..6b6a03a 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -789,6 +789,10 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
struct net *net = sock_net(skb->sk);
int chains_to_skip = cb->args[0];
int fams_to_skip = cb->args[1];
+ bool need_locking = chains_to_skip || fams_to_skip;
+
+ if (need_locking)
+ genl_lock();
for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -810,6 +814,9 @@ errout:
cb->args[0] = i;
cb->args[1] = n;
+ if (need_locking)
+ genl_unlock();
+
return skb->len;
}
--
1.8.0
^ 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