Received-SPF: pass (google.com: domain of linux-kernel+bounces-17881-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 5 Jan 2024 14:37:16 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Jie Luo <quic_luoj@quicinc.com>
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
Subject: Re: [PATCH v8 14/14] dt-bindings: net: ar803x: add qca8084 PHY
 properties
Message-ID: <864b0867-06c0-4c6d-ae71-9b5025c8d93a@lunn.ch>
References: <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>
 <b427c89a-81a9-439f-905e-2a6632065b78@quicinc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b427c89a-81a9-439f-905e-2a6632065b78@quicinc.com>

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

Lets concentrate on the pure PHY. All it sees is a clock. It does not
care where it come from. All you need in the device tree for the pure
PHY is a clock consumer.

There is one clock input, so its shared by all four instances in the
pure PHY package. So you need to use Christians code which extends the
PHY DT bindings to allow DT properties for a package of PHYs.

What about resets. Is there one reset pin for the pure PHY package, or
one per PHY?

Go find Christians code, understand it, and propose a DT binding for
the pure PHY. Include the clock provider and the reset
provider. Forget about the MDIO controller, and the PHY integrated
into the switch, etc. Baby steps...

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

You said above, there is one clock input to the qca8084. Here you use
the word clocks, plural. Is there one clock, or multiple clocks?

    Andrew