From patchwork Mon Apr 26 14:12:26 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Egger X-Patchwork-Id: 50966 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail-wy0-f184.google.com (mail-wy0-f184.google.com [74.125.82.184]) by ozlabs.org (Postfix) with ESMTP id 0D85FB7BEE for ; Tue, 27 Apr 2010 00:12:31 +1000 (EST) Received: by wyi11 with SMTP id 11sf2892876wyi.11 for ; Mon, 26 Apr 2010 07:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:received:date:from:to:cc:subject :message-id:mime-version:user-agent :x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type :content-disposition; bh=j1ynnKaeoAE2jip7zSIZxeQ34BwPD8eGMOMNGT9R3TM=; b=EsrmoBhyb+sa6CpaS43O6yMUuwbiGlO+YPXkDq+2GAC+HCntJyeO4d7NWj1AS9Xnwe /0VfOC6jpQrGYI6des+dPIzhb2ANvGXXnuB6z9hH6NcTK4t54J7UAMo9BGDHSaBi4ty+ bCQ5/mc4y7lgHWEABBEXVh+70RA4XfhsJIwmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:date:from:to:cc:subject:message-id :mime-version:user-agent:x-original-authentication-results :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type:content-disposition; b=eBUX3EMwPbEe61H13uKCLr9P1trzwbStt1/8yStU28nzvOar8OUAi0t+7nhQ1QpHJm plduMyTGbF3e0xenv5XD01Gdfz5KORHPfA57+Few0UafqIje90QTDWht/g5p/gkdv9jD 0ZT2FuEGIw6c8Xddo1+A1f1uMWrbV/WqA++5M= Received: by 10.223.15.141 with SMTP id k13mr1170011faa.41.1272291149179; Mon, 26 Apr 2010 07:12:29 -0700 (PDT) X-BeenThere: rtc-linux@googlegroups.com Received: by 10.204.32.206 with SMTP id e14ls14903630bkd.2.p; Mon, 26 Apr 2010 07:12:27 -0700 (PDT) Received: by 10.204.22.69 with SMTP id m5mr202948bkb.19.1272291146685; Mon, 26 Apr 2010 07:12:26 -0700 (PDT) Received: by 10.204.22.69 with SMTP id m5mr202945bkb.19.1272291146621; Mon, 26 Apr 2010 07:12:26 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) by gmr-mx.google.com with ESMTP id 17si534015bwz.3.2010.04.26.07.12.26; Mon, 26 Apr 2010 07:12:26 -0700 (PDT) Received-SPF: neutral (google.com: 131.188.34.40 is neither permitted nor denied by best guess record for domain of siccegge@cs.fau.de) client-ip=131.188.34.40; Received: from faui49h (faui49h.informatik.uni-erlangen.de [131.188.42.58]) by faui40.informatik.uni-erlangen.de (Postfix) with SMTP id F3E425F0E5; Mon, 26 Apr 2010 16:12:24 +0200 (MEST) Received: by faui49h (sSMTP sendmail emulation); Mon, 26 Apr 2010 16:12:26 +0200 Date: Mon, 26 Apr 2010 16:12:26 +0200 From: Christoph Egger To: Alessandro Zummo , Paul Gortmaker , Andrew Morton , maltesch@gmx.de, Ralf Baechle , Herton Ronaldo Krzesinski , rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org Cc: vamos@i4.informatik.uni-erlangen.de Subject: [rtc-linux] [PATCH] Missmatch between source and Kconfig for ACPI && !PM Message-ID: <20100426141226.GC2710@faui49.informatik.uni-erlangen.de> MIME-Version: 1.0 User-Agent: Mutt/1.5.20 (2009-06-14) X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 131.188.34.40 is neither permitted nor denied by best guess record for domain of siccegge@cs.fau.de) smtp.mail=siccegge@cs.fau.de X-Original-Sender: siccegge@cs.fau.de Reply-To: rtc-linux@googlegroups.com Precedence: list Mailing-list: list rtc-linux@googlegroups.com; contact rtc-linux+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: rtc-linux@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Disposition: inline Hi all! As part of the VAMOS[0] research project at the University of Erlangen we are looking at multiple integrity errors in linux' configuration system. There's a check for CONFIG_PM inside a block that is only compiled if CONFIG_ACPI is set. As CONFIG_ACPI depends on CONFIG_PM the check is currently redundant, the Code always active and it's else branch always dead. The attached patch takes the naive solution and only makes it clearer how this source is handled currently. However if the combination ACPI && !PM is usefull the depends in Kconfig might need to be lowered. Please keep me informed of this patch getting confirmed / merged so we can keep track of it. Regards Christoph Egger [0] http://vamos1.informatik.uni-erlangen.de/ ---- From f122e465fc239e4dd8f4d27c72e1066f0a59c6c7 Mon Sep 17 00:00:00 2001 From: Christoph Egger Date: Mon, 26 Apr 2010 16:02:37 +0200 Subject: [PATCH] Remove check for CONFIG_PM which is always present when CONFIG_ACPI As the config option for ACPI directly depends on PM in Kconfig there is currently no way to have ACPI enabled but no PM. Nontheless there's some code handling exactly this case. menuconfig ACPI [...] depends on PM [...] Signed-off-by: Christoph Egger --- drivers/rtc/rtc-cmos.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index e9aa814..0b2ae16 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -970,7 +970,6 @@ static inline int cmos_poweroff(struct device *dev) #include -#ifdef CONFIG_PM static u32 rtc_handler(void *context) { acpi_clear_event(ACPI_EVENT_RTC); @@ -999,11 +998,6 @@ static void rtc_wake_off(struct device *dev) { acpi_disable_event(ACPI_EVENT_RTC, 0); } -#else -#define rtc_wake_setup() do{}while(0) -#define rtc_wake_on NULL -#define rtc_wake_off NULL -#endif /* Every ACPI platform has a mc146818 compatible "cmos rtc". Here we find * its device node and pass extra config data. This helps its driver use