Received-SPF: pass (google.com: domain of linux-kernel+bounces-17746-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <b427c89a-81a9-439f-905e-2a6632065b78@quicinc.com>
Date: Fri, 5 Jan 2024 18:26:55 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 14/14] dt-bindings: net: ar803x: add qca8084 PHY
 properties
To: Andrew Lunn <andrew@lunn.ch>
CC: Christian Marangi <ansuelsmth@gmail.com>,
        "Russell King (Oracle)"
	<linux@armlinux.org.uk>,
        <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
        <pabeni@redhat.com>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <hkallweit1@gmail.com>, <corbet@lwn.net>, <p.zabel@pengutronix.de>,
        <f.fainelli@gmail.com>, <netdev@vger.kernel.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-doc@vger.kernel.org>
References: <7c05b08a-bb6d-4fa1-8cee-c1051badc9d9@lunn.ch>
 <ZX2rU5OFcZFyBmGl@shell.armlinux.org.uk>
 <6abe5d6f-9d00-445f-8c81-9c89b9da3e0a@quicinc.com>
 <ZX3LqN8DSdKXqsYc@shell.armlinux.org.uk>
 <1bddd434-024c-45ff-9866-92951a3f555f@quicinc.com>
 <ZZPeHJJU96y1kdlZ@shell.armlinux.org.uk>
 <6593e0a3.050a0220.5c543.8e12@mx.google.com>
 <cee9de2c-bfa4-4ca9-9001-725e2041bc25@quicinc.com>
 <85590a5b-9d5a-40cb-8a0e-a3a3a1c3720a@lunn.ch>
 <c5263daa-b5f4-4b9c-a216-73d68493a802@quicinc.com>
 <50252a5a-e4fb-42d3-b838-9ef04faf4c5c@lunn.ch>
Content-Language: en-US
From: Jie Luo <quic_luoj@quicinc.com>
In-Reply-To: <50252a5a-e4fb-42d3-b838-9ef04faf4c5c@lunn.ch>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


On 1/4/2024 9:57 PM, Andrew Lunn wrote:
>> 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?

Yes, qca8386 is a pure switch plus integrated PHYs(same PHY type as
qca8084), there is no CPU on qca8386, the management path is MDIO.
the access of switch register is by the multiple MDIO operations.

> 
>>
>>     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?

My bad, sorry for this confusion.
qca8084 is a pure PHY, there is no MAC in qca8084.

> 
> 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.

Yes, Andrew, there is only one clock input to qca8084(same as qca8386),
this input clock rate is 50MHZ, which is from the output clock of CMN
PLL block that is configured by the MDIO bus driver patch under review.

In qca8084(same as qca8386), there is a clock controller, let's call it
as NSSCC, the logic of NSSCC is same as qualcomm GCC(located in SoC),
the NSSCC provides the clocks to the quad PHYs, the initial clocks for
quad PHYs need to be configured before PHY to work.

These clocks and resets are provided by the NSSCC provider driver,
i need to define these clocks and resets in DT to use it.

> 
> 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?

There is one 50M clock input for qca8084(same as qca8386), the input
clock is generated from the CMN PLL block that is configured by MDIO
driver patch of mdio-ipq4019.c.
The frequency of input clock is fixed to 50MHZ.

> 
>>    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.

Yes, it can be connected with any vendors MAC with the interface mode
supported.

> 
> 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
Got it. Thanks Andrew for the comments and suggestions.