[PATCH] mwifiex: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 drivers/net/wireless/marvell/mwifiex/scan.c | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 54a2297..16a705d 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -1158,6 +1158,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy, case NL80211_IFTYPE_UNSPECIFIED: mwifiex_dbg(priv->adapter, INFO, "%s: kept type as IBSS\n", dev->name); + /* fall through */ case NL80211_IFTYPE_ADHOC: /* This shouldn't happen */ return 0; default: @@ -1188,6 +1189,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy, case NL80211_IFTYPE_UNSPECIFIED: mwifiex_dbg(priv->adapter, INFO, "%s: kept type as STA\n", dev->name); + /* fall through */ case NL80211_IFTYPE_STATION:/* This shouldn't happen */ return 0; default: @@ -1210,6 +1212,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy, case NL80211_IFTYPE_UNSPECIFIED: mwifiex_dbg(priv->adapter, INFO, "%s: kept type as AP\n", dev->name); + /* fall through */ case NL80211_IFTYPE_AP: /* This shouldn't happen */ return 0; default: @@ -1249,6 +1252,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy, case NL80211_IFTYPE_UNSPECIFIED: mwifiex_dbg(priv->adapter, INFO, "%s: kept type as P2P\n", dev->name); + /* fall through */ case NL80211_IFTYPE_P2P_CLIENT: case NL80211_IFTYPE_P2P_GO: return 0; diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c index d7ce7f7..19df92b 100644 --- a/drivers/net/wireless/marvell/mwifiex/scan.c +++ b/drivers/net/wireless/marvell/mwifiex/scan.c @@ -1308,6 +1308,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter, case WLAN_EID_CHANNEL_SWITCH: bss_entry->chan_sw_ie_present = true; + /* fall through */ case WLAN_EID_PWR_CAPABILITY: case WLAN_EID_TPC_REPORT: case WLAN_EID_QUIET: -- 2.7.4
[PATCH] ath9k: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 ++
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 1 +
drivers/net/wireless/ath/ath9k/main.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 7922550..ef2dd68 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -583,12 +583,14 @@ static void ar5008_hw_init_chain_masks(struct ath_hw *ah)
case 0x5:
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
AR_PHY_SWAP_ALT_CHAIN);
+ /* fall through */
case 0x3:
if (ah->hw_version.macVersion == AR_SREV_REVISION_5416_10) {
REG_WRITE(ah, AR_PHY_RX_CHAINMASK, 0x7);
REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, 0x7);
break;
}
+ /* else: fall through */
case 0x1:
case 0x2:
case 0x7:
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 61a9b85..7132918 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -119,6 +119,7 @@ static int ar9002_hw_set_channel(struct ath_hw *ah, struct
ath9k_channel *chan)
aModeRefSel = 2;
if (aModeRefSel)
break;
+ /* else: fall through */
case 1:
default:
aModeRefSel = 0;
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index a3be8ad..11d84f4 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1928,6 +1928,7 @@ static int ath9k_ampdu_action(struct ieee80211_hw *hw,
case IEEE80211_AMPDU_TX_STOP_FLUSH:
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
flush = true;
+ /* fall through */
case IEEE80211_AMPDU_TX_STOP_CONT:
ath9k_ps_wakeup(sc);
ath_tx_aggr_stop(sc, sta, tid);
--
2.7.4
Re: Atheros AR9462 - 5Ghz not working
Sedat Dilek wrote: > On Tue, May 22, 2018 at 7:21 PM, wrote: > > I've run out of ideas and am hoping someone here can help. > > > > All I want to do is connect a client to my 5Ghz network. > > > > My client: > > OS is Debian stable "Stretch" with sysvinit instead of systemd > > Atheros AR9462 (World roaming 0x64 regdomain in EEPROM) > > "iw reg set US" > > "iw list" shows both 2.4Ghz and 5Ghz bands available. > > "iw wlp3s0 survey dump" shows received traffic on 5Ghz bands. > > > > There are oodles of 5Ghz AP's within range, but scans (including passive > > scans) reveal only 2.4Ghz networks. My only guess was that it won't > > transmit due to regulatory requirements, but I cannot make it work. > > > > What I've tried: > > Running with and without CRDA > > Running latest mainline kernel > > Hacking around on the ath9k driver and nl80211 to remove all regulatory > > enforcement. > > > > Nothing works and I'm pulling my hair out. Any help would be greatly > > appreciated. > > Hi, > > I try to give some initial help. > > The linux-wireless driver is supported by ath9k driver see [1] and [2]. > > Unfortunately, you have not sent any log-files at least your dmesg-log. > No output of the above userspace commands or userspace-tools versions. > No information to VendorID/ProductID (PCI, USB, whatever). > It's not clear to me if this is a kernelspace (ath9k-driver) or > userspace (CRDA/regulatory) problem. > How should someone help you effectively? > > The linux-wireless wiki has somne informations on how to debug > Atheros/Qualcomm ath9k-driver, see [3]. > > As a debianist I say try Linux v4.16 Debian packages from > stretch-backports (and maybe a higher version of wireless-regdb). > > Try to ask questions the smart way [4] :-). > > Hope this helps. > > Regards, > - Sedat - > > [1] https://wireless.wiki.kernel.org/en/users/drivers/ath9k > [2] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/devices > [3] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/debug > [4] http://www.catb.org/esr/faqs/smart-questions.html Including dmesg | grep 'ath:' output: [ 24.603097] ath: phy0: TPC[00] 0x [ 24.603098] ath: phy0: TPC[01] 0x [ 24.603098] ath: phy0: TPC[02] 0x [ 24.603099] ath: phy0: TPC[03] 0x [ 24.603099] ath: phy0: TPC[04] 0x [ 24.603100] ath: phy0: TPC[05] 0x [ 24.603100] ath: phy0: TPC[06] 0x [ 24.603101] ath: phy0: TPC[07] 0x [ 24.603101] ath: phy0: TPC[08] 0x [ 24.603102] ath: phy0: TPC[09] 0x [ 24.603102] ath: phy0: TPC[10] 0x [ 24.603103] ath: phy0: TPC[11] 0x [ 24.603103] ath: phy0: TPC[12] 0x [ 24.603104] ath: phy0: TPC[13] 0x [ 24.603104] ath: phy0: TPC[14] 0x [ 24.603105] ath: phy0: TPC[15] 0x [ 24.603105] ath: phy0: TPC[16] 0x [ 24.603106] ath: phy0: TPC[17] 0x [ 24.603106] ath: phy0: TPC[18] 0x [ 24.603107] ath: phy0: TPC[19] 0x [ 24.603107] ath: phy0: TPC[20] 0x [ 24.603108] ath: phy0: TPC[21] 0x [ 24.603108] ath: phy0: TPC[22] 0x [ 24.603109] ath: phy0: TPC[23] 0x [ 24.603109] ath: phy0: TPC[24] 0x [ 24.603110] ath: phy0: TPC[25] 0x [ 24.603110] ath: phy0: TPC[26] 0x [ 24.603111] ath: phy0: TPC[27] 0x [ 24.603111] ath: phy0: TPC[28] 0x [ 24.603112] ath: phy0: TPC[29] 0x [ 24.603112] ath: phy0: TPC[30] 0x [ 24.603113] ath: phy0: TPC[31] 0x [ 24.603113] ath: phy0: TPC[32] 0x [ 24.603114] ath: phy0: TPC[33] 0x [ 24.603114] ath: phy0: TPC[34] 0x [ 24.603115] ath: phy0: TPC[35] 0x [ 24.603117] ath: phy0: ch=0 f=2412 low=2412 -21 h=2412 -21 [ 24.603117] ath: phy0: ch=1 f=2412 low=2412 -15 h=2412 -15 [ 24.603118] ath: phy0: ch=2 f=2412 low=2412 0 h=2412 0 [ 24.603129] ath: phy0: for frequency=2412, calibration correction = -21 -15 0 [ 24.603130] ath: phy0: MCI Reset (full_sleep = 0, is_2g = 1) [ 24.603782] ath: phy0: MCI Wait for Reg 0x1838 = 0x0800 timeout [ 24.603785] ath: phy0: MCI INT_RAW = 0x, RX_MSG_RAW = 0x [ 24.603873] ath: phy0: Reset TX queue: 0 [ 24.603874] ath: phy0: tx ok 0x38f err 0x38f desc 0x0 eol 0x0 urn 0x0 [ 24.603875] ath: phy0: Reset TX queue: 1 [ 24.603876] ath: phy0: tx ok 0x38f err 0x38f desc 0x0 eol 0x0 urn 0x0 [ 24.603876] ath: phy0: Reset TX queue: 2 [ 24.603878] ath: phy0: tx ok 0x38f err 0x38f desc 0x0 eol 0x0 urn 0x0 [ 24.603878] ath: phy0: Reset TX queue: 3 [ 24.603879] ath: phy0: tx ok 0x38f err 0x38f desc 0x0 eol 0x0 urn 0x0 [ 24.603880] ath: phy0: Reset TXQ, inactive queue: 4 [ 24.603880] ath: phy0: Reset TXQ, inactive queue: 5 [ 24.603881] ath: phy0: Reset TXQ, inactive queue: 6 [ 24.603881] ath: phy0: Reset TX queue: 7 [ 24.603893] ath: phy0: tx ok 0x38f err 0x38f desc 0x0 eol 0x0 urn 0x0 [ 24.603894
Re: Atheros AR9462 - 5Ghz not working
Sedat Dilek wrote: > On Tue, May 22, 2018 at 7:21 PM, wrote: > > I've run out of ideas and am hoping someone here can help. > > > > All I want to do is connect a client to my 5Ghz network. > > > > My client: > > OS is Debian stable "Stretch" with sysvinit instead of systemd > > Atheros AR9462 (World roaming 0x64 regdomain in EEPROM) > > "iw reg set US" > > "iw list" shows both 2.4Ghz and 5Ghz bands available. > > "iw wlp3s0 survey dump" shows received traffic on 5Ghz bands. > > > > There are oodles of 5Ghz AP's within range, but scans (including passive > > scans) reveal only 2.4Ghz networks. My only guess was that it won't > > transmit due to regulatory requirements, but I cannot make it work. > > > > What I've tried: > > Running with and without CRDA > > Running latest mainline kernel > > Hacking around on the ath9k driver and nl80211 to remove all regulatory > > enforcement. > > > > Nothing works and I'm pulling my hair out. Any help would be greatly > > appreciated. > > Hi, > > I try to give some initial help. > > The linux-wireless driver is supported by ath9k driver see [1] and [2]. > > Unfortunately, you have not sent any log-files at least your dmesg-log. > No output of the above userspace commands or userspace-tools versions. > No information to VendorID/ProductID (PCI, USB, whatever). > It's not clear to me if this is a kernelspace (ath9k-driver) or > userspace (CRDA/regulatory) problem. > How should someone help you effectively? > > The linux-wireless wiki has somne informations on how to debug > Atheros/Qualcomm ath9k-driver, see [3]. > > As a debianist I say try Linux v4.16 Debian packages from > stretch-backports (and maybe a higher version of wireless-regdb). > > Try to ask questions the smart way [4] :-). > > Hope this helps. > > Regards, > - Sedat - > > [1] https://wireless.wiki.kernel.org/en/users/drivers/ath9k > [2] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/devices > [3] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/debug > [4] http://www.catb.org/esr/faqs/smart-questions.html Here's everything you asked for (How could I know what to send until someone told me?): kernel 4.9.88 iw version 4.9 crda 3.18 wireless-regdb 2016-6-10 Everything is stock debian stable except the kernel, but like I said before: completely different operating systems have the same problem. /sys/kernel/debug/ieee80211/phy0/ath9k/base_eeprom EEPROM Version : 2 RegDomain1 :106 RegDomain2 : 31 TX Mask : 3 RX Mask : 3 Allow 5GHz : 1 Allow 2GHz : 1 Disable 2GHz HT20 : 0 Disable 2GHz HT40 : 0 Disable 5Ghz HT20 : 0 Disable 5Ghz HT40 : 0 Big Endian : 0 RF Silent : 45 BT option : 0 Device Cap : 0 Device Type : 5 Power Table Offset : 0 Tuning Caps1 : 72 Tuning Caps2 : 0 Enable Tx Temp Comp : 1 Enable Tx Volt Comp : 0 Enable fast clock : 1 Enable doubling : 1 Internal regulator : 1 Enable Paprd : 1 Driver Strength : 0 Quick Drop : 1 Chain mask Reduce : 0 Write enable Gpio : 6 WLAN Disable Gpio : 0 WLAN LED Gpio : 8 Rx Band Select Gpio :255 Tx Gain : 1 Rx Gain : 1 SW Reg : 303972982 MacAddress : 74:c6:3b:bf:90:a3 /sys/kernel/debug/ieee80211/phy0/ath9k/base_eeprom 2GHz modal Header : Chain0 Ant. Control :336 Chain1 Ant. Control :336 Chain2 Ant. Control : 16 Ant. Common Control :4195664 Ant. Common Control2 : 139810 Ant. Gain : 0 Switch Settle : 44 Chain0 xatten1DB : 0 Chain1 xatten1DB : 0 Chain2 xatten1DB : 0 Chain0 xatten1Margin : 0 Chain1 xatten1Margin : 0 Chain2 xatten1Margin : 0 Temp Slope : 25 Volt Slope : 0 spur Channels0 :164 spur Channels1 : 0 spur Channels2 : 0 spur Channels3 : 0 spur Channels4 : 0 Chain0 NF Threshold : -1 Chain1 NF Threshold : 0 Chain2 NF Threshold : 0 Quick Drop : 0 txEndToXpaOff : 0 xPA Bias Level : 0 txFrameToDataStart : 14 txFrameToPaOn : 14 txFrameToXpaOn : 14 txClip : 3 ADC Desired size :-30 5GHz modal Header : Chain0 Ant. Control :336 Chain1 Ant. Control :336 Chain2 Ant. Control : 80 Ant. Common Control :8390784 Ant. Common Control2 : 139
[PATCH] mwifiex: skip sending GT_REKEY_OFFLOAD_CFG if firmware has no support
If firmware does not support embedded supplicant, then it in turn
will not support GT rekey offloading. If this is the case, then
driver must not advertise WOWLAN flags related to GTK rekey and
it must also skip sending the GT_REKEY_OFFLOAD_CFG command.
Signed-off-by: Shrenik Shikhare
Signed-off-by: Cathy Luo
Signed-off-by: Ganapathi Bhat
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 18 +-
drivers/net/wireless/marvell/mwifiex/fw.h| 1 +
drivers/net/wireless/marvell/mwifiex/sta_event.c | 3 +++
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 54a2297..d04a599 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3555,6 +3555,9 @@ static int mwifiex_set_rekey_data(struct wiphy *wiphy,
struct net_device *dev,
{
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ if (!ISSUPP_FIRMWARE_SUPPLICANT(priv->adapter->fw_cap_info))
+ return -EOPNOTSUPP;
+
return mwifiex_send_cmd(priv, HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG,
HostCmd_ACT_GEN_SET, 0, data, true);
}
@@ -4190,6 +4193,16 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy, struct
wireless_dev *wdev,
.max_pkt_offset = MWIFIEX_MAX_OFFSET_LEN,
.max_nd_match_sets = MWIFIEX_MAX_ND_MATCH_SETS,
};
+
+static const struct wiphy_wowlan_support mwifiex_wowlan_support_no_gtk = {
+ .flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT |
+WIPHY_WOWLAN_NET_DETECT,
+ .n_patterns = MWIFIEX_MEF_MAX_FILTERS,
+ .pattern_min_len = 1,
+ .pattern_max_len = MWIFIEX_MAX_PATTERN_LEN,
+ .max_pkt_offset = MWIFIEX_MAX_OFFSET_LEN,
+ .max_nd_match_sets = MWIFIEX_MAX_ND_MATCH_SETS,
+};
#endif
static bool mwifiex_is_valid_alpha2(const char *alpha2)
@@ -4308,7 +4321,10 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter
*adapter)
WIPHY_FLAG_TDLS_EXTERNAL_SETUP;
#ifdef CONFIG_PM
- wiphy->wowlan = &mwifiex_wowlan_support;
+ if (ISSUPP_FIRMWARE_SUPPLICANT(priv->adapter->fw_cap_info))
+ wiphy->wowlan = &mwifiex_wowlan_support;
+ else
+ wiphy->wowlan = &mwifiex_wowlan_support_no_gtk;
#endif
wiphy->coalesce = &mwifiex_coalesce_support;
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h
b/drivers/net/wireless/marvell/mwifiex/fw.h
index c5dc518..b73f99d 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -249,6 +249,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define ISSUPP_SDIO_SPA_ENABLED(FwCapInfo) (FwCapInfo & BIT(16))
#define ISSUPP_ADHOC_ENABLED(FwCapInfo) (FwCapInfo & BIT(25))
#define ISSUPP_RANDOM_MAC(FwCapInfo) (FwCapInfo & BIT(27))
+#define ISSUPP_FIRMWARE_SUPPLICANT(FwCapInfo) (FwCapInfo & BIT(21))
#define MWIFIEX_DEF_HT_CAP (IEEE80211_HT_CAP_DSSSCCK40 | \
(1 << IEEE80211_HT_CAP_RX_STBC_SHIFT) | \
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c
b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 93dfb76..03a6492 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -241,6 +241,9 @@ void mwifiex_reset_connect_state(struct mwifiex_private
*priv, u16 reason_code,
if (netif_carrier_ok(priv->netdev))
netif_carrier_off(priv->netdev);
+ if (!ISSUPP_FIRMWARE_SUPPLICANT(priv->adapter->fw_cap_info))
+ return;
+
mwifiex_send_cmd(priv, HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG,
HostCmd_ACT_GEN_REMOVE, 0, NULL, false);
}
--
1.9.1
Re: [RFC 1/3] cfg80211: Add support for HE
Arend,
On Fri, 2018-05-25 at 13:11 +0300, Luca Coelho wrote:
> On Mon, 2018-05-21 at 21:47 +0200, Arend van Spriel wrote:
> > On 5/18/2018 4:05 PM, Luca Coelho wrote:
> > > @@ -781,6 +783,23 @@ int wiphy_register(struct wiphy *wiphy)
> > > sband->channels[i].band = band;
> > > }
> > >
> > > + for (i = 0; i < sband->n_iftype_data; i++) {
> > > + const struct ieee80211_sband_iftype_data
> > > *iftd;
> > > +
> > > + iftd = &sband->iftype_data[i];
> > > +
> > > + if (WARN_ON(!iftd->types))
> > > + return -EINVAL;
> > > + if (WARN_ON(types & iftd->types))
> > > + return -EINVAL;
> >
> > I suspected the types mask was not allowed to overlap for the
> > iftype_data entries, but may be worth documenting that in struct
> > ieee80211_sband_iftype_data kerneldoc.
>
> Sure, I'll add it.
Actually, looking into this again, I'm not sure I understand your
comment. AFAICT this prevents the same type from appearing twice,
right? I don't get the "not allowed to overlap"... Can you clarify?
--
Cheers,
Luca.
Re: [PATCH v2] ath6kl: mark expected switch fall-throughs
On 05/25/2018 01:27 PM, Steve deRosier wrote:
On Fri, May 25, 2018 at 11:23 AM Gustavo A. R. Silva
wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Place code comments on a line of their own.
drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 2ba8cf3..a16ee5d 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3899,16 +3899,19 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
switch (ar->hw.cap) {
case WMI_11AN_CAP:
ht = true;
+ /* fall through */
case WMI_11A_CAP:
band_5gig = true;
break;
case WMI_11GN_CAP:
ht = true;
+ /* fall through */
case WMI_11G_CAP:
band_2gig = true;
break;
case WMI_11AGN_CAP:
ht = true;
+ /* fall through */
case WMI_11AG_CAP:
band_2gig = true;
band_5gig = true;
--
2.7.4
Gustavo,
Thanks for the adjustment. It now looks good to me.
Glad to help. :)
Reviewed-by: Steve deRosier
Thanks
--
Gustavo
Re: [PATCH] ath6kl: mark expected switch fall-throughs
On 05/25/2018 01:10 PM, Kalle Valo wrote: Yeah, I was wondering the same. Was there a particular reason for this? Sometimes people use this style for a one-line code block. I can change it to the traditional style. No problem. I would prefer that. So if you can send v2 that would be great. Yep. No problem. I'll send it shortly. Thanks -- Gustavo
Re: [PATCH v2] ath6kl: mark expected switch fall-throughs
On Fri, May 25, 2018 at 11:23 AM Gustavo A. R. Silva
wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> Signed-off-by: Gustavo A. R. Silva
> ---
> Changes in v2:
>- Place code comments on a line of their own.
>drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +++
>1 file changed, 3 insertions(+)
> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> index 2ba8cf3..a16ee5d 100644
> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> @@ -3899,16 +3899,19 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
> switch (ar->hw.cap) {
> case WMI_11AN_CAP:
> ht = true;
> + /* fall through */
> case WMI_11A_CAP:
> band_5gig = true;
> break;
> case WMI_11GN_CAP:
> ht = true;
> + /* fall through */
> case WMI_11G_CAP:
> band_2gig = true;
> break;
> case WMI_11AGN_CAP:
> ht = true;
> + /* fall through */
> case WMI_11AG_CAP:
> band_2gig = true;
> band_5gig = true;
> --
> 2.7.4
Gustavo,
Thanks for the adjustment. It now looks good to me.
Reviewed-by: Steve deRosier
[PATCH v2] ath6kl: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Place code comments on a line of their own.
drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 2ba8cf3..a16ee5d 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3899,16 +3899,19 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
switch (ar->hw.cap) {
case WMI_11AN_CAP:
ht = true;
+ /* fall through */
case WMI_11A_CAP:
band_5gig = true;
break;
case WMI_11GN_CAP:
ht = true;
+ /* fall through */
case WMI_11G_CAP:
band_2gig = true;
break;
case WMI_11AGN_CAP:
ht = true;
+ /* fall through */
case WMI_11AG_CAP:
band_2gig = true;
band_5gig = true;
--
2.7.4
Re: [PATCH] ath6kl: mark expected switch fall-throughs
On 05/25/2018 08:30 AM, Kalle Valo wrote:
Sergei Shtylyov writes:
On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 2ba8cf3..29e32cd 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
switch (ar->hw.cap) {
case WMI_11AN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11A_CAP:
band_5gig = true;
break;
case WMI_11GN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11G_CAP:
band_2gig = true;
break;
case WMI_11AGN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11AG_CAP:
band_2gig = true;
band_5gig = true;
Hm, typically such comments are done on a line of their own, have
never seen this style...
Yeah, I was wondering the same. Was there a particular reason for this?
Sometimes people use this style for a one-line code block.
I can change it to the traditional style. No problem.
Thanks
--
Gustavo
Re: [PATCH] ath6kl: mark expected switch fall-throughs
"Gustavo A. R. Silva" writes:
> On 05/25/2018 08:30 AM, Kalle Valo wrote:
>> Sergei Shtylyov writes:
>>
>>> On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
>>>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 2ba8cf3..29e32cd 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
switch (ar->hw.cap) {
case WMI_11AN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11A_CAP:
band_5gig = true;
break;
case WMI_11GN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11G_CAP:
band_2gig = true;
break;
case WMI_11AGN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11AG_CAP:
band_2gig = true;
band_5gig = true;
>>>
>>> Hm, typically such comments are done on a line of their own, have
>>> never seen this style...
>>
>> Yeah, I was wondering the same. Was there a particular reason for this?
>>
>
> Sometimes people use this style for a one-line code block.
>
> I can change it to the traditional style. No problem.
I would prefer that. So if you can send v2 that would be great.
--
Kalle Valo
Re: Atheros AR9462 - 5Ghz not working
On Tue, May 22, 2018 at 7:21 PM, wrote: > I've run out of ideas and am hoping someone here can help. > > All I want to do is connect a client to my 5Ghz network. > > My client: > OS is Debian stable "Stretch" with sysvinit instead of systemd > Atheros AR9462 (World roaming 0x64 regdomain in EEPROM) > "iw reg set US" > "iw list" shows both 2.4Ghz and 5Ghz bands available. > "iw wlp3s0 survey dump" shows received traffic on 5Ghz bands. > > There are oodles of 5Ghz AP's within range, but scans (including passive > scans) reveal only 2.4Ghz networks. My only guess was that it won't transmit > due to regulatory requirements, but I cannot make it work. > > What I've tried: > Running with and without CRDA > Running latest mainline kernel > Hacking around on the ath9k driver and nl80211 to remove all regulatory > enforcement. > > Nothing works and I'm pulling my hair out. Any help would be greatly > appreciated. Hi, I try to give some initial help. The linux-wireless driver is supported by ath9k driver see [1] and [2]. Unfortunately, you have not sent any log-files at least your dmesg-log. No output of the above userspace commands or userspace-tools versions. No information to VendorID/ProductID (PCI, USB, whatever). It's not clear to me if this is a kernelspace (ath9k-driver) or userspace (CRDA/regulatory) problem. How should someone help you effectively? The linux-wireless wiki has somne informations on how to debug Atheros/Qualcomm ath9k-driver, see [3]. As a debianist I say try Linux v4.16 Debian packages from stretch-backports (and maybe a higher version of wireless-regdb). Try to ask questions the smart way [4] :-). Hope this helps. Regards, - Sedat - [1] https://wireless.wiki.kernel.org/en/users/drivers/ath9k [2] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/devices [3] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/debug [4] http://www.catb.org/esr/faqs/smart-questions.html
Re: [PATCH] wireless-regdb: Fix iteration in create_wmms() for python 3
On Fri, May 18, 2018 at 12:17:25PM -0500, Seth Forshee wrote: > The iteration in this function is over countries.itervalues(), > which is not compatible with python 3. Switch to iterating over > contries.values() instead. > > Signed-off-by: Seth Forshee Applied.
Re: [PATCH] wireless-regdb: Fix comparison of WmmRule with NoneType in python 3
On Fri, May 18, 2018 at 09:47:01AM -0500, Seth Forshee wrote: > Python 3 gives errors as a result of the changes to add wmm > rules since Permission.wmmrule can be set to None: > > TypeError: '<' not supported between instances of 'WmmRule' and 'NoneType' > > To fix this, supply compairson methods for WmmRule instead of > using the ones provided by attrs. Doing this means we also need > to supply a __hash__ method. > > Signed-off-by: Seth Forshee Applied.
Re: [PATCH] wireless-regdb: Update rules for Panama (PA) and add 60 GHz rule
On Fri, May 18, 2018 at 09:46:41AM -0500, Seth Forshee wrote: > Updates are based on the information in > http://www.asep.gob.pa/images/telecomunicaciones/Anexos/PNAF-dic2015.pdf. > > Signed-off-by: Seth Forshee Applied.
Re: [PATCH] wireless-regdb: Add 5725-5875 MHz rule for France (FR)
On Tue, May 15, 2018 at 02:11:26PM -0500, Seth Forshee wrote: > Based on [1] and [2], use of short range devices in this range > is now permitted in France. Add a rule for this range, using the > power limit of 25 dBm as specified in these documents and in > ETSI EN 300 440. > > [1] https://www.arcep.fr/uploads/tx_gsavis/14-1263.pdf > [2] https://www.arcep.fr/uploads/tx_gsavis/14-1263.pdf > > Signed-off-by: Seth Forshee Applied.
Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares
On 05/25/2018 07:44 AM, Kalle Valo wrote: Sebastian Gottschall writes: Am 26.04.2018 um 15:44 schrieb Ben Greear: On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote: From: Sebastian Gottschall starting with firmware 10.4.3.4.x series QCA changed the handling of the channel property band_center_freq1 and band_center_freq2 in vht160 operation mode likelly for backward compatiblity with vht80 only capable clients. this patch adjusts the handling to get vht160 to work again with official qca firmwares newer than 3.3 consider that this patch will not work with older firmwares anymore. to avoid undefined behaviour this we disable vht160 capability for outdated firmwares We should be able to use a feature-flag or otherwise determine if the firmware needs the old or new API and make the driver able to handle both. the new firmware must be used as is and it works. the old firmware can be detected on the missing vht cap flag. but thats not my task. i can only use feature flags if they are included within the qca firmwares. but they arent the old pre 3.3 firmwares should be treated as obsolete. they are more than 2 years old and do not announce vht160 capability even if it works with some ignorance, but on the other side the it has backward incompatiblies with older vht80 only clients. this is why the new way was introduced I was told ath10k could check for WMI_SERVICE_EXTENDED_NSS_SUPPORT flag. Can someone test and verify that? I do see that my firmware source based on older upstream QCA FW does not advertise that flag, and newer QCA firmware does, so it would appear that test might work. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares
Sebastian Gottschall writes: > Am 26.04.2018 um 15:44 schrieb Ben Greear: >> >> >> On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote: >>> From: Sebastian Gottschall >>> >>> starting with firmware 10.4.3.4.x series QCA changed the handling >>> of the channel property band_center_freq1 and band_center_freq2 in >>> vht160 operation mode >>> likelly for backward compatiblity with vht80 only capable clients. >>> this patch adjusts the handling to get vht160 to work again with >>> official qca firmwares newer than 3.3 >>> consider that this patch will not work with older firmwares >>> anymore. to avoid undefined behaviour this we disable vht160 >>> capability for outdated firmwares >> >> We should be able to use a feature-flag or otherwise determine if >> the firmware needs the old or new >> API and make the driver able to handle both. > > the new firmware must be used as is and it works. the old firmware can > be detected on the missing vht cap flag. > but thats not my task. i can only use feature flags if they are > included within the qca firmwares. but they arent > the old pre 3.3 firmwares should be treated as obsolete. they are more > than 2 years old and do not announce vht160 capability > even if it works with some ignorance, but on the other side the it has > backward incompatiblies with older vht80 only clients. > this is why the new way was introduced I was told ath10k could check for WMI_SERVICE_EXTENDED_NSS_SUPPORT flag. Can someone test and verify that? -- Kalle Valo
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Fri, May 25, 2018 at 08:50:23AM -0400, Bob Copeland wrote: > On Fri, May 25, 2018 at 02:36:56PM +0200, Niklas Cassel wrote: > > A spin lock does have the advantage of ordering: memory operations issued > > before the spin_unlock_bh() will be completed before the spin_unlock_bh() > > operation has completed. > > > > However, ath10k_htt_tx_dec_pending() was called earlier in the same > > function, > > which decreases htt->num_pending_tx, so that write will be completed before > > our read. That is the only ordering we care about here (if we should call > > ath10k_mac_tx_push_pending() or not). > > Sure. I also understand that reading inside a lock and operating on the > value outside the lock isn't really the definition of synchronization > (doesn't really matter in this case though). > > I was just suggesting that the implicit memory barrier in the spin unlock > that we are already paying for would be sufficient here too, and it matches > the semantic of "tx fields under tx_lock." On the other hand, maybe it's > just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled > about. I agree, because of the implicit memory barrier from spin_unlock_bh(), READ_ONCE shouldn't really be needed in this case. I think that it's a good thing to be critical of all "just-in-case" things, however, it's not always that obvious if you actually need READ_ONCE or not. E.g. you might need to use it even when you are holding a spin_lock. Some people recommend to use it for all concurrent non-read-only shared memory accesses: https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE Is there a better guideline somewhere..? Kind regards, Niklas
Re: [PATCH] ath6kl: mark expected switch fall-throughs
Sergei Shtylyov writes:
> On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Signed-off-by: Gustavo A. R. Silva
>> ---
>> drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> index 2ba8cf3..29e32cd 100644
>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> @@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
>> wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
>> switch (ar->hw.cap) {
>> case WMI_11AN_CAP:
>> -ht = true;
>> +ht = true; /* fall through */
>> case WMI_11A_CAP:
>> band_5gig = true;
>> break;
>> case WMI_11GN_CAP:
>> -ht = true;
>> +ht = true; /* fall through */
>> case WMI_11G_CAP:
>> band_2gig = true;
>> break;
>> case WMI_11AGN_CAP:
>> -ht = true;
>> +ht = true; /* fall through */
>> case WMI_11AG_CAP:
>> band_2gig = true;
>> band_5gig = true;
>
>Hm, typically such comments are done on a line of their own, have
> never seen this style...
Yeah, I was wondering the same. Was there a particular reason for this?
--
Kalle Valo
Re: [PATCH] mac80211: Move up init of TXQs
Niklas Cassel writes: > Tested-by: Niklas Cassel Great, thanks! -Toke
Re: [PATCH] mac80211: Move up init of TXQs
Tested-by: Niklas Cassel
On Fri, May 25, 2018 at 02:29:21PM +0200, Toke Høiland-Jørgensen wrote:
> On init, ieee80211_if_add() dumps the interface. Since that now includes a
> dump of the TXQ state, we need to initialise that before the dump happens.
> So move up the TXQ initialisation to to before the call to
> ieee80211_if_add().
>
> Fixes: 52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")
> Reported-by: Niklas Cassel
> Signed-off-by: Toke Høiland-Jørgensen
> ---
> net/mac80211/main.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 4d2e797e3f16..722f3d9fb416 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -1098,6 +1098,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>
> ieee80211_led_init(local);
>
> + result = ieee80211_txq_setup_flows(local);
> + if (result)
> + goto fail_flows;
> +
> rtnl_lock();
>
> result = ieee80211_init_rate_ctrl_alg(local,
> @@ -1120,10 +1124,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>
> rtnl_unlock();
>
> - result = ieee80211_txq_setup_flows(local);
> - if (result)
> - goto fail_flows;
> -
> #ifdef CONFIG_INET
> local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
> result = register_inetaddr_notifier(&local->ifa_notifier);
> @@ -1149,8 +1149,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> #if defined(CONFIG_INET) || defined(CONFIG_IPV6)
> fail_ifa:
> #endif
> - ieee80211_txq_teardown_flows(local);
> - fail_flows:
> rtnl_lock();
> rate_control_deinitialize(local);
> ieee80211_remove_interfaces(local);
> @@ -1158,6 +1156,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> rtnl_unlock();
> ieee80211_led_exit(local);
> ieee80211_wep_free(local);
> + ieee80211_txq_teardown_flows(local);
> + fail_flows:
> destroy_workqueue(local->workqueue);
> fail_workqueue:
> wiphy_unregister(local->hw.wiphy);
>
Re: Can no one help me?
P.S. If anyone wants to take a crack at it, I'd gladly send them one of the cards. Keep in mind they're A and E keyed M.2 cards. Otherwise I'm just going to toss them.
Re: Can no one help me?
Thanks for the reply. My first message to the list did have more information. I've tried the latest mainline kernel and also the default kernel for Debian stable and multiple other distros (Ubuntu, Arch, etc). The cards (I have several of the same model) are AR9462 in an M.2 NGFF format using the ath9k driver with 0x64 world roaming regdomain in EEPROM and US regdomain set via crda and iw claims the card supports both bands. No error messages to speak of, just 5GHz networks simply don't show up in scans and can't be associated with despite there being nearly a dozen different 5Ghz networks within range. The card acts like the entire 5Ghz band is NO_IR restricted (incoming packet statistics for 5Ghz via 'iw survey dump' do increment, but tx values are always zero. 2.4Ghz works fine. A custom kernel enabling beacon hints made no difference. I've now come to believe it's not software, but the cards themselves as OS/kernel/hardware seems to make no difference. I even installed them in a different brand/model laptop running MS Windows and got the same results. Since it was incredibly difficult to find an ath9k supported dual band card in M.2 format with a A-key slot needed by my laptop, I'm thinking now maybe the cards are simply faulty or designed incorrectly. These were bought via aliexpress.com and advertised as 5Ghz capable, but I've been unable to locate them anywhere else...all other sources seem to only carry AR9462 as Mini-PCIE, and not M.2 Anyway, I've given up on them. If anyone happens to know of an M.2 A-keyed dual band card supported by an open driver (preferrably no or open firmware too) I'd really appreciate it, but I'm not holding my breath. Again, thanks anyway. Reinoud Koornstra wrote: > What kernels have you tried? What messages do you get? Is the card not > supported? Crash? It's always good to share more info on what you're > experienced. > > On Wed, May 23, 2018, 5:38 PM wrote: > > > I realize this is a development mailinglist and not a support forum, but > > I'm really at the end of my rope here. > > > > If someone can get this working, I'll buy them a nice lunch if they're > > ever near Cincinnati. > > > > I've tried booting alternative distros to see if it is a software problem, > > but no distro I've tried will work. I've even replaced the AR9462 card with > > another one, thinking maybe the hardware was bad...but no change. > > > > Surely someone here has a clue as to what's going on? > > > > Many thanks in advance for any help. > >
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Fri, May 25, 2018 at 02:36:56PM +0200, Niklas Cassel wrote: > A spin lock does have the advantage of ordering: memory operations issued > before the spin_unlock_bh() will be completed before the spin_unlock_bh() > operation has completed. > > However, ath10k_htt_tx_dec_pending() was called earlier in the same function, > which decreases htt->num_pending_tx, so that write will be completed before > our read. That is the only ordering we care about here (if we should call > ath10k_mac_tx_push_pending() or not). Sure. I also understand that reading inside a lock and operating on the value outside the lock isn't really the definition of synchronization (doesn't really matter in this case though). I was just suggesting that the implicit memory barrier in the spin unlock that we are already paying for would be sufficient here too, and it matches the semantic of "tx fields under tx_lock." On the other hand, maybe it's just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled about. -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Thu, May 24, 2018 at 11:50:34AM -0400, Bob Copeland wrote: > On Mon, May 21, 2018 at 10:37:01PM +0200, Niklas Cassel wrote: > > On Thu, May 17, 2018 at 03:26:25PM -0700, Adrian Chadd wrote: > > > On Thu, 17 May 2018 at 16:16, Niklas Cassel > > > wrote: > > > > > > > diff --git a/drivers/net/wireless/ath/ath10k/txrx.c > > > b/drivers/net/wireless/ath/ath10k/txrx.c > > > > index cda164f6e9f6..1d3b2d2c3fee 100644 > > > > --- a/drivers/net/wireless/ath/ath10k/txrx.c > > > > +++ b/drivers/net/wireless/ath/ath10k/txrx.c > > > > @@ -95,6 +95,9 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt, > > > > wake_up(&htt->empty_tx_wq); > > > > spin_unlock_bh(&htt->tx_lock); > > > > > > > + if (htt->num_pending_tx <= 3 && !list_empty(&ar->txqs)) > > > > + ath10k_mac_tx_push_pending(ar); > > > > + > > > > > > Just sanity checking - what's protecting htt->num_pending_tx? or is it > > > serialised some other way? > [...] > > I can't see that any of the examples applies, but let's add READ_ONCE(), > > to make sure that the compiler doesn't try to optimize this. > > Couldn't you just move the num_pending_tx read inside tx_lock which is 2 lines > above? I think all the other manipulations are protected by tx_lock. Hello Bob, There is both a V2 and V3 of this patchset, V3 moves this to a sdio.c and calls ath10k_mac_tx_push_pending() unconditionally. But to answer your question, it shouldn't matter if the read is done while holding the lock or not. Sure, the compiler could do things so that the code path is always or never executed, but that is why I added READ_ONCE() in V2. A spin lock does have the advantage of ordering: memory operations issued before the spin_unlock_bh() will be completed before the spin_unlock_bh() operation has completed. However, ath10k_htt_tx_dec_pending() was called earlier in the same function, which decreases htt->num_pending_tx, so that write will be completed before our read. That is the only ordering we care about here (if we should call ath10k_mac_tx_push_pending() or not). Kind regards, Niklas
Re: [PATCH 5/7] wil6210: add support for enhanced DMA RX data flows
Maya Erez writes: > From: Gidon Studinski > > Enhanced DMA RX data path is handled using a single > RX descriptor ring for all VIFs. > Multiple RX status rings are supported, to allow RSS > and multi MSI support. > The driver gets the RX completions via the RX status rings. > The RX status message includes the completed RX buffer ID, > which points to the allocated SKB. > > The enhanced DMA RX data flow supports RX chaining, where > multiple SKBs are merged into a single packet. > > Enhanced DMA HW supports RX HW reorder offload, enabled by > default and can be disabled via module parameter. > > Signed-off-by: Gidon Studinski > Signed-off-by: Maya Erez kbuild bot reported a warning but not sure if it's valid, please take a look: drivers/net/wireless/ath/wil6210/txrx_edma.c: In function 'wil_rx_handle_edma': >> drivers/net/wireless/ath/wil6210/txrx_edma.c:815:7: warning: 'stats' may be used uninitialized in this function [-Wmaybe-uninitialized] stats->rx_non_data_frame++; ~^~~ drivers/net/wireless/ath/wil6210/txrx_edma.c:908:24: note: 'stats' was declared here struct wil_net_stats *stats; ^ -- Kalle Valo
[PATCH] mac80211: Move up init of TXQs
On init, ieee80211_if_add() dumps the interface. Since that now includes a
dump of the TXQ state, we need to initialise that before the dump happens.
So move up the TXQ initialisation to to before the call to
ieee80211_if_add().
Fixes: 52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")
Reported-by: Niklas Cassel
Signed-off-by: Toke Høiland-Jørgensen
---
net/mac80211/main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 4d2e797e3f16..722f3d9fb416 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1098,6 +1098,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_led_init(local);
+ result = ieee80211_txq_setup_flows(local);
+ if (result)
+ goto fail_flows;
+
rtnl_lock();
result = ieee80211_init_rate_ctrl_alg(local,
@@ -1120,10 +1124,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
rtnl_unlock();
- result = ieee80211_txq_setup_flows(local);
- if (result)
- goto fail_flows;
-
#ifdef CONFIG_INET
local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
result = register_inetaddr_notifier(&local->ifa_notifier);
@@ -1149,8 +1149,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
#if defined(CONFIG_INET) || defined(CONFIG_IPV6)
fail_ifa:
#endif
- ieee80211_txq_teardown_flows(local);
- fail_flows:
rtnl_lock();
rate_control_deinitialize(local);
ieee80211_remove_interfaces(local);
@@ -1158,6 +1156,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
rtnl_unlock();
ieee80211_led_exit(local);
ieee80211_wep_free(local);
+ ieee80211_txq_teardown_flows(local);
+ fail_flows:
destroy_workqueue(local->workqueue);
fail_workqueue:
wiphy_unregister(local->hw.wiphy);
Re: [PATCH 3/7] wil6210: initialize TX and RX enhanced DMA rings
Kalle Valo writes: > Maya Erez writes: > >> From: Gidon Studinski >> >> Enhanced DMA design includes the following rings: >> - Single RX descriptor ring is used for all VIFs >> - Multiple RX status rings are supported, to allow RSS >> - TX descriptor ring is allocated per connection >> - A single TX status ring is used for all TX descriptor rings >> >> This patch initializes and frees the above descriptor and >> status rings. >> >> The RX SKBs are handled by a new entity of RX buffers manager, >> which handles RX buffers, each one points to an allocated SKB. >> During Rx completion processing, the driver extracts a buffer >> ID which is used as an index to the buffers array. >> After the SKB is freed the buffer is moved from the 'active' >> list to the 'free' list, indicating it can be used for another >> descriptor. During Rx refill, SKBs are allocated and attached >> to 'free' buffers. Those buffers are attached to new descriptors >> and moved to the 'active' list. >> >> Signed-off-by: Gidon Studinski >> Signed-off-by: Maya Erez > > [...] > >> --- a/drivers/net/wireless/ath/wil6210/pcie_bus.c >> +++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c >> @@ -32,6 +32,10 @@ >> module_param(ftm_mode, bool, 0444); >> MODULE_PARM_DESC(ftm_mode, " Set factory test mode, default - false"); >> >> +static bool use_enhanced_dma_hw = true; >> +module_param(use_enhanced_dma_hw, bool, 0444); >> +MODULE_PARM_DESC(use_enhanced_dma_hw, " Use enhanced or legacy DMA HW. >> Default: true when available"); > > Similarly as with debugfs, please document in the commit log any changes > in module parameters. Oh, and in this patch there are even more new module parameters and no mention them in the commit log. But a bigger problem is that wil6210 has now 24 module parameters (with this patchset included). That is quite a lot, are those all really needed? Module parameters are bad user experience and there should be good reasons before adding them. -- Kalle Valo
Re: [PATCH 3/7] wil6210: initialize TX and RX enhanced DMA rings
Maya Erez writes: > From: Gidon Studinski > > Enhanced DMA design includes the following rings: > - Single RX descriptor ring is used for all VIFs > - Multiple RX status rings are supported, to allow RSS > - TX descriptor ring is allocated per connection > - A single TX status ring is used for all TX descriptor rings > > This patch initializes and frees the above descriptor and > status rings. > > The RX SKBs are handled by a new entity of RX buffers manager, > which handles RX buffers, each one points to an allocated SKB. > During Rx completion processing, the driver extracts a buffer > ID which is used as an index to the buffers array. > After the SKB is freed the buffer is moved from the 'active' > list to the 'free' list, indicating it can be used for another > descriptor. During Rx refill, SKBs are allocated and attached > to 'free' buffers. Those buffers are attached to new descriptors > and moved to the 'active' list. > > Signed-off-by: Gidon Studinski > Signed-off-by: Maya Erez [...] > --- a/drivers/net/wireless/ath/wil6210/pcie_bus.c > +++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c > @@ -32,6 +32,10 @@ > module_param(ftm_mode, bool, 0444); > MODULE_PARM_DESC(ftm_mode, " Set factory test mode, default - false"); > > +static bool use_enhanced_dma_hw = true; > +module_param(use_enhanced_dma_hw, bool, 0444); > +MODULE_PARM_DESC(use_enhanced_dma_hw, " Use enhanced or legacy DMA HW. > Default: true when available"); Similarly as with debugfs, please document in the commit log any changes in module parameters. -- Kalle Valo
Re: [PATCH 2/7] wil6210: add support for enhanced DMA structures
Maya Erez writes:
> From: Gidon Studinski
>
> In enhanced DMA the vrings are handled internally by the FW
> and are not exposed to the driver.
> Instead, the driver handles descriptor rings, which are mapped
> by the FW to vrings.
> The completions of the TX and RX descriptors are notified to
> the driver using status rings. Each status ring descriptor
> includes information of the completed descriptors and the ring id
> of their descriptor ring.
>
> This patch changes struct vring to generic wil_ring to allow
> its reuse for enhanced DMA descriptor rings and adds the descriptor
> and status rings specific descriptors.
>
> Signed-off-by: Gidon Studinski
> Signed-off-by: Maya Erez
[...]
> @@ -1784,7 +1785,7 @@ static void wil6210_debugfs_init_blobs(struct
> wil6210_priv *wil,
> const struct file_operations *fops;
> } dbg_files[] = {
> {"mbox",0444, &fops_mbox},
> - {"vrings", 0444, &fops_vring},
> + {"rings", 0444, &fops_ring},
When making changes to the debugfs interface please document that in the
in commit log and how the changes look from user space point of view.
Doesn't need to be long but just some sort of overview so that the
reader understands the changes without looking at the code.
--
Kalle Valo
Re: [PATCH] Added support for Dell Wireless 1537 which is an Qualcomm Atheros AR6004X with an sdio ID of 0x19. hardware ID is 0271:0419. And tested it on a Dell Venue 11 Pro 7130 with a compiled kerne
Guy Chronister writes: > Signed-off-by: Guy Chronister The commit log formatting was wrong, I fixed like this in the pending branch (also added the word "self"): ath6kl: add support for Dell Wireless 1537 This is a Qualcomm Atheros AR6004X with an sdio ID of 0x19 and hardware ID of 0271:0419. Tested on a Dell Venue 11 Pro 7130 with a self compiled kernel -- Kalle Valo
Re: [PATCH] ath6kl: mark expected switch fall-throughs
Hello!
On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 2ba8cf3..29e32cd 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
switch (ar->hw.cap) {
case WMI_11AN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11A_CAP:
band_5gig = true;
break;
case WMI_11GN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11G_CAP:
band_2gig = true;
break;
case WMI_11AGN_CAP:
- ht = true;
+ ht = true; /* fall through */
case WMI_11AG_CAP:
band_2gig = true;
band_5gig = true;
Hm, typically such comments are done on a line of their own, have never
seen this style...
MBR, Sergei
[PATCH v4] iw: ack signal support for tx ack packets
This patch is to display the average ack signal,
last ack signal of tx ack packets.
Signed-off-by: Balaji Pothunoori
---
V4:
* Changed the subject
* Added last ack signal support and renamed avg ack signal macro
V3:
* Added version no
V2:
* Removed nl80211.h changes and modified the commit log
station.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/station.c b/station.c
index 38c5f91..fd38043 100644
--- a/station.c
+++ b/station.c
@@ -308,6 +308,8 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_TID_STATS] = { .type = NLA_NESTED },
[NL80211_STA_INFO_BSS_PARAM] = { .type = NLA_NESTED },
[NL80211_STA_INFO_RX_DURATION] = { .type = NLA_U64 },
+ [NL80211_STA_INFO_ACK_SIGNAL] = {.type = NLA_U8 },
+ [NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
};
char *chain;
@@ -409,6 +411,14 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
printf("\n\trx duration:\t%lld us",
(unsigned long
long)nla_get_u64(sinfo[NL80211_STA_INFO_RX_DURATION]));
+ if (sinfo[NL80211_STA_INFO_ACK_SIGNAL])
+ printf("\n\tlast ack signal:%d dBm",
+ (int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_ACK_SIGNAL]));
+
+ if (sinfo[NL80211_STA_INFO_ACK_SIGNAL_AVG])
+ printf("\n\tavg ack signal:\t%d dBm",
+
(int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_ACK_SIGNAL_AVG]));
+
if (sinfo[NL80211_STA_INFO_EXPECTED_THROUGHPUT]) {
uint32_t thr;
--
2.7.4
Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint
Alexei Starovoitov writes: > On Wed, May 23, 2018 at 01:03:08PM +0200, Johannes Berg wrote: >> On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote: >> > fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table >> > instead of all 17 arguments by value. >> > dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table' >> > defined with very similar yet subtly different fields and offsets. >> > tracepoint is still common and using definition of 'struct >> > iwl_error_event_table' >> > from dvm/commands.h while copying fields. >> > Long term this tracepoint probably should be split into two. >> >> It would've been nice to CC the wireless list for wireless related >> patches ... > > Ohh. I didn't realize that networking wireless doesn't fall under netdev. > I thought wireless folks are silent because they are embarrassed > by a function with 17 arguments. Really, this is the level of discussion now? You don't even bother to CC the driver maintainers and your first reaction is that they are just too embarrassed to answer? Oh man... But if you continue doing these kind of "drive-by cleanups" to a subsystem you are not familiar with, at least don't assume anything and instead use get_maintainer script to find the maintainers so that the patches get reviewed and applied to the correct tree: $ scripts/get_maintainer.pl --no-rolestats --no-git -f drivers/net/wireless/intel/iwlwifi/dvm/main.c Johannes Berg Emmanuel Grumbach Luca Coelho Intel Linux Wireless Kalle Valo "David S. Miller" Daniel Borkmann Alexei Starovoitov Kees Cook linux-wireless@vger.kernel.org net...@vger.kernel.org linux-ker...@vger.kernel.org -- Kalle Valo
Re: [RFC 1/3] cfg80211: Add support for HE
On 5/25/2018 12:11 PM, Luca Coelho wrote:
+static int
> >+nl80211_send_ift_data(struct sk_buff *msg,
> >+const struct ieee80211_sband_iftype_data *iftdata)
>
>make it nl80211_send_iftype_data.
Okay, I'll replace all ift instances to iftype.
My comment is mainly about function names.
> > static int nl80211_send_band_rateinfo(struct sk_buff *msg,
> > struct ieee80211_supported_band *sband)
> > {
> >@@ -1353,6 +1383,32 @@ static int nl80211_send_band_rateinfo(struct sk_buff
*msg,
> >sband->vht_cap.cap)))
> > return -ENOBUFS;
> >
> >+ if (sband->n_iftype_data) {
> >+ struct nlattr *nl_iftype_data =
> >+ nla_nest_start(msg, NL80211_BAND_ATTR_IFTYPE_DATA);
> >+ int err;
> >+
> >+ if (!nl_iftype_data)
> >+ return -ENOBUFS;
> >+
> >+ for (i = 0; i < sband->n_iftype_data; i++) {
> >+ struct nlattr *iftdata;
> >+
> >+ iftdata = nla_nest_start(msg, i + 1);
> >+ if (!iftdata)
> >+ return -ENOBUFS;
>
>bit inconsistent dealing with error path. Here errno is returned
>
> >@@ -4490,6 +4549,19 @@ static bool nl80211_put_sta_rate(struct sk_buff *msg,
struct rate_info *info,
> > if (info->flags & RATE_INFO_FLA
return false;
> >+ } else if (info->flags & RATE_INFO_FLAGS_HE_MCS) {
> >+ if (nla_put_u8(msg, NL80211_RATE_INFO_HE_MCS, info->mcs))
> >+ return false;
>
>... and here bool is returned. Admittedly, this seems to have been the
>case already before this patch.
Sure.
> >diff --git a/net/wireless/util.c b/net/wireless/util.c
> >index d112e9a89364..b66a68a41cd6 100644
> >--- a/net/wireless/util.c
> >+++ b/net/wireless/util.c
> >@@ -4,6 +4,7 @@
> >*
> >* Copyright 2007-2009 Johannes Berg
> >* Copyright 2013-2014 Intel Mobile Communications GmbH
> >+ * Copyright 2017 Intel Deutschland GmbH
> >*/
> > #include
> > #include
> >@@ -1142,6 +1143,85 @@ static u32 cfg80211_calculate_bitrate_vht(struct
rate_info *rate)
> > return 0;
> > }
> >
> >+static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate)
> >+{
> >+#define SCALE 2048
> >+ u16 mcs_divisors[12] = {
> >+ 34133, /* 16.66... */
> >+ 17067, /* 8.33... */
> >+ 11378, /* 5.55... */
> >+ 8533, /* 4.16... */
> >+ 5689, /* 2.77... */
> >+ 4267, /* 2.08... */
> >+ 3923, /* 1.851851... */
> >+ 3413, /* 1.66... */
> >+ 2844, /* 1.38... */
> >+ 2560, /* 1.25... */
> >+ 2276, /* 1.11... */
> >+ 2048, /* 1.00... */
> >+ };
> >+ u32 rates_160M[3] = { 96077, 90740, 81666 };
> >+ u32 rates_969[3] = { 48038, 45370, 40833 };
> >+ u32 rates_484[3] = { 22941, 21666, 19500 };
> >+ u32 rates_242[3] = { 11471, 10833, 9750 };
> >+ u32 rates_106[3] = { 4000, 3777, 3400 };
> >+ u32 rates_52[3] = { 1882, 1777, 1600 };
> >+ u32 rates_26[3] = { 941, 888, 800 };
> >+ u64 tmp;
> >+ u32 result;
> >+
> >+ if (WARN_ON_ONCE(rate->mcs > 11))
> >+ return 0;
> >+
> >+ if (WARN_ON_ONCE(rate->he_gi > NL80211_RATE_INFO_HE_GI_3_2))
> >+ return 0;
> >+ if (WARN_ON_ONCE(rate->he_ru_alloc >
> >+ NL80211_RATE_INFO_HE_RU_ALLOC_2x996))
> >+ return 0;
> >+ if (WARN_ON_ONCE(rate->nss < 1 || rate->nss > 8))
> >+ return 0;
> >+
> >+ if (rate->bw == RATE_INFO_BW_160)
> >+ result = rates_160M[rate->he_gi];
> >+ else if (rate->bw == RATE_INFO_BW_80 ||
> >+ (rate->bw == RATE_INFO_BW_HE_RU &&
> >+rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_996))
> >+ result = rates_969[rate->he_gi];
> >+ else if (rate->bw == RATE_INFO_BW_40 ||
> >+ (rate->bw == RATE_INFO_BW_HE_RU &&
> >+rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_484))
> >+ result = rates_484[rate->he_gi];
> >+ else if (rate->bw == RATE_INFO_BW_20 ||
> >+ (rate->bw == RATE_INFO_BW_HE_RU &&
> >+rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_242))
> >+ result = rates_242[rate->he_gi];
> >+ else if (rate->bw == RATE_INFO_BW_HE_RU &&
> >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_106)
> >+ result = rates_106[rate->he_gi];
> >+ else if (rate->bw == RATE_INFO_BW_HE_RU &&
> >+ rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_52)
> >+ result
Re: [PATCH 1/3] brcmfmac: allow specifying features per firmware version
On 5/22/2018 3:18 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Some firmwares support tagging monitor frames, some build radiotap
header but there is no way to detect it.
This commit adds table that will allow specifying features like:
{ "01-abcdef01", BIT(BRCMF_FEAT_FOO) }
Discussed this over here. As we are releasing 4366c1 firmware we could
add a proper flag, but there may be other devices/firmwares that can
support certain features so this approach is an acceptable
alternative (more below)
Signed-off-by: Rafał Miłecki
---
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 24 ++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 876731c57bf5..1194d31d3902 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -91,6 +91,28 @@ static int brcmf_feat_debugfs_read(struct seq_file *seq,
void *data)
}
#endif /* DEBUG */
+struct brcmf_feat_fwfeat {
+ const char * const fwid;
+ u32 flags;
+};
+
+static const struct brcmf_feat_fwfeat brcmf_feat_fwfeat_map[] = {
+};
+
+static void brcmf_feat_firmware_features(struct brcmf_pub *pub)
+{
+ const struct brcmf_feat_fwfeat *e;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(brcmf_feat_fwfeat_map); i++) {
+ e = &brcmf_feat_fwfeat_map[i];
+ if (!strcmp(e->fwid, pub->fwver)) {
+ pub->feat_flags |= e->flags;
... However, let's be more verbose about this here.
Regards,
Arend
Re: [v3] wcn36xx: Add support for Factory Test Mode (FTM)
Ramon Fried wrote: > Introduce infrastructure for supporting Factory Test Mode (FTM) of the > wireless LAN subsystem. In order for the user space to access the > firmware in test mode the relevant netlink channel needs to be exposed > from the kernel driver. > > The above is achieved as follows: > 1) Register wcn36xx driver to testmode callback from netlink > 2) Add testmode callback implementation to handle incoming FTM commands > 3) Add FTM command packet structure > 4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2) > 5) Add generic handling for all PTT_MSG packets > > Signed-off-by: Eyal Ilsar > Signed-off-by: Ramon Fried > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 87f825e6e246 wcn36xx: Add support for Factory Test Mode (FTM) -- https://patchwork.kernel.org/patch/10419423/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCHv2, 1/2] ath: Add support to get the detected radar specifications
Sriram R wrote: > This enables ath10k/ath9k drivers to collect the specifications of the > radar type once it is detected by the dfs pattern detector unit. > Usage of the collected info is specific to driver implementation. > For example, collected radar info could be used by the host driver > to send to co-processors for additional processing/validation. > > Note: 'radar_detector_specs' data containing the specifications of > different radar types which was private within dfs_pattern_detector/ > dfs_pri_detector is now shared with drivers as well for making use > of this information. > > Signed-off-by: Sriram R > Signed-off-by: Kalle Valo 2 patches applied to ath-next branch of ath.git, thanks. f40105e67478 ath: add support to get the detected radar specifications 6f6eb1bcbeff ath10k: DFS Host Confirmation -- https://patchwork.kernel.org/patch/10400505/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC 1/3] cfg80211: Add support for HE
Hi Arend,
On Mon, 2018-05-21 at 21:47 +0200, Arend van Spriel wrote:
> On 5/18/2018 4:05 PM, Luca Coelho wrote:
> > From: Luca Coelho
> >
> > Add support for the HE in cfg80211 and also add userspace API to
> > nl80211 to send rate information out, conforming with
> > P802.11ax_D1.4.
>
> A couple of things changed in D2.0 so does it make sense to
> introduce
> stuff from older draft?
That was my mistake. We support D2.0, it's just that the changes for
D2.0 were mixed in an iwlwifi driver patch and I missed it.
> > +/**
> > + * struct ieee80211_he_mcs_nss_supp - HE Tx/Rx HE MCS NSS Support Field
> > + *
> > + * This structure holds the data required for the Tx/Rx HE MCS NSS Support
> > Field
> > + * described in P802.11ax_D1.4 section 9.4.2.237.4
> > + *
> > + * @rx_msc_80: Rx MCS map 2 bits for each stream, total 8 streams, for
> > channel
> > + * widths less than 80MHz.
> > + * @tx_msc_80: Tx MCS map 2 bits for each stream, total 8 streams, for
> > channel
> > + * widths less than 80MHz.
> > + * @rx_msc_160: Rx MCS map 2 bits for each stream, total 8 streams, for
> > channel
> > + * width 160MHz.
> > + * @tx_msc_160: Tx MCS map 2 bits for each stream, total 8 streams, for
> > channel
> > + * width 160MHz.
> > + * @rx_msc_80p80: Rx MCS map 2 bits for each stream, total 8 streams, for
> > + * channel width 80p80MHz.
> > + * @tx_msc_80p80: Tx MCS map 2 bits for each stream, total 8 streams, for
> > + * channel width 80p80MHz.
> > + */
> > +struct ieee80211_he_mcs_nss_supp {
> > + __le16 rx_msc_80;
>
> Should 'msc' in these fields be 'mcs'?
Certainly, it's a typo and I'll fix it.
> > + __le16 tx_msc_80;
> > + __le16 rx_msc_160;
> > + __le16 tx_msc_160;
> > + __le16 rx_msc_80p80;
> > + __le16 tx_msc_80p80;
> > +} __packed;
> > +
> > +/**
> > + * struct ieee80211_he_operation - HE capabilities element
> > + *
> > + * This structure is the "HE operation element" fields as
> > + * described in P802.11ax_D1.4 section 9.4.2.238
> > + */
> > +struct ieee80211_he_operation {
> > + __le32 he_oper_params;
> > + __le16 he_mcs_nss_set;
> > + /* Optional 0,1,3 or 4 bytes: depends on %he_oper_params */
> > + u8 optional[0];
> > +} __packed;
>
> If I recall correctly the he operation element changed significantly in
> later revisions of the spec. So do we want to introduce (stale) D1.4
> stuff when currently at D2.3?
Yeah, in our internal tree we support D2.0 and I'll update accordingly.
Do you think it's okay to support D2.0 for now and update to D2.3 if
needed later on? I don't really know how much changed between these
versions...
> > +/* Link adaptation is split between byte #2 and byte #3. It should
> > be set only
> > + * if IEEE80211_HE_MAC_CAP0_HTC_HE in which case the following values
> > apply:
> > + * 0 = No feedback.
> > + * 1 = reserved.
> > + * 2 = Unsolicited feedback.
> > + * 3 = both
> > + */
> > +#define IEEE80211_HE_MAC_CAP1_LINK_ADAPTATION 0x80
>
> This is confusing. I suspect 'byte #2' is HE_MAC_CAP1 and 'byte #3' is
> HE_MAC_CAP2. Just refer to that instead of the byte-number reference.
Right, I'll do it.
> > +/**
> > + * struct ieee80211_sband_iftype_data
> > + *
> > + * This structure encapsulates sband data that is relevant for the
> > interface
> > + * types defined in %types
> > + *
> > + * @types: interface types (bits)
>
> maybe better named @types_mask.
Makes sense.
> > +/**
> > + * ieee80211_get_sband_ift_data - return sband data for a given iftype
> > + * @sband: the sband to search for the STA on
> > + * @iftype: enum nl80211_iftype
> > + *
> > + * Return: pointer to the struct ieee80211_sband_iftype_data, or NULL is
> > none found
> > + */
> > +static inline const struct ieee80211_sband_iftype_data *
> > +ieee80211_get_sband_ift_data(const struct ieee80211_supported_band *sband,
>
> Just call this function ieee80211_get_sband_iftype_data. It's only 3
> additional chars.
Yeah, I bumped into this in one of the internal reviews, but didn't
bother. But you're right, iftype is better.
@@ -781,6 +783,23 @@ int wiphy_register(struct wiphy *wiphy)
> > sband->channels[i].band = band;
> > }
> >
> > + for (i = 0; i < sband->n_iftype_data; i++) {
> > + const struct ieee80211_sband_iftype_data *iftd;
> > +
> > + iftd = &sband->iftype_data[i];
> > +
> > + if (WARN_ON(!iftd->types))
> > + return -EINVAL;
> > + if (WARN_ON(types & iftd->types))
> > + return -EINVAL;
>
> I suspected the types mask was not allowed to overlap for the
> iftype_data entries, but may be worth documenting that in struct
> ieee80211_sband_iftype_data kerneldoc.
Sure, I'll add it.
> > diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> > index f7715b85fd2b..661728dbf989 100644
> > --- a/net/wireless/nl80211.c
> > +++ b/net/wireless/nl80211.c
> >
Re: [01/10] wcn36xx: fix buffer commit logic on TX path
Daniel Mack wrote: > When wcn36xx_dxe_tx_frame() is entered while the device is still processing > the queue asyncronously, we are racing against the firmware code with > updates to the buffer descriptors. Presumably, the firmware scans the ring > buffer that holds the descriptors and scans for a valid control descriptor, > and then assumes that the next descriptor contains the payload. If, however, > the control descriptor is marked valid, but the payload descriptor isn't, > the packet is not sent out. > > Another issue with the current code is that is lacks memory barriers before > descriptors are marked valid. This is important because the CPU may reorder > writes to memory, even if it is allocated as coherent DMA area, and hence > the device may see incompletely written data. > > To fix this, the code in wcn36xx_dxe_tx_frame() was restructured a bit so > that the payload descriptor is made valid before the control descriptor. > Memory barriers are added to ensure coherency of shared memory areas. > > Signed-off-by: Daniel Mack > Signed-off-by: Kalle Valo 10 patches applied to ath-next branch of ath.git, thanks. 9a81cc23dfef wcn36xx: fix buffer commit logic on TX path 57e06e0e2a86 wcn36xx: set DMA mask explicitly ba437e72378c wcn36xx: don't disable RX IRQ from handler edd23ab403cf wcn36xx: clear all masks in RX interrupt ce1d4be82b10 wcn36xx: only handle packets when ED or DONE bit is set 18c7ed138824 wcn36xx: consider CTRL_EOP bit when looking for valid descriptors 2a46c829a926 wcn36xx: set PREASSOC and IDLE stated when BSS info changes 773f9a28bcda wcn36xx: drain pending indicator messages on shutdown a50c6c8412f7 wcn36xx: simplify wcn36xx_smd_open() ffbc9197b472 wcn36xx: improve debug and error messages for SMD -- https://patchwork.kernel.org/patch/10404031/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [net-next] ath10k: Remove useless test before clk_disable_unprepare
YueHaibing wrote: > clk_disable_unprepare() already checks that the clock pointer is valid. > No need to test it before calling it. > > Signed-off-by: YueHaibing > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. cf3c0ae6a32b ath10k: remove useless test before clk_disable_unprepare -- https://patchwork.kernel.org/patch/10403597/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [01/52] ath: Add regulatory mapping for Bahamas
Sven Eckelmann wrote: > The country code is used by the ath to detect the ISO 3166-1 alpha-2 name > and to select the correct conformance test limits (CTL) for a country. If > the country isn't available and it is still programmed in the EEPROM then > it will cause an error and stop the initialization with: > > Invalid EEPROM contents > > The current CTL mappings for this country are: > > * 2.4GHz: ETSI > * 5GHz: FCC > > Signed-off-by: Sven Eckelmann > Signed-off-by: Kalle Valo 35 patches applied to ath-next branch of ath.git, thanks. 699e2302c286 ath: Add regulatory mapping for Bahamas 9c790f2d234f ath: Add regulatory mapping for Bermuda b840fa912308 ath: Add regulatory mapping for Kenya a71c984bc4e5 ath: Add regulatory mapping for Mauritius a0a6f2a916dc ath: Add regulatory mapping for Montenegro a20f1338c5de ath: Add regulatory mapping for Nicaragua 67a956682472 ath: Add regulatory mapping for Paraguya 2a3169a54bb5 ath: Add regulatory mapping for Serbia 667ddac5745f ath: Add regulatory mapping for Tanzania 1ea3986ad2bc ath: Add regulatory mapping for Uganda 4f183687e3fa ath: Add regulatory mapping for APL2_FCCA 9ba8df0c52b3 ath: Add regulatory mapping for APL13_WORLD 45faf6e096da ath: Add regulatory mapping for ETSI8_WORLD 897fab6c5d90 ath: Add regulatory mapping for ETSI9_WORLD 01fb2994a98d ath: Add regulatory mapping for FCC3_ETSIC fed8f5e83037 ath: Map Albania to ETSI1_WORLD 485daee92bde ath: Map Algeria to APL13_WORLD 8120cc0b215c ath: Map Australia to FCC3_WORLD 1507b32891c0 ath: Map Bangladesh to APL1_WORLD 37090d944705 ath: Map Brunei Darussalam to APL6_WORLD fed60f81a2d0 ath: Map Bulgaria to ETSI1_WORLD 515e968624b2 ath: Map Colombia to FCC1_FCCA 0fa31a86998b ath: Map Czech to ETSI1_WORLD 143a9b9bd7ee ath: Map Honduras to FCC3_WORLD 62ba2b22d120 ath: Map Isreal to ETSI3_WORLD 64874ed2a73a ath: Map Macedonia to ETSI1_WORLD 823a64065adf ath: Map Malasia to FCC1_WORLD 9bfc2bb32e01 ath: Map New Zealand to FCC3_ETSIC b5c11e474406 ath: Map Peru to APL1_WORLD c454d4c25844 ath: Map Philippines to FCC3_WORLD 12f415566fb4 ath: Map Romania to ETSI1_WORLD b7e015132d85 ath: Map Russia to ETSI8_WORLD 054e07788002 ath: Map Singapore to FCC3_WORLD 4e78075c4821 ath: Map Ukraine to ETSI9_WORLD f1abff21acc5 ath: Map Zimbabwe to ETSI1_WORLD -- https://patchwork.kernel.org/patch/10251529/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k: Add support to configure channel dwell time
Pradeep Kumar Chitrapu wrote: > Configure channel dwell time from duration of the scan request > received from mac80211 when the duration is non-zero. When the > scan request does not have duration value, use the default ones, > the current implementation. > > Corresponding flag NL80211_EXT_FEATURE_SET_SCAN_DWELL is > advertized. > > Supported Chipsets: > -QCA988X/QCA9887 PCI > -QCA99X0/QCA9984/QCA9888/QCA4019 PCI > -QCA6174/QCA9377 PCI/USB/SDIO > -WCN3990 SNOC > > Tested on QCA9984 with firmware ver 10.4-3.6-0010 > > Signed-off-by: Pradeep Kumar Chitrapu > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. be8cce96f14d ath10k: add support to configure channel dwell time -- https://patchwork.kernel.org/patch/10395687/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k: add fw crash dump support for QCA9888 and QCA99X0
Anilkumar Kolli wrote: > This patch adds firmware crash memory dump support for QCA9888 and QCA99X0. > > Tested on: > > QCA9888 firmware 10.4-3.5.3-00053 > QCA99X0 firmware 10.4.1.00030-1 > > Signed-off-by: Anilkumar Kolli > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 46dbf98c69f4 ath10k: add memory dump support for QCA9888 and QCA99X0 -- https://patchwork.kernel.org/patch/10386041/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: Fwd: [PATCH V3 1/5] brcm: update firmware for bcm43430
Hi Arend, [add Josh] Am 14.05.2018 um 12:03 schrieb Arend van Spriel: Hi Stefan, Your query kept nagging as I recalled firmware patches earlier *this* year, not november last year. Searched my mailing list archive and found this. Apparently, it got lost in the cracks. Let's ping the firmware maintainers... could you please resend instead forward? Thanks Stefan Regards, Arend
[PATCH 2/2] mac80211: last ack singal support in station dump
This patch adds "last ack signal" and "avg ack signal" support
in station dump for valid ack rssi.
Signed-off-by: Balaji Pothunoori
---
net/mac80211/sta_info.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 6428f1a..12b618e 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2310,13 +2310,21 @@ void sta_set_sinfo(struct sta_info *sta, struct
station_info *sinfo,
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL);
}
- if (ieee80211_hw_check(&sta->local->hw, REPORTS_TX_ACK_STATUS) &&
- !(sinfo->filled & BIT_ULL(NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG))) {
- sinfo->avg_ack_signal =
- -(s8)ewma_avg_signal_read(
+ if (ieee80211_hw_check(&sta->local->hw, REPORTS_TX_ACK_STATUS)) {
+ if (sta->status_stats.ack_signal_filled && ((!(sinfo->filled &
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL))) ||
+ (!(sinfo->filled &
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL_AVG) {
+ sinfo->ack_signal =
+ sta->status_stats.last_ack_signal;
+ sinfo->filled |=
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL);
+ sinfo->avg_ack_signal =
+ -(s8)ewma_avg_signal_read(
&sta->status_stats.avg_ack_signal);
- sinfo->filled |=
- BIT_ULL(NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG);
+ sinfo->filled |=
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL_AVG);
+ }
}
}
--
2.7.4
[PATCH 1/2] cfg80211: last ack singal support in station dump
This patch adds "last ack signal" support in station dump if
driver supports.
Signed-off-by: Balaji Pothunoori
---
include/uapi/linux/nl80211.h | 14 +++---
net/wireless/nl80211.c | 8
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 06f9af2..ebeb54e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3000,8 +3000,8 @@ enum nl80211_sta_bss_param {
* received from the station (u64, usec)
* @NL80211_STA_INFO_PAD: attribute used for padding for 64-bit alignment
* @NL80211_STA_INFO_ACK_SIGNAL: signal strength of the last ACK frame(u8, dBm)
- * @NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG: avg signal strength of (data)
- * ACK frame (s8, dBm)
+ * @NL80211_STA_INFO_ACK_SIGNAL_AVG: avg signal strength of data or management
+ * ACK frames(s8, dBm)
* @__NL80211_STA_INFO_AFTER_LAST: internal
* @NL80211_STA_INFO_MAX: highest possible station info attribute
*/
@@ -3041,7 +3041,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_RX_DURATION,
NL80211_STA_INFO_PAD,
NL80211_STA_INFO_ACK_SIGNAL,
- NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG,
+ NL80211_STA_INFO_ACK_SIGNAL_AVG,
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
@@ -5128,9 +5128,9 @@ enum nl80211_feature_flags {
* "radar detected" event.
* @NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211: Driver supports sending and
* receiving control port frames over nl80211 instead of the netdevice.
- * @NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT: This Driver support data ack
- * rssi if firmware support, this flag is to intimate about ack rssi
- * support to nl80211.
+ * @NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT: This Driver support ack rssi if
+ * firmware support, this flag is to intimate about ack rssi support
+ * to nl80211.
* @NL80211_EXT_FEATURE_TXQS: Driver supports FQ-CoDel-enabled intermediate
* TXQs.
*
@@ -5165,7 +5165,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_HIGH_ACCURACY_SCAN,
NL80211_EXT_FEATURE_DFS_OFFLOAD,
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211,
- NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT,
+ NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT,
NL80211_EXT_FEATURE_TXQS,
/* add new features before the definition below */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index bc40a78..df24ace 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4650,11 +4650,11 @@ static int nl80211_send_station(struct sk_buff *msg,
u32 cmd, u32 portid,
PUT_SINFO_U64(RX_DROP_MISC, rx_dropped_misc);
PUT_SINFO_U64(BEACON_RX, rx_beacon);
PUT_SINFO(BEACON_SIGNAL_AVG, rx_beacon_signal_avg, u8);
- PUT_SINFO(ACK_SIGNAL, ack_signal, u8);
if (wiphy_ext_feature_isset(&rdev->wiphy,
-
NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT))
- PUT_SINFO(DATA_ACK_SIGNAL_AVG, avg_ack_signal, s8);
-
+ NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT)) {
+ PUT_SINFO(ACK_SIGNAL, ack_signal, u8);
+ PUT_SINFO(ACK_SIGNAL_AVG, avg_ack_signal, s8);
+ }
#undef PUT_SINFO
#undef PUT_SINFO_U64
--
2.7.4
[PATCH 0/2] cfg80211/mac80211: last ack singal support in station dump
From: Balaji Pothunoori This patch adds "last ack signal" support in station dump if driver reports ack rssi for last tx packet. Balaji Pothunoori (2): cfg80211: last ack singal support in station dump mac80211: last ack singal support in station dump include/uapi/linux/nl80211.h | 14 +++--- net/mac80211/sta_info.c | 20 ++-- net/wireless/nl80211.c | 8 3 files changed, 25 insertions(+), 17 deletions(-) -- 2.7.4
