linux-kernel - Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e3a85852b911fdf16dd9ae158f42b3ef.sboyd@kernel.org>
Date: Sun, 07 Apr 2024 19:39:30 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Jan Dakinevich <jan.dakinevich@...utedevices.com>, Jerome Brunet <jbrunet@...libre.com>, Philipp Zabel <p.zabel@...gutronix.de>
Cc: Neil Armstrong <neil.armstrong@...aro.org>, Jerome Brunet <jbrunet@...libre.com>, Michael Turquette <mturquette@...libre.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Kevin Hilman <khilman@...libre.com>, Martin Blumenstingl <martin.blumenstingl@...glemail.com>, linux-amlogic@...ts.infradead.org, linux-clk@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module

Quoting Jerome Brunet (2024-04-02 07:52:38)
> 
> On Thu 28 Mar 2024 at 04:08, Jan Dakinevich <jan.dakinevich@...utedevicescom> wrote:
> 
> > This code will by reused by A1 SoC.
> 
> Could expand a bit please ?
> 
> >
> > Signed-off-by: Jan Dakinevich <jan.dakinevich@...utedevices.com>
> 
> 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. 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.