All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Brijesh Singh" <brijesh.singh@amd.com>,
	"Device Tree" <devicetree@vger.kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	linux-pci@vger.kernel.org, "Wei Yang" <richard.weiyang@gmail.com>,
	"Keith Busch" <keith.busch@intel.com>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	linux-input@vger.kernel.org, "Borislav Petkov" <bp@suse.de>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Jonathan Derrick" <jonathan.derrick@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	devel@linuxdriverproject.org
Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling
Date: Mon, 9 Apr 2018 08:38:18 -0700	[thread overview]
Message-ID: <CAPcyv4huU32+oMeoF8-HmmctafZ_uOZN-v85O5M8Ka8pBXP+Lg@mail.gmail.com> (raw)
In-Reply-To: <20180409090853.GJ19345@localhost.localdomain>

On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He <bhe@redhat.com> 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 <bhe@redhat.com>
> ---
[..]
> 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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Baoquan He <bhe@redhat.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Patrik Jakobsson" <patrik.r.jakobsson@gmail.com>,
	"David Airlie" <airlied@linux.ie>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Keith Busch" <keith.busch@intel.com>,
	"Jonathan Derrick" <jonathan.derrick@intel.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Brijesh Singh" <brijesh.singh@amd.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Yaowei Bai" <baiyaowei@cmss.chinamobile.com>,
	"Wei Yang" <richard.weiyang@gmail.com>,
	devel@linuxdriverproject.org, linux-input@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	"Device Tree" <devicetree@vger.kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling
Date: Mon, 9 Apr 2018 08:38:18 -0700	[thread overview]
Message-ID: <CAPcyv4huU32+oMeoF8-HmmctafZ_uOZN-v85O5M8Ka8pBXP+Lg@mail.gmail.com> (raw)
In-Reply-To: <20180409090853.GJ19345@localhost.localdomain>

On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He <bhe@redhat.com> 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 <bhe@redhat.com>
> ---
[..]
> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "Brijesh Singh" <brijesh.singh-5C7GfCeVMHo@public.gmane.org>,
	"Device Tree"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"David Airlie" <airlied-cv59FeDIM0c@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Wei Yang"
	<richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Keith Busch"
	<keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"Yaowei Bai"
	<baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/@public.gmane.org>,
	"K. Y. Srinivasan" <kys-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>,
	"Frank Rowand"
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Lorenzo Pieralisi"
	<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
	"Stephen Hemminger"
	<sthemmin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>,
	linux-nvdimm
	<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
	"Patrik Jakobsson"
	<patrik.r.jakobsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Borislav Petkov" <bp-l3A5Bk7waGM@public.gmane.org>,
	"Tom Lendacky" <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>,
	"Haiyang Zhang"
	<haiyangz-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>,
	"Jérôme Glisse" <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Bjorn Helgaas"
	<bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	"Thomas Gleixner" <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	"Jonathan Derrick"
	<jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling
Date: Mon, 9 Apr 2018 08:38:18 -0700	[thread overview]
Message-ID: <CAPcyv4huU32+oMeoF8-HmmctafZ_uOZN-v85O5M8Ka8pBXP+Lg@mail.gmail.com> (raw)
In-Reply-To: <20180409090853.GJ19345-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>

On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
[..]
> 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.

  parent reply	other threads:[~2018-04-09 15:38 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-08  2:47 [PATCH v2 0/3] resource: Use list_head to link sibling resource Baoquan He
2018-04-08  2:47 ` [PATCH v2 1/3] " Baoquan He
2018-04-08  2:47   ` Baoquan He
2018-04-08  2:47   ` Baoquan He
2018-04-08  2:47   ` Baoquan He
2018-04-08  4:12   ` kbuild test robot
2018-04-08  4:12     ` kbuild test robot
2018-04-08  4:12     ` kbuild test robot
2018-04-08  4:12     ` kbuild test robot
2018-04-08  9:09     ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  5:55   ` kbuild test robot
2018-04-08  5:55     ` kbuild test robot
2018-04-08  5:55     ` kbuild test robot
2018-04-08  5:55     ` kbuild test robot
2018-04-08  9:09     ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-08  9:09       ` Baoquan He
2018-04-09  9:08   ` [PATCH v3 1/3] resource: Use list_head to link resource sibling Baoquan He
2018-04-09  9:08     ` Baoquan He
2018-04-09  9:08     ` Baoquan He
2018-04-09 14:49     ` Rob Herring
2018-04-09 14:49       ` Rob Herring
2018-04-09 14:49       ` Rob Herring
2018-04-09 16:05       ` Nicolas Pitre
2018-04-09 16:05         ` Nicolas Pitre
2018-04-09 16:05         ` Nicolas Pitre
2018-04-09 16:05         ` Nicolas Pitre
2018-04-10 13:44       ` Baoquan He
2018-04-10 13:44         ` Baoquan He
2018-04-10 13:44         ` Baoquan He
2018-04-10 13:44         ` Baoquan He
2018-04-11  3:22         ` Wei Yang
2018-04-11  3:22           ` Wei Yang
2018-04-11  3:22           ` Wei Yang
2018-04-09 15:38     ` Dan Williams [this message]
2018-04-09 15:38       ` Dan Williams
2018-04-09 15:38       ` Dan Williams
2018-04-10  2:10       ` Baoquan He
2018-04-10  2:10         ` Baoquan He
2018-04-10  2:10         ` Baoquan He
2018-04-10  2:10         ` Baoquan He
2018-04-10  2:34         ` Dan Williams
2018-04-10  2:34           ` Dan Williams
2018-04-10  2:34           ` Dan Williams
2018-04-10  2:34           ` Dan Williams
2018-04-10  2:49           ` Baoquan He
2018-04-10  2:49             ` Baoquan He
2018-04-10  2:49             ` Baoquan He
2018-04-10  2:49             ` Baoquan He
2018-04-08  2:47 ` [PATCH v2 2/3] resource: add walk_system_ram_res_rev() Baoquan He
2018-04-08  2:47 ` [PATCH v2 3/3] kexec_file: Load kernel at top of system RAM if required Baoquan He
2018-04-08  2:47   ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPcyv4huU32+oMeoF8-HmmctafZ_uOZN-v85O5M8Ka8pBXP+Lg@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=airlied@linux.ie \
    --cc=baiyaowei@cmss.chinamobile.com \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=devel@linuxdriverproject.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=haiyangz@microsoft.com \
    --cc=jglisse@redhat.com \
    --cc=jonathan.derrick@intel.com \
    --cc=keith.busch@intel.com \
    --cc=kys@microsoft.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=patrik.r.jakobsson@gmail.com \
    --cc=richard.weiyang@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.