From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932816AbcCHK5v (ORCPT ); Tue, 8 Mar 2016 05:57:51 -0500 Received: from bear.ext.ti.com ([192.94.94.41]:60260 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932075AbcCHK5m (ORCPT ); Tue, 8 Mar 2016 05:57:42 -0500 Subject: Re: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable To: =?UTF-8?Q?S=c3=b6ren_Brinkmann?= , Daniel Lezcano , Olof Johansson References: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com> <20160204224128.GG4215@xsjsorenbubuntu> <20160204233950.GH4215@xsjsorenbubuntu> <56D04D17.6030502@ti.com> <20160226152714.GD3173@xsjsorenbubuntu> CC: Moritz Fischer , , , , Masahiro Yamada , Florian Fainelli , Russell King , Michal Simek , Wei Xu , , , Arnd Bergmann , Liviu Dudau , , linux-arm-kernel , Maxime Coquelin , Srinivas Kandagatla , Linux Kernel Mailing List , Sascha Hauer , Sudeep Holla , Jun Nie , Shawn Guo From: Grygorii Strashko Message-ID: <56DEAFB7.50105@ti.com> Date: Tue, 8 Mar 2016 17:55:51 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160226152714.GD3173@xsjsorenbubuntu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/26/2016 10:27 PM, Sören Brinkmann wrote: > On Fri, 2016-02-26 at 15:03:19 +0200, Grygorii Strashko wrote: >> On 02/05/2016 01:39 AM, Sören Brinkmann wrote: >>> On Thu, 2016-02-04 at 15:14:47 -0800, Moritz Fischer wrote: >>>> Hi Soeren, >>>> >>>> On Thu, Feb 4, 2016 at 2:41 PM, Sören Brinkmann >>>> wrote: >>>> >>>>> But with this change the 'if !CPU_FREQ' becomes obsolete. >>>> I'm confused, could you explain that statement? You don't want people >>>> accidentally running with GT when CPU_FREQ is on, right? >>> >>> Correct. But with this Kconfig rework you can just deselect it in >>> Kconfig. The generic HAVE_GT could always be selected. >>> >> >> >> Don't know whom should i ask - but what will be the final conclusion here? >> Can it be merged? > > I think we don't break anything either way. Would just be some > additional clean up to get rid of that mentioned constraint (which > doesn't really work well anyway in the multi-arch kernel). So, no real > objections to merging it from my side. > Yeah. Thanks I'll re-send it after 4.6-rc. But What I'm not fully understand is how to get it merged taking into account that it touches few maches & clocksource :( -- regards, -grygorii