* Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Johannes Berg @ 2016-08-11 13:22 UTC (permalink / raw)
To: Bob Copeland, Yaniv Machani
Cc: linux-kernel, Maital Hahn, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20160719123648.GC11996@localhost>
On Tue, 2016-07-19 at 08:36 -0400, Bob Copeland wrote:
> 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
> > dot11MeshHWMPpreqMinInterval, which usually set to few seconds.
> >
> > This implementation has an impact in cases where we would like to
> > resolve the path quickly.
> > A clear example is when a peer was disconnected from us,
> > while he acted as a hop to our destination.
> > Although the path table will be cleared, the next PREQ frame will
> > be sent only after reaching the MinInterval.
> > This will cause unwanted delay, possibly of few seconds until the
> > traffic will resume.
> >
> > if (!(mpath->flags & MESH_PATH_RESOLVING))
> > - mesh_queue_preq(mpath, PREQ_Q_F_START);
> > + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
>
> What about something like this here instead:
>
> if (!(mpath->flags & MESH_PATH_RESOLVING)) {
> /* force next preq to be sent without delay */
> ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
> mesh_queue_preq(mpath, PREQ_Q_F_START);
> }
>
Yaniv, did you disagree with this for some strong reason, or were you
going to resend?
Having a smaller patch seems nicer too.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-11 13:14 UTC (permalink / raw)
To: miaoqing
Cc: Pan, Miaoqing, Stephan Mueller, Herbert Xu, Matt Mackall,
Valo, Kalle, linux-wireless, ath9k-devel, linux-crypto,
Sepehrdad, Pouyan
In-Reply-To: <14a3879458f3bfc36068c2e8294ca448@codeaurora.org>
On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoqing@codeaurora.org wrote:
> On 2016-08-10 21:24, Jason Cooper wrote:
> >The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> >the appropriate place for it. It's not a devicetree blob, mac address,
> >or pci config space. Which are things we feed in once for the heck of
> >it. This is a *continuous* source or questionable quality.
> >
> >I'm seriously considering putting this and timeriomem-rng into a
> >subdirectory under hw_random/, maybe environ/. Anything in there gets
> >quality=0 for default, and *doesn't* contribute to /dev/hwrng.
> >
> >Regardless which path we take, I think we should include 'adc' in the
> >name. I've heard countless times about "Atheros cards come with an rng
> >on board". :-/
>
> If I understand correctly, you want to bind the ADC source to
> /dev/hwrng, and then change rng-tools to set the entropy to zero in
> the ioctl call ? There are two major problems with that approach,
Nope. I want to leverage the hwrng framework to facilitate feeding the
*kernel* entropy pools like all the other hwrngs do currently. The
difference for *environmental* sources is that when userspace read()s
from /dev/hwrng, they will *not* contribute.
If the environmental sources are the only sources, then no /dev/hwrng
should appear.
> 1) We already tried once before to bind our solution to /dev/hwrng,
> and got so much complaints. The conclusion was that maybe we know that
> the output of /dev/hwrng does not have perfect entropy, but a normal
> user does not know and will misuse it. You mentioned in
> https://www.kernel.org/doc/Documentation/hw_random.txt we have
>
> "This data is NOT CHECKED by any
> fitness tests, and could potentially be bogus (if the
> hardware is faulty or has been tampered with). Data is only
> output if the hardware "has-data" flag is set, but nevertheless
> a security-conscious person would run fitness tests on the
> data before assuming it is truly random."
>
> But this is not enough to convince upstream to switch to /dev/hwrng.
> I think the concern of users misusing the solution is a very valid
> concern.
Agreed.
> 2) If we set the entropy to zero in rng-tools, we cannot tolerate the
> load. Rng-tools is not a timer-based solution. Similar to our
> solution, it is based on
> /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
> the entropy counter, rng-tools keep writing into the pool, and both
> rng-tools and WiFi chip will be overloaded.
That's why I propose a change to the hwrng framework to permit noise
sources while not wiring them up to feed /dev/hwrng. timeriomem-rng
should have the same problem ath9k-rng does.
Basically, if it wasn't designed to be an rng, it shouldn't be wired up
to /dev/hwrng.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-08-11 13:08 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath, djindal
In-Reply-To: <1470916154-18821-1-git-send-email-pkushwah@qti.qualcomm.com>
> +static bool diff_beacon_interval_supported(struct wiphy *wiphy, u16
> types,
> + u32 beacon_int)
> +{
> + const struct ieee80211_iface_combination *c;
> + u16 all_types;
> + int i, j;
> +
> + for (i = 0; i < wiphy->n_iface_combinations; i++) {
> + c = &wiphy->iface_combinations[i];
> +
> + if (!c->diff_beacon_int_gcd ||
> + (beacon_int % c->diff_beacon_int_gcd))
> + continue;
> +
> + all_types = 0;
> + for (j = 0; j < c->n_limits; j++)
> + all_types |= c->limits[j].types;
> +
> + if (all_types & types)
> + return true;
> + }
> +
> + return false;
> +}
This seems odd. Shouldn't it use cfg80211_iter_combinations()? Might
need some additional helper to understand which interface types are
used right now - seems we mostly moved that to mac80211, but for this
case it should probably stay in cfg80211? Or should it?
johannes
^ permalink raw reply
* Re: [PATCH v3] mac80211: mesh: set tx_info->hw_queue to the correct queue upon packet forwarding
From: Johannes Berg @ 2016-08-11 13:04 UTC (permalink / raw)
To: Yaniv Machani, linux-kernel
Cc: Meirav Kama, David S. Miller, linux-wireless, netdev
In-Reply-To: <20160808070610.20563-1-yanivma@ti.com>
On Mon, 2016-08-08 at 10:06 +0300, Yaniv Machani wrote:
> From: Meirav Kama <meiravk@ti.com>
>
> MP received data frames from another MP. Frames are forwarded
> from Rx to Tx to be transmitted to a third MP.
> Upon cloning the skb, the tx_info was zeroed, and the
> hw_queue wasn't set correctly, causing frames to be
> inserted to queue 0 (VOICE). If re-queue occurred for some
> reason, frame will be inserted to correct queue 2 (BE).
> In this case frames are now dequeued from 2 different queues and
> sent out of order.
Uh, sorry. I was so focused on the commit message and everything that I
neglected to look into the code change ... :(
> info->control.jiffies = jiffies;
> + info->hw_queue = q;
>
This is incorrect. 'q' appears to be the AC here, so you need to set
something like vif->hw_queue[q], afaict? Check out tx.c where this is
set.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Add protection to get_expected_throughput opcode
From: Johannes Berg @ 2016-08-11 12:55 UTC (permalink / raw)
To: Maxim Altshul; +Cc: linux-wireless
In-Reply-To: <20160811103816.1695-2-maxim.altshul@ti.com>
On Thu, 2016-08-11 at 13:38 +0300, Maxim Altshul wrote:
> To protect the opcode we add a check for sta->uploaded.
>
Applied, with a reworded commit message - thanks
johannes
^ permalink raw reply
* Re: [PATCH 1/4] cfg80211: rdev-ops: remove callback check from rdev_set_coalesce()
From: Johannes Berg @ 2016-08-11 12:48 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1470825209-10054-1-git-send-email-arend.vanspriel@broadcom.com>
On Wed, 2016-08-10 at 12:33 +0200, Arend van Spriel wrote:
> The wrapper rdev_set_coalesce() checks whether the driver provides
> the set_coalesce callback and returns -ENOTSUPP if not. However, this
> check is already performed in nl80211_set_coalesce() resulting in
> -EOPNOTSUPP. This patch removes check from rdev wrapper function.
What's the point though? Presumably the compiler will optimise it out,
and it seems safer to have it this way? Same for all patches in this
series.
johannes
^ permalink raw reply
* Re: [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
From: Johannes Berg @ 2016-08-11 12:47 UTC (permalink / raw)
To: Denis Kenzior, linux-wireless
In-Reply-To: <1470261735-2977-1-git-send-email-denkenz@gmail.com>
On Wed, 2016-08-03 at 17:02 -0500, Denis Kenzior wrote:
>
> +static int nl80211_dump_interface_parse(struct sk_buff *skb,
> + struct netlink_callback *cb,
> + int *filter_wiphy)
Wrong indentation :)
> static int nl80211_dump_interface(struct sk_buff *skb, struct
> netlink_callback *cb)
> {
> int wp_idx = 0;
> int if_idx = 0;
> int wp_start = cb->args[0];
> int if_start = cb->args[1];
> + int filter_wiphy = cb->args[2];
> struct cfg80211_registered_device *rdev;
> struct wireless_dev *wdev;
>
> + if (!wp_start && !if_start && !filter_wiphy) {
This seems incorrect - you're setting
> + int ret;
> +
> + filter_wiphy = -1;
> +
> + ret = nl80211_dump_interface_parse(skb, cb,
> &filter_wiphy);
it here, but it can take the value 0, so !filter_wiphy seems wrong?
johannes
^ permalink raw reply
* Re: [PATCH v3 0/3] Improve wireless netdev detection
From: Johannes Berg @ 2016-08-11 12:44 UTC (permalink / raw)
To: Denis Kenzior, linux-wireless
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
On Wed, 2016-08-03 at 16:58 -0500, Denis Kenzior wrote:
> The current mechanism to detect hot-plug / unplug of wireless devices
> is
> somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events
> over
> nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
> somehow find a correlation between these events. This involves
> userspace
> sending GET_INTERFACE or GET_WIPHY commands to the kernel, which
> incurs
> additional roundtrips.
>
Applied. I squashed 1/2 since it's kinda pointless to have a patch
introducing infrastructure that's not used.
I also made some minor cleanups - please check (both that it's right,
and for next time)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Keep CoDel stats per txq, export them in debugfs.
From: Toke Høiland-Jørgensen @ 2016-08-11 12:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: make-wifi-fast, linux-wireless, Michal Kazior
In-Reply-To: <1470918167.12075.2.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
>> @@ -137,18 +137,20 @@ static int aqm_open(struct inode *inode, struct
>> file *file)
>> len += scnprintf(info->buf + len,
>> info->size - len,
>> "* vif\n"
>> - "ifname addr ac backlog-bytes backlog-
>> packets flows overlimit collisions tx-bytes tx-packets\n");
>> + "ifname addr ac backlog-bytes backlog-
>> packets flows drops marks overlimit collisions tx-bytes tx-
>> packets\n");
>
> It seems to me that you have to change the buffer length to take this
> into account?
Haven't run into issues with running out of buffer space in my testing.
But yeah, guess that could become an issue.
>> list_for_each_entry_rcu(sdata, &local->interfaces, list) {
>> txqi = to_txq_info(sdata->vif.txq);
>> len += scnprintf(info->buf + len, info->size - len,
>> - "%s %pM %u %u %u %u %u %u %u %u\n",
>> + "%s %pM %u %u %u %u %u %u %u %u %u
>> %u\n",
>> sdata->name,
>
> Why is it this way anyway? It'd seem nicer to move the content of this
> into the per-netdev subdirectories, and then it becomes a lot simpler
> code too (yes, at the expense of some userspace, but still)
Yeah, makes sense. Can do a larger reorg moving things into the
per-netdev and per-station directories instead.
>> txqi->txq.ac,
>> txqi->tin.backlog_bytes,
>> txqi->tin.backlog_packets,
>> txqi->tin.flows,
>> + txqi->cstats.drop_count,
>> + txqi->cstats.ecn_mark,
>> txqi->tin.overlimit,
>> txqi->tin.collisions,
>> txqi->tin.tx_bytes,
>
> Do you really want to add these in the middle? Seems that if you add
> them at the end, you at least have *some* way of keeping this working
> with older versions?
Well I though they should be logically grouped with overlimits, and was
counting on no one actually parsing these yet. Guess if the information
is moved that becomes moot.
Will re-send; thanks for the feedback :)
-Toke
^ permalink raw reply
* Re: Problems with mwifiex_pcie firmware activation
From: Stanislaw Gruszka @ 2016-08-11 12:29 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: Nishant Sarmukadam, linux-wireless@vger.kernel.org
In-Reply-To: <f5b2566be31743809217833e76060d42@SC-EXCH04.marvell.com>
Hi
On Thu, Aug 11, 2016 at 10:21:58AM +0000, Amitkumar Karwar wrote:
> > -----Original Message-----
> > From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> > Sent: Thursday, August 11, 2016 2:31 PM
> > To: Amitkumar Karwar
> > Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> > Subject: Re: Problems with mwifiex_pcie firmware activation
> >
> > On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> > > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > > > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > > > > Could you please share complete dmesg log for failure and
> > successful cases?
> > > >
> > > > Dmesg from failure case is in attachment. I loose access to system
> > > > where device initalize, I'll provide missed dmesg when I get back
> > > > the access.
> > >
> > > Have the access now, dmesg is in attachment.
> >
> > Any news here ?
>
> Do you have below patch included? It increases poll count which may help in your case.
> https://patchwork.kernel.org/patch/7973951/
Yes, I have that patch.
To clarify the issue: reverting above patch seems to helps with the
problem. That what I basically did on first of my systems with mwifiex,
that did not work similarly like second one. However I did not revert
the patch but just comment out check_winner_status:
@@ -755,7 +755,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
}
/* check if we are the winner for downloading FW */
- if (adapter->if_ops.check_winner_status) {
+ if (false) {
adapter->winner = 0;
ret = adapter->if_ops.check_winner_status(adapter);
After running modified kernel once, the problem was gone on
unmodified kernel! I suppose that once new firmware was uploaded to
the device it somehow modify it (change it's internal firmware?) and make
check_winner_status() works correctly. This is strange, but I can not
find any other explanation and don't see any other changes in the
first system that makes mwifiex suddenly work.
I could be wrong, but I suppose somebody who use pre 4.6 kernel (without
the above patch committed as: 2fd5c6ed0b4fbf3c2d9314a24c82862ce5254d42
"mwifiex: firmware download enhancements") with new enough mwifiex
firmware, will not see the problem even after kernel update. But if
somebody install 4.6 or newer kernel on pristine hardware, the device
will not work.
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH] mac80211: Keep CoDel stats per txq, export them in debugfs.
From: Johannes Berg @ 2016-08-11 12:22 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
Cc: Michal Kazior
In-Reply-To: <20160720145442.1098-1-toke@toke.dk>
> @@ -137,18 +137,20 @@ static int aqm_open(struct inode *inode, struct
> file *file)
> len += scnprintf(info->buf + len,
> info->size - len,
> "* vif\n"
> - "ifname addr ac backlog-bytes backlog-
> packets flows overlimit collisions tx-bytes tx-packets\n");
> + "ifname addr ac backlog-bytes backlog-
> packets flows drops marks overlimit collisions tx-bytes tx-
> packets\n");
It seems to me that you have to change the buffer length to take this
into account?
> list_for_each_entry_rcu(sdata, &local->interfaces, list) {
> txqi = to_txq_info(sdata->vif.txq);
> len += scnprintf(info->buf + len, info->size - len,
> - "%s %pM %u %u %u %u %u %u %u %u\n",
> + "%s %pM %u %u %u %u %u %u %u %u %u
> %u\n",
> sdata->name,
Why is it this way anyway? It'd seem nicer to move the content of this
into the per-netdev subdirectories, and then it becomes a lot simpler
code too (yes, at the expense of some userspace, but still)
> sdata->vif.addr,
This is also kinda pointless since it's easy to get elsewhere.
> txqi->txq.ac,
> txqi->tin.backlog_bytes,
> txqi->tin.backlog_packets,
> txqi->tin.flows,
> + txqi->cstats.drop_count,
> + txqi->cstats.ecn_mark,
> txqi->tin.overlimit,
> txqi->tin.collisions,
> txqi->tin.tx_bytes,
Do you really want to add these in the middle? Seems that if you add
them at the end, you at least have *some* way of keeping this working
with older versions?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: remove skb header offset mangling in ieee80211_build_hdr
From: Johannes Berg @ 2016-08-11 12:12 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
In-Reply-To: <20160713090002.51127-1-nbd@nbd.name>
On Wed, 2016-07-13 at 11:00 +0200, Felix Fietkau wrote:
> Since the code only touches the MAC headers, the offsets to the
> network/transport headers remain the same throughout this function.
> Remove pointless pieces of code that try to 'preserve' them.
>
Applied, thanks.
johannes
^ permalink raw reply
* [PATCH v5] cfg80211: Provision to allow the support for different beacon intervals
From: Purushottam Kushwaha @ 2016-08-11 11:49 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, djindal, pkushwah
This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through diff_beacon_int_gcd (u32).
The configured BI for a specific interface must be a multiple of this
value and also the active beaconing interfaces (along with the current
one) must match with the interface combinations in a group that advertise
the support for different beacon interval.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
include/net/cfg80211.h | 4 ++++
include/uapi/linux/nl80211.h | 8 ++++++--
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 13 ++++++++++---
net/wireless/util.c | 39 +++++++++++++++++++++++++++++++++++++--
5 files changed, 58 insertions(+), 8 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9c23f4d3..a0c635a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2939,6 +2939,8 @@ struct ieee80211_iface_limit {
* only in special cases.
* @radar_detect_widths: bitmap of channel widths supported for radar detection
* @radar_detect_regions: bitmap of regions supported for radar detection
+ * @diff_beacon_int_gcd: This interface combination supports different beacon
+ * intervals in multiple of GCD value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
@@ -2970,6 +2972,7 @@ struct ieee80211_iface_limit {
* .n_limits = ARRAY_SIZE(limits2),
* .max_interfaces = 8,
* .num_different_channels = 1,
+ * .diff_beacon_int_gcd = 100,
* };
*
*
@@ -2997,6 +3000,7 @@ struct ieee80211_iface_combination {
bool beacon_int_infra_match;
u8 radar_detect_widths;
u8 radar_detect_regions;
+ u32 diff_beacon_int_gcd;
};
struct ieee80211_txrx_stypes {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2206941..369e403 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4203,6 +4203,9 @@ enum nl80211_iface_limit_attrs {
* of supported channel widths for radar detection.
* @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute containing the bitmap
* of supported regulatory regions for radar detection.
+ * @NL80211_IFACE_COMB_DIFF_BI_GCD: u32 attribute specifying the GCD of
+ * different beacon intervals supported by all the interface combinations
+ * in this group (not present if all beacon interval must match).
* @NUM_NL80211_IFACE_COMB: number of attributes
* @MAX_NL80211_IFACE_COMB: highest attribute number
*
@@ -4210,8 +4213,8 @@ enum nl80211_iface_limit_attrs {
* limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI, channels = 1, max = 2
* => allows an AP and a STA that must match BIs
*
- * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
- * => allows 8 of AP/GO
+ * numbers = [ #{AP, P2P-GO} <= 8 ], diff BI gcd, channels = 1, max = 8,
+ * => allows 8 of AP/GO that can beacon at multiple of gcd intervals
*
* numbers = [ #{STA} <= 2 ], channels = 2, max = 2
* => allows two STAs on different channels
@@ -4237,6 +4240,7 @@ enum nl80211_if_combination_attrs {
NL80211_IFACE_COMB_NUM_CHANNELS,
NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
+ NL80211_IFACE_COMB_DIFF_BI_GCD,
/* keep last */
NUM_NL80211_IFACE_COMB,
diff --git a/net/wireless/core.h b/net/wireless/core.h
index eee9144..5fffe58 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
u32 *mask);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int);
+ enum nl80211_iftype iftype, u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ddb1469..d3b757d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1020,6 +1020,10 @@ static int nl80211_put_iface_combinations(struct wiphy *wiphy,
nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
c->radar_detect_regions)))
goto nla_put_failure;
+ if (c->diff_beacon_int_gcd &&
+ nla_put_u32(msg, NL80211_IFACE_COMB_DIFF_BI_GCD,
+ c->diff_beacon_int_gcd))
+ goto nla_put_failure;
nla_nest_end(msg, nl_combi);
}
@@ -3454,7 +3458,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, params.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
+ params.beacon_interval);
if (err)
return err;
@@ -7780,7 +7785,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
- err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
+ ibss.beacon_interval);
if (err)
return err;
@@ -9260,7 +9266,8 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
setup.beacon_interval > 10000)
return -EINVAL;
- err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_MESH_POINT,
+ setup.beacon_interval);
if (err)
return err;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index b7d1592..ff9a9cb 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1553,10 +1553,36 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
}
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
+static bool diff_beacon_interval_supported(struct wiphy *wiphy, u16 types,
+ u32 beacon_int)
+{
+ const struct ieee80211_iface_combination *c;
+ u16 all_types;
+ int i, j;
+
+ for (i = 0; i < wiphy->n_iface_combinations; i++) {
+ c = &wiphy->iface_combinations[i];
+
+ if (!c->diff_beacon_int_gcd ||
+ (beacon_int % c->diff_beacon_int_gcd))
+ continue;
+
+ all_types = 0;
+ for (j = 0; j < c->n_limits; j++)
+ all_types |= c->limits[j].types;
+
+ if (all_types & types)
+ return true;
+ }
+
+ return false;
+}
+
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int)
+ enum nl80211_iftype iftype, u32 beacon_int)
{
struct wireless_dev *wdev;
+ u16 types = 0;
int res = 0;
if (!beacon_int)
@@ -1565,7 +1591,16 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
- if (wdev->beacon_interval != beacon_int) {
+ types |= BIT(wdev->iftype);
+ }
+ types |= BIT(iftype);
+
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+ if (!wdev->beacon_interval)
+ continue;
+ if (wdev->beacon_interval != beacon_int &&
+ !diff_beacon_interval_supported(&rdev->wiphy, types,
+ beacon_int)) {
res = -EINVAL;
break;
}
--
1.9.1
^ permalink raw reply related
* RE: mwifiex: PCIe8997 chip specific handling
From: Amitkumar Karwar @ 2016-08-11 10:41 UTC (permalink / raw)
To: Steve deRosier
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, linux-kernel@vger.kernel.org, Wei-Ning Huang
In-Reply-To: <CALupW3CC2ketRdMoaV1r3Wuo4tZx5gZ5tF_DCAAjFgntgYWW4A@mail.gmail.com>
SGkgU3RldmUsDQoNCj4gRnJvbTogU3RldmUgZGVSb3NpZXIgW21haWx0bzpkZXJvc2llckBnbWFp
bC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTYgMjozOSBBTQ0KPiBUbzog
QW1pdGt1bWFyIEthcndhcg0KPiBDYzogQnJpYW4gTm9ycmlzOyBsaW51eC13aXJlbGVzc0B2Z2Vy
Lmtlcm5lbC5vcmc7IENhdGh5IEx1bzsgTmlzaGFudA0KPiBTYXJtdWthZGFtOyBsaW51eC1rZXJu
ZWxAdmdlci5rZXJuZWwub3JnOyBXZWktTmluZyBIdWFuZw0KPiBTdWJqZWN0OiBSZTogbXdpZmll
eDogUENJZTg5OTcgY2hpcCBzcGVjaWZpYyBoYW5kbGluZw0KPiANCj4gSGksDQo+IA0KPiBPbiBX
ZWQsIEF1ZyAxMCwgMjAxNiBhdCAxMjowNyBBTSwgQW1pdGt1bWFyIEthcndhciA8YWthcndhckBt
YXJ2ZWxsLmNvbT4NCj4gd3JvdGU6DQo+ID4gSGkgQnJpYW4sDQo+ID4NCj4gPj4gRnJvbTogQnJp
YW4gTm9ycmlzIFttYWlsdG86YnJpYW5ub3JyaXNAY2hyb21pdW0ub3JnXQ0KPiA+PiBTZW50OiBX
ZWRuZXNkYXksIEF1Z3VzdCAxMCwgMjAxNiAxMjoxNCBBTQ0KPiA+PiBUbzogQW1pdGt1bWFyIEth
cndhcg0KPiA+PiBDYzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBDYXRoeSBMdW87
IE5pc2hhbnQgU2FybXVrYWRhbTsNCj4gPj4gbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZw0K
PiA+PiBTdWJqZWN0OiBSZTogbXdpZmlleDogUENJZTg5OTcgY2hpcCBzcGVjaWZpYyBoYW5kbGlu
Zw0KPiA+Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gT24gRnJpLCBKdWwgMjksIDIwMTYgYXQgMDQ6
MDg6NTFQTSArMDUzMCwgQW1pdGt1bWFyIEthcndhciB3cm90ZToNCj4gPj4gPiBUaGUgcGF0Y2gg
Y29ycmVjdHMgdGhlIHJldmlzaW9uIGlkIHJlZ2lzdGVyIGFuZCB1c2VzIGl0IGFsb25nIHdpdGgN
Cj4gPj4gPiBtYWdpYyB2YWx1ZSBhbmQgY2hpcCB2ZXJzaW9uIHJlZ2lzdGVycyB0byBkb3dubG9h
ZCBhcHByb3ByaWF0ZQ0KPiA+PiA+IGZpcm13YXJlIGltYWdlLg0KPiA+PiA+DQo+ID4+ID4gUENJ
ZTg5OTcgWiBjaGlwc2V0IHZhcmlhbnQgY29kZSBoYXMgYmVlbiByZW1vdmVkLCBhcyBpdCB3b24n
dCBiZQ0KPiA+PiA+IHVzZWQgaW4gcHJvZHVjdGlvbi4NCj4gPj4gPg0KPiA+PiA+IFNpZ25lZC1v
ZmYtYnk6IEFtaXRrdW1hciBLYXJ3YXIgPGFrYXJ3YXJAbWFydmVsbC5jb20+DQo+ID4+ID4gLS0t
DQo+ID4+ID4gIGRyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9wY2llLmMgfCAz
NQ0KPiA+PiA+ICsrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4gZHJpdmVycy9u
ZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuaCB8IDE0ICsrKysrLS0tLS0tLQ0KPiA+
PiA+ICAyIGZpbGVzIGNoYW5nZWQsIDE4IGluc2VydGlvbnMoKyksIDMxIGRlbGV0aW9ucygtKQ0K
PiA+Pg0KPiA+PiBbLi4uXQ0KPiA+Pg0KPiA+PiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93
aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvcGNpZS5oDQo+ID4+ID4gYi9kcml2ZXJzL25ldC93aXJl
bGVzcy9tYXJ2ZWxsL213aWZpZXgvcGNpZS5oDQo+ID4+ID4gaW5kZXggZjY5OTJmMC4uNDZmOTlj
YSAxMDA2NDQNCj4gPj4gPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZp
ZXgvcGNpZS5oDQo+ID4+ID4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lm
aWV4L3BjaWUuaA0KPiA+PiA+IEBAIC0zMiwxMiArMzIsOSBAQA0KPiA+PiA+ICAjZGVmaW5lIFBD
SUU4ODk3X0RFRkFVTFRfRldfTkFNRSAibXJ2bC9wY2llODg5N191YXBzdGEuYmluIg0KPiA+PiA+
ICAjZGVmaW5lIFBDSUU4ODk3X0EwX0ZXX05BTUUgIm1ydmwvcGNpZTg4OTdfdWFwc3RhX2EwLmJp
biINCj4gPj4gPiAgI2RlZmluZSBQQ0lFODg5N19CMF9GV19OQU1FICJtcnZsL3BjaWU4ODk3X3Vh
cHN0YS5iaW4iDQo+ID4+ID4gLSNkZWZpbmUgUENJRTg5OTdfREVGQVVMVF9GV19OQU1FICJtcnZs
L3BjaWV1c2I4OTk3X2NvbWJvX3YyLmJpbiINCj4gPj4gPiAtI2RlZmluZSBQQ0lFVUFSVDg5OTdf
RldfTkFNRV9aICJtcnZsL3BjaWV1YXJ0ODk5N19jb21iby5iaW4iDQo+ID4+ID4gLSNkZWZpbmUg
UENJRVVBUlQ4OTk3X0ZXX05BTUVfVjIgIm1ydmwvcGNpZXVhcnQ4OTk3X2NvbWJvX3YyLmJpbiIN
Cj4gPj4gPiAtI2RlZmluZSBQQ0lFVVNCODk5N19GV19OQU1FX1ogIm1ydmwvcGNpZXVzYjg5OTdf
Y29tYm8uYmluIg0KPiA+PiA+IC0jZGVmaW5lIFBDSUVVU0I4OTk3X0ZXX05BTUVfVjIgIm1ydmwv
cGNpZXVzYjg5OTdfY29tYm9fdjIuYmluIg0KPiA+PiA+IC0jZGVmaW5lIFBDSUU4OTk3X0RFRkFV
TFRfV0lGSUZXX05BTUUgIm1ydmwvcGNpZTg5OTdfd2xhbi5iaW4iDQo+ID4+ID4gKyNkZWZpbmUg
UENJRVVBUlQ4OTk3X0ZXX05BTUVfVjQgIm1ydmwvcGNpZXVhcnQ4OTk3X2NvbWJvX3Y0LmJpbiIN
Cj4gPj4gPiArI2RlZmluZSBQQ0lFVVNCODk5N19GV19OQU1FX1Y0ICJtcnZsL3BjaWV1c2I4OTk3
X2NvbWJvX3Y0LmJpbiINCj4gPj4gPiArI2RlZmluZSBQQ0lFODk5N19ERUZBVUxUX1dJRklGV19O
QU1FICJtcnZsL3BjaWU4OTk3X3dsYW5fdjQuYmluIg0KPiA+Pg0KPiA+PiBXaHkgZG8gdmVyc2lv
biBidW1wcyByZXF1aXJlIGZpcm13YXJlIHJlbmFtZXM/IElzIHRoaXMganVzdCB0byBtYWtlDQo+
ID4+IHN1cmUgeW91IGRvbid0IGxvYWQgdGhlIG5ldyBmaXJtd2FyZSBvbiBvbGQgY2hpcCByZXZz
IHRoYXQgeW91IGRvbid0DQo+ID4+IHBsYW4gdG8gc3VwcG9ydCBmb3IgcHJvZHVjdGlvbiAoaS5l
Liwgb25seSBlYXJseSByZXZzIGxpa2UgdGhlIF9aDQo+ID4+IHlvdSdyZSBkcm9wcGluZyk/IFRo
aXMgZG9lc24ndCBzZWVtcyBsaWtlIGEgZ29vZCBsb25nLXRlcm0gc29sdXRpb24sDQo+ID4+IGF0
IGxlYXN0IG9uY2UgeW91IHN0YXJ0IGdldHRpbmcgdGhpcyBzaWxpY29uIG91dCBpbiB0aGUgd2ls
ZC4gQXQgc29tZQ0KPiA+PiBwb2ludCwgSSdkIGV4cGVjdCB0byBzZWUgYSBzdGFibGUgZmlsZSBu
YW1lLg0KPiA+Pg0KPiA+PiBCcmlhbg0KPiA+Pg0KPiA+DQo+ID4gV2UgaGF2ZW4ndCB5ZXQgc3Vi
bWl0dGVkIGFueSBmaXJtd2FyZSBpbWFnZSB1cHN0cmVhbSBmb3IgODk5NyBjaGlwc2V0Lg0KPiA+
IHBjaWV1YXJ0ODk5N19jb21ib192NC5iaW4vcGNpZXVzYjg5OTdfY29tYm9fdjQuYmluIHdvdWxk
IGJlIG91cg0KPiBmaXJtd2FyZSBjYW5kaWRhdGUgZm9yIHVwc3RyZWFtIHN1Ym1pc3Npb24uIFRo
ZSBmaWxlbmFtZSB3b3VsZCByZW1haW4NCj4gc2FtZSBoZXJlYWZ0ZXIuDQo+ID4NCj4gPiBwY2ll
Kjg5OTdfY29tYm9fdjIuYmluIGhhZCBzdXBwb3J0IG9ubHkgZm9yIEEwIGNoaXBzZXQNCj4gPiBw
Y2llKjg5OTdfY29tYm9fdjMuYmluIHdhcyBvdXIgaW50ZXJuYWwgZGV2ZWxvcG1lbnQgdmVyc2lv
biB3aGljaCBoYWQNCj4gPiBzdXBwb3J0IGZvciBBMSBjaGlwc2V0IHBjaWUqODk5N19jb21ib192
NC5iaW4gaGFzIHN1cHBvcnQgZm9yIGJvdGggQTANCj4gYW5kIEExIGNoaXBzZXRzIGFuZCB0aGlz
IGlzIHRoZSB2ZXJzaW9uIHRoYXQgc2hhbGwgYmUgcmVsZWFzZWQgdG8NCj4gY3VzdG9tZXJzL3Vw
c3RyZWFtIGZyb20gbm93IG9uLg0KPiA+DQo+IA0KPiBTZWVtcyB0byBtZSB0aGVuIGl0IHNob3Vs
ZCBqdXN0IGJlIG5hbWVkIHBjaWUqODk5N193bGFuLmJpbi4gIEEgdmVyc2lvbg0KPiBudW1iZXIg
c2hvdWxkbid0IGJlIHBhcnQgb2YgdGhlIGZpbGUgbmFtZSBpbiB0aGlzIGNhc2UuIEhhdmluZyB0
byB1cGRhdGUNCj4gdGhlIGRyaXZlciBmb3IgYSBmaXJtd2FyZSBuYW1lIGNoYW5nZSBpcyBzaWxs
eS4gTW9zdCB3aXJlbGVzcyBkcml2ZXJzDQo+IGhhdmUgZGlmZmVyZW50IG5hbWVzIGZvciBkaWZm
ZXJlbnQgaGFyZHdhcmUvY2hpcCByZXZzIGFuZC9vciBhbg0KPiBpbmNvbXBhdGlibGUgQVBJIGNo
YW5nZS4gIE1vc3QgZGlzdHJpYnV0aW9ucyB3b3VsZCB0eXBpY2FsbHkgb25seSBjYXJyeQ0KPiBh
IHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgZmlybXdhcmUgZm9yIGEgcGFydGljdWxhciBjaGlwLg0K
PiBTcGVha2luZyBmb3IgdGhlIG9uZXMgSSB3b3JrIHdpdGgsIEkgdXN1YWxseSBrZWVwIHRoZSBv
cmlnaW5hbCBmaWxlbmFtZQ0KPiBpbnRhY3QgKHdpdGggYSB2ZXJzaW9uIG51bWJlcikgYW5kIG1h
a2UgYSBzeW1saW5rIHRvIGl0IHdpdGggdGhlIG5hbWUNCj4gdGhlIGRyaXZlciBleHBlY3RzLiAg
ZWc6DQo+IA0KPiBmdy00LmJpbiAtPiBmd192My40LjAuOTQuYmluDQo+IGZ3X3YzLjIuMC4xNDQu
YmluDQo+IGZ3X3YzLjQuMC45NC5iaW4NCj4gDQo+IFRoYXQgd2F5IEkgY2FuIGtlZXAgdHJhY2sg
b2YgdGhlIHZlcnNpb24gaW4gbXkgZmlsZXN5c3RlbSwgYnV0IEknbSBub3QNCj4gaGFja2luZyB0
aGUgZHJpdmVyIGV2ZXJ5IGNvdXBsZSBvZiB3ZWVrcy4gIEFuZCB3ZSBkbyBpc3N1ZSBuZXcgZmly
bXdhcmUNCj4gZXZlcnkgZmV3IHdlZWtzLiBJIGNhbid0IGltYWdpbmUgYXNraW5nIG91ciBjdXN0
b21lcnMgdG8ga2VlcCB1cGRhdGluZw0KPiB0aGUgZHJpdmVyIGZvciBlYWNoIGZpcm13YXJlIGVu
aGFuY2VtZW50Lg0KPiANCj4gSU1ITyBjaGFuZ2luZyB0aGUgZHJpdmVyIHRvIHJlbmFtZSB0aGUg
ZmlybXdhcmVzIG9uIG5ldyB2ZXJzaW9ucyBzZWVtcw0KPiBib3RoIGluY29udmVuaWVudCB0byBw
ZW9wbGUgdXNpbmcgaXQsIGFuZCBleHRyYSBub24tdXNlZnVsIGNvbW1pdCBub2lzZS4NCj4gDQoN
ClRoYW5rcy4gSSBhZ3JlZSB3aXRoIHlvdS4gV2UgaGF2ZSBhbHNvIG1haW50YWluZWQgc2luZ2xl
IGluc3RhbmNlL25hbWUgZm9yIGFsbCBvdXIgY2hpcHNldHMgZm9yIGxhc3QgZmV3IHllYXJzLiBX
ZSBkbyByZWxlYXNlIG5ldyBmaXJtd2FyZSBwZXJpb2RpY2FsbHkgZm9yIHRoZXNlIGNoaXBzZXRz
LCBidXQgZmlybXdhcmUgbmFtZSBhbHdheXMgcmVtYWlucyB0aGUgc2FtZS4NCg0KLS0tLS0tLS0N
CnJvb3RAcGUtbHQ5NDk6L2xpbnV4LWZpcm13YXJlL21ydmwjIGxzDQpwY2llODg5N191YXBzdGEu
YmluICBzZDg2ODhfaGVscGVyLmJpbiAgc2Q4Nzk3X3VhcHN0YS5iaW4gIHNkODg5N191YXBzdGEu
YmluICAgdXNiODc5N191YXBzdGEuYmluDQpzZDg2ODguYmluICAgICAgICAgICBzZDg3ODdfdWFw
c3RhLmJpbiAgc2Q4ODg3X3VhcHN0YS5iaW4gIHVzYjg3NjZfdWFwc3RhLmJpbiAgdXNiODg5N191
YXBzdGEuYmluDQotLS0tLS0tLS0NCg0KSXTigJlzIGp1c3QgdGhhdCBmb3Igb3VyIG5ldyBjaGlw
c2V0IDg5OTcgZm9yIHdoaWNoIHdlIGhhdmVuJ3QgeWV0IHN1Ym1pdHRlZCB0aGUgZmlybXdhcmUg
aW1hZ2UgdXBzdHJlYW0sIHdlIHdhbnQgdG8gZmluYWxpemUgdGhlIG5hbWUgYXMgcGNpZSo4OTk3
X2NvbWJvX3Y0LmJpbg0KDQpSZWdhcmRzLA0KQW1pdGt1bWFyIEthcndhcg0K
^ permalink raw reply
* RE: Problems with mwifiex_pcie firmware activation
From: Amitkumar Karwar @ 2016-08-11 10:21 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Nishant Sarmukadam, linux-wireless@vger.kernel.org
In-Reply-To: <20160811090113.GA27059@redhat.com>
Hi Stanislaw,
> -----Original Message-----
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Thursday, August 11, 2016 2:31 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > > > Could you please share complete dmesg log for failure and
> successful cases?
> > >
> > > Dmesg from failure case is in attachment. I loose access to system
> > > where device initalize, I'll provide missed dmesg when I get back
> > > the access.
> >
> > Have the access now, dmesg is in attachment.
>
> Any news here ?
Do you have below patch included? It increases poll count which may help in your case.
https://patchwork.kernel.org/patch/7973951/
Regards,
Amitkumar
^ permalink raw reply
* [PATCH] mac80211: Add protection to get_expected_throughput opcode
From: Maxim Altshul @ 2016-08-11 10:38 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Maxim Altshul
In-Reply-To: <20160811103816.1695-1-maxim.altshul@ti.com>
To protect the opcode we add a check for sta->uploaded.
This is done to prevent a situation where the function gets
called from userspace for example, before sta is uploaded
to driver, causing a crash.
Also, change headers to comply with the change, wherever the
function was called.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
---
net/mac80211/driver-ops.h | 8 ++++----
net/mac80211/sta_info.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 1f75195..ec4a690 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1075,13 +1075,13 @@ static inline void drv_leave_ibss(struct ieee80211_local *local,
}
static inline u32 drv_get_expected_throughput(struct ieee80211_local *local,
- struct ieee80211_sta *sta)
+ struct sta_info *sta)
{
u32 ret = 0;
- trace_drv_get_expected_throughput(sta);
- if (local->ops->get_expected_throughput)
- ret = local->ops->get_expected_throughput(&local->hw, sta);
+ trace_drv_get_expected_throughput(&sta->sta);
+ if (local->ops->get_expected_throughput && sta->uploaded)
+ ret = local->ops->get_expected_throughput(&local->hw, &sta->sta);
trace_drv_return_u32(local, ret);
return ret;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 8860c6c..6624577 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2108,7 +2108,7 @@ u32 sta_get_expected_throughput(struct sta_info *sta)
if (ref && ref->ops->get_expected_throughput)
thr = ref->ops->get_expected_throughput(sta->rate_ctrl_priv);
else
- thr = drv_get_expected_throughput(local, &sta->sta);
+ thr = drv_get_expected_throughput(local, sta);
return thr;
}
--
2.9.0
^ permalink raw reply related
* [PATCH] Add protection to get_expected_throughput opcode
From: Maxim Altshul @ 2016-08-11 10:38 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Maxim Altshul
The patch is done with respect to the patch that was applied:
[PATCH v3] mac80211: mesh: Add support for HW RC implementation
1. Patch adds protection as we discussed
2. Patch changes the function call that is made in the mesh patch
to comply with the change.
Maxim Altshul (1):
mac80211: Add protection to get_expected_throughput opcode
net/mac80211/driver-ops.h | 8 ++++----
net/mac80211/sta_info.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.9.0
^ permalink raw reply
* RE: [PATCH] cfg80211: validate beacon interval for MESH/IBSS
From: Kushwaha, Purushottam @ 2016-08-11 9:56 UTC (permalink / raw)
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Undekari, Sunil Dutt, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath, Kumar, Deepak (QCA)
In-Reply-To: <1470908642-13535-1-git-send-email-pkushwah@qti.qualcomm.com>
Johannes ,
While addressing this change, we could notice that the minimum boundary for beacon interval for the case of IBSS is 1 but for Mesh it is 10. Also this check is not done for AP/P2P GO .
Any reason why there is a discrepancy among them ? These configurations should be aligned , I guess.
Shouldn't the minimum value be 10 ? If yes , the boundary check should be moved to cfg80211_validate_beacon_int ?
Thanks,
Purushottam
-----Original Message-----
From: Kushwaha, Purushottam
Sent: Thursday, August 11, 2016 3:14 PM
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org; Malinen, Jouni <jouni@qca.qualcomm.com>; Undekari, Sunil Dutt <usdutt@qti.qualcomm.com>; Kalikot Veetil, Mahesh Kumar <mkalikot@qca.qualcomm.com>; Hullur Subramanyam, Amarnath <amarnath@qca.qualcomm.com>; Kumar, Deepak (QCA) <djindal@qti.qualcomm.com>; Kushwaha, Purushottam <pkushwah@qti.qualcomm.com>
Subject: [PATCH] cfg80211: validate beacon interval for MESH/IBSS
Beacon interval validation was missing for MESH / IBSS join.
This commit addresses the same.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
net/wireless/nl80211.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index f02653a..ddb1469 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7780,6 +7780,10 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
+ err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -9255,6 +9259,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
if (setup.beacon_interval < 10 ||
setup.beacon_interval > 10000)
return -EINVAL;
+
+ err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ if (err)
+ return err;
}
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
--
1.9.1
^ permalink raw reply
* [PATCH] cfg80211: validate beacon interval for MESH/IBSS
From: Purushottam Kushwaha @ 2016-08-11 9:44 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, jouni, usdutt, mkalikot, amarnath, djindal,
pkushwah
Beacon interval validation was missing for MESH / IBSS join.
This commit addresses the same.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
net/wireless/nl80211.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f02653a..ddb1469 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7780,6 +7780,10 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
+ err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -9255,6 +9259,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
if (setup.beacon_interval < 10 ||
setup.beacon_interval > 10000)
return -EINVAL;
+
+ err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ if (err)
+ return err;
}
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
--
1.9.1
^ permalink raw reply related
* Re: Problems with mwifiex_pcie firmware activation
From: Stanislaw Gruszka @ 2016-08-11 9:01 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: Nishant Sarmukadam, linux-wireless@vger.kernel.org
In-Reply-To: <20160623120952.GA11157@redhat.com>
On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > > Could you please share complete dmesg log for failure and successful cases?
> >
> > Dmesg from failure case is in attachment. I loose access to system
> > where device initalize, I'll provide missed dmesg when I get back
> > the access.
>
> Have the access now, dmesg is in attachment.
Any news here ?
Stanislaw
^ permalink raw reply
* Re: [PATCH v3] mac80211: mesh: Add support for HW RC implementation
From: Johannes Berg @ 2016-08-11 8:03 UTC (permalink / raw)
To: Maxim Altshul, linux-kernel; +Cc: David S. Miller, linux-wireless
In-Reply-To: <20160711141539.30281-1-maxim.altshul@ti.com>
On Mon, 2016-07-11 at 17:15 +0300, Maxim Altshul wrote:
> Mesh HWMP module will be able to rely on the HW
> RC algorithm if it exists, for path metric calculations.
>
> This allows the metric calculation mechanism to calculate
> a correct metric, based on PER and last TX rate both via
> HW RC algorithm if it exists or via parameters collected
> by the SW.
>
Applied. I decided to put the fix for the sta->uploaded thing into
mac80211-next, since there's no driver affected by it now, so please
base that patch on this one, if necessary.
johannes
^ permalink raw reply
* Re: pull-request: mac80211 2016-08-05
From: Johannes Berg @ 2016-08-11 7:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <1470400329-23256-1-git-send-email-johannes@sipsolutions.net>
On Fri, 2016-08-05 at 14:32 +0200, Johannes Berg wrote:
> Hi Dave,
>
> Here's a first set of fixes for the current cycle. See the tag
> message
> for more information.
>
> I'll probably have a follow-up fix for the real problem in mac80211
> that caused the crash later, but for now we have this patch and it
> makes sense and fixes the crash, even if the behaviour isn't quite
> right (afaict.)
>
Just FYI, I'm going to "defer" the fix for the wrong behaviour to
mac80211-next since no driver is affected by it.
johannes
^ permalink raw reply
* [PATCH v2] brcmfmac: shut down AP and set IBSS mode only on primary interface
From: Wright Feng @ 2016-08-11 5:44 UTC (permalink / raw)
To: brcm80211-dev-list.pdl, arend.vanspriel, kvalo, franky.lin,
hante.meuleman, pieterpg, linux-wireless, chln
Cc: Wright Feng
When stopping hostap on virtual interface, driver will set INFRA and AP
mode that may affect the functionality on primary interface. For example,
if we create and stop hostapd on virtual interface then association
cannot work on primary interface because INFRA mode has been set to IBSS.
Hence we shut down AP and set IBSS mode only on primary interface.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
---
V2:Remove the footnote from the mail.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 2628d5e..0687ab9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4716,6 +4716,8 @@ exit:
static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct net_device *ndev)
{
+ struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
+ struct net_device *primary_ndev = cfg_to_ndev(cfg);
struct brcmf_if *ifp = netdev_priv(ndev);
s32 err;
struct brcmf_fil_bss_enable_le bss_enable;
@@ -4723,7 +4725,8 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct net_device *ndev)
brcmf_dbg(TRACE, "Enter\n");
- if (ifp->vif->wdev.iftype == NL80211_IFTYPE_AP) {
+ if ((ifp->vif->wdev.iftype == NL80211_IFTYPE_AP) &&
+ (ndev == primary_ndev)) {
/* Due to most likely deauths outstanding we sleep */
/* first to make sure they get processed by fw. */
msleep(400);
--
1.9.1
^ permalink raw reply related
* RE: [PATCH] brcmfmac: shut down AP and set IBSS mode only on primary interface
From: Wright Feng @ 2016-08-11 4:53 UTC (permalink / raw)
To: Arend Van Spriel, brcm80211-dev-list.pdl@broadcom.com,
franky.lin@broadcom.com, hante.meuleman@broadcom.com,
pieterpg@broadcom.com, Chi-Hsien Lin,
linux-wireless@vger.kernel.org, kvalo@codeaurora.org
In-Reply-To: <cab5a204-3487-ebe6-7e82-ca6dbb04ff40@broadcom.com>
On 10-8-2016 12:15, Arend Van Spriel wrote:
> On 10-8-2016 11:44, Wright Feng wrote:
> > Hi Arend,
> >
> > Thanks for the reply.
> >
> > On 10-8-2016 10:26, Arend Van Spriel wrote:
> >> On 10-8-2016 10:01, Wright Feng wrote:
> >>> When stopping hostap on virtual interface, driver will set INFRA and
> >>> AP mode that may affect the functionality on primary interface. For
> >>> example, if we create and stop hostapd on virtual interface then
> >>> association cannot work on primary interface because INFRA mode has
> >> been set to IBSS.
> >>> Hence we shut down AP and set IBSS mode only on primary interface.
> >>
> >> What is actually the use-case here. Can you elaborate? BRCMF_C_DOWN
> >> command turns out to be effectively bring the whole stack down and
> >> not just the supplied interface. I suppose you are hitting that issue here as
> well, right?
> > We want to use AP mode to let client connecting in AP+STA mode with
> 43438 wi-fi chip.
> > After that, the AP mode will be stopped, and wpa_supplicant cannot
> associate to the access point.
> > I describe the steps in detail as below.
> > 1. Create virtual interface and set mode to __ap 2. start
> > wpa_supplicant on primary interface and connect to wireless router.
> > 3. start hostap daemon on virtual interface and let client connecting.
> > 4. stop hostap daemon
> > 5. wpa_supplicant cannot associate to access point normally.
> >
> > Like you said, the issue may be hit by BRCMF_C_DOWN and same as
> > BRCMF_C_SET_INFRA BRCMF_C_SET_INFRA is not just for the supplied
> interface either. The default bss will be changed in firmware and let firmware
> uses IBSS mode to join.
> > About BRCMF_C_DOWN, driver will set BRCMF_C_UP command to bring
> device back up so it can be used again.
> > However, there is no way to set INFRA mode back except starting AP mode
> again.
>
> Ok.
>
> >>
> >> Regards,
> >> Arend
> >>
> >>> Signed-off-by: Wright Feng <wright.feng@cypress.com>
> >>> ---
> >>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5
> >> ++++-
> >>> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git
> >>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> >>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> >>> index 2628d5e..0687ab9 100644
> >>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> >>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> >>> @@ -4716,6 +4716,8 @@ exit:
> >>>
> >>> static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct
> >>> net_device *ndev) {
> >>> + struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
> >>> + struct net_device *primary_ndev = cfg_to_ndev(cfg);
> >>> struct brcmf_if *ifp = netdev_priv(ndev);
> >>> s32 err;
> >>> struct brcmf_fil_bss_enable_le bss_enable; @@ -4723,7
> >>> +4725,8 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy,
> >>> struct net_device *ndev)
> >>>
> >>> brcmf_dbg(TRACE, "Enter\n");
> >>>
> >>> - if (ifp->vif->wdev.iftype == NL80211_IFTYPE_AP) {
> >>> + if ((ifp->vif->wdev.iftype == NL80211_IFTYPE_AP) &&
> >>> + (ndev == primary_ndev)) {
> >>> /* Due to most likely deauths outstanding we sleep */
> >>> /* first to make sure they get processed by fw. */
> >>> msleep(400);
> >>> --
> >>> 1.9.1
> >>>
> >>>
> >>> This message and any attachments may contain Cypress (or its
> >>> subsidiaries)
> >> confidential information. If it has been received in error, please
> >> advise the sender and immediately delete this message.
> >>>
> >
> > This message and any attachments may contain Cypress (or its subsidiaries)
> confidential information. If it has been received in error, please advise the
> sender and immediately delete this message.
>
> Is there any way for you to get rid of this foot note. It may keep Kalle from
> taking this patch. Other option is to take this patch through our internal tree.
No problem. I will remove the footnote from the PATCH v2.
>
> Regards,
> Arend
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: miaoqing @ 2016-08-11 2:54 UTC (permalink / raw)
To: Jason Cooper
Cc: Pan, Miaoqing, Stephan Mueller, Herbert Xu, Matt Mackall,
Valo, Kalle, linux-wireless, ath9k-devel, linux-crypto,
Sepehrdad, Pouyan
In-Reply-To: <20160810132449.GH2013@io.lakedaemon.net>
Hi Jason,
On 2016-08-10 21:24, Jason Cooper wrote:
> *gentle reminder: others are reading which may not be directly included
> in the conversation. Including the archives. Please avoid top
> posting.
> :)
Thanks:)
> The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> the appropriate place for it. It's not a devicetree blob, mac address,
> or pci config space. Which are things we feed in once for the heck of
> it. This is a *continuous* source or questionable quality.
>
> I'm seriously considering putting this and timeriomem-rng into a
> subdirectory under hw_random/, maybe environ/. Anything in there gets
> quality=0 for default, and *doesn't* contribute to /dev/hwrng.
>
> Regardless which path we take, I think we should include 'adc' in the
> name. I've heard countless times about "Atheros cards come with an rng
> on board". :-/
If I understand correctly, you want to bind the ADC source to
/dev/hwrng,
and then change rng-tools to set the entropy to zero in the ioctl call ?
There are two major problems with that approach,
1) We already tried once before to bind our solution to /dev/hwrng, and
got
so much complaints. The conclusion was that maybe we know that the
output of
/dev/hwrng does not have perfect entropy, but a normal user does not
know and
will misuse it. You mentioned in
https://www.kernel.org/doc/Documentation/hw_random.txt
we have
"This data is NOT CHECKED by any
fitness tests, and could potentially be bogus (if the
hardware is faulty or has been tampered with). Data is only
output if the hardware "has-data" flag is set, but nevertheless
a security-conscious person would run fitness tests on the
data before assuming it is truly random."
But this is not enough to convince upstream to switch to /dev/hwrng. I
think the
concern of users misusing the solution is a very valid concern.
2) If we set the entropy to zero in rng-tools, we cannot tolerate the
load.
Rng-tools is not a timer-based solution. Similar to our solution, it is
based on
/proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
the entropy
counter, rng-tools keep writing into the pool, and both rng-tools and
WiFi chip will
be overloaded.
Thanks,
Miaoqing
^ 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