Re: [PATCH net-next v12 07/12] dpll: sit9531x: add support to get and set priority on input pins
From: Ivan Vecera
Date: Tue Oct 13 2026 - 05:47:56 EST
On 10/9/26 20:31, Ali Rouhi wrote:
From: Oleg Zadorozhnyi <Oleg.Zadorozhnyi@xxxxxxxxxxxxxxxxx>Reviewed-by: Ivan Vecera <ivecera@xxxxxxxxxx>
When the device has to choose a reference, it takes the first slot of
its priority table that has signal. The driver keeps a
priority per input and PLL and builds the table from it (previous
patch), so getting a priority reads that value without touching a
register, and setting one records it and, for an input the PLL lists,
rewrites the table in the new order. When the new order puts a
different input with signal first, the PLL moves to it; a change further
down the table leaves the PLL where it is.
Priority and state are separate attributes, and neither moves the other.
A priority can be set on a disconnected input and takes effect when it is
connected; disconnecting an input and connecting it again brings back the
priority it had. Setting one input's priority leaves every other input's
as it was, so the named pin is the only one whose priority changes and
the core's own notification covers that; when the new order moves the
active selection, the siblings' operational state follows on the next
poll. A priority the table write refused is not kept: the configured
value goes back to what it was, so nothing reports a priority the
device never took. The range is 0 to 255 against a table of eleven slots:
inputs of equal priority keep the order the table already has them in,
so distinct values are what fix an order. An input the PLL has never
listed reports the lowest slot, the priority it would be connected at.
A table rewritten behind the driver -- a profile reload, a direct I2C
tool -- is taken as the new configuration and the priorities are
re-seeded from it, so the poll now watches priority and operational state
as well as state, and notifies a pin when any of them moves. The
notifications go out after the walk over the pins, outside multiop_lock,
since the helper takes locks the callbacks run under.
A pin's baseline for that watch -- state, operational state and priority
-- is taken when the pin is registered, under the device lock, rather
than by the first tick, so a change between the probe-time fetch and
that tick is reported instead of absorbed into the baseline. The device
lock status is seeded the same way, so the first tick announces only
what moved since registration.
Signed-off-by: Oleg Zadorozhnyi <Oleg.Zadorozhnyi@xxxxxxxxxxxxxxxxx>
Assisted-by: LLM
Signed-off-by: Ali Rouhi <arouhi@xxxxxxxxxx>
---