Re: [PATCH v2 net-next 3/8] dpll: extend pin notifier and netlink events with notification source ID

[Jiri Pirko <jiri@resnulli.us>]

Sat, Mar 21, 2026 at 11:26:22PM +0100, grzegorz.nitka@intel.com wrote:
>Extend the DPLL pin notification API to include a source identifier
>indicating where the notification originates. This allows notifier
>consumers and netlink listeners to distinguish between notifications
>coming from an associated DPLL instance, a parent pin, or the pin
>itself.
>
>A new field, src_id, is added to struct dpll_pin_notifier_info and is
>passed through all pin-related notification paths. Callers of
>dpll_pin_notify() are updated to provide a meaningful source identifier
>based on their context:
>  - pin registration/unregistration use the DPLL's clock_id,
>  - pin-on-pin operations use the parent pin's clock_id,
>  - pin changes use the pin's own clock_id.
>
>This enables richer event routing and more accurate state handling in
>user space and in-kernel consumers.
>
>The current DPLL pin notification infrastructure does not provide any
>way to identify where a pin-related notification originates. Both the
>in-kernel notifier chain and the netlink notification path only carry
>information about the pin itself, not about the component that triggered
>the event.
>
>This becomes problematic on platforms where multiple DPLL devices or
>drivers share the same physical pin via firmware description (fwnode).
>In such setups pin creation, deletion, or state changes can be triggered
>from several independent contexts:
>
>  - from the DPLL device that owns the pin,
>  - from another DPLL device that re-registers or rebinds the same
>    fwnode-described pin,
>  - or from a pin-on-pin relationship (parent pin registering child
>    pins).
>
>Without a source identifier all these notifications look identical to
>listeners. Drivers cannot reliably determine whether a received event
>is a result of their own registration/unregistration actions or
>originated from a different DPLL instance. This leads to several types
>of problems:
>
>  * risk of duplicate pin registration when a driver reacts to its own
>    event,
>  * difficulty suppressing notifications that are merely internal
>    bookkeeping side effects,
>  * inability to implement correct pin‑multiplexing or cross‑device
>    synchronization logic when pins are shared across fwnode domains.
>
>To address this, extend `struct dpll_pin_notifier_info` with a new
>`src_id` field that identifies the originator of the event. The DPLL
>core sets this field for all pin notifications:
>
>  - pin registration/unregistration: the source is the clock_id of the
>    DPLL initiating the operation,
>  - pin-on-pin relationships: the source is the parent pin's clock_id,
>  - pin property/state updates: the source is the pin's own clock_id.
>
>Netlink notifications now also carry this additional field.
>
>With this information notifier consumers can differentiate true external
>events from internal ones and ignore the latter when appropriate.
>As shown later in this series, ICE/E825 devices rely on this to avoid
>reacting to the events that their own registration logic triggers
>when a shared-fwnode pin appears.
>
>This change only extends the notification metadata and does not alter
>existing semantics for drivers that do not use the new field.
>

This lenghty and verbose AI-generated patch description are so annoying.
Care to cut it down to something like 1/8 without unnecessary things?