[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250109094824.39cef463@kernel.org>
Date: Thu, 9 Jan 2025 09:48:24 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Andrew Lunn
<andrew+netdev@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Jonathan
Corbet <corbet@....net>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Simon Horman
<horms@...nel.org>, Russell King <linux@...linux.org.uk>, Maxime Chevallier
<maxime.chevallier@...tlin.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next v6 2/7] net: ethtool: plumb PHY stats to PHY
drivers
On Thu, 9 Jan 2025 18:27:44 +0100 Oleksij Rempel wrote:
> > So we traded on set of static inlines for another?
> > What's wrong with adding a C source which is always built in?
> > Like drivers/net/phy/stubs.c, maybe call it drivers/net/phy/accessors.c
> > or drivers/net/phy/helpers.c
>
> I chose the current stubs approach based on existing examples like
> hw_timestamps. Any implementation, including the current one, will have
> zero kernel size impact because each function is only used once. While
> moving them to a C source file is an option, it doesn't seem necessary
> given the current usage pattern. Do we really want to spend more time on
> this for something that won’t impact functionality or size? :)
If we keep following existing approaches we'll not have any chance
to improve :/
But if you feel strongly it's fine. You do need to respin to fix what
Simon pointed out tho, either way.
Powered by blists - more mailing lists