linux-next: build failure after merge of the wireless-drivers-next tree

Hi all, After merging the wireless-drivers-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe': drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function

Re: [v8] Add new mac80211 driver mwlwifi.

David Lin wrote: > This patch provides the mwlwifi driver for Marvell 8863, 8864 and 8897 > chipsets. > This driver was developed as part of the openwrt.org project to support > Linksys WRT1900AC and is maintained on https://github.com/kaloz/mwlwifi. > > The mwlwifi driver

Re: linux-next: build failure after merge of the wireless-drivers-next tree

On 19 July 2016 at 08:30, Kalle Valo wrote: > Stephen Rothwell writes: > >> After merging the wireless-drivers-next tree, today's linux-next build >> (powerpc allyesconfig) failed like this: >> >> drivers/mtd/devices/bcm47xxsflash.c: In function

RE: [v8] Add new mac80211 driver mwlwifi.

Kalle Valo [mailto:kv...@codeaurora.org] wrote:. > > David Lin wrote: > > This patch provides the mwlwifi driver for Marvell 8863, 8864 and 8897 > > chipsets. > > This driver was developed as part of the openwrt.org project to > > support Linksys WRT1900AC and is maintained on

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Rafał Miłecki writes: > On 19 July 2016 at 08:30, Kalle Valo wrote: >> Stephen Rothwell writes: >> >>> After merging the wireless-drivers-next tree, today's linux-next build >>> (powerpc allyesconfig) failed like this: >>> >>>

Re: [PATCH v7] wlcore: spi: add wl18xx support

Eyal Reizer writes: > From: Eyal Reizer > > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs

Re: [PATCH 0/4] brcm80211: Misc coverity fixes

+ Bob On 19-7-2016 1:24, Florian Fainelli wrote: > Hi, > > This patch series addresses several coverity issues, they all seemed relevant > to me. Hi Florian, Been a while so nice to see coverity fixes popping up. Actually something that I have on my todo list to add our brcm80211 to coverity

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Stephen Rothwell writes: > After merging the wireless-drivers-next tree, today's linux-next build > (powerpc allyesconfig) failed like this: > > drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe': > drivers/mtd/devices/bcm47xxsflash.c:299:17:

[PATCH v6] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

RE: [PATCH v7] wlcore: spi: add wl18xx support

> > From: Eyal Reizer > > > > Add support for using with both wl12xx and wl18xx. > > > > - all wilink family needs special init command for entering wspi mode. > > extra clock cycles should be sent after the spi init command while the > > cs pin is high. > > - Use

Re: [PATCH] mtd: add arch dependency for MTD_BCM47XXSFLASH symbol

On Tue, Jul 19, 2016 at 09:08:32AM +0200, Rafał Miłecki wrote: > We dropped strict MIPS dependency for bcm47xxsflash driver in: > commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of > KSEG0ADDR()") but using ioremap_cache still limits building it to few > selected

Re: [v2, RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

Igor Mitsyanko wrote: > From: Avinash Patil > > This patch adds support for new FullMAC WiFi driver for Quantenna > QSR10G chipsets. > > QSR10G is Quantenna's 8x8, 160M, 11ac offering. > QSR10G supports 2 simultaneous WMACs- one 5G and

Re: [PATCH 2/4] brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill

On 19-7-2016 1:24, Florian Fainelli wrote: > In case dma_mapping_error() returns an error in dma_rxfill, we would be > leaking a packet that we allocated with brcmu_pkt_buf_get_skb(). > > Reported-by: coverity (CID 1081819) > Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to

[PATCH v7] wlcore: spi: add wl18xx support

From: Eyal Reizer Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a

Re: linux-next: build failure after merge of the wireless-drivers-next tree

On 19 July 2016 at 09:09, Kalle Valo wrote: > Rafał Miłecki writes: > >> On 19 July 2016 at 08:30, Kalle Valo wrote: >>> Stephen Rothwell writes: >>> After merging the wireless-drivers-next tree, today's

[PATCH] mtd: add arch dependency for MTD_BCM47XXSFLASH symbol

We dropped strict MIPS dependency for bcm47xxsflash driver in: commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()") but using ioremap_cache still limits building it to few selected architectures only. A recent commit 57d8f7dd2132 ("bcma: allow enabling serial

Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211

On 19-7-2016 1:24, Florian Fainelli wrote: > struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2 > * ETH_ALEN, which will potentially overrun the destination buffer. NACK - this is intentional. Have to admit it is a bit of trickery. struct ieee80211_rts is mapped over struct

[RFC] ath10k: silence firmware file probing warnings

Firmware files are versioned to prevent older driver instances to load unsupported firmware blobs. This is reflected with a fallback logic which attempts to load several firmware files. This however produced a lot of unnecessary warnings sometimes confusing users and leading them to rename

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Rafał Miłecki writes: > On 19 July 2016 at 09:09, Kalle Valo wrote: >> Rafał Miłecki writes: >> >>> On 19 July 2016 at 08:30, Kalle Valo wrote: Stephen Rothwell writes: >

Re: ath10k: disable wake_tx_queue for older devices

Michal Kazior wrote: > Ideally wake_tx_queue should be used regardless as > it is a requirement for reducing bufferbloat and > implementing airtime fairness in the future. > > However some setups (typically low-end platforms > hosting QCA988X) suffer performance

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Tue, Jul 19, 2016 at 01:02:13PM +, Machani, Yaniv wrote: > On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote: > > > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute > > > to specify the minimum interval of time during which a mesh STA can > > > send only one Action

Re: TCP performance regression in mac80211 triggered by the fq code

On 12 July 2016 at 12:09, Felix Fietkau wrote: > Hi, > > With Toke's ath9k txq patch I've noticed a pretty nasty performance > regression when running local iperf on an AP (running the txq stuff) to > a wireless client. > > Here's some things that I found: > - when I use only one

RE: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote: > Chun-Yeow Yeoh > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving > time > > On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote: > > > To improve that, added an 'immediate' flag to be used when the > > > path

RE: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template

On Mon, Jul 18, 2016 at 21:52:22, Johannes Berg wrote: > linux- wirel...@vger.kernel.org; net...@vger.kernel.org > Subject: Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon > template > > On Mon, 2016-07-18 at 09:38 -0400, Bob Copeland wrote: > > On Wed, Jul 13, 2016 at 02:45:40PM +0300,

Re: [PATCH] mtd: add arch dependency for MTD_BCM47XXSFLASH symbol

Brian Norris writes: > On Tue, Jul 19, 2016 at 09:08:32AM +0200, Rafał Miłecki wrote: >> We dropped strict MIPS dependency for bcm47xxsflash driver in: >> commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of >> KSEG0ADDR()") but using

Re: [v2,1/3] ath6kl: Fix WLAN tethering authentication problem.

Pierre Le Magourou wrote: > From: Pierre Le Magourou > > When enabling WLAN tethering, a new AP is visible and a STA could > connect to it. When the STA tries to authenticate to the newly created > AP, the WPA authentication mechanism is stuck in

Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received

On Tue, Jul 19, 2016 at 11:16:24AM +0900, Masashi Honma wrote: > This patch does not fix starting MPSP, this patch fixes ending of MPSP. > Without this patch, local peer continues MPSP even if we lost opposite peer > accidentally. OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote: > When a packet is received for transmission, > a PREQ frame is sent to resolve the appropriate path to the desired > destination. > After path was established, any sequential PREQ will be sent only after >

Re: [PATCH 4/4] brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()

On 19-7-2016 1:24, Florian Fainelli wrote: > wlc_phy_txpower_get_current() does a logical OR of power->flags, which > presumes that power.flags was initiliazed earlier by the caller, > unfortunately, this is not the case, so make sure we zero out the struct > tx_power before calling into

[PATCH 4/4] ath10k: fix spurious tx/rx during boot

HW Rx filters and masks are not configured properly by firmware during boot sequences. The MAC_PCU_ADDR1 is set to 0s instead of 1s which allows the HW to ACK any frame that passes through MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself is misconfigured on boot as well. The combination of these

[PATCH 3/4] ath10k: add wmi command barrier utility

This allows placing command barriers for explicit serializing and synchronizing state. Useful for future driver development. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/core.h | 1 + drivers/net/wireless/ath/ath10k/wmi.c | 31

[PATCH 0/4] ath10k: fix spurious tx/rx during boot

Hi, Recently Marek discovered the device transmits "stuff" during device/driver boot. The problem is related with the long known "no channel" warning and it's a consequence of the same bug - rx filters not being programmed properly by firmware. See last patch for more details. I didn't do

[PATCH 2/4] ath10k: implement wmi echo event

Will be useful for implementing command barriers. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/wmi-ops.h | 12 drivers/net/wireless/ath/ath10k/wmi-tlv.c | 28 drivers/net/wireless/ath/ath10k/wmi.c | 29

[PATCH 1/4] ath10k: implement wmi echo command

Will be useful for implementing command barriers. Signed-off-by: Michal Kazior --- drivers/net/wireless/ath/ath10k/wmi-ops.h | 17 + drivers/net/wireless/ath/ath10k/wmi-tlv.c | 29 + drivers/net/wireless/ath/ath10k/wmi.c |

Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211

Arend Van Spriel writes: > On 19-7-2016 1:24, Florian Fainelli wrote: >> struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2 >> * ETH_ALEN, which will potentially overrun the destination buffer. > > NACK - this is intentional. Have to admit it

[PATCH] nl80211: Expand max value of NL80211_MESHCONF_HT_OPMODE command

Previously, the max value of NL80211_MESHCONF_HT_OPMODE was 16. But it causes EINVAL when IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED and IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT bit is enabled. So this patch expands the max value. Signed-off-by: Masashi Honma ---

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote: > > To improve that, added an 'immediate' flag to be used when the path needs > > to be resolved. > > Once set, a PREQ frame will be send w/o considering the MinInterval > > parameter. > > Suggest that you try to reduce the

Re: [PATCH 1/4] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

On 19-7-2016 1:24, Florian Fainelli wrote: > In case brcmf_sdiod_recv_chain() cannot complete a succeful call to > brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we > should, fix this. > > Reported-by: coverity (CID 1164856) > Fixes: a413e39a38573 ("brcmfmac: fix

Re: TCP performance regression in mac80211 triggered by the fq code

On 2016-07-19 15:13, Michal Kazior wrote: > On 12 July 2016 at 12:09, Felix Fietkau wrote: >> Hi, >> >> With Toke's ath9k txq patch I've noticed a pretty nasty performance >> regression when running local iperf on an AP (running the txq stuff) to >> a wireless client. >> >> Here's

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]

[PATCH 1/3] rtlwifi: don't add include path for rtl8188ee

For rtl8188ee, we pass -Idrivers/net/wireless/rtlwifi/ to gcc, however that directy no longer exists, so evidently this option is no longer required here and can be removed to avoid a warning when building with 'make W=1' or 'gcc -Wmissing-include-dirs' Signed-off-by: Arnd Bergmann

Re: [PATCH v2 05/11] Kbuild: don't add obj tree in additional includes

On Tuesday, July 19, 2016 5:33:44 PM CEST Kalle Valo wrote: > Arnd Bergmann writes: > > > On Monday, July 18, 2016 10:14:39 PM CEST Michal Marek wrote: > >> On Wed, Jun 15, 2016 at 05:45:47PM +0200, Arnd Bergmann wrote: > >> > When building with separate object directories and

[PATCH 3/3] staging/rtl8192u: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]

Re: [PATCH v2 05/11] Kbuild: don't add obj tree in additional includes

Arnd Bergmann writes: > On Monday, July 18, 2016 10:14:39 PM CEST Michal Marek wrote: >> On Wed, Jun 15, 2016 at 05:45:47PM +0200, Arnd Bergmann wrote: >> > When building with separate object directories and driver specific >> > Makefiles that add additional header include paths,

Problem connecting to wifi on libertas_cpio (sd8686)

Hi everyone! I’ve just got myself a Viliv N5 and am trying to get the integrated Wifi chipset working on it. I am able to see networks around me but any attempts to connect them appear to time out and fail. I have filed a linux kernel bug related to this issue:

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann writes: > Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of > incorrect code that results from 'char' being unsigned here, e.g. > > staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always > false due to limited range of

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann writes: > On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote: >> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c >> > b/drivers/staging/rtl8192e/rtl819x_TSProc.c >> > index 2c8a526773ed..e0a2fe5e6148 100644 >> > ---

Re: Problem connecting to wifi on libertas_cpio (sd8686)

On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote: > Hi everyone! > > I’ve just got myself a Viliv N5 and am trying to get the integrated > Wifi chipset working on it. > > I am able to see networks around me but any attempts to connect them > appear to time out and fail. > > I

Re: [PATCH 0/4] brcm80211: Misc coverity fixes

On 07/19/2016 02:20 AM, Arend Van Spriel wrote: > + Bob > > On 19-7-2016 1:24, Florian Fainelli wrote: >> Hi, >> >> This patch series addresses several coverity issues, they all seemed relevant >> to me. > > Hi Florian, > > Been a while so nice to see coverity fixes popping up. Actually >

Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211

On 07/19/2016 03:38 AM, Arend Van Spriel wrote: > On 19-7-2016 1:24, Florian Fainelli wrote: >> struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2 >> * ETH_ALEN, which will potentially overrun the destination buffer. > > NACK - this is intentional. Have to admit it is a bit

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote: > > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c > > b/drivers/staging/rtl8192e/rtl819x_TSProc.c > > index 2c8a526773ed..e0a2fe5e6148 100644 > > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c > > +++

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland wrote: > On Tue, Jul 19, 2016 at 01:02:13PM +, Machani, Yaniv wrote: >> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote: >> > > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute >> > > to specify the

Re: ath9k_hw: fix spectral scan on AR9285 and newer

Felix Fietkau wrote: > The register layout of AR_PHY_SPECTRAL_SCAN has changed, only AR9280 > uses the old layout > > Signed-off-by: Felix Fietkau Thanks, 1 patch applied to ath-next branch of ath.git: 7d6c2d1e34ef ath9k_hw: fix spectral scan on AR9285 and newer

Re: [v2] ath9k: simplify the code-paths when not using the built-in EEPROM

Martin Blumenstingl wrote: > There were two paths in the code for "external" eeprom sources. The code > in eeprom.c only handled the cases where the eeprom data was loaded via > request_firmware. ahb.c and pci.c on the other hand had some duplicate > code which

Re: ath6kl: sme_state shortcut to SME_DISCONNECTED removed

engineer...@keppy.com wrote: > From: Dan Kephart > > When an NL80211_DISCONNECT is sent to cfg80211, the driver's cfg80211 > disconnect function sets the sme_state to SME_DISCONNECTED before receiving > a WMI_DISCONNECT_EVENT from the firmware. This caused cfg80211 to

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Absolutely! With the debug logging enabled I got the following: Connecting the device initially with debug enabled: [  205.302685] libertas_sdio: Libertas SDIO driver [  205.302698] libertas_sdio: Copyright Pierre Ossman [  205.503465] cfg80211: World regulatory domain updated: [  205.503478]

Re: Problem connecting to wifi on libertas_cpio (sd8686)

So I’ve now disabled IPv6 and have set the GB (Great Britain) regulation code using: iw reg set IN Now when I try to connect to the network using wicd the system seems to crash - I guess at least it’s doing something more than just asking for the password again like it did with NetworkManager

Re: [PATCH 0/4] brcm80211: Misc coverity fixes

On 19-7-2016 18:41, Florian Fainelli wrote: > On 07/19/2016 02:20 AM, Arend Van Spriel wrote: >> + Bob >> >> On 19-7-2016 1:24, Florian Fainelli wrote: >>> Hi, >>> >>> This patch series addresses several coverity issues, they all seemed >>> relevant >>> to me. >> >> Hi Florian, >> >> Been a while

Re: [PATCH 0/4] brcm80211: Misc coverity fixes

On 07/19/2016 11:21 AM, Arend Van Spriel wrote: > On 19-7-2016 18:41, Florian Fainelli wrote: >> On 07/19/2016 02:20 AM, Arend Van Spriel wrote: >>> + Bob >>> >>> On 19-7-2016 1:24, Florian Fainelli wrote: Hi, This patch series addresses several coverity issues, they all seemed

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Just to head this off, since I noticed it... On Tue, Jul 19, 2016 at 05:08:59PM +0300, Kalle Valo wrote: > Rafał Miłecki writes: > > I sent a patch seconds ago, you may just take a look at it. If you > > still prefer to revert my commit, go ahead. > > Ok, let's try your fix.

Re: [PATCH v2 05/11] Kbuild: don't add obj tree in additional includes

Arnd Bergmann writes: >> > I think that's fine, a couple were already picked up, and what I have >> > left now is >> > >> > a281bfa5713a [SUBMITTED 20160615] [EXPERIMENTAL] Kbuild: enable >> > -Wmissing-include-dirs by default >> > 83934921e68e [SUBMITTED 20160615] rtlwifi: don't

Re: [V2] bcma: define ChipCommon B MII registers

Rafał Miłecki wrote: > We don't have access to datasheets to document all the bits but we can > name these registers at least. > > Signed-off-by: Rafał Miłecki Thanks, 1 patch applied to wireless-drivers-next.git: cc2d1de06f05 bcma: define ChipCommon B MII registers -- Sent

Re: [1/4] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

Florian Fainelli wrote: > In case brcmf_sdiod_recv_chain() cannot complete a succeful call to > brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we > should, fix this. > > Reported-by: coverity (CID 1164856) > Fixes: a413e39a38573 ("brcmfmac: fix

Re: [v7] wlcore: spi: add wl18xx support

Eyal Reizer wrote: > From: Eyal Reizer > > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is

Re: [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211

On 19-7-2016 18:42, Florian Fainelli wrote: > On 07/19/2016 03:38 AM, Arend Van Spriel wrote: >> On 19-7-2016 1:24, Florian Fainelli wrote: >>> struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2 >>> * ETH_ALEN, which will potentially overrun the destination buffer. >> >>

linux-next: manual merge of the l2-mtd tree with the wireless-drivers-next tree

Hi Brian, Today's linux-next merge of the l2-mtd tree got a conflict in: drivers/mtd/devices/Kconfig between commit: efacc699139e ("mtd: add arch dependency for MTD_BCM47XXSFLASH symbol") from the wireless-drivers-next tree and commit: 0a526341fee0 ("mtd: update description of

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Hi Brian, On Tue, 19 Jul 2016 11:39:13 -0700 Brian Norris wrote: > > I applied a trivial change to this same Kconfig entry: > > Subject: mtd: update description of MTD_BCM47XXSFLASH symbol >

Re: [PATCH 0/4] brcm80211: Misc coverity fixes

On 07/19/2016 12:36 PM, Arend Van Spriel wrote: > On 19-7-2016 20:30, Florian Fainelli wrote: >> On 07/19/2016 11:21 AM, Arend Van Spriel wrote: >>> On 19-7-2016 18:41, Florian Fainelli wrote: On 07/19/2016 02:20 AM, Arend Van Spriel wrote: > + Bob > > On 19-7-2016 1:24, Florian

Re: [PATCH] NFC: null-ify info->ram_patch when firmware is released

Hi Colin, On Fri, Jul 15, 2016 at 02:00:33PM +0100, Colin King wrote: > From: Colin Ian King > > When the firmware is released for info->ram_patch currently > info->otp_patch is being nullified and not info->ram_patch. > This looks like a cut-n-paste coding error. Fix

RE: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote: > Johannes Berg > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving > time > > On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland > wrote: > > On Tue, Jul 19, 2016 at 01:02:13PM +, Machani, Yaniv

[PATCH] NFC: pn533: Avoid a double free in error handling code

'phy' has been allocated with 'devm_kzalloc', so we should not free it using an explicit 'kfree'. It would result in a double free if the allocation of 'in_buf' fails. Signed-off-by: Christophe JAILLET --- drivers/nfc/pn533/usb.c | 9 +++-- 1 file changed, 3

Re: [PATCH 0/4] brcm80211: Misc coverity fixes

On 19-7-2016 20:30, Florian Fainelli wrote: > On 07/19/2016 11:21 AM, Arend Van Spriel wrote: >> On 19-7-2016 18:41, Florian Fainelli wrote: >>> On 07/19/2016 02:20 AM, Arend Van Spriel wrote: + Bob On 19-7-2016 1:24, Florian Fainelli wrote: > Hi, > > This patch series