On 16.01.2021 22:25, Marek Vasut wrote: > On 1/16/21 9:39 PM, Lukas Wunner wrote: >> On Sat, Jan 16, 2021 at 08:26:22PM +0100, Arnd Bergmann wrote: >>> On Sat, Jan 16, 2021 at 6:56 PM Marek Vasut <ma...@denx.de> wrote: >>>> On 1/16/21 6:04 PM, Arnd Bergmann wrote: >>>>> On Sat, Jan 16, 2021 at 5:48 PM Marek Vasut <ma...@denx.de> wrote: >>>> >>>>> 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.
