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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com