[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YlSWz+XELKV3LK8s@lunn.ch>
Date: Mon, 11 Apr 2022 22:59:59 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Josua Mayer <josua@...id-run.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
netdev@...r.kernel.org, alvaro.karsz@...id-run.com,
Michael Hennerich <michael.hennerich@...log.com>,
"David S. Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Alexandru Ardelean <alexandru.ardelean@...log.com>
Subject: Re: [PATCH 1/3] dt: adin: document clk-out property
> 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.
It is not necessarily SyncE. Fast Ethernet is based around a 25MHz
clock. Something needs to provide that clock. Sometimes the SoC/MAC
provides it, and passes it to the PHY. Sometimes the PHY provides it,
and passes it to the SoC/MAC.
There are a couple of PHYs which make use of the common clock
framework, when the SoC is the clock source. However, i don't think
there are any PHYs which provide a clock to the common clock framework
when they are the source. We do however have a number of vendor
properties to control the PHY clock output, disable the PHY clock
output, select the PHY clock output, etc. There is not too much
standardisation here, and it is made worse by some PHYs needing a
reset once the clock is ticking, some MACs stop the clock when the
link is administrative down, some PHYs stop the clock a short time
after the link goes down which can be bad for the MAC etc.
Andrew
Powered by blists - more mailing lists