From: Arnd Bergmann <[email protected]>
The mdio code in stmmac now directly links into both the lynx_pcs and
the xpcs device drivers, but the lynx_pcs dependency is only enforced
for the altera variant of stmmac, which is the one that actually uses it.
Building stmmac for a non-altera platform therefore causes a link
failure:
arm-linux-gnueabi-ld: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o: in function `stmmac_mdio_unregister':
stmmac_mdio.c:(.text+0x1418): undefined reference to `lynx_pcs_destroy'
I've tried to come up with a patch that moves this dependency back into
the dwmac-socfpga.c file, but there was no easy and obvious way to
do this. It also seems that this would not be a proper solution, but
instead there should be a real abstraction for pcs drivers that lets
device drivers handle this transparently.
As the lynx_pcs driver is tiny, it appears that we can just avoid the
link error by always forcing it to be built when the stmmac driver
is, even for non-altera platforms. This matches what we already do
for the xpcs variant that is used by the intel and tegra variants of
stmmac.
Fixes: 5d1f3fe7d2d54 ("net: stmmac: dwmac-sogfpga: use the lynx pcs driver")
Signed-off-by: Arnd Bergmann <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 5583f0b055ec7..fa956f2081a53 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -5,6 +5,7 @@ config STMMAC_ETH
depends on PTP_1588_CLOCK_OPTIONAL
select MII
select PCS_XPCS
+ select PCS_LYNX
select PAGE_POOL
select PHYLINK
select CRC32
@@ -160,7 +161,6 @@ config DWMAC_SOCFPGA
select MFD_SYSCON
select MDIO_REGMAP
select REGMAP_MMIO
- select PCS_LYNX
help
Support for ethernet controller on Altera SOCFPGA
--
2.39.2
On Wed, Jun 07, 2023 at 03:56:32PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
>
> The mdio code in stmmac now directly links into both the lynx_pcs and
> the xpcs device drivers, but the lynx_pcs dependency is only enforced
> for the altera variant of stmmac, which is the one that actually uses it.
>
> Building stmmac for a non-altera platform therefore causes a link
> failure:
>
> arm-linux-gnueabi-ld: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o: in function `stmmac_mdio_unregister':
> stmmac_mdio.c:(.text+0x1418): undefined reference to `lynx_pcs_destroy'
>
> I've tried to come up with a patch that moves this dependency back into
> the dwmac-socfpga.c file, but there was no easy and obvious way to
> do this. It also seems that this would not be a proper solution, but
> instead there should be a real abstraction for pcs drivers that lets
> device drivers handle this transparently.
There is already a patch set on netdev fixing this properly.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Jun 07, 2023 at 03:12:00PM +0100, Russell King (Oracle) wrote:
> On Wed, Jun 07, 2023 at 03:56:32PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann <[email protected]>
> >
> > The mdio code in stmmac now directly links into both the lynx_pcs and
> > the xpcs device drivers, but the lynx_pcs dependency is only enforced
> > for the altera variant of stmmac, which is the one that actually uses it.
> >
> > Building stmmac for a non-altera platform therefore causes a link
> > failure:
> >
> > arm-linux-gnueabi-ld: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o: in function `stmmac_mdio_unregister':
> > stmmac_mdio.c:(.text+0x1418): undefined reference to `lynx_pcs_destroy'
> >
> > I've tried to come up with a patch that moves this dependency back into
> > the dwmac-socfpga.c file, but there was no easy and obvious way to
> > do this. It also seems that this would not be a proper solution, but
> > instead there should be a real abstraction for pcs drivers that lets
> > device drivers handle this transparently.
>
> There is already a patch set on netdev fixing this properly.
Yes, let's focus on the solution proposed here:
https://lore.kernel.org/netdev/[email protected]/T/#t
--
pw-bot: reject