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]

Message-ID: <20220411143315.6cd5484e@kernel.org>
Date:   Mon, 11 Apr 2022 14:33:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
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, 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?