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

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

On 25/06/2026 09:45, Jiri Pirko wrote:
> Wed, Jun 24, 2026 at 05:57:35PM +0200, vadim.fedorenko@linux.dev 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!