On 2023/12/19 17:52, Arend Van Spriel wrote:
On December 17, 2023 12:25:23 PM Kalle Valo <kvalo@xxxxxxxxxx> wrote:
Hector Martin <marcan@xxxxxxxxx> wrote:
Using the WSEC command instead of sae_password seems to be the supported
mechanism on newer firmware, and also how the brcmdhd driver does it.
According to user reports [1], the sae_password codepath doesn't actually
work on machines with Cypress chips anyway, so no harm in removing it.
This makes WPA3 work with iwd, or with wpa_supplicant pending a support
patchset [2].
[1] https://rachelbythebay.com/w/2023/11/06/wpa3/
[2] http://lists.infradead.org/pipermail/hostap/2023-July/041653.html
Signed-off-by: Hector Martin <marcan@xxxxxxxxx>
Reviewed-by: Neal Gompa <neal@xxxxxxxxx>
Arend, what do you think?
We recently talked about people testing brcmfmac patches, has anyone else
tested this?
Not sure I already replied so maybe I am repeating myself. I would prefer
to keep the Cypress sae_password path as well although it reportedly does
not work. The vendor support in the driver can be used to accommodate for
that. The other option would be to have people with Cypress chipset test
this patch. If that works for both we can consider dropping the
sae_password path.
Regards,
Arend
So, if nobody from Cypress chimes in ever, and nobody cares nor tests
Cypress chipsets, are we keeping any and all existing Cypress code-paths
as bitrotting code forever and adding gratuitous conditionals every time
any functionality needs to change "just in case it breaks Cypress" even
though it has been tested compatible on Broadcom chipsets/firmware?
Because that's not sustainable long term.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature