* Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Dmitry Torokhov @ 2016-11-03 16:15 UTC (permalink / raw)
To: Xinming Hu
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, briannorris@google.com
In-Reply-To: <b9fed0716cfb46818b0a93a925e5d37a@SC-EXCH02.marvell.com>
On Thu, Nov 03, 2016 at 08:34:06AM +0000, Xinming Hu wrote:
> Hi Dmitry,
>
> > -----Original Message-----
> > From: linux-wireless-owner@vger.kernel.org
> > [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Dmitry Torokhov
> > Sent: 2016年10月28日 1:44
> > To: Amitkumar Karwar
> > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> > rajatja@google.com; briannorris@google.com
> > Subject: Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in
> > shutdown_drv
> >
> > Hi Amit,
> >
> > On Thu, Oct 27, 2016 at 02:42:40PM +0530, Amitkumar Karwar wrote:
> > > This variable is guarded by spinlock at all other places. This patch
> > > takes care of missing spinlock usage in mwifiex_shutdown_drv().
> >
> > Since in the previous discussion you stated that we inhibit interrupts and flush
> > the workqueue so that mwifiex_shutdown_drv() can't run simultaneously with
> > the main processing routine, why do we need this?
> >
> > Instead please remove call to mwifiex_shutdown_drv() in the main routine
> > and "if (adapter->mwifiex_processing)" check here.
> >
>
> mwifiex_main_process will be used from interrupt or workqueue.
> Now we have disabled interrupt and flush workqueue, so mwifiex_main_process won't be scheduled in the future.
> But mwifiex_main_process might just running in context of last interrupt, so we need wait current main_process complete in mwifiex_shutdown_drv.
synchronize_irq() is your friend then.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Jes Sorensen @ 2016-11-03 16:21 UTC (permalink / raw)
To: John Heenan; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <20161101072447.GA21575@cube>
John Heenan <john@zgus.com> writes:
> The rtl8723bu wireless IC shows evidence of a more agressive approach to
> power saving, powering down its RF side when there is no wireless
> interfacing but leaving USB interfacing intact. This makes the wireless
> IC more suitable for use in devices which need to keep their power use
> as low as practical, such as tablets and Surface Pro type devices.
>
> In effect this means that a full initialisation must be performed
> whenever a wireless interface is brought up. It also means that
> interpretations of power status from general wireless registers should
> not be relied on to influence an init sequence.
>
> The patch works by forcing a fuller initialisation and forcing it to
> occur more often in code paths (such as occurs during a low level
> authentication that initiates wireless interfacing).
>
> The initialisation sequence is now more consistent with code based
> directly on vendor code. For example while the vendor derived code
> interprets a register as indcating a particular powered state, it does
> not use this information to influence its init sequence.
>
> Only devices that use the rtl8723bu driver are affected by this patch.
>
> With this patch wpa_supplicant reliably and consistently connects with
> an AP. Before a workaround such as executing rmmod and modprobe before
> each call to wpa_supplicant worked with some distributions.
>
> Signed-off-by: John Heenan <john@zgus.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
I am at Linux Plumbers this week, so my response time is slow. Next week
I am on PTO, so I will not respond.
First of all, why do you keep CC'ing multiple mailing lists that do not
matter? This discussion belongs on linux-wireless not on netdev or lkml.
CC'ing Kalle directly is not going to get him to apply this broken patch
for you.
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 04141e5..ab2f2ef 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -3900,7 +3900,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> * initialized. First MAC returns 0xea, second MAC returns 0x00
> */
> - if (val8 == 0xea)
> + if (val8 == 0xea || priv->fops == &rtl8723bu_fops)
> macpower = false;
> else
> macpower = true;
Why oh why do you insist on not using the *standard* way of coping with
this? 'priv-rtl_chip' is used everywhere else, but you just have to do
something awful like this?
> @@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>
> ret = 0;
>
> + if(priv->fops == &rtl8723bu_fops) {
> + ret = rtl8xxxu_init_device(hw);
> + if (ret)
> + goto error_out;
> + }
> +
> init_usb_anchor(&priv->rx_anchor);
> init_usb_anchor(&priv->tx_anchor);
> init_usb_anchor(&priv->int_anchor);
Read Documentation/CodingStyle - as others already pointed you at.
> @@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> goto exit;
> }
>
> - ret = rtl8xxxu_init_device(hw);
> - if (ret)
> - goto exit;
> + if(priv->fops != &rtl8723bu_fops) {
> + ret = rtl8xxxu_init_device(hw);
> + if (ret)
> + goto exit;
> + }
>
> hw->wiphy->max_scan_ssids = 1;
> hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
Again coding style violation.
Second, I am NOT going to accept any patches that fundamentally changes
the init sequence of the code for just one device.
I already told you I want to find out *why* this matters, and what part
of rtl8xxxu_init_device() is the culprit. I want to understand the
actual problem, not just blindly move stuff around.
Jes
^ permalink raw reply
* Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Brian Norris @ 2016-11-03 18:27 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Xinming Hu, Amitkumar Karwar, linux-wireless@vger.kernel.org,
Cathy Luo, Nishant Sarmukadam, rajatja@google.com
In-Reply-To: <20161103161504.GA15366@dtor-ws>
On Thu, Nov 03, 2016 at 09:15:04AM -0700, Dmitry Torokhov wrote:
> On Thu, Nov 03, 2016 at 08:34:06AM +0000, Xinming Hu wrote:
> > > -----Original Message-----
> > > From: linux-wireless-owner@vger.kernel.org
> > > [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Dmitry Torokhov
> > >
> > > Instead please remove call to mwifiex_shutdown_drv() in the main routine
> > > and "if (adapter->mwifiex_processing)" check here.
> > >
> >
> > mwifiex_main_process will be used from interrupt or workqueue.
> > Now we have disabled interrupt and flush workqueue, so
> > mwifiex_main_process won't be scheduled in the future.
> > But mwifiex_main_process might just running in context of last
> > interrupt, so we need wait current main_process complete in
> > mwifiex_shutdown_drv.
>
> synchronize_irq() is your friend then.
Hmm, that sounds right, but IIUC, the "interrupt context" is actually
only used for SDIO, and for SDIO, the driver doesn't actually have
access to the IRQ number. The MMC/SDIO layer has some extra abstraction
around the IRQ. So this may be more difficult than it appears.
Do we need a sdio_synchronize_irq() API?
Brian
^ permalink raw reply
* Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Dmitry Torokhov @ 2016-11-03 18:48 UTC (permalink / raw)
To: Brian Norris
Cc: Xinming Hu, Amitkumar Karwar, linux-wireless@vger.kernel.org,
Cathy Luo, Nishant Sarmukadam, rajatja@google.com
In-Reply-To: <20161103182705.GA1153@google.com>
On Thu, Nov 3, 2016 at 12:27 PM, Brian Norris <briannorris@chromium.org> wrote:
> On Thu, Nov 03, 2016 at 09:15:04AM -0700, Dmitry Torokhov wrote:
>> On Thu, Nov 03, 2016 at 08:34:06AM +0000, Xinming Hu wrote:
>> > > -----Original Message-----
>> > > From: linux-wireless-owner@vger.kernel.org
>> > > [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Dmitry Torokhov
>> > >
>> > > Instead please remove call to mwifiex_shutdown_drv() in the main routine
>> > > and "if (adapter->mwifiex_processing)" check here.
>> > >
>> >
>> > mwifiex_main_process will be used from interrupt or workqueue.
>> > Now we have disabled interrupt and flush workqueue, so
>> > mwifiex_main_process won't be scheduled in the future.
>> > But mwifiex_main_process might just running in context of last
>> > interrupt, so we need wait current main_process complete in
>> > mwifiex_shutdown_drv.
>>
>> synchronize_irq() is your friend then.
>
> Hmm, that sounds right, but IIUC, the "interrupt context" is actually
> only used for SDIO, and for SDIO, the driver doesn't actually have
> access to the IRQ number. The MMC/SDIO layer has some extra abstraction
> around the IRQ. So this may be more difficult than it appears.
>
> Do we need a sdio_synchronize_irq() API?
Actually the ->disable_irq() method should be responsible for making
sure it does not complete while interrupt handler is running. As far
as I can see, for SDIO case, we end up calling sdio_card_irq_put()
which stops kernel thread and won't return while the thread is
running. For other interfaces we need to check. IIRC USB lacks
->disable_irq() altogether and this is something that shoudl be fixed
(by doing usb_kill_urb() at the minimum).
Thanks.
--
Dmitry
^ permalink raw reply
* Avery's notes from LPC2016 wireless track (Santa Fe)
From: Avery Pennarun @ 2016-11-03 20:43 UTC (permalink / raw)
To: linux-wireless
Hi all,
We talked about many topics at the Linux Plumbers' Conference in Santa
Fe on Tuesday. I took fairly detailed notes, which you can find at
the links below.
Fancy html commentable version:
https://docs.google.com/document/d/1Cr2bEf23wLkhiXXtyuBJtvvpb9xvCw7zsU-m1q1g4tA/edit
Less fancy version that (I think) will not ask for a Google account
(let me know if it gives you trouble):
https://docs.google.com/document/u/1/d/e/2PACX-1vQXbVQ-3zQt3Bcr3OWfwzbw_C49tTvf0ed8Hmf7b20E6tXc3a40tWZmPku49iGDE-OhgxNmO_lkkHEn/pub
Thanks, everyone, for the great discussion!
Have fun,
Avery
^ permalink raw reply
* Re: Avery's notes from LPC2016 wireless track (Santa Fe)
From: Barry Day @ 2016-11-03 21:55 UTC (permalink / raw)
To: Avery Pennarun; +Cc: linux-wireless
In-Reply-To: <CAHqTa-07wpAYdwTFKBm7QT6mn3PBOY5PiuSo6iZ6T9GgDd75ig@mail.gmail.com>
Thanks for that. Can I take this as meaning there won't be any videos?
I would like to have seen Jes Sorensen's talk on rtl8xxxu
Barry
^ permalink raw reply
* Re: Avery's notes from LPC2016 wireless track (Santa Fe)
From: Kathy Giori @ 2016-11-03 23:55 UTC (permalink / raw)
To: Avery Pennarun; +Cc: linux-wireless
In-Reply-To: <CAHqTa-07wpAYdwTFKBm7QT6mn3PBOY5PiuSo6iZ6T9GgDd75ig@mail.gmail.com>
On Thu, Nov 3, 2016 at 1:43 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> Hi all,
>
> We talked about many topics at the Linux Plumbers' Conference in Santa
> Fe on Tuesday. I took fairly detailed notes, which you can find at
> the links below.
Great notes Avery. Did you happen to take note of how many
participants there were? Or was the attendee list posted on the wiki
beforehand fairly accurate?
https://wireless.wiki.kernel.org/en/developers/summits/santa-fe-2016
Was there any talk about having more frequent "live" discussions of
these topics (via video conf or conf call or scheduled IRC), to help
overall collaboration without having to wait for the next f2f summit?
Mailing list interaction doesn't seem to elicit the same energy as
occurs over live dialog. Quarterly?
kathy
^ permalink raw reply
* Re: Avery's notes from LPC2016 wireless track (Santa Fe)
From: Avery Pennarun @ 2016-11-04 1:59 UTC (permalink / raw)
To: Barry Day, Avery Pennarun, linux-wireless
In-Reply-To: <20161103215525.GA25551@testbox>
On Thu, Nov 3, 2016 at 5:55 PM, Barry Day <briselec@gmail.com> wrote:
> Thanks for that. Can I take this as meaning there won't be any videos?
> I would like to have seen Jes Sorensen's talk on rtl8xxxu
As far as I know, no talks at this LPC were recorded.
^ permalink raw reply
* Re: Avery's notes from LPC2016 wireless track (Santa Fe)
From: Avery Pennarun @ 2016-11-04 2:01 UTC (permalink / raw)
To: Kathy Giori; +Cc: linux-wireless
In-Reply-To: <CAMowtuMeCYGY09SG-CrYYtgPAg3=P6sufBHLZdWmY3eodW0RwQ@mail.gmail.com>
On Thu, Nov 3, 2016 at 7:55 PM, Kathy Giori <kathy.giori@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 1:43 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> We talked about many topics at the Linux Plumbers' Conference in Santa
>> Fe on Tuesday. I took fairly detailed notes, which you can find at
>> the links below.
>
> Great notes Avery. Did you happen to take note of how many
> participants there were? Or was the attendee list posted on the wiki
> beforehand fairly accurate?
> https://wireless.wiki.kernel.org/en/developers/summits/santa-fe-2016
There were quite a few people not on the list. Google sent an
extra-large contingent last year. People estimated about 50% of the
wireless meeting were Googlers, which comes to maybe 15 out of around
30-ish. Google is doing a lot of (sometimes redundant :)) wireless
work lately.
> Was there any talk about having more frequent "live" discussions of
> these topics (via video conf or conf call or scheduled IRC), to help
> overall collaboration without having to wait for the next f2f summit?
> Mailing list interaction doesn't seem to elicit the same energy as
> occurs over live dialog. Quarterly?
It didn't come up. Honestly, it feels to me like 6 months is the
right cadence. A lot of work does happen in the background, such as
the fq_codel work (yay!) which was definitely launched by one or two
of these, but proceeded well afterwards.
Hope you're doing well at whatever you're doing now!
Have fun,
Avery
^ permalink raw reply
* RE: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Xinming Hu @ 2016-11-04 3:02 UTC (permalink / raw)
To: Dmitry Torokhov, Brian Norris
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com
In-Reply-To: <CAKdAkRQb-rnEqOxG6MLkvM068Up-+jvYqxKCNXM+OvPgn3kdwA@mail.gmail.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG1pdHJ5IFRvcm9raG92
IFttYWlsdG86ZG1pdHJ5LnRvcm9raG92QGdtYWlsLmNvbV0NCj4gU2VudDogMjAxNuW5tDEx5pyI
NOaXpSAyOjQ5DQo+IFRvOiBCcmlhbiBOb3JyaXMNCj4gQ2M6IFhpbm1pbmcgSHU7IEFtaXRrdW1h
ciBLYXJ3YXI7IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZzsgQ2F0aHkgTHVvOw0KPiBO
aXNoYW50IFNhcm11a2FkYW07IHJhamF0amFAZ29vZ2xlLmNvbQ0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIHYyIDIvNV0gbXdpZmlleDogdXNlIHNwaW5sb2NrIGZvciAnbXdpZmlleF9wcm9jZXNzaW5n
JyBpbg0KPiBzaHV0ZG93bl9kcnYNCj4gDQo+IE9uIFRodSwgTm92IDMsIDIwMTYgYXQgMTI6Mjcg
UE0sIEJyaWFuIE5vcnJpcyA8YnJpYW5ub3JyaXNAY2hyb21pdW0ub3JnPg0KPiB3cm90ZToNCj4g
PiBPbiBUaHUsIE5vdiAwMywgMjAxNiBhdCAwOToxNTowNEFNIC0wNzAwLCBEbWl0cnkgVG9yb2to
b3Ygd3JvdGU6DQo+ID4+IE9uIFRodSwgTm92IDAzLCAyMDE2IGF0IDA4OjM0OjA2QU0gKzAwMDAs
IFhpbm1pbmcgSHUgd3JvdGU6DQo+ID4+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+PiA+ID4gRnJvbTogbGludXgtd2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3JnDQo+ID4+
ID4gPiBbbWFpbHRvOmxpbnV4LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVo
YWxmIE9mIERtaXRyeQ0KPiA+PiA+ID4gVG9yb2tob3YNCj4gPj4gPiA+DQo+ID4+ID4gPiBJbnN0
ZWFkIHBsZWFzZSByZW1vdmUgY2FsbCB0byBtd2lmaWV4X3NodXRkb3duX2RydigpIGluIHRoZSBt
YWluDQo+ID4+ID4gPiByb3V0aW5lIGFuZCAiaWYgKGFkYXB0ZXItPm13aWZpZXhfcHJvY2Vzc2lu
ZykiIGNoZWNrIGhlcmUuDQo+ID4+ID4gPg0KPiA+PiA+DQo+ID4+ID4gbXdpZmlleF9tYWluX3By
b2Nlc3Mgd2lsbCBiZSB1c2VkIGZyb20gaW50ZXJydXB0IG9yIHdvcmtxdWV1ZS4NCj4gPj4gPiBO
b3cgd2UgaGF2ZSBkaXNhYmxlZCBpbnRlcnJ1cHQgYW5kIGZsdXNoIHdvcmtxdWV1ZSwgc28NCj4g
Pj4gPiBtd2lmaWV4X21haW5fcHJvY2VzcyB3b24ndCBiZSBzY2hlZHVsZWQgaW4gdGhlIGZ1dHVy
ZS4NCj4gPj4gPiBCdXQgbXdpZmlleF9tYWluX3Byb2Nlc3MgbWlnaHQganVzdCBydW5uaW5nIGlu
IGNvbnRleHQgb2YgbGFzdA0KPiA+PiA+IGludGVycnVwdCwgc28gd2UgbmVlZCB3YWl0IGN1cnJl
bnQgbWFpbl9wcm9jZXNzIGNvbXBsZXRlIGluDQo+ID4+ID4gbXdpZmlleF9zaHV0ZG93bl9kcnYu
DQo+ID4+DQo+ID4+IHN5bmNocm9uaXplX2lycSgpIGlzIHlvdXIgZnJpZW5kIHRoZW4uDQo+ID4N
Cj4gPiBIbW0sIHRoYXQgc291bmRzIHJpZ2h0LCBidXQgSUlVQywgdGhlICJpbnRlcnJ1cHQgY29u
dGV4dCIgaXMgYWN0dWFsbHkNCj4gPiBvbmx5IHVzZWQgZm9yIFNESU8sIGFuZCBmb3IgU0RJTywg
dGhlIGRyaXZlciBkb2Vzbid0IGFjdHVhbGx5IGhhdmUNCj4gPiBhY2Nlc3MgdG8gdGhlIElSUSBu
dW1iZXIuIFRoZSBNTUMvU0RJTyBsYXllciBoYXMgc29tZSBleHRyYQ0KPiA+IGFic3RyYWN0aW9u
IGFyb3VuZCB0aGUgSVJRLiBTbyB0aGlzIG1heSBiZSBtb3JlIGRpZmZpY3VsdCB0aGFuIGl0IGFw
cGVhcnMuDQo+ID4NCj4gPiBEbyB3ZSBuZWVkIGEgc2Rpb19zeW5jaHJvbml6ZV9pcnEoKSBBUEk/
DQo+IA0KPiBBY3R1YWxseSB0aGUgLT5kaXNhYmxlX2lycSgpIG1ldGhvZCBzaG91bGQgYmUgcmVz
cG9uc2libGUgZm9yIG1ha2luZyBzdXJlIGl0DQo+IGRvZXMgbm90IGNvbXBsZXRlIHdoaWxlIGlu
dGVycnVwdCBoYW5kbGVyIGlzIHJ1bm5pbmcuIEFzIGZhciBhcyBJIGNhbiBzZWUsIGZvcg0KPiBT
RElPIGNhc2UsIHdlIGVuZCB1cCBjYWxsaW5nIHNkaW9fY2FyZF9pcnFfcHV0KCkgd2hpY2ggc3Rv
cHMga2VybmVsIHRocmVhZA0KPiBhbmQgd29uJ3QgcmV0dXJuIHdoaWxlIHRoZSB0aHJlYWQgaXMg
cnVubmluZy4gRm9yIG90aGVyIGludGVyZmFjZXMgd2UgbmVlZCB0bw0KPiBjaGVjay4gSUlSQyBV
U0IgbGFja3MNCj4gLT5kaXNhYmxlX2lycSgpIGFsdG9nZXRoZXIgYW5kIHRoaXMgaXMgc29tZXRo
aW5nIHRoYXQgc2hvdWRsIGJlIGZpeGVkDQo+IChieSBkb2luZyB1c2Jfa2lsbF91cmIoKSBhdCB0
aGUgbWluaW11bSkuDQo+IA0KDQpUaGFua3MgZm9yIHRoZSBleHBsYWluLCB3aWxsIGtlZXAgdGhp
cyBjbGVhbnVwIHdvcmsuDQoNCj4gVGhhbmtzLg0KPiANCj4gLS0NCj4gRG1pdHJ5DQoNClJlZ2Fy
ZHMsDQpYaW5taW5nDQo=
^ permalink raw reply
* [PATCH] ath10k: Fix crash during rmmod when probe firmware fails
From: Mohammed Shafi Shajakhan @ 2016-11-04 8:38 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
__ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
Call Trace:
[<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
[ath10k_core]
[<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
[ath10k_core]
[<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
[<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
[<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
[<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
[<ffffffff817863af>] net_rx_action+0x20f/0x370
Reported-by: Ben Greear <greearb@candelatech.com>
Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..8187eb2 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2165,6 +2165,8 @@ err_free_firmware_files:
err_power_down:
ath10k_hif_power_down(ar);
+ napi_synchronize(&ar->napi);
+ napi_disable(&ar->napi);
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] mac80211: remove bogus skb vif assignment
From: Felix Fietkau @ 2016-11-04 9:27 UTC (permalink / raw)
To: linux-wireless; +Cc: toke, johannes
In-Reply-To: <20161104092754.91649-1-nbd@nbd.name>
The call to ieee80211_txq_enqueue overwrites the vif pointer with the
codel enqueue time, so setting it just before that call makes no sense.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/tx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c380e85..390b425 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1500,7 +1500,6 @@ static bool ieee80211_queue_skb(struct ieee80211_local *local,
struct sta_info *sta,
struct sk_buff *skb)
{
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct fq *fq = &local->fq;
struct ieee80211_vif *vif;
struct txq_info *txqi;
@@ -1525,8 +1524,6 @@ static bool ieee80211_queue_skb(struct ieee80211_local *local,
if (!txqi)
return false;
- info->control.vif = vif;
-
spin_lock_bh(&fq->lock);
ieee80211_txq_enqueue(local, txqi, skb);
spin_unlock_bh(&fq->lock);
--
2.10.1
^ permalink raw reply related
* [PATCH 3/3] mac80211: fix A-MSDU aggregation with fast-xmit + txq
From: Felix Fietkau @ 2016-11-04 9:27 UTC (permalink / raw)
To: linux-wireless; +Cc: toke, johannes
In-Reply-To: <20161104092754.91649-1-nbd@nbd.name>
A-MSDU aggregation alters the QoS header after a frame has been
enqueued, so it needs to be ready before enqueue and not overwritten
again afterwards
Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/tx.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 390b425..2c21b70 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3235,7 +3235,6 @@ static void ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data *sdata,
if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- *ieee80211_get_qos_ctl(hdr) = tid;
hdr->seq_ctrl = ieee80211_tx_next_seq(sta, tid);
} else {
info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
@@ -3360,6 +3359,11 @@ static bool ieee80211_xmit_fast(struct ieee80211_sub_if_data *sdata,
(tid_tx ? IEEE80211_TX_CTL_AMPDU : 0);
info->control.flags = IEEE80211_TX_CTRL_FAST_XMIT;
+ if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
+ tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
+ *ieee80211_get_qos_ctl(hdr) = tid;
+ }
+
__skb_queue_head_init(&tx.skbs);
tx.flags = IEEE80211_TX_UNICAST;
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] mac80211: update A-MPDU flag on tx dequeue
From: Felix Fietkau @ 2016-11-04 9:27 UTC (permalink / raw)
To: linux-wireless; +Cc: toke, johannes
The sequence number counter is used to derive the starting sequence
number. Since that counter is updated on tx dequeue, the A-MPDU flag
needs to be up to date at the tme of dequeue as well.
This patch prevents sending more A-MPDU frames after the session has
been terminated and also ensures that aggregation starts right after the
session has been established
Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/tx.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 62ccaf6..c380e85 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3451,6 +3451,11 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
goto begin;
}
+ if (test_bit(IEEE80211_TXQ_AMPDU, &txqi->flags))
+ info->flags |= IEEE80211_TX_CTL_AMPDU;
+ else
+ info->flags &= ~IEEE80211_TX_CTL_AMPDU;
+
if (info->control.flags & IEEE80211_TX_CTRL_FAST_XMIT) {
struct sta_info *sta = container_of(txq->sta, struct sta_info,
sta);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 1/3] mac80211: update A-MPDU flag on tx dequeue
From: Toke Høiland-Jørgensen @ 2016-11-04 11:46 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, johannes
In-Reply-To: <20161104092754.91649-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> The sequence number counter is used to derive the starting sequence
> number. Since that counter is updated on tx dequeue, the A-MPDU flag
> needs to be up to date at the tme of dequeue as well.
>
> This patch prevents sending more A-MPDU frames after the session has
> been terminated and also ensures that aggregation starts right after the
> session has been established
Makes sense. Suppose there's no reason why the session couldn't be
started/ended while packets were queued.
Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH 2/3] mac80211: remove bogus skb vif assignment
From: Toke Høiland-Jørgensen @ 2016-11-04 11:47 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, johannes
In-Reply-To: <20161104092754.91649-2-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> The call to ieee80211_txq_enqueue overwrites the vif pointer with the
> codel enqueue time, so setting it just before that call makes no
> sense.
Yeah, I think this was leftover from earlier version when the flow was
different. Or maybe I just missed it...
Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
-Toke
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: fix A-MSDU aggregation with fast-xmit + txq
From: Toke Høiland-Jørgensen @ 2016-11-04 11:49 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, johannes
In-Reply-To: <20161104092754.91649-3-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> A-MSDU aggregation alters the QoS header after a frame has been
> enqueued, so it needs to be ready before enqueue and not overwritten
> again afterwards
Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower
From: Jes Sorensen @ 2016-11-04 13:56 UTC (permalink / raw)
To: Joe Perches; +Cc: John Heenan, Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1478162497.1924.16.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
>> Code is 80 characters wide, and comments are /* */ never the ugly C++
>> crap.
>
> You might look at the recent Linus Torvalds authored commit
> 5e467652ffef (?printk: re-organize log_output() to be more legible")
> which does both of those: c99 // comments and > 80 columns.
>
> Absolutes are for zealots.
What Linus does in his code, is totally up to him. What I pull into the
driver that *I* maintain, is up to me. It is perfectly normal to expect
submitters to respect the coding style of the piece of code they are
trying to edit.
Jes
^ permalink raw reply
* Re: ATH10K VLAN firmware issue
From: Bruno Antunes @ 2016-11-04 14:13 UTC (permalink / raw)
To: voncken
Cc: ath10k@lists.infradead.org, linux-wireless,
OpenWrt Development List
In-Reply-To: <079401d132a6$7e7e2050$7b7a60f0$@acksys.fr>
Hi all,
Old thread but I think the issue is still present.
I'm running a setup with VLANs with WDS and ath10k cards.
To make it work both cards must be loaded in rawmode, AP
and Sta, and with no security.
I'm using a OpenWrt trunk r49941 and the most recent firmware,
10.2.4.70.58, from Kalle ath10k firmware tree.
Although it works the throughput is very bad.
Are there any alternatives to improve the throughput.
Best Regards,
Bruno
On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr> wrote:
>
>
>> -----Message d'origine-----
>> De : Ben Greear [mailto:greearb@candelatech.com]
>> Envoy=C3=A9 : mercredi 9 d=C3=A9cembre 2015 16:34
>> =C3=80 : Cedric VONCKEN; ath10k@lists.infradead.org; linux-wireless
>> Objet : Re: ATH10K VLAN firmware issue
>>
>> This only happens when you use STA + WDS, or is .1q broken for you in
>> other cases as well?
>
> No, this issue occurs in all modes (STA, STA + WDS, AP).
>
> Thanks
>
> Cedric.
>
>>
>> Thanks,
>> Ben
>>
>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>> > I'm testing to transmit frame with 802.1q tag (VLAN).
>> >
>> > My client is set in STA + WDS and the netdev is bridged with eth0.
>> > I have a computer with vlan configuration set connected to the STA
>> > eth0.
>> >
>> > If I try to transmit frames with 802.1q tag, the frames are not
> sent.
>> > I checked with wireless sniffer, and I don't see the frame with VL=
AN
>> > tag (the frames without VLAN tag are sent).
>> >
>> > I tested with firmware 10.2.4.70.14-2 from kale github,
>> > 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from
>> > openwrt, and in all cases I have the same issue.
>> >
>> > Thanks for your help.
>> >
>> >
>> > --
>> > 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
>> >
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>
> --
> 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
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Bruno Antunes @ 2016-11-04 14:41 UTC (permalink / raw)
To: Mauro Mozzarelli
Cc: OpenWrt Development List, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <27f802e7-79c5-a17f-1883-88e62a6520ef@ezplanet.net>
On 4 November 2016 at 14:18, Mauro Mozzarelli <openwrt@ezplanet.net> wrote:
> Since the capability is implemented in software you might be testing the
> limit of your router's CPU i/o speed.
By loading the module in rawmode?
The AP is an APU and Sta is an APU2.
>
>
>
> On 04/11/16 14:13, Bruno Antunes wrote:
>>
>> Hi all,
>>
>> Old thread but I think the issue is still present.
>>
>> I'm running a setup with VLANs with WDS and ath10k cards.
>>
>> To make it work both cards must be loaded in rawmode, AP
>> and Sta, and with no security.
>>
>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>
>> Although it works the throughput is very bad.
>> Are there any alternatives to improve the throughput.
>>
>> Best Regards,
>> Bruno
>>
>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr> wrote:
>>>
>>>
>>>> -----Message d'origine-----
>>>> De : Ben Greear [mailto:greearb@candelatech.com]
>>>> Envoy=C3=A9 : mercredi 9 d=C3=A9cembre 2015 16:34
>>>> =C3=80 : Cedric VONCKEN; ath10k@lists.infradead.org; linux-wireless
>>>> Objet : Re: ATH10K VLAN firmware issue
>>>>
>>>> This only happens when you use STA + WDS, or is .1q broken for you in
>>>> other cases as well?
>>>
>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>
>>> Thanks
>>>
>>> Cedric.
>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>
>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>
>>>>> My client is set in STA + WDS and the netdev is bridged with eth=
0.
>>>>> I have a computer with vlan configuration set connected to the S=
TA
>>>>> eth0.
>>>>>
>>>>> If I try to transmit frames with 802.1q tag, the frames are not
>>>
>>> sent.
>>>>>
>>>>> I checked with wireless sniffer, and I don't see the frame with
>>>>> VLAN
>>>>> tag (the frames without VLAN tag are sent).
>>>>>
>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from
>>>>> openwrt, and in all cases I have the same issue.
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc http://www.candelatech.com
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: yu-chieh kung @ 2016-11-04 17:28 UTC (permalink / raw)
To: Bruno Antunes
Cc: Mauro Mozzarelli, OpenWrt Development List,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CABUTiXUBfHB5RiZ8=ODzrK4-rCBJZ8QqZuZhMK_J7c7haFMEcw@mail.gmail.com>
I met the same problem before,
if i modify the 1q header to other value (0xaa00) before go into firmware.
I can capture the packet in the air
I think the vlan packet is dropped in firmware.
2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
> On 4 November 2016 at 14:18, Mauro Mozzarelli <openwrt@ezplanet.net> wrot=
e:
>> Since the capability is implemented in software you might be testing the
>> limit of your router's CPU i/o speed.
>
> By loading the module in rawmode?
>
> The AP is an APU and Sta is an APU2.
>
>>
>>
>>
>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>
>>> Hi all,
>>>
>>> Old thread but I think the issue is still present.
>>>
>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>
>>> To make it work both cards must be loaded in rawmode, AP
>>> and Sta, and with no security.
>>>
>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>
>>> Although it works the throughput is very bad.
>>> Are there any alternatives to improve the throughput.
>>>
>>> Best Regards,
>>> Bruno
>>>
>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr> wrote:
>>>>
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Ben Greear [mailto:greearb@candelatech.com]
>>>>> Envoy=C3=A9 : mercredi 9 d=C3=A9cembre 2015 16:34
>>>>> =C3=80 : Cedric VONCKEN; ath10k@lists.infradead.org; linux-wireless
>>>>> Objet : Re: ATH10K VLAN firmware issue
>>>>>
>>>>> This only happens when you use STA + WDS, or is .1q broken for you i=
n
>>>>> other cases as well?
>>>>
>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>
>>>> Thanks
>>>>
>>>> Cedric.
>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>
>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>
>>>>>> My client is set in STA + WDS and the netdev is bridged with et=
h0.
>>>>>> I have a computer with vlan configuration set connected to the =
STA
>>>>>> eth0.
>>>>>>
>>>>>> If I try to transmit frames with 802.1q tag, the frames are not
>>>>
>>>> sent.
>>>>>>
>>>>>> I checked with wireless sniffer, and I don't see the frame with
>>>>>> VLAN
>>>>>> tag (the frames without VLAN tag are sent).
>>>>>>
>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from
>>>>>> openwrt, and in all cases I have the same issue.
>>>>>>
>>>>>> Thanks for your help.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-wireless" in the body of a message to majordomo@vger.kernel.or=
g
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>> --
>>>>> Ben Greear <greearb@candelatech.com>
>>>>> Candela Technologies Inc http://www.candelatech.com
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-wirele=
ss"
>>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: ATH10K VLAN firmware issue
From: Valo, Kalle @ 2016-11-04 21:17 UTC (permalink / raw)
To: Bruno Antunes
Cc: voncken, OpenWrt Development List, linux-wireless,
ath10k@lists.infradead.org
In-Reply-To: <CABUTiXWg3t5qK6O5ooDE+4=Xk3Msybs5mu9+tQm_Bb0wdSrfWQ@mail.gmail.com>
Bruno Antunes <baantunes@gmail.com> writes:
> Old thread but I think the issue is still present.
>
> I'm running a setup with VLANs with WDS and ath10k cards.
>
> To make it work both cards must be loaded in rawmode, AP
> and Sta, and with no security.
>
> I'm using a OpenWrt trunk r49941 and the most recent firmware,
> 10.2.4.70.58, from Kalle ath10k firmware tree.
>
> Although it works the throughput is very bad.
> Are there any alternatives to improve the throughput.
Can someone file a bug to bugzilla about this so that all the info is
properly stored? The more comprehensive the report is the better.
https://bugzilla.kernel.org/
--=20
Kalle Valo=
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-04 21:50 UTC (permalink / raw)
To: yu-chieh kung, Bruno Antunes
Cc: Mauro Mozzarelli, OpenWrt Development List,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAGJdtRCKidEfDF7sc4BRGSfOTmcGJUJ4KZt0xU1vj4bGAnuu1Q@mail.gmail.com>
I can reproduce this in my CT firmware. I'll see if I can fix it,
but for stock firmware, it might be that changing the driver to use Ethernet packet type
of native-wifi would make .1q vlans work.
Thanks,
Ben
On 11/04/2016 10:28 AM, yu-chieh kung wrote:
> I met the same problem before,
> if i modify the 1q header to other value (0xaa00) before go into firmware.
> I can capture the packet in the air
> I think the vlan packet is dropped in firmware.
>
> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>> On 4 November 2016 at 14:18, Mauro Mozzarelli <openwrt@ezplanet.net> wrote:
>>> Since the capability is implemented in software you might be testing the
>>> limit of your router's CPU i/o speed.
>>
>> By loading the module in rawmode?
>>
>> The AP is an APU and Sta is an APU2.
>>
>>>
>>>
>>>
>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Old thread but I think the issue is still present.
>>>>
>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>
>>>> To make it work both cards must be loaded in rawmode, AP
>>>> and Sta, and with no security.
>>>>
>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>
>>>> Although it works the throughput is very bad.
>>>> Are there any alternatives to improve the throughput.
>>>>
>>>> Best Regards,
>>>> Bruno
>>>>
>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr> wrote:
>>>>>
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Ben Greear [mailto:greearb@candelatech.com]
>>>>>> Envoyé : mercredi 9 décembre 2015 16:34
>>>>>> À : Cedric VONCKEN; ath10k@lists.infradead.org; linux-wireless
>>>>>> Objet : Re: ATH10K VLAN firmware issue
>>>>>>
>>>>>> This only happens when you use STA + WDS, or is .1q broken for you in
>>>>>> other cases as well?
>>>>>
>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>
>>>>> Thanks
>>>>>
>>>>> Cedric.
>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>
>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>
>>>>>>> My client is set in STA + WDS and the netdev is bridged with eth0.
>>>>>>> I have a computer with vlan configuration set connected to the STA
>>>>>>> eth0.
>>>>>>>
>>>>>>> If I try to transmit frames with 802.1q tag, the frames are not
>>>>>
>>>>> sent.
>>>>>>>
>>>>>>> I checked with wireless sniffer, and I don't see the frame with
>>>>>>> VLAN
>>>>>>> tag (the frames without VLAN tag are sent).
>>>>>>>
>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from
>>>>>>> openwrt, and in all cases I have the same issue.
>>>>>>>
>>>>>>> Thanks for your help.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>> --
>>>>>> Ben Greear <greearb@candelatech.com>
>>>>>> Candela Technologies Inc http://www.candelatech.com
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-04 22:23 UTC (permalink / raw)
To: yu-chieh kung, Bruno Antunes
Cc: Mauro Mozzarelli, linux-wireless@vger.kernel.org,
OpenWrt Development List, ath10k@lists.infradead.org
In-Reply-To: <c58ffbe0-c305-3282-34e9-98814c6f0d14@candelatech.com>
The bug appears that vlan-tx-stripping is unconditionally enabled in
at least my firmware. I have re-compiled w/out that flag set, and it appears
to work for me.
Please download this firmware, rename it firmware-2.bin, make sure you remove/rename
any firmware-5.bin (etc) so mine will load, and see if that fixes your problem.
Please note that it is very likely you will have to use same MAC address
for the VLAN devices that the underlying station uses in order for this to work.
https://www.candelatech.com/downloads/tmp/firmware-2-full-community.bin
Thanks,
Ben
On 11/04/2016 02:50 PM, Ben Greear wrote:
> I can reproduce this in my CT firmware. I'll see if I can fix it,
> but for stock firmware, it might be that changing the driver to use Ethernet packet type
> of native-wifi would make .1q vlans work.
>
> Thanks,
> Ben
>
> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>> I met the same problem before,
>> if i modify the 1q header to other value (0xaa00) before go into firmware.
>> I can capture the packet in the air
>> I think the vlan packet is dropped in firmware.
>>
>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>> On 4 November 2016 at 14:18, Mauro Mozzarelli <openwrt@ezplanet.net> wrote:
>>>> Since the capability is implemented in software you might be testing the
>>>> limit of your router's CPU i/o speed.
>>>
>>> By loading the module in rawmode?
>>>
>>> The AP is an APU and Sta is an APU2.
>>>
>>>>
>>>>
>>>>
>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Old thread but I think the issue is still present.
>>>>>
>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>
>>>>> To make it work both cards must be loaded in rawmode, AP
>>>>> and Sta, and with no security.
>>>>>
>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>
>>>>> Although it works the throughput is very bad.
>>>>> Are there any alternatives to improve the throughput.
>>>>>
>>>>> Best Regards,
>>>>> Bruno
>>>>>
>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr> wrote:
>>>>>>
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com]
>>>>>>> Envoyé : mercredi 9 décembre 2015 16:34
>>>>>>> À : Cedric VONCKEN; ath10k@lists.infradead.org; linux-wireless
>>>>>>> Objet : Re: ATH10K VLAN firmware issue
>>>>>>>
>>>>>>> This only happens when you use STA + WDS, or is .1q broken for you in
>>>>>>> other cases as well?
>>>>>>
>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Cedric.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Ben
>>>>>>>
>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>
>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>
>>>>>>>> My client is set in STA + WDS and the netdev is bridged with eth0.
>>>>>>>> I have a computer with vlan configuration set connected to the STA
>>>>>>>> eth0.
>>>>>>>>
>>>>>>>> If I try to transmit frames with 802.1q tag, the frames are not
>>>>>>
>>>>>> sent.
>>>>>>>>
>>>>>>>> I checked with wireless sniffer, and I don't see the frame with
>>>>>>>> VLAN
>>>>>>>> tag (the frames without VLAN tag are sent).
>>>>>>>>
>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2 from
>>>>>>>> openwrt, and in all cases I have the same issue.
>>>>>>>>
>>>>>>>> Thanks for your help.
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>>
>>>>>>> --
>>>>>>> Ben Greear <greearb@candelatech.com>
>>>>>>> Candela Technologies Inc http://www.candelatech.com
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> openwrt-devel mailing list
>>>>> openwrt-devel@lists.openwrt.org
>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Bayesian rate control
From: Adrian Chadd @ 2016-11-05 5:09 UTC (permalink / raw)
To: Johannes Berg
Cc: Björn Smedman, linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <1477461362.4059.17.camel@sipsolutions.net>
Hi,
On 25 October 2016 at 22:56, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> The intel 7260 and later parts also allow user controllable rate
>> control and provide transmit completion feedback, but I don't know
>> whether it's enough for your needs.
>
> Perhaps. However, existing rate control is *very* tightly coupled to
> the driver, and it'd be fairly pointless to disentangle just for the
> sake of playing with a rate control algorithm.
>
> Also, the device doesn't support per-frame control nor any kind of
> sampling-with-table-fallback, only the rate table that you give to the
> device and update.
Hi,
But there is a per-descriptor TX rate table entry in the driver.
FreeBSD uses it to implement its rate control for the intel drivers.
What am I missing? :)
>
> Btw, mac80211_hwsim with wmediumd doing some medium simulation might
> also be something to look at for just extending to VHT.
>
> And come to think of it, there's this new driver Felix et al have been
> working on, mt7601u, which also should support proper rate control
> APIs.
-adrian
^ 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