Re: [PATCH net-next] dpll: use pin owner's dpll ref for pin-level attribute setting

[Ivan Vecera]

Reply to Sashiko findings:

> dpll_pin_is_freq_supported() reads a u64:
>     u64 freq = nla_get_u64(a), old_freq;
> while the validator takes a u32:
>     static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u32 
freq)
> ...
> Would widening the helper parameter to u64 be worth folding in here?

Good catch. This is a pre-existing issue unrelated to the owner-ref
simplification. I'd prefer to fix it in a separate follow-up patch
rather than mixing it in.

> Should Documentation/driver-api/dpll.rst be updated in the same patch?
> ...
> Could both changes be mentioned in the commit message, which currently
> describes the patch only as removing "duplicate HW writes"?

Wull address in v2. Both dpll.rst sections ("Shared pins" and "SET
commands format") are updated. The commit message will describe the
-EOPNOTSUPP validation change (from scanning all owner-matching refs to
checking the single owner ref returned by dpll_pin_own_dpll_ref_first()).

> Is the ref_sync_set callback really DPLL-independent for zl3073x?
> ...
> does this leave the sync reference still armed as a selectable
> candidate in the priority tables of every other channel?
> ...
> If ref_sync_set does need per-registration invocation, should it keep
> the xa_for_each() fan-out while the other three setters move to the
> owner ref?

This is correct finding. zl3073x_dpll_input_pin_ref_sync_set() performs
a per-channel priority write that would only reach the first channel
after this simplification.

Rather than keeping xa_for_each() in the core for this one callback,
v2 will split the fix into a preparation patch (1/2) where the driver
itself iterates all DPLL channels via list_for_each_entry() and sets
priority to NONE on each one.

Ivan