Re: [PATCH net-next v5 1/4] dpll: add DPLL_PIN_TYPE_INT_NCO pin type

[Vadim Fedorenko]

On 25/06/2026 09:45, Jiri Pirko wrote:
> Wed, Jun 24, 2026 at 05:57:35PM +0200, vadim.fedorenko@xxxxxxxxx wrote:
> > On 19/06/2026 18:07, Ivan Vecera wrote:
>
> [...]
>
> > > Proposal:
> > > 1) new pin capability
> > >      - name: state-connected-override
> > >      - doc: pin state can be changed to connected in any DPLL mode
> > >
> > > 2) new NCO pin type to switch the DPLL to NCO mode when connected
> > >
> > > 3) automatic-only DPLL
> > >      - should expose NCO pin with state-connected-override capability
> > >
> > > 4) manual-only DPLL
> > >     - does not need to expose NCO pin with state-connected-override cap
> > >
> > > 5) dual-mode DPLL (supporting mode switching)
> > >     - if it exposes NCO pin with the override cap then it has to support
> > >       switching to NCO mode directly from AUTO mode
> > >     - if does not expose NCO pin with the override cap then a user MUST
> > >       switch the DPLL mode from AUTO to MANUAL to be able to make NCO
> > >       pin connected to the DPLL
> >
> > I still don't see good reasoning for the pin. Even this sentence says
> > "DPLL mode" which keeps me thinking whether we have to move it to a
> > special DPLL mode. All these items look like overcomplication of a
> > simple function of the device itself. DPLL can be either in the closed
> > loop when one of the pins provides a signal to align to, or in the open
> > loop meaning that software can control adjustments to phase/frequency.
> > But it's definitely a property of the device, and it's not a pin in any
> > kind...
>
> Vadim, did you see this:
> https://lore.kernel.org/all/aiftnkuT9IP31qUm@FV6GYCPJ69/ ?
> I very thoroughly described what you are questioning. There is 0 reply
> to that email so perhaps you missed it? IDK.

Hi Jiri,

Yeah, I was traveling a lot lately, and looks like I missed it. I'll
reply in that thread.

Thanks!