The SyncE_Ref pin may operate as either an active or inactive reference
depending on board design and system configuration. Some platforms need
to disable the SyncE reference dynamically (e.g., when selecting a
different recovered clock input). The hardware supports toggling this
pin, therefore advertise the STATE_CAN_CHANGE capability.
Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
---
drivers/dpll/zl3073x/prop.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/dpll/zl3073x/prop.c b/drivers/dpll/zl3073x/prop.c
index ac9d41d0f978..acd7061a741a 100644
--- a/drivers/dpll/zl3073x/prop.c
+++ b/drivers/dpll/zl3073x/prop.c
@@ -215,6 +215,15 @@ struct zl3073x_pin_props *zl3073x_pin_props_get(struct zl3073x_dev *zldev,
props->dpll_props.type = DPLL_PIN_TYPE_GNSS;
+ /*
+ * The SyncE_Ref pin supports enabling/disabling dynamically.
+ * Some platforms may choose to expose this through firmware
+ * configuration later. For now, advertise this capability
+ * universally since the hardware allows state toggling.
+ */
+ props->dpll_props.capabilities |=
+ DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE;
+
/* The output pin phase adjustment granularity equals half of
* the synth frequency count.
*/
--
2.39.3
On 3/21/26 11:26 PM, Grzegorz Nitka wrote: > The SyncE_Ref pin may operate as either an active or inactive reference > depending on board design and system configuration. Some platforms need > to disable the SyncE reference dynamically (e.g., when selecting a > different recovered clock input). The hardware supports toggling this > pin, therefore advertise the STATE_CAN_CHANGE capability. > > Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> > Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> > --- > drivers/dpll/zl3073x/prop.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/dpll/zl3073x/prop.c b/drivers/dpll/zl3073x/prop.c > index ac9d41d0f978..acd7061a741a 100644 > --- a/drivers/dpll/zl3073x/prop.c > +++ b/drivers/dpll/zl3073x/prop.c > @@ -215,6 +215,15 @@ struct zl3073x_pin_props *zl3073x_pin_props_get(struct zl3073x_dev *zldev, > > props->dpll_props.type = DPLL_PIN_TYPE_GNSS; > > + /* > + * The SyncE_Ref pin supports enabling/disabling dynamically. > + * Some platforms may choose to expose this through firmware > + * configuration later. For now, advertise this capability > + * universally since the hardware allows state toggling. > + */ > + props->dpll_props.capabilities |= > + DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE; > + > /* The output pin phase adjustment granularity equals half of > * the synth frequency count. > */ I'm wondering about the purpose of this flag, or rather the need to set it manually from the driver. Surely, the existence of the state_on_dpll_set() or state_on_pin_set() callback clearly indicates this capability. Wouldn't it be simpler for the core to set it directly based on this? Ivan
> -----Original Message-----
> From: Ivan Vecera <ivecera@redhat.com>
> Sent: Tuesday, March 24, 2026 3:44 PM
> To: Nitka, Grzegorz <grzegorz.nitka@intel.com>; netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Oros, Petr
> <poros@redhat.com>; richardcochran@gmail.com;
> andrew+netdev@lunn.ch; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Prathosh.Satish@microchip.com;
> jiri@resnulli.us; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>;
> vadim.fedorenko@linux.dev; donald.hunter@gmail.com;
> horms@kernel.org; pabeni@redhat.com; kuba@kernel.org;
> davem@davemloft.net; edumazet@google.com; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Subject: Re: [PATCH v2 net-next 4/8] dpll: zl3073x: allow SyncE_Ref pin state
> change
>
> On 3/21/26 11:26 PM, Grzegorz Nitka wrote:
> > The SyncE_Ref pin may operate as either an active or inactive reference
> > depending on board design and system configuration. Some platforms
> need
> > to disable the SyncE reference dynamically (e.g., when selecting a
> > different recovered clock input). The hardware supports toggling this
> > pin, therefore advertise the STATE_CAN_CHANGE capability.
> >
> > Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> > ---
> > drivers/dpll/zl3073x/prop.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/dpll/zl3073x/prop.c b/drivers/dpll/zl3073x/prop.c
> > index ac9d41d0f978..acd7061a741a 100644
> > --- a/drivers/dpll/zl3073x/prop.c
> > +++ b/drivers/dpll/zl3073x/prop.c
> > @@ -215,6 +215,15 @@ struct zl3073x_pin_props
> *zl3073x_pin_props_get(struct zl3073x_dev *zldev,
> >
> > props->dpll_props.type = DPLL_PIN_TYPE_GNSS;
> >
> > + /*
> > + * The SyncE_Ref pin supports enabling/disabling dynamically.
> > + * Some platforms may choose to expose this through
> firmware
> > + * configuration later. For now, advertise this capability
> > + * universally since the hardware allows state toggling.
> > + */
> > + props->dpll_props.capabilities |=
> > + DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE;
> > +
> > /* The output pin phase adjustment granularity equals half of
> > * the synth frequency count.
> > */
>
> I'm wondering about the purpose of this flag, or rather the need to set
> it manually from the driver. Surely, the existence of the
> state_on_dpll_set() or state_on_pin_set() callback clearly indicates
> this capability.
>
> Wouldn't it be simpler for the core to set it directly based on this?
>
> Ivan
Hi Ivan, thanks for your review!
Yeah, I don't like the way I implemented it, but it was the simplest way.
It was more about to introduce what's needed to achieve this patchset goal.
According to your suggestion, I gave it a try with such a simple change
on pin registration (of course we need that also for pin_on_pin):
@@ -896,6 +896,9 @@ dpll_pin_register(struct dpll_device *dpll, struct dpll_pin *pin,
}
ret = __dpll_pin_register(dpll, pin, ops, priv, NULL);
+
+ if (!ret && ops->state_on_dpll_set)
+ pin->prop.capabilities |= DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE;
and it of course works.
My concern is that it's a kind of implicit property/capability enablement.
Will wait on more feedback on this.
Grzegorz
© 2016 - 2026 Red Hat, Inc.