Subject: Re: [PATCH 1/3] dt: adin: document clk-out property

From: Jakub Kicinski <[email-masked]>
Date: Mon, 11 Apr 2022 13:07:15 -0700

On Mon, 11 Apr 2022 10:42:18 +0300 Josua Mayer wrote:
> > The binding should describe the hardware, not implementation in Linux,
> > therefore you should actually list all possible choices. The driver then
> > can just return EINVAL on unsupported choices (or map them back to only
> > one supported).  
> 
> I have prepared a draft for the entries that should exist, it covers 
> five of the 6 available bits. Maybe you can comment if this is 
> understandable?
> 
>    adi,phy-output-clock:
>      description: Select clock output on GP_CLK pin. Three clocks are 
> available:
>        A 25MHz reference, a free-running 125MHz and a recovered 125MHz.
>        The phy can also automatically switch between the reference and the
>        respective 125MHz clocks based on its internal state.
>      $ref: /schemas/types.yaml#/definitions/string
>      enum:
>      - 25mhz-reference
>      - 125mhz-free-running
>      - 125mhz-recovered
>      - adaptive-free-running
>      - adaptive-recovered
> 
> Bit no. 3 (GE_REF_CLK_EN) is special in that it can be enabled 
> independently from the 5 choices above,
> and it controls a different pin. Therefore it deserves its own property, 
> perhaps a flag or boolean adi,phy-output-ref-clock.
> Any opinion if this should be added, or we can omit it completely?

Noob question - can you explain how this property describes HW?
I thought we had a framework for clock config, and did not require
vendor specific properties of this sort.

The recovered vs free running makes the entire thing sound like
a SyncE related knob, irrelevant to normal HW operation.