From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756868AbdDRNnK (ORCPT ); Tue, 18 Apr 2017 09:43:10 -0400 Received: from mga05.intel.com ([192.55.52.43]:56345 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752902AbdDRNnH (ORCPT ); Tue, 18 Apr 2017 09:43:07 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,219,1488873600"; d="scan'208";a="958248693" Message-ID: <1492522889.24567.66.camel@linux.intel.com> Subject: Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table' From: Andy Shevchenko To: Linus Walleij , Andy Shevchenko Cc: Arnd Bergmann , kbuild test robot , "kbuild-all@01.org" , "linux-kernel@vger.kernel.org" , tipbuild@zytor.com, Ingo Molnar Date: Tue, 18 Apr 2017 16:41:29 +0300 In-Reply-To: References: <201704030713.jb1PXu29%fengguang.wu@intel.com> <1491319621.708.128.camel@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-04-07 at 12:36 +0200, Linus Walleij wrote: > On Fri, Apr 7, 2017 at 10:57 AM, Andy Shevchenko > wrote: > > On Fri, Apr 7, 2017 at 11:16 AM, Linus Walleij > .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 Intel Finland Oy