[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <f16fb810-f70d-40ac-8e9d-2ada008c446d@app.fastmail.com>
Date: Thu, 20 Apr 2023 08:31:17 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "kernel test robot" <lkp@...el.com>, "Andrew Lunn" <andrew@...n.ch>
Cc: llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
"Christian Marangi" <ansuelsmth@...il.com>,
Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
"Florian Fainelli" <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
"Jakub Kicinski" <kuba@...nel.org>
Subject: Re: [lunn:v6.3-rc2-net-next-phy-leds 5/15] ld.lld: error: undefined symbol:
devm_mdiobus_alloc_size
On Fri, Mar 24, 2023, at 12:36, kernel test robot wrote:
>>> ld.lld: error: undefined symbol: devm_mdiobus_alloc_size
> >>> referenced by phy.h:458 (include/linux/phy.h:458)
> >>>
> drivers/net/ethernet/microchip/lan743x_main.o:(lan743x_pcidev_probe) in
> archive vmlinux.a
> >>> referenced by phy.h:458 (include/linux/phy.h:458)
> >>> drivers/net/ethernet/ni/nixge.o:(nixge_probe) in
> archive vmlinux.a
>
> Kconfig warnings: (for reference only)
> WARNING: unmet direct dependencies detected for PHYLIB
It looks like this has hit linux-next now, I'm seeing the same problem in
my own randconfig builds after Andrew's 01e5b728e9e4 ("net: phy: Add a
binding for PHY LEDs").
> Depends on [m]: NETDEVICES [=y] && (LEDS_CLASS [=m] || LEDS_CLASS
> [=m]=n)
> Selected by [y]:
> - PHYLINK [=y] && NETDEVICES [=y]
> - TIGON3 [=y] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_BROADCOM [=y] && PCI [=y] && PTP_1588_CLOCK_OPTIONAL [=y]
> - LAN743X [=y] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_MICROCHIP [=y] && PCI [=y] && PTP_1588_CLOCK_OPTIONAL [=y]
> - NI_XGE_MANAGEMENT_ENET [=y] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_NI [=y] && HAS_IOMEM [=y] && HAS_DMA [=y]
> - XILINX_EMACLITE [=y] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_XILINX [=y] && HAS_IOMEM [=y]
> Selected by [m]:
> - ALTERA_TSE [=m] && NETDEVICES [=y] && ETHERNET [=y] && HAS_DMA [=y]
> - DNET [=m] && NETDEVICES [=y] && ETHERNET [=y] && HAS_IOMEM [=y]
> - B44 [=m] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_BROADCOM [=y] && SSB_POSSIBLE [=y] && HAS_DMA [=y]
> - KS8851_MLL [=m] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_MICREL [=y] && HAS_IOMEM [=y] && PTP_1588_CLOCK_OPTIONAL [=y]
> - SMSC911X [=m] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_SMSC [=y] && HAS_IOMEM [=y]
> - SMSC9420 [=m] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_SMSC [=y] && PCI [=y]
> - XILINX_LL_TEMAC [=m] && NETDEVICES [=y] && ETHERNET [=y] &&
> NET_VENDOR_XILINX [=y] && HAS_IOMEM [=y]
> - USB_NET_AX88179_178A [=m] && NETDEVICES [=y] && USB_NET_DRIVERS
> [=m] && USB_USBNET [=m]
The problem here is that both PHYLIB and LEDS_CLASS are user-visible
tristate symbols that are referenced from other Kconfig symbols with
both 'depends on' and 'select'. Having the two interact introduces a
number of ways that lead to circular dependencies.
It might be ok to use 'select LEDS_CLASS' from PHYLIB, but I have not
tried that yet and I expect this will result in other build failures.
A better solution would be to change all drivers that currently use
'select PHYLIB' to 'depends on PHYLIB' and have PHYLIB itself
'default ETHERNET' to avoid most of the regressions, but doing this
for 6.4 is a bit risky and can cause other problems.
Arnd
Powered by blists - more mailing lists