On Sat, 2024-01-27 at 10:28 +0530, Aditya Kumar Singh wrote: > > > > Hm. I'm going to send some patches soon that remove the puncturing stuff > > and move it into the chandef (as we discussed elsewhere), but just > > noting that - doesn't need to concern you here, I think. > > > > Oh okay! Let's see if at all it conflicts, will send a re-based once > those gets merged. I did send my patches now, so you're very much welcome to take a look at all that I've posted (and provide comments, I'd appreciate it!), but *please* don't rebase right now or anything, was just noting this in passing. If we're happy with both sets of patches surely I can also deal with the conflicts, that will not be hard. > > > + if (cfg80211_chandef_identical(¶ms->chandef, &link_conf->chandef)) > > > return -EINVAL; > > > > Also another thing unrelated to your patch - I'm thinking about removing > > that identical() check entirely - you might want to switch to the same > > channel with quiet=1. At least for testing that'd be really useful, and > > I don't think it really serves any purpose to forbid it. > > > Yeah, we can do. But is there any actual use case? Also, what if some > notorious user space application simply sends NL command without even > quiet=1? There should be some check I guess? I did post that patch too, and we're probably better off discussing it there, but ... I'm not sure we care much about a broken userspace application running with root privileges breaking something here? :-) And at least for testing it's very useful to be able to do that. Agree that identical channel and quiet==0 doesn't make _sense_, but even then I'm not sure there's a lot of value in not permitting it. With quiet==1 at least it does make some sense still though, and we're currently not allowing it, hence my patch (to be able to test scenarios like that we saw elsewhere.) Anyway, again, don't bother about rebase or anything! johannes
