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

[Nitka, Grzegorz]

> -----Original Message-----
> From: Jiri Pirko <jiri@xxxxxxxxxxx>
> Sent: Wednesday, March 25, 2026 10:59 AM
> To: Nitka, Grzegorz <grzegorz.nitka@xxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; intel-wired-
> lan@xxxxxxxxxxxxxxxx; Oros, Petr <poros@xxxxxxxxxx>;
> richardcochran@xxxxxxxxx; andrew+netdev@xxxxxxx; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; Prathosh.Satish@xxxxxxxxxxxxx; Vecera,
> Ivan <ivecera@xxxxxxxxxx>; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@xxxxxxxxx>; vadim.fedorenko@xxxxxxxxx;
> donald.hunter@xxxxxxxxx; horms@xxxxxxxxxx; pabeni@xxxxxxxxxx;
> kuba@xxxxxxxxxx; davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx;
> Loktionov, Aleksandr <aleksandr.loktionov@xxxxxxxxx>
> Subject: Re: [PATCH v3 net-next 3/8] dpll: extend pin notifier and netlink
> events with notification source ID
> 
> Wed, Mar 25, 2026 at 10:55:27AM +0100, jiri@xxxxxxxxxxx wrote:
> >Mon, Mar 23, 2026 at 11:21:28PM +0100, grzegorz.nitka@xxxxxxxxx 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 :)

Hi Jiri. Thanks for your review!
Yes, v3 was already there, once you submitted comment in v2.
Sure, I'm going to update the commit message in the next iteration.

Regards

Grzegorz