On Thu, 2016-05-19 at 17:34 +0200, Felix Fietkau wrote:
> The header field is defined as u8[] but also accessed as struct
> ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary
> unaligned accesses, which can be very harmful for performance on many
> platforms.
>
>
Applied, thanks.
jo
On Fri, 2016-05-20 at 12:13 +0200, Rafał Miłecki wrote:
> Channels (frequencies) are getting more details that users may want
> to
> know about. E.g. it's important to know which frequencies allow using
> 40/80/160 MHz channels to setup AP properly.
>
> We list channels in "info" command output bu
Hi,
I must say, this is a bit of a surprise - where is iwpriv actually
still relevant? What driver could this possibly matter for?
Anyway ...
> + if (dev->netdev_ops->ndo_do_ioctl) {
> + if ((info->flags & IW_REQUEST_FLAG_COMPAT) &&
> + (cmd >= SIOCIWF
On Tue, 2016-05-31 at 12:03 +0200, Rafał Miłecki wrote:
> On 31 May 2016 at 11:44, Johannes Berg
> wrote:
> >
> > Applied.
> >
> > On Wed, 2016-05-04 at 17:38 +0200, Rafał Miłecki wrote:
> > >
> > > Signed-off-by: Rafał Miłecki
> > Oddl
> The requirement is to be __aligned(2). I've added 4 instances of
> ether_addr_copy with 8 addresses as arguments. Of these, the 4
> src arguments are really the same type (i.e. nla_data acting on a
> const nlattr*), so I'll try to reason about the 5 total cases below -
> 1. cfg->dst_mac should
On Mon, 2016-05-30 at 10:30 +1000, Julian Calaby wrote:
> Hi All,
>
> On Sun, May 29, 2016 at 1:30 PM, Kirtika Ruchandani
> wrote:
> >
> > This patch fixes the following checkpatch.pl warnings about
> > comments in nl80211.c :
> > - networking block comments don't use an empty '/*' line
> > - bl
On Fri, 2016-05-13 at 11:29 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> This makes it a lot easier to understand the capabilities used
> by the station:
>
Applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to
On Tue, 2016-05-31 at 15:10 +0200, Rafał Miłecki wrote:
> > Unfortunately, I get compiler warnings about width_* being possibly
> > used uninitialized. Can you address that please?
> It's nice your compiled got this mistake, my didn't. There were
> actually meant to be static. I'll fix that.
I ac
On Tue, 2016-05-31 at 00:16 +0300, Jouni Malinen wrote:
> Previously, the status parameter to cfg80211_connect_result() was
> documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
> status code for the failure is not known. This value can be used by
> an
> AP (and often is) and as s
On Mon, 2016-05-16 at 10:41 +0530, Kanchanapally, Vidyullatha wrote:
> From: "Kanchanapally, Vidyullatha"
>
> The driver extended capabilities may differ for different
> interface types which the userspace needs to know (for
> example the fine timing measurement initiator and responder
> bits mig
On Tue, 2016-05-31 at 18:28 +0200, Rafał Miłecki wrote:
>
> +static int print_channels_handler(struct nl_msg *msg, void *arg)
> +{
> + struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
> +
extra blank line
> + struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
> + struct nlattr *tb_ban
Hi Dave,
For now, I have just three fixes for the current cycle.
One of them, the hwsim one, becomes interesting with some pending
work to make hwsim work for unprivileged users in namespaces, and
I don't want to allow them to crash the system ... I'll thus wait
with that patch until you pull thi
On Wed, 2016-06-01 at 12:20 -0500, Dan Williams wrote:
> Assuming you mean the "wireless-tools" package, this list is OK. But
> probably nobody will apply the patches, since wireless-tools and the
> WEXT API are long-since deprecated
I don't think anyone even maintains the wireless-tools package
On Thu, 2016-06-02 at 20:51 +0530, Dibyajyoti Ghosh wrote:
> This patch adds pointer conversion from 32 bit to 64 bit and vice
> versa,
> if the ioctl is issued from 32 bit iwpriv to 64 bit Kernel.
>
Huh? the kernel should handle that, no? And didn't you just submit a
patch for it, so you break it
On Thu, 2016-06-02 at 20:48 +0100, One Thousand Gnomes wrote:
> On Thu, 2 Jun 2016 14:38:04 -0400
> "John W. Linville" wrote:
>
> >
> > It has recently come to my attention that the old wireless-
> > legacy.git
> > tree is no longer available on kernel.org. I honestly have no idea
> > what happ
> Not really necessary - at least one commit ID in it is well
> documented:
>
> https://www.softwarefreedom.org/resources/2007/ath5k-code-analysis.html
>
> That might very well be one of the last commits in that tree.
>
Actually, no - it says ath5k branch.
I don't seem to have it.
johannes
-
> http://www.filewatcher.com/_/?q=wireless-legacy.git, maybe ?
>
Seems to work - both have the same branches:
adm8211 72c942ed694e [PATCH] adm8211: fix build breakage from
skb->mac.raw
at76279f8592e428 cfg80211: keep track of supported
interface modes (
> diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
> index 6250b1c..50583fb 100644
> --- a/net/wireless/wext-core.c
> +++ b/net/wireless/wext-core.c
> @@ -958,8 +958,28 @@ static int wireless_process_ioctl(struct net
> *net, struct ifreq *ifr,
> return private(dev
> I know we can't remove wext because of legacy applications but is
> there anything more we can do to make the users aware that wext is
> depreciated and really should be avoided? For example a onetime
> kernel warning? Or is that too spammy? Anything else?
The problem is that wext is in this we
On Thu, 2016-06-09 at 11:06 +0530, Prasun Maiti wrote:
> Since add more warnings for inconsistent ops in cfg80211, the
> wireless
> core warns if a driver implements a cfg80211 callback but doesn't
> implements the inverse operation. The ath6kl driver implements a
> cfg80211
> .get_antenna operatio
From: Johannes Berg
Since set_tx_power and set_antenna are frequently implemented
without the matching get_tx_power/get_antenna, we shouldn't
have added warnings for those. Remove them.
The remaining ones are correct and need to be implemented
symmetrically for correct operation.
Cc
On Mon, 2016-06-06 at 20:04 +0530, Prasun Maiti wrote:
> iwpriv app uses iw_point structure to send data to Kernel. The
> iw_point
> structure holds a pointer. For compatibility Kernel converts the
> pointer
> as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
> may use iw_handle
On Mon, 2016-06-06 at 16:56 +0200, Eduardo Abinader wrote:
> Setting NULL just after freeing regdomain.
>
> Signed-off-by: Eduardo Abinader
> ---
> net/wireless/nl80211.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>
From: Johannes Berg
Everytime I need to look for these, my usual strategy fails
because it assumes the right formatting. Fix the formatting
here to make it consistent with the rest of the kernel.
Signed-off-by: Johannes Berg
---
include/uapi/linux/wireless.h | 63
On Wed, 2016-06-01 at 11:40 +0300, maxin.j...@gmail.com wrote:
> From: "Maxin B. John"
>
> Support separation of SRCDIR and OBJDIR
>
Doesn't seem to work:
$ mkdir /tmp/obj
$ make clean
$ make OBJDIR=/tmp/obj
[...]
GEN version.c
CC version.o
cc: error: version.c: No such file or directory
c
> > > +++ b/net/wireless/nl80211.c
> > > @@ -5839,10 +5839,11 @@ static int nl80211_set_reg(struct sk_buff
> > > *skb, struct genl_info *info)
> > >
> > > r = set_regdom(rd, REGD_SOURCE_CRDA);
> > > /* set_regdom took ownership */
> > > - rd = NULL;
> > >
> > > bad_reg:
> > > kfree(rd)
From: Johannes Berg
Setting rd to NULL to avoid freeing it, just to be able to return
from the function in a single place, doesn't make much sense.
Return the set_regdom() return value directly.
Signed-off-by: Johannes Berg
---
net/wireless/nl80211.c | 6 ++
1 file changed, 2 inser
> +++ b/net/mac80211/debugfs.c
> @@ -126,13 +126,31 @@ static int aqm_open(struct inode *inode, struct
> file *file)
> "R fq_overlimit %u\n"
> "R fq_collisions %u\n"
> "RW fq_limit %u\n"
> - "RW fq_quantum %u
On Thu, 2016-05-05 at 13:00 +0200, Michal Kazior wrote:
> This adds a few debugfs entries and a module
> parameter to make it easier to test, debug and
> experiment.
>
I removed the module parameter, I don't really like that. Maybe it can
be replaced by a mac80211 debugfs file, that already exists
Applied 1-4, with the changes and comments on 5 noted in separate
emails.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-05-19 at 09:16 +0200, Pavel Machek wrote:
> > In the original situation, without these patches, userspace has to
> > have a list of all LEDs that are supposed to indicate airplane
> > mode.
> Well, that's situation for many LEDs.
That doesn't make it a *good* situation though.
> > W
them
Johannes Berg (1):
cfg80211: remove get/set antenna and tx power warnings
Prasun Maiti (1):
wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
net/wireless/core.c | 2 --
net/wireless/wext-core.c | 25 +++--
2 files change
hwsim unprivileged namespace operation
changes
* human-readable VHT capabilities in debugfs
* some other cleanups, like spelling
Ben Greear (1):
mac80211: add vht cap decode to debugfs
Johannes Berg (2):
wext: reformat
On Fri, 2016-06-10 at 11:10 +0200, Michal Kazior wrote:
>
> Hmm.. could it be related to ath10k not fulfilling (some) NAPI's
> locking requirements and thus ending up with, e.g. linked-list
> mayhem?
>
Shoudln't matter since ath10k doesn't actually use rx_napi()?
johannes
--
To unsubscribe from
On Fri, 2016-06-10 at 12:47 -0700, Ben Greear wrote:
> I see this was added sometime recently: NL80211_ATTR_PAD
>
> If another enum member is added, should it replace the PAD enum?
No.
> At the least, I think we need some comments about how this is to be
> dealt with.
>
You simply ignore it :
On Fri, 2016-06-10 at 23:16 -0700, David Miller wrote:
> > Can I ask you to pull net into net-next, preferably before merging
> > this?
> Looks good, pulled, thanks!
Thanks! I see you also had pulled net in for other reasons, so I'll
include the hwsim namespace patch in the next pull request :)
On Mon, 2016-06-13 at 07:39 +0200, Michal Kazior wrote:
>
> FWIW all of these are false positives. I think this was already
> pointed out some time ago. The drv_priv stuff is merely an offset
> (see how ieee80211_vif and ieee80211_sta are defined) and the
> according structure is always checked be
On Mon, 2016-06-13 at 09:05 -0400, Bob Copeland wrote:
>
> So I did just go and check the generated code for each of these cases
> and gcc didn't elide the subsequent if-test, at least on x86-64 and
> my compiler / build config. Given http://lwn.net/Articles/342330, it
> seems possible, though.
I was about to apply this (with a typo fix for "responsile"), but
noticed these messages:
> printk(KERN_DEBUG "mac80211_hwsim: received a REGISTER, "
> "switching to wmediumd mode with pid %d\n", info-
> >snd_portid);
> + if (notify->portid == hwsim_net_get_wmediumd(notify
On Wed, 2016-06-15 at 14:37 +0200, Martin Willi wrote:
> >
> >
> > > printk(KERN_INFO "mac80211_hwsim: wmediumd released netlink"
> > > " socket, switching to perfect channel medium\n");
>
> > I wonder if we can do something better about them? Or perhaps if we
> > should remove them, so
> - if (sta->mesh->fail_avg >= 100)
> - return MAX_METRIC;
> + /* try to get rate based on HW RC algorithm */
> + rate = drv_get_expected_throughput(local, &sta->sta);
This doesn't look correct, since you should use the rate control op if
available, to get data from rate co
On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote:
>
> (Actually, "::wifi" is super confusing, I'd expect that to be a led
> that blinks when wifi is active.)
Agree with that, yeah, that'd be confusing.
> Well... "airplane" is quite confusing. I'd we use "rfkill" for
> disabling radios, and
On Fri, 2016-06-10 at 13:58 +0300, Maxin B. John wrote:
> Hi Johannes,
>
> On Thu, Jun 9, 2016 at 11:25 AM, Johannes Berg
> wrote:
> > On Wed, 2016-06-01 at 11:40 +0300, maxin.j...@gmail.com wrote:
> > > From: "Maxin B. John"
> > >
On Mon, 2016-06-13 at 21:25 +0200, Arend van Spriel wrote:
>
> On 10-06-16 23:08, Johannes Berg wrote:
> > On Fri, 2016-06-10 at 12:47 -0700, Ben Greear wrote:
> > > I see this was added sometime recently: NL80211_ATTR_PAD
> > >
> > > If another enum mem
On Fri, 2016-06-10 at 11:43 -0700, Ben Greear wrote:
> On 03/15/2016 01:20 PM, Johannes Berg wrote:
> > On Tue, 2016-03-15 at 09:10 -0700, Ben Greear wrote:
> > >
> > > The logic I wrote is basically exactly this. It uses the
> > > configured
> > > r
Very brief review:
> +/* */
That seems slightly odd.
> + /* bus private data */
> + char bus_priv[0];
You might want to - for future proofing - add some aligned() attribute.
Otherwise, if struct mutex doesn't have a size that's a multiple of the
pointer size, fields in here will not be
> */
> - changed = mesh_accept_plinks_update(sdata);
> + if (sdata->u.mesh.user_mpm &&
> + sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> + changed |= mesh_plink_dec_estab_count(sdata);
> + changed |= mesh_accept_plinks_update(sdata);
> if (!sdata->u.
> We actually cover (2) for some cases by "accident" since
> ieee80211_rx_h_decrypt() assigns rx->key to rx->sta->gtk[i] if one is
> available. I'm not completely sure this is correct since it applies
> to management frame as well, but that's the way commit
> 897bed8b4320774e56f282cdc1cceb4d774427
On Thu, 2016-06-23 at 14:12 +0300, Yaniv Machani wrote:
> Changed the configuration to support 64bit instead of 32bit
> this in order to offload the driver from handling a wraparound.
[...]
Since you Cc'ed me, and presumably want me to review it, I'll say that
this looks like a terrible idea:
>
> > Additionally, this looks like it changes the firmware API, so that
> > older firmware images will no longer work?
>
> It is backwards compatible,
> although it changes a API structure, older firmware are using only
> u16 for the field so there is no impact on that.
>
Oh, ok. I had also th
> +void sta_get_expected_throughput(struct sta_info *sta, u32 *thr)
> +{
> + struct ieee80211_sub_if_data *sdata = sta->sdata;
> + struct ieee80211_local *local = sdata->local;
> + struct rate_control_ref *ref = NULL;
> +
> + if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
> +
On Sat, 2016-06-25 at 21:32 +0300, Jouni Malinen wrote:
>
> All you need to do is to prepare a hostap.git contribution that
> requests a new subcommand/attribute to be assigned and once that gets
> applied to the hostap.git master branch, the values have been
> assigned and can be used for whateve
On Sun, 2016-06-19 at 23:51 +0300, Jouni Malinen wrote:
> If a user space program (e.g., wpa_supplicant) deletes a STA entry
> that
> is currently in NL80211_PLINK_ESTAB state, the number of established
> plinks counter was not decremented and this could result in rejecting
> new plink establishmen
On Tue, 2016-06-14 at 23:14 +0530, Ashok Raj Nagarajan wrote:
> This patch adds support to set transmit power setting type and
> transmit power level attributes to NL80211_CMD_SET_STATION in order
> to facilitate adjusting the transmit power level of a station
> associated to the AP.
Why would you
On Wed, 2016-06-15 at 22:29 +0200, Arnd Bergmann wrote:
> When building a kernel with W=1, the nl80211.c file causes a number
> of
> warnings, all about the same problem:
>
> net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config':
> net/wireless/nl80211.c:5287:103: error: comparison is al
On Thu, 2016-05-12 at 17:34 +0800, Wei-Ning Huang wrote:
>
> Johannes, I feel like being able to set calibration data at runtime
> is something common to all wireless drivers, so instead of using
> vendor commands what do you think if I pass the calibration data name
> instead of using those magic
On Mon, 2016-06-27 at 17:31 +0300, Dan Carpenter wrote:
> We normally return an unitialized value, but no one checks it so it
> doesn't matter. Anyway, let's silence the static checker warning.
>
Applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
t
On Wed, 2016-06-22 at 20:23 +0900, Masashi Honma wrote:
> Use IEEE80211_MIN_ACTION_SIZE macro for robust management frame
> check.
>
Applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wed, 2016-06-15 at 11:24 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> When driving ath10k with a modified pktgen, we see excessive amounts
> of these warnings:
>
> Jun 6 13:47:53 localhost kernel: WARNING: CPU: 1 PID: 1186 at
> /home/greearb/git/linux-4.4.dev.y/net/mac80211/t
On Tue, 2016-06-28 at 07:50 -0700, Ben Greear wrote:
> So, maybe a WARN_ON would be appropriate at the place frames are
> enqueued in the backlog queue? Since this patch did fix my problem,
> maybe that WARN_ON would show the path that allow frames with bad
> control.vif to be inserted?
Yeah tha
Hi Dave,
Another (pretty old) bug showed up, and I have a single fix for it
from Jouni; would be nice to still get it in, but it's in mesh which
seems to mostly have users who integrate everything themselves.
Let me know if there's any problem.
Thanks,
johannes
The following changes since com
On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> Some drivers (e.g. wl18xx) expect that the last stage in the
> de-initialization process will be stopping the beacons, similar to
> ap. Update ieee80211_stop_mesh() flow accordingly.
>
How well have you tested that w
On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
>
> net/mac80211/mesh.c | 33 -
> net/mac80211/util.c | 3 ---
> net/wireless/mesh.c | 2 +-
That's not a good patch - one change is mac80211 and the other
cfg80211.
> - .ht_opmode = IEEE80211_HT_OP_MOD
On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote:
> From: Meirav Kama
>
> 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
On Tue, 2016-06-28 at 14:15 +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> In the reconfigure process for mesh interface, moved the
> reconfiguration
> of the mesh peers to be done only after restarting the beacons,
> the same as it is done for AP.
>
> Signed-off-by: Maital Hahn
> Acked-by
Also - your subject lines should explain the *fix*, not the *bug*
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2016-06-27 at 15:23 +0530, Chaitanya TK wrote:
> From: Chaitanya T K
>
> If peer support reception of STBC and LDPC, enable them for better
> performance.
>
Applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord.
> How do you want to proceed? Do you want to
> revert this patch and shall i send another patch?
>
I'll rebase the patch out.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
Hi Dave,
Sorry to be sending a new pull request, but Felix had just submitted a
fairly important fix and I decided I should send it on quickly.
Now thus we have two fixes, one for the mesh refcounting issue and one
for an issue with the ethertype/length field being too long when it's
used as a le
On Thu, 2016-06-30 at 00:08 +0900, Masashi Honma wrote:
[please don't quote everything to add a single line]
> Is there any comment about this ?
>
I applied it today, but forgot to say so. Sorry about that.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
On Sat, 2016-06-25 at 19:14 -0400, Bob Copeland wrote:
> We've accumulated a couple of different fixes now to
> mesh_sta_cleanup()
> due to the different paths that user_mpm and !user_mpm cases take --
> one
> fix to flush nexthop paths and one to fix the counting.
>
> The only caller of mesh_plin
On Wed, 2016-06-29 at 14:00 +0200, Michal Kazior wrote:
> Some lockdep assertions were not fulfilled and
> resulted in a kernel warning/call trace if driver
> used intermediate software queues (e.g. ath10k).
>
> Existing code sequences should've guranteed safety
> but it's always good to be extra
On Thu, 2016-06-30 at 17:49 +0300, Maxim Altshul wrote:
> Adding this opcode, allows the TI wireless driver,
> to report throughput directly from FW to mac80211.
>
> This is used mainly for mesh metric calculation.
>
> Signed-off-by: Maxim Altshul
> ---
> Changed the units of returned value.
> d
> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> @@ -2971,7 +2971,11 @@ static int ath6kl_stop_ap(struct wiphy *wiphy,
> struct net_device *dev)
> return -ENOTCONN;
>
> ath6kl_wmi_disconnect_cmd(ar->wmi, vif->fw_vif_idx);
> +
> + spin_lock_bh(&vif->if_lock);
>
ood way of supporting that, so reject, but
implement the required behaviour in the spec of "Even if the updated
ADDBA Request frame is not accepted, the original Block ACK setup
remains active." (802.11-2012 10.5.4)
Signed-off-by: Johannes Berg
---
net/mac80211/agg-rx.c | 18 ++
On Tue, 2016-07-05 at 13:44 +0530, Purushottam Kushwaha wrote:
> No support for pbss results in a memory leak for the acl_data
> (if parse_acl_data succeeds). Fix this by moving the ACL parsing
> later.
>
Applied, thanks.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux
On Tue, 2016-07-05 at 15:23 +0300, Luca Coelho wrote:
> From: Gregory Greenman
>
> Handle the case when dev_alloc_skb returns NULL.
>
Applied. A Fixes: tag would have been nice, but I added one :)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body
Hi Dave,
People found two more bugs, so I have two more fixes. Both are related to
memory - one's a leak, the other is a missing allocation failure check.
These are both tagged for stable already, and shouldn't conflict with any
other patches, so if they won't go in any more it won't be a big dea
On Thu, 2016-06-30 at 19:51 -0500, Denis Kenzior wrote:
> This patch allows GET_INTERFACE dumps to be filtered based on
> NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV. The documentation for
> GET_INTERFACE mentions that this is possible:
> "Request an interface's configuration; either a dump request on
On Thu, 2016-06-30 at 18:30 +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 algo
On Fri, 2016-07-01 at 10:19 +0900, Masashi Honma wrote:
> Previously, mesh power management functionality works only with
> kernel
> MPM. Because user space MPM did not report mesh peer AID to kernel,
> the kernel could not identify the bit in TIM element. So this patch
> adds mesh peer AID setting
> > It seems to me that it could just use the
> > regular NL80211_ATTR_STA_AID
> > attribute, and the cfg80211 code would already be in place, and
> > you'd
> > just need to add a single line to mac80211 and
> > to cfg80211_check_station_change() to accept that.
>
> We are already using NL80211_A
On Tue, 2016-07-05 at 15:23 +0300, Luca Coelho wrote:
> From: Luca Coelho
>
> Hi Johannes,
>
> These are some cfg80211/mac80211 patches that were pending
> upstreaming
> in our internal tree (I think you know about them ;).
>
Also applied the remaining ones.
johannes
--
To unsubscribe from th
Thanks, applied.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e common cleanup for user/!user_mpm
Dan Carpenter (1):
mac80211: silence an uninitialized variable warning
Ilan Peer (1):
mac80211_hwsim: Add radar bandwidths to the P2P Device combination
Johannes Berg (4):
mac80211: agg-rx: refuse ADDBA Request with timeout update
mac802
On Thu, 2016-07-07 at 02:08 -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 corr
On Fri, 2016-07-08 at 15:58 +0530, Purushottam Kushwaha wrote:
>
> *
> + * @NL80211_ATTR_BEACON_TXRATE: User configurable beacon data rate
> (u32). This is
> + * used to set beacon tx rate.
>
It seems this should be nested from enum nl80211_tx_rate_attributes, to
perhaps allow HT/VHT beacons
On Fri, 2016-07-08 at 16:02 +0530, Purushottam Kushwaha wrote:
> Driver may support different beacon interval on virtual interfaces.
> Allow setting different beacon interval per interface if driver has
> such support.
>
It seems this should be an nl80211 feature flag (ext features)
johannes
--
T
On Fri, 2016-07-08 at 10:22 -0500, Denis Kenzior wrote:
>
> Apologies, I've only been looking at the kernel side for several
> days, so my understanding is still incomplete.
>
> I was looking at mac80211/iface.c: ieee80211_if_add() which seems to
> handle NL80211_IFTYPE_P2P_DEVICE specially by n
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 c
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_
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.
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.
> 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
--
To unsubscribe from this
On Thu, 2016-07-28 at 16:02 +0800, Kai Hendry wrote:
> Hi there,
>
> Since laptops typically have a toggle button for killing and enabled
> wifi, how does one supposed to bind rfkill like a toggle?
>
> I.e. knowing which state you are in so you can call {block,unblock}
> accordingly?
>
> Parsing
> Sure.. First use case will be to help with the problem of legacy
> client devices that roam across multiple APs. It is a classic
> enterprise Wi-Fi AP problem, often managed by a "network controller"
> unit that is connected to all the APs.
> The problem is how to handle seamless handoff of cl
> >
> > > + /* bus private data */
> > > + char bus_priv[0];
> > You might want to - for future proofing - add some aligned()
> > attribute.
> > Otherwise, if struct mutex doesn't have a size that's a multiple of
> > the
> > pointer size, fields in here will not be aligned right.
>
> Right, than
On Wed, 2016-07-13 at 14:44 +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> Some drivers (e.g. wl18xx) expect that the last stage in the
> de-initialization process will be stopping the beacons, similar to AP
> flow.
> Update ieee80211_stop_mesh() flow accordingly.
> As peers can be removed d
On Fri, 2016-07-22 at 15:12 +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.
>
My earlier comment regardin
On Wed, 2016-07-13 at 10:11 +, Machani, Yaniv wrote:
> On Wed, Jun 29, 2016 at 10:14:19, Johannes Berg wrote:
> > Cc: Hahn, Maital
> > Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before
> > beacons
> > are stopped
> >
> > On Tue, 2016-06
801 - 900 of 4576 matches
Mail list logo
