Re: [PATCH v3 7/7] mmc: Only descend into mmc directory when CONFIG_MMC is set

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v3 7/7] mmc: Only descend into mmc directory when CONFIG_MMC is set

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc2 next-20170310] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: Ralink - rt2800usb

On Fri, 2017-03-17 at 13:26 -0700, Nikita N. wrote: > Hi All, > I'm addressing to the maintainers of Ralink driver rt2800usb > (RT2870,RT3070). > To who can I send my request? This mailing list (linux-wireless@) is the right place. Dan

Ralink - rt2800usb

Hi All, I'm addressing to the maintainers of Ralink driver rt2800usb (RT2870,RT3070). To who can I send my request? Thanks -- http://www.fastmail.com - Or how I learned to stop worrying and love email again

Re: [RFC v4 06/21] ath10k: sdio support

On 2017-03-16 10:33, Kalle Valo wrote: Erik Stromdahl writes: There seems to be same pattern for reading four bytes, what if we should add a helper for that? Something like ath10k_sdio_read32()? It could handle the kmalloc and switch endianess also. But please

Re: [PATCH 2/3] ath10k: add support for channels in licensed bands

you may quickly realize that this patch cannot be a solution example: - if (channel >= 1 && channel <= 14) { + if (channel >= 1 && channel <= 7) { status->band = NL80211_BAND_2GHZ; do you you really want to limit the 2.4 channels for all users? Am 16.03.2017 um

Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function

On Thu, Mar 16, 2017 at 11:03:52PM +0900, Greg KH wrote: > On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote: > > Luis: would you ack this patch now I followed your guidance? > > It's up to Luis now :) I'm reviewing now! Luis

[PATCHv2 1/3] ath9k: Support channels in licensed bands

From: Ben Greear Many chips support channels in licensed bands. Add support for those, along with a corresponding kernel config option to disable them by default. Note that these channels are not selectable even if the option has been compiled unless the user modifies

Re: [PATCH v2 1/5] NFC: st21nfca: Fix obvious typo when check error code

On Tue, 2017-03-07 at 12:25 +0200, Andy Shevchenko wrote: > We return -ENODEV if ACPI provides a GPIO resource. Looks really > wrong. > If it has even been tested? Any comments on this clean up? Next patch which is dependent to this is related to ACPI enumeration. After GPIO ACPI library gets

ANNOUNCE: New tutorial on XDP

The tech committee would like to announce our first accepted tutorial Monsieurs Andy Gospodarek and Jesper Dangaard Brouer will give an XDP tutorial catered to mere mortals titled "XDP for the Rest of Us" Description: - XDP (eXpress Data Path) has been one of the most widely discussed

Re: [PATCH 4.11] ath10k: fix incorrect wlan_mac_base in qca6174_regs

writes: > From: Ryan Hsu > > In the 'commit ebee76f7fa46 ("ath10k: allow setting coverage class")', > it inherits the design and the address offset from ath9k, but the address > is not applicable to QCA6174, which leads to a random crash while

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On Friday, March 17, 2017 1:58:58 PM EDT Johannes Berg wrote: > > > I guess this is intended behavior? > > > > I had thought this was intended behavior as well but I see that a > > patch is already prepped and tested to make this not happen. At any > > rate it wasn't appearing to affect my

Re: [PATCH 1/3] ath9k: Support channels in licensed bands

On Friday, March 17, 2017 2:40:50 PM CET Zefir Kurtisi wrote: > On 03/16/2017 04:13 PM, Simon Wunderlich wrote: > > @@ -126,10 +142,14 @@ int ath9k_cmn_init_channels_rates(struct ath_common > > *common)> > > { > > > > struct ath_hw *ah = (struct ath_hw *)common->ah; > > void *channels;

Re: [PATCH 1/3] ath9k: Support channels in licensed bands

On 03/16/2017 04:13 PM, Simon Wunderlich wrote: > From: Ben Greear > > Many chips support channels in licensed bands. Add support for those, > along with a corresponding kernel config option to disable them by > default. Note that these channels are not selectable even

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

> > I guess this is intended behavior? > > I had thought this was intended behavior as well but I see that a > patch is already prepped and tested to make this not happen. At any > rate it wasn't appearing to affect my usecase. I can't actually see how it'd affect any usecase, since you really

Re: [PATCH 3/3] ath9k: add noise floor override option

On 17 March 2017 at 09:55, Simon Wunderlich wrote: > On Friday, March 17, 2017 9:48:07 AM CET Janusz Dziedzic wrote: >> On 16 March 2017 at 16:13, Simon Wunderlich wrote: >> > Introduce a debugfs option to manually override the noise floor, >> >

Re: [PATCH 2/2] mac80211: Drop new node with weak power

On Fri, 2017-03-17 at 14:56 +0900, Masashi Honma wrote: > > It seems that this is really what the meshcfg.rssi_threshold was > > intended for, and the plink code *does* take it into account. Can > > you > > explain where that's breaking down? > > Indeed meshcfg.rssi_threshold is already referred

[PATCH] cfg80211: preserve wdev ID across netns changes

When a wdev changes network namespace, its wdev ID will get reassigned since NETDEV_REGISTER is called again, in the new network namespace. Avoid that by checking if it was already assigned before, and document why we do that. Reported-and-tested-by: Arend Van Spriel

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On 17-3-2017 10:24, Johannes Berg wrote: > On Fri, 2017-03-17 at 10:06 +0100, Arend Van Spriel wrote: >> On 16-3-2017 22:51, Mark Asselstine wrote: >>> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote: To support network namespace the driver must assure all created

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On 17-3-2017 10:24, Johannes Berg wrote: > On Fri, 2017-03-17 at 10:06 +0100, Arend Van Spriel wrote: >> On 16-3-2017 22:51, Mark Asselstine wrote: >>> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote: To support network namespace the driver must assure all created

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On 17-3-2017 10:06, Arend Van Spriel wrote: > On 16-3-2017 22:51, Mark Asselstine wrote: >> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote: >>> To support network namespace the driver must assure all created >>> network interfaces are in the same namespace as the wiphy instance.

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On Fri, 2017-03-17 at 10:06 +0100, Arend Van Spriel wrote: > On 16-3-2017 22:51, Mark Asselstine wrote: > > On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote: > > > To support network namespace the driver must assure all created > > > network interfaces are in the same namespace as

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On 16-3-2017 22:51, Mark Asselstine wrote: > On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote: >> To support network namespace the driver must assure all created >> network interfaces are in the same namespace as the wiphy instance. >> >> Reported-by: Mark Asselstine

Re: [PATCH 3/3] ath9k: add noise floor override option

On 16 March 2017 at 16:13, Simon Wunderlich wrote: > Introduce a debugfs option to manually override the noise floor, > ignoring the automatically tuned noise floor of the driver/hw. > > In my tests with a AR9580 based module and a tx99 5 MHz interferer, > I could tune

Dell DW1601 (WIL6210)

Dear linux-wireless developers, I recently acquired a few Dell DW1601 cards and after a few initial searches it sounded like they could be used to connect to each other. Now it seems that they do not have the wifi connectivity enabled, just WBE. relevant lspci output: 03:00.0 PCI bridge [0604]:

Re: [PATCH] staging: wilc1000: fix incorrect copy of pmkid data

Am 17.03.2017 00:21, schrieb Colin King: > From: Colin Ian King > > The pmkid data is meant be be copied to the previous item in the > pmkidlist, however the code is just copying the data to itself because > the src index into pmkidlist is the same as the dst index

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

On 16-3-2017 22:51, Mark Asselstine wrote: > On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote: >> To support network namespace the driver must assure all created >> network interfaces are in the same namespace as the wiphy instance. >> >> Reported-by: Mark Asselstine

Re: Fw: [Bug 194903] New: After updating Kernel to 4.9.9 my wireless adapter does not work

On 17-3-2017 6:47, Stephen Hemminger wrote: > Hi Stephen, The issue here is with an out-of-tree driver, ie. broadcom-wl, so not really a kernel issue. Anyway, I asked for more info in bugzilla to determine whether using the brcmfmac driver, which is supported upstream, is an option. Regards,

Re: pull-request: mac80211 2017-03-16

On Thu, 2017-03-16 at 11:18 -0700, David Miller wrote: > From: Johannes Berg > Date: Thu, 16 Mar 2017 10:51:55 +0100 > > > Here's the pull request you were waiting for. I went through all my > > pending patches but only this one is applicable for net.git at this > >

Ralink - rt2800usb

Hi All, I'm addressing to the maintainers of Ralink driver rt2800usb (RT2870,RT3070) if still anybody alive. To who can I send my inquiry? Thanks -- http://www.fastmail.com - Accessible with your email software or over the web

[PATCH v2] mac80211: Use rssi_threshold even though user_mpm=1

Previously the meshcfg.rssi_threshold did not work with user_mpm=1. Signed-off-by: Masashi Honma --- net/mac80211/mesh.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c index 6e7b6a0..281d834