[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVHGz=0d_bGOu7RtF7-ssgnNmHk=MwEbTK77=+UgKGmYA@mail.gmail.com>
Date: Sat, 28 Dec 2024 14:55:02 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: kernel test robot <lkp@...el.com>
Cc: Andrew Lunn <andrew@...n.ch>, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org
Subject: Re: ERROR: modpost: "__delay" [drivers/net/mdio/mdio-cavium.ko] undefined!
On Sat, Dec 28, 2024 at 2:50 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> Hi Kernel Test Robot,
>
> On Sat, Dec 28, 2024 at 2:36 PM kernel test robot <lkp@...el.com> wrote:
> > First bad commit (maybe != root cause):
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: fd0584d220fe285dc45be43eede55df89ad6a3d9
> > commit: a9770eac511ad82390b9f4a3c1728e078c387ac7 net: mdio: Move MDIO drivers into a new subdirectory
> > date: 4 years, 4 months ago
> > config: sh-randconfig-001-20241212 (https://download.01.org/0day-ci/archive/20241228/202412282326.0DSE4HbR-lkp@intel.com/config)
> > compiler: sh4-linux-gcc (GCC) 12.4.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241228/202412282326.0DSE4HbR-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@...el.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202412282326.0DSE4HbR-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>, old ones prefixed by <<):
> >
> > >> ERROR: modpost: "__delay" [drivers/net/mdio/mdio-cavium.ko] undefined!
>
> The real issue was introduced in commit 1eefee901fca0208
> ("phy: mdio-octeon: Refactor into two files/modules").
Silly me: commit 2fd46f47be0f96be
("netdev: mdio-octeon.c: Convert to use device tree.").
But even before that, the driver used a different non-portable construct.
> Drivers must not use __delay() directly, as that is non-portable, and
> doesn't work in the presence of cpufreq.
And looking at
https://lore.kernel.org/all/202412282326.0DSE4HbR-lkp@intel.com
all of this has been said before...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists