Re: [PATCH] wil6210: remove set but not used variable 'wdev'
On 2018-12-05 09:59, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/wil6210/main.c: In function
'_wil6210_disconnect':
drivers/net/wireless/ath/wil6210/main.c:407:23: warning:
variable 'wdev' set but not used [-Wunused-but-set-variable]
It never used since commit ("e1b43407c034 wil6210: refactor disconnect
flow")
Signed-off-by: YueHaibing
---
drivers/net/wireless/ath/wil6210/main.c | 2 --
1 file changed, 2 deletions(-)
Reviewed-by: Maya Erez
--
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
Re: [RFC PATCH v2 0/2] Extended Key ID support for linux
I got the impression Extended Key IDs were added without updating all sections which should get updates. But the pattern is suspect, even the igtk numbers fit into the pattern: PTK 0 & 1 GTK 1 & 2 & 3 iGTK 4 & 5 An AP is allowed to do this, but there is no requirement for doing so. The pairwise key (TK, not PTK) is required to use Key ID 0 unless the > optional Extended Key ID for Individually Addressed Frames capability is negotiated (and 0 or 1 if that capability is negotiated). Group keys (GTK) are allowed to use Key IDs 0..4. IGTKs are allowed to use Key ID values 4 and 5. There is a long history behind this and some de facto constraints due to that history and possible implementation constraints. However, as far as the protocol itself is concerned, there would be no real need for having IGTK use 4..5; it could have as well been 0..1 or 1..2 or whatever combination the AP would like to use. These three cases have completely independent namespaces for Key IDs as far as RSN is concerned with one exception: "Use group cipher suite" that was added as an option for some AP implementation that did not support individual key mapping. That special case would end up using GTK for both group-addressed and individually-addressed frames. That said, I'm not aware of there having ever been an actually deployed device with this constraint and even if there were, this mode is highly discouraged and should not be used for anything today. Anyway, this exception and similar implementation constraints are likely behind the expectations of TK and GTK having to use different Key ID values. Thanks for the clarifications! If there really are drivers using "Use group cipher suite" it does not sound like they would be able to support Extended Key ID with APs using key ID 1+2 for GTKs. But sounds not likely anyone would need that... My experimentation with hw accel and Extended Key ID for existing drivers so far are also indicating that it will work using the keyid 1 for both PTK and GTK, so this should be a trivial change in hostapd only. As far as the kernel changes are concerned, cfg80211 and mac80211 should support everything that's allowed by the standard, i.e., use of Key IDs 0..3 for GTK. It is up to the user space implementation on the AP side (e.g., hostapd) to select which Key IDs are actually taken into use. I'm pretty sure that is already the case, but so far I only tested it with GTK shifted to 2+3. I'll make sure to test the next revision with GTK using 1+2 also. I'll test that once I get that working again from end2end. The patch here is getting a bit dated and makes no sense to invest time for that win it. Alexander
Re: [PATCH 2/5] mt76x02: fixup MT_PROT_RATE_* defines
> > On new mt76 chips, phy mode is configured by last 3 bits > of rate value. Hence OFDM bit is marked by 0x2000 > instead of 0x4000. > > Signed-off-by: Stanislaw Gruszka > --- > drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h > b/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h > index f7de77d09d28..d1ac847adce5 100644 > --- a/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h > +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_regs.h > @@ -440,9 +440,9 @@ > #define MT_PROT_TXOP_ALLOW_GF40BIT(25) > #define MT_PROT_RTS_THR_EN BIT(26) > #define MT_PROT_RATE_CCK_110x0003 > -#define MT_PROT_RATE_OFDM_60x4000 > -#define MT_PROT_RATE_OFDM_24 0x4004 > -#define MT_PROT_RATE_DUP_OFDM_24 0x4084 > +#define MT_PROT_RATE_OFDM_60x2000 > +#define MT_PROT_RATE_OFDM_24 0x2004 > +#define MT_PROT_RATE_DUP_OFDM_24 0x2084 > #define MT_PROT_TXOP_ALLOW_ALL GENMASK(25, 20) > #define MT_PROT_TXOP_ALLOW_BW20(MT_PROT_TXOP_ALLOW_ALL & > \ > ~MT_PROT_TXOP_ALLOW_MM40 & \ > -- > 1.9.3 > Acked-by: Lorenzo Bianconi
Re: [PATCH 5/5] mt76x2: initialize fall-back rate registers
>
> Initialize MT_LG_FBK_CFG{0,1} and MT_VHT_HT_FBK_CFG{0,1} registers.
>
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
> b/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
> index a1657922758e..01e672bad2f1 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/initvals.h
> @@ -88,6 +88,10 @@
> { MT_TX_PROT_CFG6, 0xe3f42004 },
> { MT_TX_PROT_CFG7, 0xe3f42084 },
> { MT_TX_PROT_CFG8, 0xe3f42104 },
> + { MT_VHT_HT_FBK_CFG0, 0x65432100 },
> + { MT_VHT_HT_FBK_CFG1, 0xedcba980 },
> + { MT_LG_FBK_CFG0, 0xedcba988 },
> + { MT_LG_FBK_CFG1, 0x00872100 },
> };
>
as for mt76x2 patch (except MT_VHT_HT_FBK_CFG1) MT_VHT_HT_FBK_CFG0,
MT_LG_FBK_CFG{0,1} are default values
(at least for mt7610e, I will double-check for mt7610u)
Regards,
Lorenzo
> static const struct mt76_reg_pair mt76x0_bbp_init_tab[] = {
> --
> 1.9.3
>
Re: [PATCH 4/5] mt76x2: initialize fall-back rate registers
>
> Initialize MT_LG_FBK_CFG{0,1} and MT_VHT_HT_FBK_CFG0 registers.
> MT_VHT_HT_FBK_CFG1 was already configured.
>
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/net/wireless/mediatek/mt76/mt76x2/init.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
> b/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
> index 54a9b5fac787..16fd514b5207 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/init.c
> @@ -140,7 +140,10 @@ void mt76_write_mac_initvals(struct mt76x02_dev *dev)
> { MT_WPDMA_DELAY_INT_CFG, 0x94ff },
> { MT_TX_SW_CFG3,0x0004 },
> { MT_HT_FBK_TO_LEGACY, 0x1818 },
> + { MT_VHT_HT_FBK_CFG0, 0x65432100 },
> { MT_VHT_HT_FBK_CFG1, 0xedcba980 },
> + { MT_LG_FBK_CFG0, 0xedcba988 },
> + { MT_LG_FBK_CFG1, 0x87872100 },
> { MT_PROT_AUTO_TX_CFG, 0x00830083 },
> { MT_HT_CTRL_CFG, 0x01ff },
> };
I do not think this patch is necessary since these value are default ones:
root@lede:/sys/kernel/debug/ieee80211/phy0/mt76# echo 0x1354 > regidx
root@lede:/sys/kernel/debug/ieee80211/phy0/mt76# cat regval
0x65432100
root@lede:/sys/kernel/debug/ieee80211/phy0/mt76# echo 0x135c > regidx
root@lede:/sys/kernel/debug/ieee80211/phy0/mt76# cat regval
0xedcba988
root@lede:/sys/kernel/debug/ieee80211/phy0/mt76# echo 0x1360 > regidx
root@lede:/sys/kernel/debug/ieee80211/phy0/mt76# cat regval
0x87872100
Regards,
Lorenzo
> --
> 1.9.3
>
Re: [PATCH 1/5] mt76x02: do not set protection on set_rts_threshold callback
On Fri, Dec 7, 2018 at 2:27 PM Stanislaw Gruszka wrote:
>
> Use set_rts_threshold calback to enable/disable threshold only for
> legacy traffic.
>
> Protection for HT and VHT traffic is defined by HT operation element
> and it's provided by remote AP or by hostapd.
>
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 16 +---
> drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 2 +-
> drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 2 +-
> 3 files changed, 3 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> index c08bf371e527..9693d6140b3d 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
> @@ -715,7 +715,7 @@ void mt76x02_tx_complete_skb(struct mt76_dev *mdev,
> struct mt76_queue *q,
> }
> EXPORT_SYMBOL_GPL(mt76x02_tx_complete_skb);
>
[...]
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> index 3a70e5bf7d42..e7ee2cc76edf 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> @@ -463,7 +463,7 @@ int mt76x02_set_rts_threshold(struct ieee80211_hw *hw,
> u32 val)
> return -EINVAL;
>
> mutex_lock(&dev->mutex);
> - mt76x02_mac_set_tx_protection(dev, val);
> + mt76x02_mac_set_rts_thresh(dev, val);
> mutex_unlock(&dev->mutex);
I think this patch will not apply since I have recently fixed an
uninitialized mutex access setting rts threshold
1770f0fa978e ("mt76: fix uninitialized mutex access setting rts
threshold"). That patch is in Kalle's pending branch
now. You should probably respin on top of it.
Regards,
Lorenzo
>
> return 0;
> --
> 1.9.3
>
