Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan Dösinger" <stefandoesinger@gmail.com>
To: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Brian Masney <bmasney@redhat.com>,
	Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 01/12] dt-bindings: soc: zte: Add zx297520v3 top clock and reset bindings
Date: Fri, 03 Jul 2026 20:20:58 +0300	[thread overview]
Message-ID: <az-AzRTTT8qfUWysHYig6Q@gmail.com> (raw)
In-Reply-To: <387ff0d7-256e-4b18-b864-37a0ec3c9d9d@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

Am Freitag, 3. Juli 2026, 09:26:43 Ostafrikanische Zeit schrieb Krzysztof 
Kozlowski:

> Also, this cannot be placed in soc. Clock and reset controllers DO NOT
> go to the soc directory. Place in it clocks.

Even when they contain other functionality like hwlock, usb phy and reboot? 
Here is the previous discussion that made me move it to soc:

https://lore.kernel.org/linux-arm-kernel/20260621-plywood-straddle-b01f0c45f27c@spud/

Likewise, what about the node name: syscon@ or clock-controller@ ? Conor 
advised me to go with syscon@

Cheers,
Stefan

--- Quoting the relevant parts from the above link:

> At what point does it make sense to move the bindings from bindings/clock to 
> bindings/mfd? The controllers are still very clock-heavy. allwinner,*-
> prcm.yaml look like clock, reset, misc controllers in mfd/ whereas 
> ingenic,cgu.yaml, sprd,sc9863a-clk.yaml and da8xx-cfgchip.txt are clock + 
misc 
> drivers in clock/.

Yeah, to bindings/mfd or bindings/soc/<vendor>. Which I think is mostly
a judgement call. Two of your devices have at least three functions,
which I think is enough to make the claim that it's not just a clock
controller.

> Likewise for the node names: syscon@ or clock-controller@?

If you have syscon in the compatible, then I think it should be syscon
in the node name as it's more general and makes it clear the device
isn't just a clock controller.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

  reply	other threads:[~2026-07-04  8:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 20:27 [PATCH v6 00/12] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-07-02 20:27 ` [PATCH v6 01/12] dt-bindings: soc: zte: Add zx297520v3 top clock and reset bindings Stefan Dösinger
2026-07-03  6:03   ` Krzysztof Kozlowski
2026-07-03  6:26   ` Krzysztof Kozlowski
2026-07-03 17:20     ` Stefan Dösinger [this message]
2026-07-04  8:35       ` Krzysztof Kozlowski
2026-07-02 20:27 ` [PATCH v6 02/12] dt-bindings: soc: zte: Add zx297520v3 matrix " Stefan Dösinger
2026-07-03  6:07   ` Krzysztof Kozlowski
2026-07-02 20:27 ` [PATCH v6 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-07-02 20:27 ` [PATCH v6 04/12] mfd: zx297520v3: Add a clock and reset MFD driver Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 05/12] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 06/12] clk: zte: Add regmap based clocks Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 07/12] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 09/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 10/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 11/12] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-07-03  9:16   ` Philipp Zabel
2026-07-03 16:19     ` Stefan Dösinger
2026-07-02 20:28 ` [PATCH v6 12/12] ARM: dts: zte: Declare zx297520v3 CRM device nodes Stefan Dösinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=az-AzRTTT8qfUWysHYig6Q@gmail.com \
    --to=stefandoesinger@gmail.com \
    --cc=bmasney@redhat.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox