* Re: support for QCA9377 SDIO (ath10k or ath6kl)
From: Valo, Kalle @ 2016-09-09 12:35 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath10k@lists.infradead.org, ath6kl@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <CAFBinCDnmEuSEKofHQy3SkKuewL+cjuxhibj7O71ASL0yfH_Ew@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> is there any support for the SDIO chips QCA9377 (and QCA9378) planned?
> Would these be supported by ath10k or ath6kl or is a completely new
> driver needed?
I'm not familiar with the details of QCA9377 SDIO firmware but I assume
ath10k would be the best option for supporting it. We split from the
beginning the core code (ath10k_core.ko) and the PCI code
(ath10k_pci.ko) to make it easier to add new bus support.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] ath10k: advertize hardware packet loss mechanism
From: Valo, Kalle @ 2016-09-09 12:27 UTC (permalink / raw)
To: kbuild test robot
Cc: Manoharan, Rajkumar, linux-wireless@vger.kernel.org,
kbuild-all@01.org, ath10k@lists.infradead.org,
rmanohar@codeaurora.org
In-Reply-To: <201609061655.E4ZdBCGt%fengguang.wu@intel.com>
kbuild test robot <lkp@intel.com> writes:
> Hi Rajkumar,
>
> [auto build test ERROR on ath6kl/ath-next]
> [also build test ERROR on v4.8-rc5 next-20160906]
> [if your patch is applied to the wrong git tree, please drop us a note to=
help improve the system]
> [Suggest to use git(>=3D2.9.0) format-patch --base=3D<commit> (or --base=
=3Dauto for convenience) to record what (public, well-known) commit your pa=
tch series was built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
>
> url: https://github.com/0day-ci/linux/commits/Rajkumar-Manoharan/ath10=
k-advertize-hardware-packet-loss-mechanism/20160906-151148
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath=
-next
> config: i386-randconfig-x008-201636 (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=3Di386=20
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from drivers/net/wireless/ath/ath10k/mac.h:21:0,
> from drivers/net/wireless/ath/ath10k/mac.c:18:
> drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_registe=
r':
>>> include/net/mac80211.h:2206:57: error: 'IEEE80211_HW_REPORTS_LOW_ACK' u=
ndeclared (first use in this function)
> #define ieee80211_hw_set(hw, flg) _ieee80211_hw_set(hw, IEEE80211_HW_=
##flg)
> ^
>>> drivers/net/wireless/ath/ath10k/mac.c:7884:2: note: in expansion of mac=
ro 'ieee80211_hw_set'
> ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
> ^~~~~~~~~~~~~~~~
> include/net/mac80211.h:2206:57: note: each undeclared identifier is re=
ported only once for each function it appears in
> #define ieee80211_hw_set(hw, flg) _ieee80211_hw_set(hw, IEEE80211_HW_=
##flg)
> ^
>>> drivers/net/wireless/ath/ath10k/mac.c:7884:2: note: in expansion of mac=
ro 'ieee80211_hw_set'
> ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
> ^~~~~~~~~~~~~~~~
This is expected as this depends on a mac80211 patch which is not
applied yet.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [1/2] carl9170: Fix wrong completion usage
From: Kalle Valo @ 2016-09-09 12:16 UTC (permalink / raw)
To: Daniel Wagner
Cc: Kalle Valo, Christian Lamparter, Luis R . Rodriguez, ath10k,
linux-wireless, netdev, linux-kernel, Daniel Wagner
In-Reply-To: <1471525926-20384-2-git-send-email-wagi@monom.org>
Daniel Wagner <wagi@monom.org> wrote:
> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
>
> carl9170_usb_stop() is used from several places to flush and cleanup any
> pending work. The normal pattern is to send a request and wait for the
> irq handler to call complete(). The completion is not reinitialized
> during normal operation and as the old comment indicates it is important
> to keep calls to wait_for_completion_timeout() and complete() balanced.
>
> Calling complete_all() brings this equilibirum out of balance and needs
> to be fixed by a reinit_completion(). But that opens a small race
> window. It is possible that the sequence of complete_all(),
> reinit_completion() is faster than the wait_for_completion_timeout() can
> do its work. The wake up is not lost but the done counter test is after
> reinit_completion() has been executed. The only reason we don't see
> carl9170_exec_cmd() hang forever is we use the timeout version of
> wait_for_copletion().
>
> Let's fix this by reinitializing the completion (that is just setting
> done counter to 0) just before we send out an request. Now,
> carl9170_usb_stop() can be sure a complete() call is enough to make
> progess since there is only one waiter at max. This is a common pattern
> also seen in various drivers which use completion.
>
> Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Thanks, 1 patch applied to ath-next branch of ath.git:
78a9e170388b carl9170: Fix wrong completion usage
--
Sent by pwcli
https://patchwork.kernel.org/patch/9287819/
^ permalink raw reply
* Re: ath6kl: Allow the radio to report 0 dbm txpower without timing out
From: Kalle Valo @ 2016-09-09 12:14 UTC (permalink / raw)
To: Eric Bentley; +Cc: ath6kl, linux-wireless
In-Reply-To: <1472537779-3723-1-git-send-email-eric.bentley@lairdtech.com>
Eric Bentley <eric.bentley@lairdtech.com> wrote:
> The ath6kl driver attempts to get the txpower value from the radio by first
> clearing the existing stored value and then watching the value to become
> non-zero.
>
> APs allow setting client power to values from -127..127, but this radio
> is not capable of setting values less then 0 and so will report txpower
> as 0dbm for both negative and 0 client power values.
>
> When the radio has txpower set to 0dbm txpower (equivalent to 1mw) the
> ath6kl_cfg80211_get_txpower() function will remain in the
> wait_event_interruptible_timeout() loop waiting for the value to be
> non-zero, and will eventually timeout. This results in a 5 second delay in
> response. However, the correct value of zero is eventually returned.
>
> The 6004 defaults to 63dbm which is then limited by regulatory and
> hardware limits with max of 18dbm (6003 max is 16dbm), therefore we can
> use values larger then these to be able to determine when the value has
> been updated.
>
> To correct the issue, set the value to a nonsensical value (255) and wait
> for it to change to the valid value.
Thanks, 1 patch applied to ath-next branch of ath.git:
cabd34d0e9c4 ath6kl: Allow the radio to report 0 dbm txpower without timing out
--
Sent by pwcli
https://patchwork.kernel.org/patch/9304907/
^ permalink raw reply
* Re: ath6kl: enable firmware crash dumps on the AR6004
From: Kalle Valo @ 2016-09-09 12:13 UTC (permalink / raw)
To: engineering; +Cc: ath6kl, linux-wireless
In-Reply-To: <1470257023-6747-1-git-send-email-dan.kephart@lairdtech.com>
engineering@keppy.com wrote:
> From: Dan Kephart <dan.kephart@lairdtech.com>
>
> The firmware crash dumps on the 6004 are the same as the 6003. Remove the
> statement guarding it from dumping on the 6004. Renamed the
> REG_DUMP_COUNT_AR6003 to reflect support on both chips.
>
> Signed-off-by: Dan Kephart <dan.kephart@lairdtech.com>
> Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
f3fa63144482 ath6kl: enable firmware crash dumps on the AR6004
--
Sent by pwcli
https://patchwork.kernel.org/patch/9262289/
^ permalink raw reply
* Re: ath9k: remove repetitions of mask array size
From: Kalle Valo @ 2016-09-09 12:12 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Oleksij Rempel, ath9k-devel, Bob Copeland
In-Reply-To: <1460818477-22785-1-git-send-email-me@bobcopeland.com>
Bob Copeland <me@bobcopeland.com> wrote:
> The constant "123", which is the number of elements in
> mask_m / mask_p, is repeated several times in this function.
>
> Replace memsets with array initialization, and replace a loop
> conditional with ARRAY_SIZE() so that we don't repeat ourselves.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Thanks, 1 patch applied to ath-next branch of ath.git:
b5182e157d3a ath9k: remove repetitions of mask array size
--
Sent by pwcli
https://patchwork.kernel.org/patch/8861641/
^ permalink raw reply
* Re: ath10k: fix reporting channel survey data
From: Kalle Valo @ 2016-09-09 12:11 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: ath10k, Ashok Raj Nagarajan, arnagara, linux-wireless
In-Reply-To: <1472794193-20774-1-git-send-email-arnagara@qti.qualcomm.com>
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> wrote:
> When user requests for survey dump data, driver is providing wrong survey
> information. This information we sent is the survey data that we have
> collected during previous user request.
>
> This issue occurs because we request survey dump for wrong channel. With
> this change, we correctly display the correct and current survey
> information to userspace.
>
> Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information")
> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
77eb3d693182 ath10k: fix reporting channel survey data
--
Sent by pwcli
https://patchwork.kernel.org/patch/9310467/
^ permalink raw reply
* Re: ath10k: Remove unnecessary error code assignment
From: Kalle Valo @ 2016-09-09 12:10 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1472746416-23869-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> The error assigned does not seems to be used anywhere,
> fixes nothing just a small cleanup
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
fe79f6314a71 ath10k: remove unnecessary error code assignment
--
Sent by pwcli
https://patchwork.kernel.org/patch/9309397/
^ permalink raw reply
* Re: [1/2] ath9k: use ieee80211_tx_status_noskb where possible
From: Kalle Valo @ 2016-09-09 12:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20160804214940.78476-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> It removes the need for undoing the padding changes to skb->data and it
> improves performance by eliminating one tx status lookup per MPDU in the
> status path. It is also useful for preparing a follow-up fix to better
> handle powersave filtering.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Thanks, 2 patches applied to ath-next branch of ath.git:
d94a461d7a7d ath9k: use ieee80211_tx_status_noskb where possible
315c457ff123 ath9k: improve powersave filter handling
--
Sent by pwcli
https://patchwork.kernel.org/patch/9264385/
^ permalink raw reply
* Re: ath10k: fix throughput regression in multi client mode
From: Kalle Valo @ 2016-09-09 12:07 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160829081613.1474-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing
> severe throughput drop in multi client mode. This issue is originally
> reported in veriwave setup with 50 clients with TCP downlink traffic.
> While increasing number of clients, the average throughput drops
> gradually. With 50 clients, the combined peak throughput is decreased
> to 98 Mbps whereas reverting given commit restored it to 550 Mbps.
>
> Processing txqs for every tx completion is causing overhead. Ideally for
> management frame tx completion, pending txqs processing can be avoided.
> The change partly reverts the commit "ath10k: improve tx scheduling".
> Processing pending txqs after all skbs tx completion will yeild enough
> room to burst tx frames.
>
> Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling")
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
18f53fe0f303 ath10k: fix throughput regression in multi client mode
--
Sent by pwcli
https://patchwork.kernel.org/patch/9303279/
^ permalink raw reply
* Re: [v3] ath10k: implement NAPI support
From: Kalle Valo @ 2016-09-09 12:05 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160826102250.24174-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Add NAPI support for rx and tx completion. NAPI poll is scheduled
> from interrupt handler. The design is as below
>
> - on interrupt
> - schedule napi and mask interrupts
> - on poll
> - process all pipes (no actual Tx/Rx)
> - process Rx within budget
> - if quota exceeds budget reschedule napi poll by returning budget
> - process Tx completions and update budget if necessary
> - process Tx fetch indications (pull-push)
> - push any other pending Tx (if possible)
> - before resched or napi completion replenish htt rx ring buffer
> - if work done < budget, complete napi poll and unmask interrupts
>
> This change also get rid of two tasklets (intr_tq and txrx_compl_task).
>
> Measured peak throughput with NAPI on IPQ4019 platform in controlled
> environment. No noticeable reduction in throughput is seen and also
> observed improvements in CPU usage. Approx. 15% CPU usage got reduced
> in UDP uplink case.
>
> DL: AP DUT Tx
> UL: AP DUT Rx
>
> IPQ4019 (avg. cpu usage %)
>
> ========
> TOT +NAPI
> =========== =============
> TCP DL 644 Mbps (42%) 645 Mbps (36%)
> TCP UL 673 Mbps (30%) 675 Mbps (26%)
> UDP DL 682 Mbps (49%) 680 Mbps (49%)
> UDP UL 720 Mbps (28%) 717 Mbps (11%)
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
3c97f5de1f28 ath10k: implement NAPI support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9301091/
^ permalink raw reply
* Re: mwifiex: PCIe8997 chip specific handling
From: Kalle Valo @ 2016-09-09 11:27 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <5c381ec576c54a7fad54e7a23a060e29@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> Hi Kalle,
>
>> -----Original Message-----
>> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] On Behalf Of Kalle Valo
>> Sent: Friday, September 09, 2016 2:45 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> Amitkumar Karwar
>> Subject: Re: mwifiex: PCIe8997 chip specific handling
>>
>> Amitkumar Karwar <akarwar@marvell.com> wrote:
>> > The patch corrects the revision id register and uses it along with
>> > magic value and chip version registers to download appropriate
>> > firmware image.
>> >
>> > PCIe8997 Z chipset variant code has been removed, as it won't be used
>> > in production.
>> >
>> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>>
>> Does apply, please rebase:
>>
>> Applying: mwifiex: PCIe8997 chip specific handling
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/marvell/mwifiex/pcie.c).
>> Repository lacks necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0001 mwifiex: PCIe8997 chip specific handling
>>
>
> The patch now smoothly applies to top of the tree. It had a dependency
> with "mwifiex: add PCIe function level reset support" which is merged.
> Let me know if there is still a problem.
Ok, I applied it now. But if there's a dependency to another patch
please document it after the "---" line, a lot easier that way.
--
Kalle Valo
^ permalink raw reply
* Re: mwifiex: PCIe8997 chip specific handling
From: Kalle Valo @ 2016-09-09 11:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1469788731-5361-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> The patch corrects the revision id register and uses it along with
> magic value and chip version registers to download appropriate firmware
> image.
>
> PCIe8997 Z chipset variant code has been removed, as it won't be used in
> production.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
75696fe70477 mwifiex: PCIe8997 chip specific handling
--
Sent by pwcli
https://patchwork.kernel.org/patch/9252431/
^ permalink raw reply
* [PATCH v2] mwifiex: handle error if IRQ request fails in mwifiex_sdio_of()
From: Amitkumar Karwar @ 2016-09-09 10:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Amitkumar Karwar
When this failure occurs, we will clear card->plt_wake_cfg so that
device would initialize without wake up on external interrupt feature.
This feature specific code in suspend and resume handlers will be
skipped.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
We were returning error in this failure case in v1 patch from Javier
Martinez Canillas. In v2, we allow device to initialize successfully.
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 6dba409..8718950 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
IRQF_TRIGGER_LOW,
"wifi_wake", cfg);
if (ret) {
- dev_err(dev,
+ dev_dbg(dev,
"Failed to request irq_wifi %d (%d)\n",
cfg->irq_wifi, ret);
+ card->plt_wake_cfg = NULL;
+ return 0;
}
disable_irq(cfg->irq_wifi);
}
--
1.9.1
^ permalink raw reply related
* RE: mwifiex: PCIe8997 chip specific handling
From: Amitkumar Karwar @ 2016-09-09 10:28 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <20160909091449.A66606183E@smtp.codeaurora.org>
SGkgS2FsbGUsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgt
d2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+
IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEthbGxlIFZhbG8NCj4gU2VudDog
RnJpZGF5LCBTZXB0ZW1iZXIgMDksIDIwMTYgMjo0NSBQTQ0KPiBUbzogQW1pdGt1bWFyIEthcndh
cg0KPiBDYzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBDYXRoeSBMdW87IE5pc2hh
bnQgU2FybXVrYWRhbTsNCj4gQW1pdGt1bWFyIEthcndhcg0KPiBTdWJqZWN0OiBSZTogbXdpZmll
eDogUENJZTg5OTcgY2hpcCBzcGVjaWZpYyBoYW5kbGluZw0KPiANCj4gQW1pdGt1bWFyIEthcndh
ciA8YWthcndhckBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+ID4gVGhlIHBhdGNoIGNvcnJlY3RzIHRo
ZSByZXZpc2lvbiBpZCByZWdpc3RlciBhbmQgdXNlcyBpdCBhbG9uZyB3aXRoDQo+ID4gbWFnaWMg
dmFsdWUgYW5kIGNoaXAgdmVyc2lvbiByZWdpc3RlcnMgdG8gZG93bmxvYWQgYXBwcm9wcmlhdGUN
Cj4gPiBmaXJtd2FyZSBpbWFnZS4NCj4gPg0KPiA+IFBDSWU4OTk3IFogY2hpcHNldCB2YXJpYW50
IGNvZGUgaGFzIGJlZW4gcmVtb3ZlZCwgYXMgaXQgd29uJ3QgYmUgdXNlZA0KPiA+IGluIHByb2R1
Y3Rpb24uDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBBbWl0a3VtYXIgS2Fyd2FyIDxha2Fyd2Fy
QG1hcnZlbGwuY29tPg0KPiANCj4gRG9lcyBhcHBseSwgcGxlYXNlIHJlYmFzZToNCj4gDQo+IEFw
cGx5aW5nOiBtd2lmaWV4OiBQQ0llODk5NyBjaGlwIHNwZWNpZmljIGhhbmRsaW5nDQo+IGZhdGFs
OiBzaGExIGluZm9ybWF0aW9uIGlzIGxhY2tpbmcgb3IgdXNlbGVzcw0KPiAoZHJpdmVycy9uZXQv
d2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuYykuDQo+IFJlcG9zaXRvcnkgbGFja3MgbmVj
ZXNzYXJ5IGJsb2JzIHRvIGZhbGwgYmFjayBvbiAzLXdheSBtZXJnZS4NCj4gQ2Fubm90IGZhbGwg
YmFjayB0byB0aHJlZS13YXkgbWVyZ2UuDQo+IFBhdGNoIGZhaWxlZCBhdCAwMDAxIG13aWZpZXg6
IFBDSWU4OTk3IGNoaXAgc3BlY2lmaWMgaGFuZGxpbmcNCj4gDQoNClRoZSBwYXRjaCBub3cgc21v
b3RobHkgYXBwbGllcyB0byB0b3Agb2YgdGhlIHRyZWUuIEl0IGhhZCBhIGRlcGVuZGVuY3kgd2l0
aCAibXdpZmlleDogYWRkIFBDSWUgZnVuY3Rpb24gbGV2ZWwgcmVzZXQgc3VwcG9ydCIgd2hpY2gg
aXMgbWVyZ2VkLg0KTGV0IG1lIGtub3cgaWYgdGhlcmUgaXMgc3RpbGwgYSBwcm9ibGVtLg0KDQpS
ZWdhcmRzLA0KQW1pdGt1bWFyDQo=
^ permalink raw reply
* Re: [RFC] mac80211: Dynamically set CoDel parameters per station.
From: Toke Høiland-Jørgensen @ 2016-09-09 9:51 UTC (permalink / raw)
To: Felix Fietkau; +Cc: make-wifi-fast, linux-wireless, Michal Kazior, Dave Taht
In-Reply-To: <2663e4fb-bcdf-a872-f5ab-fac3bb5344c1@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2016-09-08 21:59, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> CoDel can be too aggressive if a station sends at a very low rate. This
>> gets worse the more stations are present, as each station gets more
>> bursty the longer the round-robin scheduling between stations takes.
>>=20
>> This is an attempt to dynamically adjust CoDel parameters per station.
>> It takes a rather simple approach and uses a simple binary designation
>> of a station as 'slow' if it has expected throughput less than eight
>> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
>> more lenient by adjusting its target to 50 ms and interval to 300 ms.
>> There's a built-in hysteresis so a station cannot flip between slow and
>> fast more than once every two seconds.
>>=20
>> In this version the check is performed every time a packet is enqueued
>> to the intermediate queues; and the overhead of doing this is alleviated
>> a bit by caching the result and by the above-mentioned hysteresis. It
>> can probably be smarter about both when and how to do the scaling, but
>> this seems to alleviate some of the starvation I've seen with very slow
>> stations.
> Since this is not dealing properly with firmware rate control anyway,
> I'd suggest calling the update from rate_control_set_rates in order to
> avoid putting more stuff into the tx hot path.
Yeah, I wasn't expecting that to stay in the TX path, but was not
familiar enough with minstrel to know where a good place would be.
Thanks for the pointer.
> You could add a separate code path to allow firmware rate control
> devices to provide a hint at a convenient point in time.
There's already a get_expected_throughput() driver hook; but no drivers
seem to be using it? But I assume you mean a hook the other way, i.e.
export a function where the driver can tell mac80211 "my expected
throughput changed, please update"?
-Toke
^ permalink raw reply
* Re: mwifiex: scan: Simplify code
From: Kalle Valo @ 2016-09-09 9:21 UTC (permalink / raw)
To: Christophe Jaillet
Cc: akarwar, nishants, linux-wireless, netdev, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <1472644259-15605-1-git-send-email-christophe.jaillet@wanadoo.fr>
Christophe Jaillet <christophe.jaillet@wanadoo.fr> wrote:
> This patch:
> - improves code layout
> - removes a useless memset(0) for some memory allocated with kzalloc
> - removes a useless if. We know that 'if (chan_band_tlv)' will succeed
> because it has been tested a few lines above
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Thanks, 1 patch applied to wireless-drivers-next.git:
b71165761694 mwifiex: scan: Simplify code
--
Sent by pwcli
https://patchwork.kernel.org/patch/9307009/
^ permalink raw reply
* Re: mwifiex: add PCIe function level reset support
From: Kalle Valo @ 2016-09-09 9:19 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <86c718ca301b4da2ba814c049b78e6b3@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
>> Doesn't apply anymore, please rebase.
>>
>> Applying: mwifiex: add PCIe function level reset support
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/marvell/mwifiex/main.c).
>> Repository lacks necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0001 mwifiex: add PCIe function level reset support
>
> It gets applied smoothly if below patches are applied first.
> https://patchwork.kernel.org/patch/9310499/ ([v5,1/2] mwifiex: add manufacturing mode support)
> https://patchwork.kernel.org/patch/9310501/ ([v5,2/2] mwifiex: add cfg80211 testmode support)
>
> Please let me know if you want me to rebase "PCIe function level reset
> support". In that case I need to rebase and send above 2 patches as
> well.
Yes, I was able to apply this after those patches. No need to resend.
--
Kalle Valo
^ permalink raw reply
* Re: mwifiex: add PCIe function level reset support
From: Kalle Valo @ 2016-09-09 9:18 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Amitkumar Karwar
In-Reply-To: <1469541704-2880-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> This patch implements pre and post FLR handlers to support PCIe FLR
> functionality. Software cleanup is performed in pre-FLR whereas
> firmware is downloaded and software is re-initialised in
> post-FLR handler.
>
> Following command triggers FLR.
> echo "1" > /sys/bus/pci/devices/$NUMBER/reset
>
> This feature can be used as a recovery mechanism when firmware gets
> hang.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
4c5dae59d2e9 mwifiex: add PCIe function level reset support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9248233/
^ permalink raw reply
* Re: mwifiex: PCIe8997 chip specific handling
From: Kalle Valo @ 2016-09-09 9:14 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1469788731-5361-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> The patch corrects the revision id register and uses it along with
> magic value and chip version registers to download appropriate firmware
> image.
>
> PCIe8997 Z chipset variant code has been removed, as it won't be used in
> production.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Does apply, please rebase:
Applying: mwifiex: PCIe8997 chip specific handling
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/pcie.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: PCIe8997 chip specific handling
--
Sent by pwcli
https://patchwork.kernel.org/patch/9252431/
^ permalink raw reply
* Re: [1/2] brcmfmac: add support for bcm4339 chip with modalias sdio:c00v02D0d4339
From: Kalle Valo @ 2016-09-09 9:12 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1473072133-4266-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> The driver already supports the bcm4339 chipset but only for the variant
> that shares the same modalias as the bcm4335, ie. sdio:c00v02D0d4335.
> It turns out that there are also bcm4339 devices out there that have a
> more distiguishable modalias sdio:c00v02D0d4339.
>
> Reported-by: Steve deRosier <derosier@gmail.com>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Thanks, 2 patches applied to wireless-drivers-next.git:
634faf368690 brcmfmac: add support for bcm4339 chip with modalias sdio:c00v02D0d4339
5251b6be8bb5 brcmfmac: sdio: shorten retry loop in brcmf_sdio_kso_control()
--
Sent by pwcli
https://patchwork.kernel.org/patch/9313473/
^ permalink raw reply
* Re: [PATCHv8,1/4] add basic register-field manipulation macros
From: Kalle Valo @ 2016-09-09 9:11 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Linux Wireless List, Jakub Kicinski
In-Reply-To: <1472644007-20959-2-git-send-email-jakub.kicinski@netronome.com>
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> Common approach to accessing register fields is to define
> structures or sets of macros containing mask and shift pair.
> Operations on the register are then performed as follows:
>
> field = (reg >> shift) & mask;
>
> reg &= ~(mask << shift);
> reg |= (field & mask) << shift;
>
> Defining shift and mask separately is tedious. Ivo van Doorn
> came up with an idea of computing them at compilation time
> based on a single shifted mask (later refined by Felix) which
> can be used like this:
>
> #define REG_FIELD 0x000ff000
>
> field = FIELD_GET(REG_FIELD, reg);
>
> reg &= ~REG_FIELD;
> reg |= FIELD_PREP(REG_FIELD, field);
>
> FIELD_{GET,PREP} macros take care of finding out what the
> appropriate shift is based on compilation time ffs operation.
>
> GENMASK can be used to define registers (which is usually
> less error-prone and easier to match with datasheets).
>
> This approach is the most convenient I've seen so to limit code
> multiplication let's move the macros to a global header file.
> Attempts to use static inlines instead of macros failed due
> to false positive triggering of BUILD_BUG_ON()s, especially with
> GCC < 6.0.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
Thanks, 4 patches applied to wireless-drivers-next.git:
3e9b3112ec74 add basic register-field manipulation macros
faad5433b722 mt7601u: remove redefinition of GENMASK
adcc710d0a9e mt7601u: remove unnecessary include
d43af50566b4 mt7601u: use linux/bitfield.h
--
Sent by pwcli
https://patchwork.kernel.org/patch/9306999/
^ permalink raw reply
* Re: [v5,1/2] mwifiex: add manufacturing mode support
From: Kalle Valo @ 2016-09-09 9:06 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1472801707-6939-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> By default normal mode is chosen when driver is loaded. This
> patch adds a provision to choose manufacturing mode via module
> parameters.
>
> Below command loads driver in manufacturing mode
> insmod mwifiex.ko mfg_mode=1.
>
> Tested-by: chunfan chen <jeffc@marvell.com>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 2 patches applied to wireless-drivers-next.git:
cf5383b088d0 mwifiex: add manufacturing mode support
3935ccc14d2c mwifiex: add cfg80211 testmode support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9310499/
^ permalink raw reply
* Re: [v2] bcma: use of_dma_configure() to set initial dma mask
From: Kalle Valo @ 2016-09-09 9:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafał Miłecki, Arnd Bergmann, Hauke Mehrtens,
linux-wireless, linux-kernel
In-Reply-To: <1458207563-3453369-1-git-send-email-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> While fixing another bug, I noticed that bcma manually sets up
> a dma_mask pointer for its child devices. We have a generic
> helper for that now, which should be able to cope better with
> any variations that might be needed to deal with cache coherency,
> unusual DMA address offsets, iommus, or limited DMA masks, none
> of which are currently handled here.
>
> This changes the core to use the of_dma_configure(), like
> we do for platform devices that are probed directly from
> DT.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, 1 patch applied to wireless-drivers-next.git:
defb893fffef bcma: use of_dma_configure() to set initial dma mask
--
Sent by pwcli
https://patchwork.kernel.org/patch/8608751/
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Joerg Roedel @ 2016-09-09 8:38 UTC (permalink / raw)
To: Valerio Passini
Cc: Kalle Valo, Adam Morrison, linux-wireless, Omer Peleg,
linux-kernel, iommu, David Woodhouse
In-Reply-To: <CAC6K2=_Hdkgc_6igoC59J_Cn9=bdye827zbEK7PWtZY6ebh-6Q@mail.gmail.com>
Hi Valerio,
On Thu, Sep 08, 2016 at 09:07:56PM +0200, Valerio Passini wrote:
> I'm hoping having done it right and I can try your first suggestion, but I
> really cannot solve this problem by myself: sorry, I have no capabilities in
> programming in any known and unknown computer language. Surely, I can test all
> the patches you want and report the results but this is the best I can do. Best
> regards
Can you please send me the full dmesg after boot? The Intel-IOMMU is not
enabled by default, so I want to check if it is either enabled by
kernel-config or kernel command-line.
Thanks,
Joerg
^ 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