Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8124989ybi; Tue, 9 Jul 2019 09:36:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwHk7YU2XZzws5oHelMUFIdUGGyYcfLGsYuIRo0nx/erXrWe/45dM12qnvYxyKBsEovmDx8 X-Received: by 2002:a17:902:9f93:: with SMTP id g19mr32939401plq.223.1562690204307; Tue, 09 Jul 2019 09:36:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562690204; cv=none; d=google.com; s=arc-20160816; b=YOTk7QjE6j/VUW4NcKqGP7j7paG9TbskH0/5e2uBcI0QqU7u5uNaFO4N+wNio0jnsO zjJjBX0l6KHnknuVahgDLtHhf1wJRqa7WPlWQ5z1k7EB0Ev/poyjSt6jhXX6EpHf4AwN QXJEL+MF5H8lxwjdQ2dxjp/1ioHXzx1b6sX66jdVLNm3kS9SJEeX74gwbxMnBboka5Hj 0b76iyZ07QMiEWyhyZw5ZeoGMkM40S/63BO5XP5GDNGoxFiKFDY0A1HKT1b2ypLo18R6 ONbflTBDedj1YIEldEEw1PXSKrXTTmcZndspQo78x0EGJYOSW1IMpf9FRYBFXh0m6CdE rfNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=cPPf/9hGS7O1lvXL+ojlI8/7k0QLwOgUb66bbjyG+6Q=; b=c8qrMXpZOWmfdtcs7twG/0XbGxRFcWqzO1M6KWgyev5OC3we1LivD+ie3EVtR7uR5t OP5/jI4oGYrTgvhjUtXt4znSjrrvzwHLXgWoaze1+B4JtRCEJOt5XMfMav7JAnmSvZxU VMK5z9YXk/e0aaWCT/c/+pn8F+ONidxJC5SL1PX2yS3b/9FDxikG+LDQPYyaQZkjOvdB Nu7rXlWIs0kpaty07as0ngR6ETcJr0Iwrwo/S/AiO5d5D2yI5BxGaMr8pRKwn0kor56f aHF6jll8ppt2VDYcdkM4fhK5HLk8q64Nk7xD6coVCpVkbjlCOdPee4Xy20U67ThtDVDj 9PWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h131si22852551pgc.236.2019.07.09.09.36.28; Tue, 09 Jul 2019 09:36:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726486AbfGIQfz (ORCPT + 99 others); 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