Re: [PATCH net-next v12 07/12] dpll: sit9531x: add support to get and set priority on input pins

[Ivan Vecera <ivecera@redhat.com>]

On 10/9/26 20:31, Ali Rouhi wrote:
> From: Oleg Zadorozhnyi <Oleg.Zadorozhnyi@devoxsoftware.com>
> 
> 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@devoxsoftware.com>
> Assisted-by: LLM
> Signed-off-by: Ali Rouhi <arouhi@sitime.com>
> ---
Reviewed-by: Ivan Vecera <ivecera@redhat.com>