Re: [PATCH net-next V2] net: ks8851: Fix mixed module/builtin build
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: 2021-01-16 21:42:43
On 16.01.2021 22:25, Marek Vasut wrote:
On 1/16/21 9:39 PM, Lukas Wunner wrote:quoted
On Sat, Jan 16, 2021 at 08:26:22PM +0100, Arnd Bergmann wrote:quoted
On Sat, Jan 16, 2021 at 6:56 PM Marek Vasut [off-list ref] wrote:quoted
On 1/16/21 6:04 PM, Arnd Bergmann wrote:quoted
On Sat, Jan 16, 2021 at 5:48 PM Marek Vasut [off-list ref] wrote:quoted
I don't really like this version, as it does not actually solve the problem of linking the same object file into both vmlinux and a loadable module, which can have all kinds of side-effects besides that link failure you saw. If you want to avoid exporting all those symbols, a simpler hack would be to '#include "ks8851_common.c" from each of the two files, which then always duplicates the contents (even when both are built-in), but at least builds the file the correct way.That's the same as V1, isn't it ?Ah, I had not actually looked at the original submission, but yes, that was slightly better than v2, provided you make all symbols static to avoid the new link error. I still think that having three modules and exporting the symbols from the common part as Heiner Kallweit suggested would be the best way to do it.FWIW I'd prefer V1 (the #include approach) as it allows going back to using static inlines for register access. That's what we had before 7a552c850c45. It seems unlikely that a system uses both, the parallel *and* the SPI variant of the ks8851. So the additional memory necessary because of code duplication wouldn't matter in practice.I have a board with both options populated on my desk, sorry.
Making the common part a separate module shouldn't be that hard. AFAICS it would just take: - export 4 functions from common - extend Kconfig - extend Makefile One similar configuration that comes to my mind and could be used as template is SPI_FSL_LIB.