* Re: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Dmitry Torokhov @ 2016-10-26 16:36 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam
In-Reply-To: <24731897638e42ba8b05acd6afafef3b@SC-EXCH04.marvell.com>
Hi Amit,
On Wed, Oct 26, 2016 at 03:23:08PM +0000, Amitkumar Karwar wrote:
>
> This race won't occur. At this point of time(i.e while calling mwifiex_shutdown_drv() in deinit), following things are completed. We don't expect mwifiex_main_process() to be scheduled.
> 1) Connection to peer device is terminated at the beginning of teardown thread. So we don't receive any Tx data from kernel.
> 2) Last command SHUTDOWN is exchanged with firmware. So there won't be any activity/interrupt from firmware.
> 3) Interrupts are disabled.
> 4) "adapter->surprise_removed" flag is set. It will skip mwifiex_main_process() calls.
>
> -----------
> static void mwifiex_main_work_queue(struct work_struct *work)
> {
> struct mwifiex_adapter *adapter =
> container_of(work, struct mwifiex_adapter, main_work);
>
> if (adapter->surprise_removed)
> return;
> mwifiex_main_process(adapter);
> }
> ----------
> 5) We have "mwifiex_terminate_workqueue(adapter)" call to flush and destroy workqueue.
OK, but if interrupts are disabled and you ensure that work is flushed
or completed before you call mwifiex_shutdown_drv() then I do not
understand why you need all of this at all? Why do you need to check
status in mwifiex_shutdown_drv() and why do you want
mwifiex_main_process() to call mwifiex_shutdown_drv() in certain cases?
Can you simply remove all this stuff?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/8] mac80211: Allow AUTH_DATA to be used for FILS
From: Johannes Berg @ 2016-10-26 16:10 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20161026153559.GA13254@jouni.qca.qualcomm.com>
> This is admittedly a bit strange design with that special case needed
> for SAE. If we were to design the SAE case now in combination with
> FILS, I guess this would be quite different (e.g., separate
> attributes for Authentication transaction sequence number and Status
> code). Unlike the mesh use case with SAE, FILS is only between an AP
> and a station and as such, there would not really be a case where the
> station would send an Authentication frame with non-zero Status code.
>
> A future amendment might define a new authentication algorithm that
> ends up using more than a single Authentication frame exchange. In
> such a case, we would actually have need for Authentication
> transaction sequence number even though FILS doesn't need it.
>
> I think I'd rather maintain a consistent attribute design for all
> authentication algorithms and leave this as-is now. Another option
> would be to not apply the rename SAE attributes patch and define
> something new as a more generic solution, but I'm not sure there is
> sufficient justification for the added complexity since we cannot
> really get rid of the current SAE design any time soon.
Yes, fair point.
Maybe you can clarify the nl80211 attribute documentation wrt. this? It
just states that it starts with the Authentication transaction sequence
field, but afaict that's not true, it also has the status code field,
which is also ignored here.
johannes
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Add D-Link DWA-131 rev E1
From: Jes Sorensen @ 2016-10-26 15:55 UTC (permalink / raw)
To: Barry Day; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <20161025202928.GA10934@box64.home.org>
Barry Day <briselec@gmail.com> writes:
> This is a rtl8192eu dongle and has been tested
>
> Signed-off-by: Barry Day <briselec@gmail.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Thanks, I'll add it to my queue, unless Kalle grabs it first. Glad to
know it's working for you!
Jes
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 04141e5..d426836 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -6009,7 +6009,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> untested = 0;
> break;
> case 0x2001:
> - if (id->idProduct == 0x3308)
> + if (id->idProduct == 0x3308 || id->idProduct == 0x3319)
> untested = 0;
> break;
> case 0x2357:
> @@ -6188,6 +6188,8 @@ static struct usb_device_id dev_table[] = {
> .driver_info = (unsigned long)&rtl8723au_fops},
> {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x818b, 0xff, 0xff, 0xff),
> .driver_info = (unsigned long)&rtl8192eu_fops},
> +{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3319, 0xff, 0xff, 0xff),
> + .driver_info = (unsigned long)&rtl8192eu_fops},
> /* Tested by Myckel Habets */
> {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0109, 0xff, 0xff, 0xff),
> .driver_info = (unsigned long)&rtl8192eu_fops},
^ permalink raw reply
* Re: [PATCH 2/8] mac80211: Allow AUTH_DATA to be used for FILS
From: Malinen, Jouni @ 2016-10-26 15:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1477459800.4059.1.camel@sipsolutions.net>
T24gV2VkLCBPY3QgMjYsIDIwMTYgYXQgMDc6MzA6MDBBTSArMDIwMCwgSm9oYW5uZXMgQmVyZyB3
cm90ZToNCj4gDQo+ID4gwqAJaWYgKHJlcS0+YXV0aF9kYXRhX2xlbiA+PSA0KSB7DQo+ID4gLQkJ
X19sZTE2ICpwb3MgPSAoX19sZTE2ICopIHJlcS0+YXV0aF9kYXRhOw0KPiA+IC0JCWF1dGhfZGF0
YS0+c2FlX3RyYW5zID0gbGUxNl90b19jcHUocG9zWzBdKTsNCj4gPiAtCQlhdXRoX2RhdGEtPnNh
ZV9zdGF0dXMgPSBsZTE2X3RvX2NwdShwb3NbMV0pOw0KPiA+ICsJCWlmIChyZXEtPmF1dGhfdHlw
ZSA9PSBOTDgwMjExX0FVVEhUWVBFX1NBRSkgew0KPiA+ICsJCQlfX2xlMTYgKnBvcyA9IChfX2xl
MTYgKikgcmVxLT5hdXRoX2RhdGE7DQo+ID4gKwkJCWF1dGhfZGF0YS0+c2FlX3RyYW5zID0gbGUx
Nl90b19jcHUocG9zWzBdKTsNCj4gPiArCQkJYXV0aF9kYXRhLT5zYWVfc3RhdHVzID0gbGUxNl90
b19jcHUocG9zWzFdKTsNCj4gPiArCQl9DQo+ID4gwqAJCW1lbWNweShhdXRoX2RhdGEtPmRhdGEs
IHJlcS0+YXV0aF9kYXRhICsgNCwNCj4gPiDCoAkJwqDCoMKgwqDCoMKgwqByZXEtPmF1dGhfZGF0
YV9sZW4gLSA0KTsNCj4gPiDCoAkJYXV0aF9kYXRhLT5kYXRhX2xlbiArPSByZXEtPmF1dGhfZGF0
YV9sZW4gLSA0Ow0KPiANCj4gSG1tLiBEbyB3ZSByZWFsbHkgd2FudCB0byBzdGlsbCBza2lwIHRo
ZSBmaXJzdCBmb3VyIGJ5dGVzIG9mIHRoZSBkYXRhDQo+IHVzZXJzcGFjZSBwYXNzZWQ/IFRoYXQg
c2VlbXMgYSBiaXQgc3RyYW5nZSB0byBtZS4gVGhlIGRvY3MgaW4gbmw4MDIxMS5oDQo+IGRvIHNh
eSBpdCB0aGF0IHdheSBub3csIGJ1dCBzaG91bGQgd2UgcmVhbGx5IGluY2x1ZGUgYSBkdW1teQ0K
PiBBdXRoZW50aWNhdGlvbiB0cmFuc2FjdGlvbiBzZXF1ZW5jZSBudW1iZXIgZmllbGQ/DQoNClRo
aXMgaXMgYWRtaXR0ZWRseSBhIGJpdCBzdHJhbmdlIGRlc2lnbiB3aXRoIHRoYXQgc3BlY2lhbCBj
YXNlIG5lZWRlZA0KZm9yIFNBRS4gSWYgd2Ugd2VyZSB0byBkZXNpZ24gdGhlIFNBRSBjYXNlIG5v
dyBpbiBjb21iaW5hdGlvbiB3aXRoIEZJTFMsDQpJIGd1ZXNzIHRoaXMgd291bGQgYmUgcXVpdGUg
ZGlmZmVyZW50IChlLmcuLCBzZXBhcmF0ZSBhdHRyaWJ1dGVzIGZvcg0KQXV0aGVudGljYXRpb24g
dHJhbnNhY3Rpb24gc2VxdWVuY2UgbnVtYmVyIGFuZCBTdGF0dXMgY29kZSkuIFVubGlrZSB0aGUN
Cm1lc2ggdXNlIGNhc2Ugd2l0aCBTQUUsIEZJTFMgaXMgb25seSBiZXR3ZWVuIGFuIEFQIGFuZCBh
IHN0YXRpb24gYW5kIGFzDQpzdWNoLCB0aGVyZSB3b3VsZCBub3QgcmVhbGx5IGJlIGEgY2FzZSB3
aGVyZSB0aGUgc3RhdGlvbiB3b3VsZCBzZW5kIGFuDQpBdXRoZW50aWNhdGlvbiBmcmFtZSB3aXRo
IG5vbi16ZXJvIFN0YXR1cyBjb2RlLg0KDQpBIGZ1dHVyZSBhbWVuZG1lbnQgbWlnaHQgZGVmaW5l
IGEgbmV3IGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSB0aGF0IGVuZHMNCnVwIHVzaW5nIG1vcmUg
dGhhbiBhIHNpbmdsZSBBdXRoZW50aWNhdGlvbiBmcmFtZSBleGNoYW5nZS4gSW4gc3VjaCBhDQpj
YXNlLCB3ZSB3b3VsZCBhY3R1YWxseSBoYXZlIG5lZWQgZm9yIEF1dGhlbnRpY2F0aW9uIHRyYW5z
YWN0aW9uDQpzZXF1ZW5jZSBudW1iZXIgZXZlbiB0aG91Z2ggRklMUyBkb2Vzbid0IG5lZWQgaXQu
DQoNCkkgdGhpbmsgSSdkIHJhdGhlciBtYWludGFpbiBhIGNvbnNpc3RlbnQgYXR0cmlidXRlIGRl
c2lnbiBmb3IgYWxsDQphdXRoZW50aWNhdGlvbiBhbGdvcml0aG1zIGFuZCBsZWF2ZSB0aGlzIGFz
LWlzIG5vdy4gQW5vdGhlciBvcHRpb24gd291bGQNCmJlIHRvIG5vdCBhcHBseSB0aGUgcmVuYW1l
IFNBRSBhdHRyaWJ1dGVzIHBhdGNoIGFuZCBkZWZpbmUgc29tZXRoaW5nIG5ldw0KYXMgYSBtb3Jl
IGdlbmVyaWMgc29sdXRpb24sIGJ1dCBJJ20gbm90IHN1cmUgdGhlcmUgaXMgc3VmZmljaWVudA0K
anVzdGlmaWNhdGlvbiBmb3IgdGhlIGFkZGVkIGNvbXBsZXhpdHkgc2luY2Ugd2UgY2Fubm90IHJl
YWxseSBnZXQgcmlkIG9mDQp0aGUgY3VycmVudCBTQUUgZGVzaWduIGFueSB0aW1lIHNvb24uDQoN
Ci0tIA0KSm91bmkgTWFsaW5lbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgUEdQIGlkIEVGQzg5NUZB
^ permalink raw reply
* RE: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Amitkumar Karwar @ 2016-10-26 15:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam
In-Reply-To: <20161025163520.GA10979@dtor-ws>
Hi Dmitry,
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Tuesday, October 25, 2016 10:05 PM
> To: Amitkumar Karwar
> Cc: Brian Norris; linux-wireless@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam
> Subject: Re: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing'
> in shutdown_drv
>
> On Tue, Oct 25, 2016 at 04:11:14PM +0000, Amitkumar Karwar wrote:
> > Hi Dmitry,
> >
> > > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> > > Sent: Tuesday, October 25, 2016 5:28 AM
> > > To: Brian Norris
> > > Cc: Amitkumar Karwar; linux-wireless@vger.kernel.org; Cathy Luo;
> > > Nishant Sarmukadam
> > > Subject: Re: [PATCH 2/5] mwifiex: use spinlock for
> 'mwifiex_processing'
> > > in shutdown_drv
> > >
> > > On Mon, Oct 24, 2016 at 12:19:15PM -0700, Brian Norris wrote:
> > > > On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote:
> > > > > This variable is guarded by spinlock at all other places. This
> > > > > patch takes care of missing spinlock usage in
> mwifiex_shutdown_drv().
> > > > >
> > > > > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > > > > ---
> > > > > drivers/net/wireless/marvell/mwifiex/init.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/drivers/net/wireless/marvell/mwifiex/init.c
> > > > > b/drivers/net/wireless/marvell/mwifiex/init.c
> > > > > index 82839d9..8e5e424 100644
> > > > > --- a/drivers/net/wireless/marvell/mwifiex/init.c
> > > > > +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> > > > > @@ -670,11 +670,14 @@ mwifiex_shutdown_drv(struct
> > > > > mwifiex_adapter
> > > > > *adapter)
> > > > >
> > > > > adapter->hw_status = MWIFIEX_HW_STATUS_CLOSING;
> > > > > /* wait for mwifiex_process to complete */
> > > > > + spin_lock_irqsave(&adapter->main_proc_lock, flags);
> > > > > if (adapter->mwifiex_processing) {
> > > >
> > > > I'm not quite sure why we have this check in the first place; if
> > > > the main process is still running, then don't we have bigger
> > > > problems here anyway? But this is definitely the "right" way to
> check this flag, so:
> > >
> > > No, this is definitely not right way to check it. What exactly does
> > > this spinlock protect? It seems that the intent is to make sure we
> > > do not call mwifiex_shutdown_drv() while mwifiex_main_process() is
> executing.
> > > It even says above that we are "waiting" for it (but we do not, we
> > > may bail out or we may not, depends on luck).
> > >
> > > To implement this properly you not only need to take a lock and
> > > check the flag, but keep the lock until mwifiex_shutdown_drv() is
> > > done, or use some other way to let mwifiex_main_process() know it
> > > should not access the adapter while mwifiex_shutdown_drv() is
> running.
> > >
> > > NACK.
> > >
> >
> > As I explained in other email, here is the sequence.
> > 1) We find mwifiex_processing is true in mwifiex_shitdown_drv(). "-
> EINPROGRESS" is returned by the function and hw_status state is changed
> to MWIFIEX_HW_STATUS_CLOSING.
> > 2) We wait until main_process is completed.
> >
> > if (mwifiex_shutdown_drv(adapter) == -EINPROGRESS)
> > wait_event_interruptible(adapter->init_wait_q,
> >
> > adapter->init_wait_q_woken);
> >
> > 3) We have following check at the end of main_process()
> >
> > exit_main_proc:
> > if (adapter->hw_status == MWIFIEX_HW_STATUS_CLOSING)
> > mwifiex_shutdown_drv(adapter);
> >
> > 4) Here at the end of mwifiex_shutdown_drv(), we are setting
> > "adapter->init_wait_q_woken" and waking up the thread in point (2)
>
> 1. We do not find mwifiex_processing to be true
> 2. We proceed to try and shut down the driver
> 3. Interrupt is raised in the meantime, kicking work item
> 4. mwifiex_main_process() sees that adapter->hw_status is
> MWIFIEX_HW_STATUS_CLOSING and jumps to exit_main_proc
> 5.mwifiex_main_process() calls into mwifiex_shutdown_drv() that is now
> racing with another copy of the same.
This race won't occur. At this point of time(i.e while calling mwifiex_shutdown_drv() in deinit), following things are completed. We don't expect mwifiex_main_process() to be scheduled.
1) Connection to peer device is terminated at the beginning of teardown thread. So we don't receive any Tx data from kernel.
2) Last command SHUTDOWN is exchanged with firmware. So there won't be any activity/interrupt from firmware.
3) Interrupts are disabled.
4) "adapter->surprise_removed" flag is set. It will skip mwifiex_main_process() calls.
-----------
static void mwifiex_main_work_queue(struct work_struct *work)
{
struct mwifiex_adapter *adapter =
container_of(work, struct mwifiex_adapter, main_work);
if (adapter->surprise_removed)
return;
mwifiex_main_process(adapter);
}
----------
5) We have "mwifiex_terminate_workqueue(adapter)" call to flush and destroy workqueue.
>
> It seems to me that mwifiex_main_process() is [almost] always used from
> a workqueue. Can you instead of sprinkling spinlocks ensure that
> mwifiex_shutdown_drv():
>
> 1. Inhibits scheduling of mwifiex_main_process()
> 2. Does cancel_work_sync(...) to ensure that mwifiex_main_process() does not run
> 3. Continues shutting down the driver.
I think, this is already taken care of in current implementation.
>
> Alternatively, do these have to be spinlocks? Can you make them mutexes
> and take them for the duration of mwifiex_main_process() and
> mwifiex_shutdown_drv() and others, as needed?
>
As I explained above, there won't be a race between mwifiex_main_process() and mwifiex_shutdown_drv().
Let me know if you think otherwise and have any suggestions.
Regards,
Amitkumar
^ permalink raw reply
* Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Ferry Huberts @ 2016-10-26 14:43 UTC (permalink / raw)
To: Kalle Valo, Antonio Quartulli
Cc: ath9k-devel, linux-wireless, Antonio Quartulli
In-Reply-To: <87lgxbxl2d.fsf@purkki.adurom.net>
do a grep in the kernel: dual license bsd/gpl
On 26/10/16 16:05, Kalle Valo wrote:
> Antonio Quartulli <a@unstable.cc> writes:
>
>> From: Antonio Quartulli <antonio@open-mesh.com>
>>
>> This patch was crafted long time ago to work around a key cache
>> corruption problem on ath9k chipsets.
>>
>> The workaround consists in periodically triggering a worker that
>> uploads all the keys to the HW cache. The worker is triggered also
>> when the vif detects 21 undecryptable packets.
>>
>>
>> This patch is based on top compat-wireless-2015-10-26.
>>
>>
>> I was asked to release this code to the public and, since it is
>> GPL, I am now doing it.
>
> GPL? AFAICS ath9k is under ISC. I'm not sure what you mean with the
> sentence above, but it's possible to interpret it so that this patch is
> not under ISC license, which is problematic.
>
--
Ferry Huberts
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Antonio Quartulli @ 2016-10-26 14:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <87lgxbxl2d.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote:
> Antonio Quartulli <a@unstable.cc> writes:
>
> > From: Antonio Quartulli <antonio@open-mesh.com>
> >
> > This patch was crafted long time ago to work around a key cache
> > corruption problem on ath9k chipsets.
> >
> > The workaround consists in periodically triggering a worker that
> > uploads all the keys to the HW cache. The worker is triggered also
> > when the vif detects 21 undecryptable packets.
> >
> >
> > This patch is based on top compat-wireless-2015-10-26.
> >
> >
> > I was asked to release this code to the public and, since it is
> > GPL, I am now doing it.
>
> GPL? AFAICS ath9k is under ISC. I'm not sure what you mean with the
> sentence above, but it's possible to interpret it so that this patch is
> not under ISC license, which is problematic.
Honestly, my sentence was just a way to say "it makes sense to release this
patch to the public".
If it needs to be ISC in order to be merged, then it can be released under ISC.
I don't want to enter a legal case :) I just to make the patch public
Cheers,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Kalle Valo @ 2016-10-26 14:05 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <20161018083552.28592-1-a@unstable.cc>
Antonio Quartulli <a@unstable.cc> writes:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> This patch was crafted long time ago to work around a key cache
> corruption problem on ath9k chipsets.
>
> The workaround consists in periodically triggering a worker that
> uploads all the keys to the HW cache. The worker is triggered also
> when the vif detects 21 undecryptable packets.
>
>
> This patch is based on top compat-wireless-2015-10-26.
>
>
> I was asked to release this code to the public and, since it is
> GPL, I am now doing it.
GPL? AFAICS ath9k is under ISC. I'm not sure what you mean with the
sentence above, but it's possible to interpret it so that this patch is
not under ISC license, which is problematic.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Simon Wunderlich @ 2016-10-26 13:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: Antonio Quartulli, linux-wireless
In-Reply-To: <1477486736.4059.36.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]
On Wednesday, October 26, 2016 2:58:56 PM CEST Johannes Berg wrote:
> > (NOTE: going off-channel while operating is a different topic).
>
> Why do you think it's different?
>
> Seems exactly the same to me, since you come back to the channel and
> start sending without any new checking?
There are two ways to leave a channel:
1.) Leave the operating channel "permanently". Then the ETSI 301 893 says:
"If no radar was detected on an Operating Channel but the RLAN stops operating
on that channel, then the channel becomes an Available Channel." (4.7.1.4
Master Devices (c))
Then we can select a new operating channel and re-start the process.
2.) Off-Channel CAC: This is an optional feature. Simply spoken, we keep the
channel operating, but try to do CAC-checking on a different channel by
shortly switching to that new channel from time to time. The new channel must
be checked for a longer time than the standard CAC time (6 minutes for non-
weather radar channels in ETSI).
The main difference is that we keep the current channel as "operating channel"
and are also required to be able to detect radars with the same probability.
Also note that this feature is not implemented in Linux as far as I know, and
personally I haven't seen it in the wild yet.
From 4.7.2.3.1:
"Off-Channel CAC is defined as an optional mechanism by which an RLAN device
monitors channel(s), different from the Operating Channel(s), for the presence
of radar signals. The Off-Channel CAC may be used in addition to the Channel
Availability Check defined in clause 4.7.2.2, for identifying Available
Channels.
Off-Channel CAC is performed by a number of non-continuous checks spread over
a period in time. This period, which is required to determine the presence of
radar signals, is defined as the Off-Channel CAC Time.
If no radars have been detected in a channel, then that channel becomes an
Available Channel."
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting
From: Johannes Berg @ 2016-10-26 13:05 UTC (permalink / raw)
To: Zaborowski, Andrew, linux-wireless@vger.kernel.org
In-Reply-To: <F1E72F916E15444E976109681700BEE23F6AF7D9@IRSMSX102.ger.corp.intel.com>
On Fri, 2016-10-21 at 19:03 +0000, Zaborowski, Andrew wrote:
> > The problem is that you really want this to be offloaded to the
> > device, *especially* if you care about low power usage, because you
> > absolutely don't want to be processing each beacon (which is
> > typically what we derive the data from today) in the host CPU - you
> > want those to be filtered by the device so you don't wake up the
> > host CPU every ~102ms.
>
> Right, that would be a separate optimisation but it probably won't
> arrive until there's an API that the drivers can implement, so I
> think this is a prerequisite.
Huh? No, beacon filtering is implemented by a lot of drivers today.
> The userspace switches count too and are the main motivation for this
> patch. Eventually, as you say, things will depend on specific
> drivers and you will want to optimise whatever you can assuming the
> hardware you're constrained to.
Yes and no. I think we can probably define a reasonable subset that
you'd expect more devices to implement. I don't really see the
requirement to do the "banding" that you did here offloaded - doing it
in mac80211 won't help much, and won't work in cases where you have
beacon filtering already anyway.
Drivers like iwlwifi would be able to implement the banding in
software, since they get a notification on every change above a
configurable threshold, but other drivers like one I looked at actually
do have a low and high threshold today, and program them to be the same
value with our current CQM API definitions.
> It seems like any mechanism you choose can be implemented on top of
> hardware that supports a low and a high threshold by setting the next
> values while handling the event related to the previous threshold
> crossing event. If the thresholds are specified by a middle value
> and a hysteresis or distance, that would work equally well.
> The API I added in the patch also allows offloading to such hardware.
Well, ok, technically the API can be implemented on top of drivers with
low/high thresholds, by doing the configuration according to the
current range you're in.
I would argue though that it makes more sense to expose a simpler
capability (e.g. two instead of the current single threshold) and do
the reprogramming from higher layers. That ends up being more flexible,
since you can then, for example, also have ranges that aren't all
identical - which makes some sense because above a certain level you
don't really care at all.
> In short a nl80211 change would be needed regardless of the mechanism
> chosen.
Agree. I'm just not convinced that the banding mechanism you propose is
the most reasonable choice for new API.
johannes
^ permalink raw reply
* Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting
From: Johannes Berg @ 2016-10-26 13:11 UTC (permalink / raw)
To: Denis Kenzior, Andrew Zaborowski, linux-wireless
In-Reply-To: <580A2438.7030106@gmail.com>
On Fri, 2016-10-21 at 09:20 -0500, Denis Kenzior wrote:
> > It's actually not clear to me that this is really how it should be.
> > There's a point to be made that taking a more holistic "link
> > quality" would be a better choice. That's related, but maybe can be
> > a separate discussion.
> Can you elaborate on this 'link quality' idea?
Well, I didn't really want to - getting 3 system folks into a room will
result in 4 different ways of doing it - but you can take into account
not just the RSSI, but also the bitrate you can reasonably use on the
channel/with the AP, the noise you can perhaps detect (if you can), the
amount of packet loss or retransmissions you experience, etc.
I think that some systems (Android, maybe Windows) already do something
more complex than pure RSSI indicators, but I don't really know for
sure.
> > Yes, this would be ideal.
> >
> > [...]
see my other email
> This sounds really brittle. Furthermore, we also need a facility to
> know when signal strength is getting low to trigger roaming
> logic. This would mean sharing CQM facility between roaming & signal
> strength notifications. As you wrote above, things become quite
> impractical.
This would likely go through the supplicant anyway, so it could manage
proper range overlaps etc. for this.
It does seem brittle if we just have a single value, but if we add
low/high thresholds (with hysteresis) then I think we can do this, and
gain more flexibility in the process. But let's discuss more details
over in the other email I just sent :)
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Johannes Berg @ 2016-10-26 12:58 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: Antonio Quartulli, linux-wireless
In-Reply-To: <3164753.QVH0CDzpbV@prime>
On Mon, 2016-10-24 at 16:53 +0200, Simon Wunderlich wrote:
> [snip]
>
> Again, no explicit "on installation" here, but there is also nothing
> saying that we can not check/operate on other channels in the
> meantime.
Yeah, ok.
> (NOTE: going off-channel while operating is a different topic).
Why do you think it's different?
Seems exactly the same to me, since you come back to the channel and
start sending without any new checking?
johannes
^ permalink raw reply
* [PATCH] nl80211: use nla_parse_nested() instead of nla_parse()
From: Johannes Berg @ 2016-10-26 12:45 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
It's just an inline doing the same thing, but the code
is nicer with it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 85 ++++++++++++++++++++++----------------------------
1 file changed, 37 insertions(+), 48 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b0440de82171..ad49a4c43e01 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2318,10 +2318,9 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
nla_for_each_nested(nl_txq_params,
info->attrs[NL80211_ATTR_WIPHY_TXQ_PARAMS],
rem_txq_params) {
- result = nla_parse(tb, NL80211_TXQ_ATTR_MAX,
- nla_data(nl_txq_params),
- nla_len(nl_txq_params),
- txq_params_policy);
+ result = nla_parse_nested(tb, NL80211_TXQ_ATTR_MAX,
+ nl_txq_params,
+ txq_params_policy);
if (result)
return result;
result = parse_txq_params(tb, &txq_params);
@@ -3571,8 +3570,8 @@ static int nl80211_parse_tx_bitrate_mask(struct genl_info *info,
sband = rdev->wiphy.bands[band];
if (sband == NULL)
return -EINVAL;
- err = nla_parse(tb, NL80211_TXRATE_MAX, nla_data(tx_rates),
- nla_len(tx_rates), nl80211_txattr_policy);
+ err = nla_parse_nested(tb, NL80211_TXRATE_MAX, tx_rates,
+ nl80211_txattr_policy);
if (err)
return err;
if (tb[NL80211_TXRATE_LEGACY]) {
@@ -6328,9 +6327,8 @@ static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
rem_reg_rules) {
- r = nla_parse(tb, NL80211_REG_RULE_ATTR_MAX,
- nla_data(nl_reg_rule), nla_len(nl_reg_rule),
- reg_rule_policy);
+ r = nla_parse_nested(tb, NL80211_REG_RULE_ATTR_MAX,
+ nl_reg_rule, reg_rule_policy);
if (r)
goto bad_reg;
r = parse_reg_rule(tb, &rd->reg_rules[rule_idx]);
@@ -6397,8 +6395,8 @@ static int parse_bss_select(struct nlattr *nla, struct wiphy *wiphy,
if (!nla_ok(nest, nla_len(nest)))
return -EINVAL;
- err = nla_parse(attr, NL80211_BSS_SELECT_ATTR_MAX, nla_data(nest),
- nla_len(nest), nl80211_bss_select_policy);
+ err = nla_parse_nested(attr, NL80211_BSS_SELECT_ATTR_MAX, nest,
+ nl80211_bss_select_policy);
if (err)
return err;
@@ -6788,9 +6786,8 @@ nl80211_parse_sched_scan_plans(struct wiphy *wiphy, int n_plans,
if (WARN_ON(i >= n_plans))
return -EINVAL;
- err = nla_parse(plan, NL80211_SCHED_SCAN_PLAN_MAX,
- nla_data(attr), nla_len(attr),
- nl80211_plan_policy);
+ err = nla_parse_nested(plan, NL80211_SCHED_SCAN_PLAN_MAX,
+ attr, nl80211_plan_policy);
if (err)
return err;
@@ -6879,9 +6876,9 @@ nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev,
tmp) {
struct nlattr *rssi;
- err = nla_parse(tb, NL80211_SCHED_SCAN_MATCH_ATTR_MAX,
- nla_data(attr), nla_len(attr),
- nl80211_match_policy);
+ err = nla_parse_nested(tb,
+ NL80211_SCHED_SCAN_MATCH_ATTR_MAX,
+ attr, nl80211_match_policy);
if (err)
return ERR_PTR(err);
/* add other standalone attributes here */
@@ -7052,9 +7049,9 @@ nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev,
tmp) {
struct nlattr *ssid, *rssi;
- err = nla_parse(tb, NL80211_SCHED_SCAN_MATCH_ATTR_MAX,
- nla_data(attr), nla_len(attr),
- nl80211_match_policy);
+ err = nla_parse_nested(tb,
+ NL80211_SCHED_SCAN_MATCH_ATTR_MAX,
+ attr, nl80211_match_policy);
if (err)
goto out_free;
ssid = tb[NL80211_SCHED_SCAN_MATCH_ATTR_SSID];
@@ -9754,9 +9751,8 @@ static int nl80211_parse_wowlan_tcp(struct cfg80211_registered_device *rdev,
if (!rdev->wiphy.wowlan->tcp)
return -EINVAL;
- err = nla_parse(tb, MAX_NL80211_WOWLAN_TCP,
- nla_data(attr), nla_len(attr),
- nl80211_wowlan_tcp_policy);
+ err = nla_parse_nested(tb, MAX_NL80211_WOWLAN_TCP, attr,
+ nl80211_wowlan_tcp_policy);
if (err)
return err;
@@ -9901,9 +9897,7 @@ static int nl80211_parse_wowlan_nd(struct cfg80211_registered_device *rdev,
goto out;
}
- err = nla_parse(tb, NL80211_ATTR_MAX,
- nla_data(attr), nla_len(attr),
- nl80211_policy);
+ err = nla_parse_nested(tb, NL80211_ATTR_MAX, attr, nl80211_policy);
if (err)
goto out;
@@ -9937,10 +9931,9 @@ static int nl80211_set_wowlan(struct sk_buff *skb, struct genl_info *info)
goto set_wakeup;
}
- err = nla_parse(tb, MAX_NL80211_WOWLAN_TRIG,
- nla_data(info->attrs[NL80211_ATTR_WOWLAN_TRIGGERS]),
- nla_len(info->attrs[NL80211_ATTR_WOWLAN_TRIGGERS]),
- nl80211_wowlan_policy);
+ err = nla_parse_nested(tb, MAX_NL80211_WOWLAN_TRIG,
+ info->attrs[NL80211_ATTR_WOWLAN_TRIGGERS],
+ nl80211_wowlan_policy);
if (err)
return err;
@@ -10022,8 +10015,8 @@ static int nl80211_set_wowlan(struct sk_buff *skb, struct genl_info *info)
rem) {
u8 *mask_pat;
- nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_parse_nested(pat_tb, MAX_NL80211_PKTPAT, pat,
+ NULL);
err = -EINVAL;
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
@@ -10233,8 +10226,8 @@ static int nl80211_parse_coalesce_rule(struct cfg80211_registered_device *rdev,
int rem, pat_len, mask_len, pkt_offset, n_patterns = 0;
struct nlattr *pat_tb[NUM_NL80211_PKTPAT];
- err = nla_parse(tb, NL80211_ATTR_COALESCE_RULE_MAX, nla_data(rule),
- nla_len(rule), nl80211_coalesce_policy);
+ err = nla_parse_nested(tb, NL80211_ATTR_COALESCE_RULE_MAX, rule,
+ nl80211_coalesce_policy);
if (err)
return err;
@@ -10272,8 +10265,7 @@ static int nl80211_parse_coalesce_rule(struct cfg80211_registered_device *rdev,
rem) {
u8 *mask_pat;
- nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_parse_nested(pat_tb, MAX_NL80211_PKTPAT, pat, NULL);
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
return -EINVAL;
@@ -10392,10 +10384,9 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, struct genl_info *info)
if (!info->attrs[NL80211_ATTR_REKEY_DATA])
return -EINVAL;
- err = nla_parse(tb, MAX_NL80211_REKEY_DATA,
- nla_data(info->attrs[NL80211_ATTR_REKEY_DATA]),
- nla_len(info->attrs[NL80211_ATTR_REKEY_DATA]),
- nl80211_rekey_policy);
+ err = nla_parse_nested(tb, MAX_NL80211_REKEY_DATA,
+ info->attrs[NL80211_ATTR_REKEY_DATA],
+ nl80211_rekey_policy);
if (err)
return err;
@@ -10704,10 +10695,9 @@ static int nl80211_nan_add_func(struct sk_buff *skb,
wdev->owner_nlportid != info->snd_portid)
return -ENOTCONN;
- err = nla_parse(tb, NL80211_NAN_FUNC_ATTR_MAX,
- nla_data(info->attrs[NL80211_ATTR_NAN_FUNC]),
- nla_len(info->attrs[NL80211_ATTR_NAN_FUNC]),
- nl80211_nan_func_policy);
+ err = nla_parse_nested(tb, NL80211_NAN_FUNC_ATTR_MAX,
+ info->attrs[NL80211_ATTR_NAN_FUNC],
+ nl80211_nan_func_policy);
if (err)
return err;
@@ -10802,10 +10792,9 @@ static int nl80211_nan_add_func(struct sk_buff *skb,
if (tb[NL80211_NAN_FUNC_SRF]) {
struct nlattr *srf_tb[NUM_NL80211_NAN_SRF_ATTR];
- err = nla_parse(srf_tb, NL80211_NAN_SRF_ATTR_MAX,
- nla_data(tb[NL80211_NAN_FUNC_SRF]),
- nla_len(tb[NL80211_NAN_FUNC_SRF]),
- nl80211_nan_srf_policy);
+ err = nla_parse_nested(srf_tb, NL80211_NAN_SRF_ATTR_MAX,
+ tb[NL80211_NAN_FUNC_SRF],
+ nl80211_nan_srf_policy);
if (err)
goto out;
--
2.8.1
^ permalink raw reply related
* [RFC] cfg80211: support 4-way-handshake offload with PSK and 802.1X
From: Johannes Berg @ 2016-10-26 12:26 UTC (permalink / raw)
To: linux-wireless
Cc: avraham.stern, akarwar, j, yangzy, cluo, nishants, lihz,
ilan.peer
In-Reply-To: <1477483882.4059.34.camel@sipsolutions.net>
From: Avraham Stern <avraham.stern@intel.com>
TODO:
* add a separate capability flag? and explain how the offload
is supposed to work in 802.1X, EAPOL-Key messages are going
to be processed by the supplicant, but then the 4-way-HS is
done by the device after getting the PMK in the PMKSA cache
entry - explain that mechanism
* does anyone still want EAP-LEAP 16-byte PMK?
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/linux/ieee80211.h | 3 +++
include/net/cfg80211.h | 8 +++++++-
include/uapi/linux/nl80211.h | 14 +++++++++++++-
net/wireless/nl80211.c | 15 +++++++++++++++
4 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index a80516fd65c8..40206b2a6e6d 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2326,6 +2326,9 @@ enum ieee80211_sa_query_action {
#define WLAN_PMKID_LEN 16
+#define WLAN_PMK_LEN 32
+#define WLAN_PMK_LEN_SUITE_B_192 48
+
#define WLAN_OUI_WFA 0x506f9a
#define WLAN_OUI_TYPE_WFA_P2P 9
#define WLAN_OUI_MICROSOFT 0x0050f2
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d1ffbc3a8e55..3bb407c57177 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -615,6 +615,7 @@ struct survey_info {
* @wep_keys: static WEP keys, if not NULL points to an array of
* CFG80211_MAX_WEP_KEYS WEP keys
* @wep_tx_key: key index (0..3) of the default TX static WEP key
+ * @psk: PSK (for devices supporting 4-way-handshake offload, 32 bytes)
*/
struct cfg80211_crypto_settings {
u32 wpa_versions;
@@ -628,6 +629,7 @@ struct cfg80211_crypto_settings {
bool control_port_no_encrypt;
struct key_params *wep_keys;
int wep_tx_key;
+ const u8 *psk;
};
/**
@@ -2064,11 +2066,15 @@ enum wiphy_params_flags {
* caching.
*
* @bssid: The AP's BSSID.
- * @pmkid: The PMK material itself.
+ * @pmkid: The PMK identifier.
+ * @pmk: The PMK material itself.
+ * @pmk_len: The PMK length in bytes.
*/
struct cfg80211_pmksa {
const u8 *bssid;
const u8 *pmkid;
+ const u8 *pmk;
+ u8 pmk_len;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1362d24957b5..40b003cc07bd 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -371,7 +371,8 @@
* NL80211_CMD_GET_SURVEY and on the "scan" multicast group)
*
* @NL80211_CMD_SET_PMKSA: Add a PMKSA cache entry, using %NL80211_ATTR_MAC
- * (for the BSSID) and %NL80211_ATTR_PMKID.
+ * (for the BSSID) and %NL80211_ATTR_PMKID. Optionally, %NL80211_ATTR_PMK
+ * can be used to specify the PMK.
* @NL80211_CMD_DEL_PMKSA: Delete a PMKSA cache entry, using %NL80211_ATTR_MAC
* (for the BSSID) and %NL80211_ATTR_PMKID.
* @NL80211_CMD_FLUSH_PMKSA: Flush all PMKSA cache entries.
@@ -1937,6 +1938,11 @@ enum nl80211_commands {
* @NL80211_ATTR_NAN_MATCH: used to report a match. This is a nested attribute.
* See &enum nl80211_nan_match_attributes.
*
+ * @NL80211_ATTR_PMK: PMK for offloaded 4-Way Handshake. Relevant with
+ * %NL80211_CMD_CONNECT (for WPA/WPA2-PSK networks) when PSK is used, or
+ * with %NL80211_CMD_SET_PMKSA when 802.1X authentication is used and for
+ * PMKSA caching.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2336,6 +2342,8 @@ enum nl80211_attrs {
NL80211_ATTR_NAN_FUNC,
NL80211_ATTR_NAN_MATCH,
+ NL80211_ATTR_PMK,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -4638,6 +4646,9 @@ enum nl80211_feature_flags {
* configuration (AP/mesh) with HT rates.
* @NL80211_EXT_FEATURE_BEACON_RATE_VHT: Driver supports beacon rate
* configuration (AP/mesh) with VHT rates.
+ * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_OFFLOAD_STA: Device supports
+ * doing 4-way handshake in station mode (PSK is passed as part
+ * of the connect command).
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4652,6 +4663,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_LEGACY,
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
+ NL80211_EXT_FEATURE_4WAY_HANDSHAKE_OFFLOAD_STA,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b0440de82171..6720c7bf3ed1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -414,6 +414,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_NAN_MASTER_PREF] = { .type = NLA_U8 },
[NL80211_ATTR_NAN_DUAL] = { .type = NLA_U8 },
[NL80211_ATTR_NAN_FUNC] = { .type = NLA_NESTED },
+ [NL80211_ATTR_PMK] = { .len = WLAN_PMK_LEN },
};
/* policy for the key attributes */
@@ -7922,6 +7923,13 @@ static int nl80211_crypto_settings(struct cfg80211_registered_device *rdev,
memcpy(settings->akm_suites, data, len);
}
+ if (info->attrs[NL80211_ATTR_PMK]) {
+ if (!wiphy_ext_feature_isset(&rdev->wiphy,
+ NL80211_EXT_FEATURE_4WAY_HANDSHAKE_OFFLOAD_STA))
+ return -EINVAL;
+ settings->psk = nla_data(info->attrs[NL80211_ATTR_PMK]);
+ }
+
return 0;
}
@@ -8824,6 +8832,13 @@ static int nl80211_setdel_pmksa(struct sk_buff *skb, struct genl_info *info)
pmksa.pmkid = nla_data(info->attrs[NL80211_ATTR_PMKID]);
pmksa.bssid = nla_data(info->attrs[NL80211_ATTR_MAC]);
+ if (info->attrs[NL80211_ATTR_PMK]) {
+ pmksa.pmk = nla_data(info->attrs[NL80211_ATTR_PMK]);
+ pmksa.pmk_len = nla_len(info->attrs[NL80211_ATTR_PMK]);
+ if (pmksa.pmk_len != WLAN_PMK_LEN &&
+ pmksa.pmk_len != WLAN_PMK_LEN_SUITE_B_192)
+ return -EINVAL;
+ }
if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_STATION &&
dev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_CLIENT)
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: add key management offload feature
From: Johannes Berg @ 2016-10-26 12:11 UTC (permalink / raw)
To: Amitkumar Karwar, linux-wireless, hostap, Jouni Malinen
Cc: yangzy, Cathy Luo, Nishant Sarmukadam, lihz
In-Reply-To: <1474973796-1873-1-git-send-email-akarwar@marvell.com>
Getting back to this ... as I was preparing my patch.
> @@ -3687,6 +3692,9 @@ enum nl80211_key_attributes {
> NL80211_KEY_DEFAULT_MGMT,
> NL80211_KEY_TYPE,
> NL80211_KEY_DEFAULT_TYPES,
> + NL80211_KEY_REPLAY_CTR,
> + NL80211_KEY_KCK,
> + NL80211_KEY_KEK,
You made those key attributes, but ...
> nla_put(msg, NL80211_ATTR_RESP_IE, resp_ie_len,
> resp_ie)))
> goto nla_put_failure;
>
> + if (wiphy_ext_feature_isset(&rdev->wiphy,
> + NL80211_EXT_FEATURE_KEY_MGMT_OFF
> LOAD) &&
> + (nla_put_u8(msg, NL80211_ATTR_AUTHORIZED, authorized) ||
> + (key_replay_ctr && nla_put(msg, NL80211_KEY_REPLAY_CTR,
> + NL80211_REPLAY_CTR_LEN, key_replay_ctr)) ||
> + (key_kck &&
> + nla_put(msg, NL80211_KEY_KCK, NL80211_KCK_LEN,
> key_kck)) ||
> + (key_kek &&
> + nla_put(msg, NL80211_KEY_KEK, NL80211_KEK_LEN,
> key_kek))))
> + goto nla_put_failure;
Used them at a top level here! That can't possibly have worked.
Anyway, I checked and we can transport these without adding new
attributes, but adding the NL80211_ATTR_REKEY_DATA attribute with its
nested KEK, KCK and REPLAY_CTR.
That leaves the authorized attribute, I guess nesting a whole bunch of
station info etc. doesn't make a lot of sense.
I also fail to see how the data is actually configured down, since you
just pass it through. I'll send our patch for configuring the PMK/PSK
via the PMKSA cache separately in a few minutes.
johannes
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Kalle Valo @ 2016-10-26 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Hante Meuleman,
Franky Lin, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless, brcm80211-dev-list.pdl,
netdev
In-Reply-To: <3406231.8mt2808XDi@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>=20
>> > A bugfix added a sanity check around the assignment and use of the
>> > 'is_11d' variable, which looks correct to me, but as the function is
>> > rather complex already, this confuses the compiler to the point where
>> > it can no longer figure out if the variable is always initialized
>> > correctly:
>> >
>> > brcm80211/brcmfmac/cfg80211.c: In function =E2=80=98brcmf_cfg80211_sta=
rt_ap=E2=80=99:
>> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: =E2=80=98is_11d=E2=80=99=
may be used uninitialized in this function [-Werror=3Dmaybe-uninitialized]
>> >
>> > This adds an initialization for the newly introduced case in which
>> > the variable should not really be used, in order to make the warning
>> > go away.
>> >
>> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
>> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
>> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
>> > Cc: Kalle Valo <kvalo@codeaurora.org>
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>=20
>> Via which tree are you planning to submit this? Should I take it?
>
> I'd prefer if you can take it and forward it along with your other
> bugfixes. I'll try to take care of the ones that nobody else
> picked up.
Ok, I'll take it. I'm planning to push this to 4.9.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Johannes Berg @ 2016-10-26 10:18 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, daniel, netdev, linux-wireless
In-Reply-To: <20161026095238.GB16590@pox.localdomain>
On Wed, 2016-10-26 at 11:52 +0200, Thomas Graf wrote:
> On 10/26/16 at 10:59am, Johannes Berg wrote:
> >
> >
> > >
> > > /**
> > > + * nla_memdup - duplicate attribute memory (kmemdup)
> > > + * @src: netlink attribute to duplicate from
> > > + * @gfp: GFP mask
> >
> > Actually, is there any point in passing a GFP mask? None of the
> > current
> > users need it, and it seems fairly unlikely to be needed since this
> > is
> > typically used on the netlink input path, where you surely
> > shouldn't
> > need GFP_ATOMIC or so?
>
> I'm fine either way. I didn't want to make assumptions which need
> later changes. It's not hurting either and the function prototype
> is very small.
Yeah, I don't really care much - just wondered.
johannes
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Arnd Bergmann @ 2016-10-26 9:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Hante Meuleman,
Franky Lin, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless, brcm80211-dev-list.pdl,
netdev
In-Reply-To: <87zilr61ux.fsf@kamboji.qca.qualcomm.com>
On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > A bugfix added a sanity check around the assignment and use of the
> > 'is_11d' variable, which looks correct to me, but as the function is
> > rather complex already, this confuses the compiler to the point where
> > it can no longer figure out if the variable is always initialized
> > correctly:
> >
> > brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > This adds an initialization for the newly introduced case in which
> > the variable should not really be used, in order to make the warning
> > go away.
> >
> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> > Cc: Kalle Valo <kvalo@codeaurora.org>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Via which tree are you planning to submit this? Should I take it?
I'd prefer if you can take it and forward it along with your other
bugfixes. I'll try to take care of the ones that nobody else
picked up.
Arnd
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Thomas Graf @ 2016-10-26 9:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: davem, daniel, netdev, linux-wireless
In-Reply-To: <1477472376.4059.23.camel@sipsolutions.net>
On 10/26/16 at 10:59am, Johannes Berg wrote:
>
> > /**
> > + * nla_memdup - duplicate attribute memory (kmemdup)
> > + * @src: netlink attribute to duplicate from
> > + * @gfp: GFP mask
>
> Actually, is there any point in passing a GFP mask? None of the current
> users need it, and it seems fairly unlikely to be needed since this is
> typically used on the netlink input path, where you surely shouldn't
> need GFP_ATOMIC or so?
I'm fine either way. I didn't want to make assumptions which need
later changes. It's not hurting either and the function prototype
is very small.
^ permalink raw reply
* [PATCH] wireless: only ask about WDS if EXPERT is selected
From: Johannes Berg @ 2016-10-26 9:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There won't be any users of this that really need it and
aren't already experts in how the kernel functions, so
require setting EXPERT to reach this setting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index fa9c4fa9477e..8f5a3f4a43f2 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -18,7 +18,7 @@ menuconfig WLAN
if WLAN
config WIRELESS_WDS
- bool "mac80211-based legacy WDS support"
+ bool "mac80211-based legacy WDS support" if EXPERT
help
This option enables the deprecated WDS support, the newer
mac80211-based 4-addr AP/client support supersedes it with
--
2.8.1
^ permalink raw reply related
* [PATCH] nl80211: move unsplit command advertising to a separate function
From: Johannes Berg @ 2016-10-26 9:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When we split the wiphy dump because it got too large, I added a
comment and asked that all new command advertising be done only
for userspace clients capable of receiving split data, in order
to not break older ones (which can't use the new commands anyway)
This mostly worked, and we haven't added many new commands, but
I occasionally get patches that modify the wrong place.
Make this easier to detect and understand by splitting out the
old commands to a separate function that makes it more clear it
should never be modified again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 142 +++++++++++++++++++++++++++----------------------
1 file changed, 79 insertions(+), 63 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46cd48993ce9..b0440de82171 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1328,6 +1328,82 @@ nl80211_send_mgmt_stypes(struct sk_buff *msg,
return 0;
}
+#define CMD(op, n) \
+ do { \
+ if (rdev->ops->op) { \
+ i++; \
+ if (nla_put_u32(msg, i, NL80211_CMD_ ## n)) \
+ goto nla_put_failure; \
+ } \
+ } while (0)
+
+static int nl80211_add_commands_unsplit(struct cfg80211_registered_device *rdev,
+ struct sk_buff *msg)
+{
+ int i = 0;
+
+ /*
+ * do *NOT* add anything into this function, new things need to be
+ * advertised only to new versions of userspace that can deal with
+ * the split (and they can't possibly care about new features...
+ */
+ CMD(add_virtual_intf, NEW_INTERFACE);
+ CMD(change_virtual_intf, SET_INTERFACE);
+ CMD(add_key, NEW_KEY);
+ CMD(start_ap, START_AP);
+ CMD(add_station, NEW_STATION);
+ CMD(add_mpath, NEW_MPATH);
+ CMD(update_mesh_config, SET_MESH_CONFIG);
+ CMD(change_bss, SET_BSS);
+ CMD(auth, AUTHENTICATE);
+ CMD(assoc, ASSOCIATE);
+ CMD(deauth, DEAUTHENTICATE);
+ CMD(disassoc, DISASSOCIATE);
+ CMD(join_ibss, JOIN_IBSS);
+ CMD(join_mesh, JOIN_MESH);
+ CMD(set_pmksa, SET_PMKSA);
+ CMD(del_pmksa, DEL_PMKSA);
+ CMD(flush_pmksa, FLUSH_PMKSA);
+ if (rdev->wiphy.flags & WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL)
+ CMD(remain_on_channel, REMAIN_ON_CHANNEL);
+ CMD(set_bitrate_mask, SET_TX_BITRATE_MASK);
+ CMD(mgmt_tx, FRAME);
+ CMD(mgmt_tx_cancel_wait, FRAME_WAIT_CANCEL);
+ if (rdev->wiphy.flags & WIPHY_FLAG_NETNS_OK) {
+ i++;
+ if (nla_put_u32(msg, i, NL80211_CMD_SET_WIPHY_NETNS))
+ goto nla_put_failure;
+ }
+ if (rdev->ops->set_monitor_channel || rdev->ops->start_ap ||
+ rdev->ops->join_mesh) {
+ i++;
+ if (nla_put_u32(msg, i, NL80211_CMD_SET_CHANNEL))
+ goto nla_put_failure;
+ }
+ CMD(set_wds_peer, SET_WDS_PEER);
+ if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) {
+ CMD(tdls_mgmt, TDLS_MGMT);
+ CMD(tdls_oper, TDLS_OPER);
+ }
+ if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN)
+ CMD(sched_scan_start, START_SCHED_SCAN);
+ CMD(probe_client, PROBE_CLIENT);
+ CMD(set_noack_map, SET_NOACK_MAP);
+ if (rdev->wiphy.flags & WIPHY_FLAG_REPORTS_OBSS) {
+ i++;
+ if (nla_put_u32(msg, i, NL80211_CMD_REGISTER_BEACONS))
+ goto nla_put_failure;
+ }
+ CMD(start_p2p_device, START_P2P_DEVICE);
+ CMD(set_mcast_rate, SET_MCAST_RATE);
+#ifdef CONFIG_NL80211_TESTMODE
+ CMD(testmode_cmd, TESTMODE);
+#endif
+ return i;
+ nla_put_failure:
+ return -ENOBUFS;
+}
+
struct nl80211_dump_wiphy_state {
s64 filter_wiphy;
long start;
@@ -1555,68 +1631,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
if (!nl_cmds)
goto nla_put_failure;
- i = 0;
-#define CMD(op, n) \
- do { \
- if (rdev->ops->op) { \
- i++; \
- if (nla_put_u32(msg, i, NL80211_CMD_ ## n)) \
- goto nla_put_failure; \
- } \
- } while (0)
-
- CMD(add_virtual_intf, NEW_INTERFACE);
- CMD(change_virtual_intf, SET_INTERFACE);
- CMD(add_key, NEW_KEY);
- CMD(start_ap, START_AP);
- CMD(add_station, NEW_STATION);
- CMD(add_mpath, NEW_MPATH);
- CMD(update_mesh_config, SET_MESH_CONFIG);
- CMD(change_bss, SET_BSS);
- CMD(auth, AUTHENTICATE);
- CMD(assoc, ASSOCIATE);
- CMD(deauth, DEAUTHENTICATE);
- CMD(disassoc, DISASSOCIATE);
- CMD(join_ibss, JOIN_IBSS);
- CMD(join_mesh, JOIN_MESH);
- CMD(set_pmksa, SET_PMKSA);
- CMD(del_pmksa, DEL_PMKSA);
- CMD(flush_pmksa, FLUSH_PMKSA);
- if (rdev->wiphy.flags & WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL)
- CMD(remain_on_channel, REMAIN_ON_CHANNEL);
- CMD(set_bitrate_mask, SET_TX_BITRATE_MASK);
- CMD(mgmt_tx, FRAME);
- CMD(mgmt_tx_cancel_wait, FRAME_WAIT_CANCEL);
- if (rdev->wiphy.flags & WIPHY_FLAG_NETNS_OK) {
- i++;
- if (nla_put_u32(msg, i, NL80211_CMD_SET_WIPHY_NETNS))
- goto nla_put_failure;
- }
- if (rdev->ops->set_monitor_channel || rdev->ops->start_ap ||
- rdev->ops->join_mesh) {
- i++;
- if (nla_put_u32(msg, i, NL80211_CMD_SET_CHANNEL))
- goto nla_put_failure;
- }
- CMD(set_wds_peer, SET_WDS_PEER);
- if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) {
- CMD(tdls_mgmt, TDLS_MGMT);
- CMD(tdls_oper, TDLS_OPER);
- }
- if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN)
- CMD(sched_scan_start, START_SCHED_SCAN);
- CMD(probe_client, PROBE_CLIENT);
- CMD(set_noack_map, SET_NOACK_MAP);
- if (rdev->wiphy.flags & WIPHY_FLAG_REPORTS_OBSS) {
- i++;
- if (nla_put_u32(msg, i, NL80211_CMD_REGISTER_BEACONS))
- goto nla_put_failure;
- }
- CMD(start_p2p_device, START_P2P_DEVICE);
- CMD(set_mcast_rate, SET_MCAST_RATE);
-#ifdef CONFIG_NL80211_TESTMODE
- CMD(testmode_cmd, TESTMODE);
-#endif
+ i = nl80211_add_commands_unsplit(rdev, msg);
+ if (i < 0)
+ goto nla_put_failure;
if (state->split) {
CMD(crit_proto_start, CRIT_PROTOCOL_START);
CMD(crit_proto_stop, CRIT_PROTOCOL_STOP);
@@ -1627,7 +1644,6 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
NL80211_FEATURE_SUPPORTS_WMM_ADMISSION)
CMD(add_tx_ts, ADD_TX_TS);
}
- /* add into the if now */
#undef CMD
if (rdev->ops->connect || rdev->ops->auth) {
--
2.8.1
^ permalink raw reply related
* Re: [PATCH 8/8] mac80211: Claim Fast Initial Link Setup (FILS) support
From: Johannes Berg @ 2016-10-26 9:26 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20161026092315.GB3660@jouni.qca.qualcomm.com>
On Wed, 2016-10-26 at 09:23 +0000, Malinen, Jouni wrote:
> On Wed, Oct 26, 2016 at 07:50:36AM +0200, Johannes Berg wrote:
> >
> > On Wed, 2016-10-26 at 01:44 +0300, Jouni Malinen wrote:
> > >
> > > With the previous commits, initial FILS support is now functional
> > > in
> > > mac80211-based drivers for both AP and stations roles.
> >
> > That's a bit misleading, I guess AP role is handled entirely in
> > hostapd? You documented the extended feature bit to explicitly mean
> > station role only :)
>
> Yeah.. In case of mac80211, there was not really changes needed in
> the kernel side for AP mode. That may be different with non-mac80211
> drivers, though, since they might be easier to handle with the AES-
> SIV operations for associations frames handled within the driver.
Right.
> Would you prefer to split that NL80211_EXT_FEATURE_FILS into two
> separate values (_STA and _AP)
I think having it called _STA may be a little clearer, but I think I'm
OK with it the way it is (documented as station) as well.
> and have mac80211 advertise both?
I wouldn't do that, there's nothing that makes it have that capability.
> Or just add a _STA only case for now and see what we need to do with
> NL80211_ATTR_DEVICE_AP_SME cases separately once such a thing is in
> in functional state?
Yeah, we should do that.
Really all I thought you should do was reword the commit message to
make it clear that the flag only implied the station case, and that the
AP case needed no changes.
Perhaps renaming the flag to ..._STA will make that a bit clearer.
johannes
^ permalink raw reply
* Re: [PATCH 8/8] mac80211: Claim Fast Initial Link Setup (FILS) support
From: Malinen, Jouni @ 2016-10-26 9:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1477461036.4059.14.camel@sipsolutions.net>
On Wed, Oct 26, 2016 at 07:50:36AM +0200, Johannes Berg wrote:
> On Wed, 2016-10-26 at 01:44 +0300, Jouni Malinen wrote:
> > With the previous commits, initial FILS support is now functional in
> > mac80211-based drivers for both AP and stations roles.
>=20
> That's a bit misleading, I guess AP role is handled entirely in
> hostapd? You documented the extended feature bit to explicitly mean
> station role only :)
Yeah.. In case of mac80211, there was not really changes needed in the
kernel side for AP mode. That may be different with non-mac80211
drivers, though, since they might be easier to handle with the AES-SIV
operations for associations frames handled within the driver.
Would you prefer to split that NL80211_EXT_FEATURE_FILS into two
separate values (_STA and _AP) and have mac80211 advertise both? Or just
add a _STA only case for now and see what we need to do with
NL80211_ATTR_DEVICE_AP_SME cases separately once such a thing is in in
functional state?
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH 5/8] cfg80211: Add KEK/nonces for FILS association frames
From: Malinen, Jouni @ 2016-10-26 9:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1477460187.4059.4.camel@sipsolutions.net>
T24gV2VkLCBPY3QgMjYsIDIwMTYgYXQgMDc6MzY6MjdBTSArMDIwMCwgSm9oYW5uZXMgQmVyZyB3
cm90ZToNCj4gPiArKysgYi9uZXQvd2lyZWxlc3Mvbmw4MDIxMS5jDQo+ID4gKwlbTkw4MDIxMV9B
VFRSX0ZJTFNfS0VLXSA9IHsgLnR5cGUgPSBOTEFfQklOQVJZLA0KPiA+ICsJCQkJwqDCoMKgwqAu
bGVuID0gRklMU19NQVhfS0VLX0xFTiB9LA0KPiA+ICsJW05MODAyMTFfQVRUUl9GSUxTX05PTkNF
U10gPSB7IC50eXBlID0gTkxBX0JJTkFSWSwNCj4gPiArCQkJCcKgwqDCoMKgwqDCoMKgLmxlbiA9
IDIgKiBGSUxTX05PTkNFX0xFTiB9LA0KDQo+IElmIHlvdSByZW1vdmUgdGhlIHR5cGUgPSBOTEFf
QklOQVJZIGFuZCBqdXN0IGxlYXZlIHRoZSB0eXBlIHplcm8sIHRoZW4NCj4geW91J2xsIGdldCAq
bWluaW11bSogbGVuZ3RoIHZhbGlkYXRpb24sIHJhdGhlciB0aGFuIGxpbWl0aW5nIHRoZQ0KPiBt
YXhpbXVtIGxlbmd0aC4gVGhhdCBzZWVtcyBtb3JlIGFwcHJvcHJpYXRlIGZvciB0aGUgbm9uY2Vz
Pw0KDQpGSUxTX0tFSyBpcyB2YXJpYWJsZSBsZW5ndGgsIGJ1dCBGSUxTX05PTkNFUyBzaG91bGQg
YmUgZXhhY3RseSAyICoNCkZJTFNfTk9OQ0VfTEVOLiBJIGRpZG4ndCByZW1lbWJlciB0aGUgbWlu
aW11bSBsZW5ndGggY2FzZSBoZXJlLCBidXQgeWVzLA0KdGhhdCBzb3VuZHMgcmVhc29uYWJsZSBm
b3IgRklMU19OT05DRVMuDQoNCj4gPiArCWlmIChpbmZvLT5hdHRyc1tOTDgwMjExX0FUVFJfRklM
U19OT05DRVNdKSB7DQo+ID4gKwkJaWYgKG5sYV9sZW4oaW5mby0+YXR0cnNbTkw4MDIxMV9BVFRS
X0ZJTFNfTk9OQ0VTXSkNCj4gPiAhPQ0KPiA+ICsJCcKgwqDCoMKgMiAqIEZJTFNfTk9OQ0VfTEVO
KQ0KPiA+ICsJCQlyZXR1cm4gLUVJTlZBTDsNCj4gDQo+IFlvdSdyZSB2YWxpZGF0aW5nIHRoZSAq
ZXhhY3QqIGxlbmd0aCBoZXJlLCB3aGljaCB1bmZvcnR1bmF0ZWx5IG5sYXR0cg0KPiBkb2Vzbid0
IHN1cHBvcnQgcmlnaHQgbm93LCBidXQgcGVyaGFwcyB3ZSBjYW4gbGl2ZSB3aXRoIGNoZWNraW5n
IHRoYXQNCj4gaXQncyBhdCBsZWFzdCB0aGF0IG1hbnkgYnl0ZXMsIGFuZCB1c2luZyBvbmx5IDIq
bm9uY2VzPyBXZSBkbyB0aGF0IGZvcg0KPiBtb3N0IG90aGVyIGF0dHJpYnV0ZXMgKGxpa2UgTUFD
IGFkZHJlc3NlcykuDQoNClRoaXMgd2FzIGJlY2F1c2Ugb2YgdGhlIC5sZW4gYWJvdmUgZW5kaW5n
IHVwIGFsbG93aW5nIHNob3J0ZXIgdmFsdWVzLi4NClNpbmNlIHdlIGRvIHRoYXQgbWluaW11bSBs
ZW5ndGggY2hlY2sgb25seSBmb3IgbnVtYmVyIG9mIG90aGVyDQphdHRyaWJ1dGVzLCBJIGd1ZXNz
IHdlIGNhbiBkbyBpdCBoZXJlIGFzIHdlbGwgYW5kIGlnbm9yZSB3aGF0ZXZlciBlbHNlDQp0aGUg
dXNlciBzcGFjZSBtaWdodCBoYXZlIGFkZGVkIGluY29ycmVjdGx5Lg0KDQo+IE9yIGRvIHdlIGV4
cGVjdCB0byBleHRlbmQgdGhpcyB0byBtb3JlIHRoYW4gMiBub25jZXMgaW4gdGhlIGZ1dHVyZSwg
YXQNCj4gd2hpY2ggcG9pbnQgd2UnbGwgbmVlZCB0aGUgbGVuZ3RoPw0KDQpObywgdGhpcyBzaG91
bGQgcmVtYWluIGV4YWN0bHkgdHdvIG5vbmNlcyBhbmQgZWFjaCBvZiB0aG9zZSBoYXZpbmcNCmV4
YWN0bHkgMTYgb2N0ZXRzLg0KDQotLSANCkpvdW5pIE1hbGluZW4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFBHUCBpZCBFRkM4OTVGQQ==
^ permalink raw reply
* Re: [PATCH] NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
From: Tobias Klauser @ 2016-10-26 9:03 UTC (permalink / raw)
To: Lauro Ramos Venancio, Aloisio Almeida Jr
Cc: Samuel Ortiz, linux-wireless, linux-kernel, Vincent Cuissard,
Guenter Roeck
In-Reply-To: <20161026090012.29747-1-tklauser@distanz.ch>
On 2016-10-26 at 11:00:12 +0200, Tobias Klauser <tklauser@distanz.ch> wrote:
> Including linux/unaligned/access_ok.h causes the allmodconfig build on
> ia64 (and maybe others) to fail with the following warnings:
>
> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'
> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32'
> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64'
> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16'
> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32'
> include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64'
> include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64'
>
> Fix these by including asm/unaligned.h instead and leave it up to the
> architecture to decide how to implement unaligned accesses.
>
> Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Link: https://lkml.org/lkml/2016/10/22/247
> Cc: Vincent Cuissard <cuissard@marvell.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
There are two other instances of the same issue in the NFC subsystem,
namely in drivers/nfc/nxp-nci/firmware.c and drivers/nfc/nxp-nci/i2c.c
Guenter Roeck already sent a patch for these on 2015-08-01. It would be
nice if it could be applied as well.
[1] https://patchwork.kernel.org/patch/6922341/
Thanks
^ 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