Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp839203pxj; Thu, 17 Jun 2021 15:20:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzd8Zq3ZtFtUAJ2TXFhproIIRFGgQETszvclBF4QNuQKtfrt5etXpNqLQei6Tcut9m8+5TF X-Received: by 2002:a92:c952:: with SMTP id i18mr5124962ilq.292.1623968402003; Thu, 17 Jun 2021 15:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623968401; cv=none; d=google.com; s=arc-20160816; b=VYpNjOkkulV8bKy62WzWeLwUKWcXZbiVH4NjECuUYGTkGYBQsND8HJ0GuRnqHqw5Nb vaiNAMBDmjrySYvD+1jmIqQh4tDpDjDmyg/G6m82+pqJB9qrRb53InF5Y9jnfe1j/EvQ Mc6LCBWQdywGv0+gZ+GMjnoBcaNH9QN+FBNMbSVGvPjCkKTb8q8iJpY1Je3NX92C/nDT p1FAMpwS+d/61TPrVybK0ZmCGQbSThXoc11rGoyUA7rvJmDIRegISoJ5VyZEjheOvCHM gjzI/TQZJ2o2oMbVa3KrQdxuxW0y2c4kHS6Mm/JBOpECivqOzcoc3roQccuty5hWM2jW IRzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=81Ce+c7gQdmhNFYfxwHdHAzT80ECkLbi7pk1F5wt6Z0=; b=acmb+S33/P5F1vBhQlBsdRTe3QJeZOt4wpDGTX1587OXxi9qHrWEG2wyRD9EcRuHDH N7oUKVRj/DarTwJCgXt5xQWt+4dKW/yD/mtQ5uiUjKK5GU7YB5N5vzaH0e3ZCpRWC5rb 5ecIDIcYaQqWwb4zlH+5do9FlDk4/+9TcCAqXjoZ9AGNXu32EkP9+qt8b/L7Ysa9sgD8 8Z6mUqQIwXNWZozEkc5tfjkGX7wx3+q9sjyh3YWG+a8q6rBN3s0/pXBOkPWm0BYORWVN LAAU0J1SNQA2FPkU2a++7pihpIT8nvrR3vBh9zZ17biy5UC1PiERVt546wFwZlA8KaNn fMlg== 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h41si6640570jaa.50.2021.06.17.15.19.50; Thu, 17 Jun 2021 15:20:01 -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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232410AbhFQReo (ORCPT + 99 others); Thu, 17 Jun 2021 13:34:44 -0400 Received: from mail-ot1-f45.google.com ([209.85.210.45]:42510 "EHLO mail-ot1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231785AbhFQRen (ORCPT ); Thu, 17 Jun 2021 13:34:43 -0400 Received: by mail-ot1-f45.google.com with SMTP id w23-20020a9d5a970000b02903d0ef989477so6896479oth.9; Thu, 17 Jun 2021 10:32:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=81Ce+c7gQdmhNFYfxwHdHAzT80ECkLbi7pk1F5wt6Z0=; b=Z1YiSHnM9uAUEeYNJz+TUI8ULXcNZ3soPhSOJsKhuua/22KXCJXyYzBbiH9xZK557N s1TlS1pA9t/QesWJ9uHtgtBKXHOPEaNt7E5DOkuN2m3u6S+qTGPXX0mQ93FqRngCfIpb JJZTJYOOEnLmrgPj/IndhLRAUqpjU92BRuwRXyhMkS1kZDJh1YkTBwdBdK+6eJk2ysZi QCGcOVhjSt/gR+XTVe7RcgrWiSSKeqj2BXWCRKiVJaH6JV31BdExS6q5cPlLzbtoNmz2 aJszRDHbpiOWqHxYPR0CNdadPkRuozZSdNyCRffRhEuMppt9waEF2IMcMWdpHiZKT9PD vU7A== X-Gm-Message-State: AOAM532zNeHDqs9+ItT3r8ajWVlRcFgpnXelMnM20eidWsgXRox+Ojpl mMdf57Imx8Mjxbu9G/ib6+keKsK+TUjEzTyFrLM= X-Received: by 2002:a05:6830:1bf7:: with SMTP id k23mr5836663otb.206.1623951155517; Thu, 17 Jun 2021 10:32:35 -0700 (PDT) MIME-Version: 1.0 References: <20210615033535.2907295-1-libaokun1@huawei.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 17 Jun 2021 19:32:24 +0200 Message-ID: Subject: Re: [PATCH -next v2] x86/power: fix doc warnings in cpu.c To: Baokun Li 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 , yangjihong1@huawei.com, yu kuai Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.