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: <da06b5074a5d40d811a67656048f3afa262ff134.camel@sipsolutions.net>
Subject: Re: [PATCH v2 00/22] add support for S1G association
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Thomas Pedersen <thomas@adapt-ip.com>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>,
        Jouni Malinen <j@w1.fi>
Date:   Sun, 06 Sep 2020 18:04:24 +0200
In-Reply-To: <20200831205600.21058-1-thomas@adapt-ip.com>
References: <20200831205600.21058-1-thomas@adapt-ip.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Mon, 2020-08-31 at 13:55 -0700, Thomas Pedersen wrote:
> 
> Note the mac80211_hwsim S1G support introduces a regression in a few
> hostap hwsim tests. This is because when processing the reported bands,
> hostap assumes freq < 4000 is 11b, and the actual 11b/g band is
> overwritten by the S1G band info. Though it does count as a userspace
> regression, I'm not sure there is much to do about it besides apply a
> small patch to hostapd which treats freq < 2000 as an unknown band.
> 
> After the hostap workaround
> (https://lists.infradead.org/pipermail/hostap/2020-August/038748.html),
> these patches continue to pass the hwsim tests as well as HEAD.


That sounds like we could "hack around" it by sending the S1G data
first, and then the 2.4 GHz, so the latter overwrites it on broken
versions?

Not sure it's worth it though, I'd say it depends a bit on what real
hardware plans are?

I mean, if it's only hwsim for now ... who cares? And if it's going to
be special hardware that only does S1G, then also meh, you need newer
versions to support it, big deal.

But if OTOH a commonly used chipset like e.g. ath9k or ath10k will get
S1G support, then that'd be more relevant?

johannes