On 5/21/2025 2:50 PM, Johannes Berg wrote: > On Wed, 2025-05-21 at 14:47 +0530, Roopni Devanathan wrote: >>> >> 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?" > > Well that was regarding the _attribute_, you had that as NLA_S8 at that > point. > >> So I came under the impression that it would be better to change the radio_id >> datatype to u8, instead. > > Oh, well, I didn't really mean to give that impression. > > In the userspace API we have an attribute that can be in [0, n_radios-1] > or unspecified if no specific radio is intended, which is how it'll work > with existing userspace anyway. > > In the internal APIs, using -1 with a properly signed value seems > better, since we don't have the option of "not specifying" an integer. > Now, I get your picture, thanks for explaining. >> 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. > > That seems pretty odd, -1 for an invalid value is much easier to handle? > I think so, too. As mentioned already, I can change the datatype of radio_id to int, retain the NL80211_WIPHY_RADIO_ID_INVALID value at -1. This would mean that passing default value to individual drivers will set RTS threshold to all the radios in a wiphy, or it will be the case of single wiphy architecture. I hope this change will be sound and standing? > johannes
