[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <01d60932-f78f-4e4b-88e7-f331535b8076@lunn.ch>
Date: Tue, 5 Nov 2024 04:02:50 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Alistair Francis <alistair23@...il.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux@...linux.org.uk, hkallweit1@...il.com,
Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH] include: mdio: Guard inline function with CONFIG_MDIO
> Which comes from autogenerated C code like this
>
> ```
> void mdio45_ethtool_gset__extern(const struct mdio_if_info *mdio,
> struct ethtool_cmd *ecmd) { mdio45_ethtool_gset(mdio, ecmd); }
> ```
>
> mdio45_ethtool_gset__extern() is never called, so I'm not clear why
> it's not optimised out.
I think you need to understand this first, before deciding on the path
forward.
> It's not only MDIO that hits this, but so far there aren't too many
> cases. That will obviously depend on the config used though.
>
> There will be issues like this over the kernel. I'm not sure fixing
> them all is the right approach as it might be too much work and too
> hard to narrow down all occurance.
Actually, that is mostly just CPU cycles. There are build bots which
make builds with random configurations. Arnd Bergmann has one such
bot, for example. Systems like that will find the issues for you.
> But to me it seems like the correct
> fix as the current code is calling a function that might not exist,
> hence the patch :)
As 0-day has shown, another build bot, your patch is not correct and
causes problems. You can try again, but maybe first dig into the
linker.
Humm, interesting. I don't actually find anything calling
mdio45_ethtool_gset(). So you might be able to just remove it. And
then i think you can remove mdio45_ethtool_gset_npage(). But i might
be wrong...
Andrew
Powered by blists - more mailing lists