On Tue, May 24, 2016 at 04:09:58AM -0400, Robert P. J. Day wrote:
>
> first, a question about some code in drivers/of/base.c:
>
> void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
> {
> struct property *pp;
>
> of_aliases = of_find_node_by_path("/aliases");
> of_chosen = of_find_node_by_path("/chosen");
> if (of_chosen == NULL)
> of_chosen = of_find_node_by_path("/chosen@0");
>
> if (of_chosen) {
> /* linux,stdout-path and /aliases/stdout are for legacy compatibility */
> const char *name = of_get_property(of_chosen, "stdout-path", NULL);
> if (!name)
> name = of_get_property(of_chosen, "linux,stdout-path", NULL);
> if (IS_ENABLED(CONFIG_PPC) && !name)
> name = of_get_property(of_aliases, "stdout", NULL);
> if (name)
> of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
> }
> ... snip ...
>
> i can see up there that, first, "/chosen@0" is clearly an equivalent
> name (for backward compatibility?) for the "chosen" node, but if i
> scan the current kernel source tree, it seems absolutely no one is
> using it:
>
> $ grep -r "chosen@0" *
> arch/powerpc/boot/oflib.c: chosen = of_finddevice("/chosen@0");
> arch/microblaze/kernel/prom.c: strcmp(uname, "chosen@0") == 0)) {
> drivers/of/base.c: of_chosen = of_find_node_by_path("/chosen@0");
> drivers/of/fdt.c: offset = fdt_path_offset(fdt, "/chosen@0");
> drivers/of/fdt.c: (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
> $
>
> if this is a deprecated name for that node, now would seem to be a
> good time to toss it before someone gets a chance to resurrect it.
There are existing DTBs which are not in the kernel source tree (e.g.
where provided by FW on PPC platforms), which we support.
Just because a construct does not exist in an in-tree dts does not mean
we can remove support for it.
> next (and in the same vein), the kernel code in
> drivers/cpufreq/cpufreq-dt.c accepts the older style property name
> "cpu0-supply":
>
> /* Try "cpu0" for older DTs */
> if (!cpu) {
> pp = of_find_property(np, "cpu0-supply", NULL);
> if (pp) {
> name = "cpu0";
> goto node_put;
> }
> }
>
> pp = of_find_property(np, "cpu-supply", NULL);
> if (pp) {
> name = "cpu";
> goto node_put;
> }
>
> strangely(?), the *only* architecture that still uses the older name
> in .dts and .dtsi files is ARM, where that property name is used quite
> extensively. is there something about ARM that seems to want to hang
> onto that older property name? just curious.
I suspect it was developeed on ARM platforms first, and no-one has
modified the dts files. As above, even if we did we would have to retain
the support code.
> finally (for now), is there any reason to use numeric phandles
> rather than labels? i ask since someone responsible for putting
> together DTS files for a group of us handed us perfectly working
> iles, but they make use of numeric phandles:
>
> i2c@3000 {
> device_type = "i2c";
> compatible = "fsl-i2c";
> reg = <0x3000 0x100>;
> interrupts = <0xe 0x8>;
> interrupt-parent = <700>;
> dfsrr;
> };
>
> ... snip ...
>
> pic@700 {
> linux,phandle = <700>;
>
> is there any reason to use (in this case) the phandle of "700", rather
> than just adding a label to the pic@700 node and using that label?
There is no reason to if writing a dts file. Note that there are caveats
for _decompiled_ DTBs below!
> i'm not sure why someone would *prefer* to use numeric phandles.
I would guess that these dts files have simply been decompiled at some
stage.
Compiling dts to dtb results in each label being allocated a phandle,
and all references to that label being replaced with that phandle. Note
that this is a lossy process: the label text is lost, and there is no
metadata associated with wach phandle reference.
When decompiling from dtb to dts, we do not have sufficient information
to identify all phandle references (as they are just cells without any
special metadata), so must retain the specific phandle values such that
when re-compiling we don't break things.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
