Re: [PATCH net-next v11 05/13] dpll: sit9531x: read DPLL types and pin properties from system firmware

[Ali Rouhi <arouhi@sitime.com>]

On Mon, 5 Oct 2026, netdev-bot+sashiko@kernel.org wrote:

Reply inline.

> [Severity: Medium]
> Do the bindings define an order for supported-frequencies-hz?
>
> The generic binding in dpll-pin.yaml describes it only as "List of
> supported frequencies for this pin, expressed in Hz.". The input-pins
> section of sitime,sit95316.yaml documents the reg numbering, but it says
> nothing about the first entry being the rate wired to the input. The commit
> message doesn't mention this rule either. It only appears in the comment
> above.

Right, and the binding is where it belongs.

The driver takes the first entry because an input has one rate: the one
wired to it. The part qualifies that rate, it does not select among
several, and there is no frequency set on an input.

> Since this ordering would become de facto DT ABI once boards ship, could the
> binding document it? Two other options: carry the wired rate in a separate
> property, or stop inferring the current rate from its position in the list.

v12 documents it. The input pins' supported-frequencies-hz now carries
a description stating that the property names the rate wired to the
input, as a single entry.

A maxItems constraint would have been the stronger form, but dtschema
types every -hz property as a uint32 matrix, so the single /bits/ 64
value of the example reads as two cells to the tooling and maxItems: 1
fails dt_binding_check. The description is what the schema language
allows here.