Fwd: ap + adhoc not working with Mwifiex driver for sd8887

Hi, I've successfully managed to get this driver working in adhoc with olsrd on mlan0 interface, now I'm trying to add a uap0 working at the same time, with all this command: rfkill unblock wlan ip link set uap0 down ip link set mlan0 down iw dev mlan0 set type ibss ip link set mlan0 up iw dev

[PATCH v2] mwifiex: transmit packet stats incorrect.

tx_packets counter is incremented for aggregated packets, when it had already been incremented for the aggregated packet's constituent parts. Removing the extra count. Signed-off-by: Marty Faltesek --- drivers/net/wireless/marvell/mwifiex/txrx.c | 13 +++-- 1 file

[PATCH v2] mwifiex: fw download does not release sdio bus during failure

Signed-off-by: Marty Faltesek --- drivers/net/wireless/marvell/mwifiex/sdio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c index 4c8cae6..d6ef34f 100644 ---

[PATCH v2] mwifiex: bridged packets cause wmm_tx_pending counter to go negative

When a packet is queued from the bridge, wmm_tx_pending is not incremented, but when the packet is dequeued the counter is decremented. Signed-off-by: Marty Faltesek --- drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH 1/4] NFC: trf7970a: Add support for gpio as SS

As Julian suggests, this is handled by the cs-gpios property, so we will drop this patch, but keep the other three active. Thanks for the suggestion. On Mon, Apr 18, 2016 at 8:07 PM, Julian Calaby > wrote: Hi Geoff, On Tue,

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

On Tue, 19 Apr 2016 23:11:58 +0300, Bjørn Mork wrote: > Anyway, 300 674 is for vehicle transponder systems. I.e. electronic > toll collection etc. I don't think it's relevant to the regdb in any > way. Thanks for the response! I'll be sure to ask the CRC why do they reference 300 674 in the

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

Petko Bordjukov writes: > Hello, > > Just to add my input to this thread. I've previously contributed the SRD > ranges > for Bulgaria, hopefully this info will provide pointers for research in other > EU > countries. Since then I've doublechecked the standards situation

brcmfmac_sdio should read its configs from efi vars, where applicable

Over in https://bugs.debian.org/821400, Ben Hutchings makes the reasonable suggestion that where possible, when brcm/brcmfmac43340-sdio.txt (or configuration file for other brcm chipsets) is not available, brcmfmac_sdio should try looking for configuration in the efi variables directly. That

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

Hello, Just to add my input to this thread. I've previously contributed the SRD ranges for Bulgaria, hopefully this info will provide pointers for research in other EU countries. Since then I've doublechecked the standards situation for Wi-Fi with the local communications regulation commission

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

On Tue, Apr 19, 2016 at 06:04:49PM +, Reizer, Eyal wrote: > Thanks! Glad the illustration helped. > I will try it out again as if i recall cotrectly, i did try that l, and it > didnt produce the correct waveform, but perhaps i didnt understand the usage > of .cs_change correctly. > Will

Re: [PATCH] rtl8xxxu: hide unused tables

Kalle Valo writes: > Jes Sorensen writes: > >> Arnd Bergmann writes: >>> The references to some arrays in the rtl8xxxu driver were moved inside >>> of an #ifdef, but the symbols remain outside, resulting in build warnings: >>> >>>

wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

Hi, In Europe ETSI standardized the used for short range devices (SRD) [1] in ETSI EN 300 440-1 [2]. According to this standard generic use equipment is allowed to transmit in the frequency range form 5725 MHz to 5875 MHz with a maximum output power of 25 mW e.i.r.p. This generic allocation

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

On Tue, Apr 19, 2016 at 05:38:02PM +, Reizer, Eyal wrote: > Hi Mark, > > Hope you can see the attached picture that illustrates what need to sent for > sucesfull SPI init. I think what the picture shows is that you just need to send at least one byte at the end of the transfer *after*

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

On Tue, Apr 19, 2016 at 05:21:01PM +, Reizer, Eyal wrote: > The main quirk here is that i need to send extra clocks after the spi init > command while the CS pin is "high" in order to put the wilink chip into SPI > mode. > So just sending an empty transfer wouldnt do the trick here. A

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

On Tue, Apr 19, 2016 at 09:05:45AM +, Reizer, Eyal wrote: > Understood. As this special CS manipulation is unique to wspi (wilink spi) I > think the > best option is to move this gpio allocation into wlcore_spi as a new device > tree entry > used only by this driver. That sounds like it

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

On Mon, Apr 18, 2016 at 05:55:51AM +, Reizer, Eyal wrote: > > I would suggest fixing this using a new API function from the SPI core, if > > we > > don't already have a generic way to do it. > Originally this is what I have done until I was pointed to the generic > cs-gpio mechanism > in

Re: [PATCH v2] ath9k: interpret requested txpower in EIRP domain

Zefir Kurtisi writes: > Tx power limitations at upper layers are interpreted in > the EIRP domain. When the user requests a given maximum > txpower, e.g. with: 'iw phy0 set txpower fixed 1500', > he expects the EIRP to be at or below 15dBm. > > In

Re: [PATCH 2/2] net-ath9k_htc: Replace a variable initialisation by an assignment in ath9k_htc_set_channel()

Julian Calaby writes: > On Sat, Jan 2, 2016 at 5:25 AM, SF Markus Elfring > wrote: >> From: Markus Elfring >> Date: Fri, 1 Jan 2016 19:09:32 +0100 >> >> Replace an explicit initialisation for one local

Re: [PATCH] ath9k: remove duplicate assignment of variable ah

Colin King writes: > From: Colin Ian King > > ah is written twice with the same value, remove one of the > redundant assignments to ah. > > Signed-off-by: Colin Ian King Applied, thanks. -- Kalle Valo -- To

Re: [PATCH] rtl8xxxu: hide unused tables

Jes Sorensen writes: > Arnd Bergmann writes: >> The references to some arrays in the rtl8xxxu driver were moved inside >> of an #ifdef, but the symbols remain outside, resulting in build warnings: >> >> rtl8xxxu/rtl8xxxu.c:1506:33: error:

RE: [PATCH] ath10k: Fix return value for btcoex and peer stats debugfs

Applied, thanks. I removed the line wrapping from "Fixes:" lines. [shafi] thank you Kalle. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: add dynamic tx mode switch config support for qca4019

writes: > From: Raja Mani > > push-pull mode needs certain amount the host driver involvement for > managing queues in the host memory and packet delivery to firmware. > qca4019 wifi firmware has an option to stay in push mode for less > number

Re: [patch v2] ath10k: add some sanity checks

Dan Carpenter writes: > Smatch complains that since "ev->peer_id" comes from skb->data that > means we can't trust it and have to do a bounds check on it to prevent > an array overflow. > > Fixes: 6942726f7f7b ('ath10k: add fast peer_map lookup') > Signed-off-by: Dan

Re: [PATCH] ath10k: fix rx_channel during hw reconfigure

Rajkumar Manoharan writes: > Upon firmware assert, restart work will be triggered so that mac80211 > will reconfigure the driver. An issue is reported that after restart > work, survey dump data do not contain in-use (SURVEY_INFO_IN_USE) info > for operating channel.

Re: [PATCH] rtl8xxxu: hide unused tables

Arnd Bergmann writes: > The references to some arrays in the rtl8xxxu driver were moved inside > of an #ifdef, but the symbols remain outside, resulting in build warnings: > > rtl8xxxu/rtl8xxxu.c:1506:33: error: 'rtl8188ru_radioa_1t_highpa_table' > defined but not used >

RE: [PATCHv2] wlcore: spi: add wl18xx support

> > > > It is also part of the generic spi.h (include/Linux/spi/spi.h), > > > > already part of " struct spi_device" So it seemed redundant adding > > > > another mechanism for implementing the same. > > > > Platform that interact with a wilink need to use it, and platforms > > > > that don't have

[patch] brcmfmac: testing the wrong variable in brcmf_rx_hdrpull()

Smatch complains about this code: drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c:335 brcmf_rx_hdrpull() error: we previously assumed '*ifp' could be null (see line 333) The problem is that we recently changed these from "ifp" to "*ifp" but there was one that we didn't update.

[patch 2/2] mwifiex: fix loop timeout in mwifiex_prog_fw_w_helper()

USB8XXX_FW_MAX_RETRY is 3. We were using a post-op loop "while (retries--) {" but then the lines after that assume the loop exits with retries set to zero. I've fixed this by changing to a pre-op loop. I started with retries set to 4 instead of 3 so that we still go through the loop the same

[patch 1/2] mwifiex: missing error code on allocation failure

We accidentally return success instead of -ENOMEM. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c index 0510861..cdd8f9a 100644 --- a/drivers/net/wireless/marvell/mwifiex/usb.c +++

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

On Tuesday 19 April 2016 09:05:45 Reizer, Eyal wrote: > > > It is also part of the generic spi.h (include/Linux/spi/spi.h), > > > already part of " struct spi_device" So it seemed redundant adding > > > another mechanism for implementing the same. > > > Platform that interact with a wilink need to

Re: [PATCH] ath6kl: Add ability to set debug uart baud rate

Steve deRosier writes: > On Sun, Apr 17, 2016 at 5:07 PM, Julian Calaby > wrote: >> Hi Steve, >> >> This looks like it's using standard serial rates. Does it accept >> non-standard rates? If not, should this be checked before being passed >> to the

Re: [RFC] mac80211: add extap functionality

On 19 April 2016 at 13:02, Johannes Berg wrote: >> > How much of that could be done with nftables btw? > >> I'm not sure if I follow. Do you mean what I've been able to do with >> relayd until now? Without link-local ipv6 routing DHCPv6 is broken >> (could probably

Re: [RFC] mac80211: add extap functionality

> > How much of that could be done with nftables btw? > I'm not sure if I follow. Do you mean what I've been able to do with > relayd until now? Without link-local ipv6 routing DHCPv6 is broken > (could probably addressed with DHCPv6 Relay to a certain degree) and > RS/RA may not work (if it

Re: [RFC] mac80211: add extap functionality

On 19 April 2016 at 11:11, Johannes Berg wrote: > On Mon, 2016-04-18 at 13:23 +0200, Michal Kazior wrote: > >> You can't really implement complete IPv6 support in relayd though. >> Link-local routing is forbidden by the spec explicitly and a patch >> I've cooked up was

Re: [PATCHv3 4/5] mac80211: implement codel on fair queuing flows

On 19 April 2016 at 11:06, Johannes Berg wrote: > On Mon, 2016-04-18 at 14:38 +0200, Michal Kazior wrote: >> On 18 April 2016 at 07:31, Michal Kazior >> wrote: >> > >> > On 17 April 2016 at 00:29, Johannes Berg > > >

Re: [RFC] mac80211: add extap functionality

On Mon, 2016-04-18 at 13:23 +0200, Michal Kazior wrote: > You can't really implement complete IPv6 support in relayd though. > Link-local routing is forbidden by the spec explicitly and a patch > I've cooked up was rejected[1]. > > I guess this leaves either the kernel's wireless stack to take

Re: [Codel] [PATCHv3 2/5] mac80211: implement fair queueing per txq

On Mon, 2016-04-18 at 15:36 +0200, Michal Kazior wrote: > FWIW cfg80211 drivers might become another user of the fq/codel stuff > in the future. > > Arguably I should make include/net/codel.h not be qdisc specific as > it is now (and hence re-usable by mac80211) and submit fq.h to >

Re: [PATCHv3 4/5] mac80211: implement codel on fair queuing flows

On Mon, 2016-04-18 at 14:38 +0200, Michal Kazior wrote: > On 18 April 2016 at 07:31, Michal Kazior > wrote: > > > > On 17 April 2016 at 00:29, Johannes Berg > > wrote: > > > > > > On Thu, 2016-04-14 at 14:18 +0200, Michal Kazior wrote: > > >

RE: [PATCHv2] wlcore: spi: add wl18xx support

Arnd, > > > > > > > > - 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. > > > > - switch to controling the cs pin from the spi driver for achieveing the > > > > above.

Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'

On Mon, 2016-04-18 at 00:10 +0200, Arnd Bergmann wrote: > On Sunday 17 April 2016 14:42:33 Johannes Berg wrote: > > > > > > I was thinking more restrictively of just the stuff that can't even > > be > > built without modifying the sources - like the "#if VERBOSE" thing. > All the DEBUG()

Re: [PATCH v3 06/18] wcn36xx: Add helper macros to cast sta to priv

On Mon, 2016-04-18 at 22:00 -0700, Bjorn Andersson wrote: > From: Pontus Fuchs > > While poking at this I also change two related things. I rename one > variable to make the names consistent. I also move one assignment of > priv_sta to the declaration to save a few lines.