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 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? johannes
