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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50252a5a-e4fb-42d3-b838-9ef04faf4c5c@lunn.ch>
Date: Thu, 4 Jan 2024 14:57:07 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jie Luo <quic_luoj@...cinc.com>
Cc: Christian Marangi <ansuelsmth@...il.com>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
	hkallweit1@...il.com, corbet@....net, p.zabel@...gutronix.de,
	f.fainelli@...il.com, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH v8 14/14] dt-bindings: net: ar803x: add qca8084 PHY
 properties

> 1. For IPQ SoC series, there are only ipq4019, ipq5018, ipq6018,
> ipq8074 documented in the current dt-bindings doc qcom,ipq4019-mdio.yaml
> and ipq9574, ipq5332 that are being added by the MDIO patch, and one
> more ipq8064 whose MDIO driver is mdio-ipq8064.c, on more others.
> 
> 2. For qca8084(pure PHY chip), which is the quad-phy chip, which is just
>    like qca8081 PHY(single port PHY), each port can be linked to maximum
>    speed 2.5G.
> 
>    For qca8386(switch chip), which includes the same PHY CHIP as qca8084
>    (4 physical ports and two CPU ports), qca8386 switch can work with
>    the current qca8k.c DSA driver with the supplement patches.

Is the qca8386 purely a switch plus integrated PHYs? There is no CPU
on it? What is the management path? MDIO?

> 
>    Both qca8084 and qca8386 includes same network clock controller(let's
>    call it NSSCC, since this clock controller is located in the
>    Ethernet chip qca8084 and qca8386), they have the same clock initial
>    configuration sequence to initialize the Ethernet chip.

You said For "qca8084(pure PHY chip)". Here you just called it an
Ethernet chip? To me, and Ethernet chip is a MAC, Intel e1000e etc.
Do you now see how your explanations are confusing. Is it s pure PHY,
or is it an Ethernet chip?

O.K. Since we are getting nowhere at the moment, lets take just the
pure PHY chip, and ignore the rest for the moment.

For any pure PHY, there is generally one clock input, which might be a
crystal, or an actual clock. If you look at other DT bindings for
PHYs, it is only listed if the clock is expected to come from
somewhere else, like a SoC, and it needs to be turned on before the
PHY will work. And generally, a pure PHY has one defined clock
frequency input. If that is true, there is no need to specify the
clock. If multiple clock input frequencies are supported, then you do
need to specify the clock, so its possible to work out what frequency
it is using. How that clock input is then used internally in the PHY
is not described in DT, but the driver can set any dividers, PLLs
needed etc.

So, for the pure PHY chip, what is the pinout? Is there one clock
input? Or 4 clock inputs, one per PHY in the quad package? Typically,
where does this/these clocks come from? Is the frequency fixed by the
design, or are a number of input frequencies supported?

>   The Ethernet chip qca8084 and qca8386 are only connected with IPQ SoC,
>   Currently qca8084 is connected with IPQ SoC by 10G-QXGMII mode.
>   the 4 PHYs of qca8386 are connected with the internal MAC of qca8386
>   by GMII, the maximum speed is also 2.5G.
>   The port4 of qca8084 or qca8386 is optionally be able to connected
>   with IPQ SoC by sgmii.

To some extent, this does not matter. The DT binding and the driver
should not care what the pure PHY is connected to. It has standardised
ports, so in theory it could be connected to any vendors MAC.

Please be very careful with your wording. Because computers
instructions should be unambiguous, it does what it is told, we also
expect computer scientists to be unambiguous. Wording is very
important.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ