Wed, Mar 25, 2026 at 10:55:27AM +0100, [email protected] wrote: >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?
Ah, sorry, I forgot time flows only one direction :)
