From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751788AbbD2Xf0 (ORCPT ); Wed, 29 Apr 2015 19:35:26 -0400 Received: from mga03.intel.com ([134.134.136.65]:54768 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751294AbbD2XfY (ORCPT ); Wed, 29 Apr 2015 19:35:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,673,1422950400"; d="scan'208";a="563970012" Message-ID: <1430350427.5506.9.camel@spandruv-DESK3.jf.intel.com> Subject: Re: [PATCH] x86: punit_atom: punit device state debug driver From: Srinivas Pandruvada To: Paul Bolle Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Kumar P Mahesh Date: Wed, 29 Apr 2015 16:33:47 -0700 In-Reply-To: <1429954999.2927.117.camel@x220> References: <1429911723-31095-1-git-send-email-srinivas.pandruvada@linux.intel.com> <1429954999.2927.117.camel@x220> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2015-04-25 at 11:43 +0200, Paul Bolle wrote: > On Fri, 2015-04-24 at 14:42 -0700, Srinivas Pandruvada wrote: > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > > > +config PUNIT_ATOM > > + bool "ATOM Punit debug driver" > > + def_bool n > > The kconfig tools will do what you mean here. But just > default n > > is neater. And, moreover, even that is probably not needed, as n is the > default anyway. > > > + depends on DEBUG_FS > > + select IOSF_MBI > > + ---help--- > > + This is a debug driver, which gets the power states > > + of all Punit North Complex devices.The power states of > > + each IP is exposed as part of the debugfs interface. > > (This menu will show up in menuconfig's main menu. Shouldn't this be put > in some debug related menu?) The initial intention is to make a debug driver only, but there is possibility that some register setting be allowed from user space for PM decision. So leaving open this possibility to keep out of debug menus. > And these three macros will be effectively preprocessed away for > built-in only code. > > But, on the other hand, changing PUNIT_ATOM to tristate allows it to be > built as a module (I just did that). So perhaps that was your intention? Making tristate makes sense. So I will send an update with this. Thanks, Srinivas > > > Paul Bolle >