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
