> -----Original Message----- > From: Jiri Pirko <[email protected]> > Sent: Wednesday, March 25, 2026 10:59 AM > To: Nitka, Grzegorz <[email protected]> > Cc: [email protected]; [email protected]; intel-wired- > [email protected]; Oros, Petr <[email protected]>; > [email protected]; [email protected]; Kitszel, Przemyslaw > <[email protected]>; Nguyen, Anthony L > <[email protected]>; [email protected]; Vecera, > Ivan <[email protected]>; Kubalewski, Arkadiusz > <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > Loktionov, Aleksandr <[email protected]> > 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, [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 :)
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
