* Issue with intel wireless-AC 9260 in wifi direct in 5Ghz
From: Equipe Soft @ 2019-08-28 17:21 UTC (permalink / raw)
To: linux-wireless
Hello,
I'm trying to set up a wifi direct group between my AC9260 wifi board
and a android tablet supporting WifiDirect.
I tried several configurations and I faced some issues.
Here follow the testing sequence. All the following command are sent
through wpa_cli:
> p2p_find
P2P-DEVICE-FOUND f2:ee:10:c2:ce:68 p2p_dev_addr=f2:ee:10:c2:ce:68
pri_dev_type=10-0050F204-5 name='[Tablet] Galaxy Tab S3'
config_methods=0x188 dev_capab=0x25 group_capab=0x0 vendor_elems=1
new=1
>p2p_connect f2:ee:10:c2:ce:68 pin 1234 go_intent=1
74493685
PIN is set on the tablet then, on my terminal I see:
P2P-GO-NEG-SUCCESS role=GO freq=5785 ht40=0 peer_dev=f2:ee:10:c2:ce:68
peer_iface=f2:ee:10:c2:4e:68 wps_method=Display
P2P-GROUP-FORMATION-FAILURE
P2P-GROUP-REMOVED p2p-wlan0-0 GO reason=FORMATION_FAILED
dmesg :
[ 1875.593069] IPv6: ADDRCONF(NETDEV_UP): p2p-wlan0-0: link is not ready
[ 1875.659199] iwlwifi 0000:01:00.0: Microcode SW error detected.
Restarting 0x2000000.
[ 1875.667246] iwlwifi 0000:01:00.0: Start IWL Error Log Dump:
[ 1875.672851] iwlwifi 0000:01:00.0: Status: 0x00000100, count: 6
[ 1875.678718] iwlwifi 0000:01:00.0: Loaded firmware version: 38.755cfdd8.0
[ 1875.685466] iwlwifi 0000:01:00.0: 0x000014FC | ADVANCED_SYSASSERT
[ 1875.692498] iwlwifi 0000:01:00.0: 0x00A0A200 | trm_hw_status0
[ 1875.698270] iwlwifi 0000:01:00.0: 0x00000000 | trm_hw_status1
[ 1875.704048] iwlwifi 0000:01:00.0: 0x00454EF6 | branchlink2
[ 1875.709561] iwlwifi 0000:01:00.0: 0x0045E90E | interruptlink1
[ 1875.715330] iwlwifi 0000:01:00.0: 0x00000000 | interruptlink2
[ 1875.721096] iwlwifi 0000:01:00.0: 0x00009D00 | data1
[ 1875.726084] iwlwifi 0000:01:00.0: 0x00000741 | data2
[ 1875.731070] iwlwifi 0000:01:00.0: 0x00090010 | data3
[ 1875.736076] iwlwifi 0000:01:00.0: 0x00000000 | beacon time
[ 1875.741589] iwlwifi 0000:01:00.0: 0x6F091C80 | tsf low
[ 1875.746757] iwlwifi 0000:01:00.0: 0x00000000 | tsf hi
[ 1875.751833] iwlwifi 0000:01:00.0: 0x00000000 | time gp1
[ 1875.757081] iwlwifi 0000:01:00.0: 0x6F091C81 | time gp2
[ 1875.762325] iwlwifi 0000:01:00.0: 0x00000001 | uCode revision type
[ 1875.768529] iwlwifi 0000:01:00.0: 0x00000026 | uCode version major
[ 1875.774731] iwlwifi 0000:01:00.0: 0x755CFDD8 | uCode version minor
[ 1875.780934] iwlwifi 0000:01:00.0: 0x00000321 | hw version
[ 1875.786352] iwlwifi 0000:01:00.0: 0x00C89004 | board version
[ 1875.792044] iwlwifi 0000:01:00.0: 0x801BF402 | hcmd
[ 1875.796951] iwlwifi 0000:01:00.0: 0x24022000 | isr0
[ 1875.801853] iwlwifi 0000:01:00.0: 0x01000000 | isr1
[ 1875.806751] iwlwifi 0000:01:00.0: 0x08301802 | isr2
[ 1875.811653] iwlwifi 0000:01:00.0: 0x00415CC0 | isr3
[ 1875.816559] iwlwifi 0000:01:00.0: 0x00000000 | isr4
[ 1875.821462] iwlwifi 0000:01:00.0: 0x000501D1 | last cmd Id
[ 1875.826975] iwlwifi 0000:01:00.0: 0x00000000 | wait_event
[ 1875.832399] iwlwifi 0000:01:00.0: 0x000000D0 | l2p_control
[ 1875.837928] iwlwifi 0000:01:00.0: 0x00018014 | l2p_duration
[ 1875.843527] iwlwifi 0000:01:00.0: 0x0000003F | l2p_mhvalid
[ 1875.849040] iwlwifi 0000:01:00.0: 0x00000000 | l2p_addr_match
[ 1875.854811] iwlwifi 0000:01:00.0: 0x0000000D | lmpm_pmg_sel
[ 1875.860412] iwlwifi 0000:01:00.0: 0x04071046 | timestamp
[ 1875.865758] iwlwifi 0000:01:00.0: 0x0000C0E4 | flow_handler
[ 1875.871405] iwlwifi 0000:01:00.0: Start IWL Error Log Dump:
[ 1875.877037] iwlwifi 0000:01:00.0: Status: 0x00000100, count: 7
[ 1875.882889] iwlwifi 0000:01:00.0: 0x00000070 | ADVANCED_SYSASSERT
[ 1875.889020] iwlwifi 0000:01:00.0: 0x00000000 | umac branchlink1
[ 1875.894959] iwlwifi 0000:01:00.0: 0xC0087CB8 | umac branchlink2
[ 1875.900904] iwlwifi 0000:01:00.0: 0xC0084264 | umac interruptlink1
[ 1875.907134] iwlwifi 0000:01:00.0: 0xC00847C8 | umac interruptlink2
[ 1875.913344] iwlwifi 0000:01:00.0: 0x00000800 | umac data1
[ 1875.918764] iwlwifi 0000:01:00.0: 0xC00847C8 | umac data2
[ 1875.924184] iwlwifi 0000:01:00.0: 0xDEADBEEF | umac data3
[ 1875.929606] iwlwifi 0000:01:00.0: 0x00000026 | umac major
[ 1875.935026] iwlwifi 0000:01:00.0: 0x755CFDD8 | umac minor
[ 1875.940448] iwlwifi 0000:01:00.0: 0xC0887F30 | frame pointer
[ 1875.946128] iwlwifi 0000:01:00.0: 0xC0887F30 | stack pointer
[ 1875.951810] iwlwifi 0000:01:00.0: 0x0006012B | last host cmd
[ 1875.957488] iwlwifi 0000:01:00.0: 0x00000000 | isr status reg
[ 1875.963268] ieee80211 phy0: Hardware restart was requested
[ 1875.968932] iwlwifi 0000:01:00.0: iwlwifi transaction failed,
dumping registers
[ 1875.976275] iwlwifi 0000:01:00.0: iwlwifi device config registers:
[ 1875.983647] iwlwifi 0000:01:00.0: 00000000: 25268086 00100406
02800029 00000000 e0000004 00000000 00000000 00000000
[ 1875.994312] iwlwifi 0000:01:00.0: 00000020: 00000000 00000000
00000000 00148086 00000000 000000c8 00000000 0000012b
[ 1876.004835] iwlwifi 0000:01:00.0: iwlwifi device memory mapped registers:
[ 1876.011780] iwlwifi 0000:01:00.0: 00000000: 00c89004 00000040
00000000 ba00008b 00000000 00000000 00027e1f 00000000
[ 1876.022251] iwlwifi 0000:01:00.0: 00000020: 00000000 0c040005
00000321 d55555d5 d55555d5 d55555d5 80008040 041f0044
[ 1876.032714] iwlwifi 0000:01:00.0: iwlwifi device AER capability structure:
[ 1876.039694] iwlwifi 0000:01:00.0: 00000000: 14c10001 00000000
00000000 00462031 00000000 00002000 00000000 00000000
[ 1876.050219] iwlwifi 0000:01:00.0: 00000020: 00000000 00000000 00000000
[ 1876.056838] iwlwifi 0000:01:00.0: iwlwifi parent port
(0000:00:00.0) config registers:
[ 1876.064933] iwlwifi 0000:00:00.0: 00000000: d02110ee 00100006
06040000 00010000 00000000 00000000 000c0100 00000000
[ 1876.075399] iwlwifi 0000:00:00.0: 00000020: e000e000 0001fff1
00000000 00000000 00000000 00000040 00000000 0000012b
[ 1876.085869] iwlwifi 0000:01:00.0: FW error in SYNC CMD BINDING_CONTEXT_CMD
[ 1876.092773] CPU: 1 PID: 498 Comm: wpa_supplicant Not tainted
4.18.31-yocto-standard #1
[ 1876.100680] Hardware name: ********
[ 1876.105290] Call trace:
[ 1876.107744] dump_backtrace+0x0/0x158
[ 1876.111403] show_stack+0x24/0x30
[ 1876.114723] dump_stack+0x80/0xa4
[ 1876.118064] iwl_trans_pcie_send_hcmd+0x5d0/0x5e8 [iwlwifi]
[ 1876.123649] iwl_trans_send_cmd+0x68/0x108 [iwlwifi]
[ 1876.128644] iwl_mvm_send_cmd_status+0x44/0xe0 [iwlmvm]
[ 1876.133889] iwl_mvm_send_cmd_pdu_status+0x6c/0x98 [iwlmvm]
[ 1876.139480] iwl_mvm_binding_update+0x148/0x230 [iwlmvm]
[ 1876.144809] iwl_mvm_binding_add_vif+0x5c/0x80 [iwlmvm]
[ 1876.150048] iwl_mvm_start_ap_ibss+0xe0/0x238 [iwlmvm]
[ 1876.155268] ieee80211_start_ap+0x218/0x488 [mac80211]
[ 1876.160473] nl80211_start_ap+0x3f4/0x6a8 [cfg80211]
[ 1876.165446] genl_family_rcv_msg+0x1cc/0x338
[ 1876.169718] genl_rcv_msg+0xa0/0xd8
[ 1876.173207] netlink_rcv_skb+0x60/0x120
[ 1876.177043] genl_rcv+0x3c/0x50
[ 1876.180186] netlink_unicast+0x194/0x210
[ 1876.184109] netlink_sendmsg+0x1a0/0x348
[ 1876.188036] sock_sendmsg+0x34/0x50
[ 1876.191523] ___sys_sendmsg+0x288/0x2c8
[ 1876.195357] __sys_sendmsg+0x7c/0xd0
[ 1876.198933] sys_sendmsg+0x38/0x48
[ 1876.202330] el0_svc_naked+0x30/0x34
[ 1876.206366] iwlwifi 0000:01:00.0: Failed to send binding (action:1): -5
[ 1876.213092] iwlwifi 0000:01:00.0: Failed to remove MAC context: -5
[ 1876.219353] iwlwifi 0000:01:00.0: PHY ctxt cmd error. ret=-5
It looks like the module firmware got an error when trying to set the
module in AP in 5GHz. I know there could be some regulatory limitation
for IBSS in 5Ghz, but why this does not work for wifi direct.
Thanks for your time.
@team.
^ permalink raw reply
* Re: [PATCH v2] cfg80211: add local BSS receive time to survey information
From: Marcel Holtmann @ 2019-08-28 17:25 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20190828102042.58016-1-nbd@nbd.name>
Hi Felix,
> This is useful for checking how much airtime is being used up by other
> transmissions on the channel, e.g. by calculating (time_rx - time_bss_rx)
> or (time_busy - time_bss_rx - time_tx)
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> include/net/cfg80211.h | 4 ++++
> include/uapi/linux/nl80211.h | 3 +++
> net/wireless/nl80211.c | 4 ++++
> 3 files changed, 11 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 35ec1f0a2bf9..bf97c4f805d3 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -694,6 +694,7 @@ ieee80211_chandef_max_power(struct cfg80211_chan_def *chandef)
> * @SURVEY_INFO_TIME_RX: receive time was filled in
> * @SURVEY_INFO_TIME_TX: transmit time was filled in
> * @SURVEY_INFO_TIME_SCAN: scan time was filled in
> + * @SURVEY_INFO_TIME_BSS_RX: local BSS receive time was filled in
> *
> * Used by the driver to indicate which info in &struct survey_info
> * it has filled in during the get_survey().
> @@ -707,6 +708,7 @@ enum survey_info_flags {
> SURVEY_INFO_TIME_RX = BIT(5),
> SURVEY_INFO_TIME_TX = BIT(6),
> SURVEY_INFO_TIME_SCAN = BIT(7),
> + SURVEY_INFO_TIME_BSS_RX = BIT(8),
> };
>
> /**
> @@ -723,6 +725,7 @@ enum survey_info_flags {
> * @time_rx: amount of time the radio spent receiving data
> * @time_tx: amount of time the radio spent transmitting data
> * @time_scan: amount of time the radio spent for scanning
> + * @time_bss_rx: amount of time the radio spent receiving data on a local BSS
> *
> * Used by dump_survey() to report back per-channel survey information.
> *
> @@ -737,6 +740,7 @@ struct survey_info {
> u64 time_rx;
> u64 time_tx;
> u64 time_scan;
> + u64 time_bss_rx;
> u32 filled;
> s8 noise;
> };
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 822851d369ab..e74cf4daad02 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -3843,6 +3843,8 @@ enum nl80211_user_reg_hint_type {
> * @NL80211_SURVEY_INFO_TIME_SCAN: time the radio spent for scan
> * (on this channel or globally)
> * @NL80211_SURVEY_INFO_PAD: attribute used for padding for 64-bit alignment
> + * @NL80211_SURVEY_INFO_TIME_BSS_RX: amount of time the radio spent
> + * receiving local BSS data
> * @NL80211_SURVEY_INFO_MAX: highest survey info attribute number
> * currently defined
> * @__NL80211_SURVEY_INFO_AFTER_LAST: internal use
> @@ -3859,6 +3861,7 @@ enum nl80211_survey_info {
> NL80211_SURVEY_INFO_TIME_TX,
> NL80211_SURVEY_INFO_TIME_SCAN,
> NL80211_SURVEY_INFO_PAD,
> + NL80211_SURVEY_INFO_TIME_BSS_RX,
wouldn’t this go before the PAD attribute?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] cfg80211: add local BSS receive time to survey information
From: Johannes Berg @ 2019-08-28 19:44 UTC (permalink / raw)
To: Marcel Holtmann, Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <9189B2C1-6E5B-4457-9354-A010F946EE33@holtmann.org>
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.
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: add local BSS receive time to survey information
From: Marcel Holtmann @ 2019-08-28 19:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <18c4232675c7b4f13fbfe9e5d8e9364a0908f316.camel@sipsolutions.net>
Hi Johannes,
>> ... [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.
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 always move, but also not expected to be part of the API as a fixed value.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] cfg80211: add local BSS receive time to survey information
From: Johannes Berg @ 2019-08-28 19:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <F29BC537-AED5-4BFA-915F-ED8E749124FC@holtmann.org>
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 always move, but also not expected to be part of the API as a
> fixed value.
No no, the _MAX is just the token we use for knowing what we want as the
maximum when parsing etc.
The _PAD is actually a real attribute, basically nla_put_u64_64bit()
will do "nla_put_flag(_PAD)" if and only if "offset % 8 == 0", in order
to actually 64-bit align the 64-bit value in the following attribute.
(Note that offset % 8 can only be 0 or 4, due to the way netlink
attributes work.)
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: add local BSS receive time to survey information
From: Marcel Holtmann @ 2019-08-28 20:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <a15716609a2c88e1591581539fd637f7385571e4.camel@sipsolutions.net>
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.
>>
>> I assumed these are similar to the NL80211_SURVEY_INFO_MAX which we
>> also always move, but also not expected to be part of the API as a
>> fixed value.
>
> No no, the _MAX is just the token we use for knowing what we want as the
> maximum when parsing etc.
>
> The _PAD is actually a real attribute, basically nla_put_u64_64bit()
> will do "nla_put_flag(_PAD)" if and only if "offset % 8 == 0", in order
> to actually 64-bit align the 64-bit value in the following attribute.
>
> (Note that offset % 8 can only be 0 or 4, due to the way netlink
> attributes work.)
I get that part now. So the kernel is inserting a _PAD, but userspace is still not doing that. So for NL80211_ATTR_WDEV we should be doing the same actually?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] cfg80211: add local BSS receive time to survey information
From: Johannes Berg @ 2019-08-28 20:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <F130F474-2D74-4952-B94B-82200B1D6CB6@holtmann.org>
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.
> > >
> > > I assumed these are similar to the NL80211_SURVEY_INFO_MAX which we
> > > also always move, but also not expected to be part of the API as a
> > > fixed value.
> >
> > No no, the _MAX is just the token we use for knowing what we want as the
> > maximum when parsing etc.
> >
> > The _PAD is actually a real attribute, basically nla_put_u64_64bit()
> > will do "nla_put_flag(_PAD)" if and only if "offset % 8 == 0", in order
> > to actually 64-bit align the 64-bit value in the following attribute.
> >
> > (Note that offset % 8 can only be 0 or 4, due to the way netlink
> > attributes work.)
>
> I get that part now. So the kernel is inserting a _PAD, but userspace
> is still not doing that.
Yeah, and I forgot to say - if we renumbered _PAD, then newer userspace
would think old kernel's _PAD is really _BSS_RX, so things would break.
> So for NL80211_ATTR_WDEV we should be doing the same actually?
Not really. The kernel doesn't rely on it, nla_get_u64() uses
nla_memcpy() so doesn't care about alignment.
Even userspace doesn't (usually) rely on the alignment, it also
typically uses nla_get_u64() from libnl which also uses nla_memcpy() or
memcpy() (depending on the version), so it's all not really necessary.
I think some libraries or tools like maybe iproute2 didn't do it
correctly and just dereferenced a pointer there, causing alignment
violations, and so basically the decision was to get rid of unaligned
64-bit attributes to prevent that once and for all.
johannes
^ permalink raw reply
* Re: [PATCH] mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings
From: Johannes Berg @ 2019-08-28 20:36 UTC (permalink / raw)
To: huangwenabc, linux-wireless
Cc: amitkarwar, nishants, gbhat, huxinming820, solar, greg, kvalo,
sashal, mrehak
In-Reply-To: <20190828020751.13625-1-huangwenabc@gmail.com>
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.tail_len);
consider removing struct ieee_types_header from your driver, and using
struct element from <linux/ieee80211.h> instead.
This also comes with cfg80211_find_elem() that returns a suitably typed
pointer, so you don't need any casts.
> if (vendor_ie) {
> wmm_ie = vendor_ie;
> + if (*(wmm_ie + 1) > sizeof(struct mwifiex_types_wmm_info))
> + return;
and using it here would be a whole lot easier to understand too :)
johannes
^ permalink raw reply
* Re: [PATCH] mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings
From: Johannes Berg @ 2019-08-28 20:37 UTC (permalink / raw)
To: huangwenabc, linux-wireless
Cc: amitkarwar, nishants, gbhat, huxinming820, solar, greg, kvalo,
sashal, mrehak
In-Reply-To: <adff8812a50ca03f22fd0b3573a19ca42481c009.camel@sipsolutions.net>
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
^ permalink raw reply
* [PATCH] cfg80211: Purge frame registrations on iftype change
From: Denis Kenzior @ 2019-08-28 21:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior, stable
Currently frame registrations are not purged, even when changing the
interface type. This can lead to potentially weird / dangerous
situations where frames possibly not relevant to a given interface
type remain registered and mgmt_frame_register is not called for the
no-longer-relevant frame types.
The kernel currently relies on userspace apps to actually purge the
registrations themselves, e.g. by closing the nl80211 socket associated
with those frames. However, this requires multiple nl80211 sockets to
be open by the userspace app, and for userspace to be aware of all state
changes. This is not something that the kernel should rely on.
This commit adds a call to cfg80211_mlme_purge_registrations() to
forcefully remove any registrations left over prior to switching the
iftype.
Cc: stable@vger.kernel.org
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index c99939067bb0..3fa092b78e62 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -964,6 +964,7 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
}
cfg80211_process_rdev_events(rdev);
+ cfg80211_mlme_purge_registrations(dev->ieee80211_ptr);
}
err = rdev_change_virtual_intf(rdev, dev, ntype, params);
--
2.19.2
^ permalink raw reply related
* [PATCH v3 0/8] ath10k: improve throughout of tcp/udp TX/RX of sdio
From: Wen Gong @ 2019-08-28 13:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
The bottleneck of throughout on sdio chip is the bus bandwidth, to the
patches are all to increase the use ratio of sdio bus.
udp-rx udp-tx tcp-rx tcp-tx
without patches(Mbps) 320 180 170 151
with patches(Mbps) 450 410 400 320
These patches only affect sdio bus chip, explanation is mentioned in each
patch's commit log.
Alagu Sankar (1):
ath10k: enable RX bundle receive for sdio
v2: fix incorrect skb tail of rx bundle in ath10k_sdio_mbox_rx_process_packet
v3: change some code style
split fix incorrect skb tail of rx bundle to patch "adjust skb length in ath10k_sdio_mbox_rx_packet"
Wen Gong (7):
ath10k: adjust skb length in ath10k_sdio_mbox_rx_packet
v2:no this patch
v2:new added
ath10k: change max RX bundle size from 8 to 32 for sdio
v2:change macro HTC_GET_BUNDLE_COUNT
v3:change some code style
ath10k: add workqueue for RX path of sdio
v2:no change
v3:change some code style
ath10k: disable TX complete indication of htt for sdio
v2:change some code style
v3:change some code style
ath10k: add htt TX bundle for sdio
v2:no change
v3:change some code style
ath10k: enable alt data of TX path for sdio
v2:no change
v3:change some code style
ath10k: enable napi on RX path for sdio
v2:no change
v3:change some code style
drivers/net/wireless/ath/ath10k/core.c | 42 +++-
drivers/net/wireless/ath/ath10k/core.h | 4 +-
drivers/net/wireless/ath/ath10k/hif.h | 9 +
drivers/net/wireless/ath/ath10k/htc.c | 376 ++++++++++++++++++++++++++++---
drivers/net/wireless/ath/ath10k/htc.h | 43 +++-
drivers/net/wireless/ath/ath10k/htt.c | 15 ++
drivers/net/wireless/ath/ath10k/htt.h | 20 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 80 ++++++-
drivers/net/wireless/ath/ath10k/htt_tx.c | 38 +++-
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
drivers/net/wireless/ath/ath10k/sdio.c | 279 ++++++++++++++++++++---
drivers/net/wireless/ath/ath10k/sdio.h | 31 ++-
12 files changed, 844 insertions(+), 95 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v5.3] iwlwifi: assign directly to iwl_trans->cfg in QuZ detection
From: Luca Coelho @ 2019-08-29 8:13 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
From: Luca Coelho <luciano.coelho@intel.com>
We were erroneously assigning the new configuration to a local
variable cfg, but that was not being assigned to anything, so the
change was getting lost. Assign directly to iwl_trans->cfg instead.
Fixes: 5a8c31aa6357 ("iwlwifi: pcie: fix recognition of QuZ devices")
Cc: stable@vger.kernel.org # 5.2
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 24 +++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index d9ed53b7c768..3b12e7ad35e1 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1070,18 +1070,18 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/* same thing for QuZ... */
if (iwl_trans->hw_rev == CSR_HW_REV_TYPE_QUZ) {
- if (cfg == &iwl_ax101_cfg_qu_hr)
- cfg = &iwl_ax101_cfg_quz_hr;
- else if (cfg == &iwl_ax201_cfg_qu_hr)
- cfg = &iwl_ax201_cfg_quz_hr;
- else if (cfg == &iwl9461_2ac_cfg_qu_b0_jf_b0)
- cfg = &iwl9461_2ac_cfg_quz_a0_jf_b0_soc;
- else if (cfg == &iwl9462_2ac_cfg_qu_b0_jf_b0)
- cfg = &iwl9462_2ac_cfg_quz_a0_jf_b0_soc;
- else if (cfg == &iwl9560_2ac_cfg_qu_b0_jf_b0)
- cfg = &iwl9560_2ac_cfg_quz_a0_jf_b0_soc;
- else if (cfg == &iwl9560_2ac_160_cfg_qu_b0_jf_b0)
- cfg = &iwl9560_2ac_160_cfg_quz_a0_jf_b0_soc;
+ if (iwl_trans->cfg == &iwl_ax101_cfg_qu_hr)
+ iwl_trans->cfg = &iwl_ax101_cfg_quz_hr;
+ else if (iwl_trans->cfg == &iwl_ax201_cfg_qu_hr)
+ iwl_trans->cfg = &iwl_ax201_cfg_quz_hr;
+ else if (iwl_trans->cfg == &iwl9461_2ac_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg = &iwl9461_2ac_cfg_quz_a0_jf_b0_soc;
+ else if (iwl_trans->cfg == &iwl9462_2ac_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg = &iwl9462_2ac_cfg_quz_a0_jf_b0_soc;
+ else if (iwl_trans->cfg == &iwl9560_2ac_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg = &iwl9560_2ac_cfg_quz_a0_jf_b0_soc;
+ else if (iwl_trans->cfg == &iwl9560_2ac_160_cfg_qu_b0_jf_b0)
+ iwl_trans->cfg = &iwl9560_2ac_160_cfg_quz_a0_jf_b0_soc;
}
#endif
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH -next] brcmfmac: get chip's default RAM info during PCIe setup
From: Rafał Miłecki @ 2019-08-29 8:27 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Winnie Chang, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Getting RAM info just once per driver's lifetime (during chip
recognition) is not enough as it may get adjusted later (depending on
the used firmware). Subsequent inits may load different firmwares so a
full RAM recognition is required on every PCIe setup. This is especially
important since implementing hardware reset on a firmware crash.
Moreover calling brcmf_chip_get_raminfo() makes sure that RAM core is
up. It's important as having BCMA_CORE_SYS_MEM down on BCM4366 was
resulting in firmware failing to initialize and following error:
[ 65.657546] brcmfmac 0000:01:00.0: brcmf_pcie_download_fw_nvram: Invalid shared RAM address 0x04000001
This change makes brcmf_chip_get_raminfo() call during chip recognition
redundant for PCIe devices but SDIO and USB still need it and it's a
very small overhead anyway.
Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
This is a refreshed version of previous:
[PATCH 2/4] brcmfmac: get RAM info right before downloading PCIe firmware
https://patchwork.kernel.org/patch/10830171/
After Arend's comment I did some extra research on driver's RAM info
code and updated commit properly.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 6 ++++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 6 ++++++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 1ec48c4f4d4a..dd586a96b57a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -696,8 +696,10 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
return 0;
}
-static int brcmf_chip_get_raminfo(struct brcmf_chip_priv *ci)
+int brcmf_chip_get_raminfo(struct brcmf_chip *pub)
{
+ struct brcmf_chip_priv *ci = container_of(pub, struct brcmf_chip_priv,
+ pub);
struct brcmf_core_priv *mem_core;
struct brcmf_core *mem;
@@ -979,7 +981,7 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv *ci)
brcmf_chip_set_passive(&ci->pub);
}
- return brcmf_chip_get_raminfo(ci);
+ return brcmf_chip_get_raminfo(&ci->pub);
}
static void brcmf_chip_disable_arm(struct brcmf_chip_priv *chip, u16 id)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
index 206d7695d57a..7b00f6a59e89 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
@@ -69,6 +69,7 @@ struct brcmf_buscore_ops {
void (*activate)(void *ctx, struct brcmf_chip *chip, u32 rstvec);
};
+int brcmf_chip_get_raminfo(struct brcmf_chip *pub);
struct brcmf_chip *brcmf_chip_attach(void *ctx,
const struct brcmf_buscore_ops *ops);
void brcmf_chip_detach(struct brcmf_chip *chip);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 8d0e74416643..7ac945369762 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1770,6 +1770,12 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
nvram_len = fwreq->items[BRCMF_PCIE_FW_NVRAM].nv_data.len;
kfree(fwreq);
+ ret = brcmf_chip_get_raminfo(devinfo->ci);
+ if (ret) {
+ brcmf_err(bus, "Failed to get RAM info\n");
+ goto fail;
+ }
+
/* Some of the firmwares have the size of the memory of the device
* defined inside the firmware. This is because part of the memory in
* the device is shared and the devision is determined by FW. Parse
--
2.21.0
^ permalink raw reply related
* [PATCH] mt76: mt7615: move mt7615 sta utilities in pci.c
From: Lorenzo Bianconi @ 2019-08-29 8:57 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
Move mt7615_sta_add, mt7615_sta_assoc, mt7615_sta_ps and mt7615_sta_remove
utility routines in pci.c and make them static since they are only used to
initialize mt76_driver_ops callbacks
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/mac.c | 4 --
.../net/wireless/mediatek/mt76/mt7615/main.c | 40 ---------------
.../wireless/mediatek/mt76/mt7615/mt7615.h | 7 ---
.../net/wireless/mediatek/mt76/mt7615/pci.c | 49 +++++++++++++++++++
4 files changed, 49 insertions(+), 51 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index e07ce2c10013..ee6b5a609ee7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -215,10 +215,6 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
return 0;
}
-void mt7615_sta_ps(struct mt76_dev *mdev, struct ieee80211_sta *sta, bool ps)
-{
-}
-
void mt7615_tx_complete_skb(struct mt76_dev *mdev, enum mt76_txq_id qid,
struct mt76_queue_entry *e)
{
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 87c748715b5d..0da937f36d3d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -336,46 +336,6 @@ mt7615_channel_switch_beacon(struct ieee80211_hw *hw,
mutex_unlock(&dev->mt76.mutex);
}
-int mt7615_sta_add(struct mt76_dev *mdev, struct ieee80211_vif *vif,
- struct ieee80211_sta *sta)
-{
- struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
- struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
- struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
- int idx;
-
- idx = mt76_wcid_alloc(dev->mt76.wcid_mask, MT7615_WTBL_STA - 1);
- if (idx < 0)
- return -ENOSPC;
-
- msta->vif = mvif;
- msta->wcid.sta = 1;
- msta->wcid.idx = idx;
-
- mt7615_mcu_add_wtbl(dev, vif, sta);
- mt7615_mcu_set_sta_rec(dev, vif, sta, 1);
-
- return 0;
-}
-
-void mt7615_sta_assoc(struct mt76_dev *mdev, struct ieee80211_vif *vif,
- struct ieee80211_sta *sta)
-{
- struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
-
- if (sta->ht_cap.ht_supported)
- mt7615_mcu_set_ht_cap(dev, vif, sta);
-}
-
-void mt7615_sta_remove(struct mt76_dev *mdev, struct ieee80211_vif *vif,
- struct ieee80211_sta *sta)
-{
- struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
-
- mt7615_mcu_set_sta_rec(dev, vif, sta, 0);
- mt7615_mcu_del_wtbl(dev, sta);
-}
-
static void mt7615_sta_rate_tbl_update(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index a79f4ffcb70f..6ea4645da053 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -259,13 +259,6 @@ void mt7615_tx_complete_skb(struct mt76_dev *mdev, enum mt76_txq_id qid,
void mt7615_queue_rx_skb(struct mt76_dev *mdev, enum mt76_rxq_id q,
struct sk_buff *skb);
-void mt7615_sta_ps(struct mt76_dev *mdev, struct ieee80211_sta *sta, bool ps);
-int mt7615_sta_add(struct mt76_dev *mdev, struct ieee80211_vif *vif,
- struct ieee80211_sta *sta);
-void mt7615_sta_assoc(struct mt76_dev *mdev, struct ieee80211_vif *vif,
- struct ieee80211_sta *sta);
-void mt7615_sta_remove(struct mt76_dev *mdev, struct ieee80211_vif *vif,
- struct ieee80211_sta *sta);
void mt7615_mac_work(struct work_struct *work);
void mt7615_txp_skb_unmap(struct mt76_dev *dev,
struct mt76_txwi_cache *txwi);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/pci.c b/drivers/net/wireless/mediatek/mt76/mt7615/pci.c
index e250607e0a80..524ce35010e6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/pci.c
@@ -66,6 +66,55 @@ static irqreturn_t mt7615_irq_handler(int irq, void *dev_instance)
return IRQ_HANDLED;
}
+static int
+mt7615_sta_add(struct mt76_dev *mdev, struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
+ struct mt7615_sta *msta = (struct mt7615_sta *)sta->drv_priv;
+ struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
+ int idx;
+
+ idx = mt76_wcid_alloc(dev->mt76.wcid_mask, MT7615_WTBL_STA - 1);
+ if (idx < 0)
+ return -ENOSPC;
+
+ msta->vif = mvif;
+ msta->wcid.sta = 1;
+ msta->wcid.idx = idx;
+
+ mt7615_mcu_add_wtbl(dev, vif, sta);
+ mt7615_mcu_set_sta_rec(dev, vif, sta, 1);
+
+ return 0;
+}
+
+static void
+mt7615_sta_assoc(struct mt76_dev *mdev, struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
+
+ if (sta->ht_cap.ht_supported)
+ mt7615_mcu_set_ht_cap(dev, vif, sta);
+}
+
+static void
+mt7615_sta_remove(struct mt76_dev *mdev, struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
+
+ mt7615_mcu_set_sta_rec(dev, vif, sta, 0);
+ mt7615_mcu_del_wtbl(dev, sta);
+}
+
+static void
+mt7615_sta_ps(struct mt76_dev *mdev, struct ieee80211_sta *sta,
+ bool ps)
+{
+}
+
static int mt7615_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
--
2.21.0
^ permalink raw reply related
* rt2x00: 5Ghz signal power degradation with linux 5.2 kernel
From: Sergey Maranchuk @ 2019-08-29 9:42 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAJp6tx-L0Q4_OaUp+xMod0jsLjAByqnbrvk=JbEq5LOxTdhr_g@mail.gmail.com>
I got some problem after upgrade kernel to 5.2 version (debian testing
linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP.
Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for
5Ghz - 53dBm !, for longer distance (8m + walls) 2.4 - 61dBm, 5Ghz not
visible.
All works fine with kernel 4.19 and on windows 10, other devices also
see AP without any problems with same distance.
Client Device - Alfa AWUS051NH
# lsmod |grep rt2
rt2800usb 28672 0
rt2x00usb 28672 1 rt2800usb
rt2800lib 135168 1 rt2800usb
rt2x00lib 69632 3 rt2800usb,rt2x00usb,rt2800lib
mac80211 868352 3 rt2x00lib,rt2x00usb,rt2800lib
cfg80211 819200 2 rt2x00lib,mac80211
crc_ccitt 16384 1 rt2800lib
usbcore 299008 9
xhci_hcd,rt2800usb,usbhid,xpad,usblp,usb_storage,xhci_pci,uas,rt2x00usb
# uname -a
Linux pc 5.2.0-2-amd64 #1 SMP Debian 5.2.9-2 (2019-08-21) x86_64 GNU/Linux
# modinfo rt2800usb
filename:
/lib/modules/5.2.0-2-amd64/kernel/drivers/net/wireless/ralink/rt2x00/rt2800usb.ko
license: GPL
firmware: rt2870.bin
description: Ralink RT2800 USB Wireless LAN driver.
version: 2.3.0
author: http://rt2x00.serialmonkey.com
srcversion: 554185273066F7CCC831E83
...
# dmesg|grep "rt2\|ieee8"
[ 8.750465] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 2872,
rev 0202 detected
[ 8.806271] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0004 detected
[ 8.822990] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 8.823491] usbcore: registered new interface driver rt2800usb
[ 8.829996] rt2800usb 3-3:1.0 wlx00c0ca32d4ad: renamed from wlan0
[ 10.180340] ieee80211 phy0: rt2x00lib_request_firmware: Info -
Loading firmware file 'rt2870.bin'
[ 10.181479] rt2800usb 3-3:1.0: firmware: direct-loading firmware rt2870.bin
[ 10.181485] ieee80211 phy0: rt2x00lib_request_firmware: Info -
Firmware detected - version: 0.36
# lsusb
Bus 003 Device 005: ID 148f:2770 Ralink Technology, Corp. RT2770
Wireless Adapter
# iw reg get
global
country UA: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A), NO-OUTDOOR
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5670 @ 160), (N/A, 20), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 20), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
resetting to 00 didn't help
# iwlist wlx00c0ca32d4ad txpower
wlx00c0ca32d4ad unknown transmit-power information.
Current Tx-Power=20 dBm (100 mW)
# iw list
Wiphy phy0
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short long limit: 2
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 1:
Capabilities: 0x27e
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
RX STBC 2-streams
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 2 usec (0x04)
HT RX MCS rate indexes supported: 0-15, 32
TX unequal modulation not supported
HT TX Max spatial streams: 1
HT TX MCS rate indexes supported may differ
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Band 2:
Capabilities: 0x27e
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
RX STBC 2-streams
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 2 usec (0x04)
HT RX MCS rate indexes supported: 0-15, 32
TX unequal modulation not supported
HT TX Max spatial streams: 1
HT TX MCS rate indexes supported may differ
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5190 MHz [38] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5230 MHz [46] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (radar detection)
* 5270 MHz [54] (20.0 dBm) (radar detection)
* 5280 MHz [56] (20.0 dBm) (radar detection)
* 5300 MHz [60] (20.0 dBm) (radar detection)
* 5310 MHz [62] (20.0 dBm) (radar detection)
* 5320 MHz [64] (20.0 dBm) (radar detection)
* 5500 MHz [100] (20.0 dBm) (radar detection)
* 5510 MHz [102] (20.0 dBm) (radar detection)
* 5520 MHz [104] (20.0 dBm) (radar detection)
* 5540 MHz [108] (20.0 dBm) (radar detection)
* 5550 MHz [110] (20.0 dBm) (radar detection)
* 5560 MHz [112] (20.0 dBm) (radar detection)
* 5580 MHz [116] (20.0 dBm) (radar detection)
* 5590 MHz [118] (20.0 dBm) (radar detection)
* 5600 MHz [120] (20.0 dBm) (radar detection)
* 5620 MHz [124] (20.0 dBm) (radar detection)
* 5630 MHz [126] (20.0 dBm) (radar detection)
* 5640 MHz [128] (20.0 dBm) (radar detection)
* 5660 MHz [132] (20.0 dBm) (radar detection)
* 5670 MHz [134] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (20.0 dBm)
* 5755 MHz [151] (20.0 dBm)
* 5765 MHz [153] (20.0 dBm)
* 5785 MHz [157] (20.0 dBm)
* 5795 MHz [159] (20.0 dBm)
* 5805 MHz [161] (20.0 dBm)
* 5825 MHz [165] (20.0 dBm)
* 5835 MHz [167] (disabled)
* 5845 MHz [169] (disabled)
* 5855 MHz [171] (disabled)
* 5865 MHz [173] (disabled)
* 4920 MHz [184] (disabled)
* 4940 MHz [188] (disabled)
* 4960 MHz [192] (disabled)
* 4980 MHz [196] (disabled)
* 6040 MHz [208] (disabled)
* 6060 MHz [212] (disabled)
* 6080 MHz [216] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* new_mpath
* set_mesh_config
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* set_mcast_rate
* connect
* disconnect
* set_qos_map
* set_multicast_to_unicast
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0
0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
software interface modes (can always be added):
* AP/VLAN
* monitor
valid interface combinations:
* #{ AP, mesh point } <= 8,
total <= 8, #channels <= 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports SAE with AUTHENTICATE command
Device supports low priority scan.
Device supports scan flush.
Device supports AP scan.
Device supports per-vif TX power setting
Driver supports full state transitions for AP/GO clients
Driver supports a userspace MPM
Device supports configuring vdev MAC-addr on create.
Supported extended features:
* [ RRM ]: RRM
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
^ permalink raw reply
* Re: rt2x00: 5Ghz signal power degradation with linux 5.2 kernel
From: Stanislaw Gruszka @ 2019-08-29 10:03 UTC (permalink / raw)
To: Sergey Maranchuk; +Cc: linux-wireless
In-Reply-To: <CAJp6tx-RcubaTdL4tK1fuLv08s-pqU+RQz4m1mb1LRhg3625zw@mail.gmail.com>
On Thu, Aug 29, 2019 at 12:42:44PM +0300, Sergey Maranchuk wrote:
> I got some problem after upgrade kernel to 5.2 version (debian testing
> linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP.
> Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for
> 5Ghz - 53dBm !, for longer distance (8m + walls) 2.4 - 61dBm, 5Ghz not
> visible.
> All works fine with kernel 4.19 and on windows 10, other devices also
> see AP without any problems with same distance.
After looking on the changlog most possible cause of it seems to be
commit 9ad3b55654455258a9463384edb40077439d879f:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ad3b55654455258a9463384edb40077439d879f
Please try to revert it, and see if that improve rx signal level.
It that would not help, please try to narrow regression to two
consecutive kernel versions - it is: 4.19 -> 5.0 or 5.0 -> 5.1
or 5.1 -> 5.2 ?
Stanislaw
^ permalink raw reply
* [PATCH AUTOSEL 4.4 3/6] mac80211: fix possible sta leak
From: Sasha Levin @ 2019-08-29 10:51 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190829105110.2748-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 ]
If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.
Cc: stable@vger.kernel.org
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7349bf26ae7b3..1999a7eaa6920 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1211,6 +1211,11 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (is_multicast_ether_addr(mac))
return -EINVAL;
+ if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER) &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
if (!sta)
return -ENOMEM;
@@ -1228,10 +1233,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER))
sta->sta.tdls = true;
- if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
- !sdata->u.mgd.associated)
- return -EINVAL;
-
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 5/8] mac80211: fix possible sta leak
From: Sasha Levin @ 2019-08-29 10:50 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190829105100.2649-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 ]
If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.
Cc: stable@vger.kernel.org
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 954315e1661df..3b2c4692d966f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1418,6 +1418,11 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (is_multicast_ether_addr(mac))
return -EINVAL;
+ if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER) &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
if (!sta)
return -ENOMEM;
@@ -1425,10 +1430,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER))
sta->sta.tdls = true;
- if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
- !sdata->u.mgd.associated)
- return -EINVAL;
-
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 10/14] mac80211: fix possible sta leak
From: Sasha Levin @ 2019-08-29 10:50 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190829105043.2508-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 ]
If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.
Cc: stable@vger.kernel.org
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 150dd2160cefb..8168c667d91d9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1459,6 +1459,11 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (is_multicast_ether_addr(mac))
return -EINVAL;
+ if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER) &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
if (!sta)
return -ENOMEM;
@@ -1466,10 +1471,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER))
sta->sta.tdls = true;
- if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
- !sdata->u.mgd.associated)
- return -EINVAL;
-
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 18/29] mac80211: fix possible sta leak
From: Sasha Levin @ 2019-08-29 10:49 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190829105009.2265-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 5fd2f91ad483baffdbe798f8a08f1b41442d1e24 ]
If TDLS station addition is rejected, the sta memory is leaked.
Avoid this by moving the check before the allocation.
Cc: stable@vger.kernel.org
Fixes: 7ed5285396c2 ("mac80211: don't initiate TDLS connection if station is not associated to AP")
Link: https://lore.kernel.org/r/20190801073033.7892-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/cfg.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 40c5102234679..a48e83b19cfa7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1471,6 +1471,11 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (is_multicast_ether_addr(mac))
return -EINVAL;
+ if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER) &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !sdata->u.mgd.associated)
+ return -EINVAL;
+
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
if (!sta)
return -ENOMEM;
@@ -1478,10 +1483,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER))
sta->sta.tdls = true;
- if (sta->sta.tdls && sdata->vif.type == NL80211_IFTYPE_STATION &&
- !sdata->u.mgd.associated)
- return -EINVAL;
-
err = sta_apply_parameters(local, sta, params);
if (err) {
sta_info_free(local, sta);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 07/29] {nl,mac}80211: fix interface combinations on crypto controlled devices
From: Sasha Levin @ 2019-08-29 10:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Manikanta Pubbisetty, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190829105009.2265-1-sashal@kernel.org>
From: Manikanta Pubbisetty <mpubbise@codeaurora.org>
[ Upstream commit e6f4051123fd33901e9655a675b22aefcdc5d277 ]
Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on
crypto controlled devices") has introduced a change which allows
4addr operation on crypto controlled devices (ex: ath10k). This
change has inadvertently impacted the interface combinations logic
on such devices.
General rule is that software interfaces like AP/VLAN should not be
listed under supported interface combinations and should not be
considered during validation of these combinations; because of the
aforementioned change, AP/VLAN interfaces(if present) will be checked
against interfaces supported by the device and blocks valid interface
combinations.
Consider a case where an AP and AP/VLAN are up and running; when a
second AP device is brought up on the same physical device, this AP
will be checked against the AP/VLAN interface (which will not be
part of supported interface combinations of the device) and blocks
second AP to come up.
Add a new API cfg80211_iftype_allowed() to fix the problem, this
API works for all devices with/without SW crypto control.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Fixes: 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices")
Link: https://lore.kernel.org/r/1563779690-9716-1-git-send-email-mpubbise@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/cfg80211.h | 15 +++++++++++++++
net/mac80211/util.c | 7 +++----
net/wireless/core.c | 6 ++----
net/wireless/nl80211.c | 4 +---
net/wireless/util.c | 27 +++++++++++++++++++++++++--
5 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 67e0a990144a6..468deae5d603e 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -6562,6 +6562,21 @@ int cfg80211_external_auth_request(struct net_device *netdev,
struct cfg80211_external_auth_params *params,
gfp_t gfp);
+/**
+ * cfg80211_iftype_allowed - check whether the interface can be allowed
+ * @wiphy: the wiphy
+ * @iftype: interface type
+ * @is_4addr: use_4addr flag, must be '0' when check_swif is '1'
+ * @check_swif: check iftype against software interfaces
+ *
+ * Check whether the interface is allowed to operate; additionally, this API
+ * can be used to check iftype against the software interfaces when
+ * check_swif is '1'.
+ */
+bool cfg80211_iftype_allowed(struct wiphy *wiphy, enum nl80211_iftype iftype,
+ bool is_4addr, u8 check_swif);
+
+
/* Logging, debugging and troubleshooting/diagnostic helpers. */
/* wiphy_printk helpers, similar to dev_printk */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index c59638574cf8b..f101a6460b44b 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3527,9 +3527,7 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
}
/* Always allow software iftypes */
- if (local->hw.wiphy->software_iftypes & BIT(iftype) ||
- (iftype == NL80211_IFTYPE_AP_VLAN &&
- local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) {
+ if (cfg80211_iftype_allowed(local->hw.wiphy, iftype, 0, 1)) {
if (radar_detect)
return -EINVAL;
return 0;
@@ -3564,7 +3562,8 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
if (sdata_iter == sdata ||
!ieee80211_sdata_running(sdata_iter) ||
- local->hw.wiphy->software_iftypes & BIT(wdev_iter->iftype))
+ cfg80211_iftype_allowed(local->hw.wiphy,
+ wdev_iter->iftype, 0, 1))
continue;
params.iftype_num[wdev_iter->iftype]++;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 2a46ec3cb72c1..68660781aa51f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1335,10 +1335,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
}
break;
case NETDEV_PRE_UP:
- if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) &&
- !(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
- rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
- wdev->use_4addr))
+ if (!cfg80211_iftype_allowed(wdev->wiphy, wdev->iftype,
+ wdev->use_4addr, 0))
return notifier_from_errno(-EOPNOTSUPP);
if (rfkill_blocked(rdev->rfkill))
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8e2f03ab4cc9f..2a85bff6a8f35 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3210,9 +3210,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
return err;
}
- if (!(rdev->wiphy.interface_modes & (1 << type)) &&
- !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr &&
- rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP))
+ if (!cfg80211_iftype_allowed(&rdev->wiphy, type, params.use_4addr, 0))
return -EOPNOTSUPP;
err = nl80211_parse_mon_options(rdev, type, info, ¶ms);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index d57e2f679a3e4..c14e8f6e5e198 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1670,7 +1670,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
for (iftype = 0; iftype < NUM_NL80211_IFTYPES; iftype++) {
num_interfaces += params->iftype_num[iftype];
if (params->iftype_num[iftype] > 0 &&
- !(wiphy->software_iftypes & BIT(iftype)))
+ !cfg80211_iftype_allowed(wiphy, iftype, 0, 1))
used_iftypes |= BIT(iftype);
}
@@ -1692,7 +1692,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
return -ENOMEM;
for (iftype = 0; iftype < NUM_NL80211_IFTYPES; iftype++) {
- if (wiphy->software_iftypes & BIT(iftype))
+ if (cfg80211_iftype_allowed(wiphy, iftype, 0, 1))
continue;
for (j = 0; j < c->n_limits; j++) {
all_iftypes |= limits[j].types;
@@ -1895,3 +1895,26 @@ EXPORT_SYMBOL(rfc1042_header);
const unsigned char bridge_tunnel_header[] __aligned(2) =
{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 };
EXPORT_SYMBOL(bridge_tunnel_header);
+
+bool cfg80211_iftype_allowed(struct wiphy *wiphy, enum nl80211_iftype iftype,
+ bool is_4addr, u8 check_swif)
+
+{
+ bool is_vlan = iftype == NL80211_IFTYPE_AP_VLAN;
+
+ switch (check_swif) {
+ case 0:
+ if (is_vlan && is_4addr)
+ return wiphy->flags & WIPHY_FLAG_4ADDR_AP;
+ return wiphy->interface_modes & BIT(iftype);
+ case 1:
+ if (!(wiphy->software_iftypes & BIT(iftype)) && is_vlan)
+ return wiphy->flags & WIPHY_FLAG_4ADDR_AP;
+ return wiphy->software_iftypes & BIT(iftype);
+ default:
+ break;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(cfg80211_iftype_allowed);
--
2.20.1
^ permalink raw reply related
* Re: rt2x00: 5Ghz signal power degradation with linux 5.2 kernel
From: Sergey Maranchuk @ 2019-08-29 11:13 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless
In-Reply-To: <20190829100336.GA1930@redhat.com>
Yes, it is!
After reverting this commit (i used debian 5.2 kernel sources +
patched rt2800lib.ko mod) i see my home 5Ghz network with -45dBm
tnx for quick help
чт, 29 авг. 2019 г. в 13:03, Stanislaw Gruszka <sgruszka@redhat.com>:
>
> On Thu, Aug 29, 2019 at 12:42:44PM +0300, Sergey Maranchuk wrote:
> > I got some problem after upgrade kernel to 5.2 version (debian testing
> > linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP.
> > Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for
> > 5Ghz - 53dBm !, for longer distance (8m + walls) 2.4 - 61dBm, 5Ghz not
> > visible.
> > All works fine with kernel 4.19 and on windows 10, other devices also
> > see AP without any problems with same distance.
>
> After looking on the changlog most possible cause of it seems to be
> commit 9ad3b55654455258a9463384edb40077439d879f:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ad3b55654455258a9463384edb40077439d879f
>
> Please try to revert it, and see if that improve rx signal level.
>
> It that would not help, please try to narrow regression to two
> consecutive kernel versions - it is: 4.19 -> 5.0 or 5.0 -> 5.1
> or 5.1 -> 5.2 ?
>
> Stanislaw
^ permalink raw reply
* [PATCH 5.3] Revert "rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band"
From: Stanislaw Gruszka @ 2019-08-29 11:29 UTC (permalink / raw)
To: linux-wireless
Cc: Felix Fietkau, Daniel Golle, Tomislav Požega, Mathias Kresin,
Sergey Maranchuk
This reverts commit 9ad3b55654455258a9463384edb40077439d879f.
As reported by Sergey:
"I got some problem after upgrade kernel to 5.2 version (debian testing
linux-image-5.2.0-2-amd64). 5Ghz client stopped to see AP.
Some tests with 1metre distance between client-AP: 2.4Ghz -22dBm, for
5Ghz - 53dBm !, for longer distance (8m + walls) 2.4 - 61dBm, 5Ghz not
visible."
It was identified that rx signal level degradation was caused by
9ad3b5565445 ("rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band").
So revert this commit.
Cc: <stable@vger.kernel.org> # v5.1+
Reported-and-tested-by: Sergey Maranchuk <slav0nic0@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index c9b957ac5733..b2bfa83819b0 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4237,24 +4237,18 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
switch (rt2x00dev->default_ant.rx_chain_num) {
case 3:
/* Turn on tertiary LNAs */
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A2_EN,
- rf->channel > 14);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G2_EN,
- rf->channel <= 14);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A2_EN, 1);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G2_EN, 1);
/* fall-through */
case 2:
/* Turn on secondary LNAs */
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A1_EN,
- rf->channel > 14);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G1_EN,
- rf->channel <= 14);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A1_EN, 1);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G1_EN, 1);
/* fall-through */
case 1:
/* Turn on primary LNAs */
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A0_EN,
- rf->channel > 14);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G0_EN,
- rf->channel <= 14);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A0_EN, 1);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G0_EN, 1);
break;
}
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] wil6210: Delete an unnecessary kfree() call in wil_tid_ampdu_rx_alloc()
From: merez @ 2019-08-28 7:44 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-wireless, netdev, wil6210, David S. Miller, Kalle Valo,
LKML, kernel-janitors, linux-wireless-owner
In-Reply-To: <b9620e49-618d-b392-6456-17de5807df75@web.de>
On 2019-08-27 17:44, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 27 Aug 2019 16:39:02 +0200
>
> A null pointer would be passed to a call of the function “kfree”
> directly after a call of the function “kcalloc” failed at one place.
> Remove this superfluous function call.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
Reviewed-by: Maya Erez <merez@codeaurora.org>
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* Re: mac80211_hwsim (kernel 4.18+): wmediumd + 2.4Ghz
From: Johannes Berg @ 2019-08-29 14:57 UTC (permalink / raw)
To: Ramon Fontes, linux-wireless
In-Reply-To: <CAK8U23biuUY9hWE1NOnSbJCRtRVfdg1a27ZOkU5cbaGdzZLYEA@mail.gmail.com>
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 TUs
> capability: ESS ShortSlotTime (0x0401)
> signal: -34.00 dBm
> last seen: 0 ms ago
> Information elements from Probe Response frame:
> SSID: simplewifi
> Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
> DS Parameter set: channel 3
> ERP: Barker_Preamble_Mode
> Extended supported rates: 24.0 36.0 48.0 54.0
> Extended capabilities:
> * Extended Channel Switching
> * Multiple BSSID
> * SSID List
> * Operating Mode Notification
I guess this is the one you expect?
> BSS 02:00:00:00:04:00(on sta1-wlan0)
> TSF: 1566905274269230 usec (18135d, 11:27:54)
> freq: 5180
[...]
> BSS 02:00:00:00:04:00(on sta1-wlan0)
> TSF: 1566905274269230 usec (18135d, 11:27:54)
> freq: 5200
and these are garbage.
> and so on (please notice that channel number and frequency)..
> iw dev scan returns all the 5Ghz frequencies defined in
> https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c#L328
> It happens only when wmediumd is being used.
Since you cannot reproduce this without wmediumd (and neither can I) I
assume it's a wmediumd bug, in the sense that it's reporting the frame
on all the channels, or perhaps without any channel information, or so?
Or possibly the hwsim code that handles this is broken, maybe you could
see what wmediumd does (does it have any log files?)
johannes
^ 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