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

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

```text
On 11/5/26 16:18, Petr Oros wrote:
> Add a test that sets a new priority on an input pin, reads it back and
> restores the original value. The range of priorities a device accepts is
> not advertised over netlink, so the test tries one below the current
> value and then the small values every driver accepts, since a large
> current value may mark an unused pin outside the settable range, as the
> ice driver does with 255. A driver may still refuse all of them for a
> constraint the interface does not tell, so that is a skip on a device
> provided by the user, with the reason the tool reported, and a failure
> on the device the script created, whose simulator accepts every
> priority. The test skips when the dpll tool lacks the prio 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 does not
> advertise the priority-can-change capability or does not report a
> priority is a skip on a device provided by the user and a failure on the
> device the script created, whose pins have both.
>
> The dpllsim_add_pin helper gains an optional priority argument, which is
> written only when it is given, so that a pin without one keeps the
> default of the simulator. A priority is accepted for input pins only,
> so the callers pass one for those alone.
>
> The standard device lays its inputs out as gnss0 with priority 0 and
> ext0 with priority 1, and the stress devices get random priorities on
> their input pins.
>
> Signed-off-by: Petr Oros<redacted>

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

```