diff mbox series

[4.19] mt76x0: mark 802.11w as supported

Message ID 20181220114701.GA8660@redhat.com
State Not Applicable
Headers show
Series [4.19] mt76x0: mark 802.11w as supported | expand

Commit Message

Stanislaw Gruszka Dec. 20, 2018, 11:47 a.m. UTC
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(+)

Comments

Greg KH Dec. 20, 2018, 12:30 p.m. UTC | #1
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
Stanislaw Gruszka Dec. 20, 2018, 1:17 p.m. UTC | #2
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
Sid Hayn Dec. 20, 2018, 2:30 p.m. UTC | #3
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 mbox series

Patch

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;