xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Andre Przywara <andre.przywara@linaro.org>
Cc: stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] ARM/multiboot: use more flexible node naming
Date: Fri, 06 Sep 2013 12:11:29 +0100	[thread overview]
Message-ID: <5229B861.8080000@linaro.org> (raw)
In-Reply-To: <1378388623-9853-1-git-send-email-andre.przywara@linaro.org>

Hi,

I have also modified this function with my patch series "Allow Xen to 
boot with a raw Device Tree". Can you rebase this patch on top of this 
serie?

Other comments below.

On 09/05/2013 02:43 PM, Andre Przywara wrote:
> For the current "multiboot" on ARM support we look for a compatible
> string of "xen,multiboot-module" in the device tree, and then
> use "xen,linux-zimage" and "xen,linux-initrd" to differentiate
> between the two supported module types.
> To meet the more generic multiboot proposal in the device tree [1],
> allow Xen to be more flexible in the compatible naming and also use
> the new generic base name "boot,module".
> The mapping to either Dom0 kernel or RAM disk works either by
> providing a more specific name ("xen,dom0-kernel" and "xen,ramdisk"),
> or by using the enumeration order of the device tree nodes
> (module@0 = kernel, module@1 = initrd). This allows bootloaders
> without any specific Xen knowledge to boot Xen anyways.

The ePAR (section 2.2.1) requires the unit-address (name@unit-address) 
to match the first address of the "reg" property. I think, with this 
solution we doesn't comply to the specification.

If the bootloader is able to add "boot,kernel" and "boot,initramfs" to 
the compatible property, we should have a generic solution for multiboot.

> [1] http://lists.xen.org/archives/html/xen-devel/2013-09/msg00083.html
>
> Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
> ---
>   xen/common/device_tree.c | 57 ++++++++++++++++++++++++++++++++++++++++++------
>   1 file changed, 50 insertions(+), 7 deletions(-)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index ec0d5e2..e10c035 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -439,22 +439,63 @@ static void __init process_cpu_node(const void *fdt, int node,
>       cpumask_set_cpu(start, &cpu_possible_map);
>   }
>
> +static const char * const kernel_module_names[] = {
These variable are only used durint the initialization, you should add 
__initconst.

> +	"xen,linux-zimage",
> +	"xen,dom0-kernel",
> +	"boot,kernel",
> +	NULL

Xen uses spaces instead of tabulations.

> +};
> +
> +static const char * const initrd_module_names[] = {

__initconst

> +	"xen,linux-initrd",
> +	"xen,ramdisk",
> +	"boot,ramdisk",
> +	NULL

tabulations

> +};
> +
>   static void __init process_multiboot_node(const void *fdt, int node,
>                                             const char *name,
>                                             u32 address_cells, u32 size_cells)
>   {
>       const struct fdt_property *prop;
>       const u32 *cell;
> -    int nr;
> +    int nr = -1;
>       struct dt_mb_module *mod;
>       int len;
> +    const char* const * name_list;
>
> -    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
> -        nr = MOD_KERNEL;
> -    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") == 0)
> -        nr = MOD_INITRD;
> -    else
> -        early_panic("%s not a known xen multiboot type\n", name);
> +    for (name_list = kernel_module_names; *name_list != NULL; name_list++)

the coding style for "for" is for ( ... )

> +        if ( fdt_node_check_compatible(fdt, node, *name_list) == 0 ) {

newline before {

> +            nr = MOD_KERNEL;
> +            break;
> +        }
> +
> +    for (name_list = initrd_module_names; *name_list != NULL; name_list++)

for ( ... )

> +        if ( fdt_node_check_compatible(fdt, node, *name_list) == 0 ) {

newline before {

> +            nr = MOD_INITRD;
> +            break;
> +        }
> +
> +    if (nr == -1) {

newline before {

> +    	char *s;

there is a tabulation here.

> +
> +        if ( fdt_node_check_compatible(fdt, node, "boot,module") != 0 ) {

newline before {

> +            early_panic("%s not a known xen multiboot type\n", name);

early_panic is a bit tough, can we simply ignore the node?

> +            return;
> +        }
> +        s = strchr(name, '@');
> +        if (s == NULL)

if ( ... )

> +            nr = early_info.modules.nr_mods + 1;
> +        else {

newline before {

> +            nr = simple_strtoll(s + 1, NULL, 10) + 1;
> +        }
> +    }
> +
> +    if (nr >= NR_MODULES) {

if ( ... )

You should also check nr < 0. Strtoll could return a negative value.

> +        early_panic("only supporting %d multiboot modules\n",
> +            NR_MODULES - MOD_DISCARD_FIRST);

indentation here.

> +        return;
> +    }
>
>       mod = &early_info.modules.module[nr];
>
> @@ -492,6 +533,8 @@ static int __init early_scan_node(const void *fdt,
>           process_cpu_node(fdt, node, name, address_cells, size_cells);
>       else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) )
>           process_multiboot_node(fdt, node, name, address_cells, size_cells);
> +    else if ( device_tree_node_compatible(fdt, node, "boot,module" ) )
> +        process_multiboot_node(fdt, node, name, address_cells, size_cells);

Do we consider the multiboot node can live outside /chosen?

>
>       return 0;
>   }
>


-- 
Julien Grall

  parent reply	other threads:[~2013-09-06 11:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 13:43 [PATCH] ARM/multiboot: use more flexible node naming Andre Przywara
2013-09-05 13:54 ` Egger, Christoph
2013-09-05 14:03   ` Ian Campbell
2013-09-05 14:22     ` Egger, Christoph
2013-09-05 14:59       ` Ian Campbell
2013-09-06  8:44         ` Andre Przywara
2013-09-06 11:11 ` Julien Grall [this message]
2013-09-09 13:52   ` Andre Przywara
2013-09-09 12:00 ` Ian Campbell
2013-09-09 14:01   ` Andre Przywara

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=5229B861.8080000@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=andre.przywara@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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).