Sujith Manoharan suj...@msujith.org writes:
Kalle Valo wrote:
Johannes, are you planning to take this? Or should I take this once the
corresponding mac80211 patch trickles down to my tree?
Kalle, can you please pick this one ? I'll rebase and send the ath9k patch
to John once he starts
On Sun, Dec 14, 2014 at 11:39:14PM +0100, Rickard Strandqvist wrote:
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
Hi,
v9:
- switched the patch order, now RCU fixes are done before the scheduled
scan tweaks
- fix the RCU code according to comments from v8
v8:
- reworked the RCU code and placed it in patch 2
v7:
- convert the cfg80211_sched_scan_request to __rcu pointer in order
to avoid races when
Because of possible races when accessing sched_scan_req pointer in
rdev, the sched_scan_req is converted to RCU pointer.
Signed-off-by: Jukka Rissanen jukka.rissa...@linux.intel.com
---
include/net/cfg80211.h | 1 +
net/wireless/core.c| 10 +++---
net/wireless/core.h| 2 +-
From: Johannes Berg johannes.b...@intel.com
The power level might have been set, but as the interface was idle
it might not have taken effect yet. Ask the driver to check the
power level when starting up an AP so that in this case the correct
power level is used in case the device/driver can only
An attribute NL80211_ATTR_SOCKET_OWNER can be set by the scan initiator.
If present, the attribute will cause the scan to be stopped if the client
dies.
Signed-off-by: Jukka Rissanen jukka.rissa...@linux.intel.com
---
include/net/cfg80211.h | 1 +
include/uapi/linux/nl80211.h | 3 +++
From: Johannes Berg johannes.b...@intel.com
In order to let drivers have more dynamic U-APSD support,
move the enablement flag to the virtual interface driver
flags. This lets drivers not only set it up differently
for different interfaces, but also enable/disable on the
fly if needed.
This fix TX problem when IBSS connected and
enabled HT rates. Before we used 6Mbps all the
time.
Reported-by: Yeoh Chun-Yeow yeohchuny...@gmail.com
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
drivers/net/wireless/ath/ath10k/mac.c | 12
1 file changed, 12
On Fri, 2014-12-12 at 11:47 -0500, Bob Copeland (m...@bobcopeland.com)
wrote:
On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote:
On Fri, 2014-11-21 at 11:24 +, Nishikawa, Kenzoh wrote:
Instead of sending peer candidate events just once, send them
as long as the peer
On Fri, 2014-11-21 at 11:24 +, Nishikawa, Kenzoh wrote:
+ cfg80211_notify_new_peer_candidate(sdata-dev, hw_addr,
+elems-ie_start,
+elems-total_len,
+
On Fri, 2014-12-12 at 15:16 +0100, Lorenzo Bianconi wrote:
In multi-vif scenario, TPC could be enabled just on given interfaces,
but driver TPC registers should be configured anyway (so I used a glob
flag). However I can move that logic in driver code, what do you
suggest?
It seems strange
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted
Hello,
I have an issue with iwlwifi driver.
I installed iwlwifi-6000-ucode-9.193.4.1 on my ThinkPad x201 (Intel®
Centrino® Advanced-N 6200) running Debian Testing (Jessie)
It works fine in b/g mode but not in N mode.
Is there something I need to do to make it work in N mode ? Or is it a
Krzysztof Konopko k...@konagma.com writes:
On 12/12/14 19:52, Jes Sorensen wrote:
Larry Finger larry.fin...@lwfinger.net writes:
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
I was hunting particularly for inconsistencies with `sparse` and came
across this one. But I dug a bit further and
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
When a phy is given, print only its regdomain. Otherwise, use the newly
implement dump functionality to print all regdomains in the system.
Signed-off-by: Arik Nemtsov a...@wizery.com
---
v2: fix reg get for older kernels
reg.c | 40
1 file changed, 36
On Fri, Dec 12, 2014 at 2:37 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Wed, 2014-12-03 at 18:08 +0200, Arik Nemtsov wrote:
* @NL80211_CMD_GET_REG: ask the wireless core to send us its currently set
- * regulatory domain.
+ * regulatory domain. If %NL80211_ATTR_WIPHY is
On Fri, Dec 12, 2014 at 2:39 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Wed, 2014-12-03 at 18:08 +0200, Arik Nemtsov wrote:
+void nl80211_send_reg_change_event(struct regulatory_request *request)
+{
+ nl80211_common_reg_change_event(NL80211_CMD_REG_CHANGE, request);
+}
+
If a wiphy-idx is specified, the kernel will return the wiphy specific
regdomain, if such exists. Otherwise return the global regdom.
When no wiphy-idx is specified, return the global regdomain as well as
all wiphy-specific regulatory domains in the system, via a new nested
list of attributes.
If a device has self-managed regulatory, insist on returning the wiphy
specific regdomain if a wiphy-idx is specified. The global regdomain is
meaningless for such devices.
Also add an attribute for self-managed devices, so usermode can
distinguish them as such.
Signed-off-by: Arik Nemtsov
The custom-reg handling function can currently only add flags to a given
channel. This results in stale flags being left applied. In some cases
a channel was disabled and even the orig_flags were changed to reflect
this.
Previously the API was designed for a single invocation before wiphy
From: Jonathan Doron j...@wizery.com
Add a new regulatory flag that allows a driver to manage regdomain
changes/updates for its own wiphy.
A self-managed wiphys only employs regulatory information obtained from
the FW and driver and does not use other cfg80211 sources like
beacon-hints,
If a wiphy-idx is specified, the kernel will return the wiphy specific
regdomain, if such exists. Otherwise return the global regdom.
When no wiphy-idx is specified, return the global regdomain as well as
all wiphy-specific regulatory domains in the system, via a new nested
list of attributes.
The custom-reg handling function can currently only add flags to a given
channel. This results in stale flags being left applied. In some cases
a channel was disabled and even the orig_flags were changed to reflect
this.
Previously the API was designed for a single invocation before wiphy
If a device has self-managed regulatory, insist on returning the wiphy
specific regdomain if a wiphy-idx is specified. The global regdomain is
meaningless for such devices.
Also add an attribute for self-managed devices, so usermode can
distinguish them as such.
Signed-off-by: Arik Nemtsov
From: Jonathan Doron j...@wizery.com
Add a new regulatory flag that allows a driver to manage regdomain
changes/updates for its own wiphy.
A self-managed wiphys only employs regulatory information obtained from
the FW and driver and does not use other cfg80211 sources like
beacon-hints,
On Fri, Dec 12, 2014 at 07:44:35PM +0200, Johan Hedberg wrote:
Hi John,
These fixes are intended for 3.19, note that the tree to pull from is
bluetooth-next (unlike the subject implies). I'd have normally done a
pull request from bluetooth.git, but since these fixes for 3.19 is all
we have
On Mon, 2014-12-15 at 19:12 +0200, Arik Nemtsov wrote:
On Fri, Dec 12, 2014 at 2:39 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Wed, 2014-12-03 at 18:08 +0200, Arik Nemtsov wrote:
+void nl80211_send_reg_change_event(struct regulatory_request *request)
+{
+
On 2014-12-15 19:55, Peter Oh wrote:
The minimum number of pulses per burst on FCC radar type 5 is 1.
Use this number for correct radar detection.
Signed-off-by: Peter Oh p...@qca.qualcomm.com
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
1 file changed, 1 insertion(+), 1
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who decides?
Kind regards
Rickard Strandqvist
2014-12-15
As for drv_wake_tx_queue and ieee80211_tx_dequeue - is it really
necessary? There are ieee80211_tx_status and ieee80211_free_txskb
already, which can be used to decide from mac80211 level when to
dequeue packet. It could be used even in case of drivers that are not
aware of new mechanism at all.
On 12/15/2014 12:42 PM, Felix Fietkau wrote:
On 2014-12-15 19:55, Peter Oh wrote:
The minimum number of pulses per burst on FCC radar type 5 is 1.
Use this number for correct radar detection.
Signed-off-by: Peter Oh p...@qca.qualcomm.com
---
drivers/net/wireless/ath/dfs_pattern_detector.c |
On Mon, Dec 15, 2014 at 06:26:09PM -0500, Joe Borg wrote:
Fixing errors found with checkpatch.pl.
What exact errors? Please be specific here and describe what you are
doing.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to
On 12/15/2014 05:01 PM, Rickard Strandqvist wrote:
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who
Instead of sending peer candidate events just once, send them as long as the
peer remains in the LISTEN state in the peering state machine, when userspace
is implementing the peering manager.
Userspace may silence the events from a peer by progressing the state machine
or by setting the link
Peter Oh p...@qca.qualcomm.com writes:
Setting fragmentation threshold has not been supported by
any of firmware versions, hence unregister the callback and
remove the function.
Signed-off-by: Peter Oh p...@qca.qualcomm.com
Thanks, applied.
--
Kalle Valo
--
To unsubscribe from this list:
Michal Kazior michal.kaz...@tieto.com writes:
Michal Kazior (5):
ath10k: improve 11b coex
ath10k: fix STA u-APSD
ath10k: prevent invalid ps timeout config
ath10k: enable per-vif sta powersave
ath10k: advertise p2p dev support
Thanks, all five patches applied.
--
Kalle Valo
--
A heads up for the backports project:
Rajkumar Manoharan rmano...@qti.qualcomm.com writes:
Thermal cooling device support is added to control the temperature
by throttling the data transmission for the given duration. Throttling
is done using hw MAC quiet time setting. Period, duration and
Rajkumar Manoharan rmano...@qti.qualcomm.com writes:
10.2.4 firmware uses bitmask in wmi_resource_config to configure
10.2 firmware features like airtime fairness and rx batch mode instead
of maintaining separete bool entry. This allows new features that can be
configure during init time
40 matches
Mail list logo
