* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: Petri Gynther @ 2016-08-13 1:41 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-wireless, kvalo, David Miller, akarwar
In-Reply-To: <1471048085.18251.25.camel@perches.com>
Hi Joe,
On Fri, Aug 12, 2016 at 5:28 PM, Joe Perches <joe@perches.com> wrote:
> On Fri, 2016-08-12 at 17:15 -0700, Petri Gynther wrote:
>> $ iwconfig mlan0 essid MySSID
>> [ 36.930000] Path: /sbin/iwconfig
>> [ 36.930000] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
>> [ 36.940000] task: 866f83a0 ti: 866a6000 task.ti: 866a6000
>> [ 36.940000]
>> [ECR ]: 0x00230400 => Misaligned r/w from 0x8677f403
>> [ 36.960000] [EFA ]: 0x8677f403
>> [ 36.960000] [BLINK ]: mwifiex_scan_networks+0x17a/0x198c [mwifiex]
>> [ 36.960000] [ERET ]: mwifiex_scan_networks+0x18a/0x198c [mwifiex]
>> [ 36.980000] [STAT32]: 0x00000206 : K E2 E1
>> [ 36.980000] BTA: 0x700736e2 SP: 0x866a7d0c FP: 0x5faddc84
>> [ 37.000000] LPS: 0x806a37ec LPE: 0x806a37fa LPC: 0x00000000
>> [ 37.000000] r00: 0x8677f401 r01: 0x8668aa08 r02: 0x00000001
>> r03: 0x00000000 r04: 0x8668b600 r05: 0x8677f406
>> r06: 0x8702b600 r07: 0x00000000 r08: 0x8702b600
>> r09: 0x00000000 r10: 0x870b3b00 r11: 0x00000000
>> r12: 0x00000000
>> [ 37.040000]
>> [ 37.040000] Stack Trace:
>> [ 37.040000] mwifiex_scan_networks+0x18a/0x198c [mwifiex]
>>
>> Root cause:
>> mwifiex driver calls is_zero_ether_addr() against byte-aligned address:
>>
>> drivers/net/wireless/marvell/mwifiex/fw.h:
>> struct mwifiex_scan_cmd_config {
>> /*
>> * BSS mode to be sent in the firmware command
>> */
>> u8 bss_mode;
>>
>> /* Specific BSSID used to filter scan results in the firmware */
>> u8 specific_bssid[ETH_ALEN];
>>
>> ...
>> } __packed;
>>
>> drivers/net/wireless/marvell/mwifiex/scan.c:
>> mwifiex_config_scan(..., struct mwifiex_scan_cmd_config *scan_cfg_out, ...)
>> ...
>> if (adapter->ext_scan &&
>> !is_zero_ether_addr(scan_cfg_out->specific_bssid)) {
>> ...
>> }
>>
>> Since firmware-related struct mwifiex_scan_cmd_config cannot be changed,
>> modify is_zero_ether_addr() to handle byte-aligned addresses.
>
> Or add is_zero_ether_addr_unaligned and use it here.
>
>> Cc: Kalle Valo <kvalo@codeaurora.org>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Joe Perches <joe@perches.com>
>> Cc: Amitkumar Karwar <akarwar@marvell.com>
>> Signed-off-by: Petri Gynther <pgynther@google.com>
>> ---
>> include/linux/etherdevice.h | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
>> index 37ff4a6..0cfd243 100644
>> --- a/include/linux/etherdevice.h
>> +++ b/include/linux/etherdevice.h
>> @@ -90,11 +90,13 @@ static inline bool is_link_local_ether_addr(const u8 *addr)
>> * @addr: Pointer to a six-byte array containing the Ethernet address
>> *
>> * Return true if the address is all zeroes.
>> - *
>> - * Please note: addr must be aligned to u16.
>> */
>> static inline bool is_zero_ether_addr(const u8 *addr)
>> {
>> + if ((u32)addr & 0x1)
>> + return (addr[0] | addr[1] | addr[2] | addr[3] | addr[4] |
>> + addr[5]) == 0;
>> +
>
> So why skip the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> optimization below?
>
>> #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>> return ((*(const u32 *)addr) | (*(const u16 *)(addr + 4))) == 0;
>> #else
>
> How about adding:
>
> static inline bool is_zero_ether_addr_unaligned(const u8 *addr)
> {
> #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> return is_zero_ether_addr(addr);
> #else
> return addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5];
> #endif
> }
>
I like your idea. I'll add is_zero_ether_addr_unaligned() and use it
in mwifiex driver.
^ permalink raw reply
* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: kbuild test robot @ 2016-08-13 2:08 UTC (permalink / raw)
To: Petri Gynther
Cc: kbuild-all, linux-wireless, kvalo, davem, joe, akarwar,
Petri Gynther
In-Reply-To: <1471047330-8153-1-git-send-email-pgynther@google.com>
[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]
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-to-handle-byte-aligned-addresses/20160813-081835
config: x86_64-randconfig-n0-08130925 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:4:0,
from arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from net/llc/llc_if.c:14:
include/linux/etherdevice.h: In function 'is_zero_ether_addr':
include/linux/etherdevice.h:96:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if ((u32)addr & 0x1)
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> include/linux/etherdevice.h:96:2: note: in expansion of macro 'if'
if ((u32)addr & 0x1)
^~
include/linux/etherdevice.h:96:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if ((u32)addr & 0x1)
^
include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> include/linux/etherdevice.h:96:2: note: in expansion of macro 'if'
if ((u32)addr & 0x1)
^~
include/linux/etherdevice.h:96:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if ((u32)addr & 0x1)
^
include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> include/linux/etherdevice.h:96:2: note: in expansion of macro 'if'
if ((u32)addr & 0x1)
^~
vim +/if +96 include/linux/etherdevice.h
80 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
81 return (((*(const u32 *)addr) ^ (*(const u32 *)b)) |
82 (__force int)((a[2] ^ b[2]) & m)) == 0;
83 #else
84 return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | ((a[2] ^ b[2]) & m)) == 0;
85 #endif
86 }
87
88 /**
89 * is_zero_ether_addr - Determine if give Ethernet address is all zeros.
90 * @addr: Pointer to a six-byte array containing the Ethernet address
91 *
92 * Return true if the address is all zeroes.
93 */
94 static inline bool is_zero_ether_addr(const u8 *addr)
95 {
> 96 if ((u32)addr & 0x1)
97 return (addr[0] | addr[1] | addr[2] | addr[3] | addr[4] |
98 addr[5]) == 0;
99
100 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
101 return ((*(const u32 *)addr) | (*(const u16 *)(addr + 4))) == 0;
102 #else
103 return (*(const u16 *)(addr + 0) |
104 *(const u16 *)(addr + 2) |
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 25700 bytes --]
^ permalink raw reply
* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: kbuild test robot @ 2016-08-13 2:26 UTC (permalink / raw)
To: Petri Gynther
Cc: kbuild-all, linux-wireless, kvalo, davem, joe, akarwar,
Petri Gynther
In-Reply-To: <1471047330-8153-1-git-send-email-pgynther@google.com>
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
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-handle-byte-aligned-addresses/20160813-081835
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
In file included from arch/powerpc/kernel/prom_parse.c:6:0:
include/linux/etherdevice.h: In function 'is_zero_ether_addr':
>> include/linux/etherdevice.h:96:6: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
if ((u32)addr & 0x1)
^
cc1: all warnings being treated as errors
vim +96 include/linux/etherdevice.h
90 * @addr: Pointer to a six-byte array containing the Ethernet address
91 *
92 * Return true if the address is all zeroes.
93 */
94 static inline bool is_zero_ether_addr(const u8 *addr)
95 {
> 96 if ((u32)addr & 0x1)
97 return (addr[0] | addr[1] | addr[2] | addr[3] | addr[4] |
98 addr[5]) == 0;
99
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 22404 bytes --]
^ permalink raw reply
* [PATCH 1/2] etherdevice: add is_zero_ether_addr_unaligned()
From: Petri Gynther @ 2016-08-13 2:59 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, davem, joe, akarwar, Petri Gynther
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_addr() to handle byte-aligned addresses
Per Joe's suggestion -- instead of modifying is_zero_ether_addr() --
add is_zero_ether_addr_unaligned() and use it where needed.
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joe Perches <joe@perches.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Petri Gynther <pgynther@google.com>
---
include/linux/etherdevice.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 37ff4a6..f609691 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -105,6 +105,21 @@ static inline bool is_zero_ether_addr(const u8 *addr)
}
/**
+ * is_zero_ether_addr_unaligned - Determine if given Ethernet address is all zeros.
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Return true if the address is all zeroes.
+ */
+static inline bool is_zero_ether_addr_unaligned(const u8 *addr)
+{
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
+ return is_zero_ether_addr(addr);
+#else
+ return (addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]) == 0;
+#endif
+}
+
+/**
* is_multicast_ether_addr - Determine if the Ethernet address is a multicast.
* @addr: Pointer to a six-byte array containing the Ethernet address
*
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()
From: Petri Gynther @ 2016-08-13 3:00 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, davem, joe, akarwar, Petri Gynther
In-Reply-To: <1471057200-58166-1-git-send-email-pgynther@google.com>
$ iwconfig mlan0 essid MySSID
[ 36.930000] Path: /sbin/iwconfig
[ 36.930000] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
[ 36.940000] task: 866f83a0 ti: 866a6000 task.ti: 866a6000
[ 36.940000]
[ECR ]: 0x00230400 => Misaligned r/w from 0x8677f403
[ 36.960000] [EFA ]: 0x8677f403
[ 36.960000] [BLINK ]: mwifiex_scan_networks+0x17a/0x198c [mwifiex]
[ 36.960000] [ERET ]: mwifiex_scan_networks+0x18a/0x198c [mwifiex]
[ 36.980000] [STAT32]: 0x00000206 : K E2 E1
[ 36.980000] BTA: 0x700736e2 SP: 0x866a7d0c FP: 0x5faddc84
[ 37.000000] LPS: 0x806a37ec LPE: 0x806a37fa LPC: 0x00000000
[ 37.000000] r00: 0x8677f401 r01: 0x8668aa08 r02: 0x00000001
r03: 0x00000000 r04: 0x8668b600 r05: 0x8677f406
r06: 0x8702b600 r07: 0x00000000 r08: 0x8702b600
r09: 0x00000000 r10: 0x870b3b00 r11: 0x00000000
r12: 0x00000000
[ 37.040000]
[ 37.040000] Stack Trace:
[ 37.040000] mwifiex_scan_networks+0x18a/0x198c [mwifiex]
Root cause:
mwifiex driver calls is_zero_ether_addr() against byte-aligned address:
drivers/net/wireless/marvell/mwifiex/fw.h:
struct mwifiex_scan_cmd_config {
/*
* BSS mode to be sent in the firmware command
*/
u8 bss_mode;
/* Specific BSSID used to filter scan results in the firmware */
u8 specific_bssid[ETH_ALEN];
...
} __packed;
drivers/net/wireless/marvell/mwifiex/scan.c:
mwifiex_config_scan(..., struct mwifiex_scan_cmd_config *scan_cfg_out, ...)
...
if (adapter->ext_scan &&
!is_zero_ether_addr(scan_cfg_out->specific_bssid)) {
...
}
Since firmware-related struct mwifiex_scan_cmd_config cannot be changed,
we need to use the new function is_zero_ether_addr_unaligned() here.
This is v2 of the original patch:
[PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
Per Joe's suggestion -- instead of modifying is_zero_ether_addr() --
add is_zero_ether_addr_unaligned() and use it where needed.
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joe Perches <joe@perches.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index bc5e52c..d648c88 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -883,7 +883,8 @@ mwifiex_config_scan(struct mwifiex_private *priv,
sizeof(scan_cfg_out->specific_bssid));
if (adapter->ext_scan &&
- !is_zero_ether_addr(scan_cfg_out->specific_bssid)) {
+ !is_zero_ether_addr_unaligned(
+ scan_cfg_out->specific_bssid)) {
bssid_tlv =
(struct mwifiex_ie_types_bssid_list *)tlv_pos;
bssid_tlv->header.type = cpu_to_le16(TLV_TYPE_BSSID);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: David Miller @ 2016-08-13 3:26 UTC (permalink / raw)
To: pgynther; +Cc: linux-wireless, kvalo, joe, akarwar
In-Reply-To: <1471047330-8153-1-git-send-email-pgynther@google.com>
From: Petri Gynther <pgynther@google.com>
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 should do whatever it takes to avoid passing
a byte-aligned MAC address anywhere.
We _SHOULD NOT_ add support for byte aligned addresses to these
interfaces, nor add routines which by-name can handle them.
Fix this driver instead of polluting out common interfaces
unnecessarily.
Thanks.
^ permalink raw reply
* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: Petri Gynther @ 2016-08-13 3:44 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, kvalo, Joe Perches, Amitkumar Karwar
In-Reply-To: <20160812.202613.197744153887748230.davem@davemloft.net>
On Fri, Aug 12, 2016 at 8:26 PM, David Miller <davem@davemloft.net> wrote:
> From: Petri Gynther <pgynther@google.com>
> 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 should do whatever it takes to avoid passing
> a byte-aligned MAC address anywhere.
>
> We _SHOULD NOT_ add support for byte aligned addresses to these
> interfaces, nor add routines which by-name can handle them.
>
ether_addr_equal_unaligned() exists.
commit 73eaef87e98a96fe8b8a586f916b2721bf512efa
Author: Joe Perches <joe@perches.com>
Date: Fri Dec 6 14:21:01 2013 -0800
etherdevice: Add ether_addr_equal_unaligned
Add a generic routine to test if possibly unaligned
to u16 Ethernet addresses are equal.
If CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set,
this uses the slightly faster generic routine
ether_addr_equal, otherwise this uses memcmp.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
> Fix this driver instead of polluting out common interfaces
> unnecessarily.
>
Amitkumar -- is this fixable in mwifiex driver and firmware? It looks
like your firmware expects u8 specific_bssid[ETH_ALEN] at byte offset
1, per struct mwifiex_scan_cmd_config definition.
I'll let Marvell take it from here.
> Thanks.
^ permalink raw reply
* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: Joe Perches @ 2016-08-13 4:00 UTC (permalink / raw)
To: David Miller, pgynther; +Cc: linux-wireless, kvalo, akarwar
In-Reply-To: <20160812.202613.197744153887748230.davem@davemloft.net>
On Fri, 2016-08-12 at 20:26 -0700, David Miller wrote:
> From: Petri Gynther <pgynther@google.com>
> 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 should do whatever it takes to avoid passing
> a byte-aligned MAC address anywhere.
>
> We _SHOULD NOT_ add support for byte aligned addresses to these
> interfaces, nor add routines which by-name can handle them.
My recollection is that batman uses unaligned addresses
and some form of _unaligned tests are required there.
It seems that other wireless drivers also use _unaligned
in various forms.
> Fix this driver instead of polluting out common interfaces
> unnecessarily.
One solution might be to copy a hardware interface structure
to another struct with appropriate alignment.
^ permalink raw reply
* Re: [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
From: David Miller @ 2016-08-13 4:05 UTC (permalink / raw)
To: joe; +Cc: pgynther, linux-wireless, kvalo, akarwar
In-Reply-To: <1471060827.3467.5.camel@perches.com>
From: Joe Perches <joe@perches.com>
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.
^ permalink raw reply
* Re: [PATCH 1/2] etherdevice: add is_zero_ether_addr_unaligned()
From: Joe Perches @ 2016-08-13 4:11 UTC (permalink / raw)
To: Petri Gynther, linux-wireless; +Cc: kvalo, davem, akarwar
In-Reply-To: <1471057200-58166-1-git-send-email-pgynther@google.com>
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)
> +{
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + return is_zero_ether_addr(addr);
> +#else
> + return (addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]) == 0;
> +#endif
Because the return is bool, the == 0 is unnecessary.
^ permalink raw reply
* Re: [PATCH 1/2] etherdevice: add is_zero_ether_addr_unaligned()
From: Petri Gynther @ 2016-08-13 4:40 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-wireless, kvalo, David Miller, Amitkumar Karwar
In-Reply-To: <1471061519.3467.7.camel@perches.com>
On Fri, Aug 12, 2016 at 9:11 PM, Joe Perches <joe@perches.com> 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
> []
>> +static inline bool is_zero_ether_addr_unaligned(const u8 *addr)
>> +{
>> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>> + return is_zero_ether_addr(addr);
>> +#else
>> + return (addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]) == 0;
>> +#endif
>
> Because the return is bool, the == 0 is unnecessary.
>
But, we need to return true (1) when the bitwise OR result is zero.
Same logic as in is_zero_ether_addr().
^ permalink raw reply
* Re: [PATCH 1/2] etherdevice: add is_zero_ether_addr_unaligned()
From: Joe Perches @ 2016-08-13 4:59 UTC (permalink / raw)
To: Petri Gynther; +Cc: linux-wireless, kvalo, David Miller, Amitkumar Karwar
In-Reply-To: <CAGXr9JHXdQxObUJC_=4ZaJKmvFS+QygK8ytMtXCJJws62a8S7A@mail.gmail.com>
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.
^ permalink raw reply
* [PATCH v7] cfg80211: Provision to allow the support for different beacon intervals
From: Purushottam Kushwaha @ 2016-08-13 5:02 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, djindal, pkushwah
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 different interfaces must be same.
> 0 - different beacon intervals must have a GCD that's at
least as big as this value.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
include/net/cfg80211.h | 9 ++++++++-
include/uapi/linux/nl80211.h | 8 ++++++--
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 13 ++++++++++---
net/wireless/util.c | 46 ++++++++++++++++++++++++++++++++++++++++++--
5 files changed, 69 insertions(+), 9 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9c23f4d3..c3dd46c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2939,6 +2939,11 @@ struct ieee80211_iface_limit {
* only in special cases.
* @radar_detect_widths: bitmap of channel widths supported for radar detection
* @radar_detect_regions: bitmap of regions supported for radar detection
+ * @diff_beacon_int_gcd_min: This interface combination supports different
+ * beacon intervals.
+ * = 0 - all beacon intervals for different interface must be same.
+ * > 0 - different beacon intervals must have a GCD that's at
+ * least as big as this value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
@@ -2959,7 +2964,7 @@ struct ieee80211_iface_limit {
* };
*
*
- * 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
+ * 2. Allow #{AP, P2P-GO} <= 8, diff BI min gcd = 10, channels = 1, 8 total:
*
* struct ieee80211_iface_limit limits2[] = {
* { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
@@ -2970,6 +2975,7 @@ struct ieee80211_iface_limit {
* .n_limits = ARRAY_SIZE(limits2),
* .max_interfaces = 8,
* .num_different_channels = 1,
+ * .diff_beacon_int_gcd_min = 10,
* };
*
*
@@ -2997,6 +3003,7 @@ struct ieee80211_iface_combination {
bool beacon_int_infra_match;
u8 radar_detect_widths;
u8 radar_detect_regions;
+ u32 diff_beacon_int_gcd_min;
};
struct ieee80211_txrx_stypes {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2206941..894d131 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4203,6 +4203,9 @@ enum nl80211_iface_limit_attrs {
* of supported channel widths for radar detection.
* @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute containing the bitmap
* of supported regulatory regions for radar detection.
+ * @NL80211_IFACE_COMB_DIFF_BI_GCD_MIN: u32 attribute specifying the minimum GCD
+ * of different beacon intervals supported by all the interface combinations
+ * in this group (if not present, all beacon interval must match).
* @NUM_NL80211_IFACE_COMB: number of attributes
* @MAX_NL80211_IFACE_COMB: highest attribute number
*
@@ -4210,8 +4213,8 @@ enum nl80211_iface_limit_attrs {
* limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI, channels = 1, max = 2
* => allows an AP and a STA that must match BIs
*
- * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
- * => allows 8 of AP/GO
+ * numbers = [ #{AP, P2P-GO} <= 8 ], diff BI min gcd, channels = 1, max = 8,
+ * => allows 8 of AP/GO that can have BI gcd >= min gcd
*
* numbers = [ #{STA} <= 2 ], channels = 2, max = 2
* => allows two STAs on different channels
@@ -4237,6 +4240,7 @@ enum nl80211_if_combination_attrs {
NL80211_IFACE_COMB_NUM_CHANNELS,
NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
+ NL80211_IFACE_COMB_DIFF_BI_GCD_MIN,
/* keep last */
NUM_NL80211_IFACE_COMB,
diff --git a/net/wireless/core.h b/net/wireless/core.h
index eee9144..5fffe58 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
u32 *mask);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int);
+ enum nl80211_iftype iftype, u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4997857..c1741d9 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1020,6 +1020,10 @@ static int nl80211_put_iface_combinations(struct wiphy *wiphy,
nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
c->radar_detect_regions)))
goto nla_put_failure;
+ if (c->diff_beacon_int_gcd_min &&
+ nla_put_u32(msg, NL80211_IFACE_COMB_DIFF_BI_GCD_MIN,
+ c->diff_beacon_int_gcd_min))
+ goto nla_put_failure;
nla_nest_end(msg, nl_combi);
}
@@ -3433,7 +3437,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, params.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
+ params.beacon_interval);
if (err)
return err;
@@ -7768,7 +7773,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
+ ibss.beacon_interval);
if (err)
return err;
@@ -9245,7 +9251,8 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_MESH_POINT,
+ setup.beacon_interval);
if (err)
return err;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0675f51..844f02a 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1553,20 +1553,62 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
}
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
+struct diff_beacon_int {
+ u32 gcd;
+ bool valid;
+};
+
+static void
+cfg80211_validate_diff_beacon_int(const struct ieee80211_iface_combination *c,
+ void *data)
+{
+ struct diff_beacon_int *diff_bi = data;
+
+ if (c->diff_beacon_int_gcd_min &&
+ (diff_bi->gcd >= c->diff_beacon_int_gcd_min))
+ diff_bi->valid = true;
+}
+
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int)
+ enum nl80211_iftype iftype, u32 beacon_int)
{
struct wireless_dev *wdev;
int res = 0;
+ int iftype_num[NUM_NL80211_IFTYPES];
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ memset(iftype_num, 0, sizeof(iftype_num));
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+ if (!wdev->beacon_interval)
+ continue;
+ iftype_num[wdev->iftype]++;
+ }
+ iftype_num[iftype]++;
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
if (wdev->beacon_interval != beacon_int) {
- res = -EINVAL;
+ struct diff_beacon_int diff_bi = {
+ wdev->beacon_interval,
+ false,
+ };
+
+ /* Get the GCD */
+ while (beacon_int != 0) {
+ u32 tmp_bi = beacon_int;
+ beacon_int = diff_bi.gcd % beacon_int;
+ diff_bi.gcd = tmp_bi;
+ }
+
+ res = cfg80211_iter_combinations(&rdev->wiphy, 0, 0, iftype_num,
+ cfg80211_validate_diff_beacon_int,
+ &diff_bi);
+ if (res)
+ return res;
+ res = (diff_bi.valid) ? 0 : -EINVAL;
break;
}
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
From: sunbing @ 2016-08-13 9:26 UTC (permalink / raw)
To: Jes Sorensen
Cc: Larry.Finger, gregkh, linux-wireless, devel, linux-kernel,
sunbing.linux
In-Reply-To: <wrfj7fbmawl1.fsf@redhat.com>
On Aug 12, 2016, at 22:30, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> sunbing <sunbing@redflag-linux.com> writes:
>> On Aug 11, 2016, at 23:25, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>>
>>> Bing Sun <sunbing@redflag-linux.com> writes:
>>>> Fixed sparse parse error:
>>>> Expected constant expression in case statement.
>>>>
>>>> Signed-off-by: Bing Sun <sunbing@redflag-linux.com>
>>>> ---
>>>> drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +++++------
>>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> index b8848c2..f30d5d2 100644
>>>> --- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> +++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> @@ -283,14 +283,13 @@ static u32 rtw_classify8021d(struct sk_buff *skb)
>>>> */
>>>> if (skb->priority >= 256 && skb->priority <= 263)
>>>> return skb->priority - 256;
>>>> - switch (skb->protocol) {
>>>> - case htons(ETH_P_IP):
>>>> +
>>>> + if (skb->protocol == htons(ETH_P_IP)) {
>>>> dscp = ip_hdr(skb)->tos & 0xfc;
>>>> - break;
>>>> - default:
>>>> - return 0;
>>>> + return dscp >> 5;
>>>> }
>>>> - return dscp >> 5;
>>>> +
>>>> + return 0;
>>>> }
>>>
>>> Pardon me here, but I find it really hard to see how this change is an
>>> improvement over the old code in any shape or form.
>>>
>>> Jes
>>
>> There is no functional improvement.
>> But before this patch, when we do: make C=1 M=drivers/staging/rtl8723au/
>> An error output:
>> drivers/staging/rtl8723au//os_dep/os_intfs.c:287:14: error: Expected
>> constant expression in case statement
>> To avoid sparse parse error, a case statement converts to an if statement.
>> So we got this patch.
>
> Hello
>
> I understand this part, but it seems to me we are changing the code due
> to a broken test case in sparse. Does the warning go away if you use
> __constant_htons() instead of htons()?
>
> Jes
Thanks for your guidance.
1. If I use __constant_htons, checkpatch.pl will warning:
WARNING: __constant_htons should be htons
2. In os_intfs.c: rtw_classify8021d, there are only one case statement and a
default statement. So, convert "switch case" to "if else" is more readable in my opinion.
So, I pushed this patch.
There are some patches convert use of __constant_htons to htons in kernel logs.
Will there be a new patch convert to htons in the future if I use __constant_htons now ?
After search through kernel code, there are 158 "case htons(...)" statements and
2 "case __constant_htons(...)" statements. Does this mean we can ignore sparse
error and use "case htons(...)" ?
It makes me confused. More help, please.
Regards.
^ permalink raw reply
* Re: [PATCH 00/16] net: don't print error when allocating urb fails
From: David Miller @ 2016-08-13 21:55 UTC (permalink / raw)
To: wsa-dev
Cc: linux-usb, brcm80211-dev-list.pdl, linux-can, linux-wireless,
netdev
In-Reply-To: <1470949539-25392-1-git-send-email-wsa-dev@sang-engineering.com>
From: Wolfram Sang <wsa-dev@sang-engineering.com>
Date: Thu, 11 Aug 2016 23:05:19 +0200
> This per-subsystem series is part of a tree wide cleanup. usb_alloc_urb() uses
> kmalloc which already prints enough information on failure. So, let's simply
> remove those "allocation failed" messages from drivers like we did already for
> other -ENOMEM cases. gkh acked this approach when we talked about it at LCJ in
> Tokyo a few weeks ago.
Series applied to net-next, thank you.
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-08-12
From: David Miller @ 2016-08-13 22:11 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1470993646-14778-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 12 Aug 2016 11:20:45 +0200
> 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 actually going to happen.
>
> Let me know if there's any problem.
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
From: Joe Perches @ 2016-08-14 12:07 UTC (permalink / raw)
To: sunbing, Jes Sorensen
Cc: Larry.Finger, gregkh, linux-wireless, devel, linux-kernel,
sunbing.linux, Johannes Berg
In-Reply-To: <E0CA1BD5-A2ED-4FDC-8E58-8024E2F3C24C@redflag-linux.com>
On Sat, 2016-08-13 at 17:26 +0800, sunbing wrote:
> On Aug 12, 2016, at 22:30, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> > sunbing <sunbing@redflag-linux.com> writes:
> > > On Aug 11, 2016, at 23:25, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> > > > Bing Sun <sunbing@redflag-linux.com> writes:
> > > > >
> > > > > Fixed sparse parse error:
> > > > > Expected constant expression in case statement.
[]
> > > > Pardon me here, but I find it really hard to see how this change is an
> > > > improvement over the old code in any shape or form.
> > > There is no functional improvement.
> > > But before this patch, when we do: make C=1 M=drivers/staging/rtl8723au/
> > > An error output:
> > > drivers/staging/rtl8723au//os_dep/os_intfs.c:287:14: error: Expected
> > > constant expression in case statement
> > > To avoid sparse parse error, a case statement converts to an if statement.
> > > So we got this patch.
> > Hello
> >
> > I understand this part, but it seems to me we are changing the code due
> > to a broken test case in sparse. Does the warning go away if you use
> > __constant_htons() instead of htons()?
> >
> > Jes
> Thanks for your guidance.
>
> 1. If I use __constant_htons, checkpatch.pl will warning:
> WARNING: __constant_htons should be htons
>
> 2. In os_intfs.c: rtw_classify8021d, there are only one case statement and a
> default statement. So, convert "switch case" to "if else" is more readable in my opinion.
>
> So, I pushed this patch.
>
> There are some patches convert use of __constant_htons to htons in kernel logs.
> Will there be a new patch convert to htons in the future if I use __constant_htons now ?
>
> After search through kernel code, there are 158 "case htons(...)" statements and
> 2 "case __constant_htons(...)" statements. Does this mean we can ignore sparse
> error and use "case htons(...)" ?
>
> It makes me confused. More help, please.
It's a sparse defect.
Try again after patching sparse with Jes' patch:
http://marc.info/?l=linux-sparse&m=147091200720267&w=3
^ permalink raw reply
* Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
From: Johannes Berg @ 2016-08-14 12:15 UTC (permalink / raw)
To: Joe Perches, sunbing, Jes Sorensen
Cc: Larry.Finger, gregkh, linux-wireless, devel, linux-kernel,
sunbing.linux
In-Reply-To: <1471176423.5201.7.camel@perches.com>
> It's a sparse defect.
>
> Try again after patching sparse with Jes' patch:
> http://marc.info/?l=linux-sparse&m=147091200720267&w=3
Mine, not Jes's ;-)
But there's another patch going into the kernel to fix it:
https://www.ozlabs.org/~akpm/mmotm/broken-out/byteswap-dont-use-__builtin_bswap-with-sparse.patch
johannes
^ permalink raw reply
* Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
From: Joe Perches @ 2016-08-14 12:23 UTC (permalink / raw)
To: Johannes Berg, sunbing, Jes Sorensen
Cc: Larry.Finger, gregkh, linux-wireless, devel, linux-kernel,
sunbing.linux
In-Reply-To: <1471176951.5903.6.camel@sipsolutions.net>
On Sun, 2016-08-14 at 14:15 +0200, Johannes Berg wrote:
> >
> > It's a sparse defect.
> >
> > Try again after patching sparse with Jes' patch:
> > http://marc.info/?l=linux-sparse&m=147091200720267&w=3
> Mine, not Jes's ;-)
Right, sorry 'bout that.
> But there's another patch going into the kernel to fix it:
>
> https://www.ozlabs.org/~akpm/mmotm/broken-out/byteswap-dont-use-__builtin_bswap-with-sparse.patch
Thanks.
Maybe this test should be sparse version checked after
sparse is updated.
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-14 18:11 UTC (permalink / raw)
To: Theodore Ts'o, Pan, Miaoqing, Stephan Mueller,
Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160810234425.GG10523@thunk.org>
Hey Ted,
On Wed, Aug 10, 2016 at 07:44:25PM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 02:04:44PM +0000, Jason Cooper wrote:
> > iiuc, Ted, you're saying using the hw_random framework would be
> > disasterous because despite most drivers having a default quality of 0,
> > rngd assumes 1 bit of entropy for every bit read?
>
> Sorry, what I was trying to say (but failed) was that bypassing the
> hwrng framework and injecting entropy directly the entropy pool was
> disatrous.
Ok, whew. :)
> > Thankfully, most hw_random drivers don't set the quality. So unless the
> > user sets the default_quality param, it's zero.
>
> The fact that this is "most" and not "all" does scare me a little.
My recent grep showed that only virtio-rng set it to a non-zero value.
> As far as I'm concerned *all* hw_random drivers should set quality to
> zero, since it should be up to the system administrator.
Agreed.
Gathering conversation about this from a few related threads, I have one
concern. Apparently there is some confusion in userspace consumers of
/dev/hwrng data as to the quality of it. Specifically, rngd (spotted by
Stephan Mueller) appears to assume 1bit of entropy per 1 bit read. :-/
So, while moving ath9k-rng to the hwrng framework makes complete sense
internally, it's not so good for existing userspace assumptions. I'd
think that timeriomem-rng falls in this same category.
In light of this, do you think it's worth the effort (I'm volunteering)
to create a subcategory of hwrng drivers that are 'environemntal' rngs?
They can contribute to the kernel entropy pools, but not to /dev/hwrng.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
From: Johannes Berg @ 2016-08-15 6:07 UTC (permalink / raw)
To: Joe Perches, sunbing, Jes Sorensen
Cc: Larry.Finger, gregkh, linux-wireless, devel, linux-kernel,
sunbing.linux
In-Reply-To: <1471177398.5201.9.camel@perches.com>
On Sun, 2016-08-14 at 05:23 -0700, Joe Perches wrote:
>
> Maybe this test should be sparse version checked after
> sparse is updated.
*If* sparse ever gets updated :) I don't think it's been updated much
lately.
That said, I'm not even sure how, and what version, etc. so obviously
that'd have to be done after the fact. But since nobody will ever
compile the kernel with sparse's code generator, it also doesn't matter
anyway.
johannes
^ permalink raw reply
* [PATCH] NFC: Delete owner assignment
From: SF Markus Elfring @ 2016-08-15 7:12 UTC (permalink / raw)
To: linux-nfc, linux-wireless, Aloisio Almeida Jr, Krzysztof Opasiak,
Lauro Ramos Venancio, Robert Baldyga, Samuel Ortiz
Cc: LKML, kernel-janitors, Julia Lawall
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 15 Aug 2016 09:00:26 +0200
The field "owner" is set by core. Thus delete an extra initialisation.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/nfc/nfcmrvl/i2c.c | 1 -
drivers/nfc/pn533/i2c.c | 1 -
drivers/nfc/s3fwrn5/i2c.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/nfc/nfcmrvl/i2c.c b/drivers/nfc/nfcmrvl/i2c.c
index 78b7aa8..45c64a2 100644
--- a/drivers/nfc/nfcmrvl/i2c.c
+++ b/drivers/nfc/nfcmrvl/i2c.c
@@ -278,7 +278,6 @@ static struct i2c_driver nfcmrvl_i2c_driver = {
.remove = nfcmrvl_i2c_remove,
.driver = {
.name = "nfcmrvl_i2c",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(of_nfcmrvl_i2c_match),
},
};
diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 1dc8924..90798f0 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -265,7 +265,6 @@ MODULE_DEVICE_TABLE(i2c, pn533_i2c_id_table);
static struct i2c_driver pn533_i2c_driver = {
.driver = {
.name = PN533_I2C_DRIVER_NAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(of_pn533_i2c_match),
},
.probe = pn533_i2c_probe,
diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
index 3ed0adf..2e762c6 100644
--- a/drivers/nfc/s3fwrn5/i2c.c
+++ b/drivers/nfc/s3fwrn5/i2c.c
@@ -290,7 +290,6 @@ MODULE_DEVICE_TABLE(of, of_s3fwrn5_i2c_match);
static struct i2c_driver s3fwrn5_i2c_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = S3FWRN5_I2C_DRIVER_NAME,
.of_match_table = of_match_ptr(of_s3fwrn5_i2c_match),
},
--
2.9.2
^ permalink raw reply related
* Re: [PATCH 2/2] wlcore: Remove wl pointer from wl_sta structure
From: Kalle Valo @ 2016-08-15 7:56 UTC (permalink / raw)
To: Maxim Altshul
Cc: linux-kernel, john.stultz, Eliad Peller, Yaniv Machani,
linux-wireless
In-Reply-To: <20160804124314.7636-3-maxim.altshul@ti.com>
Maxim Altshul <maxim.altshul@ti.com> writes:
> No longer needed due to get_expected_throughput op change
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
The commit log is very vague, please improve it. But most importantly
you did not CC linux-wireless (adding it now) so lots of wireless people
missed this patch. Please resend.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] wlcore: Remove wl pointer from wl_sta structure
From: Kalle Valo @ 2016-08-15 7:56 UTC (permalink / raw)
To: Maxim Altshul
Cc: linux-kernel, john.stultz, Eliad Peller, Yaniv Machani,
linux-wireless
In-Reply-To: <20160804124314.7636-3-maxim.altshul@ti.com>
Maxim Altshul <maxim.altshul@ti.com> writes:
> No longer needed due to get_expected_throughput op change
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
The commit log is very vague, please improve it. But most importantly
you did not CC linux-wireless (adding it now) so lots of wireless people
missed this patch. Please resend.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] mac80211/wlcore: Add ieee80211_hw variable to get_expected_throughput
From: Kalle Valo @ 2016-08-15 7:59 UTC (permalink / raw)
To: Maxim Altshul
Cc: linux-kernel, john.stultz, Johannes Berg, Eliad Peller,
Yaniv Machani, linux-wireless
In-Reply-To: <20160804124314.7636-2-maxim.altshul@ti.com>
Maxim Altshul <maxim.altshul@ti.com> writes:
> - The variable is added to allow the driver an easy access
> to it's own hw->priv when the op is invoked.
>
> - Change wlcore op accordingly.
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
You didn't CC linux-wireless, adding it now. Others can find the full
discussion here:
http://lkml.kernel.org/g/20160804124314.7636-2-maxim.altshul@ti.com
--
Kalle Valo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox