Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp464452pxj; Thu, 17 Jun 2021 06:51:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBr5eKrQRc0ilAqD04+kb1YwPF5QVPU0QgfWkdVgskHyq85cjy/dRPaSf9Kgm2IoDNOtrv X-Received: by 2002:a05:6402:204:: with SMTP id t4mr6584247edv.34.1623937868629; Thu, 17 Jun 2021 06:51:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623937868; cv=none; d=google.com; s=arc-20160816; b=Qv42pj8f1j+5C3qBQsdH0aPVkqUuQpf69OXN/3Hp+TBM6fK0YU/sFmDQTsniZNPnMH +wAm2AoJWYh1M/UHL974doI2qqrIS4qaUBqht7LZsNRc+IbxtUhReR0yGj6hlEHiI7Qt zSD150nb9rKsmukoPA/yY0nofKXKzP0NbpXa1Kc1804e/ioyE6FnxbmoyWx8FjBucQf7 aaw29f1qSLLL3GcSa/9EFXzHmAHcye5ueHzdyVT5mjRDbp97K3D1fNx0O9JOzZy6JRV+ FhygCCW+x7ZPSbolnCYbpYBwlO+Idt87CuUjsfQaJ4E7aR3DAlxcAVNccXAT5l7VMfMV HPCw== 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=UXLDf/zBwxcg6JRYUw5vSzsqMPchC5DDa1UwTpdQ4zI=; b=rnibuHJ5cBdeMQ+mk64RFED5te57iEhwEQL8MMBgQ9b3fkwgms51eowI5Mas0d6IMd PBQZcnxYfBl8atDIMX7aopdIbhkw446hkek/iHGtviVD7i6SyM7Yq9XKTomQDhCdarJM ZZ7TR0/ChYpepsV/wWhfIRYcyAMpVXRy7w485PbXW77fTdMwVBTmS7ahXBnBJHDhLQC6 1XDkurjmPs/caJV1DSqeMCtsQPLAzUVyw6XV7ka2CimXmyoUiiUkumXICToj8qCmRamS QKQ9z+Wn4Wq/yBubRQTs8pSSwWkVLya8oyclRcuDANselLFAVfmXCHnjhfn8oAkrlKa4 OJ3A== 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 v9si5434867eds.500.2021.06.17.06.50.45; Thu, 17 Jun 2021 06:51:08 -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 S231701AbhFQMOq (ORCPT + 99 others); Thu, 17 Jun 2021 08:14:46 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:41775 "EHLO mail-ot1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231252AbhFQMOp (ORCPT ); Thu, 17 Jun 2021 08:14:45 -0400 Received: by mail-ot1-f47.google.com with SMTP id w23-20020a0568301117b029044c37262dadso526214otq.8; Thu, 17 Jun 2021 05:12:38 -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=UXLDf/zBwxcg6JRYUw5vSzsqMPchC5DDa1UwTpdQ4zI=; b=E+CLePaPKn1GH4E6We1Jk3yr3W0IGBRFyiQuxnsxRJ0luFqNCpsuZEECqXFXKC9+Kw Dffxp7QC1XnoRvrkemDDhVwlKEzQKQeCDoQcnXLmN4AtxV0y8xQoUYI3kFs3Dxvp78fs T3QEUkEdOMZtpi3pn03FzK7mY+YfOmdqZc/kDXNkqTti3m0WcHSyN8DRAikP3ipTDfrH Za+rMtTt+eFSmRKTbLqhNyq46qJ1NgOcu/4ZHbSQBCq4Fj8jhsTLh7LmhiabnuiklsFN dIORzKF+jCSPvhbU81fmjT842ew/+eodDPfXr9roWs1BeA4CMYuGB/ULb4W0f/COuQG7 9ckQ== X-Gm-Message-State: AOAM532t0mszGwP11zMCjNJqq/E701hdy1cCKQfRb8mkwI1gLMU42afm pTGXW7IcCzMY+OGqs9QYvvrg7JWD7WIzWCIgI8c= X-Received: by 2002:a9d:3e53:: with SMTP id h19mr4306429otg.260.1623931958133; Thu, 17 Jun 2021 05:12:38 -0700 (PDT) MIME-Version: 1.0 References: <20210615033535.2907295-1-libaokun1@huawei.com> In-Reply-To: <20210615033535.2907295-1-libaokun1@huawei.com> From: "Rafael J. Wysocki" Date: Thu, 17 Jun 2021 14:12:27 +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 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!