Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp58738pxy; Tue, 20 Apr 2021 12:34:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/h5X7k3DwoWLPaE1o1/R0EbK/9ASONw5t4XrDRyHstCb/CqyHcxxeGtMaNTH/ctwQXJbZ X-Received: by 2002:a17:903:248e:b029:ec:b399:7d75 with SMTP id p14-20020a170903248eb02900ecb3997d75mr6845775plw.35.1618947241992; Tue, 20 Apr 2021 12:34:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618947241; cv=none; d=google.com; s=arc-20160816; b=ofJ+rbA5NqIkGyD+Vva4eHboGLRaMeItiSRbAiSYtoFphUih/UhYFzD+znvnNgZhe6 R3nrAkkKbOnS2DwykIKueJmpY8sSklBr5/xIYTjPI/8rrAzCrp50jx6Dd5d2MWsYc3kR VAxgkwyeMNA+GG+KGWyB3dwS6C311ATSt2JT+kncEv2lrZ/qm5SKsTompv9+DpnPsmpd CR+mvXmaiQDWHEtHxREYKFRngGo4q7UTwYwH0sonMqctg3trVo0nvC014c5BACKsCPXh kIXIYFV1DTyke2Z9IeV/2fySfjrgyobt+zJDf7EimGj7ilMdtcy1oPOY0s/0nadJ0OQc pB9w== 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:dkim-signature; bh=CeykSAZI90ujQ36EqZV5t9vjKLz3qOJxleoK2VZMDEQ=; b=nbJXA/nqVUcw6DpsFukKCdrLZiePp8Sj6IZRRXuL58rajKB0UoZz2vq8TXH5Qrlg5F OK5rKaMEvx9r1oQNdxEINT6CmNqu9zXgUmJCB5ILrMKed9Q3wT5L52szqCapfYc45tcQ lyWm6ZqMr2yNpWBFNdbAtIAFcgl2mE0pTcOIw/WeuktnxKRPJWOXdaWtR9owt+hO5SlX Eh0Kgz9giNhkuFmRrtIChjgMyjTRJglkM/f1G1MrAAUxhji1jue/VrCr7KtnYF+efLKY Ie8LZMtSeACXmA4+U2dYQfBkLd4rkgcX5KYY0O6yQJFvQ8BGVy/44OTZ/Z2NjCXKI6n6 xRrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="h7ND65/2"; 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m129si22307255pfd.105.2021.04.20.12.33.49; Tue, 20 Apr 2021 12:34: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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="h7ND65/2"; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233751AbhDTTd2 (ORCPT + 99 others); Tue, 20 Apr 2021 15:33:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233544AbhDTTd0 (ORCPT ); Tue, 20 Apr 2021 15:33:26 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 222F4C06174A for ; Tue, 20 Apr 2021 12:32:54 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id g17so45799883edm.6 for ; Tue, 20 Apr 2021 12:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CeykSAZI90ujQ36EqZV5t9vjKLz3qOJxleoK2VZMDEQ=; b=h7ND65/2bTQV5sECygtsgHLlJLV6CmUcPs5PTFxMtc5gX0SgwqTfEoqiedHIt0PmaL VQL94Ost3SRLMDK71qcFPng5iVODZivCqLDGx8Cd+ylWX9slFJknB1Ijaz171uj1OHCu pIW9WhLsEPkYdDKaSs/LA4ZhyriN8Raan3BlYsRuk0qBxZEJabHxBqi+W/2cX1SKvVY8 DyYYfziamSk0hUO64IbrT3cLjLdYrUaNa5UsGfqosGEo0BTCUPVW1h3wUr4qRafdqffj +KadtNdwcrceKfLLopkaXWiBtJzEnuazKo9hNpRiZrZwsBvxCxA3bF3Me7Lb7jB7E6UW nzjw== 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=CeykSAZI90ujQ36EqZV5t9vjKLz3qOJxleoK2VZMDEQ=; b=cnBPmKNe2i30gOwqOfKseKGnHG7XxsjiLUN7cbgb5RbmzbiXBuChsy4GLxaXGWRCVG ini1h831f6lkfgzngX9cx0EdaWgVTur5ntvj9Lp/9g/ZDt8qM/RmVhl7Z8CATVsfA/3c tJg5sljhDKFx61uhaC5NKf4yeqYTE1rRkC3KNnh1POtsW7qgL9i8AEc9+hbGj35SCrEh 4caXe86ublLCcHO5t1noE4xtCIuFIjtF5aM7losOU04ABDkO8sp9v9/UraALFFPqk6ym 2xYiNHAJY1hdY9VAxwyPyTscc4AQSDOkMRNlkT/+ziSDh941xl8uIE9WZW/aoLReM8xS 13gg== X-Gm-Message-State: AOAM5301g2RQagvizB4qtwnxFKme5l1wOakzZbVIOESd/2tKXSWydzzj FKm7Wvd33ksFyDoFwWXNVmXFMRgQi6ORZcgOmwdobA== X-Received: by 2002:a05:6402:35c8:: with SMTP id z8mr9829147edc.210.1618947172905; Tue, 20 Apr 2021 12:32:52 -0700 (PDT) MIME-Version: 1.0 References: <20210419112725.42145-1-wanjiabing@vivo.com> <20210419160411.GG1904484@iweiny-DESK2.sc.intel.com> <874kg1yt0o.fsf@fossix.org> In-Reply-To: <874kg1yt0o.fsf@fossix.org> From: Dan Williams Date: Tue, 20 Apr 2021 12:32:43 -0700 Message-ID: Subject: Re: [PATCH] libnvdimm.h: Remove duplicate struct declaration To: Santosh Sivaraj Cc: Ira Weiny , Wan Jiabing , linux-nvdimm , Linux Kernel Mailing List , kael_w@yeah.net Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021 at 6:39 AM Santosh Sivaraj wrote: > > Hi Ira, > > Ira Weiny writes: > > > On Mon, Apr 19, 2021 at 07:27:25PM +0800, Wan Jiabing wrote: > >> struct device is declared at 133rd line. > >> The declaration here is unnecessary. Remove it. > >> > >> Signed-off-by: Wan Jiabing > >> --- > >> include/linux/libnvdimm.h | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h > >> index 01f251b6e36c..89b69e645ac7 100644 > >> --- a/include/linux/libnvdimm.h > >> +++ b/include/linux/libnvdimm.h > >> @@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct device *dev, > >> > >> struct nvdimm_bus; > >> struct module; > >> -struct device; > >> struct nd_blk_region; > > > > What is the coding style preference for pre-declarations like this? Should > > they be placed at the top of the file? > > > > The patch is reasonable but if the intent is to declare right before use for > > clarity, both devm_nvdimm_memremap() and nd_blk_region_desc() use struct > > device. So perhaps this duplicate is on purpose? > > There are other struct device usage much later in the file, which doesn't have > any pre-declarations for struct device. So I assume this might not be on > purpose :-) Yeah, I believe it was just code movement and the duplicate was inadvertently introduced. Patch looks ok to me. > > On a side note, types.h can also be removed, since it's already included in > kernel.h. That I don't necessarily agree with, it just makes future header reworks more fraught for not much benefit.