This is only an API consolidation to make things more readable.
Instances of HZ / CONST are replaced by appropriate msecs_to_jiffies().
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
--
To unsubscribe from this list: send the
Rafał Miłecki zaj...@gmail.com writes:
+void bcma_core_pcie2_up(struct bcma_drv_pcie2 *pcie2)
+{
+ struct bcma_bus *bus = pcie2-core-bus;
+ struct pci_dev *dev = bus-host_pci;
+
+ pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
+
This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
Thanks, 3 patches applied to wireless-drivers-next.git:
ab458cc85fa2 orinoco: orinoco_plx use msecs_to_jiffies for
Here is a output of this debugfs entry
root@OpenWrt:/# cat /sys/kernel/debug/ieee80211/phy0/vht80allow_map
2412 VHT80 N
2417 VHT80 N
2422 VHT80 N
2427 VHT80 N
2432 VHT80 N
2437 VHT80 N
2442 VHT80 N
2447 VHT80 N
2452 VHT80 N
2457 VHT80 N
2462 VHT80 N
2467 Disabled
2472 Disabled
2484 Disabled
5180
From: Troy Tan troy_...@realsil.com.cn
The hardware and firmware for the RTL8192EE utilize a FIFO list of
descriptors. There were some problems with the initial implementation.
The worst of these failed to detect that the FIFO was becoming full,
which led to the device needing to be power
On 2015-02-05 22:11, Larry Finger wrote:
On 02/05/2015 12:56 AM, Ken D'Ambrosio wrote:
Did the update to the troy branch of the rtlwifi_new repo fix the
problem?
Sadly, no. Exact same errors. So I looked at your previous e-mail,
which I've pasted (and commented about), below:
Do any
P.S. I'm sorry, I left this out: I only get the same errors during a
manual module load. At boot time, things seem to go somewhat more
smoothly -- though still fails to connect to anything. I've attached my
dmesg text so you can parse it more fully.
-Ken
On 2015-02-06 00:57, Ken
Sujith Manoharan suj...@msujith.org writes:
From: Sujith Manoharan c_man...@qca.qualcomm.com
ath9k patches for -next.
Sujith Manoharan (6):
ath9k: Add support for more WOW patterns
ath9k: Register correct WOW details with mac80211
ath9k: Fix issues with WoW enable
ath9k: Program
Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.
The easiest way to reproduce this issue: create a station
From: Markus Elfring elfr...@users.sourceforge.net
Date: Wed, 4 Feb 2015 16:32:15 +0100
The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
From: Markus Elfring elfr...@users.sourceforge.net
Date: Wed, 4 Feb 2015 18:48:28 +0100
The relay_close() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Grumbach, Emmanuel emmanuel.grumb...@intel.com writes:
Here is probably the last pull request for 3.20. Details below.
Since it is probably too late to send patches for 3.19, There are a few
patches here that are tagged for stable.
Please let me know if you have issues!
The following
On Thu, 2015-02-05 at 07:46 +0100, Michal Kazior wrote:
On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote:
Most conservative patch would be :
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index
On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote:
The intention is to control the queues to the following :
1 ms of buffering, but limited to a configurable value.
On a 40Gbps flow, 1ms represents 5 MB, which is insane.
We do not want to queue 5 MB of traffic, this would destroy
On 5 February 2015 at 14:19, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote:
The intention is to control the queues to the following :
1 ms of buffering, but limited to a configurable value.
On a 40Gbps flow, 1ms represents 5 MB, which is
On Thu, 2015-02-05 at 05:19 -0800, Eric Dumazet wrote:
TCP could eventually dynamically adjust the tcp_limit_output_bytes,
using a per flow dynamic value, but I would rather not add a kludge in
TCP stack only to deal with a possible bug in ath10k driver.
niu has a similar issue and
On Thu, 2015-02-05 at 09:38 +0100, Michal Kazior wrote:
On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote:
I do not see how a TSO patch could hurt a flow not using TSO/GSO.
This makes no sense.
Hmm..
@@ -2018,8 +2053,8 @@ static bool tcp_write_xmit(struct sock
Fellow netheads:
New Sponsor:
==
We thank Intel for supporting Netdev01. Intel is well known in its
tradition for supporting open source projects. http://www.intel.com/
Schedule:
==
The final schedule is out coded with session links.
Correct two problems with the error handling when using the netlink
forwarding API: first, the netlink skb is never freed if nla_put()
fails; and second, genlmsg_unicast() can fail if the netlink socket
is full. In the latter case, the corresponding data skb is not counted
as a drop and userspace
On Thu, 2015-02-05 at 14:44 +0100, Michal Kazior wrote:
I do get your point. But 1.5ms is really tough on Wi-Fi.
Just look at this:
; ping 192.168.1.2 -c 3
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.83 ms
64 bytes from
On 2015/2/3 21:08, Kalle Valo wrote:
Fu, Zhonghui zhonghui...@linux.intel.com writes:
From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fu zhonghui...@linux.intel.com
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject: [PATCH] brcmfmac: avoid duplicated
On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote:
I do not see how a TSO patch could hurt a flow not using TSO/GSO.
This makes no sense.
Hmm..
@@ -2018,8 +2053,8 @@ static bool tcp_write_xmit(struct sock *sk,
unsigned int mss_now, int nonagle,
* of
On Thu, 2015-02-05 at 14:44 +0100, Michal Kazior wrote:
Ok. I tried calling skb_orphan() right after I submit each Tx frame
(similar to niu which does this in start_xmit):
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -564,6 +564,8 @@ int
On Thu, 2015-02-05 at 06:41 -0800, Eric Dumazet wrote:
Not at all. This basically removes backpressure.
A single UDP socket can now blast packets regardless of SO_SNDBUF
limits.
This basically remove years of work trying to fix bufferbloat.
I still do not understand why increasing
On 02/05/15 12:34, Fu, Zhonghui wrote:
What comments about the new patch? Can this new patch be accepted?
Hi Zhonghui
Last reply from Kalle was that it did not apply to his tree and
recommended to use version numbering so [PATCH V2] subject.
Thanks,
Zhonghui
On 2015/1/26 10:46, Fu,
What comments about the new patch? Can this new patch be accepted?
Thanks,
Zhonghui
On 2015/1/26 10:46, Fu, Zhonghui wrote:
From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fu zhonghui...@linux.intel.com
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject:
On 4 February 2015 at 09:49, Kalle Valo kv...@qca.qualcomm.com wrote:
Michal Kazior michal.kaz...@tieto.com writes:
There are some slight differences in fw stats
(sic) in wmi-tlv.
Firmware has changed the querying scheme and no
longer requires the ping-pong to get all stats.
The patchset
On 02/05/2015 12:56 AM, Ken D'Ambrosio wrote:
Did the update to the troy branch of the rtlwifi_new repo fix the problem?
Larry
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 4 February 2015 at 09:55, Kalle Valo kv...@qca.qualcomm.com wrote:
Michal Kazior michal.kaz...@tieto.com writes:
If firmware advertises support for TxBF then the
driver has to instruct the firmware accordingly
during runtime. Without this patch connecting to
an AP with beamformer support
On Fri, Feb 6, 2015 at 2:44 AM, Michal Kazior michal.kaz...@tieto.com wrote:
On 5 February 2015 at 14:19, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote:
The intention is to control the queues to the following :
1 ms of buffering, but
30 matches
Mail list logo
