lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Jan 2021 22:36:12 +0100
From:   Arnd Bergmann <>
To:     Heiner Kallweit <>
Cc:     Andrew Lunn <>, Marek Vasut <>,
        Networking <>,
        Jakub Kicinski <>,
        Lukas Wunner <>
Subject: Re: [PATCH net-next] net: ks8851: Fix mixed module/builtin build

On Fri, Jan 15, 2021 at 6:24 PM Heiner Kallweit <> wrote:
> On 15.01.2021 16:59, Andrew Lunn wrote:
> > On Fri, Jan 15, 2021 at 04:05:57PM +0100, Marek Vasut wrote:
> >> On 1/15/21 4:00 PM, Andrew Lunn wrote:
> >>> On Fri, Jan 15, 2021 at 02:42:39PM +0100, Marek Vasut wrote:
> >>>> When either the SPI or PAR variant is compiled as module AND the other
> >>>> variant is compiled as built-in, the following build error occurs:
> >>>>
> >>>> arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common':
> >>>> ks8851_common.c:(.text+0x1564): undefined reference to `__this_module'
> >>>>
> >>>> Fix this by including the ks8851_common.c in both ks8851_spi.c and
> >>>> ks8851_par.c. The DEBUG macro is defined in ks8851_common.c, so it
> >>>> does not have to be defined again.
> >>>
> >>> DEBUG should not be defined for production code. So i would remove it
> >>> altogether.
> >>>
> >>> There is kconfig'ury you can use to make them both the same. But i'm
> >>> not particularly good with it.
> >>
> >> We had discussion about this module/builtin topic in ks8851 before, so I was
> >> hoping someone might provide a better suggestion.
> >
> > Try Arnd Bergmann. He is good with this sort of thing.
> >
> I'd say make ks8851_common.c a separate module. Then, if one of SPI / PAR
> is built in, ks8851_common needs to be built in too. To do so you'd have
> export all symbols from ks8851_common that you want to use in SPI /PAR.

Yes, that should work, as long the common module does not reference
any symbols from the other two modules (it normally wouldn't), and all
globals in the common one are exported.

You can also link everything into a single module, but then you have
to deal with registering two device_driver structures from a single
init function, which would undo some of cleanup.


Powered by blists - more mailing lists