linux-kernel - Re: Reset controller within a clock driver

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: <20220527192608.25F47C385A9@smtp.kernel.org>
Date:   Fri, 27 May 2022 12:26:06 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Conor.Dooley@...rochip.com
Cc:     Daire.McNamara@...rochip.com, geert@...ux-m68k.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        mturquette@...libre.com, p.zabel@...gutronix.de
Subject: Re: Reset controller within a clock driver

Quoting Conor.Dooley@...rochip.com (2022-05-27 11:40:59)
> Hi Stephen,
> 
> 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.
> 
> 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.
> 
> 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].
> 
> 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?
> 

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.