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@xxxxxxxxxxxxxxx> 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