From: "Rob Herring (Arm)" <robh@kernel.org>
To: "Stefan Dösinger" <stefandoesinger@gmail.com>
Cc: linux-phy@lists.infradead.org, Conor Dooley <conor+dt@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org, Brian Masney <bmasney@redhat.com>,
Vinod Koul <vkoul@kernel.org>,
Russell King <linux@armlinux.org.uk>,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-arm-kernel@lists.infradead.org,
Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v7 02/13] dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller
Date: Thu, 16 Jul 2026 19:05:29 -0500 [thread overview]
Message-ID: <178424672826.2081877.18233525928867886605.robh@kernel.org> (raw)
In-Reply-To: <20260717-zx29clk-v7-2-408411cfcf36@gmail.com>
On Fri, 17 Jul 2026 00:35:38 +0300, Stefan Dösinger wrote:
> These SoCs have 3 clock and reset controllers: Top, Matrix and LSP.
> Clocks go from oscillator -> top -> matrix -> LSP, with a register in
> top controlling most clocks that get passed to matrix and a register in
> matrix controlling all the clocks that get passed to LSP.
>
> Generally every device has two clocks (one work clock, and one that
> connects it to the bus, I call it PCLK), two reset bits (I don't know
> what the difference is - sometimes asserting one is enough to reset the
> device, sometimes both need to be asserted). PCLK and WCLK are
> controlled by individual gates. Some devices have a mux and/or a
> divider for their work clock. Some devices, like the GPIO controller,
> only have reset bits and no clocks.
>
> The top clock controller is fed by a 26mhz external oscillator and has 4
> PLLs to generate other clock rates. ZTE's kernel mostly relies on the
> boot ROM to set up PLLs, but one LTE-Related PLL is not configured
> on some boards. Therefore my driver contains code to program PLLs. It
> produces identical settings as the boot ROM for the pre-programmed
> frequencies.
>
> Not all clocks will have an explicit user in the end. I am defining a
> lot of them simply to shut them off. The boot loader sets up a few of
> the proprietary timers, which will send regular IRQs (although the
> kernel of course doesn't need to listen to them). I don't plan to add a
> driver for the proprietary timer as I see no use for them - the ARM arch
> timer works just fine. I will add a driver for the very similar
> proprietary watchdog though.
>
> The clock list in this patch is pretty complete but not exhaustive.
> There are other bits that are enabled, but I couldn't deduce what they
> are controlling by trial and error. Some of them seem to do nothing.
> Others cause an instant hang of the board when disabled. It is quite
> likely that a handful more clocks will be added in the future, but not a
> large number.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> Changes v6->v7:
> *) Moved the bingings back into clock/ (Krzysztof). use clock-controller@
> in example and in the later DTSI patch.
>
> *) With as lucky find in strings in LTE's cpko.ko blob I could make sense
> of the register that controls which clocks get passed from PLLs into
> the clock distribution inside topcrm. Importantly that also narrows
> which clocks can possibly be passed to Matrix, so I could slim down the
> bindings considerably.
>
> *) Add a usb phy child node with the phy schema added in the previous
> patch. I don't expect the USB status register to ever be in another
> place, so the binding expresses the @84 expectation.
>
> Changes v5->v6:
> Set value for syscon-reboot example (Sashiko). It was my intention to
> set only the lowest bit, and I think Sashiko is right that without
> 'value' being set, all other bits are actively set to 0. It shouldn't
> matter given my understanding of the hardware (afaics all other bits are
> ignored), but actively clearing bits was not my intention.
>
> I haven't changed the name match for "syscon-reboot". I see plenty of
> examples of hardcoding this string as opposed to having a regex for
> syscon-reboot@12345678 in other bindings.
>
> Changes v4->v5:
>
> Rename from zte,zx297520v3-topclk to zte,zx297520v3-topcrm and move to
> soc/zte
> Fix path in MAINTAINERS
> Add syscon-reboot node to the binding
> Give the USB and HSIC PHY resets their own reset control
> ---
> .../bindings/clock/zte,zx297520v3-topcrm.yaml | 123 +++++++++++++++++++++
> MAINTAINERS | 3 +
> include/dt-bindings/clock/zte,zx297520v3-clk.h | 66 +++++++++++
> include/dt-bindings/reset/zte,zx297520v3-reset.h | 32 ++++++
> 4 files changed, 224 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.example.dtb: clock-controller (zte,zx297520v3-topcrm): 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/clock/zte,zx297520v3-topcrm.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.example.dtb: clock-controller (zte,zx297520v3-topcrm): 'clock-names' is a required property
from schema $id: http://devicetree.org/schemas/clock/zte,zx297520v3-topcrm.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.example.dtb: clock-controller (zte,zx297520v3-topcrm): 'syscon-reboot' is a required property
from schema $id: http://devicetree.org/schemas/clock/zte,zx297520v3-topcrm.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/zte,zx297520v3-usb-phy.example.dtb: clock-controller (zte,zx297520v3-topcrm): '#clock-cells' is a required property
from schema $id: http://devicetree.org/schemas/clock/zte,zx297520v3-topcrm.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260717-zx29clk-v7-2-408411cfcf36@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
next prev parent reply other threads:[~2026-07-17 0:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 21:35 [PATCH v7 00/13] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-07-16 21:35 ` [PATCH v7 01/13] dt-bindings: phy: Add zx297520v3 USB phy documentation Stefan Dösinger
2026-07-17 0:05 ` Rob Herring (Arm)
2026-07-17 6:32 ` Krzysztof Kozlowski
2026-07-16 21:35 ` [PATCH v7 02/13] dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller Stefan Dösinger
2026-07-17 0:05 ` Rob Herring (Arm) [this message]
2026-07-17 6:36 ` Krzysztof Kozlowski
2026-07-17 8:15 ` Krzysztof Kozlowski
2026-07-16 21:35 ` [PATCH v7 03/13] dt-bindings: clk: zte: Add zx297520v3 matrix " Stefan Dösinger
2026-07-16 21:35 ` [PATCH v7 04/13] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-07-17 8:23 ` Krzysztof Kozlowski
2026-07-16 21:35 ` [PATCH v7 05/13] mfd: zx297520v3: Add a clock and reset MFD driver Stefan Dösinger
2026-07-16 21:35 ` [PATCH v7 06/13] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-07-16 21:35 ` [PATCH v7 07/13] clk: zte: Add regmap based clocks Stefan Dösinger
2026-07-16 21:35 ` [PATCH v7 08/13] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-07-16 21:35 ` [PATCH v7 09/13] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-07-16 22:00 ` [PATCH v7 10/13] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-07-16 22:00 ` [PATCH v7 12/13] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-07-16 22:00 ` [PATCH v7 13/13] ARM: dts: zte: Declare zx297520v3 CRM device nodes Stefan Dösinger
2026-07-16 22:17 ` [PATCH v7 11/13] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-07-17 6:37 ` [PATCH v7 00/13] ZTE zx297520v3 clock bindings and driver Krzysztof Kozlowski
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=178424672826.2081877.18233525928867886605.robh@kernel.org \
--to=robh@kernel.org \
--cc=bmasney@redhat.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=sboyd@kernel.org \
--cc=stefandoesinger@gmail.com \
--cc=vkoul@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