Re: Reset controller within a clock driver

[<Conor.Dooley@microchip.com>]

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