On Thu, 2024-05-30 at 13:49 +0000, Zong-Zhe Yang wrote: > Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > On Thu, 2024-05-23 at 16:22 +0800, kevin_yang@xxxxxxxxxxx wrote: > > > > [...] > > > > This checks that the *first* link the STA used isn't 6 GHz, but maybe it should be *any* link? > > > > But then again, we don't really need this check for an MLO STA since it will have HT supported > > unless it associated on 6 GHz. Maybe we should just not do the check this way, but check if it > > has HT or VHT or HE or something like that? > > > > I think there are two points here. > > 1. the way to avoid this NULL dereference > (Current patch just followed original logic and made it runnable on both MLD and non-MLD.) > > According to comments, I will change to check ht_supported/vht_supported/has_he/has_eht. > Then, it doesn't need to reference chanreq.oper.chan here. So, there won't be NULL dereference. > > 2. the check logic when MLD > (Current patch didn't consider this properly.) > > According to spec., BA agreement does once per TID and apply to all corresponding links. > So, I am thinking maybe I check the conditions on all valid_links when MLD. > And, only check deflink when non-MLD. Well, spec also requires that you have EHT (on all links) to be able to do MLO in the first place, so you shouldn't be connected. IOW, checking one link should be sufficient? And that can even be deflink, because for a STA that's always used as the assoc link (unlike for vif) johannes
