From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 051FAC73C46 for ; Tue, 9 Jul 2019 16:35:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8CFE205ED for ; Tue, 9 Jul 2019 16:35:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726512AbfGIQfz (ORCPT ); Tue, 9 Jul 2019 12:35:55 -0400 Received: from mga06.intel.com ([134.134.136.31]:50954 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726218AbfGIQfz (ORCPT ); Tue, 9 Jul 2019 12:35:55 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 09:35:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,470,1557212400"; d="scan'208";a="185945552" Received: from mmaitert-mobl2.ger.corp.intel.com (HELO localhost) ([10.249.34.54]) by fmsmga001.fm.intel.com with ESMTP; 09 Jul 2019 09:35:49 -0700 Date: Tue, 9 Jul 2019 19:35:48 +0300 From: Jarkko Sakkinen To: Mimi Zohar Cc: Nayna Jain , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Jason Gunthorpe , Sachin Sant , George Wilson , Michael Ellerman , Michal Suchanek , Peter Huewe , Christoph Hellwig Subject: Re: [PATCH v2] tpm: tpm_ibm_vtpm: Fix unallocated banks Message-ID: <20190709163548.i6w7iawyy6bgnyuw@linux.intel.com> References: <1562458725-15999-1-git-send-email-nayna@linux.ibm.com> <586c629b6d3c718f0c1585d77fe175fe007b27b1.camel@linux.intel.com> <1562624644.11461.66.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1562624644.11461.66.camel@linux.ibm.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote: > > static int tpm_get_pcr_allocation(struct tpm_chip *chip) > > { > > int rc; > > > > rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ? > > tpm2_get_pcr_allocation(chip) : > > tpm1_get_pcr_allocation(chip); > > > > > return rc > 0 ? -ENODEV : rc; > > } > > > > This addresses the issue that Stefan also pointed out. You have to > > deal with the TPM error codes. > > Hm, in the past I was told by Christoph not to use the ternary > operator.  Have things changed?  Other than removing the comment, the > only other difference is the return. Lets purge the snippet: rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ? tpm2_get_pcr_allocation(chip) : tpm1_get_pcr_allocation(chip); In this statement ternary operator does make sense because it is the most readable way to express what is going on. We assign something selecting one of the two options as the value of rc based on a condition. It is like a natural fit for a ternary-operation and less messy than two assigment statements. On the other hand: return rc > 0 ? -ENODEV : rc; Here a better form would definitely be: if (rc > 0) return - ENODEV; return rc; It is just two hard to grasp the logic when ternary operation is used. Total ban of any language construct would be just utterly stupid. I would instead use common sense here. /Jarkko