All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
Cc: marc.zyngier@arm.com, tglx@linutronix.de, jason@lakedaemon.net,
	rjw@rjwysocki.net, bhelgaas@google.com,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	hanjun.guo@linaro.org, tomasz.nowicki@linaro.org,
	graeme.gregory@linaro.org, dhdang@apm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support
Date: Thu, 17 Dec 2015 10:57:14 -0600	[thread overview]
Message-ID: <20151217165713.GA23549@localhost> (raw)
In-Reply-To: <56720095.70004@amd.com>

On Wed, Dec 16, 2015 at 06:23:49PM -0600, Suravee Suthikulanit wrote:
> Hi Bjorn,
> 
> Thanks for your review. Please see my comments below.
> 
> On 12/16/2015 4:12 PM, Bjorn Helgaas wrote:
> >On Thu, Dec 10, 2015 at 08:55:29AM -0800, Suravee Suthikulpanit wrote:
> >>This patch replaces the struct device_node with struct fwnode_handle
> >>since this structure is common between DT and ACPI.
> >>
> >>It also refactors gicv2m_init_one() to prepare for ACPI support.
> >>The only functional change is removing the node name from pr_info.
> >>
> >>Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> >>Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> >
> >>@@ -359,10 +355,10 @@ static int __init gicv2m_init_one(struct device_node *node,
> >>  	}
> >>
> >>  	list_add_tail(&v2m->entry, &v2m_nodes);
> >>-	pr_info("Node %s: range[%#lx:%#lx], SPI[%d:%d]\n", node->name,
> >>-		(unsigned long)v2m->res.start, (unsigned long)v2m->res.end,
> >>-		v2m->spi_start, (v2m->spi_start + v2m->nr_spis));
> >>
> >>+	pr_info("range[%#lx:%#lx], SPI[%d:%d]\n",
> >>+		(unsigned long)res->start, (unsigned long)res->end,
> >>+		v2m->spi_start, (v2m->spi_start + v2m->nr_spis));
> >
> >You didn't change this, but I don't think this message has enough
> >context.  It's pretty cryptic all by itself.  It'd be nice if it could
> >at least include a device name, e.g., if you could use dev_info().
> 
> Here is the example of the information printed:
> [    0.000000] GICv2m: range[0xe1180000:0xe1181000], SPI[64:320]
> 
> Basically, the v2m is just an extension of the GIC. Here, we are
> printing the memory range that it is covering, which can be used to
> identify different V2m frame and the associate interrupt range
> (SPI). The node name is not really providing any values. So, we are
> removing it.

I noticed the pr_fmt definition later; that adds some useful context I
didn't know about.  I guess there's no struct device for the GIC?  I
don't see one in struct device_node.  Seems like this piece of
hardware that apparently responds to a memory range *could* have a
struct device, but I'm a little fuzzy on how we handle ACPI and OF
device descriptions in that regard.

I hadn't noticed the memory range part; maybe you could use %pR there?

Just to double-check, there's no off-by-one error in the SPI range, is
there?  The pattern I usually expect is "start, start + nr_items - 1".

I'm just kibbitzing here; this isn't PCI code, and you don't need my
ack, so just consider these as random observations.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support
Date: Thu, 17 Dec 2015 10:57:14 -0600	[thread overview]
Message-ID: <20151217165713.GA23549@localhost> (raw)
In-Reply-To: <56720095.70004@amd.com>

On Wed, Dec 16, 2015 at 06:23:49PM -0600, Suravee Suthikulanit wrote:
> Hi Bjorn,
> 
> Thanks for your review. Please see my comments below.
> 
> On 12/16/2015 4:12 PM, Bjorn Helgaas wrote:
> >On Thu, Dec 10, 2015 at 08:55:29AM -0800, Suravee Suthikulpanit wrote:
> >>This patch replaces the struct device_node with struct fwnode_handle
> >>since this structure is common between DT and ACPI.
> >>
> >>It also refactors gicv2m_init_one() to prepare for ACPI support.
> >>The only functional change is removing the node name from pr_info.
> >>
> >>Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> >>Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> >
> >>@@ -359,10 +355,10 @@ static int __init gicv2m_init_one(struct device_node *node,
> >>  	}
> >>
> >>  	list_add_tail(&v2m->entry, &v2m_nodes);
> >>-	pr_info("Node %s: range[%#lx:%#lx], SPI[%d:%d]\n", node->name,
> >>-		(unsigned long)v2m->res.start, (unsigned long)v2m->res.end,
> >>-		v2m->spi_start, (v2m->spi_start + v2m->nr_spis));
> >>
> >>+	pr_info("range[%#lx:%#lx], SPI[%d:%d]\n",
> >>+		(unsigned long)res->start, (unsigned long)res->end,
> >>+		v2m->spi_start, (v2m->spi_start + v2m->nr_spis));
> >
> >You didn't change this, but I don't think this message has enough
> >context.  It's pretty cryptic all by itself.  It'd be nice if it could
> >at least include a device name, e.g., if you could use dev_info().
> 
> Here is the example of the information printed:
> [    0.000000] GICv2m: range[0xe1180000:0xe1181000], SPI[64:320]
> 
> Basically, the v2m is just an extension of the GIC. Here, we are
> printing the memory range that it is covering, which can be used to
> identify different V2m frame and the associate interrupt range
> (SPI). The node name is not really providing any values. So, we are
> removing it.

I noticed the pr_fmt definition later; that adds some useful context I
didn't know about.  I guess there's no struct device for the GIC?  I
don't see one in struct device_node.  Seems like this piece of
hardware that apparently responds to a memory range *could* have a
struct device, but I'm a little fuzzy on how we handle ACPI and OF
device descriptions in that regard.

I hadn't noticed the memory range part; maybe you could use %pR there?

Just to double-check, there's no off-by-one error in the SPI range, is
there?  The pattern I usually expect is "start, start + nr_items - 1".

I'm just kibbitzing here; this isn't PCI code, and you don't need my
ack, so just consider these as random observations.

Bjorn

  reply	other threads:[~2015-12-17 16:57 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10 16:55 [PATCH v7 0/4] gicv2m: acpi: Add ACPI support for GICv2m MSI Suravee Suthikulpanit
2015-12-10 16:55 ` Suravee Suthikulpanit
2015-12-10 16:55 ` Suravee Suthikulpanit
2015-12-10 16:55 ` [PATCH v7 1/4] acpi: pci: Setup MSI domain for ACPI based pci devices Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-14 15:13   ` Marc Zyngier
2015-12-14 15:13     ` Marc Zyngier
2015-12-14 21:29     ` Rafael J. Wysocki
2015-12-14 21:29       ` Rafael J. Wysocki
2015-12-15  9:52       ` Marc Zyngier
2015-12-15  9:52         ` Marc Zyngier
2015-12-16 22:15   ` Bjorn Helgaas
2015-12-16 22:15     ` Bjorn Helgaas
2015-12-17  0:25     ` Suravee Suthikulanit
2015-12-17  0:25       ` Suravee Suthikulanit
2015-12-17  0:25       ` Suravee Suthikulanit
2015-12-21  3:02   ` Rafael J. Wysocki
2015-12-21  3:02     ` Rafael J. Wysocki
2015-12-10 16:55 ` [PATCH v7 2/4] irqdomain: introduce is_fwnode_irqchip helper Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-10 16:55 ` [PATCH v7 3/4] gicv2m: Refactor to prepare for ACPI support Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-16 22:12   ` Bjorn Helgaas
2015-12-16 22:12     ` Bjorn Helgaas
2015-12-17  0:23     ` Suravee Suthikulanit
2015-12-17  0:23       ` Suravee Suthikulanit
2015-12-17  0:23       ` Suravee Suthikulanit
2015-12-17 16:57       ` Bjorn Helgaas [this message]
2015-12-17 16:57         ` Bjorn Helgaas
2015-12-22 23:04         ` Suravee Suthikulanit
2015-12-22 23:04           ` Suravee Suthikulanit
2015-12-22 23:04           ` Suravee Suthikulanit
2015-12-10 16:55 ` [PATCH v7 4/4] gicv2m: acpi: Introducing GICv2m " Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-10 16:55   ` Suravee Suthikulpanit
2015-12-21  3:04   ` Rafael J. Wysocki
2015-12-21  3:04     ` Rafael J. Wysocki
2015-12-10 17:28 ` [PATCH v7 0/4] gicv2m: acpi: Add ACPI support for GICv2m MSI Hanjun Guo
2015-12-10 17:28   ` Hanjun Guo

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=20151217165713.GA23549@localhost \
    --to=helgaas@kernel.org \
    --cc=Catalin.Marinas@arm.com \
    --cc=bhelgaas@google.com \
    --cc=dhdang@apm.com \
    --cc=graeme.gregory@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    --cc=tomasz.nowicki@linaro.org \
    --cc=will.deacon@arm.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.