* Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Yeoh Chun-Yeow @ 2016-07-18 16:59 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
> 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 mesh_hwmp_preq_min_interval to your
desired value instead of introducing a new patch specific to your use
case.
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 frame containing a PREQ element. This is to avoid
flooding of broadcast PREQ frame especially when the number of mesh
STA is increased.
---
Chun-Yeow
^ permalink raw reply
* Re: [PATCH v5] wlcore: spi: add wl18xx support
From: Kalle Valo @ 2016-07-18 17:04 UTC (permalink / raw)
To: Reizer, Eyal
Cc: Rob Herring, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-spi@vger.kernel.org
In-Reply-To: <8665E2433BC68541A24DFFCA87B70F5B3615D8AA@DFRE01.ent.ti.com>
"Reizer, Eyal" <eyalr@ti.com> writes:
> 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 init stage.
>
> Signed-off-by: Eyal Reizer <eyalr@ti.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select
> instead for sending the extra init cycle which, achieves the same hardware
> purpose.
> update device tree bindings docucmentation accordingly
> v3->v4: Remove redundant data form binding documentation and fix chip
> select number mismatch in wl1271 example
> v4->v5: Rebase on top of head of wireless-drivers-next
You now sent me two patches with v5 which is just confusing. To make the
life of maintainers easier ALWAYS increase the revision number, no
matter how small the change is.
But the "latter" v5 is corrupted somehow in patchwork:
https://patchwork.kernel.org/patch/9233597/
The "former" v5 again looks ok:
https://patchwork.kernel.org/patch/9222403/
I can't immeaditely see why that happened, but please resend.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Kalle Valo @ 2016-07-18 17:19 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <1468248832-21969-6-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> It is observed that hostapd fails to setup with management frame
> protection mode enabled when using mwifiex. This patch adds
> cfg80211_set_default_mgmt_key handler to resolve the problem.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 8955f8c..bf95cca 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -484,6 +484,18 @@ mwifiex_cfg80211_add_key(struct wiphy *wiphy, struct net_device *netdev,
> }
>
> /*
> + * CFG802.11 operation handler to set default mgmt key.
> + */
> +static int
> +mwifiex_cfg80211_set_default_mgmt_key(struct wiphy *wiphy,
> + struct net_device *netdev,
> + u8 key_index)
> +{
> + wiphy_dbg(wiphy, "set default mgmt key, key index=%d\n", key_index);
> + return 0;
> +}
> +
> +/*
> * This function sends domain information to the firmware.
> *
> * The following information are passed to the firmware -
> @@ -4002,6 +4014,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
> .leave_ibss = mwifiex_cfg80211_leave_ibss,
> .add_key = mwifiex_cfg80211_add_key,
> .del_key = mwifiex_cfg80211_del_key,
> + .set_default_mgmt_key = mwifiex_cfg80211_set_default_mgmt_key,
> .mgmt_tx = mwifiex_cfg80211_mgmt_tx,
> .mgmt_frame_register = mwifiex_cfg80211_mgmt_frame_register,
> .remain_on_channel = mwifiex_cfg80211_remain_on_channel,
Is it correct to ignore the key index? I see that brcmfmac ignores it as
well but I want to still confirm this.
Does this mean that with this patcfh mwifiex properly supports MFP?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 6/9] mwifiex: process rxba_sync event
From: Kalle Valo @ 2016-07-18 17:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Xinming Hu
In-Reply-To: <1468248832-21969-7-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> From: Xinming Hu <huxm@marvell.com>
>
> Firmware may filter and drop packets under certain condition, for
> example, ARP SA=DA packet. this event will be used to synchronize
> the Rx Block Acknowledgment (BA) window bitmap and to fill any holes
> in driver side.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
[...]
> --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> @@ -78,8 +78,15 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
> */
> static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
> {
> - int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
>
> + int ret;
> +
> + if (payload == (void *)MWIFIEX_RX_PKT_DROPPED_IN_FW) {
> + mwifiex_dbg(priv->adapter, INFO, "info: fw drop data\n");
> + return 0;
> + }
[...]
> + mwifiex_dbg(priv->adapter, ERROR,
> + "drop packet,seq=%d\n",
> + seq_num);
> +
> + ret = mwifiex_11n_rx_reorder_pkt
> + (priv, seq_num, tlv_rxba->tid,
> + tlv_rxba->mac, 0,
> + (void *)MWIFIEX_RX_PKT_DROPPED_IN_FW);
[...]
> +/* Indicate packet has been dropped in FW */
> +#define MWIFIEX_RX_PKT_DROPPED_IN_FW 0xffffffff
That pointer magic is rather ugly, why not use a proper boolean?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for wl8
From: Kalle Valo @ 2016-07-18 17:42 UTC (permalink / raw)
To: Yaniv Machani
Cc: linux-kernel, Maital Hahn, Eliad Peller, Guy Mishol,
Johannes Berg, Arik Nemtsov, linux-wireless, netdev
In-Reply-To: <20160628104305.4533-1-yanivma@ti.com>
Yaniv Machani <yanivma@ti.com> writes:
> From: Maital Hahn <maitalm@ti.com>
>
> 1. Added support for interface and role of mesh type.
> 2. Enabled enable/start of mesh-point role,
> and opening and closing a connection with a mesh peer.
> 3. Added multirole combination of mesh and ap
> under the same limits of dual ap mode.
> 4. Add support for 'sta_rc_update' opcode for mesh IF.
> The 'sta_rc_update' opcode is being used in mesh_plink.c.
> Add support in wlcore to handle this opcode correctly for mesh
> (as opposed to current implementation that handles STA only).
> 5. Bumped the firmware version to support new Mesh functionality
>
> Signed-off-by: Maital Hahn <maitalm@ti.com>
> Signed-off-by: Yaniv Machani <yanivma@ti.com>
Does this depend on any mac80211 patches? To not break anything I can't
apply this until all the dependencies are in my tree.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for wl8
From: Machani, Yaniv @ 2016-07-18 18:27 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-kernel@vger.kernel.org, Hahn, Maital, Eliad Peller,
Mishol, Guy, Johannes Berg, Arik Nemtsov,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <87eg6qx2ou.fsf@kamboji.qca.qualcomm.com>
On Mon, Jul 18, 2016 at 20:42:57, Kalle Valo wrote:
> Guy; Johannes Berg; Arik Nemtsov; linux-wireless@vger.kernel.org;
> netdev@vger.kernel.org
> Subject: Re: [PATCH] wlcore/wl18xx: mesh: added initial mesh support
> for wl8
>
> Yaniv Machani <yanivma@ti.com> writes:
>
> > From: Maital Hahn <maitalm@ti.com>
> >
> > 1. Added support for interface and role of mesh type.
> > 2. Enabled enable/start of mesh-point role,
> > and opening and closing a connection with a mesh peer.
> > 3. Added multirole combination of mesh and ap
> > under the same limits of dual ap mode.
> > 4. Add support for 'sta_rc_update' opcode for mesh IF.
> > The 'sta_rc_update' opcode is being used in mesh_plink.c.
> > Add support in wlcore to handle this opcode correctly for mesh (as
> > opposed to current implementation that handles STA only).
> > 5. Bumped the firmware version to support new Mesh functionality
> >
> > Signed-off-by: Maital Hahn <maitalm@ti.com>
> > Signed-off-by: Yaniv Machani <yanivma@ti.com>
>
> Does this depend on any mac80211 patches? To not break anything I
> can't apply this until all the dependencies are in my tree.
>
Hi Kalle,
No, there are no dependencies for this patch.
The other set of patches are bug fixes and improvements, shouldn't block the merge.
Thanks,
Yaniv
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Johannes Berg @ 2016-07-18 18:52 UTC (permalink / raw)
To: Bob Copeland, Yaniv Machani
Cc: linux-kernel, Meirav Kama, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20160718133824.GA11996@localhost>
On Mon, 2016-07-18 at 09:38 -0400, Bob Copeland wrote:
> On Wed, Jul 13, 2016 at 02:45:40PM +0300, Yaniv Machani wrote:
> > The HT capab info field inside the HT capab IE of the mesh beacon
> > is incorrect (in the case of 20MHz channel width).
> > To fix this driver will check configuration from cfg and
> > will build it accordingly.
>
> > + /* determine capability flags */
> > + cap = sband->ht_cap.cap;
> > +
> > + /* if channel width is 20MHz - configure HT capab
> > accordingly*/
> > + if (sdata->vif.bss_conf.chandef.width ==
> > NL80211_CHAN_WIDTH_20) {
> > + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> > + cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
> > + }
>
> Is it required that HT capability match the HT operation in this
> case?
>
Is there ever a case that HT *capability* should be restricted
artificially like that? I can't remember any cases - we do something
like that to work around broken APs in some cases, but here?
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Johannes Berg @ 2016-07-18 18:56 UTC (permalink / raw)
To: Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <1468849985-6881-1-git-send-email-pkushwah@qti.qualcomm.com>
On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
> Driver may allow support for different beacon interval on virtual
> interfaces.
> Allow if such support is advertised by driver. This adds new
> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations,
perhaps it would make sense to also put this flag there?
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Ben Greear @ 2016-07-18 19:04 UTC (permalink / raw)
To: Johannes Berg, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <1468868209.2944.1.camel@sipsolutions.net>
On 07/18/2016 11:56 AM, Johannes Berg wrote:
> On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
>> Driver may allow support for different beacon interval on virtual
>> interfaces.
>> Allow if such support is advertised by driver. This adds new
>> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
>
> We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations,
> perhaps it would make sense to also put this flag there?
I was under impression that ath9k had supported this for years,
but I guess I haven't tested it lately....
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Arend Van Spriel @ 2016-07-18 19:13 UTC (permalink / raw)
To: Johannes Berg, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <1468868209.2944.1.camel@sipsolutions.net>
On 18-7-2016 20:56, Johannes Berg wrote:
> On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
>> Driver may allow support for different beacon interval on virtual
>> interfaces.
>> Allow if such support is advertised by driver. This adds new
>> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
>
> We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations,
> perhaps it would make sense to also put this flag there?
Hi Johannes,
Was looking at the same thing. The description of that flag was a bit
unclear to me.
"""
* @beacon_int_infra_match: In this combination, the beacon intervals
* between infrastructure and AP types must match. This is required
* only in special cases.
"""
It is not explicitly stated but it implies the STA vif is connected, right.
Probably going off-topic here, but I am also wondering about the
use-case of the above patch. I have been looking at M-BSS. Toward
user-space these are AP interfaces, but like described in hostapd.conf
example a number of AP configuration items are required to be equal. Now
we also have chipsets with two 802.11 cores and on each an AP could be
setup with independent beacon interval. So to make the distinction would
it make sense to introduce MBSS_AP iftype? Or does AP_VLAN cover the
MBSS use-case?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Johannes Berg @ 2016-07-18 19:14 UTC (permalink / raw)
To: Ben Greear, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <578D2846.5060600@candelatech.com>
On Mon, 2016-07-18 at 12:04 -0700, Ben Greear wrote:
>
> On 07/18/2016 11:56 AM, Johannes Berg wrote:
> > On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
> > > Driver may allow support for different beacon interval on virtual
> > > interfaces.
> > > Allow if such support is advertised by driver. This adds new
> > > ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
> >
> > We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface
> > combinations,
> > perhaps it would make sense to also put this flag there?
>
> I was under impression that ath9k had supported this for years,
> but I guess I haven't tested it lately....
>
It may very well have, but if userspace can't rely on it because other
drivers don't then it's pretty pointless.
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Johannes Berg @ 2016-07-18 19:15 UTC (permalink / raw)
To: Arend Van Spriel, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <9831c426-ae04-a85f-9173-bcea30c489d7@broadcom.com>
On Mon, 2016-07-18 at 21:13 +0200, Arend Van Spriel wrote:
>
> On 18-7-2016 20:56, Johannes Berg wrote:
> > On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
> > > Driver may allow support for different beacon interval on virtual
> > > interfaces.
> > > Allow if such support is advertised by driver. This adds new
> > > ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
> >
> > We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface
> > combinations,
> > perhaps it would make sense to also put this flag there?
>
> Hi Johannes,
>
> Was looking at the same thing. The description of that flag was a bit
> unclear to me.
>
> """
> * @beacon_int_infra_match: In this combination, the beacon intervals
> * between infrastructure and AP types must match. This is
> required
> * only in special cases.
> """
>
> It is not explicitly stated but it implies the STA vif is connected,
> right.
Yes.
Forget this flag. I don't think any driver sets it - it was a hack for
iwldvm. I also don't think any userspace cares about it, and it likely
never really worked. What if the STA vif reconnects anyway?
I was merely pointing this out wrt. the grouping and where to put
something new.
> Probably going off-topic here, but I am also wondering about the
> use-case of the above patch. I have been looking at M-BSS. Toward
> user-space these are AP interfaces, but like described in
> hostapd.conf
> example a number of AP configuration items are required to be equal.
> Now
> we also have chipsets with two 802.11 cores and on each an AP could
> be
> setup with independent beacon interval. So to make the distinction
> would
> it make sense to introduce MBSS_AP iftype? Or does AP_VLAN cover the
> MBSS use-case?
>
I don't think AP_VLAN does, but isn't a mesh portal simply a mesh point
interface and an AP interface?
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Arend Van Spriel @ 2016-07-18 19:21 UTC (permalink / raw)
To: Johannes Berg, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <1468869356.2944.5.camel@sipsolutions.net>
On 18-7-2016 21:15, Johannes Berg wrote:
> On Mon, 2016-07-18 at 21:13 +0200, Arend Van Spriel wrote:
>>
>> On 18-7-2016 20:56, Johannes Berg wrote:
>>> On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
>>>> Driver may allow support for different beacon interval on virtual
>>>> interfaces.
>>>> Allow if such support is advertised by driver. This adds new
>>>> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
>>>
>>> We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface
>>> combinations,
>>> perhaps it would make sense to also put this flag there?
>>
>> Hi Johannes,
>>
>> Was looking at the same thing. The description of that flag was a bit
>> unclear to me.
>>
>> """
>> * @beacon_int_infra_match: In this combination, the beacon intervals
>> * between infrastructure and AP types must match. This is
>> required
>> * only in special cases.
>> """
>>
>> It is not explicitly stated but it implies the STA vif is connected,
>> right.
>
> Yes.
>
> Forget this flag. I don't think any driver sets it - it was a hack for
> iwldvm. I also don't think any userspace cares about it, and it likely
> never really worked. What if the STA vif reconnects anyway?
>
> I was merely pointing this out wrt. the grouping and where to put
> something new.
>
>> Probably going off-topic here, but I am also wondering about the
>> use-case of the above patch. I have been looking at M-BSS. Toward
>> user-space these are AP interfaces, but like described in
>> hostapd.conf
>> example a number of AP configuration items are required to be equal.
>> Now
>> we also have chipsets with two 802.11 cores and on each an AP could
>> be
>> setup with independent beacon interval. So to make the distinction
>> would
>> it make sense to introduce MBSS_AP iftype? Or does AP_VLAN cover the
>> MBSS use-case?
>>
>
> I don't think AP_VLAN does, but isn't a mesh portal simply a mesh point
> interface and an AP interface?
Whoops. Should not use abbreviations like that. I meant the
Multiple-BSSID functionality (from hostapd):
##### Multiple BSSID support
##################################################
#
# Above configuration is using the default interface (wlan#, or
multi-SSID VLAN
# interfaces). Other BSSIDs can be added by using separator 'bss' with
# default interface name to be allocated for the data packets of the new
BSS.
#
# hostapd will generate BSSID mask based on the BSSIDs that are
# configured. hostapd will verify that dev_addr & MASK == dev_addr. If
this is
# not the case, the MAC address of the radio must be changed before starting
# hostapd (ifconfig wlan0 hw ether <MAC addr>). If a BSSID is configured for
# every secondary BSS, this limitation is not applied at hostapd and other
# masks may be used if the driver supports them (e.g., swap the locally
# administered bit)
#
# BSSIDs are assigned in order to each BSS, unless an explicit BSSID is
# specified using the 'bssid' parameter.
# If an explicit BSSID is specified, it must be chosen such that it:
# - results in a valid MASK that covers it and the dev_addr
# - is not the same as the MAC address of the radio
# - is not the same as any other explicitly specified BSSID
#
# Alternatively, the 'use_driver_iface_addr' parameter can be used to
request
# hostapd to use the driver auto-generated interface address (e.g., to
use the
# exact MAC addresses allocated to the device).
#
# Not all drivers support multiple BSSes. The exact mechanism for
determining
# the driver capabilities is driver specific. With the current (i.e., a
recent
# kernel) drivers using nl80211, this information can be checked with
"iw list"
# (search for "valid interface combinations").
#
# Please note that hostapd uses some of the values configured for the
first BSS
# as the defaults for the following BSSes. However, it is recommended
that all
# BSSes include explicit configuration of all relevant configuration items.
#
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Johannes Berg @ 2016-07-18 19:22 UTC (permalink / raw)
To: Arend Van Spriel, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <fd7fc930-67ab-89bf-5909-0851057e0c84@broadcom.com>
> Whoops. Should not use abbreviations like that. I meant the
> Multiple-BSSID functionality (from hostapd):
Ah, heh. Yes, I think this is exactly the use case they have in mind.
Each of the multiple BSSes is represented by its own AP type virtual
interface.
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Ben Greear @ 2016-07-18 19:31 UTC (permalink / raw)
To: Johannes Berg, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <1468869244.2944.3.camel@sipsolutions.net>
On 07/18/2016 12:14 PM, Johannes Berg wrote:
> On Mon, 2016-07-18 at 12:04 -0700, Ben Greear wrote:
>>
>> On 07/18/2016 11:56 AM, Johannes Berg wrote:
>>> On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
>>>> Driver may allow support for different beacon interval on virtual
>>>> interfaces.
>>>> Allow if such support is advertised by driver. This adds new
>>>> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
>>>
>>> We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface
>>> combinations,
>>> perhaps it would make sense to also put this flag there?
>>
>> I was under impression that ath9k had supported this for years,
>> but I guess I haven't tested it lately....
>>
>
> It may very well have, but if userspace can't rely on it because other
> drivers don't then it's pretty pointless.
A flag would be nice, but for backwards compat, it could be a negative
flag. But, if mac80211 has to be patched to make this work, then maybe
the ath9k feature has been disabled/broken for some time and wouldn't matter
anyway.
Also, ath9k had some restrictions about having the timers be certain
multiples of each other so the hardware could properly service beacons
for multiple vdevs. If chip-specific restrictions remain, then it may be almost impossible
to communicate this properly to the hostapd/userspace. At best, the driver
could just fail to start the vdev in case of mismatch?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [v4] mwifiex: Reduce endian conversion for REG Host Commands
From: Kalle Valo @ 2016-07-18 19:33 UTC (permalink / raw)
To: Prasun Maiti
Cc: Amitkumar Karwar, Nishant Sarmukadam, Linux Wireless, Linux Next,
Linux Kernel
In-Reply-To: <1467022402-23990-1-git-send-email-prasunmaiti87@gmail.com>
Prasun Maiti <prasunmaiti87@gmail.com> wrote:
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are
> saved to driver. So, "leX_to_cpu" conversion is required too many
> times afterwards in driver.
>
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
>
> Signed-off-by: Prasun Maiti <prasunmaiti87@gmail.com>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
8cfb86003dbf mwifiex: Reduce endian conversion for REG Host Commands
--
Sent by pwcli
https://patchwork.kernel.org/patch/9200265/
^ permalink raw reply
* Re: wlcore/wl18xx: mesh: added initial mesh support for wl8
From: Kalle Valo @ 2016-07-18 19:33 UTC (permalink / raw)
To: Machani, Yaniv
Cc: linux-kernel, Maital Hahn, Yaniv Machani, Eliad Peller,
Guy Mishol, Johannes Berg, Arik Nemtsov, linux-wireless, netdev
In-Reply-To: <20160628104305.4533-1-yanivma@ti.com>
"Machani, Yaniv" <yanivma@ti.com> wrote:
> From: Maital Hahn <maitalm@ti.com>
>
> 1. Added support for interface and role of mesh type.
> 2. Enabled enable/start of mesh-point role,
> and opening and closing a connection with a mesh peer.
> 3. Added multirole combination of mesh and ap
> under the same limits of dual ap mode.
> 4. Add support for 'sta_rc_update' opcode for mesh IF.
> The 'sta_rc_update' opcode is being used in mesh_plink.c.
> Add support in wlcore to handle this opcode correctly for mesh
> (as opposed to current implementation that handles STA only).
> 5. Bumped the firmware version to support new Mesh functionality
>
> Signed-off-by: Maital Hahn <maitalm@ti.com>
> Signed-off-by: Yaniv Machani <yanivma@ti.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
c0174ee28003 wlcore/wl18xx: mesh: added initial mesh support for wl8
--
Sent by pwcli
https://patchwork.kernel.org/patch/9202707/
^ permalink raw reply
* Re: brcmfmac: respect hidden_ssid for AP interfaces
From: Kalle Valo @ 2016-07-18 19:34 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rafał Miłecki, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <1467800585-10678-1-git-send-email-zajec5@gmail.com>
Rafał Miłecki wrote:
> This was succesfully tested with 4366B1. A small workaround is needed
> for the main interface otherwise it would stuck at the hidden state.
>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
c940de10d45e brcmfmac: respect hidden_ssid for AP interfaces
--
Sent by pwcli
https://patchwork.kernel.org/patch/9216049/
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
From: Arend Van Spriel @ 2016-07-18 19:35 UTC (permalink / raw)
To: Johannes Berg, Purushottam Kushwaha
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath
In-Reply-To: <fd7fc930-67ab-89bf-5909-0851057e0c84@broadcom.com>
On 18-7-2016 21:21, Arend Van Spriel wrote:
> On 18-7-2016 21:15, Johannes Berg wrote:
>> On Mon, 2016-07-18 at 21:13 +0200, Arend Van Spriel wrote:
>>>
>>> On 18-7-2016 20:56, Johannes Berg wrote:
>>>> On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote:
>>>>> Driver may allow support for different beacon interval on virtual
>>>>> interfaces.
>>>>> Allow if such support is advertised by driver. This adds new
>>>>> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
>>>>
>>>> We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface
>>>> combinations,
>>>> perhaps it would make sense to also put this flag there?
>>>
>>> Hi Johannes,
>>>
>>> Was looking at the same thing. The description of that flag was a bit
>>> unclear to me.
>>>
>>> """
>>> * @beacon_int_infra_match: In this combination, the beacon intervals
>>> * between infrastructure and AP types must match. This is
>>> required
>>> * only in special cases.
>>> """
>>>
>>> It is not explicitly stated but it implies the STA vif is connected,
>>> right.
>>
>> Yes.
>>
>> Forget this flag. I don't think any driver sets it - it was a hack for
>> iwldvm. I also don't think any userspace cares about it, and it likely
>> never really worked. What if the STA vif reconnects anyway?
Uhm. My memory tells me differently and LXR also [1] :-p
Regards,
Arend
[1]
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c#L6182
^ permalink raw reply
* Re: [1/2, v4] wlcore/wl18xx: Add functionality to accept TX rate per link
From: Kalle Valo @ 2016-07-18 19:37 UTC (permalink / raw)
To: Maxim Altshul
Cc: linux-kernel, Maxim Altshul, Eliad Peller, Guy Mishol,
Machani, Yaniv, Arik Nemtsov, linux-wireless
In-Reply-To: <20160711142251.30443-1-maxim.altshul@ti.com>
Maxim Altshul <maxim.altshul@ti.com> wrote:
> FW will provide a TX rate per link for each FW status,
> and wlcore will be able to store the information for
> the use of the mesh hwmp module.
>
> This is used mainly in mesh.
> Rates are reported when a mesh interface is up.
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Thanks, 2 patches applied to wireless-drivers-next.git:
88f07e70d1be wlcore/wl18xx: Add functionality to accept TX rate per link
5634723758a1 wlcore: Add support for get_expected_throughput opcode
--
Sent by pwcli
https://patchwork.kernel.org/patch/9223705/
^ permalink raw reply
* Re: [FIX,4.6+] bcma: add PCI ID for Foxconn's BCM43142 device
From: Kalle Valo @ 2016-07-18 19:38 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Igor Mammedov, Rafał Miłecki, Stable,
open list:BROADCOM SPECIFIC AMBA DRIVER (BCMA), open list
In-Reply-To: <1468270896-2988-1-git-send-email-zajec5@gmail.com>
Rafał Miłecki wrote:
> After discovering there are 2 very different 14e4:4365 PCI devices we
> made ID tables less generic. Back then we believed there are only 2 such
> devices:
> 1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
> 2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset
>
> >From the recent report it appears there is also 14e4:4365 105b:e092
> which should be claimed by bcma. Add back support for it.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=121881
> Fixes: 515b399c9a20 ("bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142")
> Reported-by: Igor Mammedov <imammedo@redhat.com>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> Cc: Stable <stable@vger.kernel.org> [4.6+]
> Tested-by: Igor Mammedov <imammedo@redhat.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
1bea0512c339 bcma: add PCI ID for Foxconn's BCM43142 device
--
Sent by pwcli
https://patchwork.kernel.org/patch/9224231/
^ permalink raw reply
* Re: [-next] libertas: fix non static symbol warning
From: Kalle Valo @ 2016-07-18 19:39 UTC (permalink / raw)
To: weiyj_lk
Cc: sudip, Andreas Kemnade, Wei Yongjun, libertas-dev, linux-wireless
In-Reply-To: <1468323139-1756-1-git-send-email-weiyj_lk@163.com>
weiyj_lk@163.com wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fixes the following sparse warning:
>
> drivers/net/wireless/marvell/libertas/cfg.c:2047:5: warning:
> symbol 'lbs_set_power_mgmt' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Thanks, 1 patch applied to wireless-drivers-next.git:
83d58d53e062 libertas: fix non static symbol warning
--
Sent by pwcli
https://patchwork.kernel.org/patch/9225147/
^ permalink raw reply
* Re: [-next] mwifiex: fix possible memory leak in mwifiex_cfg80211_start_ap()
From: Kalle Valo @ 2016-07-18 19:39 UTC (permalink / raw)
To: weiyj_lk
Cc: Amitkumar Karwar, Nishant Sarmukadam, Wei Yongjun, linux-wireless
In-Reply-To: <1468323798-6075-1-git-send-email-weiyj_lk@163.com>
weiyj_lk@163.com wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> memory is malloced in mwifiex_cfg80211_start_ap() and should be
> freed before leaving from the error handling cases, otherwise it
> will cause memory leak.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Thanks, 1 patch applied to wireless-drivers-next.git:
4028a514eaa6 mwifiex: fix possible memory leak in mwifiex_cfg80211_start_ap()
--
Sent by pwcli
https://patchwork.kernel.org/patch/9225159/
^ permalink raw reply
* Re: brcmfmac: restore stopping netdev queue when bus clogs up
From: Kalle Valo @ 2016-07-18 19:41 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1468577794-12606-1-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> When the host-interface bus has hard time handling transmit packets
> it informs higher layer about this and it would stop the netdev
> queue when needed. However, since commit 9cd18359d31e ("brcmfmac:
> Make FWS queueing configurable.") this was broken. With this patch
> the behaviour is restored.
>
> Cc: stable@vger.kernel.org # v4.5, v4.6, v4.7
> Fixes: 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.")
> Tested-by: Per Förlin <per.forlin@gmail.com>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
82bc9ab6a8f5 brcmfmac: restore stopping netdev queue when bus clogs up
--
Sent by pwcli
https://patchwork.kernel.org/patch/9231603/
^ permalink raw reply
* Re: brcmfmac: defer DPC processing during probe
From: Kalle Valo @ 2016-07-18 19:42 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1468579153-14292-1-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> The sdio dpc starts processing when in SDIOD_STATE_DATA. This state was
> entered right after firmware download. This patch moves that transition
> just before enabling sdio interrupt handling thus avoiding watchdog
> expiry which would put the bus to sleep while probing.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
fd3ed33f51c2 brcmfmac: defer DPC processing during probe
--
Sent by pwcli
https://patchwork.kernel.org/patch/9231665/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox