This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through diff_beacon_int_gcd_min (u32).
Following sets the expectation for diff_beacon_int_gcd_min.
= 0 - all beacon intervals for d
On Fri, 2016-08-12 at 21:40 -0700, Petri Gynther wrote:
> But, we need to return true (1) when the bitwise OR result is zero.
> Same logic as in is_zero_ether_addr().
right.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kern
On Fri, Aug 12, 2016 at 9:11 PM, Joe Perches wrote:
> On Fri, 2016-08-12 at 19:59 -0700, Petri Gynther wrote:
>> Add a generic routine to test if possibly unaligned to u16
>> Ethernet address is a zero address.
> []
>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> []
>>
On Fri, 2016-08-12 at 19:59 -0700, Petri Gynther wrote:
> Add a generic routine to test if possibly unaligned to u16
> Ethernet address is a zero address.
[]
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
[]
> +static inline bool is_zero_ether_addr_unaligned(const u8 *addr
From: Joe Perches
Date: Fri, 12 Aug 2016 21:00:27 -0700
> One solution might be to copy a hardware interface structure
> to another struct with appropriate alignment.
Right, especially if this is a slow path that would be an appropriate
way to handle this.
--
To unsubscribe from this list: send
On Fri, 2016-08-12 at 20:26 -0700, David Miller wrote:
> From: Petri Gynther
> Date: Fri, 12 Aug 2016 17:15:30 -0700
>
> > Root cause:
> > mwifiex driver calls is_zero_ether_addr() against byte-aligned address:
>
> MAC addresses really must be 16-bit aligned to be used with any of the
> ethernet
On Fri, Aug 12, 2016 at 8:26 PM, David Miller wrote:
> From: Petri Gynther
> Date: Fri, 12 Aug 2016 17:15:30 -0700
>
>> Root cause:
>> mwifiex driver calls is_zero_ether_addr() against byte-aligned address:
>
> MAC addresses really must be 16-bit aligned to be used with any of the
> ethernet addr
From: Petri Gynther
Date: Fri, 12 Aug 2016 17:15:30 -0700
> Root cause:
> mwifiex driver calls is_zero_ether_addr() against byte-aligned address:
MAC addresses really must be 16-bit aligned to be used with any of the
ethernet address manipulation and test interfaces.
Therefore this driver shoul
$ iwconfig mlan0 essid MySSID
[ 36.93] Path: /sbin/iwconfig
[ 36.93] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
[ 36.94] task: 866f83a0 ti: 866a6000 task.ti: 866a6000
[ 36.94]
[ECR ]: 0x00230400 => Misaligned r/w from 0x8677f403
[ 36.96] [EFA ]: 0x8677f403
Add a generic routine to test if possibly unaligned to u16
Ethernet address is a zero address.
If CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set, use
slightly faster generic routine is_zero_ether_addr(),
otherwise use byte accesses.
This is v2 of the original patch:
[PATCH] Modify is_zero_ether_ad
Hi Petri,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.8-rc1 next-20160812]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Petri-Gynther/Modify-is_zero_ether_addr-to
Hi Petri,
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.8-rc1 next-20160812]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Petri-Gynther/Modify-is_zero_ether_addr
Hi Joe,
On Fri, Aug 12, 2016 at 5:28 PM, Joe Perches wrote:
> On Fri, 2016-08-12 at 17:15 -0700, Petri Gynther wrote:
>> $ iwconfig mlan0 essid MySSID
>> [ 36.93] Path: /sbin/iwconfig
>> [ 36.93] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
>> [ 36.94] task: 866f83a0 ti:
On Fri, 2016-08-12 at 17:15 -0700, Petri Gynther wrote:
> $ iwconfig mlan0 essid MySSID
> [ 36.93] Path: /sbin/iwconfig
> [ 36.93] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
> [ 36.94] task: 866f83a0 ti: 866a6000 task.ti: 866a6000
> [ 36.94]
> [ECR ]: 0x00230400 =
The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
channel, as such it should be a SMD client. This patch makes this
transition, now that we have the necessary frameworks available.
Signed-off-by: Bjorn Andersson
---
Resending this as the dependencies and the devicetree binding
Using the software based channel scan mechanism from mac80211 keeps us
offline for 10-15 second, we should instead issue a start_scan/end_scan
on each channel reducing this time.
Signed-off-by: Bjorn Andersson
---
It's been a while since I posted this as an RFC, I have not received any
comments
$ iwconfig mlan0 essid MySSID
[ 36.93] Path: /sbin/iwconfig
[ 36.93] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
[ 36.94] task: 866f83a0 ti: 866a6000 task.ti: 866a6000
[ 36.94]
[ECR ]: 0x00230400 => Misaligned r/w from 0x8677f403
[ 36.96] [EFA ]: 0x8677f403
Hi Johannes,
>
No, I don't see a fault in the logic. I just think it's misleading. You
make the code look like it relies on filter_wiphy != 0, but then you go
and treat filter_wiphy==0 as a valid case.
It relies on a sentry condition with all 3 variables being zero, not
just filter_wiphy. Th
This patch allows GET_INTERFACE dumps to be filtered based on
NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV. The documentation for
GET_INTERFACE mentions that this is possible:
"Request an interface's configuration; either a dump request on
a %NL80211_ATTR_WIPHY or ..."
However, this behavior has not b
sunbing writes:
> On Aug 11, 2016, at 23:25, Jes Sorensen wrote:
>
>> Bing Sun writes:
>>> Fixed sparse parse error:
>>> Expected constant expression in case statement.
>>>
>>> Signed-off-by: Bing Sun
>>> ---
>>> drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +--
>>> 1 file changed,
I am seeing this in my 4.7 kernel while debugging QCA 9884 firmware that
is crashing very often. Looks like this must exacerbate some race condition,
as ar->txqs appears to have entries in it that have been deleted already.
Just in case someone has already worked on this, please let me know. I'
> I was just thinking out loud :)
cfg80211_validate_beacon_int -> cfg80211_iter_combinations shall be invoked for
the interface combinations , currently. diff_beacon_int_gcd_min is applicable
for the interface combinations and am not sure how can we validate this for a
single interface . This s
On Fri, 2016-08-12 at 11:34 +, Undekari, Sunil Dutt wrote:
> >
> > The clarification that it also represents the minimum for a single
> > beacon interval would make some sense to me, but at the same time
> > it can't be used only for that, so perhaps separating a minimum out
> > >(rather than
>The clarification that it also represents the minimum for a single beacon
>interval would make some sense to me, but at the same time it can't be used
>only for that, so perhaps separating a minimum out >(rather than using the
>hard-coded minimum of 10) would make sense.
Sorry . Could not get y
Am 7. August 2016 13:41:04 MESZ, schrieb Arend van Spriel
:
>On 06-08-16 16:12, Jörg Krause wrote:
>> Hi all,
>
>A bit weird email format making it a bit hard to determine where your
>last reply starts...
Sorry for my bad mobile mail client. I hope this one can handle in line
comments.
>
>>
On Fri, 2016-08-12 at 14:09 +0530, Purushottam Kushwaha wrote:
>
> * @radar_detect_regions: bitmap of regions supported for radar
> detection
> + * @diff_beacon_int_gcd: This interface combination supports
> different beacon
> + * intervals in multiple of GCD value.
I think you should add "Le
Hi Dave,
This first pull request is pretty small, but there's no point
in hanging on to it for long, so here it goes anyway. Nothing
all that interesting, I think.
We might have a bunch of new APIs that were promised to me
coming up soon, for new features, but I don't know how quickly
that's actu
On 08/11/2016 09:27 PM, Felix Fietkau wrote:
> On 2016-08-11 18:05, Zefir Kurtisi wrote:
>> On 08/04/2016 11:49 PM, Felix Fietkau 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
>>> statu
This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through diff_beacon_int_gcd (u32).
The configured BI for a specific interface must be a multiple of this
value and also the active b
On Fri, Aug 12, 2016 at 07:17:38AM +, Amitkumar Karwar wrote:
> The problem looks strange. The patch just splits mwifiex_check_fw_status()
> and increases poll count. It should not have any side-effects.
> Our code used to check winner status before this patch also.
Ok, I misread the patch. A
Hi Stanislaw,
> From: Stanislaw Gruszka [mailto:sgrus...@redhat.com]
> Sent: Thursday, August 11, 2016 5:59 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> Hi
>
> On Thu, Aug 11, 2016 at 10:21:58
31 matches
Mail list logo
