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: <ca4645cc-70c0-6c2a-993f-2e1d277eefb4@gmail.com>
Date:   Thu, 27 Apr 2023 09:50:31 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: Automatically adding OCI in mac80211
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
Cc:     ilan.peer@intel.com
References: <432703ce83ac979ba06e2b85d6dc500f246c6a76.camel@gmail.com>
 <199f2ac280a1e1a195add45290411a9c1dc519fc.camel@sipsolutions.net>
 <cba322cbf992067e843114ab53da610978768d64.camel@gmail.com>
 <33e23355cd8cfcf2296bba1272df814af32b003f.camel@gmail.com>
 <38649e92c619dc2f1482aba08c977d1611064e05.camel@sipsolutions.net>
From:   James Prestwood <prestwoj@gmail.com>
In-Reply-To: <38649e92c619dc2f1482aba08c977d1611064e05.camel@sipsolutions.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Johannes,

On 4/24/23 10:15 AM, Johannes Berg wrote:
> 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 :)

No problem, I had completely forgotten about this as well. Moved on to 
other things :)

> 
>> So thinking about it more I think we have two options:
>>
>> 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.

yeah I started down this path and quickly got in over my head.

> 
>> 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.

Yeah, probably some flag attribute would be needed. At the moment I've 
got other priorities but I'll keep this in mind.

Thanks for getting back to me though.
- James

> 
>> 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