[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250508124059-GYA506797@gentoo>
Date: Thu, 8 May 2025 12:40:59 +0000
From: Yixun Lan <dlan@...too.org>
To: Alex Elder <elder@...cstar.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, mturquette@...libre.com,
sboyd@...nel.org, p.zabel@...gutronix.de, paul.walmsley@...ive.com,
palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
heylenay@....org, inochiama@...look.com, guodong@...cstar.com,
devicetree@...r.kernel.org, linux-clk@...r.kernel.org,
spacemit@...ts.linux.dev, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v6 1/6] dt-bindings: soc: spacemit: define
spacemit,k1-ccu resets
Hi Alex,
On 07:17 Thu 08 May , Alex Elder wrote:
> On 5/8/25 7:02 AM, Krzysztof Kozlowski wrote:
> > On 08/05/2025 00:35, Yixun Lan wrote:
> >>> + - if:
> >>> + properties:
> >>> + compatible:
> >>> + contains:
> >>> + enum:
> >>> + - spacemit,k1-syscon-apbc
> >>> + - spacemit,k1-syscon-apmu
> >>> + - spacemit,k1-syscon-mpmu
> >>> + then:
> >>> + required:
> >>> + - clocks
> >>> + - clock-names
> >>> + - "#clock-cells"
> >>>
> >>> additionalProperties: false
> >>>
> >>> diff --git a/include/dt-bindings/clock/spacemit,k1-syscon.h b/include/dt-bindings/clock/spacemit,k1-syscon.h
> >>> index 35968ae982466..f5965dda3b905 100644
> >>> --- a/include/dt-bindings/clock/spacemit,k1-syscon.h
> >>> +++ b/include/dt-bindings/clock/spacemit,k1-syscon.h
> >> would it be better to move all reset definition to its dedicated dir?
> >> which like: include/dt-bindings/reset/spacemit,k1-syscon.h?
> >
> > Please kindly trim the replies from unnecessary context. It makes it
> > much easier to find new content.
> >
> >
> > I don't get why such comments are appearing so late - at v6. There was
> > nothing from you about this in v1, v2 and v3, which finally got reviewed.
>
> Stephen Boyd said "please rework this to use the auxiliary driver
> framework" on version 5 of the series; it was otherwise "done" at
> that point.
>
> Doing this meant there was a much clearer separation of the clock
> definitions from the reset definitions. And Yixun's suggestion
> came from viewing things in that context.
>
> Given the rework, I considered sending this as v1 of a new series
> but did not.
>
> > I just feel people wait for maintainers to review and only after they
> > will add their 2 cents of nitpicks or even some more important things
> > potentially invalidating the review. Lesson for me: do not review
> > people's work before it reaches v10, right?
>
> That's not what happened here--or at least, it's not as simple
> as that. Your quick review was very much appreciated.
>
> Yixun: Krzysztof was satisfied with things the way they're
> defined here. Do you feel strongly I should make your suggested
> change? Or are you OK with me just keeping things defined this
> way for the next version? I'd like this question resolved before
> I send the next version.
>
I was fine with squashing all definitions in one file for old version,
but now, a new reset driver is introduced, I think it is deemed an
independent header file? all newly added macros are related to reset.
--
Yixun Lan (dlan)
Powered by blists - more mailing lists