From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751654AbbJTLtN (ORCPT ); Tue, 20 Oct 2015 07:49:13 -0400 Received: from mx-rz-3.rrze.uni-erlangen.de ([131.188.11.22]:53123 "EHLO mx-rz-3.rrze.uni-erlangen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912AbbJTLtJ (ORCPT ); Tue, 20 Oct 2015 07:49:09 -0400 X-RRZE-Submit-IP: 2001:638:a000:4142::ff0f:d304 To: Jarkko Sakkinen From: Andreas Ziegler Subject: Re: tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0 X-Enigmail-Draft-Status: N1110 Cc: Peter Huewe , Marcel Selhorst , Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, "linux-kernel@vger.kernel.org" , Valentin Rothberg , Paul Bolle Message-ID: <56262A2E.6040602@fau.de> Date: Tue, 20 Oct 2015 13:49:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 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 Hi Jarkko, your patch "tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0" showed up as commit 399235dc6e95 in linux-next today (that is, next-20151020). I noticed it because we (a research group from Erlangen[0]) are running daily checks on linux-next. Your commit creates the following structure of #ifdef blocks in drivers/char/tpm/tpm_tis.c following line 1088: #ifdef CONFIG_ACPI ... #ifdef CONFIG_PNP ... #endif ... #endif Looking at the definition of CONFIG_ACPI at drivers/acpi/Kconfig, line 5, we see that ACPI unconditionally selects PNP, meaning that CONFIG_PNP is always enabled if CONFIG_ACPI has been enabled. Thus, the inner #ifdef statement can never evaluate to 'false' if the outer #ifdef evaluates to true (i.e., CONFIG_ACPI is enabled), and hence, the #ifdef is unnecessary. The same situation holds for the nested structure following line 1124, where the #ifdef CONFIG_PNP at line 1129 is unnecessary. Is this correct or did we miss something? Regards, Andreas [0] https://cados.cs.fau.de