Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3715042iob; Mon, 2 May 2022 03:59:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygVbYaRI7Ph2ILYzljUfB/4BtHHKd8EecpyFe3gD8mBYP/K/WrO+u1/+EJnN4nYtgfF+d9 X-Received: by 2002:a05:651c:4d1:b0:24f:6374:3e85 with SMTP id e17-20020a05651c04d100b0024f63743e85mr3830470lji.387.1651489173065; Mon, 02 May 2022 03:59:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651489173; cv=none; d=google.com; s=arc-20160816; b=Dzc1AmDolrcqRhIDPtHYfAYNH/znAKhbIzf9lZv/pCPNaogBWD3YxKZqnSvkF9iIAl ZWUuJeiNmjHcQ15YwOTMZXdFtWzk61+/xCnl8ckRdGGvxcSxpENlj2seH7+juQWU2N30 NKLuI4QOwvieZavmp34yd79ucr8J5sBu+1OkFIcZ5h4+wNoqFY6po7PjlGxMhPUJa6CG M3vZZ3e1X1+Yf0Sq2lSdmo0+sUb/EeO/HbQHuDrDgMoIyD5GYAfPLXap038kOfjRSOkp AtLOIGALG8DIibCPn6BGPTDZCbmuz4kuScjEpcwQJbp1KlwcDrjDhV3ljWtzolepR29S sP4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id; bh=rne+9McIt65AOYF7lTGV2hdNpCYqa4i4dc5qeh26OMw=; b=YQHqdDwPChkfUIgrBazOPVoZ9Q9U+rG+xciBb2dcCkrl1FM5L5QCmoeeiHZtrvajMS QOl27Is/wZxeSoLLejX8bsk4JtY6T5lAmK3mVeV3SeUSDLLytNGgSML2ywvZycE11rmL 1RkqEvUdsr6jvmsqzbQfNg+89wj6N5l5uYK15s99mzxuCfOyxOCFk9ITUP50dDhtjzZ0 XbVyBkiBnElm6btTBKg0QnnmcvDmn2reY58nz9robfgjK+iNnwDMN8dy7E67W8O7D9/X PHgrSEDiMXg6ehcm9VrmjG3SM5gUb4KzKGqaE1bCPyGx8y3MZjSZxDYNgiT8I3bGQQ6R cCzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 9-20020a2e0709000000b0024f0e5a0725si13954898ljh.130.2022.05.02.03.59.04; Mon, 02 May 2022 03:59:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377467AbiD2OhR (ORCPT + 99 others); Fri, 29 Apr 2022 10:37:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377465AbiD2OhM (ORCPT ); Fri, 29 Apr 2022 10:37:12 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35BD4AAE2F for ; Fri, 29 Apr 2022 07:33:54 -0700 (PDT) Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=[127.0.0.1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1nkRgt-00042Z-F1; Fri, 29 Apr 2022 16:33:51 +0200 Message-ID: Date: Fri, 29 Apr 2022 16:33:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 From: Ahmad Fatoum Subject: Re: [RFC v2 04/39] char: impi, tpm: depend on HAS_IOPORT To: Niklas Schnelle , Arnd Bergmann Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-pci@vger.kernel.org, Arnd Bergmann , Corey Minyard , Peter Huewe , Jarkko Sakkinen , "moderated list:IPMI SUBSYSTEM" , "open list:TPM DEVICE DRIVER" , Pengutronix Kernel Team References: <20220429135108.2781579-1-schnelle@linux.ibm.com> <20220429135108.2781579-7-schnelle@linux.ibm.com> <07c39877d9e940a96be41e21e22fe45dbb73d949.camel@linux.ibm.com> Content-Language: en-US In-Reply-To: <07c39877d9e940a96be41e21e22fe45dbb73d949.camel@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Niklas, On 29.04.22 16:23, Niklas Schnelle wrote: >> Hello Niklas, >> >> On 29.04.22 15:50, Niklas Schnelle wrote: >>> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends >>> not being declared. We thus need to add this dependency and ifdef >>> sections of code using inb()/outb() as alternative access methods. >>> >>> Co-developed-by: Arnd Bergmann >>> Signed-off-by: Niklas Schnelle >> >> [snip] >> >>> diff --git a/drivers/char/tpm/tpm_infineon.c b/drivers/char/tpm/tpm_infineon.c >>> index 9c924a1440a9..2d2ae37153ba 100644 >>> --- a/drivers/char/tpm/tpm_infineon.c >>> +++ b/drivers/char/tpm/tpm_infineon.c >>> @@ -51,34 +51,40 @@ static struct tpm_inf_dev tpm_dev; >>> >>> static inline void tpm_data_out(unsigned char data, unsigned char offset) >>> { >>> +#ifdef CONFIG_HAS_IOPORT >>> if (tpm_dev.iotype == TPM_INF_IO_PORT) >>> outb(data, tpm_dev.data_regs + offset); >>> else >>> +#endif >> >> This looks ugly. Can't you declare inb/outb anyway and skip the definition, >> so you can use IS_ENABLED() here instead? >> >> You can mark the declarations with __compiletime_error("some message"), so >> if an IS_ENABLED() reference is not removed at compile time, you get some >> readable error message instead of a link error. >> >> Cheers, >> Ahmad > > I didn't know about __compiletime_error() that certainly sounds > interesting even when using a normal #ifdef. > > That said either with the function not being declared or this > __compiletime_error() mechanism I would think that using IS_ENABLED() > relies on compiler optimizations not to compile in the missing/error > function call, right? I'm not sure if that is something we should do. Yes, it assumes your compiler is able to discard the body of an if (0), which we already assume, otherwise it wouldn't make sense for any existing code to use __compiletime_error(). To me this sounds much cleaner than #ifdefs in the midst of functions, which are a detriment to maintainability. Cheers, Ahmad > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |