From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759994AbcHEPgp (ORCPT ); Fri, 5 Aug 2016 11:36:45 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:51703 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754029AbcHEPgn (ORCPT ); Fri, 5 Aug 2016 11:36:43 -0400 From: Arnd Bergmann To: Philipp Zabel Cc: Masahiro Yamada , Axel Lin , Linux Kernel Mailing List , Hans de Goede , Maxime Ripard , Lee Jones , linux-arm-kernel Subject: Re: Why do we need reset_control_get_optional() ? Date: Fri, 05 Aug 2016 17:35:54 +0200 Message-ID: <1793038.JVifRUCe28@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1470387358.3141.17.camel@pengutronix.de> References: <3400649.NoVKUzu81R@wuerfel> <1470387358.3141.17.camel@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:k5yDPTsutsmbYTxvmkmjKNlM+YGZiMSCF3JF3JIjgy5ADuKv5ja c6ZSrGm5vuAN5lXIFcYjhnOSz2o+Y9RAvYGmp75xKipLtY4HF7MVNpeAmXanCTxwjNfJwXT Pg+bWCfQjweyvxWziXlg4OyOTwdbDr95uorjGHaO5CAZaXLBZuXgh9CQ8eVtOdt/QqFaRUL S4xsvVCCz5hkIiqSzXSyA== X-UI-Out-Filterresults: notjunk:1;V01:K0:1ANXHqVz1dg=:7ldsucwUE5CR2l7kZdQR4u s1XP6Z8H+2gl+3HkqDz2qPjun6SuYYCJFBOZWvgWumdeWRycGNT+3e6OlkERLXy+U4mNNMDYB 68eZU14hLEDP6/bsdsRHXpvMBvww5BcDzV0T4wpQO36MpYvGpZuH2T12a7kgRUzIggAM6r1Q+ MXnVgzEFvQv98r9UBneQxFjoQ3IkrnyCTWk0xLUDqpWy6b+4nlYtv9+vwti5XDeDQArz7c+Jj r/F+i1Ft92vqtmRkQgL7qar9RJ6fl+yzqo5psMOimPJ8o+u6bpRNe3wOfUeU2lJ7A2iuG7uWN iXoiYXuB2KbmfPU4HaivTMkngjBeV6sqhGs3EIwE80GR0ezLoGtDD3mvdNbxLiOm1x3WzxwYz UHz+coFF/E890p0gRKza9JxYXVDr1BI8XlH2RHG0K8NTA3JgfYFGsSFOYKvU0rGdHuKCv8gL+ uu+NTk0PRsO5ObOTV2ITH23iE0tNNy5VAhU664lFHz9JAXLR5zudhBoLBjR0lTlfP5aKx+0G4 IBMXQ5EdbY2T8/dTIrRDN3CmRUqv+AbGha9C8tLOkj7/SUiIAHNo7owARaULHC35K4268QrdD QWf6uRV1jPjpnRiEC7CJbYwcOVxbZyvat9U+eNuLqLXB2Jok3o9daaFOlY9AwUhumyB0mOZPM Lf//uBmHQbM6Xb066Kr3RHgkVhSNnpL+ydQ3xFxobsk0I9XY+OuYeEvb29bMWiuJIm4Db3nCN Qbl65FMdbt3MQ4cK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, August 5, 2016 10:55:58 AM CEST Philipp Zabel wrote: > Am Samstag, den 30.07.2016, 22:13 +0200 schrieb Arnd Bergmann: > > On Friday, July 29, 2016 3:08:15 PM CEST Philipp Zabel wrote: > > > Hi Masahiro, > > > > > > Am Donnerstag, den 28.07.2016, 19:29 +0900 schrieb Masahiro Yamada: > > > [...] > > > > However, I think the following makes more sense: > > > > > > > > > > > > menuconfig RESET_CONTROLLER > > > > bool "Reset Controller Support" > > > > depends on (ARCH_HAS_RESET_CONTROLLER || COMPILE_TEST) > > > > default y > > > > help > > > > Generic Reset Controller support. > > > > > > That looks sensible to me. You'll only have to enable the reset > > > controller framework if either some enabled architecture has a reset > > > controller (in which case you want the driver for it to be activated by > > > default), or if you want to compile test some of the reset drivers. > > > > This still doesn't let a platform 'select RESET_FOO', unless they > > also select RESET_CONTROLLER and ARCH_HAS_RESET_CONTROLLER. > > > > Why do we need to guard all drivers inside of two symbols? > > Does the platform have to select RESET_FOO at all? Wouldn't it be enough > for RESET_FOO to have "default ARCH_FOO" ? It depends on what you want to achieve. With a user-visible option and "default ARCH_FOO", you can disable the driver manually, and another driver that has "depends on ARCH_FOO" can not rely on this one being present as it currently can. If we do this as config RESET_FOO bool "FOO reset controller" if COMPILE_TEST && !ARCH_FOO default ARCH_FOO then I think we get both: you won't be able to turn it off but also get the build testing. > Currently ARCH_HAS_RESET_CONTROLLER is used to default y the > RESET_CONTROLLER symbol. Maybe we should add another > ARCH_REQUIRE_RESET_CONTROLLER and have that select RESET_CONTROLLER, > similarly to how it is done for GPIOLIB? GPIOLIB just stopped using it, there is now only CONFIG_GPIOLIB that can get selected by platforms that need it. > config ARCH_HAS_RESET_CONTROLLER > bool > help > Selecting this option from the architecture Kconfig enables > the RESET_CONTROLLER framework by default but does not select > it. Use it for architectures that still work without reset > controller support and thus allow the user to disable it. > > config ARCH_REQUIRE_RESET_CONTROLLER > bool > select RESET_CONTROLLER > help > Selecting this option from the architecture Kconfig selects > the RESET_CONTROLLER framework. Use it for architectures that > should not be built without the reset controller framework > enabled. > > menuconfig RESET_CONTROLLER > bool "Reset Controller Support" > default ARCH_HAS_RESET_CONTROLLER || COMPILE_TEST > help > Generic Reset Controller support. > > This framework is designed to abstract reset handling of devices > via GPIOs or SoC-internal reset controller modules. > > If unsure, say no. > > The platforms could then select one of the ARCH_*_RESET_CONTROLLER > symbols and nobody would have to select RESET_CONTROLLER directly, for > example: > > menuconfig ARCH_TEGRA > bool "NVIDIA Tegra" > depends on ARCH_MULTI_V7 > select ARCH_REQUIRE_GPIOLIB > select ARCH_REQUIRE_RESET_CONTROLLER > select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS I never really like the way it was done for gpiolib. I think the easiest way would be to have a menu for the reset controllers that does not have any dependencies whatsoever, and make the individual reset drivers select CONFIG_RESET_CONTROLLER, which then becomes a hidden symbol that enables the core code. Arnd