On Di, 2022-12-06 at 09:41 +0100, Arnd Bergmann wrote:
> On Tue, Dec 6, 2022, at 08:39, Jeremy Kerr wrote:
> > Simple syscon devices may require deassertion of a reset signal in order
> > to access their register set. Rather than requiring a custom driver to
> > implement this, we can use the generic "resets" specifiers to link a
> > reset line to the syscon.
> >
> > This change adds an optional reset line to the syscon device
> > description, and code to perform the deassertion/assertion on
> > probe/remove.
> >
> > Signed-off-by: Jeremy Kerr <jk@xxxxxxxxxxxxxxxxxxxx>
>
> I see that this will only work after the device has been registered,
> but not for early users of the syscon framework that bypass the
> device logic and just call device_node_to_regmap() or
> syscon_regmap_lookup*() during early boot.
>
> It should be possible to solve this by adding the reset logic
> into the of_syscon_register() function and using the
> of_reset_control_get*() helpers instead of the devm_* ones,
> but I'm not sure if that causes other problems with probe
> order, or if that helps at all, if reset drivers already
> require the device subsystem to be running.
>
> Philipp, what is the earliest point at which
> reset_controller_register() can be called? Is that
> possible before postcore_initcall() or driver_register()?
reset_controller_register() only initializes a few fields in the passed
rcdev structure and adds it to a static list under a static mutex, so
there's not much of a limit.
However, reset controllers that choose to register early without
creating a platform device may run into issues with devlink inhibiting
reset consumers' probe [1].
[1] a1467faa1041 ("ARM: imx: register reset controller from a platform driver")
https://lore.kernel.org/linux-arm-kernel/20211005100618.730907-1-p.zabel@xxxxxxxxxxxxxx/
regards
Philipp
