linux-kernel - [PATCH net-next v2 2/2] dt-bindings: net: microchip,ksz: document microchip,rmii-clk-internal

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: <20231017090403.18416-1-ante.knezic@helmholz.de>
Date:   Tue, 17 Oct 2023 11:04:03 +0200
From:   Ante Knezic <ante.knezic@...mholz.de>
To:     <conor@...nel.org>
CC:     <andrew@...n.ch>, <ante.knezic@...mholz.de>, <conor+dt@...nel.org>,
        <davem@...emloft.net>, <devicetree@...r.kernel.org>,
        <edumazet@...gle.com>, <f.fainelli@...il.com>,
        <krzysztof.kozlowski+dt@...aro.org>, <kuba@...nel.org>,
        <linux-kernel@...r.kernel.org>, <marex@...x.de>,
        <netdev@...r.kernel.org>, <olteanv@...il.com>, <pabeni@...hat.com>,
        <robh+dt@...nel.org>, <woojung.huh@...rochip.com>
Subject: [PATCH net-next v2 2/2] dt-bindings: net: microchip,ksz: document microchip,rmii-clk-internal

On Tue, 17 Oct 2023 09:00:15 +0100, Conor Dooley wrote:

> > In both cases (external and internal), the KSZ88X3 is actually providing the
> > RMII reference clock.
> > Difference is only will the clock be routed as external
> > copper track (pin REFCLKO -> pin REFCLKI), or will it be routed internally.
> 
> The switch always provides it's own external reference, wut? Why would
> anyone actually bother doing this instead of just using the internal
> reference?

Thats a good question... Other KSZ chips don't have the ability to route clock
internally, and these two (ksz8863 and ksz8873) are actually by default the
expecting to route it externally. Why this is so is a matter of HW design. 
The KSZ88x3 does not have to provide the reference clock, it can be provided 
externally, by some other device, for example the uC. 
BUT in case when it is provided by the switch we have the option to route the 
internal block that is generating the clock to the clock input externally 
(as a copper track) or internally.
To quote the manual:
"When EN_REFCLKO_3 is high, KSZ8863RLL outputs a 50 MHz in REFCLKO_3. 
Register 198 bit [3] is used to select the internal or external reference clock.
Internal reference clock means that the clock for the RMII of KSZ8863RLL is
provided by KSZ8863RLL internally and the REFCLKI_3 pin is unconnected. For the 
external reference clock, the clock provides to KSZ8863RLL via REFCLKI_3.
If KSZ8863RLL does not provide the reference clock, this 50 MHz reference clock
with divide-by-2 (25 MHz) has to be used in X1 pin instead of the 25 MHz 
crystal, since the clock skew of these two clock sources impacts the RMII timing
before Rev A3 part. The Rev A3 part can connect the external 50 MHz reference 
clock to X1 pin and SMTXC3/REFCLKI_3 pins directly with strap pins of pin 17 
SMTXD33/EN_REFCLKO_3 and pin 18 SMTXD32 to be pulled down."

> > So, this should not affect the clock relation between the uC and the switch
> > device?
> 
> > This property has no effect if KSZ88X3 is not providing the reference clock.

> This appears to contradict with the above, unless I am misunderstanding
> something.

There are actually 5 RMII clock configuration modes depending on the
setting of the EN_REFCLKO_3, register 0xC6 and SMTXD32 pin (which affects
the expected clock, 25 or 50 Mhz), but the patch covers the case in which
the switch is generating the reference clock (outputing it to REFCLKO_3), 
because EN_REFCLK0_3 is pulled up. By clearing/setting the 0xC6 bit 3 we can 
choose whether to connect the REFCLKO to REFCLKI externally, or internally.

If reference clock is being provided to the ksz88x3 by some other device,
then there is no point in setting the 0xC6 bit 3 because other device is 
providing the clock to REFCLKI_3 and REFCLKO should not be connected and 
should not generate the clock (as EN_REFCLKI is pulled down).

> What I would have expected to see is that when the reference clock is
> provided externally that there would be a clocks property in the DT
> node, pointing at that external clock & when there was not, then
> no property. Likely that ship has already said, as I don't see clocks
> present in the current binding. How does the driver get the frequency of
> the RMII reference clock when an external reference is provided?

In case when ksz88x3 is generating the reference clock the devices rmii 
interface should be configured to external clock usage, for example something
like rmii-clock-ext for TI cpsw. This should be true regardles of whether
the ksz88x3 node has "microchip,rmii-clk-internal" set or not.