From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753333AbbKCKDX (ORCPT ); Tue, 3 Nov 2015 05:03:23 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:59627 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752256AbbKCKDR (ORCPT ); Tue, 3 Nov 2015 05:03:17 -0500 From: Arnd Bergmann To: Daniel Lezcano Cc: Krzysztof Kozlowski , tglx@linutronix.de, john.stultz@linaro.org, linux-kernel@vger.kernel.org, Russell King , Kukjin Kim , "moderated list:ARM SUB-ARCHITECT..." , "moderated list:ARM/SAMSUNG EXYNO..." Subject: Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option Date: Tue, 03 Nov 2015 11:02:24 +0100 Message-ID: <9713489.TbNNoNQg5A@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <563872E2.10001@linaro.org> References: <1446469011-22710-1-git-send-email-daniel.lezcano@linaro.org> <563806E7.6010105@samsung.com> <563872E2.10001@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:b29ZKB5O+MKdnSNbmj60YZlbWI4GXb1/BXfC41M1DSkv4vbfsZP ZJyn40YLO94ZxGzMYx/pN0jeLU6asTQe6KlWOWVK2tg1CqtbtAitbKVKRqL8RnMeBRcgOJE ygCeJXc0GFFxuFrCi10b++CI/8APonXJYFYDfvi9ziwIepjGz+Kpdz+xXxarsLVznCVMKt0 66YlaVDRq+t4foVEg2e5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:/cHZcKyJIj0=:ncML9DKv+stTOx6wg8jd2V zwL/0k+UWp2T377iLS/e50xtWTcSFZ5UvPzOTMF+DLFtaMrdwIf2yInusBsRh8ScdHxizTeCW +klZZ4LPZ7sn2/oz+B1Rt/eMY876QfbLDWiH196O5c6zGgUY8NFq3xVAfS2vXmSNTho0c0yok 4yg1d1tY8t5u+Ws6aN2TdKiF+GlOrWRFXuNX7s6NmhwHOdoACGgooCYsZnUMWxRVa1mLxXSGb vVFvi942l3gChv5KpXHyS66ZbaKRpS9FUJRv6HNKyXBtI+ZkBEB5zm/6qp+qhNFeHcLrkPAOL 2eXhxSxhwXJDrkX075Y3VV4CFVlr8b97YFv+ExSuJXe9phgchmL1eaQa0OXISkdKm4ydgg9sU 8w2S2j7M1VDbTJuxhtppI/GF1BaVsUzOvTcOdv1SHImwlW/f0zp+XAlSF0F4SjKN0OsiZ8KId 1R+u0/XpmAVz08YLOj36z8+6hMOJGeZVYIY3QK7uB4fduV9fC4gKsdCYqci+jzJfILqOlHxT9 6B/ZxrKFYyMIeNYp6oQltA69Epe622LdU9GVxQCTJoBp1TY4ae7U2lKT9eVZQ8r0JN/fylnli sbasFe1ey9O1LTsRAAqzAJCCaTF7EI1uTHaasq0naO+1+lKXlpie/tQlK6nxoUNCtW29iCUp+ 385al/YsGjy1nK3dYe1VjZV6wi0wFTAmzXfNnzQu0YIUZK8wOe2kRxLkc2Pcf2o7XnBbn2wNK lMm9z2RZkRnTm87E Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote: > On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote: > > On 03.11.2015 09:30, Krzysztof Kozlowski wrote: > >> On 02.11.2015 21:56, Daniel Lezcano wrote: > >>> Let the platform's Kconfig to select the clock instead of having a reverse > >>> dependency from the driver to the platform options. > >> > >> Selecting user-visible symbols is rather discouraged so why not > >> something like this: > >> > >> - def_bool y if ARCH_EXYNOS > >> - depends on !ARM64 > >> + bool "Exynos multi core timer driver" > >> + depends on ARCH_EXYNOS || (COMPILE_TEST && ARM) > > > > Nope, that was wrong as we loose auto-select on Exynos. Instead: > > - def_bool y if ARCH_EXYNOS > > - depends on !ARM64 > > + bool "Exynos multi core timer driver" if ARM > > + depends on ARCH_EXYNOS || COMPILE_TEST > > + default y if ARCH_EXYNOS > > > > This way we avoid select (which is a reverse dependency for the driver), > > have it auto-selectable and compile tested on arm. > > I think you misunderstood the patch I sent. > > It does two things: > > 1. Follow the thumb of rule of the current Kconfig format > > - The timer driver is selected by the platform (exynos in this case) > - User can't select the driver in the menuconfig > - There is no dependency on the platform except for compilation test > > 2. Add the COMPILE_TEST > > - User can select the driver for compilation testing. This is for > allyesconfig when doing compilation test coverage (exynos timer could be > compiled on other platform). As the delay code is not portable, we have > to restrict the compilation on the ARM platform, this is why there is > the dependency on ARM. > > I am currently looking at splitting the delay code in order to prevent > this restriction on this driver and some others drivers. I suspect this will come up again in the future. The problem is really that drivers/clocksource has different rules from almost everything else, by requiring the platform to 'select' the driver. The second version that Krzysztof posted is how we handle this in other driver subsystems, and I would generally prefer it to do this consistently for everything, but John Stultz has in the past argued strongly for using 'select' in all clocksource drivers. The reason is that for each platform we know in advance which driver we want, and there is never a need for the user to have to select the right one. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option Date: Tue, 03 Nov 2015 11:02:24 +0100 Message-ID: <9713489.TbNNoNQg5A@wuerfel> References: <1446469011-22710-1-git-send-email-daniel.lezcano@linaro.org> <563806E7.6010105@samsung.com> <563872E2.10001@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <563872E2.10001@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Daniel Lezcano Cc: Krzysztof Kozlowski , "moderated list:ARM/SAMSUNG EXYNO..." , Russell King , linux-kernel@vger.kernel.org, Kukjin Kim , john.stultz@linaro.org, tglx@linutronix.de, "moderated list:ARM SUB-ARCHITECT..." List-Id: linux-samsung-soc@vger.kernel.org On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote: > On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote: > > On 03.11.2015 09:30, Krzysztof Kozlowski wrote: > >> On 02.11.2015 21:56, Daniel Lezcano wrote: > >>> Let the platform's Kconfig to select the clock instead of having a reverse > >>> dependency from the driver to the platform options. > >> > >> Selecting user-visible symbols is rather discouraged so why not > >> something like this: > >> > >> - def_bool y if ARCH_EXYNOS > >> - depends on !ARM64 > >> + bool "Exynos multi core timer driver" > >> + depends on ARCH_EXYNOS || (COMPILE_TEST && ARM) > > > > Nope, that was wrong as we loose auto-select on Exynos. Instead: > > - def_bool y if ARCH_EXYNOS > > - depends on !ARM64 > > + bool "Exynos multi core timer driver" if ARM > > + depends on ARCH_EXYNOS || COMPILE_TEST > > + default y if ARCH_EXYNOS > > > > This way we avoid select (which is a reverse dependency for the driver), > > have it auto-selectable and compile tested on arm. > > I think you misunderstood the patch I sent. > > It does two things: > > 1. Follow the thumb of rule of the current Kconfig format > > - The timer driver is selected by the platform (exynos in this case) > - User can't select the driver in the menuconfig > - There is no dependency on the platform except for compilation test > > 2. Add the COMPILE_TEST > > - User can select the driver for compilation testing. This is for > allyesconfig when doing compilation test coverage (exynos timer could be > compiled on other platform). As the delay code is not portable, we have > to restrict the compilation on the ARM platform, this is why there is > the dependency on ARM. > > I am currently looking at splitting the delay code in order to prevent > this restriction on this driver and some others drivers. I suspect this will come up again in the future. The problem is really that drivers/clocksource has different rules from almost everything else, by requiring the platform to 'select' the driver. The second version that Krzysztof posted is how we handle this in other driver subsystems, and I would generally prefer it to do this consistently for everything, but John Stultz has in the past argued strongly for using 'select' in all clocksource drivers. The reason is that for each platform we know in advance which driver we want, and there is never a need for the user to have to select the right one. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 03 Nov 2015 11:02:24 +0100 Subject: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option In-Reply-To: <563872E2.10001@linaro.org> References: <1446469011-22710-1-git-send-email-daniel.lezcano@linaro.org> <563806E7.6010105@samsung.com> <563872E2.10001@linaro.org> Message-ID: <9713489.TbNNoNQg5A@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote: > On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote: > > On 03.11.2015 09:30, Krzysztof Kozlowski wrote: > >> On 02.11.2015 21:56, Daniel Lezcano wrote: > >>> Let the platform's Kconfig to select the clock instead of having a reverse > >>> dependency from the driver to the platform options. > >> > >> Selecting user-visible symbols is rather discouraged so why not > >> something like this: > >> > >> - def_bool y if ARCH_EXYNOS > >> - depends on !ARM64 > >> + bool "Exynos multi core timer driver" > >> + depends on ARCH_EXYNOS || (COMPILE_TEST && ARM) > > > > Nope, that was wrong as we loose auto-select on Exynos. Instead: > > - def_bool y if ARCH_EXYNOS > > - depends on !ARM64 > > + bool "Exynos multi core timer driver" if ARM > > + depends on ARCH_EXYNOS || COMPILE_TEST > > + default y if ARCH_EXYNOS > > > > This way we avoid select (which is a reverse dependency for the driver), > > have it auto-selectable and compile tested on arm. > > I think you misunderstood the patch I sent. > > It does two things: > > 1. Follow the thumb of rule of the current Kconfig format > > - The timer driver is selected by the platform (exynos in this case) > - User can't select the driver in the menuconfig > - There is no dependency on the platform except for compilation test > > 2. Add the COMPILE_TEST > > - User can select the driver for compilation testing. This is for > allyesconfig when doing compilation test coverage (exynos timer could be > compiled on other platform). As the delay code is not portable, we have > to restrict the compilation on the ARM platform, this is why there is > the dependency on ARM. > > I am currently looking at splitting the delay code in order to prevent > this restriction on this driver and some others drivers. I suspect this will come up again in the future. The problem is really that drivers/clocksource has different rules from almost everything else, by requiring the platform to 'select' the driver. The second version that Krzysztof posted is how we handle this in other driver subsystems, and I would generally prefer it to do this consistently for everything, but John Stultz has in the past argued strongly for using 'select' in all clocksource drivers. The reason is that for each platform we know in advance which driver we want, and there is never a need for the user to have to select the right one. Arnd