linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: remove name from machine_desc for DT platforms
Date: Fri, 15 Nov 2013 10:08:14 -0600	[thread overview]
Message-ID: <528646EE.5000109@gmail.com> (raw)
In-Reply-To: <CAHCPf3tBOvoeK+ibrA4Hc6iUpVBte+B9BL=-3p8rWz9RmHOfcQ@mail.gmail.com>

On 11/14/2013 02:33 PM, Matt Sealey wrote:
> On Sun, Nov 3, 2013 at 2:50 PM, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
> 
> Snip.. I actually reviewed what you're doing since I was
> understandably curious as to what the "plan" is for removing
> machine_desc and how you'd potentially avoid end up stashing global
> variables all over the place for early init code..
> 
>> --- a/arch/arm/kernel/devtree.c
>> +++ b/arch/arm/kernel/devtree.c
>> @@ -199,7 +199,7 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>>         const struct machine_desc *mdesc, *mdesc_best = NULL;
>>
>>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>> -       DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
>> +       DT_MACHINE_START(GENERIC_DT)
>>         MACHINE_END
> 
> This machine doesn't have a .dt_compat so...
> 
>> +               early_print("%08x\t%s\n", p->nr, p->name ? p->name : *p->dt_compat);
> 
> In your case here, isn't this going to print "calxeda,highbank" for
> you right now, with a broken tree, since it's the first in your
> dt_compat list?
> 
> In the generic case, as noted above, the compatibility list usually comes out as
> 
>                          ID (hex)       NAME
>                          :
>                          0xffffffff        Highbank
>                          0xffffffff        Generic DT based system
> 
> But you've made it say:
> 
>                          ID (hex)        NAME
>                          :
>                          0xffffffff         calxeda,highbank
>                          0xffffffff
> 
> You didn't fix your customer issue there, at least, if they're messing
> with their DT and break it ;)

This is not the issue I'm trying to fix as this is a debug early print.
It is what /proc/cpuinfo displays.

I don't think your example is even possible. If we have the default
descriptor enabled (i.e. all multi-platform builds), then we will always
match a machine descriptor and try to continue to boot never reaching
this code path.

>> @@ -859,7 +859,7 @@ void __init setup_arch(char **cmdline_p)
>>         if (!mdesc)
>>                 mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
>>         machine_desc = mdesc;
>> -       machine_name = mdesc->name;
>> +       machine_name = mdesc->name ? mdesc->name : of_flat_dt_get_machine_name();
> 
> Also you missed around line 242 of kernel/devtree.c which prints
> mdesc_best->name;

You are looking at the wrong version. See the DT clean-up that I did
which is in mainline now. This patch is dependent on that.

> 
>         model = of_get_flat_dt_prop(dt_root, "model", NULL);
>         if (!model)
>                 model = of_get_flat_dt_prop(dt_root, "compatible", NULL);
>         if (!model)
>                 model = "<unknown>";
>         pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
> 
> Which is now going to say "Machine: , model: Calxeda Foo Board", isn't it?
> 
> Should just use machine_name, if mdesc_best->name isn't set, shouldn't it?
> 
> I think there's a bunch of weirdness here.. I just checked the PAPR
> and ePAPR specs, and the original IEEE1275 and ARM bindings and
> finding board information like you want from the DT is an unholy
> crapshoot.

Maybe in the past, but we require a root compatible string. If there is
no model property, then the compatible string is the machine name.

> In this case I think we need more information, and to only print it
> once per boot if that's the goal here. Why not make machine_name an
> argument to setup_machine_fdt (or just don't have it be static in
> setup.c) and have that function fill in the right thing rather than
> having a DT parsing function in setup_arch where before it was totally
> boot-method agnostic?

Well, that's an implementation detail. First we have to agree on which
string gets used and where.

Rob

      reply	other threads:[~2013-11-15 16:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-03 20:50 [PATCH v2] ARM: remove name from machine_desc for DT platforms Rob Herring
     [not found] ` < CAOesGMg7Mt+p8U7Z5sLQDqoFG-QEUi94Vt=pxXM0NqyefBLxVA@mail.gmail.com>
2013-11-04 11:36 ` Grant Likely
2013-11-05 14:34   ` Rob Herring
2013-11-05 17:44     ` Matt Sealey
2013-11-11 17:38     ` Olof Johansson
2013-11-13 19:00       ` Rob Herring
2013-11-13 19:21         ` Olof Johansson
2013-11-13 20:04           ` Rob Herring
2013-11-14 12:32             ` Arnd Bergmann
     [not found]               ` < CACxGe6uMWjfmB4WDKs+vu05224jqpbDZBHT_ZXnqxw17JzUqvw@mail.gmail.com>
     [not found]                 ` < 5284E236.1000606@gmail.com>
     [not found]                   ` < CACxGe6sgRwiakJLUCtaaQ2NF51PpkoNZvZr6EoE-BPeZiDsDFQ@mail.gmail.com>
2013-11-14 13:33               ` Grant Likely
2013-11-14 14:46                 ` Rob Herring
2013-11-14 17:16                   ` Grant Likely
2013-11-14 23:17                     ` Rob Herring
2013-11-18 12:59                       ` Grant Likely
2013-11-18 13:54                     ` Russell King - ARM Linux
2013-11-19 13:43                       ` Grant Likely
2013-11-21 23:53                       ` Rob Herring
2013-11-15 19:13                   ` Russell King - ARM Linux
2013-11-15 20:16                     ` Rob Herring
2013-11-15 21:05                       ` Arnd Bergmann
2013-11-14 20:33 ` Matt Sealey
2013-11-15 16:08   ` Rob Herring [this message]

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=528646EE.5000109@gmail.com \
    --to=robherring2@gmail.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;
as well as URLs for NNTP newsgroup(s).