[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <3538e879-8548-4727-b397-c385295316c4@www.fastmail.com>
Date: Mon, 06 Dec 2021 21:38:25 +0100
From: "Sven Peter" <sven@...npeter.dev>
To: "Arnd Bergmann" <arnd@...db.de>
Cc: "kernel test robot" <lkp@...el.com>,
"Linux I2C" <linux-i2c@...r.kernel.org>, kbuild-all@...ts.01.org,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Wolfram Sang" <wsa-dev@...g-engineering.com>,
"Hector Martin" <marcan@...can.st>,
"Alyssa Rosenzweig" <alyssa@...enzweig.io>
Subject: Re: powerpc64-linux-ld: drivers/i2c/busses/i2c-pasemi-core.o:undefined
reference to `__this_module'
On Mon, Dec 6, 2021, at 20:47, Arnd Bergmann wrote:
> On Mon, Dec 6, 2021 at 6:02 PM Sven Peter <sven@...npeter.dev> wrote:
>> On Mon, Dec 6, 2021, at 11:10, kernel test robot wrote:
>
>> > If you fix the issue, kindly add following tag as appropriate
>> > Reported-by: kernel test robot <lkp@...el.com>
>> >
>> > All error/warnings (new ones prefixed by >>):
>> >
>> >>> powerpc64-linux-ld: warning: orphan section `.stubs' from `drivers/i2c/busses/i2c-pasemi-core.o' being placed in section `.stubs'
>> >>> powerpc64-linux-ld: drivers/i2c/busses/i2c-pasemi-core.o:(.toc+0x0): undefined reference to `__this_module'
>>
>> This seems to be triggered by compiling one of {pci,platform} as a module and the
>> other one as built-in. That setup can only happen with COMPILE_TEST since -pci
>> is otherwise only compiled for powerpc and -platform for arm64.
>>
>> -core.c is only built once with THIS_MODULE expanding to __this_module. That will
>> fail when linking the built-in driver where THIS_MODULE should've been NULL instead.
>>
>> The most simple fix (that also has no chance of breaking anything) is probably to
>> just move
>>
>> smbus->adapter.owner = THIS_MODULE;
>>
>> from core to both apple.c and pci.c. I'll prepare a patch later this week.
>
> I'd prefer fixing this in a better way, linking an object file into
> both vmlinux and a loadable
> module is not supported at all.
Make sense, I didn't know that.
> Other options are:
>
> - #include the common .c file from the individual drivers (not great)
> - use Kconfig logic to prevent the broken configuration
> - use Makefile tricks to make both drivers built-in when this happens
> - make the common part a separate loadable module, exporting all the
> global symbols.
>
> Out of these, I would prefer the last option.
Sure, I'll see when I can spare some time to do that since testing that
is going to be a bit more annoying with my current setup.
Fwiw, I2C_OCTEON and I2C_THUNDERX might have the same issue as well
with i2c-octeon-core.o. It just won't result in the same compile error
because i2c-octeon-core.c doesn't use THIS_MODULE.
It's also nothing that is likely to ever happen since those two drivers
are also never used on the same arch and it should only be possible to
create a broken configuration with COMPILE_TEST as well.
Sven
Powered by blists - more mailing lists