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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA947ECDFA1 for ; Sun, 23 Oct 2022 21:17:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8067940008; Sun, 23 Oct 2022 17:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3045940007; Sun, 23 Oct 2022 17:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF80F940008; Sun, 23 Oct 2022 17:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BDF12940007 for ; Sun, 23 Oct 2022 17:17:37 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8EDA51208CD for ; Sun, 23 Oct 2022 21:17:37 +0000 (UTC) X-FDA: 80053475754.18.E0FFB63 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf13.hostedemail.com (Postfix) with ESMTP id F36EA20002 for ; Sun, 23 Oct 2022 21:17:36 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 562F0B80DCE; Sun, 23 Oct 2022 21:17:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82492C433D6; Sun, 23 Oct 2022 21:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666559854; bh=eww41udNaMuXD4PMpBks27BJLoB4EyHOihBbydaDgtQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e+6zZQfAIp1iaUxFxyNJAVYls4dVrhMQvzQHdfcTDPdBn5omPfL1g/MV+VEstmGX+ TyhPT4XDoSkylEW3mt9g5y/sNjg+NVGGxPQmyz/xSeTkpIdCJeclplweDa0n1xJeQG jh2rOZuuhqR42zLANPnwmHOpXISgE+h/jGpkLFUGRrRMXU8/A8dj1lR+JNAKTssnmw cTKH4YPSQNCxY8YEviveP11uRO9o4IX2xte5ta2RAWVcZvGWl6iEyZybjlGvJOmEUV WcQd+lnGwabwrk3ejl9S08tWuMUI6g4ilm0sWdXFFr6AoDMpU93xZHlmoIrdv9MYC1 szA9tsjpkiOhQ== Date: Mon, 24 Oct 2022 00:17:27 +0300 From: Jarkko Sakkinen To: "Kalra, Ashish" Cc: Borislav Petkov , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, michael.roth@amd.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com Subject: Re: [PATCH Part2 v6 12/49] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP Message-ID: References: <87a0481526e66ddd5f6192cbb43a50708aee2883.1655761627.git.ashish.kalra@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666559857; a=rsa-sha256; cv=none; b=uxjvf0Mz24f3+ktc6fNWs7/ZU8zcI0rl6xJnhEYotgBRypVqDo5VmMfSkcU8L3SluiFbIm 8N9z9hF0hQ1Uj9/A2QsR21Qkw1tNYH521EZ69J0FYiqSlZY5qZ034rLTnTey4AStztvmWJ AKpeivdT01fJ+yDSjrEcpnMyROhpvPk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=e+6zZQfA; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666559857; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wm2aJOJm2GVFstApHzQ40EpUf36DUTZO7owYeDG3U4g=; b=RYjIN+P5q78s4GtHxNSBZKhaYLg6kFykzJvUa4Y6Q8MswELRWbJv1KreujBk9UkCMPkixu /D3ORqpv6dntzCmvWf/RyzSNdJTgZKHEfj36IahvsXTaGnaH9R4Y1CTWvVMpYx1DmJflbS KirwRkVMtU/kGuCpr7XW/9+ZbbZk8vU= Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=e+6zZQfA; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org X-Rspamd-Server: rspam04 X-Rspam-User: X-Stat-Signature: tm1wwagq1q1eapeo6zqp7ozoyxgcs6ng X-Rspamd-Queue-Id: F36EA20002 X-HE-Tag: 1666559856-996164 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 19, 2022 at 01:48:48PM -0500, Kalra, Ashish wrote: > Another follow up: > > > > >   int sev_platform_init(int *error); > > > > +/** > > > > + * sev_snp_init - perform SEV SNP_INIT command > > > > + * > > > > + * @error: SEV command return code > > > > + * > > > > + * Returns: > > > > + * 0 if the SEV successfully processed the command > > > > + * -%ENODEV    if the SEV device is not available > > > > + * -%ENOTSUPP  if the SEV does not support SEV > > > > + * -%ETIMEDOUT if the SEV command timed out > > > > + * -%EIO       if the SEV returned a non-zero return code > > > > > > Something's weird with those args. I think it should be > > > > > >     %-ENODEV > > > > > > and so on... > > > > > > > Yes, off course %- > > > > I see that other drivers are also using the same convention: > > include/linux/regset.h: > .. > /** > * user_regset_set_fn - type of @set function in &struct user_regset > * @target: thread being examined > * @regset: regset being examined > * @pos: offset into the regset data to access, in bytes > * @count: amount of data to copy, in bytes > * @kbuf: if not %NULL, a kernel-space pointer to copy from > * @ubuf: if @kbuf is %NULL, a user-space pointer to copy from > * > * Store register values. Return %0 on success; -%EIO or -%ENODEV > * are usual failure returns. The @pos and @count values are in > ... > > include/linux/psp-tee.h: > .. > /** > * psp_tee_process_cmd() - Process command in Trusted Execution Environment > * @cmd_id: TEE command ID (&enum tee_cmd_id) > * @buf: Command buffer for TEE processing. On success, is updated > * with the response > * @len: Length of command buffer in bytes > * @status: On success, holds the TEE command execution status > * > * This function submits a command to the Trusted OS for processing in the > * TEE environment and waits for a response or until the command times out. > * > * Returns: > * 0 if TEE successfully processed the command > * -%ENODEV if PSP device not available > * -%EINVAL if invalid input > * -%ETIMEDOUT if TEE command timed out > * -%EBUSY if PSP device is not responsive > */ > ... > > Thanks, > Ashis In SGX driver the convention is: * Return: * - -ENODEV ... * - -EINVAL ... "Return:" because this is what kernel-nanodoc-HOWTO.txt suggests. The dashes are recognized by Sphinx as list so each return code gets a newline when processed through "make htmldocs". Otherwise, you get a mess because newlines will be removed. I don't actually have idea of '%' and neither see it in the kernel documenation. BR, Jarkko