Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <31b7293f-662d-4a94-1717-9c76d7f33840@microchip.com>
References: <31b7293f-662d-4a94-1717-9c76d7f33840@microchip.com>
Subject: Re: Reset controller within a clock driver
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Daire.McNamara@microchip.com, geert@linux-m68k.org,
        linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
        mturquette@baylibre.com, p.zabel@pengutronix.de
To:     Conor.Dooley@microchip.com
Date:   Fri, 27 May 2022 12:26:06 -0700
User-Agent: alot/0.10
Message-Id: <20220527192608.25F47C385A9@smtp.kernel.org>
Precedence: bulk

Quoting Conor.Dooley@microchip.com (2022-05-27 11:40:59)
> Hi Stephen,
>=20
> After I sent the fix for the broken resets in clk/microchip/clk-mpfs.c,
> [0] I started looking at making a proper reset controller driver a la
> clk/renesas/{renesas-cpg-mssr,rzgl2l-cpg}.c where the reset controller
> is part of the clock driver file.
>=20
> I did it that way b/c the reset controller is just a single reg,
> surrounded by registers used by clocks. It's roughly a +130,-10 line
> change to the existing driver. A /very/ rough version that will not
> apply without other cleanup is appended for context.
>=20
> Before I got around to testing properly and cleaning it up for
> submission, I saw a mail you had sent and wondered if I'd gone for the
> wrong approach [1].
>=20
> Should I instead have my clock driver create a device for the reset
> controller to bind to, or is that overkill for a single register &
> Serge's situation is different b/c he'd created a file purely for
> a reset controller?
>=20

It's really up to you. It may be better to use auxiliary bus to split
the logic out to different subsystems. I can review the reset code but
I'm not the reset maintainer. Historically we've just accepted that
sometimes SoCs combine the clk and reset controls together into a "clock
and reset controller" and so we have the driver register clks and
resets. Using the bus to split up the device will help move these
registration calls to the appropriate subsystem so that the
reviewer/maintainer load is spread around.