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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Apr 2022 02:29:48 +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

On Mon, Apr 11, 2022 at 02:33:15PM -0700, Jakub Kicinski wrote:
> On Mon, 11 Apr 2022 22:59:59 +0200 Andrew Lunn wrote:
> > > 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.
> 
> I see. Why would the MAC/SoC care if the clock is recovered or free
> running, tho?

Autoneg determines which link peer will be the master and which will
be the slave. The master provides the clock for the link. So the slave
PHY might want to pass through the recovered clock so it does not need
to deal with drift between the recovered clock and its own clock.

   Andrew