From patchwork Wed Jul 4 22:52:06 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 1157531 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 2E33DDFF0F for ; Wed, 4 Jul 2012 22:56:41 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SmYRQ-0002Vj-1z; Wed, 04 Jul 2012 22:53:00 +0000 Received: from mail-qa0-f42.google.com ([209.85.216.42]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1SmYQh-0002VV-Lz for linux-arm-kernel@lists.infradead.org; Wed, 04 Jul 2012 22:52:17 +0000 Received: by qafi31 with SMTP id i31so3264877qaf.15 for ; Wed, 04 Jul 2012 15:52:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lQfQZ+F0yjt6D9kC4+PjjF0u+YQoWnl9z/oBjJF02d0=; b=JhSZZHZP0o/La9a1iUL4UvMqC0DZdqTi6kPM1nbbqHt3yfZx/Ixc8AlneG+5dxbDSz x562AYCfcuov/4iEE3ZH3leMxCzjFNM0yWu83kljHSJ5E/Q2ykys0HsGQxJj9DI5I2+u ddakyHJCaons9K9PW4HWruvgnWVYm0UNEG0MW7NoaEGL9F0HUQIIG6AMSWb9vDo/DJaK DjQlNhppgajnr+2haJMM7B6N+4dt7Qw6PnpjCClxB1huSbP2eB0YI4Uz5hG0n4dZp2oV F+5lG6PqMH0n/yhGVTUVcKZvEkOSh7OCdKUt1yR5T21pn1o4McLaLDfBqEeKc/kHPGV0 E/NQ== MIME-Version: 1.0 Received: by 10.229.137.11 with SMTP id u11mr12204501qct.53.1341442326138; Wed, 04 Jul 2012 15:52:06 -0700 (PDT) Received: by 10.229.234.81 with HTTP; Wed, 4 Jul 2012 15:52:06 -0700 (PDT) In-Reply-To: References: <20120620212046.GI4402@gmail.com> Date: Thu, 5 Jul 2012 00:52:06 +0200 Message-ID: Subject: Re: [GIT PULL] Integrator common clock From: Linus Walleij To: "Turquette, Mike" X-Gm-Message-State: ALoCoQnYcQ/xKei6i+OgQvWMhzahlb8eH9g2wPkRJfix4JHhIwNKvF1lKDWJHwtpfA6a7kOBIdo+ X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.216.42 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: arm@kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Tue, Jul 3, 2012 at 11:15 PM, Turquette, Mike wrote: > Thanks for the re-ping. I've dropped the old ones and taken in these patches. Thanks! > I made one trivial change which is to drop "depends on COMMON_CLK" > from both of the entries in drivers/clk/versatile/Kconfig. COMMON_CLK > is implied since we source your Kconfig from within a menu item that > depends on COMMON_CLK. > > Let me know if that is alright with you. OK! > One last (maybe stupid) question. I don't see that ARCH_VERSATILE > actually uses COMMON_CLK, but uses a legacy platform-specific clk > framework. Is that intended? Versatile is two things (just to add to the confusion): 1) A machine named arch/arm/mach-versatile 2) A platform named arch/arm/plat-versatile encompassing the mach-integrator, mach-versatile, mach-realview and mach-vexpress This new folder is for the latter, but the only *machine* using it in the versatile family is the Integrator. So far. I will likely convert mach-realview next, since I can test it. I don't have the mach-versatile machine sadly. I think only Catalin and Russell really runs it, except for the QEMU users which are plentiful. > I have a second question on this series. The menu option for > CLK_VERSATILE is exposed for everybody with these series. Is that > necessary? I'd prefer that folks 'select' it from platform Kconfig > instead of having it globally exposed. That's OK, does something like the below make it? This shoves them (well currently only one...) under a submenu that is only be visible to folks like me. Tested on Integrator (visible) and SPEAr (invisible). You'll have to hand-edit it for dropping the deps on COMMON_CLK though... From adb168705793bbe3c2522eff068780bb0d9c833e Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 5 Jul 2012 00:44:44 +0200 Subject: [PATCH] clk: hide Versatile clocks from the populace This folds in and hides the Versatile Kconfig submenu unless CONFIG_CLK_VERSATILE was explicitly selected by the platform(s) in the current kernel. Signed-off-by: Linus Walleij --- drivers/clk/versatile/Kconfig | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig index 169b1bc..8796005 100644 --- a/drivers/clk/versatile/Kconfig +++ b/drivers/clk/versatile/Kconfig @@ -1,8 +1,16 @@ config CLK_VERSATILE - bool "Clocks for the ARM Versatile family" + bool depends on COMMON_CLK +if CLK_VERSATILE + +menu "Clocks for the ARM Versatile family" + config CLK_ICST bool "ICST307 VCO clock driver" depends on COMMON_CLK depends on ICST + +endmenu + +endif