[U-Boot-Users] [RFC][PATCH] fdt fixup
This code adds a generic fixup mechanism that allows us to get ride of needing explicit paths to device nodes.
diff --git a/common/fdt_support.c b/common/fdt_support.c index 7a81469..2c1e8ac 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -363,4 +363,125 @@ int fdt_bd_t(void *fdt) } #endif /* ifdef CONFIG_OF_HAS_BD_T */
+/* + * "Setter" functions used to add/modify FDT entries. + */ +#ifdef CONFIG_HAS_ETH0 +static int fdt_set_eth0(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + /* Fix it up if it exists, don't create it if it doesn't exist */ + if (fdt_get_property(blob, nodeoffset, name, 0)) { + return fdt_setprop(blob, nodeoffset, name, bd->bi_enetaddr, 6); + } + return 0; +} +#endif +#ifdef CONFIG_HAS_ETH1 +/* second onboard ethernet port */ +static int fdt_set_eth1(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + /* Fix it up if it exists, don't create it if it doesn't exist */ + if (fdt_get_property(blob, nodeoffset, name, 0)) { + return fdt_setprop(blob, nodeoffset, name, bd->bi_enet1addr, 6); + } + return 0; +} +#endif +#ifdef CONFIG_HAS_ETH2 +/* third onboard ethernet port */ +static int fdt_set_eth2(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + /* Fix it up if it exists, don't create it if it doesn't exist */ + if (fdt_get_property(blob, nodeoffset, name, 0)) { + return fdt_setprop(blob, nodeoffset, name, bd->bi_enet2addr, 6); + } + return 0; +} +#endif +#ifdef CONFIG_HAS_ETH3 +/* fourth onboard ethernet port */ +static int fdt_set_eth3(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + /* Fix it up if it exists, don't create it if it doesn't exist */ + if (fdt_get_property(blob, nodeoffset, name, 0)) { + return fdt_setprop(blob, nodeoffset, name, bd->bi_enet3addr, 6); + } + return 0; +} +#endif + +static int fdt_set_busfreq(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + u32 tmp; + /* Create or update the property */ + tmp = cpu_to_be32(bd->bi_busfreq); + return fdt_setprop(blob, nodeoffset, name, &tmp, sizeof(tmp)); +} + +static int fdt_set_tbfreq(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + u32 tmp; + /* Create or update the property */ + tmp = cpu_to_be32(bd->bi_busfreq / 8); + return fdt_setprop(blob, nodeoffset, name, &tmp, sizeof(tmp)); +} + +static int fdt_set_stdout_path(void *blob, int nodeoffset, const char *name, bd_t *bd) +{ + char buf[256]; + int err, off; + + off = fdt_path_offset(blob, "/chosen"); + if (off < 0) + return off; + + err = fdt_get_path(blob, nodeoffset, &buf, 256); + if (err < 0) + return err; + + err = fdt_setprop(blob, off, "linux,stdout-path", buf, err + 1); + + return err; +} + +/* + * Fixups to the fdt. + */ + +void fdt_fixups(struct fdt_fixup *tbl, int num, void *blob, bd_t *bd) +{ + int j, err, off; + + for (j = 0; j < num; j++) { + off = -1; + do { + if (tbl[j].compat) + off = fdt_node_offset_by_prop_and_compat(blob, + off, tbl[j].compat, "device_type", + tbl[j].type, strlen(tbl[j].type) + 1); + else + off = fdt_node_offset_by_prop_value(blob, off, + "device_type", + tbl[j].type, strlen(tbl[j].type) + 1); + + if (off >= 0) { + if (tbl[j].name) { + int len; + const char *name; + + name = fdt_get_name(blob, off, &len); + if (strncmp(name, tbl[j].name, len) != 0) + continue; + } + + err = tbl[j].set_fn(blob, off, tbl[j].prop, bd); + if (err < 0) + debug("Problem setting %s = %s: %s\n", + tbl[j].node, tbl[j].prop, + fdt_strerror(err)); + } + } while (off >= 0); + } +} + #endif /* CONFIG_OF_LIBFDT */ diff --git a/include/fdt_support.h b/include/fdt_support.h index 60fa423..f66e562 100644 --- a/include/fdt_support.h +++ b/include/fdt_support.h @@ -28,7 +28,18 @@
#include <fdt.h>
+typedef int (*set_fn_t)(void *blob, int nodeoffset, const char *name, bd_t *bd); + +struct fdt_fixup { + const char *type; + const char *compat; + const char *prop; + const char *name; + set_fn_t set_fn; +}; + int fdt_chosen(void *fdt, ulong initrd_start, ulong initrd_end, int force); +void fdt_fixups(struct fdt_fixup *tbl, int num, void *blob, bd_t *bd);
#ifdef CONFIG_OF_HAS_UBOOT_ENV int fdt_env(void *fdt);
Kumar Gala wrote:
This code adds a generic fixup mechanism that allows us to get ride of needing explicit paths to device nodes.
diff --git a/common/fdt_support.c b/common/fdt_support.c index 7a81469..2c1e8ac 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -363,4 +363,125 @@ int fdt_bd_t(void *fdt) } #endif /* ifdef CONFIG_OF_HAS_BD_T */
+/*
- "Setter" functions used to add/modify FDT entries.
- */
+#ifdef CONFIG_HAS_ETH0 +static int fdt_set_eth0(void *blob, int nodeoffset, const char *name, bd_t *bd) +{
- /* Fix it up if it exists, don't create it if it doesn't exist */
- if (fdt_get_property(blob, nodeoffset, name, 0)) {
return fdt_setprop(blob, nodeoffset, name, bd->bi_enetaddr, 6);- }
- return 0;
+}
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
Best regards, gvb
P.S. Is David done changing libfdt yet??? ;-) I saw you are still keeping up with him...
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
The other option is to extend what Grant has.
Today its:
do_fixup_path(fdt, path, prop, val, len, create) do_fixup_path_u32(fdt, path, prop, val, create)
Add:
do_fixup_prop(fdt, find_prop, find_propval, findlen, prop, val, len, create) do_fixup_prop_u32(fdt, find_prop, find_propval, findlen, prop, val, create) do_fixup_compat(fdt, compat, prop, val, len, create) do_fixup_compat_u32(fdt, compat, prop, val, create) do_fixup_prop_and_compat(fdt, find_prop, find_proval, findlen, compat, prop, val, len, create) do_fixup_prop_and_compat_u32(fdt, find_prop, find_proval, findlen, compat, prop, val, create)
We get something like "do_fixup_device_type" by do_fixup_prop(fdt, "device_type", ...)
P.S. Is David done changing libfdt yet??? ;-) I saw you are still keeping up with him...
Not sure, as jdl commits things I reimport and update.
- k
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
Yes, I agree. The hard coded paths are stinky. Looking for device_type or compatible might be better.
However, even with using some combination of property values, figuring out which device is which is still a problem. (ie, which network device is eth0 and which is eth1?). Relying on the implicit order in the device tree is just as fragile as using the full path. At least with using the full path, you don't run the risk of getting the wrong node (you just don't find the node at all).
I agree with dwg in that I think embedding a "node-index" or similar property into the node is not a good solution. This may be yet another situation where an aliases node would be a good solution. Have the aliases node populated with the device enumeration (ie. eth0 mapped to "/full/path/to/ethernet@addr") an allow either a full path to be specified or an alias.
Cheers, g.
On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
Yes, I agree. The hard coded paths are stinky. Looking for device_type or compatible might be better.
However, even with using some combination of property values, figuring out which device is which is still a problem. (ie, which network device is eth0 and which is eth1?). Relying on the implicit order in the device tree is just as fragile as using the full path. At least with using the full path, you don't run the risk of getting the wrong node (you just don't find the node at all).
I wasn't thinking of using implicit order, We can use reg or the node name in addition to compat.
So something like: do_fixup_by_compat_and_name(blob, "gianfar", "ethernet@24000", "mac- address", bd->bi_enetaddr, 6) do_fixup_by_compat_and_name(blob, "gianfar", "ethernet@25000", "mac- address", bd->bi_enet1addr, 6) do_fixup_by_compat_and_name(blob, "gianfar", "ethernet@26000", "mac- address", bd->bi_enet2addr, 6)
or something like: u32 reg_buf[2]; reg_buf[0] = cpu_to_fdt32(0x24000); reg_buf[1] = cpu_to_fdt32(0x1000); do_fixup_by_compat_and_prop(blob, "gianfar", "reg", ®_buf, 8, "mac-address", bd->bi_enetaddr, 6)
reg_buf[0] = cpu_to_fdt32(0x25000); do_fixup_by_compat_and_prop(blob, "gianfar", "reg", ®_buf, 8, "mac-address", bd->bi_enet1addr, 6)
reg_buf[0] = cpu_to_fdt32(0x26000); do_fixup_by_compat_and_prop(blob, "gianfar", "reg", ®_buf, 8, "mac-address", bd->bi_enet2addr, 6)
- k
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
Yes, I agree. The hard coded paths are stinky. Looking for device_type or compatible might be better.
However, even with using some combination of property values, figuring out which device is which is still a problem. (ie, which network device is eth0 and which is eth1?). Relying on the implicit order in the device tree is just as fragile as using the full path. At least with using the full path, you don't run the risk of getting the wrong node (you just don't find the node at all).
I wasn't thinking of using implicit order, We can use reg or the node name in addition to compat.
Ah, okay. I wasn't sure if name was optional in your last email.
However, if name is specified does compatible even matter?
Or, on the other hand, is name specific enough? For example; is it still possible to wire up two 82xx chips back to back and have one CPU control both socs? In which case you could end up with 2 identical devices with identical node names in the tree.
Cheers, g.
On Nov 1, 2007, at 11:55 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
Yes, I agree. The hard coded paths are stinky. Looking for device_type or compatible might be better.
However, even with using some combination of property values, figuring out which device is which is still a problem. (ie, which network device is eth0 and which is eth1?). Relying on the implicit order in the device tree is just as fragile as using the full path. At least with using the full path, you don't run the risk of getting the wrong node (you just don't find the node at all).
I wasn't thinking of using implicit order, We can use reg or the node name in addition to compat.
Ah, okay. I wasn't sure if name was optional in your last email.
However, if name is specified does compatible even matter?
Or, on the other hand, is name specific enough? For example; is it still possible to wire up two 82xx chips back to back and have one CPU control both socs? In which case you could end up with 2 identical devices with identical node names in the tree.
If you have one cpu controller things will have different reg props than.
Name is one way to distinguish. For a given board you're going to know some level of detail about the setup such that you can choose the best mechanism to match on.
- k
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 1, 2007, at 11:55 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
Yes, I agree. The hard coded paths are stinky. Looking for device_type or compatible might be better.
However, even with using some combination of property values, figuring out which device is which is still a problem. (ie, which network device is eth0 and which is eth1?). Relying on the implicit order in the device tree is just as fragile as using the full path. At least with using the full path, you don't run the risk of getting the wrong node (you just don't find the node at all).
I wasn't thinking of using implicit order, We can use reg or the node name in addition to compat.
Ah, okay. I wasn't sure if name was optional in your last email.
However, if name is specified does compatible even matter?
Or, on the other hand, is name specific enough? For example; is it still possible to wire up two 82xx chips back to back and have one CPU control both socs? In which case you could end up with 2 identical devices with identical node names in the tree.
If you have one cpu controller things will have different reg props than.
If you have two identical SoCs back-to-back, the soc nodes will have different ranges, but the device nodes themselves will be pretty much identical. You'd need to parse all the ranges properties to get a real physaddr before you as sure to get a unique addr.
Name is one way to distinguish. For a given board you're going to know some level of detail about the setup such that you can choose the best mechanism to match on.
Possibly true; but I am concerned that it just trades one fragile method (strict path) for another (expected differences between nodes for identical devices in the tree)
Cheers, g.
Ah, okay. I wasn't sure if name was optional in your last email.
However, if name is specified does compatible even matter?
Or, on the other hand, is name specific enough? For example; is it still possible to wire up two 82xx chips back to back and have one CPU control both socs? In which case you could end up with 2 identical devices with identical node names in the tree.
If you have one cpu controller things will have different reg props than.
If you have two identical SoCs back-to-back, the soc nodes will have different ranges, but the device nodes themselves will be pretty much identical. You'd need to parse all the ranges properties to get a real physaddr before you as sure to get a unique addr.
True, we probably need an of_translate_addr() equivalent.
Name is one way to distinguish. For a given board you're going to know some level of detail about the setup such that you can choose the best mechanism to match on.
Possibly true; but I am concerned that it just trades one fragile method (strict path) for another (expected differences between nodes for identical devices in the tree)
Yeah, I guess the best one can do is leave it up to the developer to pick the right method. Its not as if we'd get ride of explicit path fixups.
The idea of aliases is looking more and more appealing to me.
- k
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
Possibly true; but I am concerned that it just trades one fragile method (strict path) for another (expected differences between nodes for identical devices in the tree)
Yeah, I guess the best one can do is leave it up to the developer to pick the right method. Its not as if we'd get ride of explicit path fixups.
The idea of aliases is looking more and more appealing to me.
Indeed.
It also an area where device_type might actually be a useful property if it is used to auto enumerate devices of the same type. ie. If the dtb doesn't explicitly specify eth* aliases, then u-boot could enumerate them so that generic fixup routines can be used and so Linux (or other OS) can use the same device numbering as u-boot.
Cheers, g.
Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
Possibly true; but I am concerned that it just trades one fragile method (strict path) for another (expected differences between nodes for identical devices in the tree)
Yeah, I guess the best one can do is leave it up to the developer to pick the right method. Its not as if we'd get ride of explicit path fixups.
The idea of aliases is looking more and more appealing to me.
Indeed.
It also an area where device_type might actually be a useful property if it is used to auto enumerate devices of the same type. ie. If the dtb doesn't explicitly specify eth* aliases, then u-boot could enumerate them so that generic fixup routines can be used and so Linux (or other OS) can use the same device numbering as u-boot.
sorry... in chosen-node select defaults, for example?
On 11/2/07, Sergej Stepanov Sergej.Stepanov@ids.de wrote:
Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
It also an area where device_type might actually be a useful property if it is used to auto enumerate devices of the same type. ie. If the dtb doesn't explicitly specify eth* aliases, then u-boot could enumerate them so that generic fixup routines can be used and so Linux (or other OS) can use the same device numbering as u-boot.
sorry... in chosen-node select defaults, for example?
I don't understand what you mean or are asking, but let me clarify what I mean.
I'm not talking about selected defaults; but about device enumeration (which is similar, but not exactly the same thing). If there is a class of devices which is typically enumerated (like ethernet devices), then the device_type property *might* be useful because it would allow firmware to find all devices of a similar type and assign numbers to them.
Also, OF has an 'aliases' mechanism defined which could be very useful. The '/aliases' node contains a set of properties which assign a set of 'simple' names to the full path of a node. For example, on the efika, /aliases looks like this:
ok cd /aliases ok .properties name "aliases" eth "/builtin/ethernet" ok
Now; for our purposes, using name->full_path mapping is probably sub-optimal and name->phandle might be better. But regardless, the alias can be used as a shortcut to refer to a particular node. For example, on the efika:
ok cd / ok cd eth ok pwd /builtin@F0000000/ethernet@F0003000 ok
So, if the aliases node was populated with common names, or if u-boot could auto-populate the /aliases node with enumerated values for things like 'eth#' and 'serial#', then we could do something like this for fixups:
do_fixup_by_name(blob, "eth0", "mac-address", bd->bi_enetaddr, 6) do_fixup_by_name(blob, "eth1", "mac-address", bd->bi_enet1addr, 6) do_fixup_by_name(blob, "eth2", "mac-address", bd->bi_enet2addr, 6)
Which will work for *any* board, regardless of where the ethernet nodes are in the tree.
Cheers, g.
On Nov 2, 2007, at 10:47 AM, Grant Likely wrote:
On 11/2/07, Sergej Stepanov Sergej.Stepanov@ids.de wrote:
Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
It also an area where device_type might actually be a useful property if it is used to auto enumerate devices of the same type. ie. If the dtb doesn't explicitly specify eth* aliases, then u-boot could enumerate them so that generic fixup routines can be used and so Linux (or other OS) can use the same device numbering as u-boot.
sorry... in chosen-node select defaults, for example?
I don't understand what you mean or are asking, but let me clarify what I mean.
I'm not talking about selected defaults; but about device enumeration (which is similar, but not exactly the same thing). If there is a class of devices which is typically enumerated (like ethernet devices), then the device_type property *might* be useful because it would allow firmware to find all devices of a similar type and assign numbers to them.
Also, OF has an 'aliases' mechanism defined which could be very useful. The '/aliases' node contains a set of properties which assign a set of 'simple' names to the full path of a node. For example, on the efika, /aliases looks like this:
ok cd /aliases ok .properties name "aliases" eth "/builtin/ethernet" ok
Now; for our purposes, using name->full_path mapping is probably sub-optimal and name->phandle might be better. But regardless, the alias can be used as a shortcut to refer to a particular node. For example, on the efika:
ok cd / ok cd eth ok pwd /builtin@F0000000/ethernet@F0003000 ok
So, if the aliases node was populated with common names, or if u-boot could auto-populate the /aliases node with enumerated values for things like 'eth#' and 'serial#', then we could do something like this for fixups:
I dont see how u-boot could auto-populate, that seems to defeat the purpose of aliases.
- k
On 11/3/07, Kumar Gala galak@kernel.crashing.org wrote:
So, if the aliases node was populated with common names, or if u-boot could auto-populate the /aliases node with enumerated values for things like 'eth#' and 'serial#', then we could do something like this for fixups:
I dont see how u-boot could auto-populate, that seems to defeat the purpose of aliases.
As I said, it *might* make sense. :-)
I'm thinking in terms of if aliases are provided then use them. But that doesn't preclude u-boot assigning aliases to device nodes that don't have them.
Cheers, g.
participants (5)
-
Grant Likely -
gvb.uboot -
Jon Loeliger -
Kumar Gala -
Sergej Stepanov