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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5AE91C433EF for ; Tue, 3 May 2022 15:09:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232281AbiECPN1 (ORCPT ); Tue, 3 May 2022 11:13:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238109AbiECPNU (ORCPT ); Tue, 3 May 2022 11:13:20 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 115AE3B56C for ; Tue, 3 May 2022 08:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651590588; x=1683126588; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=IACxIDHwXqlTIFLmAExQlUxosyzk99ozoP6vJrNh0dU=; b=WjpduO+YShmTaznUL0ZYjYUVAbqfnvzptbOyVKmEm9cFK9zBUKKJrpzS sjWORaWDIwm8SSSWA8/dmYEJYihxlT6NO8hEdGIV3EiUfukaYjX4RSzd5 agMltmycERc+Fi71o9XdxfgmlZ4TYDwx2P5yZpH0pODtcmhaX/wCfg6m6 y8TaRgzCMLIoDYLrvhjiO3IAk3St/Ziw5foWRFqKmM/rPiqjnU5sCm2s8 n88cZ4N/meTx3wbnf+JEVMkuk7U8lnLYALGB7dCuLoPN2hCoW6ElvRHzz UuVG47FdbiJtRlb++vDDnvs/vOH7PjN3Pi2Vr2GNGCzcKA6RRmSE8w4E9 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10336"; a="267654839" X-IronPort-AV: E=Sophos;i="5.91,195,1647327600"; d="scan'208";a="267654839" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 May 2022 08:09:47 -0700 X-IronPort-AV: E=Sophos;i="5.91,195,1647327600"; d="scan'208";a="562240918" Received: from kputnam-mobl1.amr.corp.intel.com (HELO [10.209.19.155]) ([10.209.19.155]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 May 2022 08:09:46 -0700 Message-ID: Date: Tue, 3 May 2022 08:09:45 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.7.0 Subject: Re: [PATCH v5 1/3] x86/tdx: Add TDX Guest attestation interface driver Content-Language: en-US To: Wander Costa Cc: Kai Huang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , Isaku Yamahata , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, open list References: <20220501183500.2242828-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220501183500.2242828-2-sathyanarayanan.kuppuswamy@linux.intel.com> <5473f606bd8e60dd7b8d58a540285d126a1361bd.camel@intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/3/22 7:38 AM, Wander Costa wrote: >> I don't want to pollute the dmesg logs if possible. For IOCTL use case, >> the return value can be used to understand the failure reason from user >> code. But for initcall failure, pr_err message is required to understand >> the failure reason. > How often is this call expected to fail? In general, it should not fail (so very low fail frequency). But the point is, we can easily understand this failure from user end. So we don't need to print more in non-debug environment. > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer