Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d14e88a69c9ed48e46058299cf3136467ba6e054.camel@sipsolutions.net>
Subject: Re: [PATCH v2] wifi: mac80211: add eht_capa debugfs field.
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Ben Greear <greearb@candelatech.com>,
        linux-wireless@vger.kernel.org
Date:   Wed, 09 Aug 2023 21:34:57 +0200
In-Reply-To: <37a24557-2562-4891-e7ec-18b5527a54f0@candelatech.com>
References: <20230519162324.1633120-1-greearb@candelatech.com>
         <1038a5fd7d658cc29d11a6eb8776255c50e8226c.camel@sipsolutions.net>
         <e81d4d8d-8076-00cc-cb72-8417dc8203ce@candelatech.com>
         <559120af6ed8cdfdee7eaa83531b35de2ce24a0f.camel@sipsolutions.net>
         <37a24557-2562-4891-e7ec-18b5527a54f0@candelatech.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-08-09 at 12:32 -0700, Ben Greear wrote:
> On 6/14/23 13:08, Johannes Berg wrote:
> > On Wed, 2023-06-14 at 09:39 -0700, Ben Greear wrote:
> > > On 6/14/23 01:29, Johannes Berg wrote:
> > > >=20
> > > > > +	/* TODO:  Fix and re-add this.  It compiles in 6.4 but not agai=
nst 'next'
> > > > > +	 * according to the kernel build bot.
> > > > > +	 * PFLAG(PHY, 5, SUPP_EXTRA_EHT_LTF, "SUPP-EXTRA-EHT-LTF");
> > > > > +	 */
> > > > >=20
> > > >=20
> > > > Well that's because the spec version was updated in wireless-next :=
)
> > > >=20
> > > > So please adjust according to the new fields there.
> > >=20
> > > It will be some time before I get a chance to revisit this.  If you c=
an
> > > accept as is, I'll fix the remaining bits when I move to 6.5 or whate=
ver
> > > mainline kernel has the updated spec.
> > >=20
> >=20
> > Actually I think it was just this field, so maybe I can just take v1.
>=20
> After doing some more detailed testing, I notice that this capa logic is =
using
> the AP's capability list, and is not showing lowest common features.  For=
 instance,
> a 2x2 STA radio shows as this when connected to 4x4 AP:
>=20
> ...
> 		EHT bw <=3D 80 MHz, max NSS for MCS 8-9: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 80 MHz, max NSS for MCS 10-11: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 80 MHz, max NSS for MCS 12-13: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 160 MHz, max NSS for MCS 8-9: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 160 MHz, max NSS for MCS 10-11: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 160 MHz, max NSS for MCS 12-13: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 320 MHz, max NSS for MCS 8-9: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 320 MHz, max NSS for MCS 10-11: Rx=3D4, Tx=3D4
> 		EHT bw <=3D 320 MHz, max NSS for MCS 12-13: Rx=3D4, Tx=3D4
>=20
> I would expect it to show Rx=3D2, Tx=3D2 in this case.
>=20
> Any opinions on how or whether to change this?  Do we already store a com=
bined
> capabilities list somewhere in mac80211 for EHT?
>=20

We did this for HT and VHT, and then kind of stopped for HE because it
got so asymmetric and complicated ... it ended up easier for drivers to
do it because they have their own hardware limitations and all and know
what they may or may not advertise, and mac80211 would have to do it
_all_. Yeah, not ideal either. So dunno. I wouldn't mind the logic I
guess and we could probably remove stuff from the drivers, but either
we'd have to be really careful about what we do and don't handle, and
probably check that against what drivers have, or handle everything
which gets difficult.

johannes