Rajkumar Manoharan 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 without breaking backward
A heads up for the backports project:
Rajkumar Manoharan 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 offset
> from TBTT can be
Michal Kazior 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
--
To unsubscribe from
Peter Oh 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
Thanks, applied.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wirel
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 sta
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 decid
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
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
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
1 file changed
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. We
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 1
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
> ---
> drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On 12/15/2014 04:12 PM, Jonathan Marcille wrote:
> Hello,
>
> I have an issue with iwlwifi driver.
What version of the kernel do you have?
>
> 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
On Mon, Dec 15, 2014 at 8:41 PM, Johannes Berg
wrote:
> On Mon, 2014-12-15 at 19:12 +0200, Arik Nemtsov wrote:
>> On Fri, Dec 12, 2014 at 2:39 PM, Johannes Berg
>> wrote:
>> > On Wed, 2014-12-03 at 18:08 +0200, Arik Nemtsov wrote:
>> >
>> >> +void nl80211_send_reg_change_event(struct regulatory_r
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
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detec
On Mon, 2014-12-15 at 19:12 +0200, Arik Nemtsov wrote:
> On Fri, Dec 12, 2014 at 2:39 PM, Johannes Berg
> 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_
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
From: Jonathan Doron
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, country-code IEs and hint
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
Revie
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
registra
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.
Ad
From: Jonathan Doron
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, country-code IEs and hint
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
Revie
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
registra
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.
Ad
On Fri, Dec 12, 2014 at 2:39 PM, Johannes Berg
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);
>> +}
>> +
>> +void nl80211_s
On Fri, Dec 12, 2014 at 2:37 PM, Johannes Berg
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 specified and the devic
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
---
v2: fix reg get for older kernels
reg.c | 40
1 file changed, 36 insertions(+), 4
Dan Carpenter writes:
> 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
>> ---
>>
Krzysztof Konopko 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
> rtw_wlan_util.c:
Krzysztof Konopko 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
> rtw_wlan_util.c:
Krzysztof Konopko writes:
> On 12/12/14 19:52, Jes Sorensen wrote:
>> Larry Finger 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 I wonder why the driver is
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
driv
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 _
> 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 se
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 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 pe
This fix TX problem when IBSS connected and
enabled HT rates. Before we used 6Mbps all the
time.
Reported-by: Yeoh Chun-Yeow
Signed-off-by: Janusz Dziedzic
---
drivers/net/wireless/ath/ath10k/mac.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k
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 strang
On Fri, 2014-12-12 at 15:28 +0100, Felix Fietkau wrote:
> > Management (and maybe control) frames can have different priorities as
> > well, this is only used for something with TDLS now I think though.
> With my implementation, those would go through the normal tx codepath,
> bypassing the softwa
On Mon, 2014-12-15 at 12:35 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> 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 ena
From: Johannes Berg
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.
Signed-off-by: Johannes Berg
---
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
---
include/net/cfg80211.h | 1 +
include/uapi/linux/nl80211.h | 3 +++
net/wireless/core.c | 16
From: Johannes Berg
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 set it when
the interfa
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
---
include/net/cfg80211.h | 1 +
net/wireless/core.c| 10 +++---
net/wireless/core.h| 2 +-
net/wireless/nl80211.c | 19 ++
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 access
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
> ---
> drivers/staging/rtl8723au/os_dep
Sujith Manoharan 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 merging patches
47 matches
Mail list logo
