Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1024885pxj; Thu, 17 Jun 2021 20:31:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5lAOP3qxCjo0L1Z6367aH/w6DKWaBatkuRa2X+TfNFuzuPp1m8YxFQ83wip7+nzhL6dlE X-Received: by 2002:a17:906:8988:: with SMTP id gg8mr343678ejc.104.1623987116542; Thu, 17 Jun 2021 20:31:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623987116; cv=none; d=google.com; s=arc-20160816; b=GKGxoCdQw91NULuwEM/Gv34C3kcYzGaRQ0B93ZxFr13N9HwK+L8yL6DmJlqQiV1jSd uf50I4ksjQwCBiSna8z4cAdDYAXWxSZN2J9t9xXduytn2Vn+aWE4pQhMecFDMQnUJIP2 VsqMpEIHjOMRLGTGu7FpqXOHqwWwDwHPb7Y0YVb6DaZnoE7UBXHniDAGRw+XQY9kM1N7 S26dATjY14RT2ICeGVcyYXmAbme6JyYn69L7I+SPkX167Qzfj8RR2Uk+sunxXf0WS2cs QK55UJJCngFwajmdJK1Hbf1r9mUoNgE+Z4eO0d8VHHoIjz/iyL/pfOGZoZLxk5/MVwxI WTKA== 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 :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=BMjd+/r92YSyOW3skGOtiKD9B9/lR6oxFwVkAs7Slgo=; b=utGJqg9S3RDCtDZa6Wcvel8nz6dIcLMCcsqXRsvNFSMVyJ8ElaCxOmNr4lTRDJHKqr ZUugfuv3bBFENQrB+/nAdAD9YuSmJE3N3cQtWj0pnST2OY5/P9Rxq5XBoPorL2R+CPdl AGcId9cvaS/xk1bxh1rsejD2IxbAx7AqVkKR1cuEBZJrY5BoKGAl6E/UbIaTeTal42Fu UlCOM97SoUShv0y6PAF++2cDwTpQ9rRAf6IyrX2A1EuBms2CSX9LFrZ1p4MiCEXXFBfB v9ugd6KELj4yfwVRvHUV+t95T0U1DFB79gyy8axokLDCZ/xlJ5+/fPt99oviC1yaMLr1 60Pg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 20si1149294ejj.363.2021.06.17.20.31.34; Thu, 17 Jun 2021 20:31:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233385AbhFRB1w (ORCPT + 99 others); Thu, 17 Jun 2021 21:27:52 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:11057 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230318AbhFRB1v (ORCPT ); Thu, 17 Jun 2021 21:27:51 -0400 Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4G5h4N38ttzZd5F; Fri, 18 Jun 2021 09:22:44 +0800 (CST) Received: from dggpeml500020.china.huawei.com (7.185.36.88) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 18 Jun 2021 09:25:41 +0800 Received: from [10.174.177.174] (10.174.177.174) by dggpeml500020.china.huawei.com (7.185.36.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 18 Jun 2021 09:25:40 +0800 Subject: Re: [PATCH -next v2] x86/power: fix doc warnings in cpu.c To: "Rafael J. Wysocki" CC: "Rafael J. Wysocki" , Pavel Machek , Thomas Gleixner , Ingo Molnar , Borislav Petkov , the arch/x86 maintainers , "H. Peter Anvin" , Linux PM , "Linux Kernel Mailing List" , Wei Yongjun , Yue Haibing , , yu kuai References: <20210615033535.2907295-1-libaokun1@huawei.com> From: "libaokun (A)" Message-ID: Date: Fri, 18 Jun 2021 09:25:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.174] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500020.china.huawei.com (7.185.36.88) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thank you for your advice. I'm about to send a patch v3 with the changes to fix the warning. Best Regards. 在 2021/6/18 1:32, Rafael J. Wysocki 写道: > On Thu, Jun 17, 2021 at 2:12 PM Rafael J. Wysocki wrote: >> On Tue, Jun 15, 2021 at 5:26 AM Baokun Li wrote: >>> Fixes the following W=1 kernel build warning(s): >>> >>> arch/x86/power/cpu.c:76: warning: Function parameter or >>> member 'ctxt' not described in '__save_processor_state' >>> arch/x86/power/cpu.c:192: warning: Function parameter or >>> member 'ctxt' not described in '__restore_processor_state' >>> >>> Signed-off-by: Baokun Li >>> --- >>> V1->V2: >>> Fix the formatting of this kerneldoc comment >>> >>> arch/x86/power/cpu.c | 31 ++++++++++++++++--------------- >>> 1 file changed, 16 insertions(+), 15 deletions(-) >>> >>> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c >>> index 3a070e7cdb8b..54b530db5ed0 100644 >>> --- a/arch/x86/power/cpu.c >>> +++ b/arch/x86/power/cpu.c >>> @@ -58,19 +58,20 @@ static void msr_restore_context(struct saved_context *ctxt) >>> } >>> >>> /** >>> - * __save_processor_state - save CPU registers before creating a >>> - * hibernation image and before restoring the memory state from it >>> - * @ctxt - structure to store the registers contents in >>> + * __save_processor_statei() - Save CPU registers before creating a >>> + * hibernation image and before restoring >>> + * the memory state from it >>> + * @ctxt: Structure to store the registers contents in. >>> * >>> - * NOTE: If there is a CPU register the modification of which by the >>> - * boot kernel (ie. the kernel used for loading the hibernation image) >>> - * might affect the operations of the restored target kernel (ie. the one >>> - * saved in the hibernation image), then its contents must be saved by this >>> - * function. In other words, if kernel A is hibernated and different >>> - * kernel B is used for loading the hibernation image into memory, the >>> - * kernel A's __save_processor_state() function must save all registers >>> - * needed by kernel A, so that it can operate correctly after the resume >>> - * regardless of what kernel B does in the meantime. >>> + * NOTE: If there is a CPU register the modification of which by the >>> + * boot kernel (ie. the kernel used for loading the hibernation image) >>> + * might affect the operations of the restored target kernel (ie. the one >>> + * saved in the hibernation image), then its contents must be saved by this >>> + * function. In other words, if kernel A is hibernated and different >>> + * kernel B is used for loading the hibernation image into memory, the >>> + * kernel A's __save_processor_state() function must save all registers >>> + * needed by kernel A, so that it can operate correctly after the resume >>> + * regardless of what kernel B does in the meantime. >>> */ >>> static void __save_processor_state(struct saved_context *ctxt) >>> { >>> @@ -181,9 +182,9 @@ static void fix_processor_context(void) >>> } >>> >>> /** >>> - * __restore_processor_state - restore the contents of CPU registers saved >>> - * by __save_processor_state() >>> - * @ctxt - structure to load the registers contents from >>> + * __restore_processor_state() - Restore the contents of CPU registers saved >>> + * by __save_processor_state() >>> + * @ctxt: Structure to load the registers contents from. >>> * >>> * The asm code that gets us here will have restored a usable GDT, although >>> * it will be pointing to the wrong alias. >>> -- >> Applied as 5.14 material, thanks! > And dropped, because it introduced a build issue. > .