On So, 2024-04-07 at 19:39 -0700, Stephen Boyd wrote: > Quoting Jerome Brunet (2024-04-02 07:52:38) > > > > On Thu 28 Mar 2024 at 04:08, Jan Dakinevich <jan.dakinevich@xxxxxxxxxxxxxxxxx> wrote: > > > > > This code will by reused by A1 SoC. > > > > Could expand a bit please ? > > > > > > > > Signed-off-by: Jan Dakinevich <jan.dakinevich@xxxxxxxxxxxxxxxxx> > > > > In general, I like the idea. > > > > We do have a couple a reset registers lost in middle of clocks and this > > change makes it possible to re-use the code instead duplicating it. > > > > The exported function would be used by audio clock controllers, but the > > module created would be purely about reset. > > > > One may wonder how it ended up in the clock tree, especially since the > > kernel as a reset tree too. > > > > I'm not sure if this should move to the reset framework or if it would > > be an unnecessary churn. Stephen, Philipp, do you have an opinion on > > this ? > > > > I'd prefer it be made into an auxiliary device and the driver put in > drivers/reset/ so we can keep reset code in the reset directory. Seconded, the clk-mpfs/reset-mpfs and clk-starfive-jh7110-sys/reset- starfive-jh7110 drivers are examples of this. > The auxiliary device creation function can also be in the > drivers/reset/ directory so that the clk driver calls some function > to create and register the device. I'm undecided about this, do you think mpfs_reset_controller_register() and jh7110_reset_controller_register() should rather live with the reset aux drivers in drivers/reset/ ? regards Philipp
