Tue, May 26, 2026 at 11:34:14AM +0200, [email protected] wrote: >Extend the DPLL pin notification API to include a source identifier >indicating where the notification originates. This allows notifier >consumers to distinguish between notifications coming from >an associated DPLL instance, a parent pin, or the pin itself. > >A new field, src_clock_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 uses 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. > >As introduced in the commit ("dpll: allow registering FW-identified pin >with a different DPLL"), it is possible to share the same physical pin >via firmware description (fwnode) with DPLL objects from different >kernel modules. This means that a given pin can be registered multiple >times. > >Driver such as ICE (E825 devices) rely on this mechanism when listening >for the event where a shared-fwnode pin appears, while avoiding reacting >to events triggered by their own registration logic. > >This change only extends the notification metadata and does not alter >existing semantics for drivers that do not use the new field. > >Reviewed-by: Arkadiusz Kubalewski <[email protected]> >Reviewed-by: Aleksandr Loktionov <[email protected]> >Signed-off-by: Grzegorz Nitka <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
