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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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