Subject: Re: [PATCH net-next v3 03/10] ethtool: allow ethtool op set_eee to set an NL extack message

From: Jakub Kicinski <[email-masked]>
Date: Wed, 15 Jan 2025 09:53:53 -0800

On Wed, 15 Jan 2025 18:46:35 +0100 Heiner Kallweit wrote:
> On 15.01.2025 00:00, Jakub Kicinski wrote:
> > On Sun, 12 Jan 2025 14:28:22 +0100 Heiner Kallweit wrote:  
> >> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> index f711bfd75..8ee047747 100644
> >> --- a/include/linux/ethtool.h
> >> +++ b/include/linux/ethtool.h
> >> @@ -270,6 +270,7 @@ struct ethtool_keee {
> >>  	__ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
> >>  	__ETHTOOL_DECLARE_LINK_MODE_MASK(advertised);
> >>  	__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertised);
> >> +	struct netlink_ext_ack *extack;
> >>  	u32	tx_lpi_timer;
> >>  	bool	tx_lpi_enabled;
> >>  	bool	eee_active;  
> > 
> > :S I don't think we have a precedent for passing extack inside 
> > the paramter struct. I see 25 .set_eee callbacks, not crazy many.
> > Could you plumb this thru as a separate argument, please?  
> 
> I see your point regarding calling convention consistency.
> Drawback of passing extack as a separate argument is that we would
> have to do the same extension also to functions in phylib.
> Affected are phy_ethtool_set_eee and genphy_c45_ethtool_set_eee,
> because extack is to be used in the latter.
> Passing extack within struct ethtool_keee we don't have to change
> the functions in the call chain. So passing extack separately
> comes at a cost. Is it worth it?

I doubt it will be uglier than stuffing transient pointers into a config
struct. But we will only know for sure once the code is written..