Hello Johannes,
While poking around in things, I noticed that the
he_capa debugfs is not showing the least-common-denominator, but rather
more specifically the peer's capabilities.
This could be bugs in how I'm using this, but thought I'd ask to
see if this was on purpose or not.
Code in question looks like this. That sta->sta.he_cap is
from the peer as far as I can tell. The local one is obtained
from the radio/driver (and then modified a bit in some hackings
I am doing).
static ssize_t sta_he_capa_read(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
char *buf, *p;
size_t buf_sz = PAGE_SIZE;
struct sta_info *sta = file->private_data;
struct ieee80211_sta_he_cap *hec = &sta->sta.he_cap;
struct ieee80211_he_mcs_nss_supp *nss = &hec->he_mcs_nss_supp;
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hi Ben,
> While poking around in things, I noticed that the
> he_capa debugfs is not showing the least-common-denominator, but rather
> more specifically the peer's capabilities.
>
> This could be bugs in how I'm using this, but thought I'd ask to
> see if this was on purpose or not.
It was on purpose. Also, for HE it's different from HT/VHT in that we
don't do this in the stack any more.
I'm not really sure _why_ now (or if we should change it), but I seem to
remember it was just a lot more complex to do in general, but drivers
didn't really care so much since they tend to have a lot of hard-coded
assumptions, e.g. they might not care about seeing 2, 3 or more streams
supported if their code assumes the device always only supports 2 in the
first place, so all they need is a >= 2 check in this case, for example.
If you wanted to change that, I wouldn't mind, but it might be complex.
johannes
On 8/20/21 2:17 AM, Johannes Berg wrote:
> Hi Ben,
>
>> While poking around in things, I noticed that the
>> he_capa debugfs is not showing the least-common-denominator, but rather
>> more specifically the peer's capabilities.
>>
>> This could be bugs in how I'm using this, but thought I'd ask to
>> see if this was on purpose or not.
>
> It was on purpose. Also, for HE it's different from HT/VHT in that we
> don't do this in the stack any more.
>
> I'm not really sure _why_ now (or if we should change it), but I seem to
> remember it was just a lot more complex to do in general, but drivers
> didn't really care so much since they tend to have a lot of hard-coded
> assumptions, e.g. they might not care about seeing 2, 3 or more streams
> supported if their code assumes the device always only supports 2 in the
> first place, so all they need is a >= 2 check in this case, for example.
>
> If you wanted to change that, I wouldn't mind, but it might be complex.
Ok, for now it is a curiosity. While hacking on things (to disable 160Mhz
support so that a station can be forced to 80Mhz when radio supports 160),
I ended up writing code to take the station HE capabilities from the driver
and then modify them. Other code in mac80211 is already sort of doing this
here and there. So, maybe that is a way to start consolidating the
'overrides' logic to build a more proper HE capab in mac80211...
Thanks,
Ben
>
> johannes
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com