On Thu, 2019-08-29 at 14:49 -0700, Amar Singhal wrote:
> Add new helper function to convert (chan_number, oper_class) pair to
> frequency. Call this function ieee80211_channel_op_class_to_frequency.
> This function would be very useful in the context of 6 GHz channels,
> where channel number is not
On Thu, 2019-08-29 at 14:04 -0300, Ramon Fontes wrote:
> Yes, that's what I (we?) expect.
>
> Yes, wmediumd has some log files, but they don't help me to identify
> the reason of the problem. I also unsuccessfully tried to modified the
> wmediumd code. Both wmediumd and mac80211_hwsim work fine up
Hi Dave,
We have just three more fixes now, and one of those is a driver fix
because Kalle is on vacation and I'm covering for him in the meantime.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 189308d5823a089b56e2299cd96589507dac7319:
Hi,
> When I use 2.4Ghz band with -only one- AP (running on top of hostapd)
> I get a (additional) list of frequencies at 5Ghz. When I do "iw dev ..
> scan"
>
> BSS 02:00:00:00:04:00(on sta1-wlan0) -- associated
> TSF: 1566905272877856 usec (18135d, 11:27:52)
> freq: 2422
> beacon interval: 100 T
On Wed, 2019-08-28 at 22:36 +0200, Johannes Berg wrote:
> First of all, the subject doesn't make a lot of sense?
Ah, the whole thing is called under that function I guess, never mind
johannes
First of all, the subject doesn't make a lot of sense?
Secondly, for a fix the code is fine I guess, but:
> rate_ie = (void *)cfg80211_find_ie(WLAN_EID_EXT_SUPP_RATES,
> params->beacon.tail,
> params->beacon.
On Wed, 2019-08-28 at 22:24 +0200, Marcel Holtmann wrote:
> Hi Johannes,
>
> > > > No, as usual, that would break ABI. PAD is a regular attribute, just
> > > > empty and ignored for aligning 64-bit values.
> > >
> > > then I do not grok on how the nla_put_u64_64bit works, but that is
> > > fine.
Hi Marcel,
> > No, as usual, that would break ABI. PAD is a regular attribute, just
> > empty and ignored for aligning 64-bit values.
>
> then I do not grok on how the nla_put_u64_64bit works, but that is
> fine.
>
> I assumed these are similar to the NL80211_SURVEY_INFO_MAX which we
> also alwa
Hi Marcel,
> ... [snip]
Please trim quotes a bit.
> > NL80211_SURVEY_INFO_PAD,
> > + NL80211_SURVEY_INFO_TIME_BSS_RX,
>
> wouldn’t this go before the PAD attribute?
No, as usual, that would break ABI. PAD is a regular attribute, just
empty and ignored for aligning 64-bit values.
johanne
On Tue, 2019-08-27 at 15:08 +0200, Sebastian Gottschall wrote:
> Am 22.08.2019 um 23:06 schrieb Josef Miegl:
> > On August 22, 2019 10:08:13 PM GMT+02:00, Johannes Berg
> > wrote:
> > > On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
> > > > Perhaps i
> Works great. Is there a possibility that a toggle for this could be
> accepted upstream? After all, WDS isn't really standardized.
I general, I'd say yes. However!
There's ongoing to work to make EAPOL frames go over nl80211 instead,
see e.g. ieee80211_tx_control_port() in mac80211, and this
On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>
> Perhaps it expects the 4-way-HS to already be in 4-addr frame format, or
> something else special in the 4-way-HS if you have WDS?
I think this is actually the right guess.
The working capture you sent me has the EAPOL 2/4 in
From: Johannes Berg
Various changes in the commit mentioned below broke
compatibility with python2. Restore it in a way that
makes it worth with both versions.
Fixes: f3c4969c2485 ("wireless-regdb: make scripts compatible with Python 3")
Signed-off-by: Johannes Berg
---
db2b
On Wed, 2019-08-21 at 23:17 +0200, Josef Miegl wrote:
> On August 21, 2019 10:12:26 PM GMT+02:00, Johannes Berg
> wrote:
> > What AP are you trying to connect to? Have you tried adding some other
> > random vendor IE, with an OUI that the AP is almost certain to not
> &
On Thu, 2019-08-22 at 01:57 +0200, Josef Miegl wrote:
> On August 20, 2019 2:36:21 PM GMT+02:00, Sebastian Gottschall
> wrote:
> > i know. thats why i never even tried to contribute it upstream. but
> > from
> > hostapd side it was more complicated than just hacking mac80211
> > and from station
On Wed, 2019-08-21 at 22:04 +0200, Josef Miegl wrote:
>
> The vendor elements are added at the very end of the frame. In fact I
> tried moving the RSN IE to the end of the frame so that the frame is
> similar to the one ubnt airos produces. No luck either. One thing I've
> learned is that ubnt air
Hi Dave,
For -next, we have more changes, but as described in the tag
they really just fall into a few groups of changes :-)
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8c40f3b212a373be843a29db608b462af5c3ed5d:
Merge tag 'mlx5-upd
n an error path
Alexander Wetzel (1):
cfg80211: Fix Extended Key ID key install checks
Hodaszi, Robert (1):
Revert "cfg80211: fix processing world regdomain when non modular"
Johannes Berg (1):
mac80211: fix possible sta leak
net/mac80211/cfg.c | 9
On Wed, 2019-08-21 at 14:59 +0530, Vasanthakumar Thiagarajan wrote:
> > > +#define ATH11K_TX_RING_MASK_3 0x0
> >
> > You have a LOT of masks here that are 0, that seems odd?
>
> We'll remove them.
I'm not sure you should just *remove* them, that might very well be
valid and what you need here,
On Wed, 2019-04-03 at 14:02 -0700, Brian Norris wrote:
> + Johannes
>
> On Thu, Oct 04, 2018 at 12:06:50PM -0700, Matthew Wang wrote:
> > Hi,
> >
> > I'm wondering if there is a flag for detecting firmware/driver support
> > for FT. It seems like checking for SME support is a pretty good proxy
>
On Sat, 2019-08-10 at 10:28 +, Guo Wei Lim wrote:
> Hi Johannes,
>
> Correct me if I am wrong.
> The problem is largely in net/mac80211/mesh_hwmp.c
> The macros
> #define PREQ_IE_ORIG_ADDR(x) (x + 7)
> #define PREP_IE_TARGET_ADDR(x) (x + 3)
>
> Almost guarantees the addresses will be odd when
On Tue, 2019-08-20 at 23:50 +0300, Jouni Malinen wrote:
> > Without really looking at the specifics, it might be relatively simple
> > to support this in mac80211?
>
> Yes, that is something that I was thinking about when going through
> this.. I don't remember why exactly mac80211 ended up with
On Thu, 2019-08-15 at 16:38 +0300, Jouni Malinen wrote:
> +/**
> + * DOC: VLAN offload support for setting group keys and binding STAs to VLANs
> + *
> + * By setting @NL80211_EXT_FEATURE_VLAN_OFFLOAD flag drivers can indicate
> they
> + * support offloading VLAN functionality in a manner where t
On Tue, 2019-08-20 at 16:52 -0500, Denis Kenzior wrote:
> I'm not sure you can state that definitively just yet?
That's not an argument, you also cannot state definitively that it will
not happen. But yes, I'd think it _is_ in fact likely to happen at some
point for something new, maybe it won'
On Wed, 2019-08-21 at 03:03 +0530, Balakrishna Bandi wrote:
> AP sends deauth per each data frame to STA which is not associated to
> AP. Non associated STA keeps on sending data frame and leads to deauth
> flooding.
Yeah. I've sort of vaguely known about this issue, but never got around
to it. Th
On Tue, 2019-08-20 at 18:47 +0300, Kalle Valo wrote:
> +static int ath11k_mac_op_config(struct ieee80211_hw *hw, u32 changed)
> +{
> + struct ath11k *ar = hw->priv;
> + int ret = 0;
> +
> + /* mac80211 requires this op to be present and that's why
> + * there's an empty function,
> +module_param_named(debug_mask, ath11k_debug_mask, uint, 0644);
> +
> +MODULE_PARM_DESC(debug_mask, "Debugging mask");
> +
> +static const struct ath11k_hw_params ath11k_hw_params = {
> + .name = "ipq8074",
indentation here seems a bit too much
> +MODULE_LICENSE("Dual BSD/
On Tue, 2019-08-20 at 18:48 +0300, Kalle Valo wrote:
>
> +enum wmi_cmd_group {
> + /* 0 to 2 are reserved */
> + WMI_GRP_START = 0x3,
> + WMI_GRP_SCAN = WMI_GRP_START, /* 0x3 */
> + WMI_GRP_PDEV, /* 0x4 */
If you're going to spell out the numbers anyway, why not do it in
On Tue, 2019-08-20 at 18:47 +0300, Kalle Valo wrote:
> +static const struct ce_attr host_ce_config_wlan[] = {
> + /* CE0: host->target HTC control and raw streams */
> + {
> + .flags = CE_ATTR_FLAGS,
> + .src_nentries = 16,
> + .src_sz_max = 2048,
> +
On Tue, 2019-08-20 at 14:58 -0500, Denis Kenzior wrote:
>
> But what actual complexity are we talking about here? If the kernel can
> do this while the CONNECT is pending, why not? It makes things simpler
> and faster for userspace. I don't see the downside unless you can
> somehow objectivel
On Tue, 2019-08-20 at 15:53 -0400, James Prestwood wrote:
> > I thought so, but I had another thought later. It might be possible
> > to
> > set LIVE_ADDR_CHANGE, but then block it in mac80211 when the
> > interface
> > is already connected (or beaconing, or whatever, using the MAC
> > address
> >
On Tue, 2019-08-20 at 18:47 +0300, Kalle Valo wrote:
>
> +static const struct service_to_pipe target_service_to_ce_map_wlan[] = {
> + {
> + __cpu_to_le32(ATH11K_HTC_SVC_ID_WMI_DATA_VO),
> + __cpu_to_le32(PIPEDIR_OUT), /* out = UL = host -> target */
> +
Hi,
> So let me ask you this. What do you _want_ to see when a contributor
> submits something as an RFC, which that contributor states is not ready
> for 'true' review and is really there to generate feedback?
>
> Do you want to have that contributor use a different prefix? Every
> maintaine
On Tue, 2019-08-20 at 14:22 -0500, Denis Kenzior wrote:
> Hi Johannes,
>
> So keeping things purely technical now :)
>
> > I thought so, but I had another thought later. It might be possible to
> > set LIVE_ADDR_CHANGE, but then block it in mac80211 when the interface
> > is already connected (or
Hi Denis,
Rather than replying to all the separate items here, just two things:
1) I'll reiterate - please keep things civil. You're taking things out
of context a *lot* here, in what seems like an attempt to draw a
parallel between my and your utterances.
2) I'll take your point that I've
On Tue, 2019-08-20 at 13:53 +0200, Sebastian Gottschall wrote:
> i was talking about a different scenario. its not about adding a
> element, but to read it back for gui for instance. this is why i made a
> patch which parses this special ie
> and adds the radioname as extra element to the statio
On Mon, 2019-08-19 at 15:58 -0500, Denis Kenzior wrote:
> Hi Johannes,
[...]
> Hmm... I sense a pattern of you not seeing a point in doing many
> things... Do you actually use the stuff you maintain?
[...]
> Well, one possible use case might be, oh something like this:
>
> https://source.andr
Hi,
> You are thinking about keeping the tx API untouched and modify the key
> install logic?
> Just prevent the firmware to activate a key for Tx when it's installed
> and notify the firmware by some means when the key can be used for Tx
> and then switch everything to the new key?
Something
Hi James,
Thanks for staying on topic.
> > I don't, short of
> >
> > 1) don't do that then
> > 2) extend the network stack to have
> > IFF_LIVE_BUT_NO_CARRIER_ADDR_CHANGE
> >or something like that
>
> So you mean 2 is my only option... ;) I am fine with this.
:-)
I thought so, but I had a
On Mon, 2019-08-19 at 17:52 +0200, Alexander Wetzel wrote:
> We may also get away by adding only means to pass the keyid of the MPDU
> (zero or one) to the HW. That could be done quite simple, I think:
>
> We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and
> IWL_TX_FLAGS_ENCRYPT_ID_
On Mon, 2019-08-19 at 13:37 +0200, Josef Miegl wrote:
> On Mon, Aug 19, 2019 at 12:12:43PM +0200, Johannes Berg wrote:
> > Contrary to what Sebastian states, it certainly is possible today,
> > although not through wpa_supplicant's config file, only through the
> > wp
Hi James,
> > It actually seems wrong to set IFF_LIVE_ADDR_CHANGE at all, because
> > you
> > don't actually support that - you only support setting it while not
> > connected?
>
> You are right, we only care about setting the MAC while not connected.
> But, the eth_ API's that set the MAC are co
On Mon, 2019-08-19 at 22:03 +0200, Johannes Berg wrote:
>
> > While less desirable we still could get that working: The mvm driver
> > would have to detect the key borders and then tell the firmware to
> > switch over to the other key. But we would have to make sure to not
On Mon, 2019-08-19 at 21:57 +0200, Alexander Wetzel wrote:
> > > +
> > > + /* The new Tx API does not allow to pass the key or keyid of a MPDU to
> > > + * the hw, preventing us to control which key(id) to use per MPDU.
> > > + * Till that's fixed we can't use Extended Key ID for the newer cards.
On Mon, 2019-08-19 at 20:05 +0200, Alexander Wetzel wrote:
> All iwlwifi cards below the 22000 series are able to handle multiple
> keyids per STA and allow the selection of the encryption key per MPDU.
>
> These are therefore fully compatible with the Extended Key ID support
> implementation in m
On Thu, 2019-08-15 at 16:38 +0300, Jouni Malinen wrote:
> From: Gurumoorthi Gnanasambandhan
>
> This provides an alternative mechanism for AP VLAN support where a
> single netdev is used with VLAN tagged frames instead of separate
> netdevs for each VLAN without tagged frames from the WLAN driver
On Thu, 2019-08-15 at 11:57 -0700, James Prestwood wrote:
> This is an example of how a devices MAC address could be changed while
> the interface is up. Currently RTNL and mac80211 both require the
> interface be down before changing the MAC.
>
> After poking around a bit I found that some driver
On Fri, 2019-08-16 at 13:38 +0200, Josef Miegl wrote:
> On Fri, Aug 16, 2019 at 01:15:30PM +0200, Sebastian Gottschall wrote:
> > in station mode you are right. you need to modify mac80211.
> Even if I don't need to capture the IE back? All I want is to include
> extra vendor IE in client assoc/rea
On Sat, 2019-08-17 at 10:31 +0200, Alexander Wetzel wrote:
> > All iwlwifi cards are able to handle multiple keyids per STA and are
> > therefore fully compatible with the Extended Key ID implementation
> > provided by mac80211.
>
> I just tried Extended Key ID with a AX200 card and it really look
On August 10, 2019 6:07:15 AM GMT+02:00, Guo Wei Lim
wrote:
>I have traced a large number of unaligned memory access on mips cpu
>due to ether_addr_equal(), is_multicast_ether_addr(),
>is_broadcast_ether_addr() being called on odd addresses.
>
>Even though the values are u8, the inlines in eth
On Mon, 2019-08-05 at 18:20 +0300, Dedy Lansky wrote:
> > Then, we can restrict the RTNL to a few cases where we add or
> > remove interfaces and really need the added protection. Some
> > of the global list management still also uses the RTNL, since
> > we need to have it anyway for netdev manage
On Thu, 2019-08-01 at 16:15 +0300, Alexei Lazar wrote:
> On 2019-07-26 16:29, Johannes Berg wrote:
> > Hi Alexei,
> >
> > I'm not exactly sure why, but this breaks practically all connectivity
> > on 2.4 and 5 GHz channels (at least in hwsim tests).
> >
>
Hi Marcel,
> > Also, I don't really buy the *need* for this since you're just removing
> > a few kernel/user roundtrips here when new devices are discovered, a
> > rare event. The parsing isn't really any more complicated for the
> > userspace side.
>
> that is an argument that is coming to bite
On Thu, 2019-08-01 at 02:14 -0500, Denis Kenzior wrote:
> + /*
> + * auto-detect support for large buffer sizes: af_netlink
> + * will allocate skbufs larger than 4096 in cases where
> + * it detects that the client receive buffer (given to
> +
From: Johannes Berg
If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is
not associated to AP")
Signed-off-by: Johannes Berg
---
net
x27;__compiletime_assert_2801' declared with attribute error:
BUILD_BUG_ON failed: invalid_ap_str[sizeof(invalid_ap_str) - 2] != '\n'
Fixes: 427ab6385cf3 ("iwlwifi: dbg_ini: enforce apply point early on buffer
allocation tlv")
Fixes: 57d88b116175 ("iwlwifi: dbg_ini: sup
From: Johannes Berg
Currently, _everything_ in cfg80211 holds the RTNL, and if you
have a slow USB device (or a few) you can get some bad lock
contention on that.
Fix that by re-adding a mutex to each wiphy/rdev as we had at
some point, so we have locking for the wireless_dev lists and
all the
context
Greg Kroah-Hartman (4):
iwlwifi: dvm: no need to check return value of debugfs_create functions
iwlwifi: mvm: remove unused .remove_sta_debugfs callback
mac80211: remove unused and unneeded remove_sta_debugfs callback
cfg80211: no need to check return value of debu
#x27;t WARN on short WMM parameters from AP
Jia-Ju Bai (1):
mac80211_hwsim: Fix possible null-pointer dereferences in
hwsim_dump_radio_nl()
Johannes Berg (1):
Revert "mac80211: set NETIF_F_LLTX when using intermediate tx queues"
Manikanta Pubbisetty (1):
{nl,mac}80211:
Hi,
Just a few things, mostly questions I guess.
> Certain features wont work and the patch masks these out.
> * monitor interfaces are not supported if any of the vif is in encap mode.
> Signed-off-by: Vasanthakumar Thiagarajan
> Signed-off-by: John Crispin
>
> Signed-off-by: John Crispin
On Wed, 2019-07-31 at 10:12 +, Shay Bar wrote:
> Hi Johannes,
> Station may receive a beacon from the AP that will rearm the bcn_mon_timer.
> If it will not get a beacon within the timeout, it will disconnect.
> In my test case, beacon arrived later (within the timeout).
> Without this patch, S
On Mon, 2019-07-01 at 10:33 -0500, Denis Kenzior wrote:
> If the wdev object has been created (via NEW_INTERFACE) with
> SOCKET_OWNER attribute set, then limit certain commands only to the
> process that created that wdev.
>
> This can be used to make sure no other process on the system interferes
On Wed, 2019-07-03 at 16:18 +0300, Shay Bar wrote:
> In case of HE AP-STA link, ieee80211_send_nullfunc() will not send the QOS
> NULL packet to check if AP is still associated.
> In this case, probe_send_count will be non zero and ieee80211_sta_work() will
> later disassociate the AP.
> (althoug
e out-of-bounds read when accessing lq_info
Ihab Zhaika (1):
iwlwifi: add 3 new IDs for the 9000 series (iwl9260_2ac_160_cfg)
Johannes Berg (2):
iwlwifi: mvm: disable TX-AMSDU on older NICs
iwlwifi: fix locking in delayed GTK setting
Luca Coelho (2):
iwlwifi:
From: Johannes Berg
Revert this for now, it has been reported multiple times that it
completely breaks connectivity on various devices.
Cc: sta...@vger.kernel.org
Fixes: 8dbb000ee73b ("mac80211: set NETIF_F_LLTX when using intermediate tx
queues")
Reported-by: Jean Delvare
Reported
From: Johannes Berg
Give a proper boottime_ns value for netlink RX to avoid scan
issues here.
Signed-off-by: Johannes Berg
---
drivers/net/wireless/mac80211_hwsim.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless
Hi,
> I noticed that the other patches in this series got applied. Was this
> one left out on purpose?
Yeah, I left out a few that I wanted to review more carefully.
I'll get to it this week (because I'm on vacation after that).
johannes
From: Johannes Berg
Over time, we really need to get rid of all of our global locking.
One of the things needed is to use parallel_ops. This isn't really
the most important (RTNL is much more important) but OTOH we just
keep adding uses of genl_family_attrbuf() now. Use .parallel_ops to
dis
Hi Denis,
(huh, why did your mail make it to my inbox 3 hours ago ...? oh well)
> > + kfree(attrbuf);
> > + if (IS_ERR(*wdev)) {
> > + kfree(attrbuf);
>
> Hmm, you just freed attrbuf above?
Good catch.
I was being stupid, wrote the patch on one machine, th
From: Johannes Berg
Over time, we really need to get rid of all of our global locking.
One of the things needed is to use parallel_ops. This isn't really
the most important (RTNL is much more important) but OTOH we just
keep adding uses of genl_family_attrbuf() now. Use .parallel_ops to
dis
On Fri, 2019-07-26 at 19:36 +0530, Karthikeyan Periyasamy wrote:
> > > Don't allow using a zero MAC address as the station
> > > MAC address. so validated the MAC address using
> > > is_valid_ether_addr.
> >
> > Theoretically, all zeroes might have been a valid address at some
> > point.
> > I se
On Fri, 2019-07-26 at 15:31 +0200, Sven Eckelmann wrote:
> As I already wrote:
>
> > The first three things looks like wpa_supplicant problems. Seems to be
> > caused by the way HE forces VHT to be enabled and now the tests fail
> > which try to disable VHT. There was already a patch [0] for th
Hi Alexei,
I'm not exactly sure why, but this breaks practically all connectivity
on 2.4 and 5 GHz channels (at least in hwsim tests).
Please check and resubmit.
It'd also be good to reformat the commit log a bit, maybe adding
paragraphs, it's a bit of a "wall of text".
Thanks,
johannes
On Wed, 2019-07-24 at 18:33 +0200, Sven Eckelmann wrote:
> From: Sven Eckelmann
>
> Some features of 802.11ax without central organizing (AP) STA can also be
> used in mesh mode. hwsim can be used to assist initial development of these
> features without having access to HW.
>
> Signed-off-by: S
Umm, regarding multi-BSSID, I'm clearly just not paying any attention
... sorry about that.
This looks good to me, can you resend as just PATCH?
Thanks,
johannes
Hi Sergey,
> Yes, this is the use-case that I tried to address in the last revision
> of the patch.
OK! I didn't see it here and I guess I didn't look at the latest version
yet, or I missed it.
> If you take a look at the top of new cfg80211_update_assoc_bss_entry
> function:
>
> + /* use
On Tue, 2019-06-18 at 08:19 +0200, John Crispin wrote:
> Store the OBSS PD parameters inside bss_conf when bringing up an AP and/or
> when a station connects to an AP. This allows the driver to configure the
> HW accordingly.
>
> Signed-off-by: Shashidhar Lakkavalli
> Signed-off-by: John Crispin
Hi,
Apologies for the late review.
I've applied patch 1, but not this one yet:
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_2 0x10
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_3 0x18
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK 0x18
>
On Wed, 2019-07-24 at 14:46 +0530, Karthikeyan Periyasamy wrote:
> Don't allow using a zero MAC address as the station
> MAC address. so validated the MAC address using
> is_valid_ether_addr.
Theoretically, all zeroes might have been a valid address at some point.
I see no reason not to reject it,
Hi Sergey,
Sorry for dropping the ball on this thread.
> > Right, it will be updated on RX. But then if we chanswitch, we would
> > probably (mac80211 using a pointer to the non-transmitting BSS) update
> > only one of the nontransmitting BSSes?
> >
> > Just saying that maybe we need to be caref
On Thu, 2019-07-25 at 13:04 -0700, Bill Unruh wrote:
> The output of iw .. scan output for Ad-Hoc (IBSS) does not have a carriage
> return running it into the next access point output
>
>
> BSS f6:63:9f:d1:f9:17(on wlp58s0)
> TSF: 0 usec (0d, 00:00:00)
> freq: 2437
> be
[trimming CCs a bit]
> > so I am not in favor of this solution. The hardware guys should start
> > looking into fixing the firmware loading and provide proper firmware that
> > can be loaded at the same time.
>
> Of course it’s much better to fix from hardware side.
I tried to ask around a b
the 9000 series (iwl9260_2ac_160_cfg)
Johannes Berg (2):
iwlwifi: mvm: disable TX-AMSDU on older NICs
iwlwifi: fix locking in delayed GTK setting
Luca Coelho (2):
iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41
iwlwifi: mvm: fix version check for GEO_TX_POWER_L
On Wed, 2019-07-24 at 15:40 +0200, Arend Van Spriel wrote:
>
> > > The only place I could find an
> > > issue with this is in cfg80211_wext_freq(). Not sure how to deal with
> > > that so it is not part of this series.
> >
> > Just finally break wext and say if you want to use 6 GHz you need to u
Hi Arend,
After all the discussion, I think we want this? Care to resend?
I think I want it at least because we shouldn't advertise HT/VHT on 6
GHz as is (just as part of HE) and that's easier if we have a different
band enum, for the capability storage...
> The only place I could find an
> issu
. Fix this.
Cc: sta...@vger.kernel.org
Fixes: 3cd1980b0cdf ("iwlwifi: pcie: introduce new tfd and tb formats")
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
---
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ne
)
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index a3e5d88f1c07..6ac1
.
Cc: sta...@vger.kernel.org
Fixes: 6996490501ed ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI
table")
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Johannes Berg
---
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Kalle,
As discussed, I have a few more fixes, I'll include them in the pull
request that Luca had already sent a number of patches for.
johannes
On Mon, 2019-07-22 at 22:20 +, John Stultz wrote:
> Hey folks,
>
> Testing on my HiKey960, I'm seeing:
> [8.894909] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
> [8.902017] [ cut here ]
> [8.906832] WARNING: CPU: 0 PID: 5 at net/wireless/core.c:868
>
On Fri, 2019-07-19 at 00:50 +0200, Lorenzo Bianconi wrote:
> Convert MT7603_WATCHDOG_TIME in jiffies rescheduling watchdog delayed
> work
Seems a bit inconsistent to me, the previous patch for mt7615 used
jiffies in the define, but here you convert?
johannes
with the new netlink vendor
command policy requirement
* fix a memory leak in an error path when setting beacons
Brian Norris (1):
mac80211: don't warn about CW params when not using them
Johannes Berg (2):
wir
On Wed, 2019-07-17 at 11:22 +0200, Yegor Yefremov wrote:
> On Fri, Jun 28, 2019 at 3:58 PM Johannes Berg
> wrote:
> > On Mon, 2019-06-24 at 22:32 +0200, Yegor Yefremov wrote:
> > > I have asked SPDX and this is their answer:
> > > https://lists.spdx.org/g/Spdx-legal
On Sat, 2019-07-13 at 17:03 +0200, Lorenzo Bianconi wrote:
> Add IEEE80211_KEY_FLAG_PUT_MMIE_SPACE flag to ieee80211_key_flags in order
> to allow the driver to notify mac80211 to allocate mmie space for AES_CMAC
> hw cipher. Moreover mac80211 will set MMIE pn while MIC will be computed
> in hw.
H
On Fri, 2019-07-12 at 15:16 +, Igor Mitsyanko wrote:
> On 7/12/19 1:40 PM, Arend Van Spriel wrote:
> >
> >
> > The inclusion of the "HE extended capabilities" element is determined by
> > the dot116GOptionImplemented option. (band[6G] != NULL) provides that
> > condition although there are
On Fri, 2019-07-12 at 11:36 +0200, Sven Eckelmann wrote:
>
> There is already a workaround for that in the hostap testcases:
>
> if all_cap_one:
> # It looks like tshark parser was broken at some point for
> # wlan.mesh.config.cap which is now (tshark 2.6.3) pointing to
> inc
On Fri, 2019-07-12 at 09:27 +, Sergey Matyukevich wrote:
> On Fri, Jul 12, 2019 at 11:11:19AM +0200, Johannes Berg wrote:
> >
> > [External Email]: This email arrived from an external source - Please
> > exercise caution when opening any attachments or clicking on links.
On Thu, 2019-07-11 at 13:30 +0200, Arend Van Spriel wrote:
>
> I assume user-space does not necessarily need the band, but hostapd
> needs to be aware that it is operating in 6GHz to setup the correct
> (information) elements in the beacon. Obviously the operating classes
> can be used there, b
On Wed, 2019-07-10 at 17:37 +, Sergey Matyukevich wrote:
> This patch implements minor refactoring for cfg80211_bss_update function.
> Code path for updating known BSS is extracted into dedicated
> cfg80211_update_known_bss function.
>
Looks good, thanks for splitting this out.
I'm not going
> Suggested approach to handle non-transmitting BSS entries is simplified in the
> following sense. If new entries have been already created after channel
> switch,
> only transmitting bss will be updated using IEs of new entry for the same
> transmitting bss. Non-transmitting bss entries will be
101 - 200 of 4576 matches
Mail list logo
