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

[Philipp Zabel]

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.

> > 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.

> > > 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