Re: [PATCH net-next v8 04/15] dpll: sit9531x: read DPLL types and pin properties from system firmware

[Ali Rouhi]

Replies inline.

> Does the XO pin end up with two sources of truth for its frequency here?
> [...] Would it be simpler to skip the frequency-seeding path for index
> SIT9531X_MAX_INPUTS the same way both INTSYNC pins already are?

Yes -- fixed in v9: the seeding path now skips the XO index, so the
clk_get_rate()/clock-frequency value read at probe stays the only source of
the XO rate.

> Can the "int-oscillator" and "synce-eth-port" comparisons ever match?
> [...] Should they just be dropped, or should the binding gain the aliases?

Dropped in v9.  Only the enum values the dpll-pin.yaml binding allows
are compared now.

> Should the return value of fwnode_property_read_u64_array() be checked
> before freqs[] is consumed?

Yes -- fixed in v9: the return value is checked, the failure is
logged, and the frequency list is skipped rather than publishing kcalloc
zeroes as supported rates.

> Does the appended catch-all range make the firmware-declared frequency list
> meaningless, and does it publish a capability set the driver cannot honour?

Reworked in v9: pins now advertise only the concrete firmware-listed
values plus the current rate.  The wide fallback range remains
only for output pins whose firmware node lists no frequencies, because those
pins genuinely do support frequency_set and would otherwise advertise nothing
settable.  The XO pin and input pins no longer get the catch-all, and a pin
with no known frequency no longer advertises 0 Hz.