Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <2c55dce18c94d778207b3fc452a09e14ee80c032.camel@sipsolutions.net>
Subject: Re: question on HE debugfs output
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Ben Greear <greearb@candelatech.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Fri, 20 Aug 2021 11:17:20 +0200
In-Reply-To: <578da3a0-f029-4e60-d4e6-34d42def62e8@candelatech.com>
References: <578da3a0-f029-4e60-d4e6-34d42def62e8@candelatech.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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