On Thu, 2025-05-29 at 08:36 -0700, Jeff Johnson wrote:
>
> > > > +++ b/include/net/mac80211.h
> > > > @@ -4572,7 +4572,8 @@ struct ieee80211_ops {
> > > > struct ieee80211_key_conf *key,
> > > > struct ieee80211_key_seq *seq);
> > > > int (*set_frag_threshold)(struct ieee80211_hw *hw, u32 value);
> > > > - int (*set_rts_threshold)(struct ieee80211_hw *hw, u32 value);
> > > > + int (*set_rts_threshold)(struct ieee80211_hw *hw, int radio_id,
> > > > + u32 value);
> > > > int (*sta_add)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> > > > struct ieee80211_sta *sta);
> > > > int (*sta_remove)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> > >
> > > rather than have one patch that modifies the get_rts_threshold API, another
> > > that modifies the set_rts_threshold API, and future ones that will modify
> > > others, should we put these interface changes that affect all drivers in a
> > > single patch so that the individual driver maintainers only have to deal with
> > > this disruption once rather than for each attribute?
> > If we are going to change the interfaces of all the handlers of these
> > attributes, I can assign a default radio_idx (-1) to all the APIs. Can I go
> > ahead implementing this?
>
> That makes sense to me. Johannes?
I don't really see a huge advantage, given that I'm going to apply those
patches either way? Do you think conflicts are likely? But if you prefer
we can do it that way, then just should separate out those changes to
completely non-functional patch (i.e. please don't mix actually changing
the RTS threshold in this patch with API updates for the others, do API
updates for all beforehand.)
johannes
