From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ivan Vecera <ivecera@redhat.com>, netdev@vger.kernel.org
Cc: Michal Schmidt <mschmidt@redhat.com>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
Jiri Pirko <jiri@resnulli.us>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Prathosh Satish <Prathosh.Satish@microchip.com>,
Lee Jones <lee@kernel.org>, Kees Cook <kees@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 15/28] dt-bindings: dpll: Add device tree bindings for DPLL device and pin
Date: Mon, 7 Apr 2025 20:01:27 +0200 [thread overview]
Message-ID: <74172acd-e649-4613-a408-d1f61ceeba8b@kernel.org> (raw)
In-Reply-To: <20250407173149.1010216-6-ivecera@redhat.com>
On 07/04/2025 19:31, Ivan Vecera wrote:
> This adds DT bindings schema for DPLL (device phase-locked loop)
Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95
A nit, subject: drop second/last, redundant "device tree bindings for".
The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> device and associated pin. The schema follows existing DPLL core API
What is core API in terms of Devicetree?
> and should be used to expose information that should be provided
> by platform firmware.
>
> The schema for DPLL device describe a DPLL chip that can contain
> one or more DPLLs (channels) and platform can specify their types.
> For now 'pps' and 'eec' types supported and these values are mapped
> to DPLL core's enums.
Describe entire hardware, not what is supported.
>
> The DPLL device can have optionally 'input-pins' and 'output-pins'
> sub-nodes that contain pin sub-nodes.
>
> These pin sub-nodes follows schema for dpll-pin and can contain
> information about the particular pin.
Describe the hardware, not the schema. We can read the contents of
patch. What we cannot read is the hardware and why you are making all
these choices.
>
> The pin contains the following properties:
> * reg - pin HW index (physical pin number of given type)
> * label - string that is used as board label by DPLL core
> * type - string that indicates pin type (mapped to DPLL core pin type)
> * esync-control - boolean that indicates whether embeddded sync control
> is allowed for this pin
> * supported-frequencies - list of 64bit values that represents frequencies
> that are allowed to be configured for the pin
Drop. Describe the hardware.
>
> Reviewed-by: Michal Schmidt <mschmidt@redhat.com>
Did this really happen?
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> .../devicetree/bindings/dpll/dpll-device.yaml | 84 +++++++++++++++++++
> .../devicetree/bindings/dpll/dpll-pin.yaml | 43 ++++++++++
> MAINTAINERS | 2 +
> 3 files changed, 129 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dpll/dpll-device.yaml
> create mode 100644 Documentation/devicetree/bindings/dpll/dpll-pin.yaml
Filenames matching compatibles... unless this is common schema, but
commit description did not mention it.
>
> diff --git a/Documentation/devicetree/bindings/dpll/dpll-device.yaml b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> new file mode 100644
> index 0000000000000..e6c309abb857f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dpll/dpll-device.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Digital Phase-Locked Loop (DPLL) Device
> +
> +maintainers:
> + - Ivan Vecera <ivecera@redhat.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + Digital Phase-Locked Loop (DPLL) device are used for precise clock
> + synchronization in networking and telecom hardware. The device can
> + have one or more channels (DPLLs) and one or more input and output
> + pins. Each DPLL channel can either produce pulse-per-clock signal
> + or drive ethernet equipment clock. The type of each channel is
> + indicated by dpll-types property.
> +
> +properties:
> + $nodename:
> + pattern: "^dpll(@.*)?$"
> +
> + "#address-cells":
> + const: 0
> +
> + "#size-cells":
> + const: 0
Why do you need these cells?
> +
> + num-dplls:
> + description: Number of DPLL channels in this device.
Why this is not deducible from compatible?
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 1
> +
> + dpll-types:
> + description: List of DPLL types, one per DPLL instance.
> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> + items:
> + enum: [pps, eec]
Why this is not deducible from compatible?
> +
> + input-pins:
> + type: object
> + description: DPLL input pins
> + unevaluatedProperties: false
So this is all for pinctrl? Or something else? Could not figure out from
commit msg. This does not help me either.
> +
> + properties:
> + "#address-cells":
> + const: 1
Why?
> + "#size-cells":
> + const: 0
Why? I don't see these being used.
> +
> + patternProperties:
> + "^pin@[0-9]+$":
> + $ref: /schemas/dpll/dpll-pin.yaml
> + unevaluatedProperties: false
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> +
> + output-pins:
> + type: object
> + description: DPLL output pins
> + unevaluatedProperties: false
> +
> + properties:
> + "#address-cells":
> + const: 1
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^pin@[0-9]+$":
> + $ref: /schemas/dpll/dpll-pin.yaml
> + unevaluatedProperties: false
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> +
> +dependentRequired:
> + dpll-types: [ num-dplls ]
> +
> +additionalProperties: true
> diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> new file mode 100644
> index 0000000000000..9aea8ceabb5af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dpll/dpll-pin.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DPLL Pin
> +
> +maintainers:
> + - Ivan Vecera <ivecera@redhat.com>
> +
> +description: |
> + Schema for defining input and output pins of a Digital Phase-Locked Loop (DPLL).
> + Each pin can have a set of supported frequencies, label, type and may support
> + embedded sync.
> +
> +properties:
> + reg:
> + description: Hardware index of the pin.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + esync-control:
> + description: Indicates whether the pin supports embedded sync functionality.
> + type: boolean
> +
> + label:
> + description: String exposed as the pin board label
> + $ref: /schemas/types.yaml#/definitions/string
> +
> + supported-frequencies:
> + description: List of supported frequencies for this pin, expressed in Hz.
> + $ref: /schemas/types.yaml#/definitions/uint64-array
Use common property suffixes and drop ref.
> +
> + type:
> + description: Type of the pin
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [ext, gnss, int, mux, synce]
> +
> +
Just one blank line
I bet that half of my questions could be answered with proper hardware
description which is missing in commit msg and binding description.
Instead your commit msg explains schema which makes no sense - I
mentioned, we can read the schema.
> +required:
> + - reg
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-04-07 18:01 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 17:28 [PATCH 00/28] Add Microchip ZL3073x support Ivan Vecera
2025-04-07 17:28 ` [PATCH 01/28] mfd: " Ivan Vecera
2025-04-07 17:53 ` Krzysztof Kozlowski
2025-04-09 6:31 ` Ivan Vecera
2025-04-07 18:05 ` Andy Shevchenko
2025-04-09 6:40 ` Ivan Vecera
2025-04-14 6:36 ` Andy Shevchenko
2025-04-14 11:39 ` Ivan Vecera
2025-04-14 11:52 ` Ivan Vecera
2025-04-14 13:55 ` Andy Shevchenko
2025-04-14 14:08 ` Ivan Vecera
2025-04-14 14:07 ` Ivan Vecera
2025-04-14 14:10 ` Andy Shevchenko
2025-04-14 14:13 ` Andy Shevchenko
2025-04-14 14:16 ` Andy Shevchenko
2025-04-14 14:53 ` Ivan Vecera
2025-04-14 17:09 ` Andy Shevchenko
2025-04-14 17:42 ` Ivan Vecera
2025-04-14 13:58 ` Andy Shevchenko
2025-04-07 17:28 ` [PATCH 02/28] mfd: zl3073x: Register itself as devlink device Ivan Vecera
2025-04-07 20:57 ` Andrew Lunn
2025-04-09 6:41 ` Ivan Vecera
2025-04-07 17:28 ` [PATCH 03/28] mfd: zl3073x: Add register access helpers Ivan Vecera
2025-04-07 21:03 ` Andrew Lunn
2025-04-09 6:42 ` Ivan Vecera
2025-04-07 17:28 ` [PATCH 04/28] mfd: zl3073x: Add macros for device registers access Ivan Vecera
2025-04-07 17:28 ` [PATCH 05/28] mfd: zl3073x: Add components versions register defs Ivan Vecera
2025-04-07 21:09 ` Andrew Lunn
2025-04-09 6:44 ` Ivan Vecera
2025-04-10 7:11 ` Krzysztof Kozlowski
2025-04-10 10:23 ` Ivan Vecera
2025-04-10 10:42 ` Krzysztof Kozlowski
2025-04-10 12:01 ` Ivan Vecera
2025-04-07 17:28 ` [PATCH 06/28] mfd: zl3073x: Implement devlink device info Ivan Vecera
2025-04-07 17:28 ` [PATCH 07/28] mfd: zl3073x: Add macro to wait for register value bits to be cleared Ivan Vecera
2025-04-07 17:28 ` [PATCH 08/28] mfd: zl3073x: Add functions to work with register mailboxes Ivan Vecera
2025-04-07 17:28 ` [PATCH 09/28] mfd: zl3073x: Add clock_id field Ivan Vecera
2025-04-07 17:31 ` [PATCH 10/28] lib: Allow modules to use strnchrnul Ivan Vecera
2025-04-07 17:50 ` Kees Cook
2025-04-07 17:31 ` [PATCH 11/28] mfd: zl3073x: Load mfg file into HW if it is present Ivan Vecera
2025-04-07 17:31 ` [PATCH 12/28] mfd: zl3073x: Fetch invariants during probe Ivan Vecera
2025-04-07 17:31 ` [PATCH 13/28] dpll: Add Microchip ZL3073x DPLL driver Ivan Vecera
2025-04-07 17:31 ` [PATCH 14/28] mfd: zl3073x: Register DPLL sub-device during init Ivan Vecera
2025-04-07 17:31 ` [PATCH 15/28] dt-bindings: dpll: Add device tree bindings for DPLL device and pin Ivan Vecera
2025-04-07 18:01 ` Krzysztof Kozlowski [this message]
2025-04-07 18:10 ` Krzysztof Kozlowski
2025-04-08 5:19 ` Michal Schmidt
2025-04-09 7:09 ` Ivan Vecera
2025-04-07 17:31 ` [PATCH 16/28] dt-bindings: dpll: Add support for Microchip Azurite chip family Ivan Vecera
2025-04-07 18:04 ` Krzysztof Kozlowski
2025-04-09 7:19 ` Ivan Vecera
2025-04-10 7:01 ` Krzysztof Kozlowski
2025-04-10 10:28 ` Ivan Vecera
2025-04-10 12:19 ` Krzysztof Kozlowski
2025-04-10 12:38 ` Ivan Vecera
2025-04-07 17:31 ` [PATCH 17/28] dpll: zl3073x: Read DPLL types from firmware Ivan Vecera
2025-04-07 17:31 ` [PATCH 18/28] dpll: zl3073x: Read optional pin properties " Ivan Vecera
2025-04-07 18:06 ` Krzysztof Kozlowski
2025-04-09 7:22 ` Ivan Vecera
2025-04-07 17:31 ` [PATCH 19/28] dpll: zl3073x: Implement input pin selection in manual mode Ivan Vecera
2025-04-07 17:32 ` [PATCH 20/28] dpll: zl3073x: Add support to get/set priority on input pins Ivan Vecera
2025-04-07 17:32 ` [PATCH 21/28] dpll: zl3073x: Implement input pin state setting in automatic mode Ivan Vecera
2025-04-07 17:32 ` [PATCH 22/28] dpll: zl3073x: Add support to get/set frequency on input pins Ivan Vecera
2025-04-07 17:32 ` [PATCH 23/28] dpll: zl3073x: Add support to get/set frequency on output pins Ivan Vecera
2025-04-07 17:32 ` [PATCH 24/28] dpll: zl3073x: Read pin supported frequencies from firmware Ivan Vecera
2025-04-07 17:32 ` [PATCH 25/28] dpll: zl3073x: Add support to get phase offset on input pins Ivan Vecera
2025-04-07 17:32 ` [PATCH 26/28] dpll: zl3073x: Add support to get/set phase adjust on pins Ivan Vecera
2025-04-07 17:33 ` [PATCH 27/28] dpll: zl3073x: Add support to get/set esync " Ivan Vecera
2025-04-07 17:33 ` [PATCH 28/28] dpll: zl3073x: Add support to get fractional frequency offset on input pins Ivan Vecera
2025-04-07 18:06 ` [PATCH 00/28] Add Microchip ZL3073x support Andy Shevchenko
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=74172acd-e649-4613-a408-d1f61ceeba8b@kernel.org \
--to=krzk@kernel.org \
--cc=Prathosh.Satish@microchip.com \
--cc=akpm@linux-foundation.org \
--cc=andy@kernel.org \
--cc=arkadiusz.kubalewski@intel.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kees@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=robh@kernel.org \
--cc=vadim.fedorenko@linux.dev \
/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;
as well as URLs for NNTP newsgroup(s).