Re: [PATCH net-next v8 15/15] dpll: sit9531x: allow the device tree to override two board facts

[Ali Rouhi]

Replies inline.

> Is the free-run rationale here consistent with the code the property feeds?
> [...] Should that clamp bypass be called out [...]?

Yes to both -- the v9 changelog names INTSYNC (not free-run)
as the configuration where Fref*DIVN does not reproduce the VCO, consistent
with the kernel-doc and the binding text, and mentions that a present override
bypasses the band clamp (with the new DIVO width guard bounding the effect,
see below).

> Should the return value of this read be checked?

Yes -- fixed in v9: the read result is checked and a malformed
property is reported with a warning instead of being silently
indistinguishable from an absent one.

> Can an out-of-range Fvco here silently misprogram DIVO?

Closed from both ends in v9: an out-of-band VCO override is dropped
with a warning at parse time, and independently the frequency setter rejects
any DIVO that does not fit the 34-bit field instead of truncating it.

> Should the element values be validated before they are narrowed into the u8
> out_pll_map[]?

Yes -- fixed in v9: every element is validated against the binding's
enum (0-3 or 255); anything else rejects the property with a warning, so a
bad entry can neither unroute a live output nor mark an output routed to a
PLL that does not drive it.