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