| Message ID | 20181220114701.GA8660@redhat.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [4.19] mt76x0: mark 802.11w as supported | expand |
On Thu, Dec 20, 2018 at 12:47:07PM +0100, Stanislaw Gruszka wrote: > commit 0ae976a11b4fb5704b597e103b5189237641c1a1 upstream. > > This is one line hw feature backport from 0ae976a11b4f ("mt76x0: init > hw capabilities"), which add also other different features, however > those are not supported in 4.19. > > 802.11w is supported by mac80211 and mt76x0u driver in 4.19 correctly > fall-back to software encryption when 802.11w ciphers are used. > > Without the patch we fail to associate with WPA3 APs, so this is > considered as fix. > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> > Signed-off-by: Felix Fietkau <nbd@nbd.name> > [remove marking non-working features on 4.19, make topic correspond the change] > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> > --- > drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 1 + > 1 file changed, 1 insertion(+) What bug is this fixing? This never worked before, so this feels like it is adding a new feature. thanks, greg k-h
On Thu, Dec 20, 2018 at 01:30:55PM +0100, Greg KH wrote: > On Thu, Dec 20, 2018 at 12:47:07PM +0100, Stanislaw Gruszka wrote: > > commit 0ae976a11b4fb5704b597e103b5189237641c1a1 upstream. > > > > This is one line hw feature backport from 0ae976a11b4f ("mt76x0: init > > hw capabilities"), which add also other different features, however > > those are not supported in 4.19. > > > > 802.11w is supported by mac80211 and mt76x0u driver in 4.19 correctly > > fall-back to software encryption when 802.11w ciphers are used. > > > > Without the patch we fail to associate with WPA3 APs, so this is > > considered as fix. > > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> > > Signed-off-by: Felix Fietkau <nbd@nbd.name> > > [remove marking non-working features on 4.19, make topic correspond the change] > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> > > --- > > drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 1 + > > 1 file changed, 1 insertion(+) > > What bug is this fixing? This never worked before, so this feels like > it is adding a new feature. It's never worked before, true. It fixes problem with associating with WPA3 Access Points. Perhaps Sid (already in CC) who requested this, could justify it better. Thanks Stanislaw
On Thu, Dec 20, 2018 at 7:30 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Dec 20, 2018 at 12:47:07PM +0100, Stanislaw Gruszka wrote: > > commit 0ae976a11b4fb5704b597e103b5189237641c1a1 upstream. > > > > This is one line hw feature backport from 0ae976a11b4f ("mt76x0: init > > hw capabilities"), which add also other different features, however > > those are not supported in 4.19. > > > > 802.11w is supported by mac80211 and mt76x0u driver in 4.19 correctly > > fall-back to software encryption when 802.11w ciphers are used. > > > > Without the patch we fail to associate with WPA3 APs, so this is > > considered as fix. > > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> > > Signed-off-by: Felix Fietkau <nbd@nbd.name> > > [remove marking non-working features on 4.19, make topic correspond the change] > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> > > --- > > drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 1 + > > 1 file changed, 1 insertion(+) > > What bug is this fixing? This never worked before, so this feels like > it is adding a new feature. It is easy to see how this walks the line between "new feature" and "bug". From a user's perspective, it presents obviously as a bug: wlan0: WPA: Failed to configure IGTK to the driver wlan0: RSN: Failed to configure IGTK When I cannot connect to an AP and wpa_supplicant is throwing failures, it sure feels like a bug. The line for acceptance shouldn't be "never worked before" or only regressions would be fixed in stable. Instead the line should be closer to "this doesn't work and was expected to work". In 4.19.5 a patch was merged to fix monitor mode on this driver, which is a far less critical bug than not supporting 802.11w and WPA3. For me I would define "bug" as unexpected failure, and no where in the wpa_supplicant output does it say this is unsupported, instead it just plain fails, and failure is a bug. Again, I agree that it can be seen both ways, but I'm arguing that it's a bug. Thanks, Zero > > thanks, > > greg k-h
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c index 7cdb3e740522..0a3e046d78db 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c @@ -681,6 +681,7 @@ int mt76x0_register_device(struct mt76x0_dev *dev) ieee80211_hw_set(hw, SUPPORTS_HT_CCK_RATES); ieee80211_hw_set(hw, AMPDU_AGGREGATION); ieee80211_hw_set(hw, SUPPORTS_RC_TABLE); + ieee80211_hw_set(hw, MFP_CAPABLE); hw->max_rates = 1; hw->max_report_rates = 7; hw->max_rate_tries = 1;
commit 0ae976a11b4fb5704b597e103b5189237641c1a1 upstream. This is one line hw feature backport from 0ae976a11b4f ("mt76x0: init hw capabilities"), which add also other different features, however those are not supported in 4.19. 802.11w is supported by mac80211 and mt76x0u driver in 4.19 correctly fall-back to software encryption when 802.11w ciphers are used. Without the patch we fail to associate with WPA3 APs, so this is considered as fix. Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> [remove marking non-working features on 4.19, make topic correspond the change] Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> --- drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 1 + 1 file changed, 1 insertion(+)