Received-SPF: pass (google.com: domain of linux-wireless+bounces-1875-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Subject: Re: [PATCH V2 2/4] wifi: brcmfmac: add per-vendor feature detection
 callback
From: Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20240103095704.135651-3-arend.vanspriel@broadcom.com>
Date: Sat, 13 Jan 2024 11:35:53 +0100
Cc: Kalle Valo <kvalo@kernel.org>,
 linux-wireless@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A137AF57-B63D-4EE0-9A6B-7CBDC30DA82D@holtmann.org>
References: <20240103095704.135651-1-arend.vanspriel@broadcom.com>
 <20240103095704.135651-3-arend.vanspriel@broadcom.com>
To: Arend van Spriel <arend.vanspriel@broadcom.com>

Hi Arend,

> Adding a .feat_attach() callback allowing per-vendor overrides
> of the driver feature flags. In this patch the callback is only
> provided by BCA vendor to disable SAE feature as it has not been
> confirmed yet. BCA chips generally do not have the in-driver
> supplicant (idsup) feature so they rely on NL80211_CMD_EXTERNAL_AUTH
> to trigger user-space authentication.

is there any way to tell if idsup is supported (firmware string or
some other mechanism). The just disabling and not implementing support
for external_auth is really having this stuck in WPA2 legacy world.

The whole out-dated firmware game on Raspberry Pi is already a mess.

My problem is really that WiFi 6E and WiFi 7 are essentially mandating
WPA3/SAE only support as soon as you move into 6 GHz operation and the
errors presented to the user are not decodable if you don=E2=80=99t have =
a
good understanding on what WiFi certification mandates.

Regards

Marcel