Re: [PATCH 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

On Monday 27 February 2017 08:08 PM, Johannes Berg wrote: > On Mon, 2017-02-20 at 16:09 +0530, Vasanthakumar Thiagarajan wrote: >> DFS requirement for ETSI domain (section 4.7.1.4 in >> ETSI EN 301 893 V1.8.1) is the only one which explicitly >> states that once DFS channel is marked as available

Re: [RFC 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain

On Thursday 26 January 2017 03:11 PM, Johannes Berg wrote: > On Wed, 2017-01-25 at 17:01 +0530, Vasanthakumar Thiagarajan wrote: >> Sharing DFS channel state across multiple wiphys (radios) could >> be useful with multiple radios on the system. When one radio >> completes CAC and marks the channel

Re: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

On Thursday 26 January 2017 03:06 PM, Johannes Berg wrote: > >> +static bool cfg80211_off_channel_oper_allowed(struct wireless_dev >> *wdev) >> +{ >> +if (!cfg80211_beaconing_iface_active(wdev)) >> +return true; >> + >> +if (!(wdev->chandef.chan->flags & IEEE80211_CHAN_RADAR))

Re: [RFC 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

On Thursday 26 January 2017 03:04 PM, Johannes Berg wrote: > >> +/* Should we apply the grace period during beaconing >> interface >> + * shutdown also? >> + */ >> +cfg80211_sched_dfs_chan_update(rdev); > > It might make some sense, say if hostapd

Re: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

On Wednesday 25 January 2017 11:50 PM, Jean-Pierre Tosoni wrote: >> -Message d'origine- >> De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- >> ow...@vger.kernel.org] De la part de Vasanthakumar Thiagarajan >> Envoyé : mercredi 25 janvier 2017 12:31 >> À :

Re: ath10k mesh error 80MHz channel

On Wednesday 21 December 2016 08:51 PM, Matteo Grandi wrote: > Hi all again, just an update to the previous message: > > looking at iw list I found this situation: > > Frequencies: > * 5180 MHz [36] (20.0 dBm) > * 5200 MHz [40] (20.0 dBm) > * 5220

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On Monday 19 December 2016 05:15 PM, Kalle Valo wrote: > "Thiagarajan, Vasanthakumar" <vthia...@qti.qualcomm.com> writes: > >> On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote: >>> >>>>> I agree. Dynamic switch part is buggy, we ca

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

On Thursday 15 December 2016 03:08 PM, Johannes Berg wrote: > >> This rx path only checks if the driver has advertised >> it's support of 802.11 header encap/decap offload for >> data frames. > > I'm not even sure I see the point in that? Other than that (and the > various other offload

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote: > >>> I agree. Dynamic switch part is buggy, we can start with not >>> allowing interfaces resulting in dynamic switch. >> >> Does this mean that when bringing up multiple interfaces, users would >> need to figure out the 'magic' order

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote: > >> There is a field, no_80211_encap, added to ieee80211_tx_info:control >> to mark if the 802.11 encapsulation is offloaded to driver. >> There is also a new callback for tx completion status indication >> to handle data frames using

Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote: > >> Drivers advertising this capability should also implement other >> functionalities which deal with 802.11 frame format like below > >> - ADDBA/DELBA offload > > This shouldn't be necessary. Ok. Since driver/hw needs to

Re: [RFC 0/3] Add new data path for ethernet frame format

On Thursday 15 December 2016 02:38 PM, Johannes Berg wrote: > On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote: >> This patch set adds a new data path to offload 802.11 header >> encap/decap to driver or hardware. Drivers having support >> for ieee80211 header encap/decap and

Re: [PATCH] ath10k: Fix rfc1042 header retrieval in QCA4019 with eth decap mode

On Monday 12 September 2016 09:01 PM, Valo, Kalle wrote: > Vasanthakumar Thiagarajan writes: > >> Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future) >> rx_hdr_status is not padded to align in 4-byte boundary. Define a >> new hw_params field to handle

Re: [PATCH 4/4] ath10k: Enable support for QCA9984

it available. You may need to create one, please refer https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports for information to create your own backports tarball. Vasanth > > On Wed, May 11, 2016 at 12:43 PM, Thiagarajan, Vasanthakumar > <vthia...@qti.qua

Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction

On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote: > On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan > wrote: >> There are slight differences in Rx hw descriptor information >> among different chips. So far driver does not use those new >> information for any

Re: [PATCH 1/2] ath10k: Define an enum to enable cycle counter wraparound logic

>> --- a/drivers/net/wireless/ath/ath10k/core.c >> +++ b/drivers/net/wireless/ath/ath10k/core.c >> @@ -55,7 +55,7 @@ static const struct ath10k_hw_params >> ath10k_hw_params_list[] = { >> .name = "qca988x hw2.0", >> .patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR, >>

Re: [PATCH 4/4] ath10k: Enable support for QCA9984

On Wednesday 11 May 2016 12:23 PM, Archisman Maitra wrote: > Hi, > > Thank you for providing me the binaries. > > I have started working on the mac80211 driver and have some questions:- > > a) I am working with OpenWRT framework, which uses mac80211 driver dated > 1-10-2016. I have noticed that

Re: [PATCH 4/4] ath10k: Enable support for QCA9984

On Monday 09 May 2016 03:16 PM, Archisman Maitra wrote: > > > The firmware crashes on applying this patch.. On examining the kernel OOPs, > I have found out that that ath10k_bmi_execute in > drivers/net/wireless/ath/ath10k/core.c when called goes in a loop until > timeout occurs after which it

Re: [PATCH] mac80211: Allow probe response frame rx to user space in AP mode

On Wednesday 09 March 2016 02:59 PM, Johannes Berg wrote: > On Wed, 2016-03-09 at 05:10 +0000, Thiagarajan, Vasanthakumar wrote: > >> When an user space wants to have control over the duration of off- >> channel (single channel) scan it could use remain-on-channel &g

Re: [PATCH] mac80211: Allow probe response frame rx to user space in AP mode

On Tuesday 08 March 2016 10:25 PM, Johannes Berg wrote: > On Mon, 2016-03-07 at 12:42 +0530, Vasanthakumar Thiagarajan wrote: >> Especially during off-channel scan user space might be interested >> in probe reponse frames along with beacon to build a list >> of preferred channel and bssid which