On 5/21/2025 2:40 PM, Johannes Berg wrote: >>>>> >>>> The following snippet of code tests the value of radio_id in >>>> nl80211_set_wiphy() in net/wireless/nl80211.c: >>>> + /* Radio idx is not expected for non-multi radio wiphy */ >>>> + if (rdev->wiphy.n_radio <= 0) >>>> + return -EINVAL; >>>> >>>> This snippet returns an error if the radio_id is negative, so radio_id >>>> passed to set_rts_threshold() will always be positive. So can we retain >>>> u8 data type for radio_id? >>> >>> I quote from the commit message: >>> >>>> A value of NL80211_WIPHY_RADIO_ID_INVALID(-1) indicates radio index is not >>>> mentioned and the configuration applies to all radio(s) of the wiphy. >>> >>> So now something is at least _very_ confusing. >>> >> I can rewrite the code to something like this: >> - Change the data type of radio_id to int. >> - NL80211_WIPHY_RADIO_ID_INVALID value assigned a -1. >> - Set RTS threshold for all radios when radio_id is -1. >> >> Is this okay? > > I honestly thought the last two items were already the case? > Yes those were the case. The history goes back to v6 of the patch series. Quoting your comment: "And why should the attribute even be signed, when you explicitly reject negative values anyway? Seems like it should simply be unsigned?" So I came under the impression that it would be better to change the radio_id datatype to u8, instead. Now with this, (u8)-1 would give 255 and when driver changes come in, I was planning on checking if radio_id >= wiphy->n_radios If this condition returns true, I was planning on setting RTS threshold to all radios in the wiphy. > johannes
