From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 704B74DB563 for ; Mon, 11 May 2026 22:12:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778537556; cv=none; b=MPlL91tUp3EfS9zuWeNXX31OQR3+M+Cf1hUUbTpIyiC09QaB1qqhd7r+ZyNdXS97P4vS8YGOTSCxPAagTgAPpHw+9Ge7wGAwbhXeB510xcJwkTYHIyTMInEhQOaHQZWmvMn+2mhrYgtE6mfm2hRRSoS8zAVeHh/qCDTgaxrvy4o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778537556; c=relaxed/simple; bh=TW5fFWPOmM1OnqKQstKJXz2DYAW15Bq3Kb4XLf5J7cE=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=PN9z9lk8NbjzL8gBsJA3HOHB3OoSzn2oACPF/KpMkmsX26UWCbtQCpnTcTtGV9jRM8VJ0Q47/mlYZI+iTOmg44qkFBteYA/K1OwdWcaFowuQza39Qu8voacIh9aVRkEN72RFwR+Mq5cmOdHq1v2b//q8sES0z/Ix+4S4txXlubo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ICxW5wKU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ICxW5wKU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 960EFC2BCB0; Mon, 11 May 2026 22:12:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778537556; bh=TW5fFWPOmM1OnqKQstKJXz2DYAW15Bq3Kb4XLf5J7cE=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=ICxW5wKUoXM34Pc+p3XRj7fK2MUB80m0m+duI/dYkD9zpgUUunp5Z1DgYo9mF8zho 6KpM/IXVmCFYvQYVE3/cM6dADpwr7VKFUEzvhcpAVtKFfkHsoUbCktWPZ7yM6f4Noj U1E4MqDi9OklikU50GC3g7sk8dCgUsEtSZk1hXYKiT3dQPsMOcOV32j+x7FbTHwB8a Xw7H0Ru68nCjKBaGnsk/ZHKGrCP9TlHRXCyIBn5ef79KqikMsr2BseVDv20P5ONnPn aUZVD0fFf4egxcMlOB1HZG8KAgrnkDp9yMUq5p5jYDN3F8OToGsM/TCAC1RQfx6TFj +qbkOxS08KAow== From: sashiko-bot@kernel.org Subject: Re: [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings. Reply-To: sashiko@lists.linux.dev To: =?utf-8?b?U3RlZmFuIETDtnNpbmdlcg==?= Cc: devicetree@vger.kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org In-Reply-To: <20260511-zx29clk-v2-1-29f0edc300f5@gmail.com> References: <20260511-zx29clk-v2-1-29f0edc300f5@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 11 May 2026 22:12:35 +0000 Message-Id: <20260511221235.960EFC2BCB0@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: - [Medium] The device tree binding intentionally omits the hardware clock d= ependency between the top controller and the matrix controller. - [Low] Missing 'clock-frequency' property in 'fixed-clock' example nodes. - [Low] The `zte,zx297520v3-matrixclk` compatible string lacks an `if-then`= block to explicitly forbid `clocks` and `clock-names`. - [Low] The node names in the example block do not follow generic naming st= andards. -- commit dcd964f6e480b59678a5c8aefa3f700c7eec5d64 Author: Stefan D=C3=B6singer dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings. This commit introduces device tree bindings for the ZTE zx297520v3 SoC clock and reset controllers. It defines the top, matrix, and lsp controllers, along with their respective clock and reset definitions. > diff --git a/Documentation/devicetree/bindings/clock/zte,zx297520v3-clk.y= aml b/Documentation/devicetree/bindings/clock/zte,zx297520v3-clk.yaml > new file mode 100644 > index 0000000000000..3b7084a18a975 > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/zte,zx297520v3-clk.yaml [ ... ] > +description: | > + The zx297520v3's clock controller consists of 3 controllers, which gen= erate > + clocks for internal SoC devices. In addition to clocks it also has res= et > + controls for most, but not all, devices. [ ... ] > + The matrix controller consumes clocks generated by PLLs in the top > + controller, but there are no controls in the top controller to sever t= his > + link. The interface between these controllers is not expressed in the = device > + tree, but the matrix controller cannot work without the clock handles > + registered by the top controller. Does omitting the clock relationship between the top and matrix controllers hide the physical hardware topology? Device tree bindings should typically describe the actual hardware connections. By leaving out the clocks property from the matrixclk node to reference the topclk outputs, could this force the driver to rely on implicit dependencies for probe ordering and break proper frequency propagation in the clock framework? [ ... ] > + - if: > + properties: > + compatible: > + contains: > + const: zte,zx297520v3-lspclk > + then: > + properties: > + clocks: [ ... ] > + required: > + - clocks > + - clock-names > + > +additionalProperties: false Since clocks and clock-names are defined at the top level of this binding, would an invalid matrixclk device tree node mistakenly including those properties silently pass validation? Because additionalProperties: false only rejects completely undefined properties, should there be an if-then block for matrixclk that explicitly sets clocks: false and clock-names: false to prevent this? [ ... ] > +examples: > + - | > + #include > + > + osc26m: osc26m { > + compatible =3D "fixed-clock"; > + clock-output-names =3D "osc26m"; > + #clock-cells =3D <0>; > + }; > + > + osc32k: osc32k { > + compatible =3D "fixed-clock"; > + clock-output-names =3D "osc32k"; > + #clock-cells =3D <0>; > + }; Do these fixed-clock examples need the clock-frequency property? The core schema for fixed clocks mandates this property, which might cause dt_binding_check to fail if it is missing here. > + topclk: topclk@13b000 { > + compatible =3D "zte,zx297520v3-topclk"; > + reg =3D <0x0013b000 0x400>; > + #clock-cells =3D <1>; > + #reset-cells =3D <1>; > + clocks =3D <&osc26m>, <&osc32k>; > + clock-names =3D "osc26m", "osc32k"; > + }; > + > + matrixclk: matrixclk@1306000 { > + compatible =3D "zte,zx297520v3-matrixclk"; > + reg =3D <0x01306000 0x400>; > + #clock-cells =3D <1>; > + #reset-cells =3D <1>; > + }; > + > + lspclk: lspclk@1400000 { > + compatible =3D "zte,zx297520v3-lspclk"; > + reg =3D <0x01400000 0x100>; Are these node names deviating from generic naming standards? The devicetree specification requires node names to describe the generic class of a device rather than specific block names. Could these be renamed using the clock-controller@... pattern to comply with conventions and avoid schema warnings? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260511-zx29clk-v2= -0-29f0edc300f5@gmail.com?part=3D1