Re: [PATCH] ARM: imx: drop devlinks to reset-controller node

On Wed, 2021-09-22 at 08:38 -0700, Saravana Kannan wrote:
[...]

Yes, this node is handled by platform code in arch/arm/mach-imx/src.c as

Yes, I saw the node is handled in that file. I know it's not currently
a platform driver. I wasn't asking about that. I'm asking if a struct
device is created for the node or not. Creation of the struct device
is done automatically by the OF code and I don't see any code that
prevents the creation of the device.

Can you please run this on your device and that should answer my question"
# find /sys/devices/ -name *reset-controller*

I'm asking this question because there is a cleaner way to fix this
instead of what you are doing if there is actually a struct device
created for the node.

Oh, I wasn't aware. Yes,
/sys/devices/platform/soc/2000000.bus/20d8000.reset-controller
does exist.

quoted

the reset controller register also contains bits to bring up the CPUs.

Ok, I initially assumed that's why you were doing this, but I didn't
see this &src node (the reset controller) being referenced anywhere
else in DT. So how does that work?

There are a few functions exported from src.c (imx_enable_cpu,
imx_set_cpu_arg/jump) that are used in hotplug.c and platsmp.c.

quoted

quoted

Based on the DT, it looks like a device would automatically
get created for this node. So it looks like it's more of an issue with
the device not being probed by a real driver? Why can't you convert
the reset controller driver to a proper platform driver instead of
this patch? I think that's the right fix.

In this case, I could indeed add a platform driver for the reset
controller part. I'm not yet sure that this is always the right thing.

Can you dig into that more please? Instead of just deleting the fwnode
links? There are also ways to make sure you don't block early users
(before driver core is up) while still doing proper ordering for later
users (like ipu, etc). I'd like to fix this in the best way possibly
so that fw_devlink can do the best ordering it can.

I'll send a patch adding the platform driver, but could you elaborate on
what could be done with the auto-generated reset-controller device
instead?

[...]

remote-endpoints always point to each other. So they create dependency
cycles and fw_devlink stops enforcing ordering between them (because
it's a cycle and it has no way to know which one depends on the other
for probing). So for this specific case, you should get away without
writing platform drivers.

Right, thank you, I assume there must have been a missing backlink then.

regards
Philipp

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel