On 1/15/21 10:36 PM, Arnd Bergmann wrote:
On Fri, Jan 15, 2021 at 6:24 PM Heiner Kallweit <hkallwe...@gmail.com> 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.
Maybe just passing THIS_MODULE around is even better way to do it, I
CCed you on the V2, [PATCH net-next V2] net: ks8851: Fix mixed
module/builtin build .
