On Mon, 2023-08-21 at 19:11 +0800, Wen Gong wrote:
> On 8/21/2023 6:57 PM, Johannes Berg wrote:
> > On Mon, 2023-08-21 at 18:36 +0800, Wen Gong wrote:
> > > On 8/21/2023 5:06 PM, Johannes Berg wrote:
> > > > On Mon, 2023-08-21 at 10:59 +0200, Johannes Berg wrote:
> > > > > From: Johannes Berg <johannes.berg@xxxxxxxxx>
> > > > >
> > > > > This reverts commit cb751b7a57e5 ("mac80211: add parse regulatory info
> > > > > in 6 GHz operation information") which added a station type bss_conf
> > > > > assignment in a parsing helper function, which will corrupt mesh data.
> > > > >
> > > > Ah crap this won't work, rtw89 already uses this.
> > > >
> > > > Wen please send a fix for this ASAP.
> > > >
> > > > johannes
> > > Hi Johannes,
> > >
> > > I looked the patch some times, but I do not know how it corrupt mesh data,
> > >
> > > Is there any clue for me?
> > Hah, no, I'm wrong ... I looked at it and for some reason thought of
> > u.mgd instead of vif.bss_conf. Sorry!
> >
> > Still it's not correct though to write to vif.bss_conf in this function
> > because it's called from mesh_matches_local() to see if it's even
> > compatible, for example, so the mere calling a "give me the 6 GHz
> > chandef" function doesn't indicate we actually are going to use it now.
>
> Do you mean mesh_matches_local() is only a try to call
> ieee80211_chandef_he_6ghz_oper(),
>
> NOT real use the 6 GHz chandef?
Yes, I believe so.
Anyway it would seem better for a utility function to have clearer
defined output, I think?
johannes
