Re: [PATCH v3 3/4] clk: baikal-t1: Move reset-controls code into a dedicated module

[Serge Semin <fancer.lancer@gmail.com>]

On Tue, May 17, 2022 at 12:37:26AM -0700, Stephen Boyd wrote:
> Quoting Serge Semin (2022-05-03 13:57:21)
> > Before adding the directly controlled resets support it's reasonable to
> > move the existing resets control functionality into a dedicated object for
> > the sake of the CCU dividers clock driver simplification. After the new
> > functionality is added clk-ccu-div.c would have got to a mixture of the
> > weakly dependent clocks and resets methods. Splitting the methods up into
> > the two objects will make code easier to read especially seeing it isn't
> > that hard to do.
> > 
> > As before the CCU reset module will support the trigger-like CCU resets
> > only, which are responsible for the AXI-bus, APB-bus and SATA-ref blocks
> > reset. The assert/de-assert-capable reset controls support will be added
> > in the next commit.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >  drivers/clk/baikal-t1/Kconfig       |  12 +-
> >  drivers/clk/baikal-t1/Makefile      |   1 +
> >  drivers/clk/baikal-t1/ccu-rst.c     | 258 ++++++++++++++++++++++++++++
> >  drivers/clk/baikal-t1/ccu-rst.h     |  60 +++++++
> >  drivers/clk/baikal-t1/clk-ccu-div.c |  94 ++--------
> 

> Perhaps this should be done via the auxiliary bus by having the clk
> driver register the reset driver and have some private API to pass any
> data to the reset driver? Then the whole file could be in
> drivers/reset/, reviewed and maintained by the reset maintainer.

I'd rather stick to the current design in the same way as the most of
the OF-based platform clock drivers. Completely splitting the reset
and clock parts isn't that easy is it seems like (though the main part
has been done in the framework of this patchset). AXI/APB-interface
reset controls are tightly coupled with the AXI/APB-clock domains at
least by having the same CSRs. Due to that the corresponding AXI-clock
domains reset functionality will need to be left in the
drivers/clk/baikal-t1/clk-ccu* module. It makes the movement isn't
that justified and will result in needless code complications and the
code coherency worsening.

-Sergey