On Wed, 2023-08-30 at 10:35 +0530, Aditya Kumar Singh wrote:
> On 8/29/23 23:21, Johannes Berg wrote:
> > On Wed, 2023-03-15 at 18:58 +0530, Aditya Kumar Singh wrote:
> > >
> > > + {
> > > + .cmd = NL80211_CMD_SET_6GHZ_POWER_MODE,
> > > + .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
> > > + .doit = nl80211_set_6ghz_power_mode,
> > > + .flags = GENL_UNS_ADMIN_PERM,
> > > + .internal_flags = IFLAGS(NL80211_FLAG_NEED_NETDEV |
> > > + NL80211_FLAG_MLO_VALID_LINK_ID),
> > > + },
> >
> > Why is this even a new command, rather than a parameter to start AP or
> > similar?
> >
> A new command was introduced because to give user space a knob to change
> power mode as and when required. Let's suppose AFC response has not yet
> arrived, AP could be started in Low Power mode. Now once AFC rules are
> applied (not going in detail here how that will happen) and user space
> knows about it, it can send command to switch to Standard Power Mode right?
At least for AP that could also be a beacon update, like most other
operational parameters. You have to update the beacon _anyway_ since you
indicate in the beacon what you're doing.
So that by itself doesn't really introduce the requirement to have a
separate command.
> > Why do we even set it in client mode from userspace?
And you didn't comment on this - what userspace do you expect to use it
in client mode? I can see hostapd in AP mode, I guess, but in client
mode I don't see how this could be used? Anyway you're tied to what the
AP is doing, no?
> > > static struct genl_family nl80211_fam __ro_after_init = {
> > > @@ -17409,7 +17473,7 @@ static struct genl_family nl80211_fam __ro_after_init = {
> > > .n_ops = ARRAY_SIZE(nl80211_ops),
> > > .small_ops = nl80211_small_ops,
> > > .n_small_ops = ARRAY_SIZE(nl80211_small_ops),
> > > - .resv_start_op = NL80211_CMD_REMOVE_LINK_STA + 1,
> > > + .resv_start_op = NL80211_CMD_SET_6GHZ_POWER_MODE + 1,
> > >
> >
> > Obviously, this should not be done.
> If this hunk is not there, the command was not going through. Upon
> digging further found out that the number of commands declared in the
> array and the count provided here has some relation. And that too with
> the last element added. Since a new element was added, modified it
> accordingly.
No no, that wasn't a discussion. I'm telling you, this is wrong, and I
will not apply a patch that does this. If you needed it, you did
something wrong in userspace.
johannes
