# Re: \[PATCH net-next v2 10/14\] selftests: dpll: add pin frequency test

- From: Ivan Vecera \<ivecera@redhat.com\>
- Date: 2026-11-06 10:51:15 
- List: netdev
- Page: https://ratatoskr.run/netdev/2026/11/17877446
- Thread: https://ratatoskr.run/netdev/2026/11/17871508/t.md

```text
On 11/5/26 16:18, Petr Oros wrote:
> Add a test that picks a supported frequency other than the current one
> from the frequency-supported list of an input pin, sets it, reads it
> back and restores the original value. Both ends of every advertised
> range are candidates, so that a pin advertising a single range wider
> than one value still has one. It skips when the dpll tool lacks the
> frequency keyword of pin set, and the restore is deferred right after
> the original value is read so that an interrupted run restores it too.
> A pin that reports no frequency or advertises a single frequency only
> is a skip on a device provided by the user and a failure on the device
> the script created, whose pins advertise several.
>
> The driver may refuse the candidate. A driver without a frequency
> setter refuses every value with EOPNOTSUPP, and a driver with
> constraints of its own refuses values the advertised ranges allow,
> zl3073x for instance wants the frequencies of an output pair to divide
> each other. On a device provided by the user a refused set is a skip
> that names the reason the tool reported, which the setter keeps in
> DPLL_LAST_ERR, on the created device the simulator accepts every
> advertised value and the refusal is a failure. Once the set went
> through, a refused restore is a failure on either.
>
> Signed-off-by: Petr Oros<redacted>

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

```