* cpu of_node links broken
@ 2017-04-05 6:12 Wesley Terpstra
[not found] ` <CAMgXwThQk=3V1HQ8YpoY57mpY0SrdyfAwS5szpsqwkS-r=FPAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Wesley Terpstra @ 2017-04-05 6:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt, devicetree-u79uwXL29TY76Z2rM5mHXA
In commit 5590f3196b293574a12be58d06d5e1120d8856ec symlinks from
devices to their OF node were added. Unfortunately, the code looks for
them in cpu_dev_init before they exist (of_core_init has not run).
This results in:
[ 0.010000] cpu cpu0: Error -2 creating of_node link
I don't know if this code used to work and it got broken, but as of
4.6 it does not work and still does not work in 4.11. Moving
of_core_init() before platform_bus_init() in driver_init()
[drivers/base/init.c] fixes the problem for me.
Is there any downside to reordering these function calls?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cpu of_node links broken
[not found] ` <CAMgXwThQk=3V1HQ8YpoY57mpY0SrdyfAwS5szpsqwkS-r=FPAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-04-05 6:41 ` Benjamin Herrenschmidt
[not found] ` <1491374467.4166.81.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-05 6:41 UTC (permalink / raw)
To: Wesley Terpstra, devicetree-u79uwXL29TY76Z2rM5mHXA
On Tue, 2017-04-04 at 23:12 -0700, Wesley Terpstra wrote:
> In commit 5590f3196b293574a12be58d06d5e1120d8856ec symlinks from
> devices to their OF node were added.
Yup. I did that ;)
> Unfortunately, the code looks for them in cpu_dev_init before they
> exist (of_core_init has not run).
> This results in:
> [ 0.010000] cpu cpu0: Error -2 creating of_node link
>
> I don't know if this code used to work and it got broken, but as of
> 4.6 it does not work and still does not work in 4.11. Moving
> of_core_init() before platform_bus_init() in driver_init()
> [drivers/base/init.c] fixes the problem for me.
>
> Is there any downside to reordering these function calls?
Interesting. I've never seen that error, I wonder if that's because
we fail to link the CPU to an OF node to begin with on our platforms.
I agree though. of_core_init() should probably be called before
we create any device that might have an OF node reference.
In fact we should probably be able to move it right before
platform_bus_init(). Something like this (untested):
[PATCH] drivers/base: Initialize OF sysfs core before creating devices
Devices might try to create symlinks to device-tree nodes,
thus all devices that have OF node linkages should be created
after of_core_init() has been called.
This especially includes cpu_dev_init().
Reported-by: Wesley Terpstra <wesley-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
Signed-off-when-somebody-tests-it-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
diff --git a/drivers/base/init.c b/drivers/base/init.c
index 48c0e22..f65d686 100644
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -28,6 +28,13 @@ void __init driver_init(void)
firmware_init();
hypervisor_init();
+ /*
+ * This relies on the firmware_kobj already existing
+ * and should be done before any device that might have
+ * an OF link is created
+ */
+ of_core_init();
+
/* These are also core pieces, but must come after the
* core core pieces.
*/
@@ -35,5 +42,4 @@ void __init driver_init(void)
cpu_dev_init();
memory_dev_init();
container_dev_init();
- of_core_init();
}
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: cpu of_node links broken
[not found] ` <1491374467.4166.81.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
@ 2017-04-05 6:49 ` Wesley Terpstra
[not found] ` <CAMgXwThRqAO0vG0QVC7LYO2Srf9inh+osw7+u21abRVhH0LDSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Wesley Terpstra @ 2017-04-05 6:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
On Tue, Apr 4, 2017 at 11:41 PM, Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
>> [ 0.010000] cpu cpu0: Error -2 creating of_node link
> Interesting. I've never seen that error, I wonder if that's because
> we fail to link the CPU to an OF node to begin with on our platforms.
You can find quite a few dmesg traces on google that include the
warning. It affects at least nios2, microblaze and riscv.
It's because the 'sd' pointer in the of_node's kobject is null, which
causes sysfs_do_create_link_sd to return -ENOENT. AFAICT, it's null
because the device tree nodes have not yet been linked into sysfs;
that is what of_core_init() does.
> Devices might try to create symlinks to device-tree nodes,
> thus all devices that have OF node linkages should be created
> after of_core_init() has been called.
Your proposed patch fixes the warning for me on riscv.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cpu of_node links broken
[not found] ` <CAMgXwThRqAO0vG0QVC7LYO2Srf9inh+osw7+u21abRVhH0LDSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-04-05 7:58 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 4+ messages in thread
From: Benjamin Herrenschmidt @ 2017-04-05 7:58 UTC (permalink / raw)
To: Wesley Terpstra; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
On Tue, 2017-04-04 at 23:49 -0700, Wesley Terpstra wrote:
> On Tue, Apr 4, 2017 at 11:41 PM, Benjamin Herrenschmidt
> <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> > > [ 0.010000] cpu cpu0: Error -2 creating of_node link
> >
> > Interesting. I've never seen that error, I wonder if that's because
> > we fail to link the CPU to an OF node to begin with on our
> > platforms.
>
> You can find quite a few dmesg traces on google that include the
> warning. It affects at least nios2, microblaze and riscv.
>
> It's because the 'sd' pointer in the of_node's kobject is null, which
> causes sysfs_do_create_link_sd to return -ENOENT. AFAICT, it's null
> because the device tree nodes have not yet been linked into sysfs;
> that is what of_core_init() does.
>
> > Devices might try to create symlinks to device-tree nodes,
> > thus all devices that have OF node linkages should be created
> > after of_core_init() has been called.
>
> Your proposed patch fixes the warning for me on riscv.
Thanks. I'll smoke-test it on powerpc tomorrow (and figure out why we
don't hit the warning) and submit it formally to Greg.
Remind me if I forget, I'm rather swamped these days :)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-04-05 7:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-05 6:12 cpu of_node links broken Wesley Terpstra
[not found] ` <CAMgXwThQk=3V1HQ8YpoY57mpY0SrdyfAwS5szpsqwkS-r=FPAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-05 6:41 ` Benjamin Herrenschmidt
[not found] ` <1491374467.4166.81.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-05 6:49 ` Wesley Terpstra
[not found] ` <CAMgXwThRqAO0vG0QVC7LYO2Srf9inh+osw7+u21abRVhH0LDSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-05 7:58 ` Benjamin Herrenschmidt
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.