Received: by 10.213.65.68 with SMTP id h4csp3330444imn; Mon, 9 Apr 2018 19:15:58 -0700 (PDT) X-Google-Smtp-Source: AIpwx49WdedKw0/Y1XkYyeWUEUITuzRy16vj96TFxlCZ8ggacZUCqBip5VzECQjU0Ai8XlfIzJz5 X-Received: by 2002:a17:902:70c6:: with SMTP id l6-v6mr2172938plt.201.1523326558688; Mon, 09 Apr 2018 19:15:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523326558; cv=none; d=google.com; s=arc-20160816; b=E3o5hOPByxur60GN3YmhtfG/Q5ZX2EdMe9vGsKbpLUjvwx145GUvRrRm47GkXAnoz/ df43W6uQV19+QyrTWOosvfLRkdG8+97nUCRrq7KHVDyt+r3BJvD2Dygpz8QCPgvh/8VK 8rtmMiwEnXc7RwFuH2Oa8I7/mhO9h6+ohul5uMTccVKyiDRIBDgde4FqfHc6CZZX1Chg cP3coBpgtjsB7yp2WVMbNy+jf1kE3Q9TN1YoKKciv8bgQQkqRgtnwMxgRfq4gZEWJo9s R7UNJSxrLkWa90ZTB/43qx0dkhdPyZ+SkrTn5hFEL2ISir26WjfOk5AYwczNwkEH0Y6Z /RLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=5ThMxY2EY1yT0w5lAtqbsssb+WLstDRkng+Wtuoq6oI=; b=k9Tl6xLxkuzIU043JgNpwgKZS/ZFsk08DEfRp1oBCl4q225WAAjq/CnpzMgntDCauF kgqlwBErbfhAY6Zs9c29DMb5Q4VdcJBe9lodAb1lBm6U2ZRtIsi5NVBeu7GddHJcTH3N +cpdGAC2K2C2OZQON3T1IfYsp1HxSQX3ANpucQLPPE+DCNyaTutPkoVIhRkUHd6oSpkx 1fbA5GzpnZ49TkmPmROdwPALgausaRp1NKgCspxhOo9FMR22TlZGtGrc9LRmuNJU41ui 2Ma4oB/Omo3+3j2BG2BojxKofuu4S3AvbTSWuq/4NVTzzbHje+RXH9Fv7UfNroy/jrEq E1eQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m65si1275059pfb.130.2018.04.09.19.15.21; Mon, 09 Apr 2018 19:15:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752464AbeDJCKx (ORCPT + 99 others); Mon, 9 Apr 2018 22:10:53 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56740 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751589AbeDJCKv (ORCPT ); Mon, 9 Apr 2018 22:10:51 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 68CCE76FBA; Tue, 10 Apr 2018 02:10:50 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E3DB21A468E; Tue, 10 Apr 2018 02:10:46 +0000 (UTC) Date: Tue, 10 Apr 2018 10:10:43 +0800 From: Baoquan He To: Dan Williams Cc: Linux Kernel Mailing List , Patrik Jakobsson , David Airlie , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Dmitry Torokhov , Rob Herring , Frank Rowand , Keith Busch , Jonathan Derrick , Lorenzo Pieralisi , Bjorn Helgaas , Thomas Gleixner , Brijesh Singh , =?iso-8859-1?B?Suly9G1l?= Glisse , Borislav Petkov , Tom Lendacky , Greg Kroah-Hartman , Yaowei Bai , Wei Yang , devel@linuxdriverproject.org, linux-input@vger.kernel.org, linux-nvdimm , Device Tree , linux-pci@vger.kernel.org Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling Message-ID: <20180410021043.GC25724@localhost.localdomain> References: <20180408024724.16812-1-bhe@redhat.com> <20180408024724.16812-2-bhe@redhat.com> <20180409090853.GJ19345@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 10 Apr 2018 02:10:50 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 10 Apr 2018 02:10:50 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bhe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/18 at 08:38am, Dan Williams wrote: > On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He wrote: > > The struct resource uses singly linked list to link siblings. It's not > > easy to do reverse iteration on sibling list. So replace it with list_head. > > > > And code refactoring makes codes in kernel/resource.c more readable than > > pointer operation. > > > > Besides, type of member variables of struct resource, sibling and child, are > > changed from 'struct resource *' to 'struct list_head'. Kernel size will > > increase because of those statically defined struct resource instances. > > > > Signed-off-by: Baoquan He > > --- > [..] > > diff --git a/kernel/resource.c b/kernel/resource.c > > index e270b5048988..473c624606f9 100644 > > --- a/kernel/resource.c > > +++ b/kernel/resource.c > > @@ -31,6 +31,8 @@ struct resource ioport_resource = { > > .start = 0, > > .end = IO_SPACE_LIMIT, > > .flags = IORESOURCE_IO, > > + .sibling = LIST_HEAD_INIT(ioport_resource.sibling), > > + .child = LIST_HEAD_INIT(ioport_resource.child), > > }; > > EXPORT_SYMBOL(ioport_resource); > > > > @@ -39,6 +41,8 @@ struct resource iomem_resource = { > > .start = 0, > > .end = -1, > > .flags = IORESOURCE_MEM, > > + .sibling = LIST_HEAD_INIT(iomem_resource.sibling), > > + .child = LIST_HEAD_INIT(iomem_resource.child), > > }; > > EXPORT_SYMBOL(iomem_resource); > > > > @@ -57,20 +61,32 @@ static DEFINE_RWLOCK(resource_lock); > > * by boot mem after the system is up. So for reusing the resource entry > > * we need to remember the resource. > > */ > > -static struct resource *bootmem_resource_free; > > +static struct list_head bootmem_resource_free = LIST_HEAD_INIT(bootmem_resource_free); > > static DEFINE_SPINLOCK(bootmem_resource_lock); > > > > +struct resource *sibling(struct resource *res) > > +{ > > + if (res->parent && !list_is_last(&res->sibling, &res->parent->child)) > > + return list_next_entry(res, sibling); > > + return NULL; > > +} > > + > > +struct resource *first_child(struct list_head *head) > > +{ > > + return list_first_entry_or_null(head, struct resource, sibling); > > +} > > + > > These names are too generic for new global symbols. A "resource_" > prefix is warranted. Thanks, sounds reasonable, will change them as resource_sibling() and resource_first_child(). Or res_sibling()/res_1st_child()?