All of lore.kernel.org
 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 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.