Message ID | 1416161106-27498-1-git-send-email-gilles.chanteperdrix@xenomai.org |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> Date: Sun, 16 Nov 2014 19:05:06 +0100 > The at91_ether driver depends on symbols defined in the macb driver. > > Currently, when compiling both at91_ether and macb as module, starting > the at91_ether module fails, because the macb module can not be loaded > with a macb interface. > > Avoid this issue by getting the macb module initialization routine to > always return 0, even when no macb device is detected. > > Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> This is not acceptable, sorry. This means the module stays in memory even if nobody has a real use for it. You'll need to find another solution, and I'll say in passing that this was very poorly designed and that's why the problem exists. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 16, 2014 at 01:53:02PM -0500, David Miller wrote: > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> > Date: Sun, 16 Nov 2014 19:05:06 +0100 > > > The at91_ether driver depends on symbols defined in the macb driver. > > > > Currently, when compiling both at91_ether and macb as module, starting > > the at91_ether module fails, because the macb module can not be loaded > > with a macb interface. > > > > Avoid this issue by getting the macb module initialization routine to > > always return 0, even when no macb device is detected. > > > > Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> > > This is not acceptable, sorry. > > This means the module stays in memory even if nobody has a real use > for it. > > You'll need to find another solution, and I'll say in passing that this > was very poorly designed and that's why the problem exists. > Ok, I see multiple possible other fixes: - inline the shared functions in the macb.h driver or move them to a library, this effectively means duplication, but who is going to enable both drivers anyway? - when both drivers are compiled as module, make one module containing both drivers say at91+macb.ko - modify the code I posted so that it only keeps the macb driver loaded without macb device if IS_ENABLED(CONFIG_ARM_AT91_ETHER) and probably many others I do not see. I just do not know which one you would find acceptable. Regards.
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 4d9fc05..f70228c 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -2327,7 +2327,20 @@ static struct platform_driver macb_driver = { }, }; -module_platform_driver_probe(macb_driver, macb_probe); +static bool found; +static int __init macb_driver_init(void) +{ + found = platform_driver_probe(&macb_driver, macb_probe) == 0; + return 0; +} +module_init(macb_driver_init); + +static void __exit macb_driver_exit(void) +{ + if (found) + platform_driver_unregister(&macb_driver); +} +module_exit(macb_driver_exit); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
The at91_ether driver depends on symbols defined in the macb driver. Currently, when compiling both at91_ether and macb as module, starting the at91_ether module fails, because the macb module can not be loaded with a macb interface. Avoid this issue by getting the macb module initialization routine to always return 0, even when no macb device is detected. Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> --- drivers/net/ethernet/cadence/macb.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)