[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/8] device tree: correctly ignore unit-address when matching nodes by name



On Tue, 2012-02-28 at 16:54 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@xxxxxxxxxx>
> 
> When matching node by their name, correctly ignore the unit address
> (@...) part of the name.  Previously, a "memory-controller" node would
> be incorrectly matched as a "memory" node.

Are we reinventing this ourselves or is this derived from the Linux (or
other) version of similar code?

> 
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> ---
>  xen/common/device_tree.c |   19 +++++++++++++++----
>  1 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index d50cb9c..e5df748 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -24,6 +24,20 @@
>  struct dt_early_info __initdata early_info;
>  void *device_tree_flattened;
>  
> +static bool_t __init node_matches(const void *fdt, int node, const char 
> *match)
> +{
> +    const char *name;
> +    size_t len;
> +
> +    name = fdt_get_name(fdt, node, NULL);
> +    len = strlen(match);
> +
> +    /* Match both "match" and "match@..." patterns but not
> +       "match-foo". */
> +    return strncmp(name, match, len) == 0
> +        && (name[len] == '@' || name[len] == '\0');

How can name[len] == '@' when len came from strlen? Wouldn't you need
some sort of strchr construct?

Oh, I see, it's strlen(match) not strlen(name) and the short-curcuiting
behaviour of && protects you from the case where strlen(match) >
strlen(name) because the strncmp will fail so name[len] won't be
evaluated.

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

> +}
> +
>  static void __init get_val(const u32 **cell, u32 cells, u64 *val)
>  {
>      *val = 0;
> @@ -93,13 +107,10 @@ static void __init early_scan(const void *fdt)
>  {
>      int node;
>      int depth;
> -    const char *name;
>      u32 address_cells[MAX_DEPTH];
>      u32 size_cells[MAX_DEPTH];
>  
>      for (node = 0; depth >= 0; node = fdt_next_node(fdt, node, &depth)) {
> -        name = fdt_get_name(fdt, node, NULL);
> -
>          if (depth >= MAX_DEPTH) {
>              early_printk("fdt: node '%s': nested too deep\n",
>                           fdt_get_name(fdt, node, NULL));
> @@ -109,7 +120,7 @@ static void __init early_scan(const void *fdt)
>          address_cells[depth] = prop_by_name_u32(fdt, node, "#address-cells");
>          size_cells[depth] = prop_by_name_u32(fdt, node, "#size-cells");
>  
> -        if (strncmp(name, "memory", 6) == 0)
> +        if (node_matches(fdt, node, "memory"))
>              process_memory_node(fdt, node, address_cells[depth-1], 
> size_cells[depth-1]);
>      }
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.