Ubuntu (kernel 4.4) + Intel 7265N = cannot pair bluetooth

2017-05-01 Thread Luis Pablo Gallo
I have a notebook with Ubuntu installed, and an Intel 7265N driver for WiFi and bluetooth. I cannot pair any device to it. Ubuntu finds the devices, but doesn't get their name, and doesn't allow me to pair them either. Is there a fix for this? Should it be working? Thanks! -- Luis Pablo

[PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

2017-05-01 Thread Adrian Chadd
This reverts b057886524be060021e3cfad0ba8458c850330cd in 2015 which converted this allocation from dma_map_coherent() to kzalloc() / dma_map_single(). The current problem manifests when using later model NICs with larger (>700KiB) scratch spaces in memory. Although the kzalloc call succeeds, the

Re: [PATCH v3 2/2] mwifiex: pcie: add card_reset() support

2017-05-01 Thread Dmitry Torokhov
On Mon, May 01, 2017 at 12:37:00PM -0700, Brian Norris wrote: > Similar to the SDIO driver, we should implement this so that we will > automatically reset the device whenever there's a command timeout or > similar. > > Signed-off-by: Brian Norris Reviewed-by: Dmitry

Re: [PATCH v3 1/2] mwifiex: initiate card-specific work atomically

2017-05-01 Thread Dmitry Torokhov
On Mon, May 01, 2017 at 12:36:59PM -0700, Brian Norris wrote: > The non-atomic test + set is a little awkward here, and it technically > means we might double-schedule work unnecessarily. AFAICT, this is not > really a problem, since the extra "work" will be a no-op (the flag(s) > will be cleared

[PATCH v3 1/2] mwifiex: initiate card-specific work atomically

2017-05-01 Thread Brian Norris
The non-atomic test + set is a little awkward here, and it technically means we might double-schedule work unnecessarily. AFAICT, this is not really a problem, since the extra "work" will be a no-op (the flag(s) will be cleared by then), but it's still an anti-pattern. Rewrite this to use the

[PATCH v3 2/2] mwifiex: pcie: add card_reset() support

2017-05-01 Thread Brian Norris
Similar to the SDIO driver, we should implement this so that we will automatically reset the device whenever there's a command timeout or similar. Signed-off-by: Brian Norris --- v3: keep all the new reset code in patch 2, not patch 1 v2: use atomic test/set, based on

Re: [PATCH v2 1/2] mwifiex: initiate card-specific work atomically

2017-05-01 Thread Brian Norris
On Mon, May 01, 2017 at 11:45:48AM -0700, Brian Norris wrote: > The non-atomic test + set is a little awkward here, and it technically > means we might double-schedule work unnecessarily. AFAICT, this is not > really a problem, since the extra "work" will be a no-op (the flag(s) > will be cleared

[PATCH v2 2/2] mwifiex: pcie: add card_reset() support

2017-05-01 Thread Brian Norris
Similar to the SDIO driver, we should implement this so that we will automatically reset the device whenever there's a command timeout or similar. Signed-off-by: Brian Norris --- v2: use atomic test/set, based on Dmitry's suggestion ---

[PATCH v2 1/2] mwifiex: initiate card-specific work atomically

2017-05-01 Thread Brian Norris
The non-atomic test + set is a little awkward here, and it technically means we might double-schedule work unnecessarily. AFAICT, this is not really a problem, since the extra "work" will be a no-op (the flag(s) will be cleared by then), but it's still an anti-pattern. Rewrite this to use the

Re: [PATCH 5/9] cfg80211/nl80211: add authorized flag to roaming event

2017-05-01 Thread Arend van Spriel
On 4/28/2017 11:02 PM, Johannes Berg wrote: On Wed, 2017-04-26 at 12:05 +0200, Arend van Spriel wrote: the mobility domain does not require new 802.1X authentication, but roaming to another mobility domain does. Not sure about the terminology here. Is "mobility domain" the same as "ESS"