Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <38649e92c619dc2f1482aba08c977d1611064e05.camel@sipsolutions.net>
Subject: Re: Automatically adding OCI in mac80211
From:   Johannes Berg <johannes@sipsolutions.net>
To:     James Prestwood <prestwoj@gmail.com>,
        linux-wireless@vger.kernel.org
Cc:     ilan.peer@intel.com
Date:   Mon, 24 Apr 2023 19:15:02 +0200
In-Reply-To: <33e23355cd8cfcf2296bba1272df814af32b003f.camel@gmail.com>
References: <432703ce83ac979ba06e2b85d6dc500f246c6a76.camel@gmail.com>
         <199f2ac280a1e1a195add45290411a9c1dc519fc.camel@sipsolutions.net>
         <cba322cbf992067e843114ab53da610978768d64.camel@gmail.com>
         <33e23355cd8cfcf2296bba1272df814af32b003f.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

Hi James,

Sorry - going through old email that might still need attention, clearly
dropped the ball on this ...

On the other hand, now we have all the MLO code in the tree :)

> So thinking about it more I think we have two options:
>=20
> 1. Improve CMD_ASSOCIATE to be non-destructive on failure and allow the
> API to accept a channel definition directly i.e. enough info for
> nl80211_parse_chandef() to work. Then use this chandef rather than
> derive its own. If this fails (e.g. due to a downgrade) return an error
> and userspace could downgrade the width itself and try again. What I'm
> thinking here is not modifying any values in sdata, link, ifmgd etc.
> until the channel switch returns successfully.

That seems rather complex too, to be honest.

> 2. Build the OCI element all in the kernel. As far as figuring out the
> operating class I'm happy to contribute that (IWD already does this).

That might be easier, though I guess it needs to have an opt-in from
userspace to solve this issue.

> And I'm not sure what you mean about it not working with MLO, I don't
> know much about it.

I don't know how OCV works with MLO in the first place, but I guess it'd
have to be per link?

So I guess it would work, just have to be done for each link.

> Also I do think there would be some value doing (1) in general as far
> as it being non-destructive. ieee80211_mgd_assoc() starts modifying
> state almost immediately making any failure (even -EBUSY) result in a
> disconnect AFAICT. This seems kinda bad...

Well, there could be some plausible reordering here, but a lot of hw/fw
fundamentally cannot try to make a new connection while maintaining an
old one, so in general you can't really fix that completely.

johannes