linux-kernel - Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Apr 2017 16:41:29 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        kbuild test robot <fengguang.wu@...el.com>,
        "kbuild-all@...org" <kbuild-all@...org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        tipbuild@...or.com, Ingo Molnar <mingo@...nel.org>
Subject: Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to
 `gpiod_add_lookup_table'

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@...il.com> wrote:
> > On Fri, Apr 7, 2017 at 11:16 AM, Linus Walleij <linus.walleij@...aro
> > .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@...ux.intel.com>
Intel Finland Oy