From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754664AbcBZP2P (ORCPT ); Fri, 26 Feb 2016 10:28:15 -0500 Received: from mail-cys01nam02on0087.outbound.protection.outlook.com ([104.47.37.87]:3905 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753896AbcBZP2O (ORCPT ); Fri, 26 Feb 2016 10:28:14 -0500 Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=bestguesspass action=none header.from=xilinx.com; Date: Fri, 26 Feb 2016 07:27:14 -0800 From: =?utf-8?B?U8O2cmVu?= Brinkmann To: Grygorii Strashko CC: Moritz Fischer , , , , Masahiro Yamada , Florian Fainelli , Russell King , Daniel Lezcano , Michal Simek , Wei Xu , , , Arnd Bergmann , "Liviu Dudau" , , linux-arm-kernel , Maxime Coquelin , Srinivas Kandagatla , Linux Kernel Mailing List , Sascha Hauer , "Sudeep Holla" , Olof Johansson , Jun Nie , Shawn Guo Subject: Re: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable Message-ID: <20160226152714.GD3173@xsjsorenbubuntu> References: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com> <20160204224128.GG4215@xsjsorenbubuntu> <20160204233950.GH4215@xsjsorenbubuntu> <56D04D17.6030502@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56D04D17.6030502@ti.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-22156.006 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.100;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(438002)(377424004)(479174004)(164054003)(24454002)(377454003)(87936001)(63266004)(85182001)(76506005)(23676002)(50986999)(57986006)(1076002)(85202003)(5001960100002)(54356999)(6806005)(76176999)(189998001)(11100500001)(110136002)(1096002)(1220700001)(33716001)(86362001)(586003)(93886004)(47776003)(4326007)(2906002)(2870700001)(4001350100001)(50466002)(92566002)(83506001)(5008740100001)(19580405001)(77096005)(19580395003)(2950100001)(33656002)(106466001)(107986001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1NAM02HT101;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;MLV:sfv;LANG:en; X-MS-Office365-Filtering-Correlation-Id: 1f7b5289-4486-4754-8e34-08d33ec165bb X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501002);SRVR:SN1NAM02HT101; X-Microsoft-Antispam-PRVS: <75ff1d9144584e0e87db87e071e63ab1@SN1NAM02HT101.eop-nam02.prod.protection.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13017025)(8121501046)(13018025)(13024025)(13015025)(13023025)(5005006)(10201501046)(3002001);SRVR:SN1NAM02HT101;BCL:0;PCL:0;RULEID:;SRVR:SN1NAM02HT101; X-Forefront-PRVS: 0864A36BBF X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2016 15:27:53.7022 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.100];Helo=[xsj-pvapsmtpgw02] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT101 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks, Sören