[tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/platform
head:   d4d969909bef4c1e103eec0fc2c820773811fb72
commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1] x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
config: x86_64-randconfig-s4-04030434 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>> platform_bt.c:(.init.text+0x13a30): undefined reference to `gpiod_add_lookup_table'

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29266 bytes --]

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Mon, Apr 3, 2017 at 2:23 AM, kbuild test robot
<fengguang.wu@intel.com> wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/platform
> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1] x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
> config: x86_64-randconfig-s4-04030434 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
>         git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
>         # save the attached .config to linux build tree
>         make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>>> platform_bt.c:(.init.text+0x13a30): undefined reference to `gpiod_add_lookup_table'

Thank you for report.
I'm about to check this.

-- 
With Best Regards,
Andy Shevchenko

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Arnd Bergmann]

On Mon, Apr 3, 2017 at 10:13 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Apr 3, 2017 at 2:23 AM, kbuild test robot
> <fengguang.wu@intel.com> wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/platform
>> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
>> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1] x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
>> config: x86_64-randconfig-s4-04030434 (attached as .config)
>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>> reproduce:
>>         git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
>>         # save the attached .config to linux build tree
>>         make ARCH=x86_64
>>
>> All errors (new ones prefixed by >>):
>>
>>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>>>> platform_bt.c:(.init.text+0x13a30): undefined reference to `gpiod_add_lookup_table'

I'd guess it's a missing dependency on GPIOLIB

     Arnd

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Mon, Apr 3, 2017 at 12:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Apr 3, 2017 at 10:13 AM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Mon, Apr 3, 2017 at 2:23 AM, kbuild test robot
>> <fengguang.wu@intel.com> wrote:
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/platform
>>> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
>>> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1] x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
>>> config: x86_64-randconfig-s4-04030434 (attached as .config)
>>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>> reproduce:
>>>         git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
>>>         # save the attached .config to linux build tree
>>>         make ARCH=x86_64
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>>>>> platform_bt.c:(.init.text+0x13a30): undefined reference to `gpiod_add_lookup_table'
>
> I'd guess it's a missing dependency on GPIOLIB

Apparently not this one.

The module is purely built whenever HCIUART_BCM is defined which is a
consumer of GPIO.
And that one does not have a dependency.

Fengguang, this is second semi-false positive report. Can we do
something about such?

-- 
With Best Regards,
Andy Shevchenko

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Mon, Apr 3, 2017 at 12:36 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Apr 3, 2017 at 12:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Apr 3, 2017 at 10:13 AM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Mon, Apr 3, 2017 at 2:23 AM, kbuild test robot
>>> <fengguang.wu@intel.com> wrote:

>>>>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>>>>>> platform_bt.c:(.init.text+0x13a30): undefined reference to `gpiod_add_lookup_table'
>>
>> I'd guess it's a missing dependency on GPIOLIB
>
> Apparently not this one.
>
> The module is purely built whenever HCIUART_BCM is defined which is a
> consumer of GPIO.

> And that one does not have a dependency.

...and they should not. So, there are two ways of fix this:
- add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
- add ifdeffery around this code here (with obvious increase of ugliness).

-- 
With Best Regards,
Andy Shevchenko

Re: [kbuild-all] [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Fengguang Wu]

On Mon, Apr 03, 2017 at 12:36:25PM +0300, Andy Shevchenko wrote:
>On Mon, Apr 3, 2017 at 12:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Apr 3, 2017 at 10:13 AM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Mon, Apr 3, 2017 at 2:23 AM, kbuild test robot
>>> <fengguang.wu@intel.com> wrote:
>>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/platform
>>>> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
>>>> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1] x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
>>>> config: x86_64-randconfig-s4-04030434 (attached as .config)
>>>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>>> reproduce:
>>>>         git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
>>>>         # save the attached .config to linux build tree
>>>>         make ARCH=x86_64
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>>>>>> platform_bt.c:(.init.text+0x13a30): undefined reference to `gpiod_add_lookup_table'
>>
>> I'd guess it's a missing dependency on GPIOLIB
>
>Apparently not this one.
>
>The module is purely built whenever HCIUART_BCM is defined which is a
>consumer of GPIO.
>And that one does not have a dependency.
>
>Fengguang, this is second semi-false positive report. Can we do
>something about such?

Andy, I didn't look into the logical side of this problem, however I
can reproduce the issue in commit d4d969909. While its parent commit
succeeded in producing the kernel:

=============== commit d4d969909 ===============
/home/wfg/linux
HEAD is now at d4d9699... x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
/home/wfg/linux/obj-compiletest

make ARCH=x86_64

!!! BUILD ERROR !!!
cat /tmp/build-err-d4d969909bef4c1e103eec0fc2c820773811fb72-wfg
arch/x86/built-in.o: In function `tng_bt_sfi_setup':
platform_bt.c:(.init.text+0x13a3a): undefined reference to `gpiod_add_lookup_table'
make[1]: *** [vmlinux] Error 1
make[1]: Target '_all' not remade because of errors.
make: *** [sub-make] Error 2

=============== PREV commit 2f2a033fb5819c393d65da9b6233e095f3690f15 ===============
/home/wfg/linux
Previous HEAD position was d4d9699... x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
HEAD is now at 2f2a033... x86/platform/uv/BAU: Implement uv4_wait_completion with read_status
/home/wfg/linux/obj-compiletest

make ARCH=x86_64

cat /tmp/build-err-2f2a033fb5819c393d65da9b6233e095f3690f15-wfg

Thanks,
Fengguang

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Mon, 2017-04-03 at 12:44 +0300, Andy Shevchenko wrote:
> On Mon, Apr 3, 2017 at 12:36 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, Apr 3, 2017 at 12:31 PM, Arnd Bergmann <arnd@arndb.de>
> > wrote:
> > > On Mon, Apr 3, 2017 at 10:13 AM, Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > > On Mon, Apr 3, 2017 at 2:23 AM, kbuild test robot
> > > > <fengguang.wu@intel.com> wrote:
> > > > >    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
> > > > > > > platform_bt.c:(.init.text+0x13a30): undefined reference to
> > > > > > > `gpiod_add_lookup_table'
> > > 
> > > I'd guess it's a missing dependency on GPIOLIB
> > 

+Cc: Linus.

> > Apparently not this one.
> > 
> > The module is purely built whenever HCIUART_BCM is defined which is
> > a
> > consumer of GPIO.
> > And that one does not have a dependency.
> 
> ...and they should not. So, there are two ways of fix this:
> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
> - add ifdeffery around this code here (with obvious increase of
> ugliness).

Linus, there is a (minor) issue with one of the user of
gpiod_add_lookup_table(), i.e. we have a code which is either built-in
or not compiled at all and it has some external dependency without
having an explicit Kconfig option. The external dependency considers
GPIOLIB as an optional, and thus some configurations might bring
unresolved symbols.

There are at least two solutions:
- add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
- add ifdeffery around this code here (with obvious increase of
ugliness).

What is your opinion on the case?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Linus Walleij]

On Tue, Apr 4, 2017 at 5:27 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Mon, 2017-04-03 at 12:44 +0300, Andy Shevchenko wrote:

>> ...and they should not. So, there are two ways of fix this:
>> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
>> - add ifdeffery around this code here (with obvious increase of
>> ugliness).
>
> Linus, there is a (minor) issue with one of the user of
> gpiod_add_lookup_table(), i.e. we have a code which is either built-in
> or not compiled at all and it has some external dependency without
> having an explicit Kconfig option. The external dependency considers
> GPIOLIB as an optional, and thus some configurations might bring
> unresolved symbols.
>
> There are at least two solutions:
> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
> - add ifdeffery around this code here (with obvious increase of
> ugliness).
>
> What is your opinion on the case?

I've heard similar things about other places where people want
to have "half GPIOLIB" adding a few lookup stubs for just numbing
gpiolib.

If it is just a stub without much code I guess that is prettier, but
still it is a bit weird, because I guess the table that are passed
to gpiod_add_lookup_table() will still be compiled into the object
so you are anyways carrying cruft, and then what is the point in
not just doing select GPIOLIB.

But we might be looking at the wrong thing.

Looking closer at the file I see it is some kind of translation
of SFI (simple firmware interface) information into platform/board
data.

IMO SFI is just another hardware description language, and
SFI-described GPIO should be in drivers/gpio/gpiolib-sfi.c or
something like this akin to ACPI and OF. Why is it contained as
platform hacks?

Also a lot of the code down there and I mean
arch/x86/platform/intel-mid/device_libs/ is starting to look like the
ARM board files before we started to convert to device tree.
It includes using the old GPIO interface with the global number space
rather than descriptors and such quite extensively.

So I'm a bit worried that we are seeing a symptom of board data
stockpiling in arch/x86 and not really a GPIO compilation problem.

Yours,
Linus Walleij

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Fri, Apr 7, 2017 at 11:16 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Apr 4, 2017 at 5:27 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>> On Mon, 2017-04-03 at 12:44 +0300, Andy Shevchenko wrote:
>
>>> ...and they should not. So, there are two ways of fix this:
>>> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
>>> - add ifdeffery around this code here (with obvious increase of
>>> ugliness).
>>
>> Linus, there is a (minor) issue with one of the user of
>> gpiod_add_lookup_table(), i.e. we have a code which is either built-in
>> or not compiled at all and it has some external dependency without
>> having an explicit Kconfig option. The external dependency considers
>> GPIOLIB as an optional, and thus some configurations might bring
>> unresolved symbols.
>>
>> There are at least two solutions:
>> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
>> - add ifdeffery around this code here (with obvious increase of
>> ugliness).
>>
>> What is your opinion on the case?
>
> I've heard similar things about other places where people want
> to have "half GPIOLIB" adding a few lookup stubs for just numbing
> gpiolib.
>
> If it is just a stub without much code I guess that is prettier, but
> still it is a bit weird, because I guess the table that are passed
> to gpiod_add_lookup_table() will still be compiled into the object
> so you are anyways carrying cruft, and then what is the point in
> not just doing select GPIOLIB.

Because it's optional to HCIUART_BCM as far as I know. But I didn't
look closer to possibilities there (IIRC there no *_optional() calls
to GPIOLIB).

>
> But we might be looking at the wrong thing.
>
> Looking closer at the file I see it is some kind of translation
> of SFI (simple firmware interface) information into platform/board
> data.
>
> IMO SFI is just another hardware description language, and
> SFI-described GPIO should be in drivers/gpio/gpiolib-sfi.c or
> something like this akin to ACPI and OF. Why is it contained as
> platform hacks?

We have already discussed this a lot when I proposed to create
something like gpiolib-sfi.c. We have only legacy stuff with SFI amd
SFI perse is 99% useless. To not uglify drivers we in any case have to
hardcode mappings between weird SFI names to what drivers are
expecting.
So, it does not worth doing it.

> Also a lot of the code down there and I mean
> arch/x86/platform/intel-mid/device_libs/ is starting to look like the
> ARM board files before we started to convert to device tree.
> It includes using the old GPIO interface with the global number space
> rather than descriptors and such quite extensively.
>
> So I'm a bit worried that we are seeing a symptom of board data
> stockpiling in arch/x86 and not really a GPIO compilation problem.

Don't be. I'm trying to avoid this and my plan is actually to modify
bootloader on that board to provide ACPI tables instead. This will
hide all crappy stuff in bootloader, though we better to support
legacy (stock) bootloader as well and thus platform data.

-- 
With Best Regards,
Andy Shevchenko

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Linus Walleij]

On Fri, Apr 7, 2017 at 10:57 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Apr 7, 2017 at 11:16 AM, Linus Walleij <linus.walleij@linaro.org> wrote:

>> If it is just a stub without much code I guess that is prettier, but
>> still it is a bit weird, because I guess the table that are passed
>> to gpiod_add_lookup_table() will still be compiled into the object
>> so you are anyways carrying cruft, and then what is the point in
>> not just doing select GPIOLIB.
>
> Because it's optional to HCIUART_BCM as far as I know. But I didn't
> look closer to possibilities there (IIRC there no *_optional() calls
> to GPIOLIB).

Do you mean for adding tables?
We have:
devm_gpiod_get_optional() & friends.

They return NULL if the GPIO is not there, or if the
GPIO library is compiled out (as of HEAD, due to the
patch from Dmitry T.)

>> IMO SFI is just another hardware description language, and
>> SFI-described GPIO should be in drivers/gpio/gpiolib-sfi.c or
>> something like this akin to ACPI and OF. Why is it contained as
>> platform hacks?
>
> We have already discussed this a lot when I proposed to create
> something like gpiolib-sfi.c. We have only legacy stuff with SFI amd
> SFI perse is 99% useless. To not uglify drivers we in any case have to
> hardcode mappings between weird SFI names to what drivers are
> expecting.
> So, it does not worth doing it.

Aha OK. Yeah you know this way better than me so I trust
you on this.


>> So I'm a bit worried that we are seeing a symptom of board data
>> stockpiling in arch/x86 and not really a GPIO compilation problem.
>
> Don't be. I'm trying to avoid this and my plan is actually to modify
> bootloader on that board to provide ACPI tables instead. This will
> hide all crappy stuff in bootloader, though we better to support
> legacy (stock) bootloader as well and thus platform data.

OK sounds reasonable. Kind of like the attached device tree we
do on ARM.

Yours,
Linus Walleij

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Fri, 2017-04-07 at 12:36 +0200, Linus Walleij wrote:
> On Fri, Apr 7, 2017 at 10:57 AM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Fri, Apr 7, 2017 at 11:16 AM, Linus Walleij <linus.walleij@linaro
> > .org> wrote:
> > > If it is just a stub without much code I guess that is prettier,
> > > but
> > > still it is a bit weird, because I guess the table that are passed
> > > to gpiod_add_lookup_table() will still be compiled into the object
> > > so you are anyways carrying cruft, and then what is the point in
> > > not just doing select GPIOLIB.
> > 
> > Because it's optional to HCIUART_BCM as far as I know. But I didn't
> > look closer to possibilities there (IIRC there no *_optional() calls
> > to GPIOLIB).
> 
> Do you mean for adding tables?
> We have:
> devm_gpiod_get_optional() & friends.

> They return NULL if the GPIO is not there, or if the
> GPIO library is compiled out (as of HEAD, due to the
> patch from Dmitry T.)

I'm talking if they are used or not in hci_bcm.c.

Just checked and indeed the driver is using _optional() variants.
This means GPIOLIB is optional to the driver.

> > > So I'm a bit worried that we are seeing a symptom of board data
> > > stockpiling in arch/x86 and not really a GPIO compilation problem.
> > 
> > Don't be. I'm trying to avoid this and my plan is actually to modify
> > boot loader on that board to provide ACPI tables instead. This will
> > hide all crappy stuff in bootloader, though we better to support
> > legacy (stock) bootloader as well and thus platform data.
> 
> OK sounds reasonable. Kind of like the attached device tree we
> do on ARM.

It will time. Meanwhile, what is the best approach to avoid build break?

Taking into consideration above (hci_bcm.c driver uses _optional()
variants) and no separate Kconfig option for platform code, I would go
with a stub for gpiod_add_lookup_table() when !GPIOLIB.

Another option is to make this stub inside that driver. Btw, as far as I
can see this is the only user which has no explicit dependency to
GPIOLIB.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Linus Walleij]

On Tue, Apr 18, 2017 at 3:41 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, 2017-04-07 at 12:36 +0200, Linus Walleij wrote:

>> They return NULL if the GPIO is not there, or if the
>> GPIO library is compiled out (as of HEAD, due to the
>> patch from Dmitry T.)
>
> I'm talking if they are used or not in hci_bcm.c.
>
> Just checked and indeed the driver is using _optional() variants.
> This means GPIOLIB is optional to the driver.

GPIOLIB's idea of "optional" should preferrably be the same as
an optional regulator, i.e. "electrically optional" not "software optional".

The regulator example is for example an ADC reference voltage that is
not strictly required, then it is optional, and the ADC can use some
internal reference voltage instead. It does not mean that the regulator
framework is optional.

I'd like to have the same semantice for GPIO but maybe that is a
pipe dream :/

Yours,
Linus Walleij

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Wed, 2017-04-19 at 11:01 +0200, Linus Walleij wrote:
> On Tue, Apr 18, 2017 at 3:41 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, 2017-04-07 at 12:36 +0200, Linus Walleij wrote:
> > > They return NULL if the GPIO is not there, or if the
> > > GPIO library is compiled out (as of HEAD, due to the
> > > patch from Dmitry T.)
> > 
> > I'm talking if they are used or not in hci_bcm.c.
> > 
> > Just checked and indeed the driver is using _optional() variants.
> > This means GPIOLIB is optional to the driver.
> 
> GPIOLIB's idea of "optional" should preferrably be the same as
> an optional regulator, i.e. "electrically optional" not "software
> optional".
> 
> The regulator example is for example an ADC reference voltage that is
> not strictly required, then it is optional, and the ADC can use some
> internal reference voltage instead. It does not mean that the
> regulator
> framework is optional.

Yeah, my point is that hci_bcm.c by design can work without GPIOs (looks
like it might be hardware without dedicated GPIO lines, though I'm quite
 in doubts there is one exists) which makes GPIOLIB requirement
optional.  Thus, platform code in question (this patch) should cope with
absence of gpiod_add_lookup_table().

The question is what by your opinion is the best approach here (I put
them in order of my preferences):
1) make a stub for gpiod_add_lookup_table() for !GPIOLIB case for all
users;
2) as in 1) but inside this very user;
3) uglify Makefile with something like ifeq $(CONFIG_GPIOLIB,y);
4) create a Kconfig option for this very user (the worst variant I could
even think about).

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Andy Shevchenko]

On Mon, 2017-04-03 at 07:23 +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86/platform
> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1]
> x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
> config: x86_64-randconfig-s4-04030434 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
>         git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
>         # save the attached .config to linux build tree
>         make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
> > > platform_bt.c:(.init.text+0x13a30): undefined reference to
> > > `gpiod_add_lookup_table'
> 
> 

This is going to be fixed by
https://lkml.org/lkml/2017/5/11/774
when Linus applies the patch.

> ---
> 0-DAY kernel test infrastructure                Open Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all                   Intel
> Corporation

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

[Linus Walleij]

On Mon, May 22, 2017 at 8:41 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Mon, 2017-04-03 at 07:23 +0800, kbuild test robot wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>> x86/platform
>> head:   d4d969909bef4c1e103eec0fc2c820773811fb72
>> commit: d4d969909bef4c1e103eec0fc2c820773811fb72 [1/1]
>> x86/platform/intel-mid: Enable Bluetooth support on Intel Edison
>> config: x86_64-randconfig-s4-04030434 (attached as .config)
>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>> reproduce:
>>         git checkout d4d969909bef4c1e103eec0fc2c820773811fb72
>>         # save the attached .config to linux build tree
>>         make ARCH=x86_64
>>
>> All errors (new ones prefixed by >>):
>>
>>    arch/x86/built-in.o: In function `tng_bt_sfi_setup':
>> > > platform_bt.c:(.init.text+0x13a30): undefined reference to
>> > > `gpiod_add_lookup_table'
>>
>>
>
> This is going to be fixed by
> https://lkml.org/lkml/2017/5/11/774
> when Linus applies the patch.

I've sent a pull request to Torvalds for this patch today.

Yours,
Linus Walleij