On 6/8/2026 4:58 PM, Jakub Kicinski wrote:

On Mon, 8 Jun 2026 15:15:48 -0700 Jacob Keller wrote:

quoted

quoted

@@ -935,7 +935,13 @@ struct kernel_ethtool_ts_info {
  * these bits separate, per GET and SET. GET is much easier to "unlock".
  */
 #define ETHTOOL_OP_NEEDS_RTNL_LINKSETTINGS	BIT(0)
-#define ETHTOOL_OP_NEEDS_RTNL_GPAUSEPARAM	BIT(1)
+#define ETHTOOL_OP_NEEDS_RTNL_SPFLAGS		BIT(1)
+#define ETHTOOL_OP_NEEDS_RTNL_SRINGPARAM	BIT(2)
+#define ETHTOOL_OP_NEEDS_RTNL_SCHANNELS		BIT(3)
+#define ETHTOOL_OP_NEEDS_RTNL_SCOALESCE		BIT(4)
+#define ETHTOOL_OP_NEEDS_RTNL_GPAUSEPARAM	BIT(5)
+#define ETHTOOL_OP_NEEDS_RTNL_SPAUSEPARAM	BIT(6)
+#define ETHTOOL_OP_NEEDS_RTNL_RSS		BIT(7)  

Whats the reasoning for changing order here? Is this sorted somehow?

I went back and forth on this a little but at the end I wanted the GET
and SET bits to be next to each other (PAUSE ones specifically, that's
the only case where phylink forces us to add a GET bit).

quoted

Would it make more sense to use an enum to define the bits instead so
that patches don't have to do a -/+ of the same NAME?

We'd need to add enum for bit ids and then defines for BIT(id)?
Dunno, personally I don't really like that. And we never switch
on the values here so enum buys us little. Maybe BTF, that's about it?

Its fine as is. I just didn't like seeing the bit indexes requiring
change mid-series.

You could just leave the indexes as the final values, but that also
looks odd, so I think its just a choice of which oddity do you prefer.
Regardless, it is noise since the only difference is inter-patch diffs
for stuff that will all be merged at once.