public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/4] arm64:thunder: Add initial dts for Cavium Thunder SoC in 2 Node topology.
Date: Fri, 3 Oct 2014 12:19:16 +0100	[thread overview]
Message-ID: <20141003111916.GF26643@leverpostej> (raw)
In-Reply-To: <1411635840-24038-4-git-send-email-ganapatrao.kulkarni@caviumnetworks.com>

On Thu, Sep 25, 2014 at 10:03:58AM +0100, Ganapatrao Kulkarni wrote:
> adding devicetree definition for thunder's 2 node topology.
> Defined cpu-map for all 96 cores of 2 node system.

[...]

> +               CPU0: cpu at 000 {
> +                       device_type = "cpu";
> +                       compatible = "cavium,thunder", "arm,armv8";
> +                       reg = <0x0 0x000>;
> +                       enable-method = "psci";
> +               };
> +               CPU1: cpu at 001 {
> +                       device_type = "cpu";
> +                       compatible = "cavium,thunder", "arm,armv8";
> +                       reg = <0x0 0x001>;
> +                       enable-method = "psci";
> +               };

This is going to take up an awful lot of space.  Perhaps we should follwo ePAPR
and allow for common properties to go in /cpus (as I believe we do for arm). We
might not be able to do that for device_type given how we detect CPU nodes at
present, but we could certainly do it for the enable-method:

---->8----
diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
index cce9524..733b3ed 100644
--- a/arch/arm64/kernel/cpu_ops.c
+++ b/arch/arm64/kernel/cpu_ops.c
@@ -54,7 +54,18 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
  */
 int __init cpu_read_ops(struct device_node *dn, int cpu)
 {
-       const char *enable_method = of_get_property(dn, "enable-method", NULL);
+       const char *enable_method = NULL;
+       of_property_read_string(dn, "enable-method", &enable_method);
+
+       if (!enable_method) {
+               /*
+                * Perhaps we have a common /cpus/enable-method
+                */
+               struct device_node *cpus = of_get_parent(dn);
+               of_property_read_string(cpus, "enable-method", &enable_method);
+               of_node_put(cpus);
+       }
+
        if (!enable_method) {
                /*
                 * The boot CPU may not have an enable method (e.g. when
---->8----

I don't believe we check the compatible string at the moment, so that should be
safe to make common too.

Mark.

  reply	other threads:[~2014-10-03 11:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-25  9:03 [RFC PATCH 0/4] arm64:numa: Add numa support for arm64 platforms Ganapatrao Kulkarni
2014-09-25  9:03 ` [RFC PATCH 1/4] arm64: defconfig: increase NR_CPUS range to 2-128 Ganapatrao Kulkarni
2014-10-03 10:58   ` Mark Rutland
2014-10-06  4:29     ` Ganapatrao Kulkarni
2014-09-25  9:03 ` [RFC PATCH 2/4] arm/arm64:dt:numa: adding numa node mapping for memory nodes Ganapatrao Kulkarni
2014-10-03 11:05   ` Mark Rutland
2014-10-06  4:20     ` Ganapatrao Kulkarni
2014-10-06 11:08       ` Mark Rutland
2014-10-06 17:26         ` Ganapatrao Kulkarni
2014-09-25  9:03 ` [RFC PATCH 3/4] arm64:thunder: Add initial dts for Cavium Thunder SoC in 2 Node topology Ganapatrao Kulkarni
2014-10-03 11:19   ` Mark Rutland [this message]
2014-09-25  9:03 ` [RFC PATCH 4/4] arm64:numa: adding numa support for arm64 platforms Ganapatrao Kulkarni
2014-10-03 12:13   ` Mark Rutland
2014-10-06  5:14     ` Ganapatrao Kulkarni
2014-10-06 11:26       ` Mark Rutland
2014-10-06 17:52         ` Ganapatrao Kulkarni
2014-10-17 17:19           ` Ganapatrao Kulkarni
2014-10-20 14:25             ` Steve Capper
2014-10-20 14:30               ` Steve Capper
2014-10-22 11:27                 ` Ganapatrao Kulkarni
2014-10-28  8:48             ` Hanjun Guo
2014-10-29  7:20               ` Ganapatrao Kulkarni
2014-09-25  9:04 ` Ganapatrao Kulkarni

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=20141003111916.GF26643@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox