Returning EPROBE_DEFER after probing a bus may result in an infinite
probe loop if the EPROBE_DEFER error is never resolved. For example, if
the PCS is located on another MDIO bus and that MDIO bus is missing its
driver then we will always return EPROBE_DEFER. But if there are any
devices on our own MDIO bus (such as PHYs), those devices will be
successfully bound before we fail our own probe. This will cause the
deferred probing infrastructure to continuously try to probe our device.
To prevent this, split the MAC and MDIO functionality into separate
auxiliary devices. These can then be re-probed independently.
Fixes: 1a02556086fc ("net: axienet: Properly handle PCS/PMA PHY for 1000BaseX mode")
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---
drivers/net/ethernet/xilinx/Kconfig | 1 +
.../net/ethernet/xilinx/xilinx_axienet_main.c | 76 +++++++++++--------
.../net/ethernet/xilinx/xilinx_axienet_mdio.c | 32 +++++---
3 files changed, 69 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/Kconfig b/drivers/net/ethernet/xilinx/Kconfig
index 7502214cc7d5..3b940d2d3115 100644
--- a/drivers/net/ethernet/xilinx/Kconfig
+++ b/drivers/net/ethernet/xilinx/Kconfig
@@ -27,6 +27,7 @@ config XILINX_AXI_EMAC
tristate "Xilinx 10/100/1000 AXI Ethernet support"
depends on HAS_IOMEM
depends on XILINX_DMA
+ select AUXILIARY_BUS
select PHYLINK
select DIMLIB
help
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index c2512c04a88f..2f26474b16f6 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -22,6 +22,7 @@
* - Add support for extended VLAN support.
*/
+#include <linux/auxiliary_bus.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/etherdevice.h>
@@ -2749,13 +2750,16 @@ static void axienet_disable_misc(void *clocks)
clk_bulk_disable_unprepare(XAE_NUM_MISC_CLOCKS, clocks);
}
-static int axienet_mac_probe(struct axienet_local *lp)
+static int axienet_mac_probe(struct auxiliary_device *auxdev,
+ const struct auxiliary_device_id *id)
{
+ struct axienet_local *lp = auxdev->dev.platform_data;
struct net_device *ndev = lp->ndev;
struct device_node *np;
int ret;
- SET_NETDEV_DEV(ndev, lp->dev);
+ auxiliary_set_drvdata(auxdev, ndev);
+ SET_NETDEV_DEV(ndev, &auxdev->dev);
if (lp->phy_mode == PHY_INTERFACE_MODE_SGMII ||
lp->phy_mode == PHY_INTERFACE_MODE_1000BASEX) {
np = of_parse_phandle(lp->dev->of_node, "pcs-handle", 0);
@@ -2818,9 +2822,9 @@ static int axienet_mac_probe(struct axienet_local *lp)
return ret;
}
-static void axienet_mac_remove(struct platform_device *pdev)
+static void axienet_mac_remove(struct auxiliary_device *auxdev)
{
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = auxiliary_get_drvdata(auxdev);
struct axienet_local *lp = netdev_priv(ndev);
unregister_netdev(ndev);
@@ -2829,9 +2833,9 @@ static void axienet_mac_remove(struct platform_device *pdev)
put_device(&lp->pcs_phy->dev);
}
-static void axienet_mac_shutdown(struct platform_device *pdev)
+static void axienet_mac_shutdown(struct auxiliary_device *auxdev)
{
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = auxiliary_get_drvdata(auxdev);
rtnl_lock();
netif_device_detach(ndev);
@@ -2877,6 +2881,24 @@ static int axienet_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(axienet_pm_ops,
axienet_suspend, axienet_resume);
+static const struct auxiliary_device_id xilinx_axienet_mac_id_table[] = {
+ { .name = KBUILD_MODNAME ".mac", },
+ { },
+};
+MODULE_DEVICE_TABLE(auxiliary, xilinx_axienet_mac_id_table);
+
+static struct auxiliary_driver xilinx_axienet_mac = {
+ .name = "mac",
+ .id_table = xilinx_axienet_mac_id_table,
+ .probe = axienet_mac_probe,
+ .remove = axienet_mac_remove,
+ .shutdown = axienet_mac_shutdown,
+ .driver = {
+ .pm = &axienet_pm_ops,
+ },
+};
+module_auxiliary_driver(xilinx_axienet_mac)
+
/**
* axienet_probe - Axi Ethernet probe function.
* @pdev: Pointer to platform device structure.
@@ -2892,12 +2914,14 @@ static DEFINE_SIMPLE_DEV_PM_OPS(axienet_pm_ops,
static int axienet_probe(struct platform_device *pdev)
{
int ret;
+ struct auxiliary_device *auxdev;
struct device_node *np;
struct axienet_local *lp;
struct net_device *ndev;
struct resource *ethres;
u8 mac_addr[ETH_ALEN];
int addr_width = 32;
+ char name[20];
u32 value;
ndev = devm_alloc_etherdev(&pdev->dev, sizeof(*lp));
@@ -2906,7 +2930,6 @@ static int axienet_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ndev);
- SET_NETDEV_DEV(ndev, &pdev->dev);
ndev->features = NETIF_F_SG;
ndev->ethtool_ops = &axienet_ethtool_ops;
@@ -3174,36 +3197,27 @@ static int axienet_probe(struct platform_device *pdev)
lp->tx_dma_cr = axienet_calc_cr(lp, XAXIDMA_DFT_TX_THRESHOLD,
XAXIDMA_DFT_TX_USEC);
- ret = axienet_mdio_setup(lp);
- if (ret)
- dev_warn(&pdev->dev,
- "error registering MDIO bus: %d\n", ret);
-
- ret = axienet_mac_probe(lp);
- if (!ret)
- return 0;
-
- if (lp->mii_bus)
- axienet_mdio_teardown(lp);
- return ret;
-}
-
-static void axienet_remove(struct platform_device *pdev)
-{
- struct net_device *ndev = platform_get_drvdata(pdev);
- struct axienet_local *lp = netdev_priv(ndev);
-
- axienet_mac_remove(pdev);
- axienet_mdio_teardown(lp);
+ snprintf(name, sizeof(name), "mdio.%llx",
+ (unsigned long long)lp->regs_start);
+ auxdev = devm_auxiliary_device_create(&pdev->dev, name, lp);
+ if (IS_ERR(auxdev))
+ return dev_err_probe(&pdev->dev, PTR_ERR(auxdev),
+ "could not create MDIO bus\n");
+
+ snprintf(name, sizeof(name), "mac.%llx",
+ (unsigned long long)lp->regs_start);
+ auxdev = devm_auxiliary_device_create(&pdev->dev, name, lp);
+ if (IS_ERR(auxdev))
+ return dev_err_probe(&pdev->dev, PTR_ERR(auxdev),
+ "could not create MAC\n");
+
+ return 0;
}
static struct platform_driver axienet_driver = {
.probe = axienet_probe,
- .remove = axienet_remove,
- .shutdown = axienet_mac_shutdown,
.driver = {
.name = "xilinx_axienet",
- .pm = &axienet_pm_ops,
.of_match_table = axienet_of_match,
},
};
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
index 9ca2643c921e..8874525ec3f3 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
@@ -9,6 +9,7 @@
* Copyright (c) 2010 - 2012 Xilinx, Inc. All rights reserved.
*/
+#include <linux/auxiliary_bus.h>
#include <linux/clk.h>
#include <linux/of_address.h>
#include <linux/of_mdio.h>
@@ -277,12 +278,15 @@ static int axienet_mdio_enable(struct axienet_local *lp, struct device_node *np)
* Sets up the MDIO interface by initializing the MDIO clock.
* Register the MDIO interface.
**/
-int axienet_mdio_setup(struct axienet_local *lp)
+static int axienet_mdio_probe(struct auxiliary_device *auxdev,
+ const struct auxiliary_device_id *id)
{
+ struct axienet_local *lp = auxdev->dev.platform_data;
struct device_node *mdio_node;
struct mii_bus *bus;
int ret;
+ auxiliary_set_drvdata(auxdev, lp);
bus = mdiobus_alloc();
if (!bus)
return -ENOMEM;
@@ -294,7 +298,7 @@ int axienet_mdio_setup(struct axienet_local *lp)
bus->name = "Xilinx Axi Ethernet MDIO";
bus->read = axienet_mdio_read;
bus->write = axienet_mdio_write;
- bus->parent = lp->dev;
+ bus->parent = &auxdev->dev;
lp->mii_bus = bus;
mdio_node = of_get_child_by_name(lp->dev->of_node, "mdio");
@@ -317,15 +321,25 @@ int axienet_mdio_setup(struct axienet_local *lp)
return ret;
}
-/**
- * axienet_mdio_teardown - MDIO remove function
- * @lp: Pointer to axienet local data structure.
- *
- * Unregisters the MDIO and frees any associate memory for mii bus.
- */
-void axienet_mdio_teardown(struct axienet_local *lp)
+static void axienet_mdio_remove(struct auxiliary_device *auxdev)
{
+ struct axienet_local *lp = auxiliary_get_drvdata(auxdev);
+
mdiobus_unregister(lp->mii_bus);
mdiobus_free(lp->mii_bus);
lp->mii_bus = NULL;
}
+
+static const struct auxiliary_device_id xilinx_axienet_mdio_id_table[] = {
+ { .name = KBUILD_MODNAME ".mdio", },
+ { },
+};
+MODULE_DEVICE_TABLE(auxiliary, xilinx_axienet_mdio_id_table);
+
+static struct auxiliary_driver xilinx_axienet_mdio = {
+ .name = "mdio",
+ .id_table = xilinx_axienet_mdio_id_table,
+ .probe = axienet_mdio_probe,
+ .remove = axienet_mdio_remove,
+};
+module_auxiliary_driver(xilinx_axienet_mdio)
--
2.35.1.1320.gc452695387.dirtyOn Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote: > Returning EPROBE_DEFER after probing a bus may result in an infinite > probe loop if the EPROBE_DEFER error is never resolved. That sounds like a core problem. I also thought there was a time limit, how long the system will repeat probes for drivers which defer. This seems like the wrong fix to me. Andrew
On 6/21/25 03:33, Andrew Lunn wrote: > On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote: >> Returning EPROBE_DEFER after probing a bus may result in an infinite >> probe loop if the EPROBE_DEFER error is never resolved. > > That sounds like a core problem. I also thought there was a time > limit, how long the system will repeat probes for drivers which defer. > > This seems like the wrong fix to me. I agree. My first attempt to fix this did so by ignoring deferred probes from child devices, which would prevent "recursive" loops like this one [1]. But I was informed that failing with EPROBE_DEFER after creating a bus was not allowed at all, hence this patch. Limiting the number of deferred probe attempts (at least before continuing to boot) is a good idea in theory, but would not address the root of the issue. Setting a good threshold is not obvious, since there are almost certainly systems out there that are missing some device links and have a lot of deferred probes. --Sean [1] https://lore.kernel.org/all/CAGETcx-koKBvSXTHChYYF-qSU-r1cBUbLghJZcqtJOGQZjn3BA@mail.gmail.com/
On Mon, Jun 23, 2025 at 11:16:08AM -0400, Sean Anderson wrote: > On 6/21/25 03:33, Andrew Lunn wrote: > > On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote: > >> Returning EPROBE_DEFER after probing a bus may result in an infinite > >> probe loop if the EPROBE_DEFER error is never resolved. > > > > That sounds like a core problem. I also thought there was a time > > limit, how long the system will repeat probes for drivers which defer. > > > > This seems like the wrong fix to me. > > I agree. My first attempt to fix this did so by ignoring deferred probes > from child devices, which would prevent "recursive" loops like this one > [1]. But I was informed that failing with EPROBE_DEFER after creating a > bus was not allowed at all, hence this patch. O.K. So why not change the order so that you know you have all the needed dependencies before registering the MDIO bus? Quoting your previous email: > Returning EPROBE_DEFER after probing a bus may result in an infinite > probe loop if the EPROBE_DEFER error is never resolved. For example, > if the PCS is located on another MDIO bus and that MDIO bus is > missing its driver then we will always return EPROBE_DEFER. Why not get a reference on the PCS device before registering the MDIO bus? Andrew
On 6/23/25 14:27, Andrew Lunn wrote: > On Mon, Jun 23, 2025 at 11:16:08AM -0400, Sean Anderson wrote: >> On 6/21/25 03:33, Andrew Lunn wrote: >> > On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote: >> >> Returning EPROBE_DEFER after probing a bus may result in an infinite >> >> probe loop if the EPROBE_DEFER error is never resolved. >> > >> > That sounds like a core problem. I also thought there was a time >> > limit, how long the system will repeat probes for drivers which defer. >> > >> > This seems like the wrong fix to me. >> >> I agree. My first attempt to fix this did so by ignoring deferred probes >> from child devices, which would prevent "recursive" loops like this one >> [1]. But I was informed that failing with EPROBE_DEFER after creating a >> bus was not allowed at all, hence this patch. > > O.K. So why not change the order so that you know you have all the > needed dependencies before registering the MDIO bus? > > Quoting your previous email: > >> Returning EPROBE_DEFER after probing a bus may result in an infinite >> probe loop if the EPROBE_DEFER error is never resolved. For example, >> if the PCS is located on another MDIO bus and that MDIO bus is >> missing its driver then we will always return EPROBE_DEFER. > > Why not get a reference on the PCS device before registering the MDIO > bus? Because the PCS may be on the MDIO bus. This is probably the most-common case. --Sean
On Mon, Jun 23, 2025 at 02:48:53PM -0400, Sean Anderson wrote: > On 6/23/25 14:27, Andrew Lunn wrote: > > On Mon, Jun 23, 2025 at 11:16:08AM -0400, Sean Anderson wrote: > >> On 6/21/25 03:33, Andrew Lunn wrote: > >> > On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote: > >> >> Returning EPROBE_DEFER after probing a bus may result in an infinite > >> >> probe loop if the EPROBE_DEFER error is never resolved. > >> > > >> > That sounds like a core problem. I also thought there was a time > >> > limit, how long the system will repeat probes for drivers which defer. > >> > > >> > This seems like the wrong fix to me. > >> > >> I agree. My first attempt to fix this did so by ignoring deferred probes > >> from child devices, which would prevent "recursive" loops like this one > >> [1]. But I was informed that failing with EPROBE_DEFER after creating a > >> bus was not allowed at all, hence this patch. > > > > O.K. So why not change the order so that you know you have all the > > needed dependencies before registering the MDIO bus? > > > > Quoting your previous email: > > > >> Returning EPROBE_DEFER after probing a bus may result in an infinite > >> probe loop if the EPROBE_DEFER error is never resolved. For example, > >> if the PCS is located on another MDIO bus and that MDIO bus is > >> missing its driver then we will always return EPROBE_DEFER. > > > > Why not get a reference on the PCS device before registering the MDIO > > bus? > > Because the PCS may be on the MDIO bus. This is probably the most-common > case. So you are saying the PCS is physically there, but the driver is missing because of configuration errors? Then it sounds like a kconfig issue? Or are you saying the driver has been built but then removed from /lib/modules/ Andrew
On 6/23/25 18:45, Andrew Lunn wrote:
> On Mon, Jun 23, 2025 at 02:48:53PM -0400, Sean Anderson wrote:
>> On 6/23/25 14:27, Andrew Lunn wrote:
>> > On Mon, Jun 23, 2025 at 11:16:08AM -0400, Sean Anderson wrote:
>> >> On 6/21/25 03:33, Andrew Lunn wrote:
>> >> > On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote:
>> >> >> Returning EPROBE_DEFER after probing a bus may result in an infinite
>> >> >> probe loop if the EPROBE_DEFER error is never resolved.
>> >> >
>> >> > That sounds like a core problem. I also thought there was a time
>> >> > limit, how long the system will repeat probes for drivers which defer.
>> >> >
>> >> > This seems like the wrong fix to me.
>> >>
>> >> I agree. My first attempt to fix this did so by ignoring deferred probes
>> >> from child devices, which would prevent "recursive" loops like this one
>> >> [1]. But I was informed that failing with EPROBE_DEFER after creating a
>> >> bus was not allowed at all, hence this patch.
>> >
>> > O.K. So why not change the order so that you know you have all the
>> > needed dependencies before registering the MDIO bus?
>> >
>> > Quoting your previous email:
>> >
>> >> Returning EPROBE_DEFER after probing a bus may result in an infinite
>> >> probe loop if the EPROBE_DEFER error is never resolved. For example,
>> >> if the PCS is located on another MDIO bus and that MDIO bus is
>> >> missing its driver then we will always return EPROBE_DEFER.
>> >
>> > Why not get a reference on the PCS device before registering the MDIO
>> > bus?
>>
>> Because the PCS may be on the MDIO bus. This is probably the most-common
>> case.
>
> So you are saying the PCS is physically there, but the driver is
> missing because of configuration errors? Then it sounds like a kconfig
> issue?
>
> Or are you saying the driver has been built but then removed from
> /lib/modules/
The latter. Or maybe someone just forgot to install it (or include it
with their initramfs). Or maybe there was some error with the MDIO bus.
There are two mutually-exclusive scenarios (that can both occur in the
same system). First, the PCS can be attached to our own MDIO bus:
MAC
|
+->MDIO
|
+->PCS
+->PHY (etc)
In this scenario, we have to probe the MDIO bus before we can look up
the PCS, since otherwise the PCS will always be missing when we look for
it. But if we do things in the right order then we can't get
EPROBE_DEFER, and so there's no risk of a probe loop.
Second, the PCS can be attached to some other MDIO bus:
MAC MDIO
| |
+->MDIO +->PCS
|
+->PHY (etc)
In this scenario, the MDIO bus might not be present for whatever reason
and we have the possibility of an EPROBE_DEFER error. If that happens,
we will end up in a probe loop because the PHY on the MDIO bus
incremented deferred_trigger_count when it probed successfully:
deferred_probe_work_func()
driver_probe_device(MAC)
axienet_probe(MAC)
mdiobus_register(MDIO)
device_add(PHY)
(probe successful)
driver_bound(PHY)
driver_deferred_probe_trigger()
return -EPROBE_DEFER
driver_deferred_probe_add(MAC)
// deferred_trigger_count changed, so...
driver_deferred_probe_trigger()
--Sean
Hi Andrew, On 6/23/25 19:16, Sean Anderson wrote: > On 6/23/25 18:45, Andrew Lunn wrote: >> On Mon, Jun 23, 2025 at 02:48:53PM -0400, Sean Anderson wrote: >>> On 6/23/25 14:27, Andrew Lunn wrote: >>> > On Mon, Jun 23, 2025 at 11:16:08AM -0400, Sean Anderson wrote: >>> >> On 6/21/25 03:33, Andrew Lunn wrote: >>> >> > On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote: >>> >> >> Returning EPROBE_DEFER after probing a bus may result in an infinite >>> >> >> probe loop if the EPROBE_DEFER error is never resolved. >>> >> > >>> >> > That sounds like a core problem. I also thought there was a time >>> >> > limit, how long the system will repeat probes for drivers which defer. >>> >> > >>> >> > This seems like the wrong fix to me. >>> >> >>> >> I agree. My first attempt to fix this did so by ignoring deferred probes >>> >> from child devices, which would prevent "recursive" loops like this one >>> >> [1]. But I was informed that failing with EPROBE_DEFER after creating a >>> >> bus was not allowed at all, hence this patch. >>> > >>> > O.K. So why not change the order so that you know you have all the >>> > needed dependencies before registering the MDIO bus? >>> > >>> > Quoting your previous email: >>> > >>> >> Returning EPROBE_DEFER after probing a bus may result in an infinite >>> >> probe loop if the EPROBE_DEFER error is never resolved. For example, >>> >> if the PCS is located on another MDIO bus and that MDIO bus is >>> >> missing its driver then we will always return EPROBE_DEFER. >>> > >>> > Why not get a reference on the PCS device before registering the MDIO >>> > bus? >>> >>> Because the PCS may be on the MDIO bus. This is probably the most-common >>> case. >> >> So you are saying the PCS is physically there, but the driver is >> missing because of configuration errors? Then it sounds like a kconfig >> issue? >> >> Or are you saying the driver has been built but then removed from >> /lib/modules/ > > The latter. Or maybe someone just forgot to install it (or include it > with their initramfs). Or maybe there was some error with the MDIO bus. > > There are two mutually-exclusive scenarios (that can both occur in the > same system). First, the PCS can be attached to our own MDIO bus: > > MAC > | > +->MDIO > | > +->PCS > +->PHY (etc) > > In this scenario, we have to probe the MDIO bus before we can look up > the PCS, since otherwise the PCS will always be missing when we look for > it. But if we do things in the right order then we can't get > EPROBE_DEFER, and so there's no risk of a probe loop. > > Second, the PCS can be attached to some other MDIO bus: > > MAC MDIO > | | > +->MDIO +->PCS > | > +->PHY (etc) > > In this scenario, the MDIO bus might not be present for whatever reason > and we have the possibility of an EPROBE_DEFER error. If that happens, > we will end up in a probe loop because the PHY on the MDIO bus > incremented deferred_trigger_count when it probed successfully: > > deferred_probe_work_func() > driver_probe_device(MAC) > axienet_probe(MAC) > mdiobus_register(MDIO) > device_add(PHY) > (probe successful) > driver_bound(PHY) > driver_deferred_probe_trigger() > return -EPROBE_DEFER > driver_deferred_probe_add(MAC) > // deferred_trigger_count changed, so... > driver_deferred_probe_trigger() Does the above scenario make sense? As I see it, the only approaches are - Modify the driver core to detect and mitigate this sort of scenario (NACKed by Greg). - Split the driver into MAC and MDIO parts (this patch). - Modify phylink to allow connecting a PCS after phylink_create but before phylink_start. This is tricky because the PCS can affect the supported phy interfaces, and phy interfaces are validated in phylink_create. - Defer phylink_create to ndo_open. This means that all the netdev/ethtool ops that use phylink now need to check ip the netdev is open and fall back to some other implementation. I don't think we can just return -EINVAL or whatever because using ethtool on a down device has historically worked. I am wary of breaking userspace because some tool assumes it can get_ksettings while the netdev is down. Do you see any other options? IMO, aside from the first option, the second one has the best UX. With the latter two, you could have a netdev that never comes up and the user may not have very good insight as to why. E.g. it may not be obvious that the user should try to bring the netdev up again after the PCS is probed. By waiting to create the netdev until after we successfully probe the PCS we show up in devices_deferred and the netdev can be brought up as usual. --Sean
Hi Sean,
kernel test robot noticed the following build errors:
[auto build test ERROR on net/main]
url: https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/auxiliary-Allow-empty-id/20250620-040839
base: net/main
patch link: https://lore.kernel.org/r/20250619200537.260017-5-sean.anderson%40linux.dev
patch subject: [PATCH net 4/4] net: axienet: Split into MAC and MDIO drivers
config: s390-allmodconfig (https://download.01.org/0day-ci/archive/20250620/202506202126.EmqQsj0w-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250620/202506202126.EmqQsj0w-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202506202126.EmqQsj0w-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of '__inittest'
3225 | module_platform_driver(axienet_driver);
| ^
include/linux/platform_device.h:292:2: note: expanded from macro 'module_platform_driver'
292 | module_driver(__platform_driver, platform_driver_register, \
| ^
include/linux/device/driver.h:261:3: note: expanded from macro 'module_driver'
261 | } \
| ^
include/linux/module.h:131:42: note: expanded from macro '\
module_init'
131 | static inline initcall_t __maybe_unused __inittest(void) \
| ^
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2900:1: note: previous definition is here
2900 | module_auxiliary_driver(xilinx_axienet_mac)
| ^
include/linux/auxiliary_bus.h:289:2: note: expanded from macro 'module_auxiliary_driver'
289 | module_driver(__auxiliary_driver, auxiliary_driver_register, auxiliary_driver_unregister)
| ^
include/linux/device/driver.h:261:3: note: expanded from macro 'module_driver'
261 | } \
| ^
include/linux/module.h:131:42: note: expanded from macro '\
module_init'
131 | static inline initcall_t __maybe_unused __inittest(void) \
| ^
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of 'init_module'
3225 | module_platform_driver(axienet_driver);
| ^
include/linux/platform_device.h:292:2: note: expanded from macro 'module_platform_driver'
292 | module_driver(__platform_driver, platform_driver_register, \
| ^
include/linux/device/driver.h:261:3: note: expanded from macro 'module_driver'
261 | } \
| ^
include/linux/module.h:133:6: note: expanded from macro '\
module_init'
133 | int init_module(void) __copy(initfn) \
| ^
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2900:1: note: previous definition is here
2900 | module_auxiliary_driver(xilinx_axienet_mac)
| ^
include/linux/auxiliary_bus.h:289:2: note: expanded from macro 'module_auxiliary_driver'
289 | module_driver(__auxiliary_driver, auxiliary_driver_register, auxiliary_driver_unregister)
| ^
include/linux/device/driver.h:261:3: note: expanded from macro 'module_driver'
261 | } \
| ^
include/linux/module.h:133:6: note: expanded from macro '\
module_init'
133 | int init_module(void) __copy(initfn) \
| ^
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of '__exittest'
3225 | module_platform_driver(axienet_driver);
| ^
include/linux/platform_device.h:292:2: note: expanded from macro 'module_platform_driver'
292 | module_driver(__platform_driver, platform_driver_register, \
| ^
include/linux/device/driver.h:266:3: note: expanded from macro 'module_driver'
266 | } \
| ^
include/linux/module.h:139:42: note: expanded from macro '\
module_exit'
139 | static inline exitcall_t __maybe_unused __exittest(void) \
| ^
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2900:1: note: previous definition is here
2900 | module_auxiliary_driver(xilinx_axienet_mac)
| ^
include/linux/auxiliary_bus.h:289:2: note: expanded from macro 'module_auxiliary_driver'
289 | module_driver(__auxiliary_driver, auxiliary_driver_register, auxiliary_driver_unregister)
| ^
include/linux/device/driver.h:266:3: note: expanded from macro 'module_driver'
266 | } \
| ^
include/linux/module.h:139:42: note: expanded from macro '\
module_exit'
139 | static inline exitcall_t __maybe_unused __exittest(void) \
| ^
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of 'cleanup_module'
3225 | module_platform_driver(axienet_driver);
| ^
include/linux/platform_device.h:292:2: note: expanded from macro 'module_platform_driver'
292 | module_driver(__platform_driver, platform_driver_register, \
| ^
include/linux/device/driver.h:266:3: note: expanded from macro 'module_driver'
266 | } \
| ^
include/linux/module.h:141:7: note: expanded from macro '\
module_exit'
141 | void cleanup_module(void) __copy(exitfn) \
| ^
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2900:1: note: previous definition is here
2900 | module_auxiliary_driver(xilinx_axienet_mac)
| ^
include/linux/auxiliary_bus.h:289:2: note: expanded from macro 'module_auxiliary_driver'
289 | module_driver(__auxiliary_driver, auxiliary_driver_register, auxiliary_driver_unregister)
| ^
include/linux/device/driver.h:266:3: note: expanded from macro 'module_driver'
266 | } \
| ^
include/linux/module.h:141:7: note: expanded from macro '\
module_exit'
141 | void cleanup_module(void) __copy(exitfn) \
| ^
4 errors generated.
vim +/__inittest +3225 drivers/net/ethernet/xilinx/xilinx_axienet_main.c
8a3b7a252dca9f Daniel Borkmann 2012-01-19 3224
2be586205ca2b8 Srikanth Thokala 2015-05-05 @3225 module_platform_driver(axienet_driver);
8a3b7a252dca9f Daniel Borkmann 2012-01-19 3226
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Thu, 19 Jun 2025 16:05:37 -0400 Sean Anderson wrote: > Returning EPROBE_DEFER after probing a bus may result in an infinite > probe loop if the EPROBE_DEFER error is never resolved. For example, if > the PCS is located on another MDIO bus and that MDIO bus is missing its > driver then we will always return EPROBE_DEFER. But if there are any > devices on our own MDIO bus (such as PHYs), those devices will be > successfully bound before we fail our own probe. This will cause the > deferred probing infrastructure to continuously try to probe our device. > > To prevent this, split the MAC and MDIO functionality into separate > auxiliary devices. These can then be re-probed independently. There's a, pardon the expression, C++-like build failure here culminating in: drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of '__exittest' drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of '__inittest' drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of 'init_module' drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of 'cleanup_module' I'm guessing the existing module_platform_driver() and the new module_auxiliary_driver() don't want to be friends when this code is built as a module? -- pw-bot: cr
On 6/19/25 19:10, Jakub Kicinski wrote: > On Thu, 19 Jun 2025 16:05:37 -0400 Sean Anderson wrote: >> Returning EPROBE_DEFER after probing a bus may result in an infinite >> probe loop if the EPROBE_DEFER error is never resolved. For example, if >> the PCS is located on another MDIO bus and that MDIO bus is missing its >> driver then we will always return EPROBE_DEFER. But if there are any >> devices on our own MDIO bus (such as PHYs), those devices will be >> successfully bound before we fail our own probe. This will cause the >> deferred probing infrastructure to continuously try to probe our device. >> >> To prevent this, split the MAC and MDIO functionality into separate >> auxiliary devices. These can then be re-probed independently. > > There's a, pardon the expression, C++-like build failure here > culminating in: > > drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of '__exittest' > drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of '__inittest' > drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of 'init_module' > drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3225:1: error: redefinition of 'cleanup_module' > > I'm guessing the existing module_platform_driver() and the new > module_auxiliary_driver() don't want to be friends when this > code is built as a module? Hm, I thought I had built this as a module. I guess not. Will fix. --Sean
© 2016 - 2025 Red Hat, Inc.