From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Subject: Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller Date: Fri, 5 Jun 2020 13:48:27 +0300 Message-ID: References: <20200604211039.12689-1-michael@walle.cc> <20200604211039.12689-3-michael@walle.cc> <8ed988b3e0bc48ea9219d0847c1b1b8e@walle.cc> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <8ed988b3e0bc48ea9219d0847c1b1b8e@walle.cc> Sender: linux-hwmon-owner@vger.kernel.org To: Michael Walle Cc: "open list:GPIO SUBSYSTEM" , devicetree , Linux Kernel Mailing List , linux-hwmon@vger.kernel.org, linux-pwm@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-arm Mailing List , Linus Walleij , Bartosz Golaszewski , Rob Herring , Jean Delvare , Guenter Roeck , Lee Jones , Thierry Reding , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thom List-Id: linux-pwm@vger.kernel.org On Fri, Jun 5, 2020 at 1:09 PM Michael Walle wrote: > Am 2020-06-05 10:01, schrieb Andy Shevchenko: > > On Fri, Jun 5, 2020 at 12:16 AM Michael Walle wrote: ... > >> + bool "Kontron sl28 core driver" > >> + depends on I2C=y > > > > Why not module? > > There are users of the interupt lines provided by the interrupt > controller. > For example, the gpio-button driver. If this is compiled into the kernel > (which it is by default in the arm64 defconfig), probing will fail > because > the interrupt is not found. Is there a better way for that? I guess the > same > is true for the GPIO driver. And GPIO nicely handles this via deferred probe mechanism. Why it can't be used here? So, we really need to have a strong argument to limit module nowadays to be only builtin. ... > >> + depends on OF > > > > I didn't find an evidence this is needed. > >> +#include > > > > No evidence of user of this. > > I think you meant mod_devicetable.h. > > devm_of_platform_populate(), so I need CONFIG_OF, too right? Ah, this explains header, thanks! But it doesn't explain depends OF. So, perhaps, depends OF || COMPILE_TEST will be more informative, i.e. tells "okay, this driver can be compiled w/o OF, but won't be functional". -- With Best Regards, Andy Shevchenko