On Tue, Jun 3, 2025 at 8:24 PM Michal Wilczynski <m.wilczyn...@samsung.com> wrote: > > > > Agreed. And as far as implementation goes, you can have the same > > driver be a PM domain AND pwrseq provider. It just has to bind to the > > device node that represents an actual component, not a made-up > > "convenience" node. > > Sure - this can be done using existing AON node. > > To keep the pwrseq code organized in drivers/power/sequencing/, a > similar approach to our th1520-pd driver interfacing with the AON > firmware library (drivers/firmware/thead,th1520-aon.c) could work. > > The idea would be to treat code like pwrseq-thead-aon.c (changed from a > current pwrseq-thead-gpu.c) as a library. It would export its necessary > functions (e.g., for specific sequence init/deinit steps) using > EXPORT_SYMBOL_GPL. The main AON driver would then call these to provide > the pwrseq functionality. > > This will introduce a compile-time dependency, as expected. > > An alternative would be to keep the driver in drivers/power/sequencing/ > as a platform driver and start it up using, for example, an auxiliary > bus. This is similar to what the JH7110 clock driver > (drivers/clk/starfive/clk-starfive-jh7110-sys.c) is doing with a reset > driver. This could offer a cleaner separation of roles if that's > preferred. > > Please let me know which way would be preferred.
I forgot the auxiliary bus is a thing. Yeah, definitely use that, it's more elegant than a library function IMO. Bart
