netdev - Re: [PATCH v4 1/3] dt-bindings: net: adin: document phy clock

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: <bfe71846f940be3c410ae987569ddfbf@walle.cc>
Date:   Thu, 12 May 2022 23:20:18 +0200
From:   Michael Walle <michael@...le.cc>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     alexandru.ardelean@...log.com, alvaro.karsz@...id-run.com,
        davem@...emloft.net, edumazet@...gle.com, josua@...id-run.com,
        krzysztof.kozlowski+dt@...aro.org, michael.hennerich@...log.com,
        netdev@...r.kernel.org, pabeni@...hat.com, robh+dt@...nel.org
Subject: Re: [PATCH v4 1/3] dt-bindings: net: adin: document phy clock

Am 2022-05-11 21:42, schrieb Jakub Kicinski:
> On Wed, 11 May 2022 19:10:36 +0200 Michael Walle wrote:
>> Am 2022-05-11 18:11, schrieb Jakub Kicinski:
>> > On Wed, 11 May 2022 14:58:55 +0200 Michael Walle wrote:
>> >> FWIW, the recovered clock only works if there is a link. AFAIR on the
>> >> AR8031 you can have the free-running one enabled even if there is no
>> >> link, which might sometimes be useful.
>> >
>> > Is that true for all PHYs? I've seen "larger" devices mention holdover
>> > or some other form of automatic fallback in the DPLL if input clock is
>> > lost.
>> 
>> I certainly can't speak of 'all' PHYs, who can ;) But how is the
>> switchover for example? hitless? will there be a brief period of
>> no clock at all?
>> 
>> The point I wanted to add is that the user should have the choice or
>> at least you should clearly mention that. If you drop the suffix and
>> just
>> use "25mhz" is that now the recovered one or the free-running one. And
>> why is that one preferred over the other? Eg. if I were a designer for 
>> a
>> cheapo board and I'd need a 125MHz clock and want to save some bucks
>> for the 125MHz osc and the PHY could supply one, I'd use the
>> free-running mode. Just to avoid any surprises with a switchover
>> or whatever.
> 
> It's pure speculation on my side. I don't even know if PHYs use
> the recovered clock to clock its output towards the MAC or that's
> a different clock domain.
> 
> My concern is that people will start to use DT to configure SyncE which
> is entirely a runtime-controllable thing, and doesn't belong. Hence
> my preference to hide the recovered vs free-running detail if we can
> pick one that makes most sense for now.

I see. That makes sense, but then wouldn't it make more sense to pick
the (simple) free-running one? As for SyncE you'd need the recovered
clock.

> Again, if you feel strongly that the current design is indeed needed
> to configure pure SOC<>PHY / MAC<>PHY clocking, just send a review tag
> and I'll apply :)

I just wanted to add my two cents :) I'm fine with either one.

>> > I thought that's the case here, too:
>> 
>> I read "reference" as being the 25MHz (maybe when the PHY is in 10Mbit
>> mode? I didn't read the datasheet) because the first mode is called
>> 25mhz-reference. So it might be switching between 25MHz and 125MHz?
>> I don't know.
> 
> I couldn't grok that from the datasheet. Anyway, it'd be good to make
> it clearer that the second sentence refers to the "adaptive" mode and
> not the behavior of the recovered clock when lock is lost. Just put
> (adaptive) in the sentence somewhere.

Mh, there is not much there, whatever "heartbeat clock" means.

-michael