From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751329AbdGZNuc (ORCPT ); Wed, 26 Jul 2017 09:50:32 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:32860 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750867AbdGZNua (ORCPT ); Wed, 26 Jul 2017 09:50:30 -0400 Subject: Re: [PATCH] irqchip: create a Kconfig menu for irqchip drivers To: Masahiro Yamada References: <1501041791-10131-1-git-send-email-yamada.masahiro@socionext.com> <3d59b609-aeec-9177-8849-da1fbd386191@arm.com> <7595babf-8cc8-9191-cead-09fe955a42af@arm.com> Cc: Thomas Gleixner , Jason Cooper , Linux Kernel Mailing List From: Marc Zyngier Organization: ARM Ltd Message-ID: <218865f9-ac06-ba47-287e-cff188957736@arm.com> Date: Wed, 26 Jul 2017 14:50:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/07/17 14:14, Masahiro Yamada wrote: > 2017-07-26 19:37 GMT+09:00 Marc Zyngier : >> On 26/07/17 11:18, Masahiro Yamada wrote: >>> Hi Marc, >>> >>> >>> 2017-07-26 17:04 GMT+09:00 Marc Zyngier : >>>> On 26/07/17 05:03, Masahiro Yamada wrote: >>>>> Some irqchip drivers have a Kconfig prompt. When we run menuconfig >>>>> or friends, those drivers are directly listed in the "Device Drivers" >>>>> menu level. This does not look nice. Create a sub-system level menu. >>>>> >>>>> Signed-off-by: Masahiro Yamada >>>>> --- >>>>> >>>>> drivers/irqchip/Kconfig | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig >>>>> index f1fd5f44d1d4..7b66313a2952 100644 >>>>> --- a/drivers/irqchip/Kconfig >>>>> +++ b/drivers/irqchip/Kconfig >>>>> @@ -1,3 +1,5 @@ >>>>> +menu "IRQ chip support" >>>>> + >>>>> config IRQCHIP >>>>> def_bool y >>>>> depends on OF_IRQ >>>>> @@ -306,3 +308,5 @@ config QCOM_IRQ_COMBINER >>>>> help >>>>> Say yes here to add support for the IRQ combiner devices embedded >>>>> in Qualcomm Technologies chips. >>>>> + >>>>> +endmenu >>>>> >>>> >>>> I'm very reluctant to introduce this. IMHO, interrupt controllers are >>>> way too low level a thing to let them be selected by the user. They >>>> really should be selected by the platform that needs them >>> >>> This is true for the root irqchip. >>> Not necessarily true for child irqchips. >> >> I dispute that argument. We've been able to make this work so far >> *without* exposing yet another menu maze to the user. What has changed? > > > The irqchip maintainers applied drivers > with user-configurable Kconfig entries. They are *not* user-selectable, since there is *NO* menu entry. *You* are making them user-selectable, and I'm objecting to that. >>> >>> >>>> Do you have any example in mind where having a user-selectable interrupt >>>> controller actually makes sense on its own? >>> >>> Yes. >>> >>> I see some user-selectable drivers in drivers/irqchip/Kconfig >>> and I'd like to add one more for my SoCs. >>> >>> >>> This patch: >>> https://github.com/uniphier/linux/commit/f39efdf0ce34f77ae9e324d9ec6c7f486f43a0ed >>> >>> This is really optional, so >>> I intentionally implemented it as a platform driver >>> instead of IRQCHIP_DECLARE(). >> >> I really cannot see how this could be optional. It means that you could >> end-up in a situation where the drivers for the devices being this >> irqchip could have been compiled in, but not their interrupt controller. >> How useful is that? > > In my case, the assumed irq consumer is GPIO. > > If the irq consumer is probed before the irqchip, > it will be tried later by -EPROBE_DEFER. > If the irqchip is not compiled at all, right, the irq consumer will not work. > One possible (and general) solution is to specify "depends on" correctly > between the provider and the consumer. Exactly. It has to be selected either by the platform Kconfig, or whatever is wired onto this irqchip. >>> Looks like irq-ts4800.c, irq-keystone.c are modules as well. >> >> They are directly selected by their respective defconfig. > > > Are you sure? > > As far as I see, they are not selected by anyone. > > > $ git grep 'TS4800_IRQ\|KEYSTONE_IRQ' > arch/arm/configs/keystone_defconfig:CONFIG_KEYSTONE_IRQ=y > arch/arm/configs/multi_v7_defconfig:CONFIG_KEYSTONE_IRQ=y And what is that if not a selection? > drivers/irqchip/Kconfig:config TS4800_IRQ > drivers/irqchip/Kconfig:config KEYSTONE_IRQ > drivers/irqchip/Makefile:obj-$(CONFIG_TS4800_IRQ) += irq-ts4800.o > drivers/irqchip/Makefile:obj-$(CONFIG_KEYSTONE_IRQ) += > irq-keystone.o > > > > defconfig just provides a default value. That's the platform maintainer's problem, not mine. > > Users are allowed to disable the option from menuconfig. No. They are allowed to change what makes sense, and leaving them in control of the irqchips doesn't make any sense *at all*. >> On arm64, >> which is what I expect you driver targets, you should simply select it >> in your platform entry. > > OK, assuming your clain is correct, > we have 5 suspicious entries in drivers/irqchip/Kconfig. > > > config JCORE_AIC > bool "J-Core integrated AIC" if COMPILE_TEST > > config TS4800_IRQ > tristate "TS-4800 IRQ controller" > > config KEYSTONE_IRQ > tristate "Keystone 2 IRQ controller IP" > > config EZNPS_GIC > bool "NPS400 Global Interrupt Manager (GIM)" > > config QCOM_IRQ_COMBINER > bool "QCOM IRQ combiner support" > > > > The prompt strings make the entries visible in menuconfig. > So, they should be removed. Not at all. The help string is extremely useful (use the '/' key i9n menuconfig and search for an entry...), and act as documentation. > The prompts are pointless if the options are supposed by selected by others. See above. > Also, tristate is pointless. > If they are supposed to be selected by platforms, > they have no chance to be a module. > They should be turned into bool (without prompt) > > Is this what you mean? Among other things, yes. M. -- Jazz is not dead. It just smells funny...