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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 27 May 2022 20:52:05 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <sboyd@...nel.org>
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

On 27/05/2022 20:26, Stephen Boyd wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 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.

Aye, CC'ed him in case he had an opinion too.

> 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.

SGTM, I'll give it a go.
Thanks,
Conor.