Messages in this thread | | | Subject | Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon devices | From | Jeremy Kerr <> | Date | Wed, 07 Dec 2022 15:56:42 +0800 |
| |
Hi Arnd,
Thanks for taking a look a this. Just a question about the early approach; I'm not too familiar with the internals of the syscon/regmap infrastructure:
> > 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. > > Ok, in that case I think we should at least leave the option of > doing the reset from an early syscon as well.
OK, sounds good - I'll add a direct of_reset_control_get_<variant>() in the early of_syscon_register path, which should work in a similar way to the clocks properties.
However: this may conflict with the later platform_device syscon; if the late syscon tries to of_reset_control_get_exclusive() the same reset controller (because it's the same syscon node), that will (of course) fail.
Hence a question about the syscon infrastructure: how are the late- and early- syscon registrations supposed to interact? Should I allow for there to be two syscons registered (one through of_syscon_register(), the other through the platform device probe), or do we expect that to never happen?
In case of the former, I can just grab a shared handle to the reset controller instead, but I want to make sure that's the correct thing to do.
Cheers,
Jeremy
| |