Search Linux Wireless

Re: [PATCH v2] wifi: mac80211: add eht_capa debugfs field.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/9/23 12:34, Johannes Berg wrote:
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:

+	/* TODO:  Fix and re-add this.  It compiles in 6.4 but not against 'next'
+	 * according to the kernel build bot.
+	 * PFLAG(PHY, 5, SUPP_EXTRA_EHT_LTF, "SUPP-EXTRA-EHT-LTF");
+	 */


Well that's because the spec version was updated in wireless-next :)

So please adjust according to the new fields there.

It will be some time before I get a chance to revisit this.  If you can
accept as is, I'll fix the remaining bits when I move to 6.5 or whatever
mainline kernel has the updated spec.


Actually I think it was just this field, so maybe I can just take v1.

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:

...
		EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=4, Tx=4
		EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=4, Tx=4
		EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=4, Tx=4
		EHT bw <= 160 MHz, max NSS for MCS 8-9: Rx=4, Tx=4
		EHT bw <= 160 MHz, max NSS for MCS 10-11: Rx=4, Tx=4
		EHT bw <= 160 MHz, max NSS for MCS 12-13: Rx=4, Tx=4
		EHT bw <= 320 MHz, max NSS for MCS 8-9: Rx=4, Tx=4
		EHT bw <= 320 MHz, max NSS for MCS 10-11: Rx=4, Tx=4
		EHT bw <= 320 MHz, max NSS for MCS 12-13: Rx=4, Tx=4

I would expect it to show Rx=2, Tx=2 in this case.

Any opinions on how or whether to change this?  Do we already store a combined
capabilities list somewhere in mac80211 for EHT?


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.

Yeah, I'm not excited to write a large pile of new and mostly duplicated logic
just for better debugfs output.

The main thing I want out of this is current-negotiated-bandwidth and
current-negotiated-nss.  I can hack that in one way or another.

Another option:  If mac80211 already knows the STA's own capabilities, that could
be added to this debugfs file, and then user-space could deal with finding the
least common demoninator for that it cares about?  But does mac80211 even store
a precise capa list for the station's current association?

Thanks,
Ben

--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux