RE: [PATCH v4 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: Sunday, March 29, 2026 1:25 PM
> 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 v4 net-next 3/8] dpll: extend pin notifier and netlink
> events with notification source ID
> 
> Thu, Mar 26, 2026 at 05:28:27PM +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 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 <arkadiusz.kubalewski@xxxxxxxxx>
> >Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@xxxxxxxxx>
> >Signed-off-by: Grzegorz Nitka <grzegorz.nitka@xxxxxxxxx>
> >---
> > drivers/dpll/dpll_core.c    | 14 ++++++++------
> > drivers/dpll/dpll_core.h    |  2 +-
> > drivers/dpll/dpll_netlink.c | 10 +++++-----
> > drivers/dpll/dpll_netlink.h |  4 ++--
> > include/linux/dpll.h        |  1 +
> > 5 files changed, 17 insertions(+), 14 deletions(-)
> >
> >diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c
> >index 55ad03977d6d..c7fcae76c3f5 100644
> >--- a/drivers/dpll/dpll_core.c
> >+++ b/drivers/dpll/dpll_core.c
> >@@ -71,7 +71,8 @@ void dpll_device_notify(struct dpll_device *dpll,
> unsigned long action)
> > 	call_dpll_notifiers(action, &info);
> > }
> >
> >-void dpll_pin_notify(struct dpll_pin *pin, unsigned long action)
> >+void dpll_pin_notify(struct dpll_pin *pin, u64 ntfy_src,
> 
> I don't see the reason for "ntfy_" prefix here. Also. It's src_clock_id.
> 
> Could you perhaps consistently name this "src_clock_id" here and in the
> info struct as well?
> 
> Thanks!
> 
> [..]

Sure, will update it. Most likely it came from very early development, when
I wasn't 100% sure it will be clock_id.
To be updated in the next iteration.

Thanks!

Grzegorz