On 5/21/2025 3:00 PM, Johannes Berg wrote: > On Wed, 2025-05-21 at 14:58 +0530, Roopni Devanathan wrote: >> >> On 5/21/2025 2:56 PM, Johannes Berg wrote: >>> On Wed, 2025-05-21 at 14:55 +0530, Roopni Devanathan wrote: >>>> >>>> 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? >>> >>> Right, that sounds good. Except it still shouldn't be >>> NL80211_WIPHY_RADIO_ID_INVALID since negative values are not part of the >>> nl80211 API :) >>> >> So, why not, we give a value of 255 to NL80211_WIPHY_RADIO_ID_DEFAULT? Then, we can >> retain u8 datatype of radio_id. > > The internal "all radios" (and otherwise invalid) value is _never_ part > of the API. Quoting myself: > >> 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. > > So no, regardless of the value (and I still think -1 is better), this > define simply doesn't belong to the nl80211 API. > I am not sure where to define NL80211_WIPHY_RADIO_ID_DEFAULT other than in nl80211. Can you point out to your expectation? > johannes
