Re: [PATCH net-next v8 02/15] dt-bindings: dpll: add SiTime SiT95316 clock generator

[Ali Rouhi]

Reply inline.

> Is the statement that "every valid value exceeds the 32 bits '-hz' allows"
> correct?  A "-hz" property can carry 64-bit values, so the stated reason for
> dropping the unit suffix does not seem to hold. [...] could the property be
> named sitime,pll-fvco-hz while keeping
> $ref: /schemas/types.yaml#/definitions/uint64-array [...]

The description's 32-bit rationale was wrong and is corrected in v9.
The rename itself, however, does not pass dt_binding_check.

dtschema types unit-suffix properties centrally: property-units.yaml maps the
"-hz" suffix to uint32-matrix (only "opp-hz" is defined as 64-bit), and the
meta-schema rejects a type $ref on any property matching a unit-suffix pattern
("Standard unit suffix properties don't need a type $ref").  So
"sitime,pll-fvco-hz" with an explicit uint64-array $ref fails validation, and
without the $ref the values are typed as 32-bit cells, which cannot carry a
VCO frequency (4.9-7.8 GHz).  Verified with dt-doc-validate (dtschema 2026.6):
the renamed property produces exactly those two errors.

The examples cited work because they are not new vendor properties:
"supported-frequencies-hz" is typed 64-bit by the dpll-pin.yaml schema itself
and "opp-hz" by property-units.yaml.  A new vendor property has no such hook,
so the name stays suffix-less with the explicit uint64-array $ref, and the v9
description now states this real constraint instead of the 32-bit claim.