Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2038094pxb; Thu, 7 Oct 2021 22:30:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxi/NL2oPwFUWzeyYYR1zdgFAZTpd+ueeUdn1eowxxneKq0x7O7U7Ntj99oEizxgtRjpF0e X-Received: by 2002:a17:906:d979:: with SMTP id rp25mr1542695ejb.355.1633671032551; Thu, 07 Oct 2021 22:30:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633671032; cv=none; d=google.com; s=arc-20160816; b=efeRy4nfu8H+IZBmNZsr5MhDXRT4N3ByBUcM5ufFvziL5OblNVCgwOdRTwid1TCXXs Kba3mL+MPWm6sZaHG3F3JabBPar76I0oodTaURNCoB02vdhpZWafiyOHI1T8JeKTg0wb sLJrmCPt8wZqNgwuwLqI88NuFOYwMW+jcGJEvgefFBVjqt9ptT0MBcfa0scDjKcS/Rq8 V6GIju9mQM0xw1X6M5hBiUX0Qd+JqVHk+WtonKUphoN3HGkou7wy/raY8+PxCMYiN4Eh f6f5Hp55Tr4mpw4rMmQfFD1J5E6VInz0o1fypDPenVEL5g8cV66+mCblZhnQn94BcVt+ O9Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=fRVqtB6tjc3sxvXUb6FPScwW0I2W4WcKV6lwQWDcLCc=; b=U1RLHtE95tzNCta44Oh30BS73KcAvOa4XHc5D697SJ6e7zo4/nQfJxobR7nQNVwklO fVeM7r++vsqXasS/oddaPUZULHXfm6lXxMedv1GeUSOf3PPvYWaXs50FFzwmUpryDO6w Kx5YeVI4IEFE6rPuA50iqp6DHS7DQd2wJmeVEOk1m64ImdfM0WsxTZQMxTupPpE0E8KQ SrhMDA17XUsBiOYGczR10uS6k1oOaM2XRMZEWTs/89JquDNtnsufIZYUMS6UFOeUDU4T qwOtBFjeaBcr+NjOcKHxrn6uixnTJuNlxo3PVkXr/FPISiK940Ob3IPaK0YHy2v5O9AU MpCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=DmZ3bBlJ; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k11si2059354ejk.702.2021.10.07.22.30.08; Thu, 07 Oct 2021 22:30:32 -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; dkim=pass header.i=@axtens.net header.s=google header.b=DmZ3bBlJ; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229654AbhJHFap (ORCPT + 99 others); Fri, 8 Oct 2021 01:30:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229534AbhJHFao (ORCPT ); Fri, 8 Oct 2021 01:30:44 -0400 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 551DFC061570 for ; Thu, 7 Oct 2021 22:28:50 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id g184so2033016pgc.6 for ; Thu, 07 Oct 2021 22:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=fRVqtB6tjc3sxvXUb6FPScwW0I2W4WcKV6lwQWDcLCc=; b=DmZ3bBlJOasNrb5KADrKm87TITN3NDKvTs+ZM+h0mGXkGv8yuRH2ITtU6l5wtXhJjg FfXvz1XmlILKnNdcoQHrztrjUkxDw9bI/71PS/u7zk6yXUGxC9JyEnUgqvMXsL1R6UVP W0gU+aQx7Ag7ey4mpODEmfcC+xaMjYqzxZ81E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=fRVqtB6tjc3sxvXUb6FPScwW0I2W4WcKV6lwQWDcLCc=; b=r9YNwd8pN/4Q6Why8o7sZaKZ49BzXfigk99FYn+MOeZ49nUFI4XjUe6ckqitxoMnop qH7t3b+QyMhT0Sr6PamELcEVNm1dzYluQxlVfLa720qR5JgM9gIiR/g8ILUfh7n2UFbV CFywd4n4+cKCnQ8e/+f8b/P08xEoybWGxw19K3qHF8apUOHbL+dzflzXQ/UNBroOgutb coxas9xuQNUNqO8ky35ydYurQXpSAn77t8FcDZ2rXVHi7JFcb+Rm9GUp2+CCwJJOCM0O nqIZ2SQEL79vrtM4hO5iesE8hIRgSLTJru4nfGenSSMOQPH/S+q234HKMld7xh4nkQZB llkw== X-Gm-Message-State: AOAM5312P4pKGaa00fvbNX09W1C4hMoIo9rRo4Z4nZT8o00HehM0fopr beQFHValXLTuqR7k/+7nMcOASg== X-Received: by 2002:aa7:8294:0:b0:44c:c0b:d94c with SMTP id s20-20020aa78294000000b0044c0c0bd94cmr8323003pfm.24.1633670929752; Thu, 07 Oct 2021 22:28:49 -0700 (PDT) Received: from localhost ([2001:4479:e300:600:b4a4:1577:dca8:77b9]) by smtp.gmail.com with ESMTPSA id l18sm1130657pfu.202.2021.10.07.22.28.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 22:28:49 -0700 (PDT) From: Daniel Axtens To: Kai Song , linuxppc-dev@lists.ozlabs.org Cc: oohall@gmail.com, paulus@samba.org, linux-kernel@vger.kernel.org, Kai Song Subject: Re: [PATCH] powerpc/eeh:Fix docstrings in eeh In-Reply-To: <20211004085842.255813-1-songkai01@inspur.com> References: <20211004085842.255813-1-songkai01@inspur.com> Date: Fri, 08 Oct 2021 16:28:46 +1100 Message-ID: <87czog9jap.fsf@linkitivity.dja.id.au> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kai, Thank you for your patch! I have 3 very minor tweaks and I am otherwise very happy with it. Firstly, in your commit name, there should be a space between "powerpc/eeh:" and "Fix docstrings". You might also want to say "in eeh.c" rather than "in eeh" because there is eeh code in a number of other files too. > We fix the following warnings when building kernel with W=1: > arch/powerpc/kernel/eeh.c:598: warning: Function parameter or member 'function' not described in 'eeh_pci_enable' > arch/powerpc/kernel/eeh.c:774: warning: Function parameter or member 'edev' not described in 'eeh_set_dev_freset' > arch/powerpc/kernel/eeh.c:774: warning: expecting prototype for eeh_set_pe_freset(). Prototype was for eeh_set_dev_freset() instead > arch/powerpc/kernel/eeh.c:814: warning: Function parameter or member 'include_passed' not described in 'eeh_pe_reset_full' > arch/powerpc/kernel/eeh.c:944: warning: Function parameter or member 'ops' not described in 'eeh_init' > arch/powerpc/kernel/eeh.c:1451: warning: Function parameter or member 'include_passed' not described in 'eeh_pe_reset' > arch/powerpc/kernel/eeh.c:1526: warning: Function parameter or member 'func' not described in 'eeh_pe_inject_err' > arch/powerpc/kernel/eeh.c:1526: warning: Excess function parameter 'function' described in 'eeh_pe_inject_err' > > Signed-off-by: Kai Song > --- > arch/powerpc/kernel/eeh.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c > index e9b597ed423c..57a6868a41ab 100644 > --- a/arch/powerpc/kernel/eeh.c > +++ b/arch/powerpc/kernel/eeh.c > @@ -589,6 +589,7 @@ EXPORT_SYMBOL(eeh_check_failure); > /** > * eeh_pci_enable - Enable MMIO or DMA transfers for this slot > * @pe: EEH PE > + * @function : EEH function I don't think there should be a space between '@function' and ':'. I know the parameter is called 'function' and I think "EEH function" was a good guess for the docstring. However, if we look at the way 'function' is used, it is compared with EEH_OPT_xxx constants, and then it's passed to eeh_ops->set_option(), eeh_pci_enable() is also called in eeh_pe_set_option() with a parameter called 'option'. So I think maybe 'function' should be described as the "EEH option"? This is still very unsatisfactory but it's not the fault of your patch - the EEH codebase is very messy and it's worth fixing the W=1 warnings even if we don't fully clean up the EEH codebase. > - * eeh_set_pe_freset - Check the required reset for the indicated device > - * @data: EEH device > + * eeh_set_dev_freset - Check the required reset for the indicated device > + * @edev: EEH device > * @flag: return value > * This is good. > /** > * eeh_pe_reset_full - Complete a full reset process on the indicated PE > * @pe: EEH PE > + * @include_passed: include passed-through devices? > * > * This function executes a full reset procedure on a PE, including setting > * the appropriate flags, performing a fundamental or hot reset, and then > @@ -937,6 +939,7 @@ static struct notifier_block eeh_device_nb = { This is OK. > /** > * eeh_init - System wide EEH initialization > + * @ops: struct to trace EEH operation callback functions I think "@ops: platform-specific functions for EEH operations" is probably clearer? > * > * It's the platform's job to call this from an arch_initcall(). > */ > @@ -1442,6 +1445,7 @@ static int eeh_pe_reenable_devices(struct eeh_pe *pe, bool include_passed) > * eeh_pe_reset - Issue PE reset according to specified type > * @pe: EEH PE > * @option: reset type > + * @include_passed: include passed-through devices? > * This is OK. > * The routine is called to reset the specified PE with the > * indicated type, either fundamental reset or hot reset. > @@ -1513,12 +1517,12 @@ EXPORT_SYMBOL_GPL(eeh_pe_configure); > * eeh_pe_inject_err - Injecting the specified PCI error to the indicated PE > * @pe: the indicated PE > * @type: error type > - * @function: error function > + * @func: error function This is good. > * @addr: address > * @mask: address mask > * > * The routine is called to inject the specified PCI error, which > - * is determined by @type and @function, to the indicated PE for > + * is determined by @type and @func, to the indicated PE for This is good. When you resend, you can include: Reviewed-by: Daniel Axtens Kind regards, Daniel