Mon, Mar 23, 2026 at 11:21:28PM +0100, [email protected] 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. >
I wonder, did you miss my comment to v2?
