Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp2065733ybg; Fri, 5 Jun 2020 04:53:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyie62PZnQ92vB9TnX5OLbDjp8GK93N09a/0Da8D+eoAbTfKSVLunOr+W4osWYnmLfdilQN X-Received: by 2002:aa7:df05:: with SMTP id c5mr8623940edy.48.1591358004319; Fri, 05 Jun 2020 04:53:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591358004; cv=none; d=google.com; s=arc-20160816; b=TtXKUADzoYmbYLfK5sbTxGAp5mHReib9iluronhNg1JhihvPCiwmzyY+7I83+c5BI2 Uq7rQoL/2JFbqU27uQYjJxBegQ//VqQdqMqRg/CY4NxUGbq1tE6cu7kGMi7BhNedSxj9 YSGBKG2hvcPYySb821okTZh28NIcH/+l8XJWeRzW7IW48us6XGNzhgd6NVaOBZsk0uFc MdNDNOexgMicYDVrn104B75ZzQeypzyg3XGzs3AXSbfT3T2eiIc5PANSsevxRu+H1zkf u0m2tT3agN/+fHn80IkoE2kBZ29NM5EhR7YjryHizcpc58zdciiqqN5mNN2YFBiR7LdZ CXwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=/ER+pXew699aFz9lRU/UtY269UriM4m1gHDqBzilNF0=; b=PPnpKs9EjAtAlrZFY/pq8jJrMUxlZztOM73U7G4i1LkjnFN+hAC9/2dp13ZnMqjtsF eRl8vdDUso7VcHtaeU5dzDhjc4BA4TCiJthBmxaGFVXHHYQYAcAVFbe/F0uSL4eZpYzI E82EzvWEC3O4002+N/n6p2vB8vZkVb0cJZKcZQ3xIffnHON0x/F31O5Mjgc7wj7T9l6/ XWVX2hDwlOhiTA0mB/eyTZX8w8f78CzFsk4dqWlj5HKDUsmYANGladnqNxgu5nzPvP6T tykiG96JsNXFdjznsfOwA++q6OVUZ9WZKWevogIqI8YcmI/8W/csctX7K37tFfhAgQNO 8QIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=WOTqL1q5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j1si3397560edj.464.2020.06.05.04.53.01; Fri, 05 Jun 2020 04:53:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=WOTqL1q5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726496AbgFELvN (ORCPT + 99 others); Fri, 5 Jun 2020 07:51:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726328AbgFELvL (ORCPT ); Fri, 5 Jun 2020 07:51:11 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E342C08C5C2; Fri, 5 Jun 2020 04:51:11 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 726BF22FEC; Fri, 5 Jun 2020 13:51:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1591357869; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/ER+pXew699aFz9lRU/UtY269UriM4m1gHDqBzilNF0=; b=WOTqL1q5lVzt+KkEj2owI4A1lqxulU6qjVgnX7Fgolv/1VHdSWTe5qwcdYnZRfLQ2I7sHo 1EUptsptx9N4EuPomc09TB5DOJoQNPkRGpLSCB/Ur9LH8PQiLUnhh+iLM7hAcyB7Q9jxZH VBka4JiutxAQHctV0rsFn+jcdze1zKQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Jun 2020 13:51:09 +0200 From: Michael Walle To: Andy Shevchenko 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-K=C3=B6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper , Marc Zyngier , Mark Brown , Greg Kroah-Hartman , Andy Shevchenko Subject: Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller In-Reply-To: References: <20200604211039.12689-1-michael@walle.cc> <20200604211039.12689-3-michael@walle.cc> <8ed988b3e0bc48ea9219d0847c1b1b8e@walle.cc> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: michael@walle.cc Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2020-06-05 12:48, schrieb Andy Shevchenko: > 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. Was that a question for me? TBH thats how other interrupt drivers doing it for now. And it would be the users who need to be fixed, right? Or even the platform code? Because it will complain with [ 2.962990] irq: no irq domain found for interrupt-controller@1c ! [ 2.975762] gpio-keys buttons0: Found button without gpio or irq [ 2.981872] gpio-keys: probe of buttons0 failed with error -22 >> >> + 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". ok -- -michael