Hi
On 11/19/2014 03:09 AM, Johan Hedberg wrote:
Hi Kirill,
On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
Chan-yeol Park (1):
Bluetooth: Fix hci_sync missing wakeup interrupt
Look like this commit causes problem for me:
Hi Martin,
If v1 is being used which can be case because older FWs dont have support for
keymaterial v2, I suspect FW is returning bad length.
I've noticied that there is a more recent firmware version available in
the Marvell git repository but that it doesn't seem to have propagated
to the
18.11.2014 01:36, Maximilian Engelhardt wrote:
[]
I just wanted to ask if there is any progress on this issue since I haven't
heard anything for a month. Please let me know if you need any additional
information.
I've no idea if there's any progress. Meanwhile I've an easy way of
testing of
Hi,
I tried to understand why this 0x13d3, 0x3408 device support
wouldn't go in btusb as it's really close to IMC BT chip found in
Realtek Wifi devices which is on the path to go in btusb [1]
then I guess there is a lot of code that could be shared to support
all IMC usb devices in the btusb
It seems that I am too stupid.
It is neither AR3012 or AR3011 device.
It is AR9565 with sflash.
Probably it makes sense to do a separate section for these devices.
But still
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_IGNORE },
works better than
{ USB_DEVICE(0x13d3, 0x3408), .driver_info
Introduce commands to initiate and cancel TDLS channel-switching. Once
TDLS channel-switching is started, the lower level driver is responsible
for continually initiating channel-switch operations and returning to
the base (AP) channel to listen for beacons from time to time.
Upon cancellation of
On Tue, Nov 18, 2014 at 08:09:19PM +0200, Johan Hedberg wrote:
Hi Kirill,
On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
Chan-yeol Park (1):
Bluetooth: Fix hci_sync missing wakeup interrupt
Look like this commit
On Wed, Nov 19, 2014 at 1:22 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Sun, 2014-11-09 at 18:50 +0200, Arik Nemtsov wrote:
+ if (WARN_ON(tid = IEEE80211_NUM_TIDS))
+ return -EINVAL;
That validates 16
+ queues =
On Wed, 2014-11-19 at 13:40 +0200, Arik Nemtsov wrote:
On Wed, Nov 19, 2014 at 1:22 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Sun, 2014-11-09 at 18:50 +0200, Arik Nemtsov wrote:
+ if (WARN_ON(tid = IEEE80211_NUM_TIDS))
+ return -EINVAL;
That validates 16
On Wed, Nov 19, 2014 at 1:41 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Wed, 2014-11-19 at 13:40 +0200, Arik Nemtsov wrote:
On Wed, Nov 19, 2014 at 1:22 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Sun, 2014-11-09 at 18:50 +0200, Arik Nemtsov wrote:
+ if
From: Liad Kaufman liad.kauf...@intel.com
In TDLS (e.g., TDLS off-channel) there is a requirement for
some drivers to supply an unused TID between the AP and the
device to the FW, to allow sending PTI requests and to allow
the FW to aggregate on a specific TID for better throughput.
To ensure
if CONFIG_DEV_COREDUMP=y is added to configuration file, it
gets removed when final configuration file is generated. The
reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled.
Currently make menuconfig doesn't display an option to enable
WANT_DEV_COREDUMP. This patch updates Kconfig so
On Wed, 2014-11-19 at 05:28 -0800, Amitkumar Karwar wrote:
if CONFIG_DEV_COREDUMP=y is added to configuration file, it
gets removed when final configuration file is generated. The
reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled.
Currently make menuconfig doesn't display an
Hi Johannes,
Currently make menuconfig doesn't display an option to enable
WANT_DEV_COREDUMP. This patch updates Kconfig so that user can enable
WANT_DEV_COREDUMP.
This is completely intentional - drivers should select
WANT_DEV_COREDUMP and users are only able to set ALLOW_DEV_COREDUMP=n
to
On 11/17/14 23:36, Maximilian Engelhardt wrote:
On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
On 9 October 2014 09:52, Arend van Sprielar...@broadcom.com wrote:
I have been staring at differences brcmsmac and our internal driver (which
wl is derived from as well). Would you be
On 11/19/14 14:46, Arend van Spriel wrote:
On 11/17/14 23:36, Maximilian Engelhardt wrote:
On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
On 9 October 2014 09:52, Arend van Sprielar...@broadcom.com wrote:
I have been staring at differences brcmsmac and our internal driver
(which
wl
Hi Avinash,
On 19/11/14 09:44, Avinash Patil wrote:
Could you please check if issue is seen with this FW as well?
Here is link:
http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=3f45b8c4cc1eb1d102bc3486b19677332dd215ab
Tried that firmware (14.66.35.p52) with kernel 3.16, same issue.
Aleh Suprunovich b...@ahlamon.org writes:
drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c:747:1: warning: symbol
'rtl8723a_EfusePgPacketRead' was not declared. Should it be static?
Function 'rtl8723a_EfusePgPacketRead' seems to be unused in current
staging code.
Before, it was available
On Fri, 2014-11-14 at 11:10 -0600, Dan Williams wrote:
On Fri, 2014-11-14 at 10:02 -0600, Dan Williams wrote:
On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote:
Hi Dan,
I've updated wireless code on RHEL and get complain that now
cfg80211 and rfkill modules are loaded on
All applied.
johannes
--
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 http://vger.kernel.org/majordomo-info.html
From: Luciano Coelho luciano.coe...@intel.com
For net detect, we will need to reuse most of the scheduled scan
parsing function, but not all, so split out the attributes parsing
part out of the main start sched_scan function.
Signed-off-by: Luciano Coelho luciano.coe...@intel.com
Signed-off-by:
This series introduces randomised MAC addresses for scanning. It
obviously needs driver support, so three feature flags (for scan,
scheduled scan and wowlan-net-detect) are needed.
Currently it's only for unassociated, but maybe some devices can
also support it for background scans.
I've
From: Johannes Berg johannes.b...@intel.com
Add the necessary feature flags and a scan flag to support using
random MAC addresses for scan while unassociated.
The configuration for this supports an arbitrary MAC address
value and mask, so that any kind of configuration (e.g. fixed
OUI or full
From: Johannes Berg johannes.b...@intel.com
In order to use the scan and scheduled scan request pointers during
RX to check for randomisation, make them accessible using RCU.
Change-Id: Ic3674042303055a26900c8aaca9490a70a389392
Signed-off-by: Johannes Berg johannes.b...@intel.com
Reviewed-on:
From: Johannes Berg johannes.b...@intel.com
This adds support for scanning with random MAC address for
both software and hardware scan.
Change-Id: Ib667b4ba0f515f9d1fc073d8ae4c7785f6c3e124
Signed-off-by: Johannes Berg johannes.b...@intel.com
Reviewed-on: https://gerrit.rds.intel.com/r/47442
Applied both.
johannes
--
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 http://vger.kernel.org/majordomo-info.html
On Fri, 2014-11-14 at 18:43 +0100, Rafał Miłecki wrote:
Callback add_virtual_intf is supposed to return ERR_PTR and trying to
return NULL results in some Unable to handle kernel paging request,
etc. As it may be complicated to debug trace, let's catch it (WARN).
I guess we can do that.
On Mon, Nov 17, 2014 at 11:48:06AM +0100, Johannes Berg wrote:
From: Johannes Berg johannes.b...@intel.com
In many cases, drivers can filter things like beacons that will
skew statistics reported by mac80211. To get correct statistics
in these cases, call drivers to obtain statistics and let
On 11/19/2014 09:49 AM, Bob Copeland wrote:
On Mon, Nov 17, 2014 at 11:48:06AM +0100, Johannes Berg wrote:
From: Johannes Berg johannes.b...@intel.com
In many cases, drivers can filter things like beacons that will
skew statistics reported by mac80211. To get correct statistics
in these
On Fri, 2014-11-14 at 13:16 +0200, Jukka Rissanen wrote:
We can always know the hwname of the radio so use the value
from wiphy.
Applied. I was hoping you'd fix the smatch thing but I guess not ... did
that myself now.
johannes
--
To unsubscribe from this list: send the line unsubscribe
From: Johannes Berg johannes.b...@intel.com
The hwname will always be set if idx is negative (as it's
a u32 read into an s64 it can't overflow either) so we can
remove the unnecessary check for hwname being non-NULL.
This was reported by smatch.
Signed-off-by: Johannes Berg
On Thu, 2014-11-13 at 17:25 +0200, Jukka Rissanen wrote:
Replace NL80211_ATTR_IFACE_SOCKET_OWNER attribute with more generic
NL80211_ATTR_SOCKET_OWNER that can be used with other commands
that interface creation.
Applied.
johannes
--
To unsubscribe from this list: send the line unsubscribe
On Thu, 2014-11-13 at 17:25 +0200, Jukka Rissanen wrote:
@@ -12127,6 +12130,12 @@ static int nl80211_netlink_notify(struct
notifier_block * nb,
list_for_each_entry_rcu(rdev, cfg80211_rdev_list, list) {
bool schedule_destroy_work = false;
+ bool
On Wed, 2014-11-12 at 16:26 +0200, Tomasz Bursztyka wrote:
Let the other listeners being notified when a new or del interface
command has been issued, thus reducing later necessary request to be in
sync with current context.
Applied.
johannes
--
To unsubscribe from this list: send the line
On Wed, 2014-11-19 at 00:10 +0100, Felix Fietkau wrote:
From: Johannes Berg johannes.b...@intel.com
This allows drivers with a firmware or chip-based rate lookup table to
use the most recent default rate selection without having to get it from
per-packet data or explicit
On Sun, 2014-11-16 at 00:27 +0100, Felix Fietkau wrote:
Check the queue mapping earlier, skb-queue_mapping is more likely than
skb-data to still be in d-cache.
Applied.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to
On Sun, 2014-11-16 at 00:27 +0100, Felix Fietkau wrote:
@@ -1026,6 +1023,10 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta
*sta, void *priv_sta,
if (!msp-is_ht)
return mac80211_minstrel.get_rate(priv, sta, msp-legacy,
txrc);
+ if (!(info-flags
+++ b/net/mac80211/rate.h
@@ -37,11 +37,15 @@ static inline void rate_control_tx_status(struct
ieee80211_local *local,
struct rate_control_ref *ref = local-rate_ctrl;
struct ieee80211_sta *ista = sta-sta;
void *priv_sta = sta-rate_ctrl_priv;
+ struct ieee80211_tx_info
/**
+ * ieee80211_tx_status_noskb - transmit status callback without skb
+ *
+ * This function can be used as a replacement for ieee80211_tx_status
+ * in drivers that cannot reliably map tx status information back to
+ * specific skbs.
+ *
+ * This function may not be called in IRQ
There are better ways to get the kernel information, use the
utsname and omit the version code entirely since it's duplicate.
The version magic is rather useless anyway
Signed-off-by: Johannes Berg johan...@sipsolutions.net
---
drivers/net/wireless/ath/ath10k/debug.c | 7 +++
1 file changed,
On Wed, 2014-11-19 at 19:47 +0100, Felix Fietkau wrote:
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other. Calls
+ * to this function, ieee80211_tx_status_ni() and
ieee80211_tx_status_irqsafe()
+
Signed-off-by: Felix Fietkau n...@openwrt.org
---
net/mac80211/rc80211_minstrel.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index c2b91bf..d51f6b1 100644
--- a/net/mac80211/rc80211_minstrel.c
+++
This op works like .tx_status, except it does not need access to the
skb. This will be used by drivers that cannot match tx status
information to specific packets.
Signed-off-by: Felix Fietkau n...@openwrt.org
---
include/net/mac80211.h | 4
net/mac80211/rate.h| 6 +-
2 files
Preparation for adding a no-skb tx status path
Signed-off-by: Felix Fietkau n...@openwrt.org
---
net/mac80211/rc80211_minstrel_ht.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index
Signed-off-by: Felix Fietkau n...@openwrt.org
---
net/mac80211/rc80211_minstrel_ht.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c
b/net/mac80211/rc80211_minstrel_ht.c
index 2641dc8..b52996a 100644
---
19.11.2014 20:54, Arend van Spriel wrote:
[]
In our last email exchange I got the impression you switch to Intel board and
did not want to keep replacing cards for testing.
I especially wrote that I have several days to try things out and
if you'll be quick it will be possible for me to test
On Wed, 2014-11-19 at 19:13 +, Wu, Fengguang wrote:
In file included from arch/microblaze/include/asm/unaligned.h:21:0,
from include/linux/ieee80211.h:22,
from
drivers/net/wireless/brcm80211/include/brcmu_wifi.h:21,
from
From: Johannes Berg johannes.b...@intel.com
This is a specific implementation, asm/unaligned.h is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
On 11/19/14 21:18, Johannes Berg wrote:
From: Johannes Bergjohannes.b...@intel.com
This is a specific implementation,asm/unaligned.h is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
Thanks, Johannes
Maybe it would be
On Wed, 2014-11-19 at 21:36 +0100, Arend van Spriel wrote:
On 11/19/14 21:18, Johannes Berg wrote:
From: Johannes Bergjohannes.b...@intel.com
This is a specific implementation,asm/unaligned.h is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs
On 11/19/14 21:42, Johannes Berg wrote:
On Wed, 2014-11-19 at 21:36 +0100, Arend van Spriel wrote:
On 11/19/14 21:18, Johannes Berg wrote:
From: Johannes Bergjohannes.b...@intel.com
This is a specific implementation,asm/unaligned.h is the
multiplexer that has the arch-specific knowledge of
On Wed, 2014-11-19 at 21:47 +0100, Arend van Spriel wrote:
On 11/19/14 21:42, Johannes Berg wrote:
On Wed, 2014-11-19 at 21:36 +0100, Arend van Spriel wrote:
On 11/19/14 21:18, Johannes Berg wrote:
From: Johannes Bergjohannes.b...@intel.com
This is a specific
On 11/19/14 21:48, Johannes Berg wrote:
On Wed, 2014-11-19 at 21:47 +0100, Arend van Spriel wrote:
On 11/19/14 21:42, Johannes Berg wrote:
On Wed, 2014-11-19 at 21:36 +0100, Arend van Spriel wrote:
On 11/19/14 21:18, Johannes Berg wrote:
From: Johannes Bergjohannes.b...@intel.com
This is a
19.11.2014 22:58, Michael Tokarev wrote:
19.11.2014 20:54, Arend van Spriel wrote:
[]
I submitted two patches upstream and additionally I have attached two other
that are still under review. Could you try these patches and sent me the
content of the two debugfs files 'macstat' and 'hardware'
From: Johannes Berg johannes.b...@intel.com
This is a specific implementation, asm/unaligned.h is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
This issue was revealed by kbuild testing
when asm/unaligned.h was added in
55 matches
Mail list logo
